15:01:21 <korzen> #startmeeting neutron_upgrades
15:01:22 <openstack> Meeting started Mon Aug  1 15:01:21 2016 UTC and is due to finish in 60 minutes.  The chair is korzen. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:26 <korzen> Hello all
15:01:26 <openstack> The meeting name has been set to 'neutron_upgrades'
15:01:33 <korzen> rossella_s: jlibosva: sc68cal: electrocucaracha:
15:01:40 <korzen> ankur-gupta-f,
15:01:52 <ankur-gupta-f> hello
15:01:53 <rossella_s> hi there
15:01:54 * electrocucaracha waves back
15:02:11 <korzen> I see there is plenty of us
15:02:24 <korzen> Ihar is OOO today
15:02:53 <korzen> I'm not sure if he is out for today or this week
15:03:23 <korzen> let start with agenda
15:03:29 <korzen> #topic Announcements
15:03:43 <korzen> Upgrades and objects are priority work items for upcoming neutron midcycle
15:03:58 <korzen> #link https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems
15:04:53 <korzen> hope we will have good discussions there
15:05:17 <electrocucaracha> korzen: do you need that we update the line 28"
15:05:33 <electrocucaracha> korzen: with the objects that we're working on
15:05:56 <korzen> yea, I guess we can add all reviews
15:06:07 <korzen> that we think are important
15:06:32 <korzen> P1 stays the same, port, subnet and maybe network
15:07:20 <korzen> we will see in about 2 weeks
15:07:28 <korzen> waht is the general progress
15:07:48 <korzen> some of the items on the list is last week Ihar and I had good conversation with kevinbenton
15:08:08 <korzen> and valuable feedback from him was gathered
15:08:32 <korzen> I need to reach kevinbenton to settle the details
15:08:53 <korzen> but in general the discussion was about extensions and OVO
15:09:24 <korzen> how we should handle the out of tree plugins/extensions to neutron resources
15:10:19 <korzen> how API is currently passing all filters to plugins and we do not support unknown arguments in objects
15:11:10 <korzen> and also kevinbenton noticed a improvement required in objects like QoS and trunk to slip details up to API
15:11:48 <amotoki> I think we need a way to let the API layer know what attributes are available as filters.
15:11:59 <korzen> meaning like every fields in converted to to_dict and exposed via API, for example revision_number which was merged last week
15:12:56 <korzen> amotoki, so it should be the general aproach
15:13:10 <amotoki> korzen: totally agree
15:13:44 <korzen> for now, I guess we can remove the filters just before passing it to object
15:14:17 <korzen> #link 		○ http://lists.openstack.org/pipermail/openstack-dev/2016-July/100286.html
15:14:17 <amotoki> by which layer?
15:14:17 <korzen> ML discussion on approach
15:15:09 <korzen> amotoki, in db layer
15:15:29 <amotoki> korzen: sounds fair.
15:15:30 <korzen> like here https://review.openstack.org/#/c/321001/13/neutron/db/db_base_plugin_common.py@278
15:16:09 <korzen> currently is looks like unknown filters are filtered out in https://github.com/openstack/neutron/blob/master/neutron/db/common_db_mixin.py#L203
15:17:03 <korzen> currently, we are forced to change the tenant_id to project_id until API layer will take care of that
15:17:17 <korzen> not sure when that happen, amotoki dasm
15:17:52 <dasm> korzen: plans were to do this previous week/this week
15:18:00 <dasm> but still we didn't merge all db changes.
15:18:18 <amotoki> korzen: In my understanding, the API layer translates the changes so that the change does not affect the DB layer directly.
15:18:19 <korzen> dasm, ok, good to know, hope to see it ASAP :)
15:18:23 <dasm> so api will be next step after db.
15:18:37 <dasm> korzen: as asap as possible ;)
15:18:50 <korzen> dasm, exactly
15:19:12 <dasm> amotoki: that's the idea. but didn't look into api layer, so i'm not quite sure if something else would be necessary
15:19:29 <dasm> or it can be completely separated from db.
15:19:47 <amotoki> dasm: i need to investigate it a bit next two weeks before the midcycle.
15:20:04 <dasm> amotoki: hmm.. so this/next week?
15:20:43 <dasm> i'll also try to catch-up with api layer and check it before midcycle
15:20:49 <amotoki> dasm: yeah. at least the API layer needs to pass either of tenant_id or project_id to DB layer.
15:21:33 <korzen> my understanding is that DB layer should be prepared to handle both
15:22:30 <amotoki> dasm: korzen: yes. it should work, but the APi layer should pass either of them at some time
15:23:02 <amotoki> if DB layer accepts both, the migration would be easier :)
15:23:07 <dasm> korzen: you're assumption is correct, but what amotoki wrote.
15:23:14 <dasm> amotoki: :)
15:23:44 <korzen> yea, ok moving on
15:23:48 <dasm> :D
15:23:52 <electrocucaracha> hehe
15:23:56 <korzen> #topic Partial Multinode Grenade
15:24:03 <korzen> is sc68cal around?
15:24:44 <korzen> I guess not
15:24:54 <korzen> I have no update on that topic
15:25:12 <korzen> so next
15:25:20 <korzen> #topic Object implementation
15:25:34 <korzen> we had good progress last weeks
15:25:55 <korzen> Ihra was working on security groups patch
15:26:21 <korzen> I have subnet integration patch almost ready
15:26:43 <electrocucaracha> korzen: manjeet was doing some migration on models -> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bug/1597913
15:26:53 <korzen> thanks to manjeet on starting this effort
15:26:57 <ankur-gupta-f> korzen: o/ question(s)
15:27:03 <electrocucaracha> this effort was need it before OVO implementation
15:27:22 <korzen> #link https://bugs.launchpad.net/neutron/+bug/1597913
15:27:22 <openstack> Launchpad bug 1597913 in neutron "refactor model definitions" [Wishlist,In progress] - Assigned to Victor Morales (electrocucaracha)
15:27:37 <korzen> yes ankur-gupta-f ?
15:27:38 <ankur-gupta-f> Do you have the bandwidth to do network OVO? If so, what Objects need work?
15:28:01 <ankur-gupta-f> note: it will take me a bit longer to get up to speed
15:28:33 <korzen> ankur-gupta-f, well I guess I can use your help, because there is still one or two patches for subnet
15:29:06 <amotoki> korzen: is there any summary on the progress of OVO migration?
15:29:20 <dasm> amotoki: ++ do we have some up-to-date place?
15:29:21 <amotoki> I think it is related to ankur-gupta-f's question.
15:29:31 <dasm> i noticed that etherpad is kind outdated
15:29:59 <korzen> amotoki, dasm I guess that my last email for ML is a good point to start, other than gerrit
15:30:27 <korzen> let me grab a link
15:30:57 <korzen> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/099039.html
15:31:10 <dasm> korzen: thanks.\
15:31:21 <ankur-gupta-f> Digging through Subnet OVO I noticed that subnetpool is not a synthetic field but rather its own Object. Why is this? pardon my silly questions.
15:31:28 <ankur-gupta-f> thanks for the link korzen:
15:31:46 <korzen> so there is  list of objects and some of them is already merged
15:31:57 <electrocucaracha> korzen: even when the P1 is port, subnet and network, that doesn't restrict to take others right?
15:32:54 <korzen> ankur-gupta-f, not sure exactly
15:33:04 <amotoki> is P1 Phase1?
15:33:19 <korzen> electrocucaracha, your question is directed to core reviewers, rossella_s
15:33:24 <korzen> priority 1
15:33:30 <korzen> amotoki, ^
15:33:31 <amotoki> :)
15:34:04 <electrocucaracha> ack
15:34:05 <rossella_s> electrocucaracha, there's no restriction but if you have free cycle, better help with the existing objects
15:34:10 <korzen> electrocucaracha, the intention is like have the bigger objects converted first
15:35:00 <korzen> I'm happy seeing all the objects being developed in parallel but we are limited to core's bandwidth
15:35:30 <dasm> moar cores!!11 ;)
15:35:31 <amotoki> agree with all. In my understanding, we are now focusing on stuffs related to port/subnet/network as they have many attributes added by extensions
15:35:51 <ankur-gupta-f> korzen: If that is the case then the Etherpad should be updated with the P1 priorities and what specifically needs to be worked on for each Object (network, subnet, etc..)
15:35:52 <korzen> more cores (but not CPU) like they said in nova
15:36:01 <electrocucaracha> got it, maybe the only thing that can be do it in parallel is the movement of models
15:36:44 <korzen> ankur-gupta-f, which etherpad?
15:37:03 <ankur-gupta-f> https://etherpad.openstack.org/p/code-sprint-neutron-objects-brno
15:37:10 <ankur-gupta-f> unless a newer one exists
15:37:28 <ankur-gupta-f> I keep getting refered to it to pick up something to work on
15:37:34 <korzen> ankur-gupta-f, no I guess this is the only one, besides ML
15:38:28 <korzen> ok, I will update the etherpad then
15:38:35 <korzen> this week
15:38:38 <ankur-gupta-f> Thank you
15:38:42 <amotoki> From today's discussion, it seems better we have some etherpad pages to capture the progress
15:39:15 <amotoki> reusing the code sprint etherpad may be confusing though :-(
15:39:34 <korzen> #action korzen to update/create etherpad with OVO progress
15:39:50 <ankur-gupta-f> We have others on our team interested in potentially helping out as well. It would help out a lot. Thanks korzen: amotoki:
15:40:27 <amotoki> korzen: you don't need to do all by yourself of course.  everyone can collaborate :)
15:40:52 <korzen> yeap
15:41:01 <electrocucaracha> +1
15:41:21 <rossella_s> ankur-gupta-f, korzen the port object can be adopted, Ihar was working on it but he has plenty on his plate
15:41:41 <ankur-gupta-f> +2
15:42:28 <korzen> so subnet is very close, port is handles by Ihar but network could use some help
15:42:54 <korzen> we can also ask Ihar if he need a help in port
15:43:49 <rossella_s> korzen, let's create the etherpad and put all the info there
15:44:16 <korzen> rossella_s, ok, I will create such, and also we can put there an side effect jobs
15:44:20 <korzen> like Setup core plugin in multiple places
15:44:42 <korzen> or common place to modify the filters from API to object layer
15:44:49 <rossella_s> korzen, agreed
15:45:34 <korzen> or we have this API fitlering for QoS and trunk
15:45:41 <korzen> filtering*
15:45:58 <korzen> talking about extensions and objects
15:46:04 <korzen> Ihar started a patch
15:46:16 <korzen> #link https://review.openstack.org/#/c/348279/
15:46:46 <korzen> it is like get the db object as accessible field from OVO
15:47:49 <korzen> because the general request was- we cannot cut off the db from extension usage, which would mean that out of tree extension will be broken
15:48:29 <korzen> rossella_s, do you have any example in my, where out of tree extension can modify the DB to inject its logic?
15:49:00 <korzen> in mind*
15:50:51 <korzen> current approach to extension when using object is to define all fields that are needed upfront in object definition
15:50:52 <rossella_s> korzen, I don't but I imagine it's possible
15:51:25 <korzen> when out-of-tree extension wants to add anything, it wont get the data of of DB
15:51:32 <korzen> out of*
15:51:52 <korzen> I have hacked in UT
15:51:55 <rossella_s> korzen, they will have to use objects too...otherwise what's the point of this ?
15:52:12 <korzen> to dynamically add new field with defined OVO
15:52:34 <korzen> and at tearDown to remove the fields from 'fields'
15:52:45 <rossella_s> korzen, cool...add me as reviewer please
15:52:59 <korzen> rossella_s, let me grab a link
15:53:26 <amotoki> do we have any feedback from active out-of-tree plugins/drivers maintainers? it is not easy to discuss out-of-tree stuffs without good feedback...
15:54:04 <korzen> amotoki, nothing yet, only from kevinbenton
15:54:19 <korzen> rossella_s, https://review.openstack.org/#/c/321001/13/neutron/tests/unit/plugins/ml2/drivers/ext_test.py defining extension OVO
15:55:00 <rossella_s> korzen, thanks
15:55:24 <korzen> rossella_s, https://review.openstack.org/#/c/321001/13/neutron/tests/unit/plugins/ml2/test_extension_driver_api.py and here you have the hack
15:55:29 <korzen> line 191
15:55:59 <korzen> ok, I guess we are running late, any questions?
15:56:12 <korzen> #topic Open discussion
15:56:57 <korzen> amotoki, can you point me to any person who can give a feedback about out of tree extensions?
15:58:19 <amotoki> korzen: honestly I am not sure who is best person. Gary maintains vmware plugins but i am not sure nsx plugin is affected..
15:58:58 <korzen> ok, I will talk with kevin first and then maybe ML
15:59:04 <amotoki> most plugin/driver maintainer are noticed when their plugins/drivers start to break.
15:59:09 <dasm> :D
15:59:23 <amotoki> if it happens early in a cycle, it would be a good chance to communicate.
15:59:26 <korzen> :)
15:59:44 <korzen> ok we are out of time
15:59:59 <dasm> thanks o/
16:00:06 <korzen> thanks everyone, ping me on IRC ir something was not clear
16:00:11 <korzen> #endmeeting