| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-10 | |||
| 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? | |
| 19:32:00 | superdan | we've had bugs reported because they changed the size of the flavor foo and the instances didn't change and that was surprising to them | |
| 19:32:10 | mordred | _wow_ | |
| 19:32:30 | sdague | superdan: right, given the way horizon exposes it, I'm not surprised | |
| 19:32:34 | superdan | yeah | |
| 19:32:38 | sdague | it's actually extra terrible UX | |
| 19:33:24 | superdan | leakypipes: before we go expose flavors in their current form, are we not supposed to at least consider reporting them in an RP-friendly way? like so that when we get rid of the current notion of a flavor we're not pinned to this format? | |
| 19:33:58 | superdan | leakypipes: like, does it matter if we just tell them how much DISK_GB they got and not necessarily report the split between swap and root and ephemeral? | |
| 19:34:02 | sdague | mordred: so even if we decided to make flavors undeletable (which I think has other fallout) it would have to be in a microversion, which means it would be a very long time before that was fundamental behavior | |
| 19:34:15 | superdan | we can't make them undeletable, IMHO | |
| 19:34:20 | sdague | mordred: honestly, it is better to get the horizon expectations reset | |
| 19:34:21 | mordred | yah. I see that ship as having sailed | |
| 19:34:23 | superdan | that's also punching ops in the face | |
| 19:34:39 | mordred | fwiw, I do not feel _strongly_ about name or id. I have a contract with shade users that I'll always be providing an id key in the flavor dict of a server, but I can easily just plop a none in there if it goes away from the server record | |
| 19:35:08 | superdan | mordred: in some sense, your flavor id becomes the uuid of the instance itself after boot | |
| 19:35:09 | mordred | so, in the realm of "mordred will scream and yell and rant for years" and "mordred will just sigh and have a beer" 0 this is WAY much more in the beer stage than the other | |
| 19:35:19 | superdan | mordred: if we later allow you to "buy an extra gig of ram".. that's what it'll be | |
| 19:35:22 | mordred | superdan: I can see that argument | |
| 19:35:57 | sdague | superdan: so, while it could some day | |
| 19:36:02 | sdague | it really doesn't today | |
| 19:36:14 | superdan | sdague: what doesn't? | |
| 19:36:35 | sdague | it feels like there is definitely a common case of "I want another like that one" | |
| 19:36:52 | superdan | sdague: that's even worse, because we know that id can be wrong | |
| 19:36:57 | superdan | if you teach people to ask for another just like it, | |
| 19:36:58 | sdague | and if people didn't rename all their flavors, or hot resize | |