15:01:30 <ihrachys> #startmeeting neutron_upgrades
15:01:31 <openstack> Meeting started Mon Feb 22 15:01:30 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:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:35 <openstack> The meeting name has been set to 'neutron_upgrades'
15:01:36 <jschwarz> \o/
15:01:37 <korzen> hello
15:01:40 <ihrachys> hi neutrinos :)
15:01:42 <sayalilunkad> hi
15:02:07 <ihrachys> ok, let's roll
15:02:09 <ihrachys> #topic Announcements
15:02:14 <ihrachys> not much on this side of things
15:02:32 <ihrachys> first, note we are approaching Mitaka-3
15:02:46 <ihrachys> meaning, we can't push patches that can break anything, and are not scheduled for Mitaka-3
15:02:50 <electrocucaracha> Hi
15:02:57 <ihrachys> so that may postpone some merges for our team.
15:03:04 <ihrachys> we'll discuss the details of that later though
15:03:29 <ihrachys> another thing is, (I can't repeat more) there is code sprint for objectification in Brno
15:03:31 <ihrachys> #link https://etherpad.openstack.org/p/code-sprint-neutron-objects-brno
15:03:49 <ihrachys> I suggest you work on bookings and write your nickname under the link
15:04:03 <ihrachys> note that I talked to a preferred hotel locally and got some better price
15:04:09 <ihrachys> details in the etherpad
15:04:16 <ski1> hey!
15:04:21 <ihrachys> so you may want to book using the trick described there
15:04:33 <sc68cal> o/
15:04:34 <ihrachys> and those who already booked that hotel, can still rebook it
15:04:41 * njohnston wishes he could make it.
15:04:50 * sc68cal will not be able to go - travel request was denied ;_;
15:05:11 <ihrachys> for now, I guess it's rossella_s and korzen confirmed, and mhickey tentatitve, and aslo some local folks
15:05:13 <ihrachys> sc68cal: that's sad
15:05:24 <sayalilunkad> I will probably join as well, will update the etherpad today
15:05:32 <ihrachys> sayalilunkad: cool, please do
15:05:47 <ihrachys> ok, now to specific topics
15:05:50 <ihrachys> #topic Partial upgrade
15:05:53 <rossella_s> ihrachys, did you check regarding the hotel rate?
15:06:02 <jschwarz> ihrachys, any further details on remote options?
15:06:02 <ihrachys> rossella_s: yes, all in the etherpad
15:06:07 <rossella_s> ihrachys, thanks
15:06:13 <ihrachys> jschwarz: we'll get some bluejeans session running I guess
15:06:22 <ihrachys> ok, so partial upgrades
15:06:25 <ihrachys> sc68cal: wanna update?
15:06:29 <sc68cal> sure.
15:06:31 <ihrachys> I know there is a major progress lately
15:06:51 <sc68cal> So - thanks to armax we were able to trace the failure back to a significant change to Nova
15:07:05 <sc68cal> they are trying to deprecate the ec2 api and did it a bit too well, the metadata service broke
15:07:35 <sc68cal> so our job uncovered a serious regression, that thankfully we caught early before Mitaka was released
15:07:39 <sc68cal> sdague was very happy
15:07:46 <ihrachys> yay
15:07:51 <ihrachys> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086914.html more details
15:08:00 <sc68cal> So we are now passing, and it is a non-voting job that is run on every changeset now
15:08:07 <korzen> CI rulezz
15:08:22 <sc68cal> I think the next step is to revive korzen 's project-config patch to make a DVR job
15:08:37 <ihrachys> right. there is an email in the thread about next steps
15:08:39 <ihrachys> #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/087136.html
15:08:49 <ihrachys> korzen: would you mind reviving the patch for dvr job?
15:09:04 <korzen> ihrachys, yes, I will take a look
15:09:30 <ihrachys> ok cool. so my understanding is that we are on good track to get Mitaka fully supported for rolling upgrade server vs. agent
15:09:34 <ihrachys> thanks all involved!
15:10:05 <korzen> good job!
15:10:06 <sc68cal> ++
15:10:29 <ihrachys> ok, now to the next topic
15:10:31 <ihrachys> #topic Object implementation
15:11:10 <ihrachys> I was mostly off or sick previous week so could not make significant review effort on that one. But I believe rossella_s is on top of it. dare to update rossella_s ?
15:11:23 <rossella_s> I finally started working on the synthetic fields patch...I should push it today
15:11:51 <korzen> rossella_s, good news :)
15:12:04 <rossella_s> sayalilunkad, is on top of the sec group extension, it's getting into shape
15:12:35 <rossella_s> korzen is taking care of the subnet ovo and of the composite key...but I guess we are a bit blocked since we can't merge stuff into master so easily
15:13:01 <ihrachys> yeah, let's discuss the merging strategy later in a separate section.
15:13:40 <ihrachys> I want to notify folks that if you want your patches to get more attention from the team, please use 'ovo' as a topic for the patches
15:13:45 <korzen> I have rebased the subnet OVO on top of composite keys patch and a hook in base object to modify the fields before DB operations
15:13:57 <ihrachys> current queue is
15:13:58 <ihrachys> #link https://review.openstack.org/#/q/topic:ovo
15:14:37 <ihrachys> rossella_s: so I guess it's currently business as usual? people spin on patches, provide reviews etc.?
15:14:45 <rossella_s> ihrachys, yes
15:14:53 <ihrachys> nothing that would block us except the release approaching
15:15:01 <rossella_s> ihrachys, you want to update maybe regarding the sqlalchemy type?
15:15:01 <ihrachys> ok cool.
15:15:14 <ihrachys> oh ok. right, on the sqlalchemy types
15:15:37 <ihrachys> I briefly looked at that one the prev week since it's a blocker for some objects like address pairs
15:15:39 <ihrachys> #link https://review.openstack.org/277558
15:15:51 <ihrachys> and proposed a version that would not mess with existing db models field types
15:16:00 <ihrachys> neither it requires any alembic conversions
15:16:12 <rossella_s> ihrachys, ++
15:16:16 <ihrachys> the patch is as simple as to allow to use OVO IPAddressField
15:16:26 <ihrachys> another similar patch should be proposed for CIDR
15:16:43 <rossella_s> and MAC address
15:17:08 <electrocucaracha> I'll need CIDR for Subnetpoolprefix
15:17:10 <ihrachys> oh right. yeah. so basically there should be a patch per unsupported OVO field.
15:17:26 <ihrachys> I suggest folks to start with those bits before getting more involved into actual objects
15:17:37 <ihrachys> first, you won't land the latter without the former
15:17:58 <ihrachys> second, those custom types are isolated from the existing neutron-server code and hence can be safely merged right now
15:18:17 <ihrachys> which would be a good usage of the time this point in the cycle
15:18:46 <korzen> I can take the CIDR type
15:18:51 <ihrachys> korzen: cool, please do
15:19:02 <ihrachys> mac address anyone?
15:19:13 <electrocucaracha> I can do my best
15:19:28 <ihrachys> electrocucaracha: ok let's assume it's on you and sync later this week
15:20:13 <ihrachys> electrocucaracha: what's the current status for sphinx integration for db models?
15:20:14 <ihrachys> #link https://review.openstack.org/#/c/274874/
15:20:44 <electrocucaracha> I've submitted the requirement to global-requirements
15:21:04 <ihrachys> right, that will be
15:21:05 <ihrachys> #link https://review.openstack.org/#/c/281880/
15:21:19 <electrocucaracha> yes, I was looking the link
15:21:19 <ihrachys> that one also fails in gate
15:21:29 <electrocucaracha> the last change passed all the tests
15:21:40 <ihrachys> oh not really, it's fine
15:21:42 <electrocucaracha> so, now I'm waiting for voting
15:22:07 <ihrachys> ok cool. let's wait for infra folks to chime in.
15:22:20 <ihrachys> electrocucaracha: you can make the neutron patch to Depends-On on the requirements patch
15:22:43 <ihrachys> electrocucaracha: then you'll get the +1 CI vote for neutron patch without waiting for requirements bit to merge
15:23:31 <electrocucaracha> ihrachys, got it
15:23:58 <ihrachys> ok, let's move on to non-object stuff
15:24:00 <ihrachys> #link Other patches on review
15:24:22 <ihrachys> I'd just note that there is a second piece for automatic RPC version pinning from ajo up for review
15:24:23 <ihrachys> #link https://review.openstack.org/268040
15:24:45 <ihrachys> currently used for QoS only, but may be interesting to track in scope of the team
15:24:52 <rossella_s> indeed
15:25:23 <ihrachys> ok, let's take some time to discuss merging strategy for objects
15:25:23 <ihrachys> #topic Merging strategy for objects
15:25:48 <ihrachys> so as I said before, there is concern around how we move forward in sight of release
15:26:07 <ihrachys> we are asked to be cautious landing patches that are not targeted for Mitaka-3 and are not release critical
15:26:08 <rossella_s> ihrachys, did you talk to armax?
15:26:26 <ihrachys> rossella_s: not yet, I will do after we discuss the approach now
15:26:33 <rossella_s> ihrachys, ok thanks
15:26:53 <ihrachys> first, the first easiest thing to do is, as I said, try to land patches that are not touching production code right now
15:26:58 <ihrachys> like those custom types
15:27:09 <ihrachys> or testing coverage features
15:27:22 <korzen> I guess we can wait for opening master for Newton
15:27:28 <ihrachys> or land objects that are not yet used in db code
15:27:37 <ihrachys> korzen: may take some significant time though
15:27:54 <ihrachys> I appreciate there are patches in review that are more invasive though
15:28:01 <ihrachys> and we may want to move with them.
15:28:16 <ihrachys> and stacking multiple patches in gerrit is not fun
15:28:20 <korzen> ok, so the good idea would to be merge only the API
15:28:32 <korzen> OVO classes without using them
15:28:56 <ihrachys> that said, if we land some fundamental bits like custom types or base db classes pieces, will it be too much stacking?
15:29:19 <ihrachys> an alternative that was noted before in irc is that we could have a short-standing feature branch for just that work
15:29:24 <rossella_s> ihrachys, I think there will be some stacking, for example for extensions
15:29:45 <ihrachys> there are some complications with feature branches. like CI is frequently broken and requires to be babysitted
15:30:01 <ihrachys> rossella_s: stacking or depends-On kind of things?
15:30:06 <rossella_s> ihrachys, I am thinking about korzen's proposal...we could merge the ovo classes + test without using them in the code base
15:30:13 <ihrachys> because the depends-on is more light weight
15:30:43 <ihrachys> rossella_s: right, that could be a solution for now, and I think that it may even keep us busy until Newton is open
15:30:43 <rossella_s> ihrachys, stacking really...because extensions are fields inside the port object for example
15:30:56 <rossella_s> ihrachys, I think so too
15:31:27 <rossella_s> ihrachys, it could work...it would be also easy to test in the code base, just sending a WIP patch were the object is introduced in the code base
15:31:30 <ihrachys> and if we are so effective that we handle all non-invasive bits before master is open, we can reconsider
15:31:45 <korzen> The only question is would changes in NeutronDbObject not break the QoS feature?
15:31:57 <ihrachys> rossella_s: right, we could just mark those WIP pieces with -2 and be safe it won't land
15:32:37 <ihrachys> korzen: I am happy to brag we have reasonable testing coverage for QoS, so we could be more or less safe there.
15:32:49 <ihrachys> korzen: and also it's still quite an isolated feature
15:33:00 <ihrachys> breaking qos is not like breaking ports :)
15:33:08 <rossella_s> I guess we have a plan to move forward then _)
15:33:15 <ihrachys> obviously, we don't want any
15:33:28 <korzen> ihrachys I hope so, I rely on the CI testing on QoS since I'm not trying to test the OVO changes each time with QoS :)
15:34:20 <ihrachys> ok, another thing that I want to suggest to people with +2 hammer is that we are mindful about git conflicts that our pieces can introduce for other release critical patches. Gerrit UI shows the conflicting patches (upper right corner), so please check the list before pressing +W.
15:34:46 <rossella_s> ihrachys, good point
15:35:22 <ihrachys> cool. I hope everyone understands that while objects are important, release is more important.
15:35:47 <ihrachys> I guess we have a plan on moving forward with objects, I will update armax on that so that we are on the same page.
15:35:49 <ihrachys> #topic Open discussion
15:35:58 <ihrachys> anything to raise/discuss?
15:36:58 <saisriki> hi, I would like to help with something
15:38:05 <saisriki> I was working on https://review.openstack.org/#/c/277558 earlier
15:38:24 <rossella_s> saisriki, maybe you can coordinate with electrocucaracha regarding the MAC field
15:38:30 <ihrachys> saisriki: right. thanks for that, it was a good base.
15:38:37 <ihrachys> another idea is checking what's in:
15:38:39 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam#Backlog
15:38:39 <electrocucaracha> +1
15:38:56 <saisriki> ok
15:39:05 <ihrachys> another piece that asks for more reviews (not exactly coding) is:
15:39:06 <ihrachys> #link https://review.openstack.org/#/c/124946/
15:39:16 <ihrachys> that's framework for tests for alembic scripts
15:39:42 <ihrachys> if you feel like getting some expertise with this piece, it would be cool to review
15:39:47 <ihrachys> or play locally
15:39:59 <rossella_s> and the port security extension needs some love, I didn't get any feedback from dguitarbite
15:40:07 <ihrachys> rossella_s: link?
15:40:08 <saisriki> ihrachys: ok
15:40:11 <dguitarbite> Hello
15:40:12 <dguitarbite> Im here
15:40:25 <rossella_s> ihrachys, no link, there's no patch upstream AFAIK
15:40:35 <dguitarbite> rossella_s: How shall I proceed. I predict atleast one more week before I can resume working on it
15:40:51 <rossella_s> dguitarbite, do you have something that you can upload?
15:41:00 <dguitarbite> I have stubs ... boilerplate code ready ... not sure if it helps uploading it. But I will if you think its better.
15:41:02 <rossella_s> dguitarbite, then probably saisriki can help you
15:41:17 <dguitarbite> rossella_s: I am in for collaboration.
15:41:20 <ihrachys> dguitarbite: I think it's good to upload what you have and just mark as WIP
15:41:31 <ihrachys> dguitarbite: and then others may chime in and update it
15:41:41 <dguitarbite> ihrachys: Ok, Ill upload the patch,
15:41:53 <rossella_s> dguitarbite, thanks
15:42:10 <ihrachys> ok I guess we gave plenty of options to try to saisriki :) hopefully saisriki's head is not blowing :)
15:42:16 <ihrachys> anything else to discuss?
15:42:46 <saisriki> ihrachys: thanks
15:42:59 <korzen> we should reach to other neturon folks that upgrade are important
15:43:15 <korzen> and try to make you way to Newton as priority
15:43:27 <korzen> s/you/our
15:43:39 <ihrachys> korzen: any specific ideas how to achieve that?
15:44:17 <korzen> ML
15:44:24 <ihrachys> korzen: I guess we made some progress in Mitaka in keeping the community informed about this part of the process (we updated devref, we blocked some patches that could break the rolling scenario etc.)
15:45:53 <ihrachys> korzen: ok, what would be the contents of the discussion apart from the general call to be more cautious about upgrades?
15:46:11 <korzen> I guess that Neutron is behind the Nova and Cinder and without the Neutron online upgrade the whole Openstack Upgrade story is not complete
15:46:53 <korzen> there are pleanty of topics not yet covered
15:47:27 <korzen> for example the online schema migration working for different neutron server working in the same time
15:47:36 <korzen> online data migration
15:47:46 <ihrachys> korzen: agreed on the general stanza, and the fact that we are behind. that said, isn't it a proper reflection of resources we have for the topic?
15:48:32 <ihrachys> I am all for getting more people on board with patches that will get us quicker into online data migration world.
15:48:37 <ihrachys> I wonder how to achieve that
15:48:47 <ihrachys> it's either talking to them and hoping for the best
15:49:07 <ihrachys> or putting some strict rules that would force them to take care of missing framework pieces
15:49:40 <rossella_s> I guess during the summit we can raise these points and probably get more people interested
15:50:07 <ihrachys> and I am really not sure we reached the point where we could ask folks to fill in missing gaps e.g. for online data migration, because that would basically mean asking them to land all objects
15:51:11 <ihrachys> and the fact that we don't have the process followed and documented for any single resource (yet) makes it hard to sell
15:51:12 <korzen> the online data migration may be dependent on OVO implementation but the finishing the schema migration
15:51:55 <ihrachys> korzen: can you reword the last one? I am not sure I follow.
15:52:45 <korzen> current implementation of online schema migration does not support scenario when multiple Neutron servers are running in the same time in different versions
15:52:53 <korzen> you have to put down all the servers
15:52:58 <korzen> and then upgrade them
15:53:39 <ihrachys> korzen: right, but that's because we allow to land contraction migrations
15:53:58 <ihrachys> and the latter is because we have no other sane way to isolate data migration in runtime (read: no objects)
15:54:13 <ihrachys> so the proper order would be: get objects in, then forbid contractions
15:54:27 <ihrachys> does it make sense, or I miss something?
15:55:27 <korzen> I'm not expert in OVO to make sure that OVO will do the job right
15:55:45 <korzen> but I can image that you are right ihrachys ;)
15:56:00 <ihrachys> well, that's how nova achieves no downtime server upgrade - by isolating data migration behind object facades
15:56:40 <ihrachys> then you have some dirty code in the object, but not spilled thru the code base
15:57:33 <korzen> yeap, that make sense
15:57:38 <ihrachys> korzen: don't get me wrong: even making people more aware about the next steps can be a worthy thing to do. I suspect some people lack the whole picture on why we even want the objects. so ML posts can serve the need somewhat. and discussions on the summit too.
15:58:07 <ihrachys> anything that get people on board is the step to take
15:58:36 <ihrachys> and I guess I may want to get back to devref and update it with more details on the intended path to no downtime
15:58:47 <ihrachys> unless someone does it before I reach there
15:59:00 <ihrachys> I think that no downtime bit is not documented there just yet.
15:59:15 <rossella_s> please do ihrachys !
15:59:26 <ihrachys> ok I guess we should wrap up, it's time to give space for the next meetings :)
15:59:29 <ihrachys> thanks everyone
15:59:34 <ihrachys> and keep up the good work
15:59:34 <ihrachys> #endmeeting