| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 17:22:10 | aspiers | I guess this can all be done as one of the later work items in the spec, right? Since it's more about improving the UX than actually enabling SEV | |
| 17:22:38 | efried | aspiers: Well, you don't need to talk about anywhere near this level of detail in the spec | |
| 17:23:23 | efried | I'm just showing you that it's definitely doable to support the same generic property (encrypt_my_memory=true) in the flavor and image props | |
| 17:23:34 | efried | and get it translated to placement-ese by "nova". | |
| 17:23:48 | efried | So the UX is encrypt_my_memory=true, done. | |
| 17:23:52 | aspiers | efried: but without that detail how will I pip generic-resource-pools.rst to the post for the largest spec ever? ;) | |
| 17:24:17 | efried | Add a seqdiag | |
| 17:24:22 | aspiers | but seriously, yup - it was always a goal of the spec to allow booting SEV via image properties | |
| 17:24:26 | aspiers | ohhhhh nice idea | |
| 17:24:54 | efried | http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/reshape-provider-tree.html | |
| 17:25:55 | efried | that seqdiag is only ~38L source :( | |
| 17:26:18 | aspiers | :D | |
| 17:26:37 | efried | oh, I've got a better idea | |
| 17:26:54 | efried | ascii diagrams of nested provider trees | |
| 17:26:59 | efried | those take up some good vertical space. | |
| 17:27:13 | jaypipes | I'm sure those make cdent shiver. | |
| 17:27:34 | aspiers | I was thinking more in terms of the file size | |
| 17:28:01 | aspiers | I'm about 400 bytes behind the leader ;-) | |
| 17:28:09 | efried | oh, you're going byte size? | |
| 17:28:15 | efried | I thought you were going #lines | |
| 17:29:11 | aspiers | well the ranking is the same regardless | |
| 17:29:29 | efried | one of my earlier specs, don't remember which one, dansmith literally -1'd it because it was too long. I distinctly remember trimming it by 10% to earn his +2. | |
| 17:29:40 | aspiers | haha | |
| 17:29:50 | mriedem | gmann: if i'm defining a new ci job which extends tempest-multinode-full-py3 and modify the devstack_localrc vars from that job, does it merge the vars or do i need to do a full replace with what i want? | |
| 17:29:51 | dansmith | pretty sure that's exactly how that went down, no embellishment at all | |
| 17:30:21 | aspiers | I never intended SEV to be so long, just kept getting feedback on new angles | |
| 17:31:45 | efried | aspiers: I think it was this one: https://review.opendev.org/#/c/510244/ | |
| 17:33:07 | efried | hah, yup http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-17.log.html#t2017-10-17T15:21:53 <== dansmith | |
| 17:41:18 | aspiers | efried: just looked at https://review.opendev.org/#/c/645316/2/nova/compute/api.py - IIUC I could just add an invocation of a new _modify_request_spec_for_encrypted_memory() to _provision_instances() which would apply the translation to the flavor extra specs or image properties? | |
| 17:41:41 | mriedem | heh n-obj is still enabled by default in devstack | |
| 17:41:42 | mriedem | derp | |
| 17:43:05 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Run revert resize tests in nova-live-migration https://review.opendev.org/653498 | |
| 17:43:05 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Revert "Wait for network-vif-plugged on resize revert" https://review.opendev.org/639396 | |
| 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/ | |