16:02:21 <rkukura> #startmeeting networking_ml2
16:02:23 <openstack> Meeting started Wed Jun 15 16:02:21 2016 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:26 <openstack> The meeting name has been set to 'networking_ml2'
16:02:36 <rkukura> #topic Agenda
16:02:46 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_June_15.2C_2016
16:03:44 <rkukura> so we have some discussion that I think andreas_s_ added
16:04:02 <andreas_s_> rkukura, yes
16:04:52 <rkukura> Does anyone want to add anything?
16:07:22 <rkukura> #topic Announcements
16:07:31 <rkukura> I don’t have any announcements - anyone else?
16:08:09 <rkukura> ok, lets move on...
16:08:22 <rkukura> #topic Distributed port bindings
16:08:35 <rkukura> andreas_s_: Do you want to introduce this?
16:08:40 <andreas_s_> sure
16:09:11 <andreas_s_> I uploaded a patchset that starts to unify the dvr_portbinding and the normal portbinding tables
16:09:27 <andreas_s_> to make a normal binding just a special case of a distributed binding with just one host
16:09:38 <andreas_s_> this is based on rkukura work from last year
16:09:46 <andreas_s_> #link https://review.openstack.org/#/c/326987
16:10:00 <andreas_s_> Now I need some guidance how to continue
16:10:13 <andreas_s_> First of all: Is this the right approach?
16:10:41 <andreas_s_> Cause there's another patchset flying around renaming the dvr_portbinding table to a distributed_portbinding table, which does somehting similar
16:11:06 <andreas_s_> #link  https://review.openstack.org/#/c/323993
16:11:20 <rkukura> I think andreas_s_’s patch set does a lot more than simple renaming
16:11:37 <andreas_s_> those are not yet conflicting, but in the final stage they will
16:12:06 <rkukura> It basically makes distributed bindings and non-distributed bindings use the same DB schema, with non-distributed a special case of distributed
16:12:53 <andreas_s_> the alternative would be that we could come up with a patchset that moves all normal bindings into the renamed distributed bindig table
16:13:57 <rkukura> andreas_s_: Doesn’t your patch set do this in the migration?
16:14:10 <rkukura> I think I had addressed that way back, but that was before the expand/contract stuff
16:14:15 <Sukhdev> andreas_s_ : what use case are you trying to address with this?
16:14:45 <andreas_s_> Sukhdev, cleanup of db and code
16:15:08 <andreas_s_> Sukhdev, and this is the groundwork to get distributed compute ports one day
16:15:42 <rkukura> andreas_s_: Isn’t it also a step towards using distributed bindings for other services, such as DHCP, HA, as well as improving VM migration?
16:15:43 <Sukhdev> andreas_s_ : Ah I get it - I was reviewing your spec and was trying to find the connection -
16:16:14 <Sukhdev> right
16:16:20 <andreas_s_> rkukura, yes, it is! But it's the same with the other patchset flying around
16:16:55 <andreas_s_> with the other approach we might end up in removing the portbinding table at all, and store everything in the distributed portbinding table
16:17:03 <rkukura> andreas_s_: I may be missing something, but that other patchset just renames tables, doesn’t it? I think more work would be needed in either case.
16:17:50 <andreas_s_> rkukura, yes, it does just a rename. But follow up patchsets already implement a distributed binding for router ha ports
16:17:58 <andreas_s_> it's a series of patches
16:18:12 <rkukura> I have not seen the followup patches, so I need to look those over
16:18:27 <andreas_s_> ok
16:19:17 <andreas_s_> rkukura, Sukhdev, I think some guidance form you guys is required here, as doing both in parralel does not make much sense I guess
16:19:58 <andreas_s_> as mentioned before, I could also just make a patch, that moves everything from the ml2_portbinding table into the dvr_binding table
16:20:06 <rkukura> I certainly have my own view on how this would best work (basically, my start that andreas_s_ has picked up), but I defer to those willing to do the work. Could we get some discussion going between all the parties on this?
16:21:39 <Sukhdev> rkukura : what is the best way to accomplish that discussion?
16:22:08 <rkukura> Venkata Anil isn’t on this meeting, it he?
16:22:36 <andreas_s_> no, he's not online anymore
16:22:40 <Sukhdev> I do not his IRC handle
16:23:08 <Sukhdev> looks like he has done quite a bit of work on these patches as well
16:24:55 <yamamoto> Sukhdev: anilvenkata
16:25:15 <Sukhdev> yamamoto : thanks
16:25:35 <Sukhdev> right he is not online at the moment
16:26:06 <rkukura> andreas_s_: As someone currently investing time in this with specific goals, do you feel the other patches accomplish your goals?
16:27:16 <andreas_s_> rkukura, yes, I think so cause we both have the same goal in the end - add a distributed port
16:27:34 <andreas_s_> he wants to make a routher ha port distributed, I want to make a normal port distributed
16:27:46 <rkukura> I’m pretty sure I had previously discussed my approach with anilvenkata, but I think he gave up waiting for me, and wasn’t aware andreas_s_ was working on this
16:28:23 <andreas_s_> rkukura, I think the challenge with his patches is, that he doesn't build a clean relationship between port and binding
16:28:27 <rkukura> So do his patches end up with still having two separate schemas for distributed and non-distributed bindings?
16:28:40 <andreas_s_> rkukura, things like vnic_type seem to be stored duplicated for each binding
16:28:49 <andreas_s_> but I need to verify that in the db
16:29:10 <andreas_s_> rkukura, yes
16:29:12 <rkukura> If so, then it seems that approach isn’t going to help with migration where normal bindings become distributed for a short period of time and the normal again
16:29:34 <andreas_s_> rkukura, my point of view is, that every port is a distributed port
16:29:46 <rkukura> andreas_s_: That’s mine too
16:29:54 <andreas_s_> rkukura, the special thing with a normal port is just, that there's only one binding for it
16:30:04 <rkukura> But I don’t think anilvenkata’s patches get us to that point
16:30:18 <andreas_s_> rkukura, no, cause that's not his scope
16:30:27 <andreas_s_> rkukura, so you're right
16:30:33 <rkukura> And we really need to review carefully what port attributes are host-specific
16:30:51 <andreas_s_> the work that still would need to be done on top of his changes is moving the normal port stuff to that renamed table
16:32:16 <rkukura> As an asside, I really would have hoped that these weekly ML2 IRC sub-team meetings would have been a forum where these sorts of ML2 changes had been discussed before anyone invested a lot of effort in one particular approach.
16:32:47 <Sukhdev> rkukura :+1
16:32:52 <yamamoto> rkukura: +1
16:33:13 <Sukhdev> rkukura : I am going to put this on neutron core team meeting's agenda and bring it up there
16:33:25 <rkukura> Sukhdev: I think that is a good idea
16:33:53 <Sukhdev> andreas_s_, rkukura: so, listening to your comments - two thoughts come to mind
16:34:34 <rkukura> But in the mean time, would an openstack-dev thread make sense on these two specific patchsets and approaches? Or should we try to get some sort of meeting organized to discuss the way forward?
16:35:04 <Sukhdev> 1) is there a way to work with venkata's patch and make appropriate modifiactions to achieve the same goal, and
16:35:34 <Sukhdev> 2) anything that is not covered by his patch to address as additional patch
16:36:19 <andreas_s_> rkukura, still thinking what would be best..
16:37:23 <rkukura> I added comments to two of his patches suggesting we coordinate these efforts. I had thought I had done this of the first one previously, but didn’t see it.
16:37:39 <yamamoto> is this meeting difficult for anilvenkata?
16:37:46 <andreas_s_> rkukura, I saw it..
16:38:06 <andreas_s_> yamamoto, I guess he's located somewhere in Aisa
16:38:09 <andreas_s_> Asia
16:39:04 <rkukura> One point that hasn’t been mentioned is the relationship between these sorts of changes and the move to versioned objects
16:39:38 <andreas_s_> rkukura, right I think this is not a big deal when introducing a new object like the binding_result
16:39:58 <andreas_s_> rkukura, I just read in some document that new objects are only accepted as OVOs...
16:40:12 <andreas_s_> that's why I planned to make it an OVO in one of the next iterations
16:40:20 <andreas_s_> but I wanted to have all the tests passing first
16:40:27 <rkukura> As carl_baldwin pointed out on the review, with OVO, its supposed to be possible to run new code without doing migrations first, making table renames and significant schema modification much more difficult
16:40:48 <rkukura> andreas_s_: had also inidicated on his patch that it needed to address OVO
16:40:54 <andreas_s_> Sukhdev, I agree to your two points - that's something I could have a look at tomorrow
16:41:02 <carl_baldwin> rkukura: Specifically contract migrations.
16:41:25 <carl_baldwin> rkukura: "expand" migrations can be run before new code is run.
16:42:00 <rkukura> carl_baldwin: What about migrations that involve merging two exisitng tables into a different set of new or modified tables?
16:43:24 <carl_baldwin> rkukura: As I understand it, the new tables can be created and populated with data using an expand migration.  The old tables cannot be removed until the contract migrations are run.
16:44:26 <carl_baldwin> rkukura: to go much deeper, we'd have to get someone like HenryG, ihrachys, or rossella_s to help us out.
16:44:29 <rkukura> carl_baldwin: I think we will need to look at schema changes from andreas_s_’s patch set (which I had started a long time ago) and see how that maps to expand/contract
16:45:12 <rkukura> But the point is, if we are ever going to make these sorts of schema changes, I think it makes sense to do them before the adoption of OVO for these tables.
16:45:27 <carl_baldwin> rkukura: I think that eventually, writes will go to both the old schema and the new schema at the same time for a period of time.  So, the two cannot conflict.
16:46:05 <carl_baldwin> rkukura: If you've got some schema changes in mind, it might be wise to get them in sooner than later.  And, hopefully get them as right as possible.
16:46:27 <rkukura> carl_baldwin: +1
16:46:45 <rkukura> We have 14 minutes left, so should move ahead on the agenda
16:46:54 <rkukura> Anything else on this for today?
16:46:55 <carl_baldwin> rkukura: But, schema changes will always happen.  There will just be a new set of stricter rules.
16:47:35 <rkukura> #topic Driver API feature requests
16:47:52 <rkukura> These are on the agenda under open discussion
16:47:52 <yamamoto> i put it
16:48:11 <rkukura> yamamoto: thanks - want to explain?
16:48:27 <yamamoto> i just wanted to raise attention here about these possible driver api changes
16:48:49 <rkukura> I glanced at a couple of them - should we go over these in more detail next week
16:48:50 <rkukura> ?
16:48:55 <yamamoto> sure
16:48:59 <Sukhdev> yamamoto : I reviewed them all and in some cases put comments on them
16:49:10 <yamamoto> Sukhdev: thank you
16:49:34 <Sukhdev> yamamoto : we can go through them one at a time
16:49:49 <rkukura> I will file an RFE for letting MDs and EDs handle all the new core resources, which I’ve been promising for a while
16:50:39 <rkukura> Sukhdev: Are you proposing to go through them now, or next week?
16:51:03 <Sukhdev> rkukura : we are short on time today  - perhaps tomorrow
16:51:25 <Sukhdev> we have enough time to go over this - https://review.openstack.org/#/c/320657/1/neutron/db/ipam_backend_mixin.py
16:51:34 <Sukhdev> this is also on the agenda
16:51:44 <rkukura> Sukhdev: right - I was just looking at that one now
16:52:04 <Sukhdev> I posted comment on this patch and asked them to proceed with it and merge
16:52:11 <Sukhdev> this patch is by carl_baldwin
16:52:11 <rkukura> I’m not sure what “generic plugin” or “common port binding implementation” refer to
16:52:43 <Sukhdev> but, the crux of the issue is binding: host id being used as None vs ''
16:52:55 <Sukhdev> s/''/' '
16:53:44 <rkukura> That is a minor detail that should be straightforward to change
16:53:45 <Sukhdev> I did not think they should hold off their work because of this - so, carl_baldwin's patch is merged - but, we can discuss the issue here
16:54:21 <Sukhdev> rkukura : right, I felt the same
16:54:49 <rkukura> I’m still not sure what “generic plugin” refers to
16:55:00 <rkukura> Is this just the DB layer?
16:55:21 <Sukhdev> carl_baldwin is here - lets ask him
16:55:31 <rkukura> carl_baldwin: ?
16:55:35 <carl_baldwin> rkukura: By "common port binding implementation" I just meant neutron.db.portbindings_db
16:56:05 <rkukura> OK, I don’t think ML2 uses that, or intends to
16:56:08 <carl_baldwin> rkukura: By generic plugin, I just meant SegmentTestPlugin created in https://review.openstack.org/#/c/320657/8/neutron/tests/unit/extensions/test_segment.py
16:56:23 <carl_baldwin> rkukura: That's fine.  I was trying to point out the difference in the two.
16:56:28 <rkukura> OK
16:56:38 <carl_baldwin> It isn't a big deal.  I just brought it up since rossella_s asked about it.
16:56:52 <carl_baldwin> rkukura: Hope that clears things up.
16:56:58 <rkukura> Is it worth filing a bug to unify None vs. ‘’ for the host_id?
16:57:34 <rkukura> Maybe that could be addressed as part of the patches reworking ML2’s port binding schema as discussed above
16:57:53 <rkukura> Anyway, thanks for clarifting this carl_baldwin and Sukhdev
16:58:05 <rkukura> #topic Open Discussion
16:58:27 <rkukura> Is there anything else anyone wants to discuss in our last two minutes?
16:58:42 <Sukhdev> rkukura : I think we are good
16:59:00 <rkukura> Thanks everyone!
16:59:03 <Sukhdev> yamamoto : lets move those items from open discussion to main agenda for next week
16:59:11 <yamamoto> Sukhdev: sure
16:59:15 <rkukura> +1
16:59:28 <rkukura> #endmeeting