15:02:01 <ihrachys> #startmeeting neutron_upgrades
15:02:02 <openstack> Meeting started Mon Jan 30 15:02:01 2017 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:05 <openstack> The meeting name has been set to 'neutron_upgrades'
15:02:15 <korzen> hello
15:02:16 <sindhu> hi
15:02:16 <ihrachys> hello everyone
15:02:50 <ihrachys> #link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam Agenda
15:03:03 <ihrachys> #topic Announcements
15:03:23 <ihrachys> Ocata-3 released the previous week, so we are in freeze mode
15:03:33 <ihrachys> meaning, we don't land non-critical bits
15:04:02 <ihrachys> from those that we care about, I think only https://review.openstack.org/#/c/407868/ has a chance for exception
15:04:11 <ihrachys> others will need to wait for Pike to open
15:04:19 <ihrachys> which should happen when rc1 is cut off master
15:04:22 <ihrachys> which is this week
15:05:01 <ihrachys> any other patches that we think are critical to merge before rc1 cut off?
15:05:33 * electrocucaracha is thinking
15:05:35 <korzen> no, I guess that port binding adoption patch is the one
15:06:03 <korzen> I'm working on it, but need more time to adopt to extended PortBinding Db model
15:06:26 <korzen> I can say what is wrong on next section
15:06:30 <ihrachys> yeah I see all test fail. is it some new development in code base that triggered that?
15:06:39 <ihrachys> ok let's do in next section
15:06:49 <ihrachys> #topic Partial Multinode Grenade
15:07:01 <ihrachys> korzen: did you mean this section, or another one?
15:07:16 <korzen> another
15:07:17 <korzen> ;)
15:08:07 <ihrachys> ok, re partial
15:08:22 <ihrachys> I was going to report bugs for linuxbridge job. I haven't :-o
15:08:27 <ihrachys> I will follow up after the meeting
15:08:50 <ihrachys> as for another matter of business, multiple api servers, have you korzen set the env you planned to?
15:09:07 <korzen> sadly no
15:09:15 <korzen> I'm targeting to test in this week
15:09:26 <ihrachys> ok we both slag, good :)
15:09:48 <ihrachys> slag, is it a word? nevermind
15:10:09 <ihrachys> #topic Object implementation
15:10:19 <ihrachys> korzen: your stage
15:10:46 <korzen> ok, so the port binding table was extended with status field and 'host' was added to primary keys
15:11:12 <korzen> and the port binding adoption patch was not adjusted to have host as primary key
15:11:30 <korzen> one issue is to add host in get_object
15:11:56 <korzen> the other issue is that current flow of creating port binding is udpating the host in later steps
15:12:05 <korzen> updating*
15:12:30 <korzen> now having the host as primary key, OVO is forbidding to update it
15:13:18 <korzen> so I'm working on delete and create instead of update the port binding
15:13:30 <ihrachys> oh. we can either delete/create, or we may need to relax rules for primary keys not being updatable
15:14:03 <ihrachys> what was the reason why we enforced that in the first place? any good explanation?
15:14:06 <korzen> it is the requirement not to update the primary keys because of objects DB API
15:14:29 <korzen> in object DB API we are doing fetch and then save the changes
15:14:42 <korzen> if you change the primary key, the fetch will fail
15:15:25 <korzen> and you do not have a way of look back the original value of PK
15:15:30 <korzen> in object state
15:15:52 <ihrachys> oh right.
15:16:12 <ihrachys> so we would need to pass two sets of filters - one for original keys, another for new
15:16:26 <ihrachys> yeah better keep it simple while it's possible and do delete/create
15:16:49 <korzen> yes
15:17:16 <korzen> so I'm looking into delete&create scenario, the work is in progress
15:17:29 <ihrachys> that being said, an updated object == fetched object, so we have the info on original fields; but probably not worth of exploring.
15:17:48 <ihrachys> korzen: thanks, I hope we can get it in this week to avoid dangerous backports
15:18:14 <korzen> I hope it also
15:18:47 <ihrachys> looking at the merged list from previous week
15:18:55 <ihrachys> https://review.openstack.org/#/q/status:merged+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db
15:19:12 <ihrachys> seems like we landed ipam only
15:19:32 <ihrachys> as for open patches...
15:19:33 <ihrachys> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/adopt-oslo-versioned-objects-for-db
15:20:06 <ihrachys> some were ready to go, like Tag or ProvisioningBlock, but will need to wait master to reopen
15:20:16 <korzen> I was also looking into subnet ovo adoption patch
15:20:16 <electrocucaracha> ihrachys: what about Tag? it was so close
15:20:39 <ihrachys> electrocucaracha: we bumped it off gate after Ocata-3 was released.
15:20:49 <ihrachys> we will land in due course start of Pike
15:21:04 <ihrachys> NetworkSegment turned out to have an issue with passing gate: https://review.openstack.org/385178
15:21:10 <ihrachys> electrocucaracha: any news on that gate failure?
15:21:24 <ihrachys> the one where neutron apparently hanged on segment allocation
15:21:41 <electrocucaracha> I tried using dicts instead of objects but it's still failing
15:22:08 <electrocucaracha> I noticed that most of the suscriptors use them as dicts
15:22:32 <electrocucaracha> I'll need extra eyes on that
15:22:53 <ihrachys> ok. have you tried to reproduce it locally?
15:23:55 <electrocucaracha> I think that I couldn't
15:24:04 <electrocucaracha> but I can retry today
15:24:31 <ihrachys> ok. it's one of those cases that is very expensive to debug in gate.
15:25:13 <electrocucaracha> agree
15:26:32 <korzen> the problem with subnet/network/port OVOs would be the extensions, I hoped that enginefacade work will help with detached db_obj, but it is not so simple, I need to add the db_obj to session in make_subnet_dict and detach it again after extension is done adding its db stuff
15:28:18 <ihrachys> korzen: as long as they pre-fetch their relationships on fetch, isn't it enough for them to get access to them?
15:28:33 <ihrachys> even while the db_obj may be detached?
15:29:04 <korzen> ihrachys, yes, all extensions need to be pre-fetched, because db_obj won't be able to do any feching
15:29:46 <korzen> I guess with current implementation of extensions, we need to register it somehow
15:29:59 <korzen> and do the prefetching
15:30:14 <ihrachys> isn't it done with lazy= directive in db model?
15:30:29 <korzen> yes, lazy should work
15:31:35 <korzen> so I guess every extension should define its db relationship with lazy joined
15:32:06 <ihrachys> maybe not joined, see https://review.openstack.org/#/c/408143/
15:32:31 <ihrachys> but the premise is the same - their models may require some tweaking to pre-fetch data
15:32:52 <ihrachys> which should also help keeping the number of queries to fetch a resource at constant.
15:33:44 <korzen> yes
15:34:05 <korzen> btw, electrocucaracha are you going to PTG?
15:34:16 <electrocucaracha> Nope :(
15:34:24 <korzen> :(
15:34:26 <electrocucaracha> actually I was checking the neutron agenda
15:34:34 <electrocucaracha> https://etherpad.openstack.org/p/neutron-ptg-pike
15:34:55 <electrocucaracha> it seems like neutron upgrades will be covered by your topics korzen right?
15:35:20 <korzen> yes, I wanted to setup the goals for Pike
15:35:38 <korzen> if not at wide audience, at least at upgrades subteam forum
15:36:17 <electrocucaracha> in terms of scope, how can we make to complete it in pike
15:36:19 <electrocucaracha> ?
15:37:11 <korzen> by our hard work ;)
15:37:24 <electrocucaracha> :)
15:37:31 <korzen> what do you mean exactly?
15:38:17 <electrocucaracha> well, OSIC is so interested in enable Neutron upgrades in Pike, so if it's needed more resources or something else
15:38:31 <electrocucaracha> maybe we can help somehow
15:39:14 <korzen> we will groom the efforts and tasks to do, and we will start doing it :)
15:39:14 <electrocucaracha> the good news is that we have a lot of progress in many ongoing patches the bad news is that they're on progress
15:39:22 <ihrachys> neutron upgrades is a vague term. which specific use cases do you consider? if that's mixed api versions coverage in gate, that's I believe something that we will need people looking at and sync with other projects.
15:39:44 <ihrachys> in the meantime, korzen was planning to test it manually for Ocata
15:40:44 <korzen> I think that online data migration is the critical piece we are missing to support zero-downtime upgrades
15:40:59 <electrocucaracha> yeah, maybe it should be better to define the scope and be realistic on the things that we can accomplish
15:41:12 <electrocucaracha> this seems more like cathedral model instead of bazaar
15:42:35 <electrocucaracha> this is something that we can't discuss in 18 minutes, but at least I'd like to consider it in the agenda of PTG
15:42:37 <ihrachys> korzen: that would assume that you have a valid case to cover with data migration rules. so far we did not have one. maybe live migration will give us one. I am all for working on framework for that, but do we grasp what will need to be done right now so that we can start?
15:42:41 <korzen> ihrachys, do you know the exact schedule for the PTG? or are there any free spot to create upgrade subteam meeting before we go to the neutron team>?
15:43:33 <ihrachys> korzen: afaiu ptg is not a single stream event, it's more like multiple groups running with their ideas in smaller groups. so we should be able to sync on spot.
15:44:17 <electrocucaracha> korzen ihrachys : dasanind will be there to also representing OSIC, just try to involve her in the discussions
15:44:46 <korzen> ok, I will work on the agenda
15:44:50 <ihrachys> gotcha
15:45:19 <dasanind> electrocucaracha: thank you
15:45:51 <ihrachys> #action korzen to work on PTG upgrades agenda
15:46:02 <dasanind> korzen: and ihrachys : all the meetings in PTG are in one room?
15:46:27 <ihrachys> korzen: I believe it's like a room with multiple tables. honestly it's first PTG so we may need to check.
15:46:55 <ihrachys> korzen: anyway, my question on the strategy for data migration from above is still up. what do you think on how to make progress without a use case? come up with a fake one?
15:48:03 <korzen> ihrachys, I'm planning to take a look at nova's and cinder's way of completing this action. I have a feeling that the framework should be done before (or at least in parallel) to actual first usage of it
15:48:49 <ihrachys> I agree with the goal
15:48:49 <korzen> if some would need to do the data migration, he/she would be blocked because of non existing framework
15:49:22 <electrocucaracha> +1
15:49:39 <korzen> I will update the team upfront after initial research
15:49:51 <korzen> if the online data migration is critical
15:50:49 <ihrachys> ack
15:50:51 <ihrachys> thanks
15:51:01 <korzen> I'm not so keen on API versioning, but I guess that there will be a separate discussion on the API future
15:51:24 <korzen> and the upgrades use-case can be a addition to such discussion
15:52:03 <reedip_> ihrachys : do we have an etherpad for the ptg ?
15:52:15 <ihrachys> reedip_: https://etherpad.openstack.org/p/neutron-ptg-pike
15:52:40 <ihrachys> korzen: yes api seems to be a hot potato right now
15:53:50 <ihrachys> ok, let's move one
15:54:16 <ihrachys> I don't see any motion on patches with UpgradeImpact tag, so skipping the section
15:54:23 <ihrachys> #topic Open discussio
15:54:25 <ihrachys> #topic Open discussion
15:54:44 <ihrachys> the list on the agenda page is empty as usual
15:54:59 <ihrachys> unless we have something on spot to raise...
15:55:27 <electrocucaracha> hehehe, well we started the open discussion before
15:55:34 <electrocucaracha> talking about PTG
15:55:37 <ihrachys> kinda yes
15:55:41 <korzen> sorry about that ;)
15:56:18 <ihrachys> ok if there is nothing to raise at this point, I call it a day. thanks folks.
15:56:19 <korzen> no other opens from me
15:56:25 <ihrachys> #endmeeting