| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-05 | |||
| 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 | Like giving them a date by which we need to have agreement, as suggested above. | |
| 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 | Okay, thanks dansmith. | |
| 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 | Meanwhile, how about the other one, mixed PCPU/VCPU in one instance | |
| 17:33:09 | efried | dansmith: sounded like mriedem was lunching. | |
| 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 | dansmith | efried: certainly not the host cpus, but the mask is letting them choose which vcpus right? | |
| 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: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. | |
| 17:53:49 | dansmith | efried: yes, specifying the numa topology is done via complex masking which is pretty gross | |
| 17:54:04 | fungi | aspiers: i can say i've used it for personal systems, but i don't remember which docs i read | |
| 17:54:09 | dansmith | efried: sure, but when that was defined, we didn't have anything else, as we do today | |
| 17:54:39 | aspiers | mriedem, fungi: having said that, I already tried passing unencoded userdata and I get this: | |
| 17:54:42 | aspiers | __init__.py[WARNING]: Unhandled non-multipart (text/x-not-multipart) userdata: 'b'network:'...' | |
| 17:54:57 | aspiers | maybe that's a separate issue | |
| 17:55:01 | efried | dansmith: I can't think of a reason why the mask would be a required thing, vs just a count as you say. But again, that's without having a bunch of context, and without rereading all the comment history leading up to whatever we've landed on at this point. | |
| 17:55:17 | efried | It would certainly reduce the test surface | |
| 17:55:21 | dansmith | efried: well, I found a comment from stephenfin which says it was rejected because "it didn't let you choose which ones" | |
| 17:55:26 | efried | though I don't imagine it would make much difference on the code side | |
| 17:55:28 | dansmith | but no explanation of why that's important | |
| 17:55:37 | fungi | aspiers: also i want to say the userdata workflow/model is sort of copied from ec2 so it may have been assumed by the authors that people were familiar with ec2... but yeah docs can always stand to be improved | |
| 17:55:38 | efried | since we would (again, guessing) reuse the code that does it for the numa pinsets. | |
| 17:56:05 | mordred | efried: woot | |
| 17:56:18 | dansmith | I guess if you want your dedicated cpu to be one of the ones with a large amount of memory or something, but we're just getting to the point where you're defining all the legacy hardware attributes fo the system and we lose all flexibility | |
| 17:56:59 | efried | dansmith: I'm pretty sure "just count 'em" is going to be supported as well, just like it is for numa split | |
| 17:57:06 | efried | but if we want to say that's the only thing... | |
| 17:57:14 | efried | I don't see a reason why that would be a problem. | |
| 17:57:21 | efried | Again, as long as the VM can figure out which is which. | |
| 17:57:25 | efried | oh | |