| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-05 | |||
| 15:09:20 | efried | mordred: well, okay, interpreting the conf sections tho | |
| 15:10:20 | mordred | that could maybe be worth it | |
| 15:33:46 | openstackgerrit | Balazs Gibizer proposed openstack/nova stable/queens: Stabilize unshelve notification sample tests https://review.opendev.org/674636 | |
| 16:13:48 | mriedem | stephenfin: after debugging for a few hours i think i figured out the problem, | |
| 16:14:40 | mriedem | https://github.com/openstack/nova/blob/433b1662e48db57aaa42e11756fa4a6d8722b386/nova/network/neutronv2/api.py#L1807 builds a list of network dicts with a small subset of the actual network values we'd care about, in this case physical_network | |
| 16:15:28 | mriedem | that likely means this is mtu is wrong when attaching a port as well https://github.com/openstack/nova/blob/433b1662e48db57aaa42e11756fa4a6d8722b386/nova/network/neutronv2/api.py#L2775 | |
| 16:56:08 | efried | dansmith: Please let me know when you're dug out and available for a couple minutes. | |
| 16:59:41 | dansmith | efried: I'm not dug out, but looking for anything else to do but keep digging | |
| 16:59:54 | efried | dansmith: oh, neat. | |
| 17:00:07 | efried | so at last week's meeting we discussed a couple of feature freeze exceptions | |
| 17:00:22 | efried | and basically gave you the deciding vote for both of them. | |
| 17:00:50 | dansmith | that's ... odd | |
| 17:01:26 | efried | dansmith: http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-08-01-21.00.log.html#l-59 | |
| 17:01:44 | efried | the old "give action items to the absent guy" trick | |
| 17:02:17 | dansmith | so the image encryption and pcpu ones? | |
| 17:02:20 | efried | y | |
| 17:02:40 | dansmith | I didn't know the former was even a thing, which might be a bad sign | |
| 17:02:56 | efried | oh, mriedem seemed to think you had discussed it at the PTG and on IRC. | |
| 17:03:22 | efried | fungi is TC liaison for the popup team, he might be able to summarize from a xproj perspective. | |
| 17:03:36 | fungi | yup, just catching up real fast | |
| 17:04:07 | dansmith | well, I was involved in the earlier image encryption stuff | |
| 17:04:30 | dansmith | er, the signing stuff I mean | |
| 17:04:34 | fungi | it's the image encryption work the secustack folks have been trying to coordinate between barbican/cinder/glance/nova | |
| 17:04:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: neutron: avoid redundant show_network calls in _get_physnet_tunneled_info https://review.opendev.org/674422 | |
| 17:04:53 | fungi | so involves interrelated specs in all of them | |
| 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. | |