| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-28 | |||
| 21:05:06 | melwitt | so no, but similar | |
| 21:05:41 | efried | The Cherry Picks one (rightly) shows black-dotted patches from the other branches. I don't see black dots under Related Changes. | |
| 21:05:55 | mriedem | dansmith: one more time through the ringer https://review.openstack.org/#/c/547990/ | |
| 21:06:03 | efried | You say temporary glitch. I say it never happened. Need new glasses. | |
| 21:06:10 | melwitt | earlier before mriedem +2ed it, it was strikeouted in the Related Changes tabbydoo | |
| 21:06:27 | mriedem | i saw it | |
| 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 | openstack | Launchpad bug 1759689 in oslo.config "In 1.6.0 startup can be extremely slow when checking many config items" [Undecided,New] | |
| 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: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 | 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:33 | mriedem | you're anal about functions being defined before they are used, like in | |
| 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? | |