| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-10 | |||
| 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 | leakypipes | mriedem: because Ironic doesn't require the node.resource_class to be present. | |
| 19:09:56 | superdan | so that the RT doesn't need to translate | |
| 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 | superdan | it just needs to know about resources, which is completely reasonable IMHO | |
| 19:12:42 | jroll | it just needs to know what a VCPUS is, what a MEMORY_MB is, etc | |
| 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? | |
| 19:28:52 | superdan | mordred: like you booted this instance with flavor foo, and that flavor had 24TB of disk, but foo now has no disk and 64MB of ram, but we report that the instance's flavor is "foo" ? | |
| 19:29:12 | mordred | yah. I mean, the operator who did that is an operator who hates their users | |
| 19:29:30 | sdague | superdan: in the conversation the other day we said we'd document it as "potentially highly fictional" | |