| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-18 | |||
| 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? | |
| 18:21:40 | jaypipes | thx all | |
| 18:21:43 | jaypipes | appreciated. | |
| 18:22:11 | dansmith | jaypipes: okay, that's okay then, although kinda wasteful because we don't care about the shared-with providers if they don't have anything we asked for right? | |
| 18:22:49 | edleafe | dansmith: merged https://review.openstack.org/#/c/473627/ | |
| 18:23:03 | mriedem | dansmith: i commented on that in the change too | |
| 18:23:07 | mriedem | we all had the same question :) | |
| 18:23:21 | jaypipes | dansmith: they *do* have what we asked for, though. :) it's just that a different provider is sharing those requested resources with them. | |
| 18:23:38 | dansmith | edleafe: cool | |
| 18:24:00 | dansmith | jaypipes: if I ask for DISK_GB only, I do not need to know the uuids of the compute nodes associated with the disk provider placement returns to me | |
| 18:25:07 | jaypipes | dansmith: no? I suppose so. I just figured it was best to return that information just in case. but I can easily be persuaded otherwise I suppose :) | |
| 18:25:21 | mriedem | jaypipes: dansmith: so i asked the same in the change, | |
| 18:25:29 | dansmith | jaypipes: definitely no. | |
| 18:25:32 | mriedem | but concluded that for nova-scheduler, this doesn't matter as we wouldn't have this happen | |
| 18:25:33 | jaypipes | heh | |
| 18:25:34 | dansmith | jaypipes: it's not harmful, it's just noise | |
| 18:25:43 | dansmith | right, but going forward, | |
| 18:25:56 | dansmith | if something else is looking to just allocate some disk resources, | |
| 18:26:02 | dansmith | it's weird to get back compute nodes | |
| 18:26:37 | dansmith | anyway, as long as the allocation is right, we can worry about it later | |
| 18:26:51 | mriedem | i agree it's sort of weird | |
| 18:27:04 | dansmith | edleafe: and what about the change to start reporting only the custom inventory out of the ironic driver? | |
| 18:27:12 | mriedem | hard to write an api w/o a consumer | |
| 18:27:33 | dansmith | edleafe: like, is the healing of existing instances the only thing we need to finish here? | |
| 18:27:54 | mriedem | jaypipes: dansmith: for now we could omit the shared providers with the thing you asked for (the compute nodes in this case), | |
| 18:28:04 | mriedem | and later, if someone wanted that, we could make it a query parameter on the api | |
| 18:28:14 | mriedem | ?include_friends=True | |
| 18:28:19 | jaypipes | mriedem: you mean omit the *shared-with* providers? | |
| 18:28:32 | mriedem | return the provider that has the resource you're asking for, | |
| 18:28:37 | mriedem | so the shared storage pool | |
| 18:28:40 | mriedem | and omit the compute nodes related to it | |
| 18:28:50 | mriedem | add that support in later with a query parameter, just an idea | |