| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-10 | |||
| 19:02:56 | jroll | thanks | |
| 19:03:16 | cfriesen | has anyone run into problems in the field due to heat trying to scale out with a flavor that has been deleted? Or is that sort of thing usually dealt with by issuing notifications of upcoming flavor changes? | |
| 19:03:35 | mriedem | cfriesen: no one uses heat in the field | |
| 19:03:42 | cfriesen | lol | |
| 19:03:50 | mriedem | btw, let me just say, trying to sort this ptg topics etherpad into some kind of agenda is giving me heartburn | |
| 19:04:28 | jroll | mriedem: just watching our new ptl sort ironic's topics gave me heartburn | |
| 19:04:32 | leakypipes | pretty sure it was bauzas that didn't like the get_inventory() stuff, but I can't find his comments now. maybe comments were only on IRC>... | |
| 19:05:14 | leakypipes | ah, no.. it was figleaf :) | |
| 19:05:35 | leakypipes | this patch here, comment from figleaf on PS3: https://review.openstack.org/#/c/415920/ | |
| 19:05:44 | mriedem | i'll go fill out foundation marketing surveys instead, that'll be much more fun | |
| 19:06:31 | superdan | leakypipes: well, regardless, I think that's the way to go IMHO | |
| 19:06:34 | leakypipes | that patch series originally added an update_inventory() method to the virt driver interface. | |
| 19:07:15 | mriedem | update_inventory() in each virt driver does seem gross | |
| 19:07:24 | mriedem | but get_resource_thingies() seems fine | |
| 19:07:30 | mriedem | if only ironic needs to return anything, then so be it | |
| 19:07:47 | mriedem | that's why i was thinking, just add a 'resource_class' key to the get_available_resources() dict | |
| 19:08:18 | superdan | mriedem: yeah, just "show me your resources, beeyotch" in the virt drviers | |
| 19:08:24 | superdan | not "update 'em too" | |
| 19:08:27 | leakypipes | mriedem: err, that already exists :) | |
| 19:08:52 | superdan | jroll: that's what I'm talking about | |
| 19:08:54 | leakypipes | https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L331 | |
| 19:09:17 | mriedem | ok, | |
| 19:09:26 | leakypipes | that's how things *already* work :) only for Ironic of course, though. | |
| 19:09:32 | mriedem | so why do we need the extra 'if resource_class: do special ironic stuff' in RT? | |
| 19:09:42 | superdan | because it's the wrong layer | |
| 19:09:47 | superdan | instead of returning the node class, | |
| 19:09:49 | superdan | we should return resources | |
| 19:09:53 | mriedem | because it's doing the whole drop old types, add new resource class | |
| 19:09:56 | superdan | so that the RT doesn't need to translate | |
| 19:09:56 | leakypipes | mriedem: because Ironic doesn't require the node.resource_class to be present. | |
| 19:10:15 | superdan | the ironic driver can return the VCPU, DISK, and IRONIC_FOO things when appropriate | |
| 19:10:21 | leakypipes | Take a look at the first PS on this: https://review.openstack.org/#/c/415921/ | |
| 19:11:22 | superdan | leakypipes: why not just "return inventory"? | |
| 19:11:25 | leakypipes | specifically, go here: | |
| 19:11:26 | leakypipes | https://review.openstack.org/#/c/415921/8..1/nova/virt/libvirt/driver.py | |
| 19:11:31 | leakypipes | line 5471 | |
| 19:11:59 | superdan | I don't like the semantics of this, but the general idea is what I'm saying | |
| 19:12:12 | leakypipes | superdan: because there was a complaint that "the virt driver then needs to understand the internals of the resource provider and inventory modeling of the placement API"./ | |
| 19:12:30 | jroll | I don't think it does | |
| 19:12:42 | jroll | it just needs to know what a VCPUS is, what a MEMORY_MB is, etc | |
| 19:12:42 | superdan | it just needs to know about resources, which is completely reasonable IMHO | |
| 19:12:53 | superdan | right | |
| 19:12:54 | superdan | and it knows about those today | |
| 19:13:00 | superdan | we just have to translate them from useless to usefulish in the RT | |
| 19:13:10 | superdan | and then we get shit like "if ironic, do other stuff" too high in the stack | |
| 19:14:54 | superdan | leakypipes: okay so I have sufficiently shit all over your thing, but I think that the end result is getting to do it like you originally wanted right? | |
| 19:15:02 | leakypipes | superdan: and hierarchies of providers, and traits, etc... | |
| 19:15:07 | melwitt | mriedem: on that max_count = 50 thing on the map_instances, I was trying to say I think because of the map_all = True it will keep looping doing batches of 50 until all are mapped, and then it will return 0 | |
| 19:15:46 | leakypipes | superdan: heh, who knows? I think I've actually had about 3 different patch series that use three different strategies to get there. :) | |
| 19:15:53 | mriedem | melwitt: you're right | |
| 19:15:54 | mriedem | i'm dumb | |
| 19:17:12 | leakypipes | jroll: just go for it :) | |
| 19:17:30 | jroll | leakypipes: I will try next week sometime | |
| 19:17:37 | superdan | jroll: well, we're two weeks from being able to do that right? | |
| 19:17:41 | jroll | or at least pseudo-code it on the list | |
| 19:17:52 | jroll | superdan: from being able to do what now | |
| 19:17:53 | superdan | leakypipes: well, sorry I dunno what to say.. you asked me to review it | |
| 19:17:58 | superdan | jroll: draw shit on the walls | |
| 19:18:09 | jroll | superdan: yeah that too | |
| 19:18:18 | figleaf | superdan: my objection was that there was too much in terms of placement engine implementation details in the virt layer | |
| 19:18:19 | jroll | f your language | |
| 19:18:34 | figleaf | superdan: not that the virt layer reported its inventory | |
| 19:18:49 | cfriesen | leakypipes: regarding https://review.openstack.org/#/c/265282/4/specs/pike/approved/instance-flavor-api.rst , mordred specifically asked for the flavor "id" to be included as a historical data point about what was used to boot the instance. | |
| 19:18:59 | leakypipes | superdan: no worries man :) | |
| 19:19:07 | superdan | figleaf: the resource class and inventory part of placement is very much the business of the virt driver, IMHO.. | |
| 19:19:17 | cfriesen | leakypipes: even though that id might represent something else now. | |
| 19:19:19 | figleaf | jroll: I think that we *all* need a more visual representation of the flow of information through the code | |
| 19:19:30 | superdan | figleaf: reporting it to placement is not, but reporting it up the stack to compute manager and RT is | |
| 19:19:36 | jroll | figleaf: I want one built in VR where I can swim through it | |
| 19:19:47 | leakypipes | cfriesen: nobody listens to mordred. nothing to see here. move along. | |
| 19:19:51 | figleaf | jroll: you might drown | |
| 19:19:52 | mordred | leakypipes: :) | |
| 19:20:20 | jroll | ha | |
| 19:20:27 | dims_ | LOL | |
| 19:20:57 | leakypipes | here is a visualization of the data flow between the systems: http://www.27bslash6.com/images/logo_for_simon_edhouse.gif | |
| 19:21:13 | superdan | now I'm paying attention | |
| 19:21:16 | jroll | wow | |
| 19:21:50 | leakypipes | ok, back to work people. | |
| 19:21:57 | superdan | wait, which one is ironic and which one is nova | |
| 19:21:58 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/resource-providers-scheduler-db-filters.html#other-deployer-impact needs to be updated... | |
| 19:22:02 | superdan | I think ironic is behind, no? | |
| 19:22:29 | jroll | I thought front was nova devs and back was the resource tracker | |
| 19:22:50 | jroll | that's been my experience | |
| 19:22:52 | superdan | jroll: well, certainly has been true some of the time | |
| 19:23:12 | jroll | mriedem: what about it | |
| 19:23:22 | mriedem | jroll: last paragraph isn't correct | |
| 19:23:25 | mriedem | i can update it | |
| 19:23:34 | jroll | ah ok | |
| 19:23:36 | mriedem | but it's going in my ocata marketing survey so it needs to be spotless | |
| 19:23:49 | leakypipes | mriedem: what about the last paragraph is incorrect? | |
| 19:24:18 | mriedem | leakypipes: we don't even attempt to use placement until all of your computes are ocata | |
| 19:24:23 | mriedem | and they can't start in ocata w/o reporting into placement | |
| 19:24:27 | jroll | mriedem: trying to make readers' minds melt so they don't see that you don't care about marketing surveys? | |
| 19:24:34 | mriedem | the fallback described in there says that you can get like one compute / RP back | |
| 19:25:56 | mriedem | specifically, "There may be a short period of time while the scheduler receives a smaller-than-accurate set of resource providers that meet the requested resource amounts." | |
| 19:25:58 | leakypipes | mriedem: gotcha. you want me to push up a fix? | |
| 19:26:23 | mriedem | i think the rest of it, while not correct per the implementation, is generic enough that it's still truthy | |
| 19:26:27 | mriedem | leakypipes: if you want | |
| 19:27:00 | leakypipes | thx mordred I see that :) | |
| 19:27:41 | superdan | mordred: you don't think it's confusing to say that this instance is from flavor foo when foo exists an is totally different now? | |