Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-18
16:38:00 dansmith why would you
16:38:01 dansmith ?
16:38:14 dansmith if you don't request any resources from the compute node... you don't get a compute node
16:39:12 jaypipes dansmith: but the compute node is a target because the shared resource is shared with it.
16:39:40 dansmith can you give a concrete example?
16:39:55 dansmith because shared disk should be allocate-able without a compute node if you don't care about CPU/RAM right?
16:40:51 jaypipes dansmith: I actually can't think of a concrete use-case here.
16:40:52 mriedem if you request things that don't result in compute nodes, you just get NoValidHost
16:40:59 mriedem which is fine for nova scheduler right?
16:41:04 dansmith mriedem: from scheduler, but not from placement
16:41:06 mriedem we can't build you a server on a ceph pool alone
16:41:09 mriedem dansmith: sure
16:41:19 jaypipes mriedem: well, technically you get a KeyError right now :) but, even then, I'm not sure.
16:41:27 dansmith right, but it should be fine for cinder to ask for an allocation against a storage provider with nothing else
16:41:34 mriedem yeah so let's fix the KeyError in placement
16:41:39 mriedem right
16:42:23 jaypipes mriedem: yeah, I'm working on fixing that :)
16:49:57 melwitt mriedem: something I was wondering, I noticed the func tests you wrote are in novaclient, so we wouldn't catch a problem unless we look at novaclient jobs
16:50:04 jaypipes https://bugs.launchpad.net/nova/+bug/1705071
16:50:05 openstack Launchpad bug 1705071 in OpenStack Compute (nova) "[placement] Attempting to find allocation candidates for shared-only resources results in KeyError" [High,Triaged]
16:50:11 mriedem notifications meeting in #openstack-meeting-4 in 10 minutes
16:50:36 mriedem melwitt: yup, i did that because they run single tenant in serial
16:50:46 mriedem melwitt: unlike the tempest dsvm jobs
16:51:16 mriedem but idk maybe that doesn't make sense,
16:51:22 mriedem we could also do a functional test in tree
16:51:22 melwitt mriedem: okay, just wanted to make sure that was the intention. I was thinking of the overhead vs the fact that a failure there might go unnoticed for some time
16:51:44 mriedem my goal was the change that runs each test 15 times
16:51:48 mriedem to check for leaks
16:52:07 mriedem but we could also do that in tree tests i reckon
16:52:52 melwitt right. I was looking at them yesterday and wasn't sure whether to +W them once I noticed they're in novaclient. so I wanted to ask you first
16:53:41 mriedem ask and ye shall receive...a meh of an answer
16:53:48 melwitt :)
17:11:14 moshele jaypipes: hi
17:11:34 jaypipes moshele: well hello there :)
17:12:34 moshele jaypipes: can we do goolge hangout ? I have some question regarding the designer/vnic_type/vif/plugins
17:13:18 jaypipes moshele: yes, OK with me. I had asked you, jangutter and sean-k-mooney earlier today to do one.
17:13:20 moshele jaypipes: around https://review.openstack.org/#/c/484197/ and also https://review.openstack.org/#/c/398265/
17:13:57 moshele jaypipes: ha ok I guess I missed that
17:15:09 moshele sean-k-mooney, jangutter : can we do a call tomorrow?
17:15:40 sean-k-mooney moshele: sure but we are cutting it rather close if we want to have support in pike for ovs with hardware offload
17:16:33 moshele sean-k-mooney, jaypipes: what is blocking this than https://review.openstack.org/#/c/398265/
17:17:19 moshele sean-k-mooney: we can do the hw_veb refactor (https://review.openstack.org/#/c/484197/) in queen
17:17:21 sean-k-mooney moshele: it need rodolfos feature based scheduling
17:19:16 moshele sean-k-mooney: I thought we agreed that it will be just limitation with working with SR-IOV. and we will fix it in queens
17:19:32 sean-k-mooney moshele: jaypipes to supprot https://review.openstack.org/#/c/398265 we basically need https://review.openstack.org/#/c/449257/ and https://review.openstack.org/#/c/451777/
17:20:53 sean-k-mooney moshele: i dont think we should merge https://review.openstack.org/#/c/398265 without adressing the sriov work as the port creation will change. e.g. in queens you would need to set the feature request in teh port binings so it existing vms would be broken on upgrade
17:21:02 jaypipes moshele: I'm more concerned about os-vif patches that are dependencies.
17:21:14 jaypipes moshele: since those have a hard freeze date of this Thursday
17:21:21 jaypipes moshele: do we have a list of those patches?
17:21:56 sean-k-mooney jaypipes: you should have an email titled [openstack-dev][os-vif] 1.6.1 release for pike. in your inbox
17:22:22 sean-k-mooney jaypipes: i belive the should have section are the required os-vif patches
17:22:41 jaypipes sean-k-mooney: yes, been going through that
17:23:10 jaypipes sean-k-mooney: the representor ones, yeah?
17:23:21 sean-k-mooney yep these Improve OVS Representor Lookup https://review.openstack.org/#/c/484051/
17:23:22 sean-k-mooney Add support for VIFPortProfileOVSRepresentor https://review.openstack.org/#/c/483921/
17:23:24 sean-k-mooney unplug_vf_passthrough: don't try to delete representor netdev https://review.openstack.org/#/c/478820/
17:23:25 jaypipes gotcha
17:24:03 sean-k-mooney for melonox only https://review.openstack.org/#/c/478820/ is needed. for netronome the other two are also needed
17:28:36 moshele sean-k-mooney: sorry I don't follow, how it will break upgrade. If the limitation will be that SR-IOV mechanism driver and OVS hardware offload can't coexist in pike
17:30:06 sean-k-mooney in queens the could and existing deployment could not be upgrades as vm that have neutron ports without the feature request could get scheduled to node following upgrade that had both deployed
17:30:08 mriedem melwitt: ok so i think we're hunky dorey on the current list of comments in https://review.openstack.org/#/c/416521/ - are you going to rebase that today?
17:30:30 melwitt mriedem: yeah, running unit tests over it now for sanity first
17:30:40 mriedem awesome opposum
17:30:50 melwitt thanks :)
17:30:52 mriedem i'm going to make coffee and rebase my service/hypervisor api uuid change for the next hour
17:31:20 gibi jaypipes: I'm leaving for today. I will read back tomorrow moring
17:31:23 openstackgerrit melanie witt proposed openstack/nova master: Make security_group_rules use check_deltas() for quota https://review.openstack.org/477700
17:31:24 openstackgerrit melanie witt proposed openstack/nova master: Remove 'reserved' count from used limits https://review.openstack.org/446242
17:31:26 openstackgerrit melanie witt proposed openstack/nova master: Make key_pairs use check_deltas() for quota https://review.openstack.org/477699
17:31:28 openstackgerrit melanie witt proposed openstack/nova master: Remove useless quota_usage_refresh from nova-manage https://review.openstack.org/446243
17:31:29 openstackgerrit melanie witt proposed openstack/nova master: Count instances to check quota https://review.openstack.org/416521
17:31:34 openstackgerrit melanie witt proposed openstack/nova master: Make Quotas object favor the API database https://review.openstack.org/410945
17:31:37 openstackgerrit melanie witt proposed openstack/nova master: Add online migration to move quotas to API database https://review.openstack.org/410946
17:31:44 sean-k-mooney moshele: basicaly this break if you ever enable the sriovnicagent and ovs with offload in the same deployment and do a livemigrate unless you carfull segratate with availablity zone and make sure you dont have a mix off both backend in the same availablity zone
17:39:36 sjmc7 hi gibi. sorry, meant to bring this up in the notifications meeting but i had to step away for a bit. we were having a discussion last week about the field that the API returns as ‘status’ - do the notifications have an equivalent?
17:42:16 openstackgerrit Feodor Tersin proposed openstack/nova master: Implement ScaleIO image backend https://review.openstack.org/407440
17:51:29 mriedem dansmith: can you poke through this and see if i'm at least on the correct track? https://review.openstack.org/#/c/481748/ if so then i can go ahead with clarifying some of the wording
18:09:28 openstackgerrit Jay Pipes proposed openstack/nova master: placement: alloc candidates only shared resources https://review.openstack.org/484900
18:09:31 jaypipes gibi: ^^
18:10:39 jaypipes mriedem, dansmith, edleafe, cdent: I'd like your opinion on above please.
18:10:44 jaypipes bauzas: you too. :)
18:16:46 edleafe jaypipes: (after quick read) - so requesting some DISK_GB will return hosts that have it local, hosts that have it via shared resources, and the shared RP themselves?
18:17:10 edleafe (*just* DIK_GB)
18:17:17 edleafe DISK_GB
18:17:49 jaypipes edleafe: it will return a single allocation_request (allocating against the shared storage provider) but will include both the shared storage provider as well as the shared-with providers (the compute nodes) in the provider_summaries part of the response.
18:18:09 dansmith mriedem: does that help at all? it's a little rambly
18:18:17 jaypipes edleafe: and yeah, this is for when someone requests allocation candidates and specifies requested resources and those resources are only shared.
18:18:20 dansmith mriedem: edleafe: where is the set for the flavor overrides?
18:18:44 dansmith I assume based on the questions in there that the healing of existing instances isn't in place
18:19:02 edleafe jaypipes: what about something like DISK_GB, where the resources are both local and shared?
18:20:23 dansmith jaypipes: did you just say that if I ask for DISK_GB that I'll get back the shared provider (i.e. a netapp) and all the compute nodes as providers that share with it?
18:20:46 jaypipes edleafe: that's handled already and does not produce the KeyError.
18:20:47 edleafe dansmith: I'm working on that code. When the ironic driver starts up, it will handle the inventory/allocation corrections
18:21:04 dansmith edleafe: working on meaning it's not up in any form yet?
18:21:09 edleafe jaypipes: OK, fine. Like I said, I just did a quick read
18:21:18 edleafe dansmith: righty-o
18:21:28 jaypipes dansmith: you will get back a single allocation_request that references the shared storage provider, and the provider_summaries section of the HTTP response will contain the UUIDs of the provider that are shared with.
18:21:32 mriedem jaypipes: questions / comments inline
18:21:33 edleafe dansmith: I just got an ironic devstack working with custom RCs this morning
18:21:37 dansmith edleafe: okay, but the flavor overrides stuff is up right? but not yet merged?

Earlier   Later