16:02:26 #startmeeting networking_ml2 16:02:26 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:31 The meeting name has been set to 'networking_ml2' 16:02:39 hi! 16:02:56 hi brianstajkowski 16:03:00 hey andreas_s 16:03:10 #topic: Agenda 16:03:17 #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_November_16.2C_2016 16:03:58 #topic: Announcements 16:04:18 I am using the agenda from the last week - 16:04:36 Anybody has any announcements? 16:04:53 none here 16:04:55 I missed neutron core meeting this week - any update from it 16:06:02 I wasn’t there and haven’t looked at the log 16:06:32 #topic: RFEs/Bugs 16:07:23 Port binding info for nova migration - 16:07:31 yeah 16:07:44 i've taken over spec work on this from andreas_s 16:07:45 I want to introduce you guys to brianstajkowski 16:07:50 :) 16:07:53 jinx 16:07:59 brianstajkowski : welcome 16:08:29 hi brianstajkowski! 16:08:43 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 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 while we hammer out the nitty gritty of the spec and merge it 16:09:42 cool 16:09:52 question though 16:10:11 are we set on merging the portbinding and ditributedportbinding tables? 16:10:58 meaning, are we set on the name of the table distributedportbinding at this point? should it be called something entirely different? 16:11:47 I don't think that merging those tables is a requirement 16:11:55 it was just one possibility 16:12:04 yes understood 16:12:10 brianstajkowski: Interested in your recommendations on both those 16:12:53 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 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 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 brianstajkowski: makes sense 16:14:37 that's all I had on this 16:14:47 brianstajkowski, the other point is, that in ocata you are not allowed to do any contract operations 16:14:57 yea i heard this as well 16:15:38 i don't want that to influence a good direction once chosen though 16:15:49 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 yes, not a problem, was it in regard to ovo? 16:17:07 that also plays a role. OVO is the enabler for upgrades without downtime 16:17:30 and due to the update without downtime thing contract operations are not allowed anymore 16:17:50 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 rkukura, exactly 16:18:30 So contract migrations will be allowed later, just not in ocata? 16:19:07 rkukura, they will only be allowed to cleanup schema changes that happend N-2 release in the past (or so) 16:19:21 ok 16:19:31 not sure about the N-2 here 16:20:03 what is so specific about N-2? 16:20:33 i guess just a cutoff date 16:21:04 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 I don't know the details - there is spec out there 16:21:52 #link https://review.openstack.org/386685 16:22:48 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 brianstajkowski, nice! 16:23:11 brianstajkowski : which company do you work for? 16:23:41 rackspace, i manage the intel/rackspace portion for neutron 16:23:53 nice 16:24:08 brianstajkowski, osic, right? 16:24:12 osic yes 16:25:13 rkukura | So contract migrations will be allowed later, just not in ocata? 16:25:27 rkukura: afair, contract is not allowed at all. and won't be reintroduced 16:25:38 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 brianstajkowski, I think it makes sense to keep them for the beginning 16:26:10 dasm, ok 16:26:15 andreas_s +1 16:26:23 agree andreas_s 16:26:38 dasm: any details on this? 16:26:48 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 brianstajkowski: currently looking for source 16:27:01 k 16:27:07 but we need an expert here I guess. haven't seen ihar around.. 16:27:27 andreas_s: general idea is to disallow contract and allow just for expand transactions. so cleanup happens after N+2 16:27:50 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 dasm: Isn’t that cleanup after N+2 a contract migration? 16:27:55 brianstajkowski, so my point is, if you merge those tables - will it be easily possible to distinguish normal and distributed binding? 16:28:08 rkukura: yes 16:28:36 andreas_s: that's the main point, seems like the table then becomes something entirely different 16:28:46 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 dasm, got it 16:29:38 andreas_s: but in this case it seems easier to just alter the portbinding table 16:29:44 dasm, thanks for clarifying! 16:29:50 ty dasm ! 16:29:50 andreas_s: np 16:30:30 brianstajkowski, yep, probably extend the PK to include the host attribute and add the status column or so 16:30:53 +1 16:30:59 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 rkukura: someday, does it makes sense to do it now though is the question 16:32:10 I meant “both the DB schema and the logic” 16:32:17 ah ok 16:32:31 db is simple :) logic is challenging I guess... 16:32:38 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 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 dasanind_: That was my goal when I was working on this a long time ago, but I’m not sure now 16:34:01 oh ok 16:34:02 might be a good first step before we combine 16:34:47 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 brianstajkowski, dasanind_ maybe we could start aligning the columns of the portbinding table to the distributed table? 16:35:34 possible yes 16:35:40 i'll see what we can do 16:35:59 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 andreas_s: that's a good starting point 16:36:09 brianstajkowski: sounds good 16:36:14 perfect ty all 16:37:15 I guess the thing with the "active" is a real ting - also dvr uses this 16:37:47 right - be sure to run it by them - perhaps swami 16:38:22 anything else on this topic? 16:38:28 nothing here 16:38:37 not from me 16:38:49 cool - thanks 16:39:09 andreas_s : shall we move on to next topic? 16:39:17 andreas_s, yes 16:39:21 please 16:39:53 #topic: Driver API - request for feaatures 16:40:14 So, I see two bugs - 16:40:25 one is unassigned 16:41:35 rkukura : no body updated the bug after your comments 16:42:18 I see 16:42:34 there seems to be no taker for this 16:44:12 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 Is there anybody here who has any update/status for either one of these two bugs/requests 16:44:50 rkukura : yes, I believe so 16:45:04 nope 16:45:30 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 My 2nd comment about enforcment of extension semantics in port binding should probably be addressed (or not) separately from this bug. 16:49:11 looking at the dates - I see no action on this for a while (almost 5 months) 16:51:10 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 rkukura : OK 16:52:47 for the second bug, there is a patch 16:52:57 I reviewed it while back and looked good to me 16:53:24 I hadn’t seen that one, but just added that to me list to review 16:54:18 cool - 16:54:29 I do not have anything else 16:54:39 #topic Open Discussion 16:54:56 Anybody wants to discuss anything additional? 16:55:42 Who is planning to attend the PTG in Atlanta? 16:57:58 rkukura : there is your answer :-) 16:58:14 Looks like we are done 16:58:18 Thanks folks 16:58:29 thanks Sukhdev_! 16:58:32 #endmeeting