| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 17:10:24 | aspiers | efried: best if you skip the last 10 minutes ;-) | |
| 17:10:32 | efried | I'm the same age as artom, give or take a year. | |
| 17:10:36 | efried | stephenfin: ack, thanks | |
| 17:10:49 | efried | I used to be a perl wiz, actually taught a class at one time | |
| 17:11:24 | efried | and artom yes, all of those things. And http://www.thunderpony.com and I was also a child actor :P | |
| 17:11:34 | efried | and regular expressions are awesome. | |
| 17:11:43 | efried | now, back to request filters... | |
| 17:12:07 | artom | efried, damn, you sing as well | |
| 17:12:40 | artom | Oh, right, the thing I'm actually paid to do | |
| 17:13:14 | efried | aspiers: So the RequestSpec is how you find out if your magic key=val is in the flavor and/or image. | |
| 17:13:20 | efried | Tthe jury is still out as to what happens next. | |
| 17:13:49 | aspiers | artom: here's some fun with regexes for you https://adamspiers.org/computing/perl_signatures.html | |
| 17:14:03 | efried | mriedem and I were discussing that about 1h15m ago ^^ | |
| 17:14:21 | aspiers | efried: and that would automatically work for both extra specs and image properties? | |
| 17:14:35 | aspiers | efried: thanks, scrolling up 75m | |
| 17:14:39 | efried | aspiers: well, it would work for both if you implemented both. | |
| 17:14:51 | efried | you have access to both because they're in the RequestSpec. | |
| 17:14:54 | artom | aspiers, yeah, no :P | |
| 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 | |