Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-28
21:09:21 mriedem efried: since we don't have that https failure in devstack, we'll likely need divya to assert it fixes the bug
21:09:25 mriedem i don't have the setup for it
21:09:50 efried mriedem: Roger that. If it looks okay to you at a glance, I'll send it that way.
21:10:15 mikal mriedem: its not just unit tests, look at nova.virt.xenapi.firewall for example.
21:11:15 mriedem mikal: yeah linux_net is going to be mingled into everything
21:11:51 mriedem so i'm not really sure what the best way is to unwind the nova-net stuff since it's mixed into everything
21:12:00 mikal Orbital nukes?
21:12:25 mikal For a start, do we even know if xen people still use the dom0 firewalling stuff? Its copyright 8 years ago now.
21:12:27 mriedem well, what i know i don't want to see is a single giant patch that just deletes everything
21:12:40 mriedem mikal: would have to ask BobBall or jianghuaw_
21:12:49 mikal I think you just did?
21:13:56 cdent dansmith or mriedem : were either of you aware of jaypipes-away asking about some tweaks to oslo config to know if an option's value was coming from a default or elsewhere (even if the value was the same)? dhellman implemented a feature to support that in oslo_config but it seems to have bad mojo and maybe it can die: https://bugs.launchpad.net/oslo.config/+bug/1759689
21:13:56 openstack Launchpad bug 1759689 in oslo.config "In 1.6.0 startup can be extremely slow when checking many config items" [Undecided,New]
21:14:27 mikal This nova.virt.firewall thing is news to me and is going to be an issue I think
21:14:32 mikal Its used quite widely.
21:14:36 mriedem cdent: nope
21:14:39 cdent (sorry that's 6.0.0 above, not 1.6.0)
21:14:52 mriedem i saw the ML thread
21:15:02 mikal Oh, its security groups
21:15:09 mikal That makes sense. Why not just call it that then?
21:15:39 mriedem i will be amused when i found out that you wrote most of this mikal
21:15:50 mikal I did not
21:16:33 mikal I am innocent. My tech debt is elsewhere.
21:22:22 mriedem efried: i think https://review.openstack.org/#/c/557508/ looks ok for the most part
21:22:29 efried mriedem: Thanks.
21:22:35 mriedem i think the diff could be smaller,
21:22:42 mriedem but it's ready for divya to test
21:24:40 efried mriedem: It's really just gerrit being silly. I didn't move the method - just put the new stuff in front of it (because it makes more sense ordered that way).
21:25:08 mriedem ok
21:25:25 mriedem or,
21:25:28 mikal mriedem: looking at this, I think the first step is like privsep. Remove nova-net support from just one driver (presumably libvirt). Learn what it looks like by doing that, and then repeat for other drivers.
21:25:33 mriedem you're anal about functions being defined before they are used, like in
21:25:33 openstackgerrit Ed Leafe proposed openstack/nova master: Address issues raised in adding member_of to GET /a-c https://review.openstack.org/554357
21:25:34 mriedem c
21:25:53 mriedem mikal: yeah you're probably right
21:25:58 mriedem also,
21:26:12 mriedem the apis that are solely nova-net only will need to be cleansed to just fast-fail at any microversion
21:26:32 mriedem can't remember if we 404 or 405 for those today after the deprecation versions
21:27:28 mikal It looks to me like linux_net and nova-net are also not synonyms like I thought they were. nova.virt.libvirt.vif uses linux-net to plug devices for example.
21:27:37 mriedem yes, dansmith loves that
21:28:17 mriedem i think for the deprecated apis, you get a 404 https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi.py#L739
21:28:27 mriedem so one thing one could start with, is neutering all of those APIs
21:29:31 mikal I had assumed for privsep I could ignore nova-net, but I don't think that's true now that I learn that vif plugging calls into it.
21:29:36 mikal This is a tangled mess.
21:30:04 mikal i.e. I might be forced to privsep a bunch of "nova-net" in order to land the final couple of privsep patches.
21:31:25 mriedem mikal: or just help with the nova-net removal
21:32:11 mikal Perhaps, but I'm a hobbyist. Any critical part of nova's roadmap depending on me is going to be a problem.
21:39:25 mriedem ok, let's drop privsep from runways then :)
21:39:52 mriedem or, be OK with saying privsep won't be done by the end of your runway
21:39:53 mikal mriedem: sure, if you want. You've been saying its a low priority the whole time though. You can't have it both ways.
21:39:56 mriedem b/c of the nova-net stuff
21:40:22 mriedem what do i want both ways?
21:40:31 mriedem my point is,
21:40:42 mriedem i don't think you should do more privsep stuff for nova-net specific things when we're going to drop nova-net,
21:40:44 mikal Either you want privsep or you don't. I don't really care either way any more.
21:40:56 mriedem and if that means the privsep conversion isn't done at the end of your current runway, i think that's ok
21:41:26 mriedem also, i'm not the only person here
21:41:30 mikal I've said all along that privsep wouldn't be done at the end of the runway. The last couple of patches which need nova-net to go can just sit around until someone removes nova-net.
21:46:59 efried This seems simple to me. The scope of the runway is the privsep series up to but not including the patches that require nova-net removal. Runways don't have to encompass an entire blueprint. That was something we talked about early on, but later relaxed our stance on.
21:59:39 melwitt agreed, privsep up until the nova-net requiring ones can be done as part of the runway and that's it
22:07:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Add nova-status check for ironic flavor migration https://review.openstack.org/527541
22:10:14 openstackgerrit Eric Fried proposed openstack/nova master: Slugification utilities for placement names https://review.openstack.org/556628
22:14:51 mriedem efried: maybe you'd like to rev https://review.openstack.org/#/c/546813/ ?
22:14:57 mriedem i'm itching to +2 that
22:15:06 efried mriedem: sec...
22:16:42 melwitt mikal: earlier today we were talking about metadata API versioning because of a spec review where the proposal wants to change the network_data.json format in a new version. dansmith said new versions can be only additive and that was news to me and mgagne. is that also your understanding? we see this code comment by you above the version list https://github.com/openstack/nova/blob/master/nova/api/metadata/base.py#L60
22:17:21 melwitt and I'm not aware of any other documentation about the versioning
22:17:23 esberglu mriedem: efried: Sorry I've been caught up in some other stuff. Was planning on hitting that either tonight or 1st thing in the am
22:17:52 efried esberglu: I can punch it rn if you like.
22:19:11 mikal melwitt: I don't think we've ever done a non-additive change, but I'd have to check. The scheme is inherited from ec2, so I guess what they've done might also matter. Mostly this comes down to looking at the cloud-init implementation and seeing how it would handle the data changing.
22:20:19 esberglu efried: If you want to go for it. I'm trying to finish out a bunch system upgrades today
22:21:19 mriedem Kevin_Zheng: just a small change to add to https://review.openstack.org/#/c/536722/ about older computes
22:21:22 mriedem then i'll be +2 again
22:21:37 melwitt mikal: yeah, I think you're right that we haven't done a non-additive change. ack on having to look at cloud-init. although there might be other things consuming the API that might not handle a compat change even if cloud-init does
22:22:04 mikal melwitt: very true. You can totally write a shell script to parse metadata, that's the whole idea.
22:22:14 mikal melwitt: the original cloud-init was in fact a shell script.
22:25:59 mgagne melwitt, mikal: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
22:26:06 mgagne "The earlier versions are available to you in case you have scripts that rely on the structure and information present in a previous version."
22:26:47 mgagne my understanding of this statement is that newer versions can remove information or change structure in non-backward compatible ways
22:29:01 efried mriedem: Does that reno need to say anything beyond "The PowerVM driver now supports hot plugging/unplugging of network interfaces." ?
22:29:39 mriedem efried: nope
22:29:44 openstackgerrit Eric Fried proposed openstack/nova master: PowerVM Driver: Network interface attach/detach https://review.openstack.org/546813
22:29:46 efried mriedem: ight. ^
22:29:57 mriedem thanks
22:29:59 efried My daughter cooked me a steak. I'm out.
22:30:09 esberglu efried: tx
22:30:26 melwitt mgagne: I interpret it the same way. so, the source material for this API was intended to be able to change things between versions and break compat. it will be interesting to see how cloud-init is written and whether it would be insulated to such an API change. (and that's aside from all of the other things people may have written to consume the metadata API)
22:30:55 mikal cloud-init has heavy contributions from amazon, so we're probably ok then
22:31:14 mikal Although the openstack implementation in cloud-init probably doesn't get much love from amazon
22:31:25 melwitt yeah, that's my concern
22:31:28 mikal I do think asking someone to check cloud-init as part of the spec review is reasonable
22:31:39 mgagne melwitt: supported versions are hardcoded: https://git.launchpad.net/cloud-init/tree/cloudinit/sources/helpers/openstack.py?h=ubuntu/xenial#n44
22:32:09 mikal LOL, they're quite far behind.
22:32:35 mikal Unless xenial is shipping an old version?
22:32:36 mgagne that's for xenial, should check for latest
22:32:55 mgagne but it supports network_data.json so I'm happy =)
22:33:41 mgagne same for latest version it seems: https://git.launchpad.net/cloud-init/tree/cloudinit/sources/helpers/openstack.py?h=ubuntu/devel#n44
22:33:42 mikal https://github.com/cloud-init/cloud-init/blob/master/cloudinit/sources/helpers/openstack.py
22:33:46 mikal Trunk is just as far behind
22:34:08 mikal I guess maybe they expect us to be keeping that stuff up to date

Earlier   Later