| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 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 | |
| 18:49:07 | efried | I can live with that. I can change mine to Partial-Bug and yours can be Closes-Bug. Or we can swap the order of the fixes. But I don't think we're allowed to have Partial-Bug *after* Closes-Bug. mriedem, a ruling? | |
| 18:49:19 | eandersson | The only difference is that the ironicclient is less opiniated (in it's current implementation) | |
| 18:49:27 | eandersson | Sure | |
| 18:49:35 | efried | ...I guess we can break them apart too. There's actually no reason for them to be in a series, I don't think. | |
| 18:50:32 | mriedem | efried: don't think that matters too much, but partial-bug will change the assignee, whereas related-bug wouldn't | |
| 18:50:37 | mriedem | so i'd use related-bug or separate bugs | |
| 18:51:24 | efried | they're truly both fixing part of the bug. | |
| 18:51:39 | eandersson | I assumed that partial-bug wouldn't change the assignee | |
| 18:51:41 | efried | but okay, if the assignee is the only bit of process that matters | |
| 18:51:46 | eandersson | The more you know | |
| 18:52:17 | efried | and we can always change the assignee | |
| 18:52:27 | efried | so effit, let's go as is. | |
| 18:52:31 | eandersson | Sounds good | |
| 18:53:33 | efried | mriedem: series at https://review.opendev.org/#/c/654457/ when you get a chance -- ironic ksa stuff never worked (/me sheepish); but ironicclient covered for us; but wasn't respecting region_name when it did, we were just getting lucky most of the time. | |
| 18:53:51 | efried | what other core can tackle ksa stuff? | |
| 18:53:57 | tssurya | mriedem: silly question - does the addition of an existing key (locked) to filters/sorting have anything to do with microversions ? as in we just allow them without any checks from the moment we implement them right ? | |
| 18:54:15 | eandersson | It was also partially broken on the ironic client side https://github.com/openstack/python-ironicclient/commit/c038f1db67e7809513d5535648d15c3590b191d5 | |
| 18:54:40 | mriedem | tssurya: there is a whitelist on filters and sorting params, | |
| 18:54:54 | tssurya | right, | |
| 18:54:55 | mriedem | specifying filters that aren't in the whitelist are just ignored for now (gmann has a spec to make that an error), | |
| 18:55:03 | mriedem | specifying sort params that aren't in the whitelist is a 400 | |
| 18:55:22 | mriedem | so you can't add locked as a filter/sort param without a microversion bump | |
| 18:55:39 | mriedem | efried: ack | |
| 18:55:59 | mriedem | tssurya: that's how i verified you couldn't just filter/sort on the instance.hidden field in my change | |
| 18:56:01 | tssurya | mriedem: ah because of change in behaviour for sort params? | |
| 18:56:07 | mriedem | yes | |
| 18:56:19 | mriedem | i thought we said in your spec we weren't going to start filtering/sorting on locked? | |
| 18:56:35 | tssurya | oh we did ? :D | |
| 18:56:43 | mriedem | oh nvm | |
| 18:56:45 | mriedem | "Filtering/Sorting: The locked key will be added to the existing list of valid sorting/filtering keys so that instances can be filtered/sorted based on this field." | |
| 18:56:45 | tssurya | the last iteration was that we would | |