16:02:56 <rkukura> #startmeeting networking_ml2
16:02:57 <openstack> Meeting started Wed Mar 11 16:02:56 2015 UTC and is due to finish in 60 minutes.  The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:03:00 <openstack> The meeting name has been set to 'networking_ml2'
16:03:10 <rkukura> #topic Agenda
16:03:19 <Sukhdev> HenryG: welcome
16:03:31 <rkukura> #link https://wiki.openstack.org/wiki/Meetings/ML2
16:03:59 <rkukura> Anything specific to add to the agenda?
16:04:23 <shivharis> k3 in Mar 19
16:04:26 <rkukura> #topic Announcements
16:04:35 <rkukura> From the neutron meeting:
16:04:35 <shivharis> s/in/is/
16:04:58 <rkukura> Feature, String, and Dependency Freeze: March 19
16:05:10 <rkukura> RCs: April 9-23
16:05:19 <rkukura> Kilo release: April 30
16:05:35 <rkukura> Any other announcements?
16:06:37 <rkukura> #topic ML2 Drivers decomposition discussion
16:06:58 <rkukura> Any updates, issues or questions on this?
16:07:43 <Sukhdev> I notice - great progress is being made on this effort
16:07:44 <shivharis> rkukura: what was it about pinning neutron for mds/plugins in neuton meeting
16:07:57 <rkukura> shivharis: good question
16:08:20 <rkukura> I didn’t exactly follow the argument why pinning was needed
16:08:23 <shivharis> rkukura: seemingly breaks plugins that have already passed due to changes in neutron
16:09:03 <Sukhdev> shivharis: I missed the meeting - please provide more context
16:09:05 <shivharis> armax: if you are around can you please clarify for ML2'ers
16:09:20 <rkukura> shivharis: Are you saying that the neutron changes actually break the driver CI? If so, don’t we want to know that?
16:09:35 <armax> shivharis: what exactly?
16:10:07 <shivharis> marun, armax: need clarification on neutron pinning discussed in neutron meeting
16:10:13 <rkukura> armax: Can you explain the rationale for pinning neutron versions in driver CI as discussed in the neutron meeting?
16:10:24 <armax> ok
16:10:58 <armax> the question is: at the moment both the drivers/plugins and aas services chase neutron’s tip of master
16:11:17 <armax> armax: however, this doesn’t have to be the only option
16:12:31 <armax> services, as well as drivers, may want to target a specific hash for neutron, which is deemed stable and working from an integration perspective
16:13:13 <rkukura> armax: If the neutron hash is pinned, what is the point of triggering the CI on neutron changes? Am I missing something?
16:13:31 <shivharis> armax: so changes in neutron can break drivers even though at some point it passed CI etc, but what would be a good version, leave it to the developer of ml2drivers?
16:13:59 <armax> the need of having CI checking master is so that one can verify whether the pin can be bumpted
16:14:01 <armax> bumped
16:15:37 <Sukhdev> armax: I am confused - folks have stable versions (of neutron) and master - are you talking about pining some version of master itself?
16:16:04 <armax> that was simply a proposal at the moment
16:17:51 <shivharis> armax: i guess we should wait till this is finalized, we can get clarification at a later time
16:17:51 <rkukura> Seems like ML2 driver owners should track this, but no immediate change is required/recommended, right?
16:18:01 <armax> rkukura: correct
16:18:03 <sadasu> armax: is this something that is going to be flushed out in Kilo, or is it something you are exploring for Liberty
16:18:10 <armax> lbaas is going to experiemnt with this
16:18:11 <shivharis> armax: thanks
16:18:21 <armax> I wouldn’t recommend taking any action at the moment
16:18:36 <armax> but it’s important to be aware that the option of pinning is there,
16:18:40 <rkukura> While armax is here, are there any other questions for him regarding decomosition?
16:18:56 <armax> if one does pin, then yes, the CI tracking master is only there to validate whether the pin can be moved forward
16:18:58 <sadasu> I have one
16:19:06 <armax> makes sense?
16:19:59 <HenryG> The biggest hump the vendor repos have to get over right now is to switch away from oslo-incubator usage
16:20:02 <rkukura> sadasu: go adead…
16:20:18 <Sukhdev> armax: In general, it makes sense - but, the devil is in the details :-)
16:20:35 <shivharis> armax: run CI twice to see if we can move the pin?
16:21:17 <sadasu> armax: might have to give this more thought....do you really want to add dependency on vendor CI for pinning? We want to decouple correct?
16:21:24 <armax> shivharis: you run the CI once per project, how many configurations you’re testing it’s up to you
16:21:58 <sadasu> vendors should be picking a pin based on how they see their CIs behaving, but those are very initial thoughts
16:22:01 <armax> sadasu: the end goal is to minimize the depedency yes
16:22:11 <sadasu> my question was regarding UTs on Neutron side
16:22:25 <armax> sadasu: what about them?
16:22:41 <sadasu> with the Neutron shim being very thin, and UTs not being able to import modules from stackforge repos
16:23:25 <sadasu> UTs on the Neutron side end up mocking so much that there doesnot seem much value in it
16:24:09 <sadasu> so is there a hard requirement for having UTs on the Neutron side?
16:24:14 <armax> sadasu: no
16:24:38 <rcurran> sadasu, all cisco_nexus md UTs have been moved to stackforge
16:25:14 <GLaupre> UTs?
16:25:16 <rkukura> sadasu: I think whether UTs are needed on the neutron side really depends on how thin vs. thick the specific shim is. If the shim for example includes port binding logic, that probably should be tested in neutron using mocked versions of underlying calls.
16:25:17 <sadasu> rcurran: correct, but the mech driver is a pass through
16:25:26 <sadasu> not all mech drivers are split that way
16:25:46 <rcurran> sadasu, it'a an option. just fyi
16:26:23 <Sukhdev> rkukura: yes, you are correct
16:26:31 <armax> sadasu: correct…it’s not about running UTs here or there
16:27:31 <Sukhdev> I guess the critical question to be answered is - if anything changes on the neutron side (the API, for example), how and where do you want to catch it?
16:28:00 <armax> sadasu: so long as you ensure effective coverage, unit or otherwise it doesn’t matter where it leaves but how to run it
16:28:03 <sadasu> rkukura: point taken, but a very small set of UTs...we can run a full detailed set of UTs on stackforge..so why not do everything there
16:28:06 <armax> s/leaves/lives/
16:28:38 <sadasu> armax: yes, my question was about where it lives...we are definitely ensuring good coverage
16:28:48 <rkukura> sadasu: I think there is flexibility
16:29:15 <armax> even if it existed in your own trees and you have external dependencies
16:29:23 <armax> then it’s the ‘trigger’ that counts
16:29:41 <sadasu> thanks for all responses/inputs
16:29:46 <shivharis> unit tests should exists where the code exists (repo'wise)
16:29:56 <sadasu> armax: didn't get that one
16:30:49 <rkukura> shivharis: Don’t want to reduce neutron’s code coverage metrics
16:31:25 <sadasu> shivharis: agreed in theory..but UTs have an issue that if you import a module in Neutron that in turn imports from stackforge, UTs implode
16:32:38 <sadasu> solution for that would be to mock
16:32:44 <Sukhdev> sadasu: you mean circular dependancy
16:32:59 <sadasu> Sukhdev: correct
16:32:59 <armax> sadasu: that’s one option, the other option is to move that type of coverage elsehwere
16:33:35 <armax> sadasu: and execute it based on what changes may impact the code under coverage
16:33:51 <sadasu> armax: yes, that can be tested well on the stackforge side since we don't have the import restriction
16:34:23 <rkukura> lets try to wrap up the decomposition discussion in the next couple minutes so we have time for the rest of the agenda
16:34:42 <Sukhdev> HenryG: care to elaborate on oslo-incubator issue?
16:35:21 <shivharis> armax: thanks
16:35:42 <armax> Sukhdev: there may be breaking changes due to the handling/transition from openstack/common to oslo graduated libraries
16:35:43 <HenryG> Sukhdev: neutron is switching most of the oslo stuff to incubated oslo packages
16:35:44 <sadasu> armax: thanks...I think I have my questions answered.
16:36:20 <armax> ihar will be compiling a wiki page, a journal if you will, where these issues are documented
16:36:40 <HenryG> Sukhdev: https://wiki.openstack.org/wiki/Neutron/VendorSplitPackaging
16:36:50 <armax> for instance this one: https://review.openstack.org/#/c/159638/ it’s going to break all the projects
16:36:54 <sadasu> should we be looking out for a specific commit that will bring these changes?
16:37:04 <armax> that depedent on Neutron and use openstack/common/log
16:37:26 <Sukhdev> HenryG, armax : Thanks for the heads up - will go and read this
16:37:57 <sadasu> thanks for the links
16:38:25 <rkukura> are we ready to move onto the next agenda item?
16:39:09 <rkukura> guess so…
16:39:11 <Sukhdev> rkukura: yes
16:39:12 <rkukura> #topic ML2 Sync and error handling (Task Flow)
16:39:28 <rkukura> manishg: You around?
16:39:30 <shivharis> manishg: hi
16:40:29 <rkukura> I’d at least like to remind people to review and comment on https://review.openstack.org/#/c/154333/
16:40:46 <rkukura> I added one comment this AM.
16:41:03 <shivharis> i had some questions, i guess i will insert in rhe review
16:41:39 <rkukura> OK, anything else on this today?
16:42:45 <rkukura> if not…
16:42:49 <rkukura> #topic Bugs
16:42:59 <shivharis> bugs, we are looking good, i am hoping the high priority ones will be taken care of by K3 (Mar 19) - otherwise it will be very hard
16:43:21 <manishg> rkukura: around.  sorry was distracted!  will wait until after bugs
16:43:26 <shivharis> if anyone needs any help - reviews for bugs - now is the time to ask
16:44:05 <shivharis> not much to add further..
16:44:11 <rkukura> shivharis: On https://bugs.launchpad.net/neutron/+bug/1367391, I was making progress, but am just getting back to it now. Hopefuily will have patch in review by 3/16
16:44:11 <openstack> Launchpad bug 1367391 in neutron "ML2 DVR port binding implementation unnecessarily duplicates schema and logic" [High,In progress] - Assigned to Robert Kukura (rkukura)
16:44:45 <shivharis> rkukura: this is high pri bug, k3 then?
16:45:10 <rkukura> shivharis: yes
16:45:24 <shivharis> rkukura: thanks
16:45:48 <shivharis> lets move on ..
16:46:05 <rkukura> no other bugs to discuss?
16:46:33 <shivharis> i am worried about one - really:
16:46:47 <shivharis> https://bugs.launchpad.net/neutron/+bug/1378732
16:46:47 <openstack> Launchpad bug 1378732 in neutron "migrate_to_ml2 script doesn't work for Juno release" [High,New] - Assigned to Mark McClain (markmcclain)
16:47:24 <shivharis> i have pinged, will ping again, we need some resolution - i ping on this again
16:47:33 <shivharis> i will ping on this again
16:48:22 <shivharis> will seek mestery on this
16:48:25 <rkukura> shivharis: Thanks.
16:48:34 <rkukura> Any other bugs to discuss?
16:48:39 <shivharis> this one is in limbo
16:48:57 <shivharis> i meant the previous one
16:49:06 <rkukura> #topic: ML2 Sync and error handling (Task Flow) - revisited
16:49:15 <rkukura> manishg: Did you have an update on this?
16:49:38 <manishg> rkukura: I'll look at your comment.  No other comments there.  one question
16:49:43 <rkukura> ok
16:49:53 <rkukura> go ahead manishg …
16:49:58 <manishg> Sukhdev wanted to talk about changing the state back to 'Creating'
16:50:03 <manishg> after it was created.
16:50:22 <manishg> I'm not sure how that would work?  The device would have to generate an event through neutron REST API
16:50:28 <Sukhdev> manishg: I wanted to discuss the issue that I raised last week -
16:50:32 <rkukura> back to creating? Or start in creating, and change to active once complete?
16:50:55 <manishg> rkukura:  normal flow  Null -> creating -> active (once all drivers are happy)
16:51:05 <rkukura> right
16:51:25 <manishg> Sukhdev wanted : Null-> creating -> Active -> creating (in case one of the devices is unhappy later)
16:51:39 <Sukhdev> well, it can be changed to any state other than active - so that no action is taken while the back-end is going through recreating the state
16:52:24 <manishg> Sukhdev: are you proposing that once we add state to the resource attributes, the REST API should allow 'updating' the internal state?
16:53:02 <Sukhdev> manishg, possibly - or any other way for the back-end to tell the front end to hold off until I tell you to go again
16:53:04 <shivharis> manishg: will this lead the system to hang waiting for some completion
16:53:27 <manishg> rkukura: other pending item in my plate is to write something about accumulating and queueing while it's not ACTIVE yet.
16:53:36 <rkukura> I think we need to think hard about how we want these states to effect the client workflow. We could allow all REST APIs all the time, or reject or block them in certain states. I lean towards allowing them, and treating the backends as “eventually consistent”.