15:01:55 <ihrachys> #startmeeting neutron_upgrades
15:01:56 <openstack> Meeting started Mon Jan 11 15:01:55 2016 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:00 <openstack> The meeting name has been set to 'neutron_upgrades'
15:02:12 <mhickey> Hello
15:02:18 <ihrachys> o/ everyone
15:02:23 <roaet> o/
15:02:56 <ihrachys> hello everyone after Christmas break
15:03:05 <ihrachys> this is the first meeting this year
15:03:12 <ihrachys> let's go straight into topics
15:03:14 <roaet> hoo ah
15:03:20 <ihrachys> #topic partial grenade
15:03:32 <ihrachys> sc68cal: wanna update the team?
15:04:17 <ihrachys> ok, probably Sean is not avail for now, so I will try to accommodate
15:04:47 <ihrachys> the status is we still see grenade job failing on resource creation when ssh-ing into a cirros image, and it occurs not consistently
15:05:21 <ihrachys> sc68cal made some modifications for grenade to see ssh debug output, and it seems that connection is established, but then dropbear never responds
15:05:48 <ihrachys> I had an idea today that maybe it's because of tunnelling headers not squeezing into mtu
15:06:24 <ihrachys> posted some test patches for that, but seems like they are not enough to validate the fix: https://review.openstack.org/#/q/status:open+project:openstack/neutron+topic:bug/1527675
15:06:32 <Sam-I-Am> morning
15:06:38 <ihrachys> but we'll see
15:06:59 <ihrachys> the patch passed once, though I am not sure it's because of the patch, or I was just lucky
15:07:06 <ihrachys> so rechecking more
15:08:05 <ihrachys> apart from that, I believe sc68cal also has this grenade patch in this context: https://review.openstack.org/263884
15:08:24 <ihrachys> that should change the way how we test for ssh connectivity, and should collect more logs for us.
15:08:56 <ihrachys> btw if that's indeed mtu issue, we may want to enable MTU advertisement as in: https://review.openstack.org/263486 (also from sc68cal)
15:09:13 <ihrachys> that's on partial grenade. any questions? korzen? sc68cal?
15:09:39 <korzen> nothing from my side
15:09:45 <ihrachys> ok; let's move on
15:09:49 <ihrachys> #topic versioned objects
15:10:01 <ihrachys> rossella_s: wanna update on port?
15:10:07 <rossella_s> ihrachys, yep
15:10:31 <rossella_s> ihrachys, unfortunately I didn't have as much time as I wanted...anyway I think I figured out a way to split tasks
15:11:09 <ihrachys> rossella_s: cool. that could be interesting to roaet and ski2 who were hungry for work items :)
15:11:14 <rossella_s> the thing is that port is composed by many part...I mean every extension defines some new attributes. I will take time to port everything
15:12:12 <ihrachys> rossella_s: what's the plan?
15:13:26 <rossella_s> so I was planning to start from the leaf of the three...I will submit a patch later today/tomorrow to port a leaf, something simple like extra dhcp opts
15:13:37 <rossella_s> then other people can do the same for other extensions
15:13:53 <rossella_s> then we can finally go back to the port object
15:13:56 <ihrachys> rossella_s: do we have a list of extensions to port? what do we do with extensions that are not in the tree?
15:13:59 <roaet> are the ovo extensions going to patch in attributes?
15:14:46 <ihrachys> roaet: I think we cannot just patch attrs in the object, since it changes its API. I would think of having a single field for the list of extension attrs.
15:14:49 <rossella_s> ihrachys, I can create a list of extensions, regarding extensions out of the tree they need to be ported too of course, I'd leave that for a second stage
15:15:26 <ihrachys> rossella_s: we will need to think for some compatibility layer for at least a cycle I guess?
15:15:30 <roaet> hrmm. I guess I'll have to see it. I'm a bit puzzled about how to go about doing it.
15:15:56 <rossella_s> roaet, an example is here https://review.openstack.org/#/c/253641 , see how binding is handled
15:15:59 <rossella_s> ihrachys, yes
15:16:28 <rossella_s> ihrachys, tbh I expected it to be less work ...I was too optimistic
15:16:58 <ihrachys> rossella_s: heh. isn't it always that way? :)
15:17:08 <rossella_s> ihrachys, yo
15:17:46 <ihrachys> ok, apart from ports, any news for network object? afair roaet was going to analyze the hierarchy for that.
15:18:03 <korzen> ihrachys, yes, #link: https://review.openstack.org/#/c/264273
15:18:07 <roaet> I'm in process of manually making an ERD for neutron
15:18:24 <roaet> And it was suggested to make this an automated process for devref docs as well
15:18:26 <korzen> I have posted the Network and Subnet OVO patch
15:18:29 <ihrachys> korzen: niiice
15:18:29 <ihrachys> roaet: korzen: you need to sync guys.
15:18:57 <ihrachys> roaet: do you have specific ideas for automation?
15:19:10 <roaet> throwing it into tox's doc step as a separate python process
15:19:28 <roaet> not openstack-manuals, just neutron
15:19:33 <ihrachys> roaet: what would be the output?
15:19:43 <roaet> a png erd
15:20:02 <roaet> but I'm doing it manually first so I can get the OVO stuff done
15:20:06 <ihrachys> ok, I guess you will unravel it, and then we'll see how it looks like :)
15:20:11 <roaet> the erd automation is not necessary for OVO
15:20:22 <ihrachys> roaet: see the patch from korzen ^ I haven't checked it yet, but I guess there is something already done there
15:20:24 <roaet> but the erd would be very helpful for discussions
15:20:32 <roaet> I looked at that patch some days ago.
15:20:42 <ihrachys> roaet: yeah, ERD is useful out of network object context.
15:21:05 <roaet> it also shows all the relationships between the in-tree extensions and their 'parents'
15:21:15 <ihrachys> roaet: ok. as long as you sync with korzen on what's missing, I am happy. :)
15:21:40 <roaet> cool :D
15:21:44 <korzen> I have taken the DHCP get_active_networks call and tried to mock it with Network OVO
15:21:57 <korzen> all the attr are there
15:22:14 <korzen> but please take a look if you are in favor of my solution
15:22:19 <ihrachys> ok, another thing related to objects is mhickey's 'hasher' test that should from now on forbid unexpected changes to object API: https://review.openstack.org/258026
15:22:37 <ihrachys> korzen: haven't seen the patch till now; will take a look.
15:23:01 <ihrachys> the hasher test is merged, so those messing with objects may get new test failures.
15:23:25 <mhickey> ihrachys: patch for hasher done. patch in for o.vo to wrap temp registry pattern. #link: https://review.openstack.org/#/c/263800
15:23:42 <ihrachys> mhickey: yay. thanks for that and the follow up.
15:24:13 <mhickey> ihrachys: np. that should be near to finisht. then just add the wrapped methods to neutron.
15:24:25 <ihrachys> aye aye
15:24:26 <ihrachys> speaking of object backports, ajo also posted a WIP patch for rpc callbacks upgrades: https://review.openstack.org/265347 everyone is welcome to check it out.
15:24:44 <ihrachys> ajo: wanna update us on that one?
15:24:58 <ajo> hi, sure, I was running AFK, but I'm here yet :)
15:25:21 <ajo> Basically, this implements the devref we proposed for such mechanism, but it's still incomplete,
15:25:36 <ajo> what I posted in that WIP is the core logic for it, so it's really worth reviewing even if marked as WIP
15:25:52 <ajo> probably I will remove the WIP, and push the other bulletpoints of the commit message as a separate/separate patches
15:26:12 <ihrachys> cool. folks, let's review that one. btw I will update the agenda for the meeting with links to new patches.
15:26:23 <ihrachys> ajo: if it's splittable, yeah
15:27:12 <ihrachys> #topic bugs
15:27:35 <ihrachys> I suspect we may have more content for the topic in the future, so let's adopt the habit of having one :)
15:27:45 <ihrachys> I have one bug here to mention
15:27:47 <ihrachys> #link https://bugs.launchpad.net/neutron/+bug/1531772
15:27:49 <openstack> Launchpad bug 1531772 in neutron "Liberty server and Kilo security group aware agent fail to refresh firewall for DHCP and router IPv6 ports" [High,New] - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
15:28:09 <ihrachys> that's basically rolling upgrade scenario broken for kilo to liberty upgrade for security groups
15:28:52 <ihrachys> I don't have a patch yet; anyhow, I think some may find it worth checking the description and why it's broken. the brief idea is we made incompat change to rpc interface
15:29:12 <ihrachys> rossella_s: could use your attention to that later ^ :)
15:29:44 <rossella_s> ihrachys, of course
15:29:51 <ihrachys> btw see I marked the bug with 'upgrade' tag. it's unofficial, but better than nothing. if you have more bugs like that, please mark the same way.
15:30:18 <ihrachys> ok...
15:30:22 <ihrachys> #topic open floor
15:30:29 <ihrachys> anyone have stuff to raise?
15:30:38 <mhickey> ihrachys: yes
15:30:46 <ihrachys> mhickey: floor is yours
15:31:10 <mhickey> ihrachys: https://review.openstack.org/#/c/248190/ : how to progress following conversation with HenryG today
15:31:45 <ihrachys> mhickey: ok. first, let's update the review with some comments from discussion today. it's otherwise not clear what you refer to. :)
15:32:01 <mhickey> ihrachys: sure. will I add a comment then?
15:33:12 <ihrachys> for those unaware, that's a patch to allow to determine whether there are pending contract scripts in alembic. and there is some issue due to every subproject using a separate env.py with a separate version table that is not seen in scope of neutron-db-manage db context. we probably need some subproject API that could be consumed by neutron-db-manage to determine version table names.
15:33:29 <ihrachys> mhickey: yeah, comment to add. it should give some more info to all reviewers.
15:33:43 <mhickey> ihrachys: ok, thanks
15:34:25 <ihrachys> mhickey: I would suggest to talk to HenryG about when we expect his alternative idea of converging all projects to single env.py to arrive. if it's not Mitaka, I better search for alternative way to tackle it.
15:34:45 <ihrachys> does that sound right?
15:34:51 <mhickey> ihrachys: my thinking also. probably need some solution for M.
15:34:59 <mhickey> ihrachys: kewl
15:35:23 <ihrachys> mhickey: yeah, I already told ansible folks a command will be avail in M, so I would need to deliver :D
15:35:37 <mhickey> :)
15:35:38 <ihrachys> mhickey: they were otherwise introducing some huge hacks for that
15:35:51 <mhickey> ihrachys: ack
15:35:55 <ihrachys> like walking thru the scripts, checking their file names...
15:36:12 <ihrachys> ok, anything else worth attention?
15:36:36 <ihrachys> 3...
15:36:51 <ihrachys> 2...
15:37:03 <ihrachys> 1...
15:37:22 <ihrachys> ok thanks everyone for joining. will see you all in a week! happy hacking!
15:37:23 <ihrachys> o/
15:37:25 <mhickey> bye all. thanks ihrachys :)
15:37:27 <ihrachys> #endmeeting