15:03:00 <ihrachys> #startmeeting neutron_upgrades
15:03:01 <openstack> Meeting started Mon Jan 25 15:03:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:04 <openstack> The meeting name has been set to 'neutron_upgrades'
15:03:10 <ihrachys> o/ to all
15:03:24 <ihrachys> #topic Organisational matters
15:03:48 <ihrachys> rossella_s: wanna talk about objects sprint?
15:03:55 <rossella_s> ihrachys, sure!
15:04:18 <rossella_s> ihrachys, so the idea is to gather in Europe to make some progress regarding the introduction of ovo
15:04:35 <rossella_s> anybody interested?
15:04:43 <korzen> I'm interested
15:04:44 <ihrachys> me obviously :)
15:04:48 <rossella_s> :P
15:04:52 <mhickey> me too
15:04:58 <ihrachys> mhickey: cool
15:05:12 <mhickey> ihrachys: would need travel approval first
15:05:15 <dguitarbite> me too!
15:05:33 <ihrachys> ok, I guess we have some ideas about what the place would be. One suggestion was Brno (Red Hat office), another was Nuremberg (SuSE)
15:06:21 <ihrachys> I am obviously welcoming everyone to Brno :D [though I will need to check with local office guardians to make sure it would be avail]
15:06:37 <ihrachys> what would be the time for that?
15:06:43 <rossella_s> regarding Nurember it's confirm that it's available
15:07:06 <rossella_s> ihrachys, good question...end february?
15:07:13 <rossella_s> how do others feel?
15:07:27 <ihrachys> unless someone plans to go to Minnesota, I am fine with end of Feb
15:07:32 <sc68cal> don't do end of feb please
15:07:46 <sc68cal> I'm already going to QA midcycle end of feb... which is booked the same week as neutron midcycle
15:07:54 <sc68cal> err - which neutron midcycle double booked
15:07:57 <mhickey> not last week of februrary for me
15:07:58 <sc68cal> please don't triple book. :(
15:08:09 <korzen> 15th?
15:08:14 <ihrachys> ok, let's look middle of March maybe?
15:08:19 <mhickey> February*
15:08:25 <korzen> it depends how much we would like to achieve
15:08:29 * ihrachys wonders how to check against over-booking
15:08:31 <sc68cal> march please. Enough time to ask for travel approval
15:08:44 <rossella_s> March is ok for me
15:08:50 <sc68cal> also not get screwed by last minute airfare
15:08:51 <ihrachys> korzen: elaborate
15:09:16 <korzen> I mean that Mitaka-3 is at beginning of the March
15:09:33 <korzen> if we would like to progress with OVO for mitaka we should gather faster
15:09:51 <mhickey> korzen: probably a good point
15:10:00 <korzen> March would be too late
15:10:07 <SamYaple> o/
15:10:16 <ihrachys> korzen: I suspect there is no feature-wise push for getting it exactly in Mitaka. If we do progress for very start of N, that would still be a reasonable time for that.
15:10:20 <sc68cal> yeah but we didn't plan well enough in advance to do an in person meeting
15:10:33 * SamYaple is from Kolla team, sorry for being late
15:10:41 <ihrachys> SamYaple: hi!
15:10:47 <sc68cal> now we're going to try and get everyone to book with about 2 weeks notice to fly to europe? ehhhhh
15:11:06 <ihrachys> korzen: I think we can still make some mitaka progress offline too. it's not like we will wait till March to do anything.
15:11:26 <korzen> ok, just saying my point
15:11:47 <ihrachys> sc68cal: what would be a better time? mid March ok or too early?
15:12:01 <sc68cal> I think mid march is reasonable
15:12:54 <ihrachys> ok, let's figure it out really quick. rossella_s, let's discuss afterwards around location.
15:12:57 * sc68cal is being opinionated because he's going to submit travel budget for this
15:13:07 <ihrachys> sc68cal: that's pretty cool :)
15:13:36 <ihrachys> sc68cal: btw fwaas 2.0 could be a good candidate for ovo too ;)
15:13:46 <ihrachys> ok, let's move on
15:13:48 <ihrachys> #topic Partial Multinode Grenade
15:13:51 <korzen> how long would the sprint take?
15:13:51 <sc68cal> ihrachys: indeed. We talked about that at the midcycle
15:14:06 <ihrachys> #undo
15:14:07 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x97b6490>
15:14:12 <ihrachys> korzen: that's a good question.
15:14:18 <korzen> 3 days?
15:14:20 <ihrachys> 3 days?
15:14:21 <rossella_s> yes
15:14:24 <rossella_s> :)
15:14:54 <rossella_s> I guess 3 days is the minimum amount of time to make decent progress
15:15:01 <korzen> ok, to lets say it will be 3 days and starting monday 7th or 14th
15:15:16 <ihrachys> 14th is more mid march ;)
15:15:36 <ihrachys> ok, moving on
15:15:39 <ihrachys> #topic Partial Multinode Grenade
15:16:03 <ihrachys> sc68cal: I think we are almost there with https://bugs.launchpad.net/neutron/+bug/1527675
15:16:04 <openstack> Launchpad bug 1527675 in neutron "Neutron multinode grenade sometimes fails at resource phase create" [High,Confirmed] - Assigned to Sean M. Collins (scollins)
15:16:04 <ihrachys> right?
15:16:18 <sc68cal> yep
15:16:18 <ihrachys> just a patch or two to merge to fix that mtu issue.
15:16:29 <sc68cal> just need your backport to devstack for stable/liberty to go through
15:16:33 <sc68cal> and the devstack-gate change
15:16:39 * sc68cal fetchese URLs
15:16:44 <sc68cal> *fetches
15:17:15 <ihrachys> yeah. I believe once those are in, we'll have 3 test failures to fix, all while ssh-ing using floating IP
15:17:58 <ihrachys> I actually thought those will be fixed by some of https://review.openstack.org/#/q/status:open+project:openstack-infra/devstack-gate+branch:master+topic:multinode-neutron-mtu but it did not look that way when I checked gate results.
15:18:28 <ihrachys> we'll probably need another bug to report once we get latest gate results with MTU fixes in
15:18:32 <sc68cal> ack.
15:18:34 <sc68cal> https://review.openstack.org/267605
15:18:41 <sc68cal> https://review.openstack.org/267847
15:18:56 <sc68cal> for those following at home
15:19:07 <ihrachys> I was playing with all needed patches with https://review.openstack.org/#/c/265759/ fake patch. anyone can use it to check experimental to collect latest logs.
15:20:00 <ihrachys> sc68cal: that MTU discussion on openstack-dev, does it reveal any specific action items that could help the job?
15:20:12 * ihrachys hasn't checked it just yet
15:20:31 <sc68cal> ihrachys: not yet. I think we're still in the exploring phase. Sam-I-Am has hardware and is poking things
15:21:00 <sc68cal> but the consensus is this whole thing is just silly and we need to simplify this whole thing.
15:21:15 <ihrachys> it won't be neutron anymore, will it?
15:21:31 <sc68cal> I mean if we as neutron-devs can't set the MTUs correctly at the gate for our CI jobs how in the hell is anyone else supposed to have a chance at this
15:22:05 <ihrachys> jumbo frames! isn't that what we suggest now?
15:22:17 <ihrachys> I mean, allowing them on physical layer
15:22:39 <sc68cal> right
15:23:12 <sc68cal> but if you don't have access to jumbo frames but want to do tunnels.... we screw them
15:23:30 <ihrachys> yeah. ok, we'll dig more. and the next is...
15:23:33 <ihrachys> #topic Object implementation
15:23:45 <dguitarbite> sc68cal: devs ... its a ops issue ;)
15:24:13 <ihrachys> on that side, I think we finally started with some progress. there are patches for port and network, also allowed addresses
15:24:20 <ihrachys> allowed address pairs: https://review.openstack.org/#/c/268274/
15:24:29 <ihrachys> port: https://review.openstack.org/#/c/253641/
15:24:36 <ihrachys> subnet: https://review.openstack.org/#/c/269056
15:25:02 <korzen> Subnet is: https://review.openstack.org/#/c/264273
15:25:21 <ihrachys> oh, sorry
15:25:36 <ihrachys> need to fix the agenda :)
15:26:17 <rossella_s> yep the agenda is out-dated, my fault too
15:26:19 <ihrachys> there is also a follow up for the hasher test that should save against unexpected API changes for objects: https://review.openstack.org/270230
15:26:40 <ihrachys> the test was working for the most part, but just not guaranteed :)
15:27:36 <ihrachys> ok, moving forward
15:27:39 <ihrachys> #topic other patches
15:28:05 <ihrachys> mhickey successfully pushed has_offline_migrations that week: https://review.openstack.org/248190 Congrats!
15:28:25 <mhickey> ihrachys: thanks and to all reviewers
15:28:36 <ihrachys> that should help folks to automate expand-only online upgrades (actually requested by ansible folks)
15:29:07 <ihrachys> also ajo proposed upgrade patch for rpc callbacks: https://review.openstack.org/265347
15:29:36 <ihrachys> that's somewhat related to versioned objects (currently affecting qos objects only, but will later be used for other resources)
15:29:38 <rossella_s> lots of stuff to review
15:29:42 <ihrachys> oh yeah
15:30:16 <korzen> one question regarding the rpc callback, can someone point to code where the OVO is sent over wire>
15:30:17 <korzen> ?
15:30:30 <ihrachys> sec
15:30:59 <ihrachys> korzen: https://github.com/openstack/neutron/blob/master/neutron/api/rpc/handlers/resources_rpc.py#L139
15:31:07 <korzen> ok thx ihrachys
15:31:36 <ihrachys> that rpc callbacks patch is a scary beast, the more eyes the better.
15:32:06 <ihrachys> ok. speaking of partial upgrades, we still need that backport to fix rolling upgrade for security groups for K->L: https://review.openstack.org/268697
15:32:19 <ihrachys> (not that we are going to gate on it but still)
15:32:49 <ihrachys> there is also a small devref change to clarify our current strategy for rolling upgrades for notifications: https://review.openstack.org/268125
15:33:44 <ihrachys> that's about it on patches side from me. anything else we should care?
15:34:03 <rossella_s> not that I know
15:34:04 <korzen> speaking about the https://review.openstack.org/#/c/269056
15:34:11 <korzen> Use Oslo Versioned serializer for RPC messages
15:34:28 <korzen> it is affecting the OVO sent over main RPC
15:34:44 <korzen> because now, we will be sending only dicts, without metadata
15:34:58 <ihrachys> ah right, that one. I was not sure about that one. at least until we have a case where we push an object directly, omitting modules like rpc callbacks
15:35:48 <ihrachys> korzen: the way it's currently handled for rpc callbacks is that version is implied from topic name.
15:36:17 <korzen> ok, so metadata is sent
15:36:22 <korzen> so no*
15:36:26 <ihrachys> there may be cases when we want to sent metadata as part of payload, but I would like to see them before we go with using that serializer.
15:36:59 <korzen> ok, the serializer would hit us twice them
15:37:03 <ihrachys> korzen: hm, I should actually check it. maybe it does. it's just that it's not vital there.
15:37:15 <korzen> one hit will be when introducing OVO on agent side
15:37:56 <korzen> and then introducing the serializer will impact the agent again
15:38:24 <ihrachys> not sure I follow
15:39:21 <korzen> when we sent OVO over wire, we should be able at agent side rebuild the OVO object to see if agent is able to handle the version
15:40:07 <korzen> reasonable would be to introduce the serializer before sending the OVO
15:40:33 <korzen> but maybe someone more experienced with OVO had better point of view
15:41:52 <rossella_s> korzen, not to discourage you but I think the idea is that for now this serializer is not need so you can start working again on this patch when there's a real need
15:42:16 <korzen> it can be also done step by step: OVO at server side, serializer, OVO at agent side
15:42:57 <rossella_s> let's first introduce OVO then we can work on the serializer. Without OVO in place I don't see the point
15:43:54 <korzen> ok, for OVO at serve side it would be OK
15:44:46 <ihrachys> for the very first OVO phase, I would not expect us to expose objects to agents. that would require RPC refactoring, which is a separate deal.
15:44:46 <rossella_s> korzen, and thanks for all your work! you can resume the serializer when time is ripe for it
15:45:20 <ihrachys> ok, next is...
15:45:26 <ihrachys> #topic object ERD
15:46:30 <ihrachys> not much on that one; but fyi ski2 sent me some core resource models' ERD in private, I will need to look into it and will send it to openstack-dev@
15:46:52 <ihrachys> or maybe just ask him to share with everyone :)
15:47:05 <rossella_s> :)
15:47:13 <ihrachys> that diagram should help us to make calls on what's next to tackle for objectification
15:47:30 <ihrachys> ok, and next is...
15:47:33 <ihrachys> #topic Open discussion
15:47:36 <electrocucaracha> I started an extension of sphinx to autogenerate the diagrams,
15:47:54 <ihrachys> electrocucaracha: oh nice. are you working in sync with ski2?
15:48:02 <electrocucaracha> yes
15:48:36 <electrocucaracha> ohh sorry, I'm in sync with saisriki
15:49:02 <electrocucaracha> but, I'll send the instructions to ski2 as well
15:49:15 <ihrachys> electrocucaracha: ok, as long as it's not parallel efforts :)
15:49:29 <ihrachys> electrocucaracha: and thanks! :)
15:50:12 <rossella_s> electrocucaracha, nice nickname :D
15:50:23 <electrocucaracha> :) thanks rossella_s
15:50:53 <saisriki> I was working on the ERD in sync with electrocucaracha and ski2
15:51:21 <saisriki> The ERD is available for viewing at https://www.gliffy.com/go/html5/9741595?app=1b5094b0-6042-11e2-bcfd-0800200c9a66
15:52:48 <ihrachys> saisriki: note it's some proprietary webapp with trial period. we need something more stable for that, even short term :)
15:53:22 <saisriki> ack
15:53:33 <ihrachys> thanks again
15:53:38 <ihrachys> anything else folks?
15:53:39 <electrocucaracha> my understanding is that the final solution will be an script to autogenerate it
15:54:07 <ihrachys> electrocucaracha: that's the ideal, yes
15:54:56 <electrocucaracha> https://github.com/electrocucaracha/schemadisplay_sphinx
15:55:18 <electrocucaracha> that's the sphinx extension that I'm working
15:55:36 <ihrachys> nice. will it get a separate pypi package?
15:55:42 <ihrachys> or do we put it into neutron tree?
15:56:07 <electrocucaracha> I don't think so, I just place the code there
15:56:13 <sc68cal> ihrachys: we probably just add it to conf.py in neutron's doc/
15:56:26 <sc68cal> in the list of extensions, and then add it to requirements
15:56:54 <sc68cal> doc/source/conf.py
15:56:55 <ihrachys> that's ideal. that would mean a pypi package for the extension though.
15:57:36 <ihrachys> ok, once we get code, we'll handle the integration in some way :)
15:57:47 <ihrachys> thanks all for joining!
15:57:57 <ihrachys> and have a great week :)
15:57:58 <ihrachys> #endmeeting