15:03:34 #startmeeting neutron_upgrades 15:03:34 Meeting started Mon Jan 18 15:03:34 2016 UTC and is due to finish in 60 minutes. The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:03:38 The meeting name has been set to 'neutron_upgrades' 15:04:04 let's go straight to specific patches :) 15:04:11 #topic partial upgrade 15:04:50 we have some great progress on that front. specifically, we seem to understand the reason for job failures: bad mtu settings in multinode gate 15:05:07 ihrachys, good news 15:05:34 we have a gerrit topic for all those patches 15:05:36 #link https://review.openstack.org/#/q/status:open+topic:multinode-neutron-mtu 15:05:45 ihrachys, MTU is always problematic...I hope we will fix it 15:06:04 it does not completely fix the job, but at least we go past initial resource creation, run tests, and only 3 of those fail 15:06:14 (all due to ssh not working on FIP) 15:07:03 folks are looking further on those failures, maybe it's also mtu related, just now on br-ex side (previous issue was due to bad mtu from br-tun side) 15:07:16 ok, let's move on :) 15:07:20 #topic objects 15:07:21 thanks for the recep ihrachys 15:07:25 I had one patch on DVR multinode grenade experimental job - can we enable it in short while? 15:07:27 rossella_s: wanna update? 15:07:37 ihrachys, yes 15:07:47 korzen: sorry, let's return to that a bit later 15:07:58 ihrachys, I updated the agenda too, so I have a patch regarding port the allowed address pairs extension 15:07:59 ok, no problem 15:08:12 https://review.openstack.org/#/c/268274/ 15:08:44 folks interested in having a task can look in the backlog, I have listed the extensions that needs to be ported 15:09:23 regarding the port ovo, tests are passing, work is paused since I want to port all the extensions needed first so that we can move the whole port object to ovo 15:09:46 rossella_s: cool! patch seems quite clean on brief sight 15:09:47 reviews are welcome :) 15:09:54 not invasive or smth :) 15:10:06 I tried ihrachys 15:10:17 another patch to mention is https://review.openstack.org/#/c/268273/ "Handle OVO that don't have ID as primary key" 15:10:28 I'd appreciate if you ihrachys could have a look 15:10:42 it's a way of handling object that don't have the "id" field 15:11:02 that's all from me 15:11:15 oh right. that is indeed missing in base db api. will check. 15:11:21 korzen: what's on your side? 15:11:50 so I have the patch: https://review.openstack.org/#/c/264273 - I have added the status there 15:12:20 current the unit tests are failing, I'll be working on fixing them 15:12:46 The network OVO is used in one use case - DHCP requests 15:12:50 nice. also specific coverage should be added to all new objects. 15:12:57 yes, that's too 15:13:20 currently there is only the GET method implemented using the ML2plugin 15:13:48 I see you added RBAC object. I think hdaniel had some patch for qos policies to add rbac support there that required objects. probably not sent to gerrit yet though. 15:14:13 yes, the NetworkRBAC is just for reference 15:14:26 I did not use it so can remove it from my patch 15:14:41 I have worked also on Subnet OVO 15:14:43 ok cool. I will get back to hdaniel to see what's ETA on his side for RBAC aware objects 15:14:59 in the same patch 15:15:21 korzen: will we be able to split it? 15:15:24 I can split but I guess that is can be also introduced in one patch Netrwork and Subnet 15:15:41 or there are some obstacles against doing it? 15:16:03 I prefer to split concerns. it's easier for reviewers to grasp 15:16:11 without subnet ovo the network ovo is using the custom JSON field 15:16:11 and hence merge :) 15:16:20 ihrachys, +1 15:16:26 then I guess we first introduce subnets, then networks 15:16:32 yep 15:16:40 ok, I'm fine with it 15:16:43 your network patch can depend on the subnet on korzen 15:17:14 ok, I will change it 15:17:16 korzen: thanks! 15:17:33 any more updates on objects? 15:17:33 I have also introduced the RPC serialiazer 15:17:51 korzen: what's that? link? 15:17:57 https://review.openstack.org/#/c/269056 15:18:16 it is the case where we are sending the OVO via RPC not dicts 15:18:33 the output is that we can deserialize the object on the client side 15:18:54 and check for the compatible version 15:19:18 currently we are using the OVO on server side 15:19:24 korzen: what's the expected usage for the serializer in neutron? 15:19:36 korzen: we also use it on agent side, for qos 15:19:47 thru rpc callbacks 15:19:59 and on client's, the info metadata about what is the version is lost 15:20:29 we can send the OVO via RPC and check on client side if it is matching the client's code 15:20:45 it is maily for future use, for example for backports 15:20:46 yeah, but it's assumed for now versions haven't changed. and once the ajo's patch for rolling upgrades for rpc callbacks is merged, agents should always receive their own version. 15:21:24 Indirection API - ask server to translate the message to required lower version 15:21:46 it can also log the error message 15:21:49 for admin usage 15:21:56 korzen: we have it in some form for rpc callbacks. if we don't use them, yes, it may make sense. 15:22:19 ok, I guess we'll need to discuss it in review itself 15:22:21 are we going to use rpc callcabacks for ports and networks? 15:22:30 korzen: yes, that was the assumption 15:22:54 using rpc callbacks for all object state propagation from server to agents 15:23:24 ok, so lets look into my patch and see if it is usable for neutron 15:23:59 right. should be considered in more broad context, looking it general rpc strategy we'll take. 15:24:25 #topic other patches 15:24:33 korzen: what was that about dvr? 15:24:52 let me link it 15:25:38 https://review.openstack.org/#/c/250215 15:26:01 Create DVR multinode grenade job for Neutron upgrade tests 15:26:17 it is introducing the DVR gate job for grenade testing 15:26:43 not gate, experimental for now 15:27:01 yeap, I meant experimental 15:27:39 korzen: should we maybe fix legacy mode first as sc68cal suggested? 15:28:17 yes, this is my thinking also, but I wanted not to lost my commit there 15:28:41 as long as it's not abandoned, we won't loose it :) 15:29:11 ok, I have one small update to devref related to RPC rolling upgrades 15:29:13 #link https://review.openstack.org/268125 15:29:18 reviews welcome 15:29:55 Noted ;) 15:29:55 anything else worth attention? mhickey? 15:31:22 ok, probably nothing :) 15:31:28 :) 15:31:33 #topic open discussion 15:31:42 anything else anyone wants to share? 15:32:09 do you think we can land the OVO implementations for Mitaka? 15:32:32 We can try at least 15:32:50 korzen: pieces of it, yes. I am not very optimistic about *all* the pieces we could in theory merge. 15:33:14 hi, I'm around now 15:33:23 any advice how to proceed to get most of it merged? 15:33:31 more decoupling? 15:33:39 more manpower? 15:33:39 korzen: well, we need reviews and proper test coverage. 15:33:40 More tests 15:33:48 korzen: yes, decoupling helps. one piece at a time 15:33:54 ajo: ok tell us about rpc callbacks 15:34:18 ihrachys : ack, the core logic is up for review here: https://review.openstack.org/265347 15:34:59 ihrachys: sorry; was distrecated 15:34:59 and integration is WIP https://review.openstack.org/268040 I hope I will publish the final integration there tomorrow 15:35:08 *distracted* 15:35:22 first patch is the one that calculates the version sets that need to be pushed over the wire, 15:35:33 I am proceed reviewing the ajo's patch, but more eyes would be welcome. I need to admit it's hard to understand and we may need to shuffle it for a bit. 15:35:48 and the second one, introduces the needed RPCs (agents->neutron-server) to update versions quickly to all running neutron servers as the agents come up 15:36:02 I will have a look too...I put it in my queue 15:36:03 ajo: i will give more feedback as I understand more 15:36:11 ihrachys , ack, that's ok, the easier to understand, the better. 15:37:11 ihrachys: need to sync with HenryG today on has_offline_migrations patch 15:37:25 folks, that's re https://review.openstack.org/248190 ^ 15:37:37 mhickey: I saw folks tested it and reported success back. nice. 15:38:23 ihrachys: just need to see if solution is enough till the "one env" 15:38:34 mhickey: I see you need to hardcode table names for *aas 15:38:44 mhickey: does it mean it won't work with other subprojects? 15:39:25 ihrachys: yes; most ugly but might be no point in doing more until the env are squashed 15:39:48 ihrachys: what other subprojects? 15:39:55 I see. we need to think at least about how we handle those cases. 15:40:03 mhickey: well, any 3party plugin 15:40:03 mhickey: like vmware-nsx 15:40:43 ihrachys: not if they are using a version table that is not "alembic_version" 15:41:23 mhickey: I suspect they don't, need to check with HenryG 15:41:57 ihrachys: yes; if thats the case then we would need some configuration to help tell Neutron what is the version table name. 15:42:01 another example: https://github.com/openstack/networking-sfc/tree/master/networking_sfc/db/migration/alembic_migrations/versions/liberty 15:42:32 mhickey: https://github.com/openstack/networking-sfc/blob/master/networking_sfc/db/migration/alembic_migrations/env.py#L26 15:43:03 mhickey: yeah, I think I mentioned before we may need to have some API for plugins to pass the table names 15:43:16 may be using stevedore hooks? 15:43:18 mhickey: and if they don't, we can just bail out with an error. 15:43:26 ajo: yes, that would be the idea 15:43:30 ihrachys; my goodness, we are opening Pandora's box! :) 15:43:43 mhickey pandora box was open long ago :D 15:43:56 ajo: sure... 15:43:58 yeah, the day neutron repo was created 15:44:02 lol 15:44:03 ajo :D 15:44:07 Lol 15:44:12 lol 15:44:36 ok, we'll need to figure out something for subprojects. :) 15:44:43 ok, let me investigate it more and see how I can try and bring the patch to a good state for merging. 15:45:41 ok, let's wrap the meeting. seems like all is discussed. 15:46:04 thank you folks! 15:46:05 #endmeeting