| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-10 | |||
| 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" | |
| 19:29:31 | mordred | but as a user who booted the server in the first place, I booted a "foo" server | |
| 19:29:43 | superdan | mordred: for what it's worth, horizon makes the above trivial to do | |
| 19:29:54 | mordred | superdan: that's really sad for everyone | |
| 19:30:05 | sdague | superdan: it does, but there are also lots of people that don't change the meanings of their flavors | |
| 19:30:06 | mordred | I think of flavors sort of like server model numbers | |
| 19:30:16 | mordred | when you order a DL380 from HPE, you get a DL380 | |
| 19:30:19 | superdan | mordred: right, horizon says "you can edit flavors" but what it really means is "I will delete and recreate it for you" | |
| 19:30:19 | mordred | it doesn't stop being a dl380 | |
| 19:30:31 | mordred | but next year, hpe will sell you a new thing called a dl380 | |
| 19:31:01 | sdague | so, it feels fine to include it, but say that the underlying definition may have changed, hence why we give you the definition of what it once was as well | |
| 19:31:09 | leakypipes | mordred: even though you can order 10 DL380s and you'll get seven different motherboard manufacturers? ;) | |
| 19:31:09 | mordred | ++ | |
| 19:31:25 | mordred | (to both of you) | |
| 19:31:30 | sdague | I also think mordred should open a bug with horizon and get them to remove that feature | |
| 19:31:43 | sdague | because, it's terrible as an easy thing to tell users to do | |
| 19:31:51 | mordred | sdague: can we just make flavors undeletable instead? | |