16:03:35 <rkukura> #startmeeting networking_ml2
16:03:36 <openstack> Meeting started Wed Jun 29 16:03:35 2016 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:40 <openstack> The meeting name has been set to 'networking_ml2'
16:03:51 <rkukura> #topic Agenda
16:04:02 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_June_29.2C_2016
16:04:21 <rkukura> Fairly light agenda today - does anyone want to add anything?
16:04:31 <andreas_s_> I want to give a brief update on distributed portbinding for live migration
16:04:46 <andreas_s_> really brief :)
16:04:47 <rkukura> andreas_s_: I was going to ask you if you wanted to do that
16:05:04 <rkukura> lets do that just before the feature requests
16:05:16 <rkukura> anything else on the agenda?
16:05:42 <rkukura> #topic Announcements
16:05:53 <rkukura> I don’t have any announcements - does anyone else?
16:06:35 <rkukura> I have not been following the neutron IRC meetings the past couple weeks, so please let us know if there are immentant milestones we shoud be aware of
16:06:52 <rkukura> immenant, I think was the word
16:07:27 <rkukura> if not…
16:07:37 <andreas_s_> I don't remember anything urgent, but I'm also not a regular participant ;)
16:07:46 <rkukura> #topic Feature Requests
16:08:10 <rkukura> So there are 3 feature request bugs on the agenda that we wanted to discuss
16:08:27 <rkukura> #link https://bugs.launchpad.net/neutron/+bug/1583096
16:08:27 <openstack> Launchpad bug 1583096 in neutron "ml2 supported extensions list is inaccurate" [Medium,Confirmed]
16:08:57 <rkukura> I added my thoughts as a comment on this bug a little while ago
16:10:10 <yamamoto> a problem is the current ext-list can't express complex deployment like heterogeneous ones
16:10:27 <rkukura> In my view, the presence of mechanism drivers and their individual capabilities is not what should determine which API extensions the ML2 plugin supports, since different combination of drivers might support different sets of extensions. I think this is really the same issue we’ve discussed before about needing to enforce extension semantics.
16:11:20 <rkukura> I view the ext-list as expressing what the API supports, not necessarily what the set of drivers involved for some specific port might support.
16:12:54 <rkukura> Ideally, ML2 would use extension drivers for all of its extension implementations, and the admin could configure only those EDs that are applicable in that deployment, but it still might be heterogenous and have cases, like bare metal or SR-IOV where not all semantics are available for certain ports.
16:15:46 <rkukura> In my bug comment, I tried to describe an example of security groups with normal KVM+OVS, KVM+SR-IOV, and baremetal, and where a ToR switch MD might be able to enforce some SG rules, but not all.
16:16:16 <rkukura> Any other thoughts on this? Or should we just continue the discussion on the bug for now, and revisit it next week?
16:16:35 <andreas_s_> rkukura, so are you suggesting to mark it as invalid?
16:17:06 <andreas_s_> cause it sounds like there's no good solution...
16:17:23 <rkukura> andreas_s_: I do not think any one MD can determine whether or not any particular extension should be in the list
16:17:44 <rkukura> I have been proposing that port binding enforce extension value semantics
16:18:10 <andreas_s_> ok
16:18:37 <rkukura> But orthgonally to that, it might make sense to start packaging extensions as EDs so that the admin can decide which ones are applicable, and that this would allow the admin to control what is in the ext-list.
16:19:14 <rkukura> I will add another comment to the bug to try to capture that 2nd proposal as a partial solution.
16:19:29 <rkukura> Any other thoughts on this?
16:19:32 <yamamoto> rkukura: in your view tempest agent-extension test should be fixed?  it asserts dhcp-agent is running if the extension is expressed.
16:21:27 <rkukura> yamamoto: that sounds wrong to me - the tempest tests should not make any assumtions about how the API sematics are implemented
16:22:51 <yamamoto> rkukura: my opinion is agent-list returning an empty list is fine, esp. for api tests. but there are people who disagree.
16:24:22 <rkukura> It seems to me that more and more neutron backends are moving towards implementing things like DHCP, routing, etc., without using the reference agents for this.
16:24:46 <yamamoto> #link https://bugs.launchpad.net/tempest/+bug/1509590
16:24:46 <openstack> Launchpad bug 1509590 in tempest "some tests assume existance of some agents" [Undecided,Invalid] - Assigned to YAMAMOTO Takashi (yamamoto)
16:25:14 <rkukura> I guess tempest tests that are intended only for a specific reference implemantation could make those sorts of assumptions, but general tempest tests shoud not.
16:25:50 <rkukura> Any other discussion on this feature request right now, or should we move on?
16:26:03 <yamamoto> let's move on
16:26:37 <rkukura> #link https://bugs.launchpad.net/neutron/+bug/1587401
16:26:37 <openstack> Launchpad bug 1587401 in neutron "Helper method to change status of port to abnormal state is needed in ml2." [Wishlist,Confirmed]
16:28:42 <rkukura> I feel this is something worth addressing, and needs a good proposal that takes into account HPB and other scenarios with multiple MDs involved in the same resource.
16:29:50 <rkukura> ajo added a comment that also kind of gets to the extension semantic enforcement issue we were discussing above
16:30:28 <yamamoto> i was thinking to allow each MD to do context.set_status(ERROR) and the plugin accumulates them.
16:30:57 <ajo> in the qos context, it happens that sometimes you can't detect if a qos rule is not appliable to a port until you buind it
16:31:02 <ajo> bind it, sorry
16:31:15 <ajo> for example if you have ovs & sr-iov in the same deployment
16:31:18 <ajo> so...
16:31:43 <ajo> in that context it could make sense to let the port work, but mark it as abnormal (for example) but some extended information (why is it abnormal) could be interesting too
16:31:55 <ajo> (x-type of rule can't be applied to an sr-iov port)
16:32:07 <rkukura> At least in a bound port, the status seems like it should be determined by the set of MDs involved in its binding, so maybe the plugin should just query each of those drivers to obtain the status. If this is soming that changes dynamically, it has to happen during gets, not just when ports are created or updated.
16:33:23 <rkukura> ajo: see https://bugs.launchpad.net/neutron/+bug/1583096 for some related thoughts on enforcing semantics of extensions such as QoS during port binding.
16:33:23 <openstack> Launchpad bug 1583096 in neutron "ml2 supported extensions list is inaccurate" [Medium,Confirmed]
16:33:27 <rkukura> and afterward
16:34:31 <ajo> thanks rkukura will do
16:34:59 <rkukura> On https://bugs.launchpad.net/neutron/+bug/1587401, I think we need someone to work up a specific proposal, figuring out whether the status would be pushed or polled, etc., and maybe how to provide additional information.
16:34:59 <openstack> Launchpad bug 1587401 in neutron "Helper method to change status of port to abnormal state is needed in ml2." [Wishlist,Confirmed]
16:37:57 <rkukura> I guess we can leave this bug as confirmed but unassigned until someone decides to work on it.
16:38:07 <yamamoto> rkukura: do you think how it should be shown to api user?  as an aggregated status?
16:38:24 <yamamoto> or eg. a set of status?
16:38:42 <rkukura> yamamoto: I’m not sure.
16:39:25 <rkukura> I think the overall status needs to remain as-is in the API, but something with more detail could be added.
16:40:08 <rkukura> Ready to move on?
16:40:15 <yamamoto> yes
16:40:30 <rkukura> #link https://bugs.launchpad.net/neutron/+bug/1592238
16:40:30 <openstack> Launchpad bug 1592238 in neutron "[RFE] ml2: needs a way for MD to pass data from precommit to postcommit" [Wishlist,In progress] - Assigned to Li Ma (nick-ma-z)
16:42:01 <rkukura> I added some comments to the code review and the bug. I’m fine with the idea of adding a dict for this purpose, but would like to see it included in the driver_api.py abstract class so its clearly part of the official API.
16:42:28 <rkukura> Any other thoughts on this one?
16:42:52 <rkukura> And does anyone know Li Ma’s IRC handle?
16:43:18 <andreas_s_> no, don't know
16:43:54 <rkukura> Feel free to review the code and/or add comments to the bug.
16:44:22 <rkukura> oops - forgot to cover the distirbuted port binding status before the feature requests
16:44:34 <rkukura> #topic Distributed Port Binding Status
16:44:43 <rkukura> andreas_s_: Do you want to update us?
16:44:52 <andreas_s_> sure
16:45:05 <andreas_s_> so db patches are still WIP
16:45:23 <andreas_s_> I moved the code to ovo and got feedback that it looks good
16:45:45 <andreas_s_> now started working on the dvr parts
16:45:54 <rkukura> andreas_s_: I’d like to have a look at that - I’ve been kind of dubious about OVO for this sort of thing, and want to see how it works out
16:46:09 <yamamoto> rkukura: li ma's nick is nick-ma iirc
16:46:18 <rkukura> yamamoto: thanks
16:46:21 <andreas_s_> #link https://review.openstack.org/333218
16:46:28 <andreas_s_> rkukura, ^
16:46:45 <andreas_s_> that's the ovo on top of my original patch - will squash those 2 later on
16:47:08 <rkukura> andreas_s_: ok, will try to make sense of it in the mean time
16:47:21 <andreas_s_> I was attending the nova live migration meeting on tuesday
16:47:50 <andreas_s_> to discuss how nova could exploit the distributed ports for live migration
16:48:20 <andreas_s_> we put that topic on the agenda for the nova midcycle around 20th of July
16:48:49 <andreas_s_> so getting some technical feedback on the specs would be great
16:48:59 <andreas_s_> before that summit
16:49:04 <andreas_s_> *midcycle
16:49:17 <rkukura> andreas_s_: makes sense
16:49:22 <andreas_s_> #link https://review.openstack.org/309416
16:49:44 <rkukura> was the two sets of competing patches resolved by merging the rename patches first?
16:50:20 <andreas_s_> probably armax and carl_baldwin will attend and discuss it with nova folks there
16:50:28 <andreas_s_> rkukura, yeah the renaming patch landed
16:50:52 <rkukura> where is the mid-cycle?
16:51:05 <andreas_s_> I must admit I don't know
16:51:38 <andreas_s_> rkukura, Intel - Hillsboro, OR, USA
16:51:46 <rkukura> thanks
16:52:22 <rkukura> andreas_s_: thanks for the update - anything more before open discussion?
16:52:32 <andreas_s_> so if you have any serious doubts that the concept with live migration will not work out, please speak up :)
16:52:47 <andreas_s_> no
16:53:05 <rkukura> andreas_s_: Is this using OVO to do on-demand migration of the schema?
16:53:56 <yamamoto> on-line you mean?
16:54:03 <andreas_s_> rkukura, what do you mean with on-demand migration?
16:54:30 <andreas_s_> ah schema, so you're talking about the db
16:54:42 <andreas_s_> it's still using the alembic stuff.
16:55:09 <rkukura> I could easily be wrong, but was under the impression that with OVO you don’t run a migration script that moves all the data at once, but instead individual records get migrated as they are accessed.
16:55:26 <andreas_s_> no, that's not yet the case
16:55:32 <andreas_s_> might be in the future
16:55:48 <rkukura> So for now, its just making the code work with either the old or new schema?
16:55:53 <andreas_s_> ihar told me that the new migration approach will not land before ocata
16:56:26 <andreas_s_> yes, with the new schema
16:56:53 <andreas_s_> the underlying patch includes the alembic scripts that move the data and delete the old columns
16:57:11 <rkukura> ok, I’m not as concerned with this part of it then. I will try to review the patches ASAP.
16:57:12 <andreas_s_> so there's still some downtime during upgrade
16:57:33 <rkukura> we are about out of time - anything else on this?
16:57:35 <andreas_s_> rkukura, let me ping you when I merged both together - cause this will be the final state
16:57:48 <rkukura> andreas_s_: thanks - please do
16:57:51 <andreas_s_> no, I'm done
16:57:54 <rkukura> #topic Open Discussion
16:57:55 <andreas_s_> thanks!
16:58:02 <rkukura> anything to discuss?
16:58:15 <yamamoto> nothing from me
16:58:37 <rkukura> anyone else?
16:58:48 <rkukura> Thanks everyone!
16:59:02 <rkukura> #endmeeting