| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-18 | |||
| 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 | |
| 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 | |
| 18:42:12 | jaypipes | mriedem, dansmith, edleafe: ok dokey ^^ | |
| 18:42:44 | mriedem | when amazon makes a life-like enough "my buddy" cyborg child, we'll probably have one | |
| 18:42:53 | mriedem | and then i'll make it clean my floors | |
| 18:43:29 | melwitt | my buddy, that's a blast from the past | |
| 18:43:44 | mriedem | don't forget the hulk hogan my buddy | |
| 18:43:58 | melwitt | yikes | |
| 18:49:44 | dansmith | edleafe: do you have a game plan for the heal process? | |
| 18:50:13 | dansmith | I was thinking we had to convert the instances from ram/cpu/disk, but really we just need to add the source class to them I think for pike | |
| 18:50:33 | dansmith | edleafe: which we might be able to do in an online migration instead of in the driver, now that I think of it | |
| 18:50:57 | dansmith | edleafe: but we also need the piece to make the resource tracker report allocations for the custom resources an instance has in its flavor, which I don't think is done yet | |
| 18:51:00 | dansmith | jaypipes: right? | |
| 18:51:49 | mriedem | correct | |
| 18:51:52 | jaypipes | correct | |
| 18:51:56 | mriedem | the data migration and posting allocations isn't done | |
| 18:52:35 | edleafe | dansmith: doing it in the driver's init_host has a lot of advantages | |
| 18:52:55 | dansmith | ah, the reason is because we don't easily know ironic vs. libirt instances in manage | |
| 18:52:57 | dansmith | that's why | |
| 18:53:04 | dansmith | edleafe: we just need to be good about it (i.e. spawn a thread) | |
| 18:53:09 | edleafe | mostly that it runs once, and nova can't accidentally allocate against it until the healing is run | |
| 18:53:36 | edleafe | dansmith: well, we can see about improving it once I get it working | |
| 18:53:36 | dansmith | edleafe: well, I don't think we can block compute startup entirely right? | |
| 18:53:53 | dansmith | and we don't need to until we convert the requests to be custom-only, which is queens I think | |
| 18:54:24 | edleafe | dansmith: this has to be done in Pike so we can remove it in Queens and go to custom-only | |
| 18:54:44 | dansmith | edleafe: the migration does yeah, so we can do it async | |
| 18:54:47 | openstackgerrit | Baodong (Robert) Li proposed openstack/nova-specs master: Expose vlan trunking in metadata/configdrive https://review.openstack.org/471815 | |
| 18:55:02 | dansmith | so nobody is working on reporting allocations for custom resource type overrides in the flavors, right? | |
| 18:56:18 | edleafe | dansmith: the understanding was that operators would add the extra_specs stuff before starting Pike | |
| 18:56:41 | dansmith | edleafe: to the base flavors? | |
| 18:56:44 | mriedem | edleafe: they shouldn't do any of that, | |
| 18:56:45 | edleafe | dansmith: the nodes should already be populated with a resource_class in Ocata | |
| 18:56:48 | mriedem | until this other stuff is done | |
| 18:57:02 | dansmith | right | |
| 18:57:03 | dansmith | they can't | |
| 18:57:10 | dansmith | the spec says that in queens, afaik | |
| 18:57:15 | mriedem | we could likely build something into nova-status in queens | |
| 18:57:21 | edleafe | mriedem: well, yeah - that's why this is going into Pike | |
| 18:57:29 | dansmith | if we report inventory in pike, and allocations for existing, then everything is good to cut over in queens | |
| 18:57:39 | mriedem | you could query all ironic compute nodes in all cells and get the instances from them and check to see if their flavors have been migrated | |
| 18:58:14 | mriedem | anyway i think i put some words about the operator thing in the spec amendment | |