| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-18 | |||
| 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 | |
| 18:29:23 | mriedem | in other words, does it make sense to get back provider summaries that have 0 resource listed? | |
| 18:29:44 | dansmith | meaning zero resource allocated in the allocations returned right? | |
| 18:29:46 | mriedem | https://review.openstack.org/#/c/484900/1/nova/objects/resource_provider.py@2577 | |
| 18:30:03 | mriedem | the compute nodes wouldn't come back in the allocations right? | |
| 18:30:08 | mriedem | only the shared storage provider | |
| 18:30:24 | jaypipes | dansmith, mriedem: well, here's the thing... | |
| 18:30:26 | mriedem | yeah | |
| 18:30:26 | mriedem | https://review.openstack.org/#/c/484900/1/nova/tests/functional/db/test_resource_provider.py@2709 | |
| 18:30:29 | dansmith | to me, if I ask for DISK_GB allocations, and I get back a couple of allocation options against a DISK_GB provider, the provider summaries should only include info about those providers, not those providers and other random ones | |
| 18:31:21 | jaypipes | dansmith, mriedem: I'm kinda thinking ahead and envisioning the cinder scheduler calling placement and wanting to get back information about the compute nodes that have some DISK_GB resources shared *with* them. Information including, for instance, distances between the compute nodes and the shared storage provider (via aggregate distance links) | |
| 18:31:40 | mriedem | jaypipes: but we can build that in later with a microversion and query parameter | |
| 18:31:45 | jaypipes | dansmith, mriedem: in that case, we would want to return the compute nodes in the provider summaries but not in the allocation requests. | |
| 18:31:50 | jaypipes | mriedem: yes, for sure. | |
| 18:31:57 | dansmith | but that's like, a long time off, and is an overlap between nova and cinder, | |
| 18:32:05 | dansmith | which the cinder scheduler may or may not be doing, right? | |
| 18:32:06 | jaypipes | dansmith: ack | |
| 18:32:17 | jaypipes | just trying to explain my thinking | |
| 18:32:43 | dansmith | specifically if the cinder scheduler is asking placement for something, I expect it's for a non-nova user, and thus compute nodes are completely irrelevant | |
| 18:33:12 | mriedem | well, | |
| 18:33:23 | mriedem | nothing is irrelevant between nova and cinder b/c we're incestual :) | |
| 18:33:33 | mriedem | e.g. AZs! | |
| 18:33:41 | mriedem | CONF.cinder.cross_az_attach ftw | |
| 18:34:04 | mriedem | i would just prefer to keep this as basic as possible for now, and build out for other use cases later | |
| 18:34:25 | dansmith | yes | |
| 18:34:26 | jaypipes | mriedem: totally cool with me. like I said, I was just trying to explain my thoughts about the future. | |
| 18:34:36 | mriedem | ack | |