| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 17:43:06 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Revert resize: wait for external events in compute manager https://review.opendev.org/644881 | |
| 17:43:22 | efried | aspiers: more or less. I think this would be better positioned as a method in request_filter.py personally, but that's details. The thing that you'll be needing that isn't applicable in --^ is how you determine whether to add the thing. | |
| 17:43:26 | aspiers | efried: so the new method would frob either reqspec.flavor.extra_specs or reqspec.image? | |
| 17:43:34 | efried | yes | |
| 17:44:06 | aspiers | ahah OK, request_filter.py looks pretty trivial to extend | |
| 17:44:07 | efried | aspiers: But that code path has access to the reqspec too, so whatevs. | |
| 17:44:14 | aspiers | right | |
| 17:44:17 | efried | yes, in fact I should -1 mriedem's patch for that. | |
| 17:44:35 | aspiers | I was going to ask, why didn't https://review.opendev.org/#/c/645316/2/nova/compute/api.py extend request_filter.py :) | |
| 17:45:10 | efried | well, I was going to say it's because the logic of how he's determining whether to add the filter comes from someplace that's not easy to get at from request_filter.py | |
| 17:45:36 | mriedem | efried: that is the rason | |
| 17:45:37 | mriedem | *reason | |
| 17:45:47 | aspiers | ahah, right | |
| 17:45:57 | mriedem | the multiattach info is on the bdm, and even then only after it's connected | |
| 17:46:01 | aspiers | but in my case all I need is the request_spec | |
| 17:46:04 | efried | yup | |
| 17:46:16 | mriedem | so during server create, the request filter would have to loop the bdms looking for the volume_id, then query cinder to get the volume multiattach flag | |
| 17:46:22 | mriedem | which is pretty shitty for performance during scheduling | |
| 17:46:33 | efried | and since this is all about performance during scheduling... | |
| 17:46:39 | aspiers | Ok awesome, this is starting to make a lot of sense | |
| 17:46:42 | mriedem | right | |
| 17:46:53 | aspiers | efried: tweaking the spec now | |
| 17:46:55 | mriedem | well, it's about performance and not picking a compute that doesn't support multiattach | |
| 17:47:05 | efried | aspiers: Hold on a tick, I'm answering your other concern too. | |
| 17:47:15 | aspiers | efried: ok | |
| 17:47:19 | mriedem | if we stored a multiattach attribute on the bdm object and stored something about those in the request spec it'd be a different story | |
| 17:47:22 | mriedem | but that's a lot of ifs | |
| 17:51:35 | tssurya | gibi: if I bump the version on the instance_payload do I need to manually also bump the versions on all payloads inheriting from the instance_payload ? | |
| 17:53:56 | efried | aspiers: responded. And hanging out if you have questions. | |
| 17:54:01 | aspiers | efried: thanks! | |
| 17:54:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add nova-multi-cell job https://review.opendev.org/655222 | |
| 17:54:46 | mriedem | dansmith: let's cross our fingers and toes ^ | |
| 17:54:57 | dansmith | hoo boy | |
| 17:55:08 | efried | aspiers: Also note that jaypipes responded. | |
| 17:55:27 | aspiers | yep, already saw that | |
| 17:55:57 | efried | jaypipes: Are you okay with "unlimited" being expressed as MAXINT inventory? | |
| 17:58:23 | efried | or, heh, an allocation_ratio of 1E9999 :P | |
| 17:59:25 | jaypipes | efried: there is no such thing as an unlimited inventory. it there was, it would be a trait, because it isn't quantitative/consumable. | |
| 17:59:30 | aspiers | efried: "It'll be up to the driver to determine what that inventory should look like and what it's based on, knowing that the request will always be for 1 unit." - my point was that maybe we *don't* know that | |
| 18:00:11 | aspiers | efried: e.g. picking a stupid example, what if MKTME counted it per vcpu rather than per host? | |
| 18:00:52 | efried | jaypipes: rightright, this is a case where there's always a limit, but sometimes we don't know exactly what it is, so we need to let it be imposed by the host (not by placement). But we still need an inventory, so the driver can in that case specify an inventory that's "arbitrarily large". | |
| 18:00:52 | jaypipes | efried: obviously, there's nothing *stopping* anyone from putting MAX_INT in there :) | |
| 18:01:02 | jaypipes | efried: just saying it doesn't really make sense to me :) | |
| 18:01:48 | aspiers | efried: but in the future I'm guessing AMD machines *may* remove that limit | |
| 18:02:00 | aspiers | at least it's not something we can immediately rule out | |
| 18:02:24 | efried | aspiers: Then the driver would use an inventory of actual_limit/num_vcpus or something clever | |
| 18:02:29 | efried | aspiers: But I also meant to mention this: | |
| 18:02:52 | efried | if something like that does come up, we can always add a new, specialized resource class for that. | |
| 18:03:18 | aspiers | well sure, but that's why I was suggesting starting with an implementation-specific resource class | |
| 18:03:32 | efried | aspiers: But do you understand my counter-usecase for that? | |
| 18:03:48 | efried | It means you'll *never* be able to schedule generically. | |
| 18:04:02 | efried | whereas if you start generic, you can always get more specific. | |
| 18:04:29 | aspiers | I don't see why, since our plan is for the user to always use encrypt_memory=true | |
| 18:04:49 | aspiers | the request filter can then decide into which resource classes to translate that request | |
| 18:04:56 | efried | yes, exactly. | |
| 18:05:07 | efried | In an env where there's AMD_SEV and INTEL_MKTME, which would it choose? | |
| 18:05:36 | aspiers | so a RequestSpec can't do "give me either foo or bar"? | |
| 18:05:49 | efried | nope | |
| 18:05:53 | aspiers | ahah | |
| 18:05:57 | sean-k-mooney | you can do that with traits | |
| 18:05:59 | efried | more to the point, placement can't | |
| 18:06:02 | sean-k-mooney | but not resouce classes | |
| 18:06:15 | sean-k-mooney | actully that has not merged yet | |
| 18:06:28 | aspiers | OK | |
| 18:06:31 | sean-k-mooney | or been coded | |
| 18:07:04 | aspiers | efried: so it sounds like basically this isn't even a debate, the only way to make it work is to have a vendor-agnostic resource class :) | |
| 18:07:08 | sean-k-mooney | im think of https://review.opendev.org/#/c/649992/ | |
| 18:07:25 | efried | sean-k-mooney: We have ?traits=in:X,Y,Z, don't we?? | |
| 18:07:32 | aspiers | I'm fine with that - it's certainly going to make it easier to justify in the spec | |
| 18:07:38 | sean-k-mooney | efried: there is a spec for that | |
| 18:07:59 | sean-k-mooney | which is the one i linked https://review.opendev.org/#/c/649992/ | |
| 18:10:41 | efried | aspiers: One can envisage starting off with a specific resource class, and then moving to a generic one when the next one is introduced. Resulting in an interesting upgrade problem where you may have to "reshape" existing inventories/allocations from the old resource class to the new one. And we still support mismatched conductor/compute environments, IIRC, though I can never remember which one has to go first, so that could also | |
| 18:11:24 | efried | aspiers: So it's still a debate, yes; it could be made to work either way, yes; but IMO for reasons stated, generic is a bit more future-proof without actually losing you anything. | |
| 18:12:35 | efried | sean-k-mooney: Hmph, I coulda sworn we already had required=in:..., but I don't see it in the api-ref. | |
| 18:13:19 | efried | yup, that spec. | |
| 18:14:08 | sean-k-mooney | ya so they were previously approved for stein but no implemented | |
| 18:15:39 | sean-k-mooney | anyway with a generic resocue class and specific trats we could support that usecase if we hav requrie=in | |
| 18:15:49 | sean-k-mooney | or we could reshape | |
| 18:16:05 | sean-k-mooney | we do however already have the trait | |
| 18:22:44 | efried | mriedem: Would you be able to run the nova meeting this Thursday? I got suckered^wroped into school runs. I should be back around :15-:20. | |
| 18:31:31 | openstackgerrit | Eric Fried proposed openstack/nova master: Hacking N363: Don't use spec[_set]='string' https://review.opendev.org/650370 | |
| 18:36:00 | openstackgerrit | Erik Olof Gunnar Andersson proposed openstack/nova master: Pass on region when we don't have a valid ironic endpoint https://review.opendev.org/654692 | |
| 18:41:19 | mriedem | efried: yeah i think i can do that | |
| 18:41:39 | efried | thanks mriedem | |
| 18:42:06 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: [WIP] Support adding the reason behind a server lock https://review.opendev.org/648662 | |
| 18:42:29 | efried | eandersson: Hmph, I see why you did that; perhaps I need a separate bug for min/max | |
| 18:42:45 | efried | as currently stacked, min/max would have to be partial and yours would have to be closes | |
| 18:42:46 | eandersson | Nah I think your bug is the real fix | |
| 18:42:57 | eandersson | Mine is just a fallback bug fix | |
| 18:43:28 | eandersson | but I am fine with separate bug reports as well | |
| 18:43:41 | efried | eandersson: Mine should really have a bug that says, "ksa endpoint lookup never worked because of min_version" | |
| 18:44:05 | efried | Your bug is about region_name not being respected, which is true regardless of my fix. | |
| 18:44:42 | efried | eandersson: You want to open the other or should I? | |
| 18:45:22 | efried | I mean, credit's to you for finding the problem (and pretty much for tracking down the cause too) so... | |
| 18:47:16 | eandersson | Haha | |
| 18:47:23 | eandersson | Actually yours fixes my bug 99.9% | |
| 18:47:25 | eandersson | of the time | |
| 18:47:52 | eandersson | The only time your fix does not fix my bug is if ServiceNotFound is raised | |
| 18:48:09 | efried | which probably would mean that ironicclient would raise the same | |
| 18:48:17 | eandersson | Very likely | |