15:00:37 <ihrachys> #startmeeting neutron_upgrades
15:00:38 <openstack> Meeting started Mon Dec 12 15:00:37 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:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:40 <ihrachys> o/ everyone
15:00:41 <openstack> The meeting name has been set to 'neutron_upgrades'
15:00:42 <electrocucaracha> howdy
15:00:44 <korzen> hello
15:00:46 <sshank> Hi
15:00:51 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:00:52 <sindhu> Hi
15:00:54 <dasanind_> hi
15:01:30 <ihrachys> btw folks it would be nice if whenever you have a question for the team, you update the agenda page ^ so that we can prepare for potential discussion
15:01:40 <ihrachys> #topic Announcements
15:01:54 <ihrachys> Ocata-2 is happening this week
15:02:10 <ihrachys> PTG registration is ongoing
15:02:39 <ihrachys> nothing else of interest that I know
15:02:42 <ihrachys> #topic Partial Multinode Grenade
15:03:00 <ihrachys> there was some progress made I believe
15:03:25 <ihrachys> the jschwarz's devstack patch that broke the gate was reverted, but then Armando re-proposed it with the issue fixed
15:03:41 <ihrachys> #link https://review.openstack.org/#/q/I292ff0dc080fb84b5f879ba2f00f03eff295b55b,n,z
15:04:15 <ihrachys> that now landed into newton and ocata, so it should be enough to make next steps
15:04:45 <korzen> any update on how to test zero-downtime in gate?
15:05:03 <ihrachys> that being said, we still see 3 tempest tests failing as in http://logs.openstack.org/59/396659/3/experimental/gate-grenade-dsvm-neutron-linuxbridge-multinode-ubuntu-xenial-nv/684b940/logs/grenade.sh.txt.gz#_2016-12-09_10_11_59_314
15:05:44 <ihrachys> korzen: no, that was on my plate, but then I was (obviously) distracted by some local weekly event. I should get back to it this week.
15:06:05 <korzen> ok
15:06:19 <ihrachys> jschwarz: do you have capacity to help with debugging those 3 tempest failures in partial grenade linuxbridge job?
15:06:39 <jschwarz> ihrachys, not currently, sorry :<
15:06:44 <manjeets> o/
15:07:20 <ihrachys> ok. I will need to check if it's some MTU issue again, we had something similar before for ovs job.
15:08:03 <ihrachys> maybe I should try with I53c0eb57da956b36f09731d25db989719e9bc9dc that reverts an MTU hack inside linuxbridge agent
15:08:39 <ihrachys> ok, updated the testing patch to include it https://review.openstack.org/#/c/396659/ and triggered experimental.
15:08:43 <ihrachys> we'll see how it goes
15:09:27 <ihrachys> korzen: since you've asked, do you have capacity to take over that task from me? :)
15:09:43 <ihrachys> I mean, the no-downtime gating testing investigation
15:09:56 <korzen> ihrachys, I can aks around this week
15:10:01 <korzen> ask*
15:10:47 <ihrachys> ok, if I get to it in time, I will update you, and vice versa.
15:10:53 <korzen> ye
15:11:08 <ihrachys> #topic Object implementation
15:11:19 <ihrachys> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db
15:11:36 <ihrachys> we have some patches that I believe are ready to go: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db+label:Code-Review%252B2
15:11:39 <electrocucaracha> ihrachys: I made a exhaustive check on the spreadsheet
15:12:21 <ihrachys> electrocucaracha: link to the sheet?
15:12:27 <electrocucaracha> #link https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XEWBdFVPMB8/edit#gid=1434170112
15:13:06 <electrocucaracha> ihrachys: we included a columns for lever of confidence and tentative release target
15:13:51 <electrocucaracha> hopefully, that helps to get an idea of the patches that are almost ready
15:13:57 <ihrachys> that's enormous tracking effort I admit, thanks for doing that
15:14:12 <electrocucaracha> any time
15:15:17 <korzen> hmm we are now at ocata-2
15:15:31 <korzen> and the progress is not so advanced
15:15:40 <korzen> when is ocata-3?
15:16:15 <ihrachys> end of Jan
15:16:15 <ihrachys> https://releases.openstack.org/ocata/schedule.html#o-3
15:16:25 <ihrachys> so we have roughly a month
15:17:11 <korzen> well, until some resource is not changed, the OVO does not impact zero-downtime
15:17:34 <ihrachys> yeah, the only thing we absolutely must deliver is port binding since it's needed for live migration rework
15:17:47 <korzen> so the priority should have the port binding
15:17:58 <ihrachys> I see it's sched to Pike in the doc. electrocucaracha, any reason for that?
15:18:10 <korzen> #link https://review.openstack.org/#/c/407868/
15:18:31 <electrocucaracha> not really, It's because I haven't seen progress on that
15:18:46 <electrocucaracha> but it's just my limited perception
15:19:11 <ihrachys> I see. we may actually need to bump it in priority.
15:19:57 <korzen> #link https://review.openstack.org/#/c/404293/ Port Binding extension with PK and 'status' field
15:20:12 <korzen> so the links are very important
15:20:29 <ihrachys> korzen: thanks for sharing the latter, I was not aware
15:20:49 <korzen> np
15:21:32 <korzen> returning to zero-downtime testing, is some working on setting it up for manual tests?
15:22:13 <korzen> it would be nice to see how the port binding is influencing the zero-downtime
15:22:23 <korzen> before we have gate
15:23:23 <korzen> I guess that no...
15:23:25 <korzen> :(
15:23:45 <ihrachys> I guess so
15:24:17 <ihrachys> do I hear someone volunteering? :)
15:25:10 <korzen> ihrachys, if you mean me, then not this month :P
15:25:34 <manjeets> when you said port binding is influencing 0 downtime ? which way can you explain bit more
15:25:37 <manjeets> korzen,
15:25:49 <ihrachys> haha. gotcha. I would start with checking with infra on setting the gate; and if we are not close to it, then consider falling back to manual.
15:25:51 <manjeets> you mean with or without ovo ?
15:26:09 <ihrachys> manjeets: there are changes in the pipeline to modify port binding resource
15:26:20 <ihrachys> adding a new status field, and expanding primary key
15:26:28 <korzen> manjeets, the OVO is a requirement
15:26:39 <ihrachys> we will need OVO object for it in and integrated to make it work flawlessly
15:26:49 <manjeets> ok got it
15:26:53 <manjeets> thanks
15:28:07 <korzen> from other news, I have restored my subnet integration patch and need to check how to overcome the db_obj detached
15:28:29 <electrocucaracha> that is for improving live migration effort right?
15:28:31 <ihrachys> korzen: I see you talked to ataraday in another channel on the matter. any brief conclusions?
15:28:42 <ihrachys> electrocucaracha: yes, port binding work is for live migration
15:29:20 <korzen> so the db_obj needs to be added to working session before any extension is going to use the extra relationships defined in DB
15:29:45 <korzen> this is also problematic when transition to new enginefacade
15:30:46 <ihrachys> korzen: meaning that we will need to have the db_obj not detached?
15:30:50 <korzen> the solution I'm thinking is to create new session and add db_obj to it before calling _apply_dict_extend_functions
15:31:09 <korzen> for starter, it seems like a workaround
15:31:37 <korzen> I'm not sure if we can drop the detaching
15:32:10 <ihrachys> yeah, there were some issues with it I believe. like session caching values between fetches, or something.
15:32:33 <korzen> yes, so for started I would not go into removing the detaching
15:32:51 <ihrachys> ack. ok, let's see what you will craft. :)
15:32:53 <korzen> unless ataray or kevinbenton would make something smarter
15:33:03 <ihrachys> I assume as long as it's good with Anna, it's good with me :)
15:33:18 * ihrachys loves to be lazy
15:33:22 <korzen> :)
15:33:53 <sshank> ihrachys, Any leads on the segment_id issue in port binding level patch? Should we add it to pass tests?
15:34:50 <ihrachys> sshank: yeah, I need to look at that, haven't done it yet. I will do it asap. I hope we will be able to overcome it without duplicating the field, but I need to play with it.
15:35:21 <ihrachys> btw on related news, I will join the late neutron meeting today to update the broader team about our progress and will raise some patches that should be ready to go there.
15:35:31 <ihrachys> hopefully it will help get them in the queue :)
15:35:53 <ihrachys> ok let's move on to the next topic which is ...
15:35:54 <ihrachys> #topic Other patches on review
15:35:56 <korzen> ihrachys, I have updated a little last week
15:36:02 <korzen> on tuesday's meeting
15:36:02 <ihrachys> korzen: thanks!
15:36:41 <electrocucaracha> well, I'm a little lost about some comments for Router OVO
15:37:05 <ihrachys> there is a policy proposal that expands the list of cases where UpgradeImpact tag is to be used: https://review.openstack.org/#/c/402004/
15:37:50 <ihrachys> electrocucaracha: the latest PS or PS30?
15:38:47 <electrocucaracha> ihrachys: I don't remember the PS but it was your comment about how to address attached_ports
15:38:54 <electrocucaracha> https://review.openstack.org/#/c/307964/34/neutron/objects/router.py@139
15:39:20 <manjeets> I am having a issue in implementing port_ovo https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_db.py#L645
15:40:06 <electrocucaracha> PS30
15:40:13 <manjeets> I changed port_db.security_groups to port_db.security_group_ids which is a coerced set of ids
15:41:00 <manjeets> list() or set() seems like not working on that
15:41:14 <ihrachys> electrocucaracha: I think korzen had a comment there that may have helped you?
15:41:28 <ihrachys> in PS30
15:41:31 <ihrachys> "You were missing router_id=self.id in reload_attached_ports() ..."
15:42:28 <electrocucaracha> mmm ok maybe I didn't see it, sorry korzen
15:42:47 <ihrachys> manjeets: can't you extract the IDs from security-group objects?
15:42:58 <korzen> electrocucaracha, np, I also forget what I have reviewed
15:43:11 <ihrachys> korzen: :) true story
15:44:00 <manjeets> I guess I can i'll try ihrachys
15:44:52 <ihrachys> in related news, no-downtime spec/write-up seems to be ready to land: https://review.openstack.org/#/c/386685/
15:45:00 <ihrachys> we have +2 from armax, and more +1s
15:46:12 <manjeets> yes ihrachys do we have patch up for forbiding contract migrations in code as well ?
15:46:12 <ihrachys> ok seems rather calm, let's move on
15:46:22 <ihrachys> manjeets: we have a functional test
15:46:26 <ihrachys> manjeets: is it not enough?
15:46:39 <manjeets> it is enough
15:46:50 <ihrachys> yeah, so it was landed some time ago
15:46:51 <manjeets> i would be I belive
15:47:08 <ihrachys> https://review.openstack.org/#/c/400239/
15:47:19 <ihrachys> that's the contract forbidding patch
15:47:24 <manjeets> thanks
15:47:24 <ihrachys> ok
15:47:30 <ihrachys> #topic Open discussion
15:47:50 <korzen> https://review.openstack.org/#/c/400412/ one word about that patch
15:47:50 <ihrachys> we have nothing on the wiki page in the section
15:48:11 <ihrachys> I suggest to fill it in for next times, so that we know that there is a topic to discuss
15:48:14 <ihrachys> korzen: looking
15:48:28 <korzen> when someone will try to create object passing stardard_attr_id, the object creating will fail
15:48:49 <korzen> this was why UTs in QoS were failing
15:49:14 <ihrachys> which makes sense since the object does not have such field
15:49:28 <ihrachys> correct?
15:49:38 <korzen> true
15:49:53 <electrocucaracha> fyi: ndahiwade has reported a bug in oslo.versioned-objects  https://review.openstack.org/#/c/408739/
15:50:01 <korzen> is it allowed to implicitly set the standard_attr-id?
15:50:21 <korzen> it is rather created while object creation
15:50:52 <ihrachys> korzen: right. I wouldn't think it's to support.
15:52:07 <ihrachys> electrocucaracha: looking
15:52:23 <ndahiwade> https://review.openstack.org/#/c/370452/ This is the patch where the problem was encountered.
15:53:05 <ndahiwade> https://review.openstack.org/#/c/370452/32/neutron/objects/common_types.py, Temporary solution for neutron until it is accepted in Oslo
15:54:10 <ihrachys> not sure I follow. why should oslo.versionedobjects dict-of-strings type access non-strings for values?
15:55:04 <electrocucaracha> apparently the configurations field is not accepting dict as valid type
15:55:14 <ihrachys> seems like instead we may need to define a new type that would allow any values
15:55:28 <ndahiwade> http://paste.openstack.org/show/592124/
15:55:42 <ihrachys> electrocucaracha: it's not configurations field issue, but the fact that in your dict, one of key values is not a string but another dict
15:55:46 <ihrachys> that's bridge_mappings
15:55:55 <ihrachys> so you have two levels of dicts
15:56:06 <ihrachys> while the type from the library is for a single layer dict
15:56:37 <ndahiwade> http://paste.openstack.org/show/591831/
15:56:58 <ndahiwade> ihrachys^^ this is the error for list type not accepted
15:57:23 * electrocucaracha doesn't want to be the bad of the movie, but we have less than 3 minutes
15:57:57 <ihrachys> ndahiwade: right, that's because your tunnel_types key has a list value while type allows for strings only
15:58:06 <ihrachys> we need to define new less-strict type I believe
15:58:22 <ihrachys> so I probably agree with the direction for the neutron patch but I don't believe it's oslo issue.
15:58:34 <ihrachys> maybe we just use wrong type
15:59:06 <manjeets> 1
15:59:10 <ndahiwade> ihrachys: Okay,thanks
15:59:22 <ihrachys> manjeets: plus or minus? :)
15:59:34 <manjeets> 1 minute left ....lol
15:59:40 <ihrachys> ok :)
15:59:45 <ihrachys> thanks guys!
15:59:48 <ihrachys> #endmeeting