15:01:34 <ihrachys> #startmeeting neutron_upgrades
15:01:38 <openstack> Meeting started Mon Jan 16 15:01:34 2017 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:41 <openstack> The meeting name has been set to 'neutron_upgrades'
15:01:44 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam
15:02:12 <electrocucaracha> o/
15:03:05 <korzen> hello
15:03:07 <ihrachys> today is MLK day in some US offices, that's why I believe we have lower presence
15:03:17 <korzen> what is MLK?
15:03:24 <ihrachys> Martin Luter King day
15:03:30 <korzen> oh, ok
15:03:42 <electrocucaracha> Yeah , it's
15:03:44 <korzen> we do not have this holiday in Europe ;)
15:03:49 <ihrachys> electrocucaracha: Intel celebrating?
15:04:14 <korzen> Intel US szhould have free day
15:04:29 <ihrachys> I see. well, I am in RedHat US, and I don't have a holiday. ;)
15:04:29 <electrocucaracha> Yes, but Rackspace no
15:04:47 <ihrachys> gotcha. ok, let's run it quick.
15:04:55 <ihrachys> #topic Announcements
15:05:31 <ihrachys> as you know, there is PTG next month
15:05:43 <ihrachys> armax sent an email with a link to etherpad: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110040.html
15:06:07 <ihrachys> it would probably make sense to brain storm which upgrade topics may be worth covering there
15:06:12 <ihrachys> and filling in the etherpad
15:06:33 <electrocucaracha> I won't be able to be there, but I'll try to follow you in etherpad
15:06:49 <ihrachys> I was thinking we can try to make progress on mixed server version gating, but that probably belongs to cross-project sessions, not neutron
15:07:21 <korzen> I have made some small list:
15:07:28 <korzen> API versioning
15:07:33 <korzen> New mechanism for blocking contract migrations
15:07:39 <korzen> Online Data Migration
15:08:06 <ihrachys> korzen: what's the 'new' mechanism?
15:08:26 <korzen> ihrachys, I mean to change that UT
15:08:49 <korzen> maybe it is not so critical
15:10:08 <ihrachys> I guess it's high detail. as for other two, I think both are good. can you put them into the pad so that we can start expanding on them this week?
15:10:30 <korzen> ok
15:12:05 <ihrachys> ok cool
15:12:11 <korzen> do you think about something more to be discuss?
15:13:24 <ihrachys> I think we are otherwise good; push-notifications progress may also be relevant to us, but I believe it will be raised in other context.
15:15:06 <ihrachys> ok, don't hesitate to fill in the pad with more topics if you come up with any
15:15:08 <ihrachys> #topic Partial Multinode Grenade
15:15:44 <ihrachys> linuxbridge job still not feeling well. I also saw tempest (not grenade) job failing at 30%+ rate previous week.
15:16:03 <ihrachys> so I was not really sure if it's grenade specific
15:16:13 <ihrachys> now it seems the tempest flavour is back to normal
15:16:17 <ihrachys> http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=8&fullscreen
15:16:48 <ihrachys> gotta look at it closer this week
15:17:21 <ihrachys> reminder: it's already in check queue, but not-voting so far.
15:17:35 <ihrachys> let's move to objects
15:17:36 <ihrachys> #topic Object implementation
15:18:17 <ihrachys> we landed DictOfMiscValuesField: https://review.openstack.org/411830
15:18:29 <korzen> :)
15:18:46 <ihrachys> we also landed tenant_id -> project_id switch: https://review.openstack.org/#/c/382659/
15:18:58 <korzen> good work dasm
15:19:44 <ihrachys> one of the more critical bits up for review is port binding adoption: https://review.openstack.org/#/c/407868/
15:19:57 <ihrachys> I reviewed it the previous week; it's currently in conflict
15:20:04 <ihrachys> would be nice if we can rebase it sooner
15:20:17 <korzen> I will ping Lujin
15:20:24 <ihrachys> thanks
15:20:51 <korzen> I was about to rebase and address comments but waited for path author to do it first
15:21:12 <ihrachys> there is nothing major there now, it's just a matter of code cleanup
15:23:37 <korzen> I wonder if subnet, port and network OVO adoption patch are relevant?
15:23:42 <korzen> for Ocata release
15:23:44 <ihrachys> NetworkSegment adoption: https://review.openstack.org/#/c/385178 also seems close
15:23:52 <ihrachys> korzen: it may or it may not, depending on readines
15:23:57 <ihrachys> *readiness
15:24:13 <ihrachys> electrocucaracha: anything that blocks us from respinning ^ ?
15:24:37 <electrocucaracha> I don't remember the last issue
15:24:47 <ihrachys> electrocucaracha: I will look at the UT failure you mentioned for .db_obj
15:24:59 <ihrachys> apart from it, it seems close
15:25:05 <electrocucaracha> Ohh that one
15:25:36 <electrocucaracha> I can take a look but that will be tomorrow
15:26:27 <ihrachys> electrocucaracha: sure, no need to spoil the holiday ;)
15:26:47 <ihrachys> korzen: are any of those adoptions close?
15:27:05 <korzen> subnet is
15:27:17 <korzen> port and network are non-existing
15:27:33 <korzen> subnet is implemented
15:27:46 <korzen> but I had issue with db_obj being detached from session
15:28:06 <korzen> and I'm waiting for Ann to get it fixed with new engine facade
15:28:19 <ihrachys> I see. will new engine fix it?
15:28:45 <korzen> yes, because the new engine is adding the object to active session
15:28:49 <korzen> db_obj
15:29:32 <korzen> well, I need to rebase subnet adoption patch on top of Ann's patch
15:29:47 <korzen> but in theory it should work
15:29:57 <ihrachys> korzen: I guess it's https://review.openstack.org/#/c/402750 that is needed for subnet?
15:30:13 <korzen> yes, that one
15:31:11 <ihrachys> it's mostly very simple
15:31:16 <ihrachys> I will take a look
15:31:21 <ihrachys> in the meantime, rebase would be nice
15:31:21 <electrocucaracha> What about the Flavor and service Profile patch it's also close to be completed
15:31:27 <korzen> It is also a matter of push-notification
15:32:36 <ihrachys> electrocucaracha: that one, I just +2d it again, let's find a second opinion. rossella_s, https://review.openstack.org/#/c/306685/ maybe?
15:32:59 <rossella_s> ihrachys, ack, will look at it
15:33:03 <ihrachys> korzen: I am not sure push-notification is related, but we will cover it in a separate section
15:33:10 <electrocucaracha> Thanks rossella_s
15:33:21 <rossella_s> electrocucaracha, my pleasure
15:34:12 <ihrachys> ok, let's move on to next section
15:34:17 <ihrachys> #topic Other patches to review
15:34:23 <electrocucaracha> Just FYI, I included a new status on the spreadsheet that can help to focus on those OVo patches that I consider ready
15:34:36 <ihrachys> electrocucaracha: thanks
15:34:38 <ihrachys> first topic is, multiple port binding
15:35:02 <ihrachys> spec being https://review.openstack.org/#/c/309416/
15:35:11 <ihrachys> I think it's very close, next respin should do
15:35:46 <ihrachys> there is also a patch adding host to primary key in the binding table: https://review.openstack.org/#/c/404293/
15:36:32 <ihrachys> that one is also very close, I just need to have a look at replies to my comments.
15:37:13 <ihrachys> with that, we may get the PK expansion in Ocata BEFORE nova or neutron starts writing into it, which should simplify the online db upgrade matters once we get to landing actual extension
15:37:48 <ihrachys> which prolly won't happen this time
15:38:19 <ihrachys> any questions on port binding?
15:38:25 <korzen> so the whole feature port binding for LM wont happen in Ocata
15:38:27 <korzen> ?
15:38:34 <ihrachys> korzen: it looks that way, yes.
15:39:02 <korzen> I was thinking at implementation patch, if we also need to update the OVO?
15:39:07 <korzen> for port binding
15:39:11 <ihrachys> I think back in Barcelona, there was agreement that it may as well happen, so it shouldn't be news for e.g. nova
15:40:14 <ihrachys> korzen: if we land db expansion this cycle only, then no need to update it in Ocata; we will add new field in Pike
15:40:43 <ihrachys> for status
15:41:03 <ihrachys> or you mean that now primary key is expanded, so we need to reflect it in the object?
15:41:39 <korzen> if we are expending, then it should not matter
15:41:47 <korzen> expanding*
15:42:12 <korzen> until API and backend code is ready to consume it
15:42:17 <ihrachys> korzen: well, for one, get_object should allow only filters that result in unique result?
15:42:52 <ihrachys> and unless we add the host to PK in object, it will happily accept just port_id
15:43:00 <korzen> so you mean when we will have extra PK, ovo get_object won't work?
15:43:53 <ihrachys> I think it may then fail if there are multiple matching records in db
15:44:20 <korzen> get_object would return .first()
15:44:25 <ihrachys> hm, we implement get_object as .first
15:44:28 <ihrachys> yea
15:44:54 <korzen> adding new PK is backward compatible
15:44:58 <korzen> right?
15:45:21 <ihrachys> if the code does not assume a single record (like calling .one) then yes, it's ok
15:45:22 <korzen> there is no new code that will insert port_id twice
15:45:38 <ihrachys> btw I checked Newton code and haven't found any place were we would assume that
15:46:08 <ihrachys> there is no such code now, but there will be in Pike, so Ocata code should be ready for that.
15:46:45 <korzen> good point
15:46:50 <korzen> I will take another look
15:47:46 <ihrachys> ok, let's move on to push notifications
15:47:48 <korzen> so, I guess that merging the port binding ovo adoption in Ocata would be helpful
15:47:57 <korzen> one last question ;)
15:47:59 <ihrachys> korzen: absolutely!
15:48:04 <korzen> ok
15:48:13 <ihrachys> korzen: was that your question?
15:48:21 <korzen> that one
15:48:36 <ihrachys> ok. yes, it would be very helpful. I want to land it asap.
15:48:36 <korzen> merging port_bindgin adoption
15:48:40 <korzen> ok
15:49:02 <ihrachys> speaking of push-notifications, kevinbenton made some progress
15:49:13 <ihrachys> a patch to mention is server side notifier: https://review.openstack.org/#/c/388939/
15:49:34 <ihrachys> the notifier subscribes to AFTER_* events, re-fetches the relevant object, and pushes it on the wire
15:49:44 <ihrachys> note it re-fetches, not reuses the same object
15:49:51 <ihrachys> that was used during update of the database
15:50:19 <ihrachys> that's what I meant saying that landing adoption patches is not strictly relevant to push-notifications now
15:50:51 <ihrachys> is my thinking correct? korzen
15:52:01 <korzen> it looks like
15:52:39 <korzen> it would affect only the RPC
15:52:46 <korzen> and not REST API
15:52:57 <ihrachys> right. as long as we can construct the object from ID, it should do
15:53:34 <ihrachys> I don't know of any patches that currently consume the objects on agent side, but I believe kevinbenton is on it
15:53:49 <ihrachys> we may want to help with reviews there too
15:54:34 <korzen> I was looking at some patches but did not have enough time to jump into details
15:54:49 <ihrachys> korzen: so far there is not much to review there
15:54:52 <ihrachys> ok let's look at the list of patches with UpgradeImpact: https://review.openstack.org/#/q/status:open+message:%22UpgradeImpact%22+project:openstack/neutron
15:55:14 <ihrachys> ok, first one will require a spec/write-up, so we can skip that one
15:55:55 <ihrachys> second is, not allowing to start macvtap agent with wrong bridge configuration: https://review.openstack.org/#/c/323398/
15:56:00 <ihrachys> sounds like no-brainer to me
15:56:15 <ihrachys> and we do it for other agents already
15:57:03 <ihrachys> finally, the patch that claims to solve another network disruption in ovs agent: https://review.openstack.org/#/c/305724/
15:57:13 <ihrachys> I thought we solved all of those like 2 cycles ago? :)
15:57:42 <korzen> in Liberty
15:57:47 <ihrachys> seems like it's l2pop only, at least that's what the patch touches
15:57:47 <korzen> and in Mitaka
15:57:52 <ihrachys> so corner case
15:57:55 <ihrachys> korzen: and in Newton! :)
15:58:21 <ihrachys> if that's l2pop only, we may look into expanding the scenarios list in fullstack connectivity tests.
15:58:28 <korzen> which one was in Newton?
15:58:33 <ihrachys> I believe we have some tests there that restart agents and ping in the meantime
15:58:38 <ihrachys> korzen: I am just kiddin'
15:59:03 <korzen> :)
15:59:15 <ihrachys> ok, let's do the last quick
15:59:18 <ihrachys> #topic Open discussion
15:59:22 <ihrachys> there is not much time
15:59:31 <korzen> https://review.openstack.org/#/c/336518/
15:59:33 <ihrachys> but if you have something to raise and move to #openstack-neutron please do
15:59:37 <korzen> ihrachys, ^
15:59:42 <ihrachys> sigh
15:59:42 <korzen> please review ;)
15:59:43 <ihrachys> yeah
15:59:55 <electrocucaracha> Thanks
16:00:09 <korzen> ok, thanks :)
16:00:10 <ihrachys> ok that's it, we need to free the floor
16:00:12 <ihrachys> #endmeeting