15:00:52 <ihrachys> #startmeeting neutron_upgrades
15:00:53 <openstack> Meeting started Mon Nov 21 15:00:52 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:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:56 <ihrachys> o/
15:00:56 <openstack> The meeting name has been set to 'neutron_upgrades'
15:01:00 <electrocucaracha> o/
15:01:01 <korzen> hello
15:01:05 <sshank> Hello
15:01:05 <asingh_> Hello
15:01:09 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:01:15 <sindhu> hi
15:01:21 <trinaths> hi
15:01:39 <ihrachys> #topic Announcements
15:02:04 <ihrachys> first, Ocata-1 is released. I don't believe it influences us in any way except showing that time is running out :)
15:02:29 <manjeets> o/
15:02:30 <ihrachys> second, PTG (formerly design summit) is open for registration
15:02:31 <korzen> we hare 4 weeks left till Ocata-2
15:02:36 <korzen> have*
15:02:39 <ihrachys> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106995.html Info on how to register for PTG
15:02:59 <ihrachys> for the record, neutron sessions are Wed-Fri
15:03:40 <ihrachys> finally, switch to Xenial is still ongoing. I believe we switched all grenade jobs in Newton+ to Xenial without a hassle.
15:04:25 <ihrachys> #topic Partial Multinode Grenade
15:04:46 <ihrachys> the previous meeting, I reported that we have made some progress for linuxbridge multinode grenade job
15:05:03 <ihrachys> since then, https://review.openstack.org/#/c/396658/ landed
15:05:22 <ihrachys> and jschwarz looked at the last test failure in the job and actually came up with a devstack side fix for that
15:05:45 <ihrachys> #link https://review.openstack.org/#/c/400258/ Fix for linuxbridge grenade multinode
15:06:09 <ihrachys> I haven't reviewed it yet, but we already triggered experimental job in https://review.openstack.org/#/c/396659/
15:06:23 <ihrachys> since infra is quite loaded right now, it will take some time to get results
15:06:24 * jschwarz finally helped out with the linuxbridge job!
15:06:31 <ihrachys> jschwarz: I hope you did! ;)
15:06:36 <ihrachys> jschwarz: thanks
15:07:28 <ihrachys> if it indeed fixes the issue, we will proceed with moving it into check queue and making it voting
15:08:35 <ihrachys> one thing before it happens, we will need to switch the job to Xenial too
15:09:00 <ihrachys> but I hope it should work fine as it did for other grenade jobs
15:09:53 <ihrachys> after that, gate jobs seem like done, if not for the planned job for mixed neutron-server versions
15:10:07 <manjeets> ihrachys, question what is difference b/w running trusty vs xenial is that just the distro ?
15:10:17 <ihrachys> we will need someone to start looking at what infra has to offer for us to bake such a job
15:10:26 <ihrachys> manjeets: yes it's ubuntu version
15:10:39 * electrocucaracha systemd?
15:10:48 <ihrachys> manjeets: since it bumps kernel and other platform pieces it may sometimes break a thing or two
15:11:01 <manjeets> ok
15:11:01 <ihrachys> we saw functional jobs broken seriously because of the switch
15:11:11 <manjeets> thanks
15:11:11 <ihrachys> but grenade is probably less involving on platform side
15:11:39 <ihrachys> electrocucaracha: I believe yes, it's systemd now
15:11:53 <ihrachys> electrocucaracha: but since we don't really use it to start services in gate, it should not matter?
15:12:49 <electrocucaracha> ihrachys: yeah, more likely the thing that could affect us it's the third party libraries
15:13:05 <electrocucaracha> ihrachys: but I think that you've identified most of the issues
15:14:22 <ihrachys> ok. so we have that mixed neutron-server job task in the queue
15:14:39 <ihrachys> anyone willing to go to infra and other projects to talk about how to achieve that?
15:15:14 <ihrachys> (the job where neutron-server would run on both old and new sides of grenade, and where API requests would be routed via some loadbalancer like haproxy
15:15:55 <electrocucaracha> I don't have an idea how, but I can try it
15:16:21 <ihrachys> electrocucaracha: ok let's sync on it after the meeting
15:16:37 <ihrachys> #topic Object implementation
15:16:44 <ihrachys> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db
15:16:49 <ihrachys> we haven't landed much this week
15:17:11 <ihrachys> but one piece that landed is https://review.openstack.org/#/c/297887/
15:17:14 <ihrachys> that's Agent object
15:17:24 <ihrachys> it's not integrated though
15:17:52 <manjeets> is port object ready to be integrated ?
15:17:59 <electrocucaracha> ihrachys: there are three patches that are blocking other patches and contains many OVO objects
15:18:32 <electrocucaracha> manjeets: I think that korzen mentioned that he couldn't work on the integration
15:18:44 <manjeets> i was looking at code, if it is ready we can integrate port in pieces
15:18:45 <korzen> port? not
15:18:55 <manjeets> korzen, yea port
15:19:03 <ihrachys> manjeets: I believe integration will reveal issues, but it would be nice to start landing integration, maybe in pieces
15:19:44 <korzen> I will be working opn network OVO usage in code
15:19:55 <korzen> s/opn/on
15:20:02 <korzen> and subnet
15:20:29 <korzen> we should also aware of push notification when talking about port/subnet/network
15:20:59 <electrocucaracha> ihrachys: do you mind to take a look of these patches? https://review.openstack.org/#/c/396327/ https://review.openstack.org/#/c/338625/ https://review.openstack.org/#/c/360799/
15:21:16 <ihrachys> right. there is a WIP patch from kevinbenton with some server side integration for object changes: https://review.openstack.org/#/c/388939/10
15:21:54 <ihrachys> electrocucaracha: do any of those have integration ready?
15:23:22 <electrocucaracha> the first one dasanind is working on that but given that impacts those four objects it requires to check it
15:23:53 <electrocucaracha> for quotes, I'm still dealing with the integration, maybe I have something for today, but it's too close
15:24:40 <electrocucaracha> and for IPAM ndahiwade it's working on the integration, I think that they have it but in different patches
15:25:04 <electrocucaracha> I'm sure that we can squash them
15:25:43 <ihrachys> electrocucaracha: yeah. I understand why we want to split larger objects, but not sure if it's worth having them split for smaller pieces.
15:26:58 <electrocucaracha> actually the first patch, Allocation and Endpoint originally was three different patches
15:27:26 <electrocucaracha> but yes, we can reduce the amount of patches and have better control
15:27:42 <ihrachys> that would be awesome
15:28:17 <ihrachys> are we in agreement we attempt to get integration for at least smaller objects before considering landing them?
15:28:34 <electrocucaracha> +1
15:28:44 <manjeets> +1
15:29:21 <ihrachys> cool, thanks for bearing with me ;)
15:29:54 <ihrachys> I think we can safely move to the next topic, but I give 30 secs to raise anything else that is critical
15:30:13 <electrocucaracha> router ovo patch?
15:30:56 <ihrachys> electrocucaracha: ok. I saw you had some issue with doing lazy loading in qospolicy like way
15:31:14 <ihrachys> I believe korzen gave some relevant suggestion there
15:31:20 <sindhu> all the patches that have issues with having session instead of context, it should depend on https://review.openstack.org/#/c/398873
15:32:06 <ihrachys> ouch. I see ml2 driver api changing
15:32:20 <electrocucaracha> and what about the way that the test framework generates uuid for non required uuidfields
15:33:16 <ihrachys> electrocucaracha: ok. maybe we should set it to None in setUp
15:33:35 <ihrachys> electrocucaracha: an alternative could be allowing to define a set of fields to disable generator for
15:33:49 <ihrachys> that could be a list defined on the test class.
15:34:21 <ihrachys> one more idea is maybe not generating anything for UUID fields?
15:34:33 <ihrachys> those random values will not ever be valid anyhow
15:34:53 <ihrachys> if a test needs to link the object to some other table, the test case will need to set the field anyway.
15:35:56 <ihrachys> ok let's move on
15:36:01 <ihrachys> #topic Other patches for review
15:36:12 <ihrachys> electrocucaracha: btw I will leave the comments above in the patch later
15:36:29 <ihrachys> for blueprint online-upgrades, we currently have a list of patches
15:36:40 <manjeets> i am having a weird issue with this patch https://review.openstack.org/#/c/353088/
15:36:46 <ihrachys> one is a spec that I plan to get back this week https://review.openstack.org/386685
15:37:10 <manjeets> test only fails if I run all the unit tests together
15:37:11 <ihrachys> and another is a patch that forbids contract migration scripts for Ocata: https://review.openstack.org/400239
15:38:10 <manjeets> if run that alone or all on tests on that test file it works
15:38:11 <ihrachys> manjeets: I am not even sure it's related to OVO work
15:38:11 <manjeets> http://logs.openstack.org/88/353088/28/check/gate-neutron-python27-ubuntu-xenial/d19c2a8/console.html.gz#_2016-11-17_23_53_34_484014
15:38:23 <manjeets> its an ovo patch
15:38:34 <ihrachys> manjeets: please report a bug and add 'unit-test' and 'gate-failure' to bug tags.
15:38:41 <ihrachys> manjeets: yeah but it doesn't mean it fails there only
15:38:52 <ihrachys> manjeets: maybe check logstash to see if it shows up in any other patches
15:39:07 <manjeets> ok
15:40:00 <ihrachys> manjeets: ping me if you need help with logstash
15:40:17 <manjeets> sure thanks ihrachys
15:40:40 <ihrachys> ok any more patches for the team to review?
15:40:51 <ihrachys> except OVO and what was already mentioned
15:41:25 <ihrachys> ok let's move on
15:41:30 <ihrachys> #topic Open discussion
15:41:51 <ihrachys> just an update: on the last meeting, I said that the grenade failure https://bugs.launchpad.net/neutron/+bug/1611237 is going away with Xenial switch
15:41:51 <openstack> Launchpad bug 1611237 in neutron "Restart neutron-openvswitch-agent get ERROR "Switch connection timeout"" [High,Confirmed]
15:41:59 <ihrachys> seems like it does not, I hit it on a xenial job
15:42:07 <ihrachys> so we will need to have another look at it
15:42:27 <ihrachys> I think it's clear what happens there (ryu not killed on SIGTERM)
15:42:38 <ihrachys> but there is no patch to review, or even an idea why it happens
15:42:46 <ihrachys> if you feel brave, have a look
15:42:55 <ihrachys> anything more you folks wanted to raise?
15:43:25 <electrocucaracha> ihrachys: well my only concern is about the progress that we have merging ovo
15:43:53 <electrocucaracha> ihrachys: is there anything that we can do to accelerate it?
15:45:24 <ihrachys> electrocucaracha: we obviously need core reviewers on those patches. we now advertise patches on weekly meetings. one thing that I find not ideal is that sometimes I need to comment on well known issues in patches, so I can't +2 a patch right away. it could probably help if other folks cross-review patches to kill those nits before those with +2 jump on patches.
15:45:52 <ihrachys> in the end, it's all about core reviewers not giving enough votes.
15:46:48 <korzen> ihrachys, do you have any common mistakes that are repeating between patches?
15:46:50 <electrocucaracha> ok, I think that we can cover the well know issues part
15:47:00 <ihrachys> korzen: like project_id being UUID
15:47:10 <ihrachys> korzen: no unit tests for an object
15:47:24 <ihrachys> korzen: no integration?
15:47:34 <ihrachys> (sometimes it's justified)
15:47:53 <ihrachys> korzen: missing nullable= argument where needed
15:49:00 <korzen> ok, thanks
15:49:53 <ihrachys> as for core attention, we all feel the whirlpools in the community
15:50:06 <ihrachys> some key people were moved from OpenStack
15:50:19 <ihrachys> it makes current core reviewers more loaded
15:50:44 <ihrachys> we will probably need to expand the core team to accommodate, but that's not up to me to make it happen
15:51:09 <electrocucaracha> ihrachys: maybe we have to raise this issue to armax
15:51:23 <ihrachys> electrocucaracha: I believe armax has open door policy ;)
15:52:18 <electrocucaracha> ihrachys: we can mention it in tomorrow's neutron meeting
15:52:35 <ihrachys> electrocucaracha: there is no armax on those meetings, if that's your goal
15:52:52 <ihrachys> I believe anyone can talk to armax on the matter
15:53:00 <ihrachys> *anyone concerned
15:53:26 <ihrachys> ok anything more on anyone's mind?
15:53:35 <sshank> ihrachys, korzen I was planning on adding a class method get_standard_attributes(cls) after here: https://github.com/openstack/neutron/blob/master/neutron/objects/base.py#L316 to get access to standard attribute. Is it advised?
15:54:15 <korzen> what do you mean by 'standard attributes'?
15:54:19 <korzen> all of them?
15:54:33 <ihrachys> I think we needed just ID?
15:54:41 <korzen> it should be just ID
15:54:48 <sshank> korzen, to return 'standard_attr.HasStandardAttributes'
15:55:43 <ihrachys> sshank: what else do we need from the model except id?
15:57:18 <korzen> in my understanding, we should have new property in DeclarativeObject returing standard_attr_id
15:57:20 <korzen> that is all
15:57:31 * asingh_ ihrachys https://github.com/openstack/neutron/blob/master/neutron/db/tag_db.py#L30-L92
15:57:33 <ihrachys> sshank: as for the direction, I believe you will need to expose the ID only on objects that are linked to standard attributes table. there is some relevant code in https://github.com/openstack/neutron/blob/master/neutron/objects/base.py#L252 that you can use as a clue
15:57:43 <korzen> smth like here: https://github.com/openstack/neutron/blob/master/neutron/objects/base.py#L219
15:58:38 <korzen> the new attribute can be called standard_attr_id to be backward compatible
15:59:07 <ihrachys> asingh_: aha. can't we implement the filters inside base.py? just pass the info on the needed tags into obj_db_api and handle it there?
16:00:06 <ihrachys> anyhow, we need to wrap up
16:00:14 <ihrachys> thanks folks for joining, we will continue in gerrit
16:00:26 <ihrachys> asingh_: maybe just post a "strawman" patch and we will go from there
16:00:29 <ihrachys> #endmeeting