| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-18 | |||
| 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 | https://review.openstack.org/#/c/484900/1/nova/tests/functional/db/test_resource_provider.py@2709 | |
| 18:30:26 | mriedem | yeah | |
| 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 | |
| 18:35:39 | mriedem | on another note, i just got this text, "the only thing i need from you on my birthday is for you to say absolutely nothing in response to what my mom is sending to me for my birthday" | |
| 18:36:02 | mriedem | to which my immediate reaction was, "oh f*" | |
| 18:36:28 | mriedem | god i hope it's a PUPPY!!! | |
| 18:36:34 | dansmith | hah | |
| 18:36:36 | openstackgerrit | Michael Bayer proposed openstack/nova master: Generalize DB conf group copying https://review.openstack.org/484908 | |
| 18:38:05 | edleafe | mriedem: a restraining order? | |
| 18:38:16 | jaypipes | edleafe: no, that was last year. | |
| 18:39:22 | mriedem | laura's mom is sending her a restraining order to keep them apart? | |
| 18:39:24 | mriedem | that doesn't make sense | |
| 18:39:35 | mriedem | it's probably a drone with an ipad controlled by a puppy | |
| 18:39:42 | mriedem | and some kind of vacuum | |
| 18:39:49 | mriedem | b/c that's all the kinds of crap laura's mom sends for every event | |
| 18:40:24 | dansmith | no it has to be something better than an airborne puppy-controlled vacuum camera | |
| 18:40:26 | mriedem | breaking news folks: it's yet another hardwood floor cleaner | |
| 18:40:40 | mriedem | i hope it plays nice with the other 3 we already have | |
| 18:40:56 | melwitt | lol floor cleaner? that doesn't sound very fun | |
| 18:41:22 | mriedem | laura's mom (1) love gadgets (2) shopping on qvc and (3) cleaning | |
| 18:41:25 | mriedem | *love's | |
| 18:41:27 | mriedem | loves? | |
| 18:41:46 | mriedem | so we have a pile of floor cleaners and tablets all over the house | |
| 18:41:48 | dansmith | I was thinking more along the lines of a "how to get excited about having a second child" book or something | |
| 18:42:01 | mriedem | that ship sailed a couple of years ago | |
| 18:42:02 | melwitt | lol | |
| 18:42:07 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: alloc candidates only shared resources https://review.openstack.org/484900 | |