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