| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-10 | |||
| 18:59:15 | leakypipes | superdan: what you're talking about there (fix the stuff in the virt driver's get_available_resource()) call is EXACTLY what I had originally proposed and that approach was shot down as too invasive of the virt layer :) | |
| 18:59:19 | mriedem | scottda: so for whatever reason, at 3am last night, i was thinking maybe we should just change the default catalog_info for nova/cinder to be v3 in pike | |
| 18:59:22 | leakypipes | superdan: lemme get a link ... one sec. | |
| 18:59:34 | superdan | leakypipes: well, this is too invasive to the RT layer, IMHO :D | |
| 18:59:37 | mriedem | scottda: anyone with older config would be using cinder v2, new nova installs would be cinder v3 by default | |
| 18:59:58 | mriedem | scottda: that would make us test nova + cinder v3 by default in the gate in pike | |
| 19:00:09 | leakypipes | superdan: see here for an original proposed solution to this: https://review.openstack.org/#/c/334038/ | |
| 19:00:22 | superdan | leakypipes: we might also haveanother method for just RP stuff, and just stop calling the old one at some point | |
| 19:00:25 | leakypipes | back in the good ole days of Mitaka :) | |
| 19:00:28 | superdan | to avoid mixing the two | |
| 19:00:39 | leakypipes | superdan: ya, totes agreed. | |
| 19:00:53 | superdan | leakypipes: where is the giant nak from zeus on that patch? | |
| 19:00:59 | leakypipes | superdan: I think we have to live with some more cruft int he RT for a time (until Queens at earliest). | |
| 19:01:09 | mriedem | ha yeah it's all +1s in there | |
| 19:02:07 | jroll | the get_inventory() method landed but not the implementations for the drivers, wat | |
| 19:02:12 | superdan | leakypipes: cruft being the reporting of both things? or what/ | |
| 19:02:40 | mriedem | leakypipes: no that was also abandoned https://review.openstack.org/#/c/334035/ | |
| 19:02:49 | mriedem | i don't know why it takes you to git.o.o | |
| 19:02:54 | jroll | mriedem: oh, weird | |
| 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 | 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? | |