Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-05
14:57:37 mordred efried: I thnik that should do it
14:58:40 efried thx
14:58:54 efried it's the required-projects thing I can never seem to suss
15:01:10 mriedem efried: unrelated to that, i've noticed that we get several warnings from openstacksdk for cinder and barbican not having valid_interfaces in nova conf when functional tests fail,
15:01:15 mriedem http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22WARNING%20%5Bopenstack%5D%20Disabling%20service%5C%22%20AND%20message%3A%5C%22Encountered%20an%20exception%20attempting%20to%20process%20config%20for%20project%5C%22%20AND%20message%3A%5C%22no%20such%20option%20valid_interfaces%20in%20group%5C%22&from=7d
15:02:42 efried mriedem: that's interesting. Off the cuff, it's gotta be because we're not importing the ksa opts correctly. Investigating...
15:02:55 openstackgerrit Adam Spiers proposed openstack/nova master: Track libvirt host/domain capabilities for multiple machine types https://review.opendev.org/673151
15:02:56 openstackgerrit Adam Spiers proposed openstack/nova master: Allow assertXmlEqual() to pass options to matchers.XMLMatches https://review.opendev.org/674628
15:02:56 openstackgerrit Adam Spiers proposed openstack/nova master: Fix libvirt driver tests to use LibvirtConfigCapsGuest instances https://review.opendev.org/674629
15:03:00 aspiers kashyap: ^^^
15:03:55 aspiers efried: a couple of those are trivial changes split off from the main patch, and should only take 1--2 mins to review
15:04:15 efried mriedem: oh, right, we never did finish cutting over cinder or barbican to ksa
15:05:10 efried mordred: I wonder if it's worth fixing up the oslo.config method to accept a list of services we care about, so the sdk only builds proxies for those...
15:06:58 kashyap aspiers: Ack
15:08:51 mordred efried: the proxy objects themselves are on-demand. it doesn't build something if it's not used
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

Earlier   Later