16:02:26 <Sukhdev_> #startmeeting networking_ml2
16:02:26 <openstack> Meeting started Wed Nov 16 16:02:26 2016 UTC and is due to finish in 60 minutes.  The chair is Sukhdev_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:31 <openstack> The meeting name has been set to 'networking_ml2'
16:02:39 <brianstajkowski> hi!
16:02:56 <andreas_s> hi brianstajkowski
16:03:00 <brianstajkowski> hey andreas_s
16:03:10 <Sukhdev_> #topic: Agenda
16:03:17 <Sukhdev_> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_November_16.2C_2016
16:03:58 <Sukhdev_> #topic: Announcements
16:04:18 <Sukhdev_> I am using the agenda from the last week -
16:04:36 <Sukhdev_> Anybody has any announcements?
16:04:53 <rkukura> none here
16:04:55 <Sukhdev_> I missed neutron core meeting this week - any update from it
16:06:02 <rkukura> I wasn’t there and haven’t looked at the log
16:06:32 <Sukhdev_> #topic: RFEs/Bugs
16:07:23 <Sukhdev_> Port binding info for nova migration -
16:07:31 <andreas_s> yeah
16:07:44 <brianstajkowski> i've taken over spec work on this from andreas_s
16:07:45 <andreas_s> I want to introduce you guys to brianstajkowski
16:07:50 <andreas_s> :)
16:07:53 <brianstajkowski> jinx
16:07:59 <Sukhdev_> brianstajkowski : welcome
16:08:29 <rkukura> hi brianstajkowski!
16:08:43 <brianstajkowski> main point on this is I hope to have the wip tag off by friday or next monday, just rolling through ml2 changes db sections
16:09:05 <brianstajkowski> shortly after that, on our team we have a dev lined up to quickly get a wip patch up for nova to begin work
16:09:31 <brianstajkowski> while we hammer out the nitty gritty of the spec and merge it
16:09:42 <andreas_s> cool
16:09:52 <brianstajkowski> question though
16:10:11 <brianstajkowski> are we set on merging the portbinding and ditributedportbinding tables?
16:10:58 <brianstajkowski> meaning, are we set on the name of the table distributedportbinding at this point? should it be called something entirely different?
16:11:47 <andreas_s> I don't think that merging those tables is a requirement
16:11:55 <andreas_s> it was just one possibility
16:12:04 <brianstajkowski> yes understood
16:12:10 <rkukura> brianstajkowski: Interested in your recommendations on both those
16:12:53 <rkukura> Way back, I was advocating simply making a non-distributed port binding a special case of a potenatially distributed port binding, but not sure how things have evolved since then
16:13:48 <brianstajkowski> if we merge them we can toss around what it can be changed to if it is, or just alter the portbinding table
16:14:04 <brianstajkowski> i guess there's no hard opinions, i'll throw it in the spec and we can work it out that way then
16:14:19 <rkukura> brianstajkowski: makes sense
16:14:37 <brianstajkowski> that's all I had on this
16:14:47 <andreas_s> brianstajkowski, the other point is, that in ocata you are not allowed to do any contract operations
16:14:57 <brianstajkowski> yea i heard this as well
16:15:38 <brianstajkowski> i don't want that to influence a good direction once chosen though
16:15:49 <andreas_s> brianstajkowski, so when moving data we need to do a lot of things to make that happen. Ihar and I guess korzen wanted to work with me on that
16:16:34 <brianstajkowski> yes, not a problem, was it in regard to ovo?
16:17:07 <andreas_s> that also plays a role. OVO is the enabler for upgrades without downtime
16:17:30 <andreas_s> and due to the update without downtime thing contract operations are not allowed anymore
16:17:50 <rkukura> Is the idea that an OVO would maintain both the old and new tables for some period of time, and later a contract migration would remove the old table?
16:18:06 <andreas_s> rkukura, exactly
16:18:30 <rkukura> So contract migrations will be allowed later, just not in ocata?
16:19:07 <andreas_s> rkukura, they will only be allowed to cleanup schema changes that happend N-2 release in the past (or so)
16:19:21 <rkukura> ok
16:19:31 <andreas_s> not sure about the N-2 here
16:20:03 <Sukhdev_> what is so specific about N-2?
16:20:33 <Sukhdev_> i guess just a cutoff date
16:21:04 <rkukura> If this to give time for all components to be udpate - my view is this could be minutes or hours rather than years
16:21:28 <andreas_s> I don't know the details - there is spec out there
16:21:52 <andreas_s> #link https://review.openstack.org/386685
16:22:48 <brianstajkowski> most of our team is working ovo, i can reach out for specifics there and figure out what our restrictions will be
16:23:03 <andreas_s> brianstajkowski, nice!
16:23:11 <Sukhdev_> brianstajkowski : which company do you work for?
16:23:41 <brianstajkowski> rackspace, i manage the intel/rackspace portion for neutron
16:23:53 <Sukhdev_> nice
16:24:08 <andreas_s> brianstajkowski, osic, right?
16:24:12 <brianstajkowski> osic yes
16:25:13 <dasm> rkukura | So contract migrations will be allowed later, just not in ocata?
16:25:27 <dasm> rkukura: afair, contract is not allowed at all. and won't be reintroduced
16:25:38 <andreas_s> brianstajkowski, the other thing is, there are "2 parallel threads" in the ml2 code, one for distributed binding and one for normal binding
16:25:54 <andreas_s> brianstajkowski, I think it makes sense to keep them for the beginning
16:26:10 <andreas_s> dasm, ok
16:26:15 <Sukhdev_> andreas_s +1
16:26:23 <brianstajkowski> agree andreas_s
16:26:38 <brianstajkowski> dasm: any details on this?
16:26:48 <andreas_s> dasm, so what I understood is that at some point in the future you should be able to cleanup the old tables/columns that are not required anymore
16:26:57 <dasm> brianstajkowski: currently looking for source
16:27:01 <brianstajkowski> k
16:27:07 <andreas_s> but we need an expert here I guess. haven't seen ihar around..
16:27:27 <dasm> andreas_s: general idea is to disallow contract and allow just for expand transactions. so cleanup happens after N+2
16:27:50 <dasm> N release introduces new column, N+1 syncs both columns new and old, N+2 drops old column, when all data is migrated/synced
16:27:54 <rkukura> dasm: Isn’t that cleanup after N+2 a contract migration?
16:27:55 <andreas_s> brianstajkowski, so my point is, if you merge those tables - will it be easily possible to distinguish normal and distributed binding?
16:28:08 <dasm> rkukura: yes
16:28:36 <brianstajkowski> andreas_s: that's the main point, seems like the table then becomes something entirely different
16:28:46 <dasm> rkukura: andreas_s brianstajkowski this should behave similar to cinder use-case: http://docs.openstack.org/developer/cinder/devref/rolling.upgrades.html#alter-on-a-column
16:29:33 <andreas_s> dasm, got it
16:29:38 <brianstajkowski> andreas_s: but in this case it seems easier to just alter the portbinding table
16:29:44 <andreas_s> dasm, thanks for clarifying!
16:29:50 <brianstajkowski> ty dasm !
16:29:50 <dasm> andreas_s: np
16:30:30 <andreas_s> brianstajkowski, yep, probably extend the PK to include the host attribute and add the status column or so
16:30:53 <brianstajkowski> +1
16:30:59 <rkukura> brianstajkowski, andreas_s: Way back when I was working on portbinding, my plan was to unify both the DB and the schema
16:31:58 <brianstajkowski> rkukura: someday, does it makes sense to do it now though is the question
16:32:10 <rkukura> I meant “both the DB schema and the logic”
16:32:17 <brianstajkowski> ah ok
16:32:31 <andreas_s> db is simple :) logic is challenging I guess...
16:32:38 <dasanind_> andreas_s, brianstajkowski, rkukura:  Does that mean the proposal is to have only one port binding table to handle both the distributed and normal port binding?
16:33:22 <brianstajkowski> dasanind_: well initially that was a part of the spec, i think we are deciding now on just altering the portbinding table to accomodate multiple bindings and add a status column
16:33:27 <rkukura> dasanind_: That was my goal when I was working on this a long time ago, but I’m not sure now
16:34:01 <dasanind_> oh ok
16:34:02 <brianstajkowski> might be a good first step before we combine
16:34:47 <andreas_s> rkukura, dasanind_, I guess that's the big vision - and it still would make sense - cause the code is really hard to understand with that 2 parallel threads.. But this is a huge change - probably very risky
16:35:19 <andreas_s> brianstajkowski, dasanind_ maybe we could start aligning the columns of the portbinding table to the distributed table?
16:35:34 <brianstajkowski> possible yes
16:35:40 <brianstajkowski> i'll see what we can do
16:35:59 <andreas_s> if they use the same columns and the values are designed in a way that they are compatible (e.g. status "active" does not have 2 meanings") then this would be a first step
16:36:01 <dasanind_> andreas_s: that's a good starting point
16:36:09 <rkukura> brianstajkowski: sounds good
16:36:14 <brianstajkowski> perfect ty all
16:37:15 <andreas_s> I guess the thing with the "active" is a real ting - also dvr uses this
16:37:47 <Sukhdev_> right - be sure to run it by them - perhaps swami
16:38:22 <Sukhdev_> anything else on this topic?
16:38:28 <brianstajkowski> nothing here
16:38:37 <rkukura> not from me
16:38:49 <Sukhdev_> cool - thanks
16:39:09 <Sukhdev_> andreas_s : shall we move on to next topic?
16:39:17 <andreas_s> andreas_s, yes
16:39:21 <andreas_s> please
16:39:53 <Sukhdev_> #topic: Driver API - request for feaatures
16:40:14 <Sukhdev_> So, I see two bugs -
16:40:25 <Sukhdev_> one is unassigned
16:41:35 <Sukhdev_> rkukura : no body updated the bug after your comments
16:42:18 <rkukura> I see
16:42:34 <Sukhdev_> there seems to be no taker for this
16:44:12 <rkukura> I’m pretty sure the exensions that are packaged as extension drivers show up if and only if those extension drivers are configured, right?
16:44:16 <Sukhdev_> Is there anybody here who has any update/status for either one of these two bugs/requests
16:44:50 <Sukhdev_> rkukura : yes, I believe so
16:45:04 <andreas_s> nope
16:45:30 <rkukura> So this issue is really that we might want to not advertize extensions mixed-into the ML2 plugin itself when none of the configured mechanism drivers are able to support them
16:46:32 <rkukura> My 2nd comment about enforcment of extension semantics in port binding should probably be addressed (or not) separately from this bug.
16:49:11 <Sukhdev_> looking at the dates - I see no action on this for a while (almost 5 months)
16:51:10 <rkukura> Sukhdev_: I don’t think anyone is working on the extension advertizement bug, but I don’t think we should close it as won’t fix
16:52:02 <Sukhdev_> rkukura : OK
16:52:47 <Sukhdev_> for the second bug, there is a patch
16:52:57 <Sukhdev_> I reviewed it while back and looked good to me
16:53:24 <rkukura> I hadn’t seen that one, but just added that to me list to review
16:54:18 <Sukhdev_> cool -
16:54:29 <Sukhdev_> I do not have anything else
16:54:39 <Sukhdev_> #topic Open Discussion
16:54:56 <Sukhdev_> Anybody wants to discuss anything additional?
16:55:42 <rkukura> Who is planning to attend the PTG in Atlanta?
16:57:58 <Sukhdev_> rkukura : there is your answer :-)
16:58:14 <Sukhdev_> Looks like we are done
16:58:18 <Sukhdev_> Thanks folks
16:58:29 <rkukura> thanks Sukhdev_!
16:58:32 <Sukhdev_> #endmeeting