15:02:01 <ihrachys> #startmeeting neutron_upgrades
15:02:02 <openstack> Meeting started Mon Jan 23 15:02:01 2017 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:05 <openstack> The meeting name has been set to 'neutron_upgrades'
15:02:13 <electrocucaracha> howdy
15:02:16 <korzen> Hello
15:02:17 <ihrachys> hi everyone
15:02:20 <sindhu> hi
15:02:21 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:02:35 <dasanind> hi
15:03:00 <ihrachys> #topic Announcements
15:03:27 <ihrachys> ptg is coming, please fill in the etherpad with your names and topics if you visit the event: https://etherpad.openstack.org/p/neutron-ptg-pike
15:03:54 <ihrachys> also, this week is milestone-3
15:04:35 <ihrachys> next week is rc-1, which will traditionally slow down feature development
15:05:00 <ihrachys> it will be a good time to test what we have though
15:05:12 <ihrachys> more info about the release schedule is at: https://releases.openstack.org/ocata/schedule.html
15:06:27 <ihrachys> #topic Partial Multinode Grenade
15:07:16 <ihrachys> I guess no one got to test multinode mixed server versions so far, did anyone?
15:07:28 <electrocucaracha> nope
15:07:35 <korzen> I'm preparing
15:07:39 <korzen> for it
15:07:53 <sshank_> Hello all.
15:07:58 <korzen> I hope to do some manual tests by end of week
15:08:03 <korzen> or next week
15:09:28 <ihrachys> cool. I will see if I can jump on it too. I have some spare time in my list which I may fill in with some testing too.
15:09:30 <korzen> It will be some fancy containerized control plane env
15:09:56 <korzen> with kubernetes and fuel-ccp
15:10:27 <korzen> I hope to be it quick and reliable :)
15:10:44 <korzen> a little more convenient then devstack
15:10:51 <ihrachys> I guess so. :)
15:10:57 <manjeets> o/
15:11:57 <ihrachys> in other news, linuxbridge grenade job is still failing ~40% times comparing to ovs one with ~15%
15:12:05 <ihrachys> no progress on that one that I know though
15:12:27 <ihrachys> #action ihrachys to report bugs for linuxbridge grenade multinode failures
15:13:40 <ihrachys> #topic Object implementation
15:14:02 <ihrachys> we merged some bits lately
15:14:09 <ihrachys> #link https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db Merged patches
15:14:15 <ihrachys> ipam objects: https://review.openstack.org/360799
15:14:27 <ihrachys> auto-allocated-topology: https://review.openstack.org/357506
15:14:35 <ihrachys> flavour: https://review.openstack.org/306685
15:15:05 <ihrachys> I think we are doing some progress on other patches. let's see what's in queue
15:15:13 <ihrachys> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db Open patches
15:15:30 <electrocucaracha> yeah, the other big patch is Quotas
15:15:40 <ihrachys> ok, tag is almost there, but failed in gate queue: https://review.openstack.org/356825 Probably something irrelevant and we need to recheck.
15:16:05 <electrocucaracha> ihrachys: I've rechecked
15:16:13 <ihrachys> electrocucaracha: yeah, I didn't get to that because of its size so far :)
15:16:33 <ihrachys> port binding patch is, I believe, ready to go: https://review.openstack.org/407868
15:16:37 <ihrachys> rossella_: ^ please ;)
15:16:39 <manjeets> ihrachys, and external network is also up for review https://review.openstack.org/#/c/353088/
15:17:10 <ihrachys> also network segment integration seems ready: https://review.openstack.org/#/c/385178/
15:17:14 <korzen> I have subnet adoption patch, but it is huge and I'm dependent on engineface job being merged first
15:17:29 <korzen> enginefacade*
15:17:35 <ihrachys> manjeets: gotcha
15:17:52 <ihrachys> korzen: and that enginefacade patch is not ready to merge
15:18:13 <korzen> yea, it is still evolving
15:18:31 <korzen> but subnet is not critical
15:19:07 <electrocucaracha> what about DistributedVirtualRouterMacAddress?
15:19:56 <electrocucaracha> forget it, it seems like it's still on progress
15:20:48 <ihrachys> I am doing reviews when I get time. I will raise the patches with one +2 today during the meeting so that we can get those in quick.
15:20:52 <korzen> what about port binding level object?
15:21:08 <sshank_> korzen, It seems to be complete.
15:21:13 <korzen> https://review.openstack.org/#/c/382037/
15:21:16 <ihrachys> korzen: I am still to look at that l3_agent object field. I am not sure that's the right thing but I need to check the context.
15:21:24 <sshank_> korzen, https://review.openstack.org/#/c/382037/
15:21:38 <ihrachys> oh wait, that's another one
15:21:55 <ihrachys> in that one, I think we need to understand why we can't expose segment as an object on top of the level.
15:21:56 <korzen> l3_agent is in router binding
15:22:08 <dasanind> yeah https://review.openstack.org/#/c/360908/
15:22:09 <ihrachys> because if we can't, it means that port json representation won
15:22:14 <ihrachys> ...'t contain segmenti nfo
15:22:33 <ihrachys> which may be bad for push-notifications
15:22:47 <korzen> won :)
15:23:02 <korzen> I can take a look tomorrow
15:23:15 <sshank_> ihrachys, The problem was unlike other objects, the network segement seems to point back at a field not present in the level object.
15:23:34 <ihrachys> I think it makes sense to talk to kevinbenton whether it's a problem for his use case.
15:23:56 <korzen> theoretically I can image having segment as synthetic field
15:23:56 <sshank_> ihrachys, I think you mentioned about this in the commit message while creating the object.
15:24:03 <ihrachys> sshank_: yeah I remember there was some reasoning behind what you did, I just can't recollect and will need to think a bit more on the problem.
15:24:24 <ihrachys> sshank_: yeah I was hoping that pulling port object will give you levels->segments chain
15:25:31 <sshank_> ihrachys, It seems like the network segment needs segment_id to refer back.
15:25:55 <korzen> It would be good to describe the use case, because it is well understand
15:25:57 <sshank_> ihrachys, https://github.com/openstack/neutron/commit/dcd78423aa9e3fda5234c22fc14b06064e65e689
15:26:05 <korzen> it is not well*
15:27:01 <sshank_> I am not sure how the segment synthetic field effects push notifications.
15:27:05 <ihrachys> korzen: you mean push-notifications case?
15:27:11 <korzen> ihrachys, yes
15:27:41 <ihrachys> #action ihrachys to explain the use case behind segment object field in port binding level object in https://review.openstack.org/#/c/382037/
15:28:55 <korzen> one way or the other, I can take a look at the synthetic field use case, if it is required
15:30:29 <ihrachys> I see a patch from tonytan4ever to support LIKE filters: https://review.openstack.org/#/c/419152/
15:30:33 <ihrachys> it does have a different topic
15:30:49 <ihrachys> lemme fix that
15:32:12 <sshank_> And also provisioning blocks integration seems to be done: https://review.openstack.org/#/c/361303/
15:32:54 <ihrachys> re tonytan4ever's patch, is there any reason why we implement that in agent class and not base one?
15:34:33 <korzen> nope
15:34:41 <korzen> I do not know any
15:36:02 <ihrachys> so that's one thing. another thing is UX for the filter, but I guess I should put that in comments in gerrit instead of here.
15:36:23 <ihrachys> ok let's move on to the next section
15:36:25 <ihrachys> #topic Other patches on review
15:36:47 <ihrachys> #topic https://review.openstack.org/#/q/status:open+message:%22UpgradeImpact%22+project:openstack/neutron
15:36:59 <ihrachys> the same list as from before
15:37:06 <ihrachys> oops
15:37:07 <korzen> topic?
15:37:08 <ihrachys> #undo
15:37:09 <openstack> Removing item from minutes: #topic https://review.openstack.org/#/q/status:open+message:%22UpgradeImpact%22+project:openstack/neutron
15:37:17 <ihrachys> #link https://review.openstack.org/#/q/status:open+message:%22UpgradeImpact%22+project:openstack/neutron
15:37:31 <korzen> now is better :)
15:37:35 <ihrachys> no moves on any of those patches that I see, so I guess we can move on :)
15:37:51 <ihrachys> #topic Open discussion
15:38:01 <ihrachys> nothing on the agenda
15:38:10 <ihrachys> anyone has a topic to raise?
15:38:19 <korzen> I have seen that push-notification at server side is merged
15:38:32 <korzen> #link https://review.openstack.org/#/c/388939 Server-side push notifications for ML2
15:38:56 <ihrachys> oh right. it took like 10+ rechecks :)
15:39:01 <ihrachys> gate is crazy these days
15:39:14 <korzen> does it mean that every subnet, network and port related stuff need to bump OVO version?
15:39:27 <korzen> like port binding for live migration
15:39:39 <ihrachys> korzen: probably not until we actually consume those objects?
15:40:14 <korzen> yes, I guess this is one way of looking at it
15:40:15 <ihrachys> unless we consider that RPC interface as public and hence want to maintain compatibility for any external consumers that may pop up
15:40:44 <ihrachys> I would take a shortcut this cycle because I don't believe someone will use the messages right away
15:41:33 <korzen> yes, I guess that until opening master for Pike, we are safe
15:41:52 <korzen> we can add this port binding extensions without bumping version
15:41:53 <ihrachys> yeah for Pike, we will need to be more cautious
15:42:05 <ihrachys> because we should complete push-notifications by then for sure
15:42:09 <korzen> if it will be merged this week
15:42:52 <korzen> so I guess that priority for this week is to merge the port binding adoption
15:43:00 <ihrachys> yea
15:43:03 <korzen> port binding extension for live migration
15:43:14 <korzen> and we will be good for Pike
15:43:20 <korzen> for Ocata*
15:43:30 <ihrachys> extension doesn't land this cycle, it's only db model changes
15:43:35 <ihrachys> but that's fine for our matters
15:43:43 <korzen> yes, the DB stuff
15:43:52 <korzen> well db model changes
15:43:54 <korzen> :)
15:44:55 <korzen> the spec is merged https://review.openstack.org/309416
15:44:57 <korzen> Spec for providing Nova portbinding information for live migration
15:45:33 <electrocucaracha> ihrachys: what are the plans from here until the first RC is released? implement as much as OVO as possible? reduce the number of changes to avoid issues? hardening the testing OVO framework?
15:46:32 <ihrachys> electrocucaracha: I believe it's PTL who sets the agenda here, but in general, we can land OVO patches for now
15:46:39 <ihrachys> we will definitely stop at RC-1
15:46:43 <ihrachys> and we should be cautious
15:46:49 <ihrachys> we will look at the impact
15:47:06 <korzen> when stable/ocata will be created?
15:47:11 <ihrachys> port binding changes are probably those of more impact that we should try to land
15:47:20 <ihrachys> korzen: stable branches are created from RC-1
15:47:51 <ihrachys> so in between milestone-3 and rc-1, there is like a week of cautious improvements before stable is spinned off
15:48:08 <korzen> ok
15:48:26 <ihrachys> at which point, master is in theory unblocked for new work, but then again, PTL may tweak the process to give more attention to Ocata preparations
15:48:37 <ihrachys> like asking not to land anything huge in Pike
15:48:42 <ihrachys> untill further notice
15:49:01 <electrocucaracha> got it, basically we depends on the decision of the PTL of the things that goes and not
15:49:14 <korzen> which PTL ;) ?
15:49:22 <electrocucaracha> hehe
15:49:22 <korzen> the old one or brand new?
15:49:26 <manjeets> lol
15:50:21 <ihrachys> korzen: I assume the new one will need to negotiate with the old one :)
15:52:20 <manjeets> reminder 8 mins left
15:52:42 <ihrachys> I guess we can actually make use of those 8 mins by doing some reviews and coding
15:53:05 <ihrachys> see you all next time in a week, thanks for all the work you heavy lift
15:53:11 <ihrachys> #endmeeting