| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-05 | |||
| 17:05:10 | mriedem | efried: not ptg, there was a forum session | |
| 17:05:14 | mriedem | with nova/cinder/glance | |
| 17:05:21 | mriedem | john and dan were there from what i recall | |
| 17:05:22 | dansmith | ah right, I remember that for sure | |
| 17:05:43 | fungi | mostly hoping that if the idea has legs from nova's side, we don't end up with the corresponding bits implemented in other projects in train but not in nova until unpossible | |
| 17:05:56 | dansmith | I just somehow hadn't come across this spec yet | |
| 17:06:16 | dansmith | seems like mriedem's comments haven't been addressed in several days though | |
| 17:06:43 | efried | We discussed that this morning in the meeting, stand by for log... | |
| 17:07:02 | efried | http://eavesdrop.openstack.org/meetings/image_encryption/2019/image_encryption.2019-08-05-13.00.log.html | |
| 17:07:28 | efried | mriedem: I kinda had to proxy for you design-wise, you prolly want to see whether what was suggested and "agreed upon" makes sense in light of your comments. | |
| 17:08:07 | fungi | and yeah, it seemed like the main reason they ended up needing to request a spec freeze exception was that they were having trouble getting folks to review it, but of course everyone's busy so it's not like i'm pointing fingers | |
| 17:09:03 | mriedem | efried: you mean this? "mhen and i discussed that it would be the best option for now to make "image_key_id" immutable. So that is just can be set in the server create step." | |
| 17:09:10 | mriedem | i think they missed the point | |
| 17:09:37 | mriedem | i think the point i was trying to make in the nova spec was that we'd need a pre-filter to filter out hosts that don't support encrypted images | |
| 17:09:53 | mriedem | likely by using the combination of image_key_id on the image and some compute capabilities trait | |
| 17:10:15 | mriedem | that resolves issues around rolling upgrades with old computes and non-libvirt drivers | |
| 17:10:29 | efried | oh, okay. I was just climbing online after weekend and hadn't reread the spec before that meeting, so I wasn't really swapped in. | |
| 17:10:46 | mriedem | it's the same idea is dansmith's disk format pre-filter, | |
| 17:10:58 | mriedem | don't land guests with an image on a driver that doesn't support the image | |
| 17:10:58 | efried | yeah, I get it now, and am remembering those comment threads. | |
| 17:11:02 | dansmith | yeah, which is broken by this btw | |
| 17:11:09 | efried | no | |
| 17:11:20 | efried | that's filtering by disk_format, not container_format | |
| 17:11:30 | efried | this will be adding a container_format filter. | |
| 17:11:45 | dansmith | efried: isn't the disk_format changed in this case as well? | |
| 17:11:49 | mriedem | i need to get lunch before a 1pm call | |
| 17:11:52 | efried | I don't think so dansmith | |
| 17:12:05 | efried | because the underlying disk_format isn't affected by encryption status | |
| 17:12:09 | efried | iiuc | |
| 17:12:15 | dansmith | I thought that the convo we had indicated that they didn't want the metadetails of the image exposed in the clear | |
| 17:12:43 | fungi | it would be good to get them to say that in the spec if that's a design goal | |
| 17:12:49 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Parse the 'os' element from domainCapabilities https://review.opendev.org/673790 | |
| 17:12:50 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Scaffolding for Secure Boot for KVM/QEMU guests https://review.opendev.org/674657 | |
| 17:13:16 | efried | I don't know if I was there (read: paying attention, or comprehending things) when that conversation occured. But I thought the important thing was the image content. Why would it matter if the disk format was in the clear? | |
| 17:13:26 | efried | but yeah, agree with fungi, that should be stated one way or another | |
| 17:13:37 | efried | (it might be, in one of the other specs) | |
| 17:14:58 | fungi | there are times when i miss having cross-project specs that tie these per-project specs together (and then i remember what an equal amount of pain that additional process was too) | |
| 17:15:16 | dansmith | efried: yeah I dunno, just thought I recalled that being a thing | |
| 17:16:04 | efried | so dansmith fungi perhaps we can take the approach of "spec freeze exception granted conditional upon reaching agreement on the spec details by XXX date" | |
| 17:16:05 | fungi | it's good feedback for the spec, if nothing else. i expect luzi and mhen are afk by now though so are unlikely to answer until tomorrow | |
| 17:16:29 | dansmith | efried: tbh, this seems like a really large thing to get an exception, | |
| 17:16:30 | efried | yes, and that's a problem - they're EU timezone and the meeting is at 6am Pacific | |
| 17:16:39 | dansmith | especially given the outstanding comments | |
| 17:17:32 | efried | It didn't seem all that huge to me. But I guess this is why you need to be involved. | |
| 17:18:08 | efried | What I don't want to have happen is, all the other projects' stars align, but the effort gets punted to U purely because we didn't get enough eyes on the nova spec early enough to land it before freeze. | |
| 17:18:46 | dansmith | I think there's a bit of papering over the details in the virt/compute side | |
| 17:19:13 | dansmith | they describe it as somewhat transparent in front of download, which defeats the stated goals, but then later make it sound like it's after download | |
| 17:19:16 | dansmith | I'm adding some comments | |
| 17:20:48 | efried | Okay, thanks dansmith. | |
| 17:20:48 | efried | I think it will help with the cross-timezone iteration if we can codify the level of urgency for them to respond and/or edit. | |
| 17:20:48 | efried | Like giving them a date by which we need to have agreement, as suggested above. | |
| 17:21:09 | efried | unless you're saying you think it's a no-go regardless | |
| 17:21:21 | fungi | thanks dansmith! presumably the risk for an exception is higher if the implementation is going to have fingers into a lot of existing code. i don't know enough about nova to know how much entanglement the implementation pieces would be for nova. i'm mostly around to advocate for the use case from the security sig's perspective, and just to remind that cross-project efforts like this tend to need a bit | |
| 17:21:23 | fungi | of timeline leniency due to trying to not expend extra community energy by having implementations misaligned between projects | |
| 17:21:33 | dansmith | well, to me, exceptions for specs and implementation are when it's like largely ready and well-reviewed and we just need a week to finish up the nits | |
| 17:21:39 | dansmith | mriedem: what's your thinking on this? | |
| 17:22:14 | dansmith | fungi: well, the spec seems to be a little confused about what layer this happens in, tbh, so I can't even really comment | |
| 17:22:15 | dansmith | but | |
| 17:22:33 | dansmith | the image handling code on the compute is largely maligned, complicated, and fragile, so... | |
| 17:23:21 | fungi | yeah, i can't say i'm overly surprised... a lot of it has probably been there since aeons | |
| 17:24:50 | fungi | my main goal is to make sure we get expectations set as early as possible for the folks who are working on this, since there may be no point in pushing to get the implementations done in other projects until the u cycle if it's not going to be possible for nova in train | |
| 17:25:47 | fungi | and i wouldn't want the other projects stuck maintaining code for an incomplete feature through an entire release | |
| 17:29:00 | fungi | on a positive note, i think there's been a lot of progress getting this effort on all involved projects' radar in this cycle, which bodes well for earlier agreement on details in the next cycle if it needs to be deferred | |
| 17:33:09 | efried | dansmith: sounded like mriedem was lunching. | |
| 17:33:09 | efried | Meanwhile, how about the other one, mixed PCPU/VCPU in one instance | |
| 17:33:22 | dansmith | efried: yep, saw, figured he can answer later | |
| 17:33:42 | dansmith | efried: just commented on the image one, give me a few | |
| 17:34:22 | efried | Okay. Summary: It seems Stephen, Alex, and Sean have come to an agreement on the design. And it's strictly conditioned on the schedule around the cpu-resources impl. | |
| 17:34:49 | dansmith | efried: ah, looks like mriedem was +0 during the meeting, and had some of the same concerns re: other drivers, so.. | |
| 17:35:03 | dansmith | on the image one I mean | |
| 17:35:09 | efried | y | |
| 17:35:57 | dansmith | efried: I'm confused, I thought the poll on the ML was that shared+dedicated on one host had no major need from ops | |
| 17:36:53 | efried | I don't remember that hitting the ML. I just know this is a big deal for the use case involving CPU priority | |
| 17:37:36 | efried | Stemming from Jay's suggestion that, instead of supporting CPU priorities in any native way, we have the operator designate their "high priority" CPUs to the PCPU pool | |
| 17:37:57 | efried | so in order to have some high and some normal priority CPUs in one instance, we need to be able to support PCPU+VCPU in one instance. | |
| 17:39:06 | efried | (are you thinking of the "NUMA and non-NUMA instances on one host" issue?) | |
| 17:41:18 | openstackgerrit | Eric Fried proposed openstack/nova master: DNM: Test blank sdk placement proxy https://review.opendev.org/674625 | |
| 17:41:41 | dansmith | efried: yeah, just found it | |
| 17:41:45 | efried | mordred: I ran that locally (against just one of the failing tests) and it seems to make it happy enough) ---^ | |
| 17:42:15 | efried | big-ish hammer | |
| 17:49:55 | dansmith | efried: is it really necessary for the user to pick which of their virtual cpus are the dedicated ones? | |
| 17:50:13 | dansmith | like, I thought the point here was that a flavor would request PCPU=2 and VCPU=2 and get two of each? | |
| 17:50:29 | aspiers | is it just me or could the note about base64 encoding in https://docs.openstack.org/nova/latest/user/metadata.html#user-data be a lot more helpful? | |
| 17:51:01 | aspiers | IMHO it's expecting too much of the average user to know how to base64 encode stuff | |
| 17:51:04 | efried | dansmith: It is *not* necessary (and Sean & Stephen made it clear that this was never going to be supported) to be able to say which *host* CPUs you get. | |
| 17:51:24 | aspiers | Or if it's not, that means I'm dumber than the average user, because I'm going to have to look it up | |
| 17:51:41 | efried | dansmith: It's also not necessarily required for you to be able to dictate the set of *virtual* CPU IDs for each. | |
| 17:52:00 | efried | dansmith: But it is necessary for the VM to be able to figure out which is which once they are assigned. | |
| 17:52:00 | dansmith | efried: certainly not the host cpus, but the mask is letting them choose which vcpus right? | |
| 17:52:13 | dansmith | efried: sure, exposing which is which is fine | |
| 17:52:17 | efried | dansmith: Isn't that already supported for numa-isms? | |
| 17:52:21 | fungi | aspiers: could probably use some additional prose, yes. short answer is `echo foo|base64` | |
| 17:52:35 | dansmith | but making them request a complicated mask instead of "two dedicated please" is kinda crazy | |
| 17:52:41 | mriedem | aspiers: the CLI does it for you https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/servers.py#L669 | |
| 17:52:44 | aspiers | fungi: thanks. I find it kind of astonishing that the CLI doesn't just do it for you | |
| 17:52:51 | mriedem | so the doc is talking about the API but confusing when giving a CLI example | |
| 17:52:56 | aspiers | mriedem: hah OK | |
| 17:53:15 | aspiers | that's also astonishing, because it suggests to me that hardly anyone is using this feature? | |
| 17:53:25 | aspiers | or they're just not reading the docs | |
| 17:53:38 | efried | dansmith: I'm not an expert here, nor have I been following the technical details deeply. But I suspect if a mask is being suggested, it's for compat with some other syntax, like the one for NUMA. | |