15:01:27 <ihrachys> #startmeeting neutron_upgrades
15:01:27 <openstack> Meeting started Mon Jun 13 15:01:27 2016 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:29 <ihrachys> o/
15:01:31 <openstack> The meeting name has been set to 'neutron_upgrades'
15:01:32 <rossella_s> hi
15:01:35 <korzen> hello
15:01:37 <slunkad> hello
15:01:59 <jlibosva> o/
15:02:14 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:02:35 * ihrachys notes he should really clean up that agenda page...
15:02:44 <ihrachys> #action ihrachys to clean up agenda page
15:03:07 <dasm> o/
15:03:07 <ihrachys> #topic Actions from the last meeting
15:03:20 <ihrachys> "ihrachys to walk thru topic:ovo and change topics where applicable"
15:03:28 <ihrachys> well I checked some and changed topics for some
15:03:46 <ihrachys> we still have patches there that I thought maybe are not mature enough to show up in review page anyway
15:03:53 <ihrachys> "rossella_s to come up with specific list of TODOs for port object"
15:03:58 <ihrachys> rossella_s: that's yours
15:04:12 <rossella_s> ihrachys, shame on me, I haven't done it yet
15:04:21 <rossella_s> ihrachys, I promise I will do that this week
15:04:29 <ihrachys> #action to come up with specific list of TODOs for port object
15:04:33 <ihrachys> #action rossella_s to come up with specific list of TODOs for port object
15:04:49 <ihrachys> rossella_s: ack
15:05:03 <ihrachys> #topic Partial Multinode Grenade
15:05:12 <ihrachys> I am pretty sure nothing happened on that front
15:05:29 <korzen> I have done the patch: https://review.openstack.org/#/c/326366/ to break  the gate and it broke :D
15:05:31 <ihrachys> but I remember that korzen tried to break the job we have and it failed!
15:05:35 <ihrachys> YAY
15:05:42 <ihrachys> meaning, it works as we expect
15:05:51 <rossella_s> :)
15:06:27 <ihrachys> korzen: do you have a plan on getting DVR done? it should not be too hard, right? we had it passing before.
15:07:06 <korzen> ihrachys, I'm not planning to do it this week...
15:07:19 <korzen> I'm focusing more on Subnet OVO
15:07:46 <ihrachys> anyone brave enough to roll it the next few weeks?
15:08:12 <ihrachys> it will involve some boring infra setup
15:08:35 <ihrachys> #action ihrachys to come up with a plan for getting dvr grenade multinode voting
15:09:02 <ihrachys> I will take it unless someone else have cycles, in which case I am happy to move it to your plate
15:09:07 <ihrachys> #topic Object implementation
15:09:11 <rossella_s> thanks ihrachys
15:09:27 <ihrachys> there was A LOT of progress on objects and related topic
15:09:27 <ihrachys> *topics
15:09:33 <ihrachys> maybe not that much landed, but we'll get there
15:09:52 <rossella_s> yay
15:09:58 <korzen> jupi :)
15:10:02 <ihrachys> first, query hook mechanism added to objects: https://review.openstack.org/328304
15:10:15 <ihrachys> that one is waiting for CI to go into merge queue
15:10:28 <rossella_s> :)
15:11:02 <ihrachys> among other things, I realized that qos policy shared filter was broken in Mitaka by RBAC object changes. Fix uses the mechanism jlibosva added: https://review.openstack.org/328313
15:11:53 <ihrachys> I also have patches for qos plugin to support pagination/sorting: https://review.openstack.org/328259 and https://review.openstack.org/328273 (using Pager object we introduced lately)
15:12:05 <rossella_s> so productive you are :p
15:12:34 <ihrachys> there is also PortSecurity objects including db code conversion that I believe are ready for review: https://review.openstack.org/327257
15:13:01 <ihrachys> what else..
15:13:08 <ihrachys> obviously, we have subnetpools: https://review.openstack.org/300056
15:13:18 <ihrachys> but that one will probably need some rebases on top of other patches, right?
15:13:19 <ihrachys> jlibosva: ?
15:13:31 <jlibosva> I'll rebase once we merge hooking mechanism
15:13:45 <ihrachys> ok cool.
15:13:47 <jlibosva> CI failed btw :)
15:14:02 <ihrachys> jlibosva: yeah, but not your fault it seem
15:14:08 <jlibosva> of course not mine!
15:14:13 <ihrachys> haha
15:14:24 <korzen> I have published the Subnet OVO patch: https://review.openstack.org/#/c/321001/ What I need to do is to fix the tests...
15:14:30 <ihrachys> we also have sec groups patch from sayalilunkad: https://review.openstack.org/284738
15:14:58 <ihrachys> sec groups are actually quite a good one, I think with due effort it is a good candidate to land in next week,
15:15:12 <ihrachys> korzen: all places using the model switched?
15:15:27 <ihrachys> CI is red, that may take time to fix all that :)
15:16:13 <slunkad> ihrachys: yes possibly
15:16:23 <korzen> ihrachys, I have made the db plugin common/v2 to use it while get, update and delete
15:17:03 <ihrachys> one interesting thing that jlibosva surfaced with subnetpools is lack of support for CaS updates in objects interface
15:17:14 <ihrachys> jlibosva has a WIP here: https://review.openstack.org/#/c/327207/
15:17:19 <korzen> I have great fun trying to implement the 'shared' attribute
15:17:35 <ihrachys> korzen: wait why do you implement it
15:17:44 <ihrachys> korzen: we have all support in base classes?
15:17:58 <korzen> shared in subnet is based on shared in network
15:18:04 <ihrachys> korzen: if it's rbac, we have metaclass for that; otherwise it's a mere hook registration for queries
15:18:08 <korzen> the current rbac does not support it
15:18:08 <ihrachys> oh
15:18:20 <ihrachys> ok, I probably talk non-sense then :)
15:18:37 <korzen> I have introduced the lookup method for network shared state
15:18:50 <korzen> but I'm not proud of it, :(
15:18:57 <ihrachys> I see
15:19:00 <korzen> maybe I need to modify the rbac
15:19:13 <ihrachys> we may want to have that piece as a separate patch since it sounds like touching base mechanisms
15:19:41 <korzen> I can take a look if shared is not required in tests
15:20:45 <ihrachys> anyway, that's a great progress.
15:21:05 <ihrachys> I think we are still sometimes blocked by missing reviewers though.
15:21:27 <ihrachys> even though I try to pull relevant people in ;)
15:21:31 <korzen> anyone is willing to write the progress report this week?
15:22:18 <ihrachys> it's 2 weeks already?
15:22:29 <ihrachys> I can do it
15:22:30 <korzen> I have posted it on 2dn June
15:22:43 <ihrachys> #action ihrachys to send a bi-weekly to openstack-dev@
15:23:19 <ihrachys> anything more on objects? questions? concerns?
15:23:25 <korzen> ihrachys, thanks  :)
15:23:53 <ihrachys> rossella_s: anything from your side?
15:24:04 <ihrachys> rossella_s: do you think you will be able to review this week?
15:24:11 <jlibosva> one question on future steps and plan
15:24:12 <rossella_s> ihrachys, nope, last week I was busy with other stuff
15:24:34 <jlibosva> do we plan to introduce objects first just in order to make live db migration possible and then we'll start using objects over rpc?
15:24:36 <rossella_s> ihrachys, yes I will devote some hours to review for sure, feel free to ping me whenever needed
15:24:39 <ihrachys> rossella_s: btw do you track object related changes in vlan-aware-vms?
15:24:46 <stajkowski> ihrachys: rossella_s there are just some implementation questions on ovo from our team, is it possible to setup a time where we could address these as a group
15:24:48 <rossella_s> ihrachys, yes
15:24:56 <stajkowski> seems a few devs are stuck
15:24:57 <ihrachys> jlibosva: I think once we have objects, we can use them in rpc.
15:25:09 <ihrachys> jlibosva: f.e. kevinbenton plans to use subnet for rpc refactor spec
15:25:18 <ihrachys> I saw other people talking about using rpc callbacks
15:25:20 <rossella_s> stajkowski, this meeting is a good place I think
15:25:27 <ihrachys> in l3 agent extensions spec at least
15:25:39 <stajkowski> rossella_s: then we can compile and send over for next week
15:25:50 <ihrachys> stajkowski: what's your team?
15:26:14 <ihrachys> is it some feature like vlan-aware-vms? or just some company?
15:26:24 <stajkowski> ihrachys: osic neutron, intel/rackspace, we have about 4 devs working with you, tony tan, john perkins, victor and sai
15:26:40 <ihrachys> oh ok. yeah, please ping us on irc.
15:26:47 <stajkowski> ihrachys: will do ty
15:26:57 <ihrachys> it's pretty hard to know what issues you have if you don't
15:27:09 <jlibosva> ihrachys: so my question was whether we plan to do the whole server side first and then start rpc
15:27:31 <jlibosva> or it can happen for certain objects while we still have ongoing work for different resources
15:27:34 <ihrachys> jlibosva: I personally plan to focus on db, but no, I don't see a reason to block rpc if someone has interest in that specific part
15:27:40 <ihrachys> jlibosva: I will help with reviews for that too
15:28:02 <ihrachys> jlibosva: do I hear you stepping in or what? :D
15:28:03 <amotoki> jlibosva: does anyone plan to update RPC interface now?
15:28:36 <ihrachys> amotoki: at least for dhcp agent, yes, there is a spec that relies on rpc callbacks for subnet updates.
15:28:44 <korzen> are we talking about converting the calls to rpc callback?
15:28:47 <ihrachys> but not systematically for what I know
15:28:54 <amotoki> ah i see.
15:29:01 <ihrachys> korzen: yes, that's the question from jlibosva as I understand it
15:29:12 <jlibosva> I was just wondering whether there is a plan :)
15:29:49 <ihrachys> I don't think there is plan needed at this point. it's a general understanding that yes, it will be used on rpc side of things too
15:30:31 <ihrachys> does that answer a question? or you think it's silly not to have a detailed plan today for that?
15:30:43 <jlibosva> it answers, thanks
15:31:03 <ihrachys> ok good :)
15:31:16 <ihrachys> #topic Open discussion
15:31:35 <ihrachys> anything to discuss?
15:31:49 <amotoki> generic qustion
15:32:00 <amotoki> i have a question on the relationship between keystone v3 migration and ovo conversion.
15:32:28 <korzen> that is the good one
15:32:40 <amotoki> should we use rename_column from tenant_id to project_id, or do we use ovo from project_id?
15:33:03 <ihrachys> amotoki: for new objects, we use project_id I think. I think we have an example somewhere
15:33:04 <amotoki> i haven't synced with both efforts well, but let me ask it.
15:33:37 <amotoki> ihrachys: yes we already started to use project_id
15:33:52 <jlibosva> from objects perspective - shouldn't we just rely on model?
15:33:53 <ihrachys> amotoki: no, I mean ovo
15:34:08 <korzen> I have added the project_id to Subnet OVO, but in order to be backward compatible, I have added the property tenant_id, so that the user can do subnet.tenant_id and it will return the project_id
15:35:05 <ihrachys> jlibosva: yes. but for old resources that have tenant_id in model, we already use project-id in OVO
15:35:19 <ihrachys> https://github.com/openstack/neutron/blob/master/neutron/objects/subnet.py#L152
15:35:33 <amotoki> ihrachys: perhaps my understanding is same. we use project_id for new objects and still have tenant_id for existing db model.
15:35:41 <ihrachys> so it's translated into tenant_id when it reaches db_api
15:35:48 <amotoki> If I understand correctly, the next step of keystone v3 effort is db stuff.
15:35:56 <ihrachys> once models are switched to project-id too, we just remove that translation
15:36:12 <korzen> https://review.openstack.org/#/c/321001/2/neutron/objects/subnet.py@175
15:36:21 <ihrachys> in that way, we don't change fields for the object.
15:36:32 <korzen> here is how to expose project_id as tenant_id
15:36:44 <jlibosva> maybe I'm just not familiar with the keystone migration process/plan, does it mean Neutron won't be keystone v2 compat?
15:37:27 <amotoki> jlibosva: in kyestone v3 migration plan, we will rename all tenant-id fields to project_id FINALLY.
15:37:31 <dasm> amotoki: yes. next step with keystone v3 is prepare offline migration to rename tenant -> project
15:37:56 <amotoki> so the question is to rename tenant_id column or we handle renaming to project_id by ovo.
15:38:03 <amotoki> this is the reason I asked
15:38:14 <ihrachys> amotoki: please rename in the db while you can
15:38:15 <korzen> amotoki, both?
15:38:34 <ihrachys> in ovo, we will do it for existing objects that may still have tenant_id
15:38:42 <ihrachys> but that may require some compat code
15:38:45 <jlibosva> amotoki: does it mean Neutron won't be able to talk to keystone v2, if tenant_id will be gone?
15:39:23 <amotoki> jlibosva: no. it is dealt by keystoneauth library. we can continue to talk to kyestone v2
15:39:45 <jlibosva> amotoki: aha, thanks
15:40:18 <korzen> My understanding is that we cannot sent project_id over RPC because of backward compat
15:40:33 <amotoki> ihrachys: thanks for the clarification. we can rename tenant_id_to project_id in the keystone v3 work and ovo can deal with tenant_id (if needed)
15:40:51 <ihrachys> korzen: we can if we do it in rolling way.
15:41:09 <ihrachys> amotoki: right. I don't think we are tightly coupled.
15:41:54 <amotoki> i just want to clarify we will support API live upgrade in neutron. if we rename tenant_id to project-id, we cannot do API live upgrade in newton.
15:42:04 <amotoki> does it match to the current plan?
15:42:15 <korzen> ihrachys, I meant that we would drop the tenant_id immediately
15:43:02 <ihrachys> amotoki: not sure what you mean by 'API live upgrade'
15:43:27 <ihrachys> amotoki: mixed controller versions? no, it does not get support for M->N upgrades
15:43:34 <korzen> amotoki, do you mean like multiple neutron server running in different version in the same?
15:43:50 <amotoki> ihrachys: yes. mixed version of controller versions
15:44:36 <ihrachys> amotoki: no, it does not affect you since it won't be supported.
15:45:00 <ihrachys> amotoki: overall, if there were a solution for that, it would involve much more than special casing for tenant-id.
15:45:10 <amotoki> ihrachys: ah..... sorry 'no' is correct in English.
15:45:11 <ihrachys> it requires a complete api versioning
15:45:27 <amotoki> i would like to mean 'no'.
15:46:04 <ihrachys> amotoki: does it answer your question?
15:46:23 <amotoki> ihrachys: yes I got the answer.
15:46:47 <amotoki> we use a contract migartion to rename tenant_id to project_id. right?
15:46:57 <ihrachys> right
15:46:59 <dasm> amotoki: yes.
15:47:20 <ihrachys> any more questions? comments? concerns?
15:47:48 <korzen> amotoki, the API would accept both tenant_id and project_id?
15:48:09 <amotoki> korzen: yes. that's the plan now.
15:48:25 <korzen> amotoki, ok, that's nice
15:48:37 <amotoki> dasm is the main person who is now working on it. i should help it.
15:49:17 <ihrachys> amotoki: do you have a plan to remove support for tenant? it's actually a breaking change for api if we decide to remove it.
15:49:57 <amotoki> ihrachys: we cannot drop tenant_id support until API versioning comes.
15:50:22 <amotoki> sorry for slow progress....
15:50:43 <ihrachys> right. making sure we don't just pull the rug from under our users in say two cycles
15:50:51 <amotoki> at least we don't plan to drop tenant_id in newton
15:51:05 <ihrachys> well that would be insane for newton indeed :)
15:51:18 <dasm> REMOVE THEM ALL!
15:51:20 <dasm> :)
15:51:27 <korzen> the rugs?
15:51:36 <ihrachys> USERS
15:51:37 <dasm> code from neutron
15:51:39 <amotoki> both project_id and tenant_id ? :)
15:51:54 <ihrachys> USERS, they always make developer lives harder
15:52:12 <korzen> no users no bugs!
15:52:44 <ihrachys> finally we will be able to polish all the tests and documentation. sweet dream.
15:53:11 <ihrachys> ok cool. unless someone has more to say, I will call it a day in a minute
15:54:11 <ihrachys> #endmeeting