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