15:00:43 <ihrachys> #startmeeting neutron_upgrades
15:00:44 <openstack> Meeting started Mon Nov  7 15:00:43 2016 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:48 <openstack> The meeting name has been set to 'neutron_upgrades'
15:00:56 <electrocucaracha> o/
15:01:08 <korzen> hello
15:01:12 <ihrachys> hey!
15:01:13 <namnh> hi
15:01:16 <asingh_> Hi
15:01:19 <ihrachys> I hope I haven't messed with a timezone? :)
15:01:37 <korzen> I have the same one
15:01:41 <ihrachys> apparently not since you are all here ;)
15:02:08 <ihrachys> friendly ping to jschwarz rossella_s
15:02:17 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam
15:02:21 <johndperkins> o/
15:02:22 <jaypipes> o/
15:02:50 * ihrachys waves at jaypipes and johndperkins
15:02:52 <jaypipes> shitbuckets, I've been caught by daylight savings...
15:02:56 <ihrachys> haha!
15:02:57 <johndperkins> hi ihrachys
15:03:06 <ihrachys> timezones suck
15:03:13 <korzen> utc for everyone
15:03:22 <ihrachys> #topic Announcements
15:04:21 <ihrachys> as you all are probably aware, we had a lively lovely summit two weeks ago. there will be a separate section for the report later in the meeting.
15:04:48 <ihrachys> we approach Ocata-1 in a week or two
15:04:49 <ihrachys> #link https://releases.openstack.org/ocata/schedule.html
15:04:57 <ihrachys> not that it usually means much... :)
15:05:19 <ihrachys> #topic Barcelona Summit
15:06:05 <ihrachys> we had an interesting discussion on neutron-server next steps that significantly touched upgrades
15:06:16 <ihrachys> the etherpad of the design session is...
15:06:18 <ihrachys> #link https://etherpad.openstack.org/p/ocata-neutron-server-next
15:06:42 <ihrachys> I expanded on it somewhat with a report in openstack-dev@
15:06:44 <ihrachys> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106684.html
15:07:16 <ihrachys> for our matters, the following is important
15:07:29 <ihrachys> 1. we agreed that in Ocata we forbid contract migrations
15:07:42 <ihrachys> #action ihrachys to send a patch forbidding contract migrations
15:08:47 <ihrachys> 2. the first candidate for in-runtime data migration using OVOs in tree will be the new port bindings rework by andreas_s needed for nova-neutron integration of live migration procedures
15:08:54 <electrocucaracha> ihrachys: when was the last time that someone submitted  a contract patch?
15:08:56 <ihrachys> there is a spec by Andreas at:
15:08:57 <ihrachys> #link https://review.openstack.org/#/c/309416/
15:09:14 <ihrachys> it would be wise to review that proposal in scope of OVO application
15:09:23 <ihrachys> electrocucaracha: Newton?
15:10:12 <electrocucaracha> ihrachys: nevermind, I can check the history
15:10:53 <ihrachys> there was a cross-project (ops) session on upgrades tags and next steps
15:11:10 <ihrachys> #link https://etherpad.openstack.org/p/ocata-xp-upgrades
15:11:26 <ihrachys> there, several things are worth mentioning
15:11:42 <ihrachys> first, ops propose defining new upgrades related tags for projects
15:11:53 <ihrachys> basically, multiple levels of upgrades scenario support
15:12:35 <ihrachys> starting from two existing ones (supports-upgrades and supports-rolling-upgrades) and going further to no-api-downtime tag, and no-api-impact one
15:12:49 <ihrachys> for our case, the most interesting is the no-api-downtime one for now
15:13:12 <ihrachys> the tag requires both technical possibility of upgrading API endpoints without downtime
15:13:19 <ihrachys> as well as CI coverage for that
15:13:38 <ihrachys> sadly, there was not much time on the session to discuss about specific gating strategy for thta
15:13:56 <ihrachys> but the main point is: other projects are also looking at gating for that (nova, glance, cinder, ...)
15:14:07 <ihrachys> so we may need to join efforts
15:15:35 <ihrachys> so, to wrap up, things we are to deliver this cycle are: 1. forbidden contractions (easy) 2. live data migration for whatever features are in the review pipeline (not much since Ocata is short and tight)
15:15:53 <ihrachys> then there is 3. CI coverage for no-api-downtime
15:16:09 <ihrachys> of course, there is still 4. ongoing switch to OVOs
15:16:22 <ihrachys> that one is last but not least, of course
15:16:47 <ihrachys> are folks still with me? :)
15:16:52 <korzen> yeap
15:16:52 <electrocucaracha> ihrachys: what about priorities?
15:17:10 * jschwarz waves at ihrachys
15:17:18 <ihrachys> electrocucaracha: priorities for what exactly?
15:17:31 <ihrachys> if you mean if OVO and related work gets a priority for Ocata, yes, it does
15:17:43 <electrocucaracha> ihrachys: number 2 and 3?
15:18:00 <ihrachys> as well as a handful of other features that were mostly on track in Newton already.
15:18:01 <electrocucaracha> ihrachys: it's important but, it's for next release?
15:18:16 <ihrachys> electrocucaracha: I think 2. is definitely a high priority if there is work to do
15:18:30 <ihrachys> electrocucaracha: no, we definitely deliver 2. in Ocata.
15:18:57 <ihrachys> CI coverage... depending on how close we are (the setup may be not easy to achieve), so it may spill over into Pike
15:19:24 <korzen> I guess that CI is cross project activity
15:19:33 <korzen> we need to setup the devstack-gate
15:19:39 <korzen> and neutron do not own it
15:20:20 <ihrachys> to set an order, that would be 1. forbid contractions 2. OVO transition and support for features in the pipeline 3/4. other OVO work. 3/4. CI coverage for no-api-downtime (depending on cross-project progress)
15:20:34 <ihrachys> right, it's cross project
15:20:49 <ihrachys> (which does not mean we can't make a tangible contribution to make it happen)
15:21:04 <ihrachys> it is definitely not in our full control
15:21:15 <electrocucaracha> ihrachys: got it, thanks
15:21:17 <ihrachys> so we will probably be lead in a way
15:23:03 <ihrachys> to close the topic of summit, there was a session from korzen on live data upgrades technics
15:23:06 <ihrachys> but I struggle to find it
15:23:12 <ihrachys> korzen: have a link?
15:24:00 <sshank> ihrachys, This https://www.youtube.com/watch?v=juunf0u4cyo
15:24:07 <ihrachys> sshank: thanks!
15:24:34 <ihrachys> full disclosure: I haven't personally had a chance to watch it just yet, but I trust it's good sauce ;)
15:24:55 <korzen> sshank, thanks, I was looking to it ;)
15:25:09 <ihrachys> anything more to update on the summit? any questions from those not lucky enough to join it?
15:26:20 <ihrachys> ok let's move on then :)
15:26:27 <ihrachys> #topic Partial Multinode Grenade
15:26:47 <ihrachys> I know some folks were playing with grenade locally the previous weeks.
15:27:16 <ihrachys> I also think that jschwarz once told me he will have some cycles to make progress on linuxbridge multinode grenade job
15:27:26 <ihrachys> any news on any of those?
15:27:41 <jschwarz> ihrachys, not yet
15:27:55 <jschwarz> sadly my last few weeks were spend on travelling and Israeli Holidays
15:28:08 <jschwarz> I'm gonna try and dedicate some cycles for this in the coming weeks
15:28:35 <ihrachys> OSIC folks playing with grenade, anything to share? questions? concerns? results? :)
15:28:41 <electrocucaracha> ihrachys: in my case, I couldn't find an issue to analyze and also I was traveling
15:28:57 <ihrachys> jschwarz: you know I won't leave you free anymore ;)
15:29:12 <jschwarz> ihrachys, I'm counting on it ;)
15:30:15 <ihrachys> electrocucaracha: ok. I assume you were trying to set it locally?
15:30:45 <ihrachys> maybe it's an easier path for the start to just analyze logs from the gate. at least to classify what fails.
15:31:31 <electrocucaracha> ihrachys: but that was my point I could find a failure gate
15:31:49 <electrocucaracha> ihrachys: anyway, we can address that offline
15:31:58 <ihrachys> electrocucaracha: you would need to 'check experimental' for that.
15:32:03 <ihrachys> electrocucaracha: sure let's take it offline
15:32:25 <ihrachys> #topic Object implementation
15:32:29 <ihrachys> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db
15:33:00 <ihrachys> there is a lot of stuff in the queue, thanks for folks producing the patches
15:33:16 <ihrachys> I should be back on track with reviews this week
15:33:29 <korzen> me too
15:33:30 <ndahiwade> ihrachys: korzen: Could you take a look at this patch https://review.openstack.org/#/c/370452/?
15:33:59 <ihrachys> also, armax and I think Kevin told me they will help with those patches. but I believe they will need a first vote from me or someone more involved in the effort, so the ball is in our park.
15:34:41 <ndahiwade> ihrachys: korzen: getting this error http://paste.openstack.org/show/588264/
15:34:41 <ihrachys> ndahiwade: looking. seems like failing in CI with legit failures?
15:35:07 <ndahiwade> It's here https://github.com/openstack/neutron/blob/master/neutron/tests/unit/objects/test_base.py#L1338
15:35:31 <ndahiwade> The assertfalse doesn't expect the synthetic field to be loaded?
15:36:22 <ihrachys> ndahiwade: I believe the check assumes that the parent object does have an empty synthetic field
15:36:30 <ihrachys> meaning, no actual child is created
15:36:50 <ihrachys> then the test case goes and creates a child, and does some more checks on the field
15:37:09 <ihrachys> so the initial state of the test case should be an empty synthetic field, and it's apparently not the case
15:37:40 <korzen> I remember working on it some weeks ago
15:38:05 <ihrachys> I also see some irrelevant (reverting?) changes in https://review.openstack.org/#/c/370452/22/neutron/tests/unit/objects/test_base.py
15:38:08 <korzen> but I could not remember in that moment what was the issue here
15:39:28 <ndahiwade> ihrachys: thanks, do I need to tweak the UT to make it pass?
15:39:44 <ihrachys> ndahiwade: I don't think you should change the test case failing
15:39:45 <ndahiwade> or any other approach?
15:39:56 <ihrachys> ndahiwade: but you also touch some other test cases. I don't think that's what you want?..
15:40:35 <ihrachys> and in other files too
15:40:51 <ihrachys> I think there is some issue with the rebase for the patch that you have
15:41:10 <ndahiwade> ihrachys: yes I don't need those...may be it's the rebase..yes
15:41:22 <korzen> from what I remember, the synthetic field can be empty but this UT is not taking it into account. I had to created some special filtering and exception mechanism in UT to make it pass, covering for specific scenario
15:41:46 <ndahiwade> korzen: Do you have a patch I could refer to?
15:41:53 <ihrachys> korzen: ndahiwade: I think it's line 42 in https://review.openstack.org/#/c/370452/22/neutron/tests/unit/objects/test_network.py
15:41:59 <ihrachys> see that you create an agent there
15:42:01 <korzen> unfortunately not :(
15:42:19 <ihrachys> so the initial state of the test case will be - the object having a non-empty field for the agent
15:42:36 <ihrachys> the test case is apparently not ready for that
15:42:51 <ihrachys> netsplit just happened or what?..
15:42:57 <ihrachys> I see folks dropped from the channel
15:43:14 <korzen> maybe
15:43:51 <ndahiwade> ihrachys:should I create the test_agent outside the loop? I have composite primary key...so need to create both
15:44:00 <ihrachys> I think that's a test only issue that ndahiwade sees. it may actually require the test case to be tweaked somehow to allow for existing childen.
15:44:26 <ihrachys> that said, I am not sure exposing the agent as an object field is a good idea itself; we may need to take it to gerrit.
15:44:42 <ihrachys> ndahiwade: yeah, I understand that you need an agent to pass db constraints.
15:44:45 <korzen> ndahiwade, I will take a look tomorrow
15:45:04 <ihrachys> ndahiwade: would it work if you just convert the agent field into a single UUID field agent_id?
15:45:04 <ndahiwade> ihrachys: koraen: Sure Thanks:)
15:45:12 <ndahiwade> *korzen
15:45:41 <ndahiwade> I integration needs a synthetic field
15:45:55 <ndahiwade> It expects the entire object to be loaded
15:47:07 <ihrachys> ndahiwade: where exactly is it?
15:47:30 <ihrachys> oh that query builder in get_dhcp_agents_hosting_networks?
15:47:36 <ihrachys> https://review.openstack.org/#/c/370452/22/neutron/db/agentschedulers_db.py
15:48:19 <ihrachys> anyhoo, we would need to dive into the review on gerrit to have a deep discussion
15:48:30 <ihrachys> thanks for bringing that up!
15:48:38 <ndahiwade> ihrachys: https://github.com/openstack/neutron/blob/master/neutron/db/agentschedulers_db.py#L462-L465
15:49:03 <ihrachys> ack
15:49:22 <ndahiwade> ihrachys: Sure thanks
15:49:30 <ihrachys> #topic Other patches on review
15:49:54 <ihrachys> the spec for no-api-downtime upgrades is still on review: https://review.openstack.org/386685
15:49:59 <korzen> I wanted to bring up the standard attr id
15:50:33 <ihrachys> korzen: let's do in open discussion
15:50:43 <korzen> ok
15:51:10 <ihrachys> folks who have not yet reviewed the spec, please do
15:51:52 <ihrachys> I am not aware of any more upgrades patches that could hit us
15:52:01 <ihrachys> so let's go straight to korzen's stuff
15:52:05 <ihrachys> #topic Open Discussion
15:52:13 <ihrachys> korzen: your floor
15:52:24 <korzen> so I have discussed using the standard-attr-id with someone
15:53:00 <korzen> the case is: in some usage scenarios, we need to access the standard-attr-id
15:53:22 <korzen> but we do not have StandardAttr OVO
15:53:39 <korzen> we use the declarative way of adding the field
15:53:45 <korzen> fields
15:54:08 <ihrachys> we can in theory have a detached (not linked to other objects) OVO for that
15:54:11 <ihrachys> would it work?
15:54:47 <korzen> so the point is: should we add it to standard-attr-id to every resource that is using it?
15:55:06 <korzen> it would require to update the versions of all objects
15:55:21 <korzen> currently it is used for port I guesss
15:55:47 <ihrachys> I don't think. can't we have a detached OVO for that that will receive the ID of the object that it belongs to?
15:56:04 <ihrachys> or you think more of loading it optimally from db_obj?
15:56:39 <ihrachys> we could prolly have a method that would return a StandardAttrObject by extracting it from db_obj
15:56:44 <korzen> Iguess that the detached OVo would be goof
15:56:47 <korzen> good*
15:57:31 <sshank> ihrachys, As an example, https://review.openstack.org/#/c/361303/22/neutron/db/provisioning_blocks.py@174 Ports model has the Standard attr Id but object doesn't. So to have this detached OVO, stand attr OVO is needed?
15:58:10 <korzen> sshank, thanks, that was the case
15:58:58 * electrocucaracha is back
15:59:11 <ihrachys> oh I think I get what you mean. you want to get_objects(standard_attr_id=...)
15:59:24 <ihrachys> it would work I believe if we would pass thru the filter
15:59:46 <ihrachys> or is there anything more?
15:59:58 <korzen> ihrachys, it is rather returning the id
16:00:06 <korzen> not knowing it ahead
16:00:36 <ihrachys> ok, we may need a simple OVO or even just a method returning the ID
16:00:38 <ihrachys> anyhow, we are tight on time, so let's proceed on the gerrit
16:00:44 <ihrachys> thanks everyone for joining!
16:00:45 <korzen> ok
16:00:46 <ihrachys> #endmeeting