15:00:36 <ihrachys> #startmeeting neutron_upgrades
15:00:37 <openstack> Meeting started Mon Sep 26 15:00:36 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:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:40 <openstack> The meeting name has been set to 'neutron_upgrades'
15:00:41 <ihrachys> hi everyone
15:00:42 <korzen> hello
15:00:47 <asingh_> Hello
15:00:50 <electrocucaracha> hi
15:00:52 <sindhu> hi
15:01:04 <sshank> Hello.
15:01:08 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:01:19 <ihrachys> #topic Announcements
15:01:21 <manjeets_> 0/
15:01:42 <ihrachys> nothing particular, master is open for merging more patches, and we started to do it for some that are tracked by the team
15:01:49 <ihrachys> #topic Partial Multinode Grenade
15:02:24 <ihrachys> as korzen pointed out the prev meeting, we may need grenade to switch to newton for old side of master grenade before we can proceed on linuxbridge multinode job
15:02:41 <dasanind_> o/
15:03:08 <ihrachys> I think it's done now that https://review.openstack.org/#/c/375453/ landed
15:03:41 <ihrachys> so now I will pull some strings to have jschwarz to look at that job ;)
15:04:30 <ihrachys> #topic Moving models to neutron/db/models/...
15:04:32 <jschwarz> ihrachys, https://www.youtube.com/watch?v=1zNdw4DaUM8 XD
15:04:51 <manjeets_> ihrachys: l3 models ?
15:05:15 <ihrachys> I was looking at some of those the prev week, there were some issues that did not allow me to land much
15:05:30 <ihrachys> let me list some of issues so that folks are aware
15:05:50 <ihrachys> some models were still using neutron.db.model_base instead of neutron_lib.db.model_base
15:06:14 <ihrachys> some were not following the naming guidelines set in README file under neutron/db/models
15:06:22 <ihrachys> like using plurals instead of singulars
15:06:57 <ihrachys> some were also using very long names for modules. we should attempt to have shorter if possible, especially in code because the code just stretches thru lines and becomes harder to read.
15:07:21 <ihrachys> some broke indentation in some places due to longer model paths.
15:07:33 <ihrachys> those are mostly small bits, but they should get attention nevertheless
15:07:50 <ihrachys> I will get back to those respinned this week, hopefully we'll have more to land
15:08:42 <electrocucaracha> hopefully, asingh_ was discussed last week how she has been dealing with some rebase/merge conflicts
15:09:02 <electrocucaracha> given that those are dependencies for ovo and other patches
15:10:23 <ihrachys> sorry, there was an emergency, was distracted... :)
15:11:06 <ihrachys> I was just opening the topic for the bug and reviewing what I have there
15:11:16 <ihrachys> if you think there is better tactics to do it, tell me
15:11:38 <ihrachys> manjeets_: you mentioned l3 models. you think those are more critical? and they don't have those issues I mentioned?
15:11:54 <manjeets_> they are using neutron.lib
15:12:09 <manjeets_> but only problem is they are very conflictive
15:12:13 <manjeets_> ihrachys:
15:12:28 <ihrachys> manjeets_: so where do I start?
15:12:40 <ihrachys> manjeets_: a solution for conflicts is a thread of patches
15:13:08 <ihrachys> manjeets_: rebased one on top of the other
15:13:42 <amotoki> i think various l3 related model relocation patches depends on l3 model relocation patch.
15:13:52 <manjeets_> right amotoki
15:14:03 <ihrachys> manjeets_: so which one is the first?
15:14:17 <amotoki> https://review.openstack.org/#/c/348562/ ?
15:14:17 <manjeets_> https://review.openstack.org/#/c/348562/
15:15:03 <ihrachys> ok I will check that one right after the meeting
15:16:15 <manjeets_> ok and external networks relocation and ovo also needs some reviews
15:16:38 <ihrachys> a lot of stuff needs reviews. I was hoping that folks will cross check patches so that they are ready to land.
15:17:06 <ihrachys> anyhow, I will take a look at the topic this week once more, plus this l3 patch today.
15:17:30 <ihrachys> we will act on what we'll have in the queue.
15:17:39 <ihrachys> #topic Objects implementation
15:18:04 <ihrachys> we have two patches ready in the queue - ports and networks. ports has one +2, networks has +2/+W and waits for ports one to land.
15:18:24 <ihrachys> I hope I will pull the 2nd +2 from core reviewers this or next day.
15:18:35 <manjeets_> https://review.openstack.org/#/c/353088/
15:18:37 <manjeets_> https://review.openstack.org/#/c/334695/
15:18:37 <ihrachys> it's ridiculous how long it takes to have anyone looking at anything
15:18:52 <manjeets_> https://review.openstack.org/#/c/369744/
15:18:54 * ihrachys ends ranting
15:19:43 <ihrachys> manjeets_: those don't depend on model moves?
15:19:53 <manjeets_> one of them does
15:19:59 <manjeets_> external networks one
15:20:26 <manjeets_> ihrachys: but for dns I did relocation and ovo intro and implementation in single patch
15:20:26 <korzen> I've worked on Subnet OVO adoption patches and spotted a blocker, Detached db_obj is useless for plugin code
15:21:17 <korzen> detaching db_obj is making it impossible for plugin or extension code to reach the values
15:22:23 <ihrachys> korzen: they can reload. or you can work on leaving it attached.
15:22:40 <korzen> ihrachys, how exactly they can reload?
15:23:53 <ihrachys> korzen: they have the model. can't they refetch it?
15:24:17 <korzen> ihrachys, it is even for in-code extend_subnet_dict
15:24:56 <ihrachys> korzen: I suspect a better approach may be actually leaving it attached, but then, you have the problem of stale data captured by the object
15:25:27 <korzen> ihrachys, yes, I should take a look where the stale data is a problem
15:26:02 <ihrachys> korzen: that's the issue I haven't managed to solve. if you manage, then fine, I am happy to review. :)
15:26:10 <korzen> ihrachys, :)
15:26:35 <korzen> ok I will spend
15:26:48 <korzen> some time on it this week and get to you next week
15:27:01 <manjeets_> korzen: do you have some patch up which is facing this issue ?
15:27:16 <korzen> manjeets_, I have 2
15:27:48 <korzen> manjeets_, https://review.openstack.org/#/c/351740/
15:28:15 <korzen> manjeets_, and https://review.openstack.org/#/c/321001/
15:28:57 * manjeets_ bookmarks them for review
15:28:59 <korzen> the latter is passing
15:29:33 <korzen> because I have hacked it adding lazy='joined'
15:29:49 <korzen> but this hack is not working for the former one
15:31:37 <electrocucaracha> korzen: I did the same for Routers
15:31:40 <ihrachys> ok, thanks for looking at it korzen. I hope you will manage to do something with it. detachment is not a must if we can live without it.
15:32:23 <ihrachys> it's more of a hack-around sqlalchemy behaviour
15:33:57 <korzen> electrocucaracha, you wanted to discuss the readme for OVO?
15:34:27 <korzen> the naming conventions and putting the object in one file
15:34:29 <electrocucaracha> korzen: that's true, ankur-gupta-f created that patch
15:35:15 <ankur-gupta-f> electrocucaracha: sorry wasn't paying attention. Which one?
15:35:18 <electrocucaracha> but at the end the discussion about how to naming things and folders is still opne
15:35:29 <ankur-gupta-f> https://review.openstack.org/#/c/352577/
15:35:30 <ankur-gupta-f> ah
15:35:34 <ankur-gupta-f> ^^^
15:35:53 <electrocucaracha> yeah, that one
15:36:32 <manjeets_> are we really following the dir tree example in that patch
15:36:41 <ankur-gupta-f> manjeets_: we aren't at all
15:36:45 <ankur-gupta-f> so it needs to be reworked
15:36:47 <ihrachys> I don't see why we should follow what's proposed there.
15:36:59 <manjeets_> me neither
15:37:00 <korzen> currently we are doing it opposite, place all related OVOs in one file
15:37:13 <ihrachys> I believe the path chosen and acted on for models will work for OVOs too
15:37:23 <ihrachys> no extensions/ needed, you keep related objects in same file
15:37:23 <manjeets_> ihrachys: +1
15:37:40 <ihrachys> subnet.py is for network plus all related things like dhcp extra options
15:37:42 <korzen> I'm also +1
15:38:08 <electrocucaracha> +1
15:38:09 <ankur-gupta-f> yea. last time that patch was done was august 10th. will rework based on what is being done
15:38:16 <ihrachys> ok cool, let's respin that patch to reflect that
15:38:21 <ihrachys> ankur-gupta-f: thanks
15:38:29 <ankur-gupta-f> np. Should I add anything else?
15:38:39 <ankur-gupta-f> maybe add ref to the NeutronDbObjects patch of yours
15:38:40 <korzen> plugins?
15:38:41 <korzen> ml2
15:38:47 <ihrachys> nah as long as it covers the approach. you can take inspiration from models/README
15:39:03 <ankur-gupta-f> kk golden
15:39:31 <korzen> ok, in db/models we also havep plugins
15:39:35 <korzen> so it is ok
15:40:34 <ihrachys> ok cool. on ovo, I believe it's a matter of review time to make progress.
15:40:53 <korzen> talking about object patches, I have added validate_filters for count()
15:41:05 <korzen> ○ https://review.openstack.org/376430
15:41:25 <korzen> because is required for Subnet integration patch
15:41:43 <ihrachys> ok, just wanted to ask about where the need came from :)
15:42:04 <ihrachys> though it's valid nevertheless because count() is supposed to be similar to get_objects() api wise
15:42:12 <korzen> it is in subnet API where you can pass some not valid filter
15:42:22 <korzen> ihrachys, yes, exactly
15:43:19 <ihrachys> ok let's move on
15:43:23 <ihrachys> #topic Other patches on review
15:43:39 <manjeets_> korzen: mind if I take subnetroute patch ?
15:43:48 <korzen> manjeets_, no problem
15:43:48 <ihrachys> I don't have anything specific in my queue, it's either OVO or release related for me. if you folks have something, please raise.
15:44:51 <korzen> I'm good
15:45:06 <manjeets_> ihrachys: I have which is for adding tables in neutron db
15:45:06 <ihrachys> ok cool
15:45:13 <ihrachys> manjeets_: link?
15:45:25 <manjeets_> not a patch just design consideration
15:45:46 <manjeets_> I looked at tables manually querying neutron db
15:46:15 <manjeets_> some tables just have two fields of redundant data which could have been easily accomodated in parent
15:46:40 <ihrachys> manjeets_: right. they usually belong to an extension.
15:47:02 <ihrachys> manjeets_: some people felt like untangling extension data from base model is somehow better.
15:47:15 <ihrachys> even though it's loaded nevertheless thru relationships :)
15:47:23 <ihrachys> and plus adds complexity to queries
15:47:38 <ihrachys> ideally, there would be some effort to simplify schema
15:47:38 <sshank> regarding join, if joins are on 2 objects, should the fields in those objects be used to create new a joined object?
15:47:43 <manjeets_> query complexity is concern
15:48:08 <sshank> How to take care of joins was my question.
15:49:03 <manjeets_> based on my review after looking at database we should also think caching layer on neutron db but that's just an idea to save time on db transactions
15:50:09 <ihrachys> sshank: f.e. see port security attached to ports, I expose it as a synthetic field on ports object
15:50:24 <ihrachys> sshank: so when you load port, you get a field for port_security on it
15:51:27 <ihrachys> I believe for objects, we should think more about usage patterns and API clarity than mapping to particular schema presentation. the fact that some logical fields are detached from a resource and are put in a separate tables does not necessarily justify it being untangled on objects level.
15:52:11 <ihrachys> #topic Open discussion
15:52:17 <ihrachys> I have one, that's for korzen
15:52:28 <ihrachys> I was looking at logs for multinode grenade jobs lately
15:52:38 <ihrachys> and noticed that there is q-agt in new side of the cloud
15:52:44 <ihrachys> see f.e. http://logs.openstack.org/32/376332/4/check/gate-grenade-dsvm-neutron-multinode/efd591d/logs/new/
15:52:57 <ihrachys> korzen: does it suggest we broke the job somewhere on the path?
15:53:27 <korzen> ihrachys, why?
15:53:45 <ihrachys> well I was thinking, the agent will run from old cloud side, with no restart?
15:54:17 <korzen> q-agt should be in the controller node with new version and in the compute running old version
15:54:37 <ihrachys> pfff
15:54:43 <korzen> we have 2 compute nodes, one of them in on controller node
15:54:47 <ihrachys> I guess I forgot everything about the job :P
15:54:50 <korzen> :)
15:54:52 <ihrachys> right you are
15:54:55 <ihrachys> now I grasp
15:55:06 <ihrachys> we have q-agt on new side for l3
15:55:09 <ihrachys> and dhcp
15:55:21 <ihrachys> ok, mistery cleared for me :)
15:55:31 <korzen> no problem
15:55:33 <korzen> :)
15:55:37 <dasanind_> ihrachys: for vxlanallocation and vxlanendpoints there are interfaces that are being used outside of neutron tree. On discussion with blogan he suggested to add new interfaces for OVO. I have put up a patch with that approach https://review.openstack.org/367810.  My question is: Is there any other way to do this?
15:56:28 <ihrachys> dasanind_: what's that? I don't follow. why do you need OVO for a regular class?
15:57:33 <dasanind_> ihrachys: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/type_vxlan.py#L72
15:58:18 <ihrachys> dasanind: ok, and what's the concern there? why can't you just switch the code to objects?
15:58:23 <ihrachys> without new classes and all?
15:58:34 <ihrachys> is that because you pass model classes into __init__?
15:58:40 <dasanind_> ihrachys: there is 3 level inheritance
15:59:30 <ihrachys> is that because of no context argument?
15:59:38 <dasanind_> ihrachys: yes
15:59:54 <ihrachys> I was thinking we can do it without alternative implementation
16:00:16 <ihrachys> I will need to have a look.
16:00:23 <ihrachys> having two interfaces for the same thing is not nice.
16:00:27 <ihrachys> ok time's up
16:00:30 <ihrachys> thanks everyone
16:00:31 <manjeets_> time uo
16:00:32 <ihrachys> #endmeeting