Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-23
17:15:44 efried aspiers: I knew a guy who copy/pasted one of those obfuscated perl regex commands into his interpreter. It was one of those //ee things, and translated to something like rm -rf /
17:15:55 aspiers efried: OK. I guess this will start making a lot more sense as I start reading that code and hacking on it
17:16:19 aspiers efried: Ouch, that's a more sinister case of the "curl ... | sudo bash" syndrome
17:16:33 aspiers although I promise that all of those .sigs are totally innocent and safe to run
17:17:01 aspiers Well the top one still works, at least
17:17:36 efried aspiers: Detecting the property from the request spec is going to be the easy part. The thing mriedem and I were talking about stemmed from his patch here https://review.opendev.org/#/c/645316/ which does a very similar thing to what you're wanting to do in terms of adding stuff that'll make its way into the placement request.
17:18:59 efried tl;dr: one way to do it would be to stuff the placement-ese translation of your request - so like a resource request for 1 MEM_ENC_CONTEXT - into the actual RequestSpec.flavor.extra_specs, and make sure that that change to the flavor does *not* get persisted.
17:20:22 efried However, longer term, we're going to want to do such things by stuffing them into RequestSpec.requested_resources: https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L93-L100
17:20:55 efried but as hinted by that TODO, we're only using that for bandwidth resources at the moment.
17:21:04 aspiers ok
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: Revert "Wait for network-vif-plugged on resize revert" https://review.opendev.org/639396
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: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 jaypipes efried: obviously, there's nothing *stopping* anyone from putting MAX_INT in there :)
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: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"?

Earlier   Later