16:01:40 <Sukhdev> #startmeeting networking_ml2
16:01:40 <openstack> Meeting started Wed Jan 28 16:01:40 2015 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:44 <openstack> The meeting name has been set to 'networking_ml2'
16:01:57 <Sukhdev> #topic: Agenda
16:02:13 <Sukhdev> https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_January_28.2C_2015
16:02:40 <Sukhdev> #topic: Announcements
16:02:59 <Sukhdev> Kilo-2 is next Thursday
16:03:21 <Sukhdev> if you need anything to get into K2, you may want to push your patches
16:03:50 <Sukhdev> I do not have any other announcement - anybody wants to announce anything?
16:04:23 <Sukhdev> #topic: ML2 Drivers decomposition discussion
16:04:46 <Sukhdev> Drivers/Plugin decomposition is a hot topic these days
16:05:00 <sadasu> is there a BP/bug to make changes in devstack to pull changes from external stackforge repo?
16:05:27 <Sukhdev> sadasu: Not that I am aware of
16:05:55 <Sukhdev> there are multiple ways to deal with pulling the code from stackforge
16:06:14 <Sukhdev> I am trying to figure out it as well - getting closer, but, not there yet
16:06:22 <banix> Anyone not using StackForge for their code?
16:06:38 <sadasu> Sukhdev: can you share what you have so far?
16:06:39 <Sukhdev> banix: yes - several examples now
16:07:07 <banix> Sukhdev what are they?
16:07:33 <banix> I may get disconnected shortly. My apologies in advance
16:07:34 <Sukhdev> So, one way is to include the depandancy in the requirements.txt file -
16:07:57 <Sukhdev> This is the way I am trying to make it work -
16:08:03 <Sukhdev> See my patch here - https://review.openstack.org/#/c/148749/
16:08:04 <sadasu> Sukhdev: I think that has to be done
16:08:32 <banix> Ok thx
16:09:02 <Sukhdev> sadasu: the second way (most of the early adapters are doing) is to manually install it
16:09:04 <shivharis> i assume you are talking about the neutron requirements.txt
16:09:20 <Sukhdev> shivharis: no
16:09:44 <shivharis> ok, then how does one know in the first place which requirements.txt is to be used
16:09:54 <Sukhdev> shivharis: This is new requirements file which goes into the driver/plugin's local directory - see on my patch as example
16:10:13 <shivharis> chicken/egg stuff
16:10:27 <Sukhdev> shivharis: How so?
16:11:07 <shivharis> how does one know in the first place Arista's requirements.txt needs to be used to pull Aristia MD
16:11:26 <shivharis> which happens to have the requirements.tx
16:11:41 <Sukhdev> shivharis: good question
16:12:19 <Sukhdev> shivharis: The idea (the way I understand it ) is that who ever wants to deploy Arista driver will use it
16:12:27 <shivharis> I think this is where the devstack magic needs to happen
16:12:47 <shivharis> or some other deployment tool
16:13:21 <rkukura> My undestanding was that these requirements.txt files were for human consumption, and not used automatically. But I could have missed something.
16:13:28 <Sukhdev> shivharis: I am not aware of anybody working on anything related to devstack for this
16:13:55 <sadasu> rkukura: correct. But, we could leverage that for devstack
16:14:12 <shivharis> i am also stuck at this place. I have done the split.sh etc
16:14:26 <shivharis> i think armax just joined, Hi armax!!
16:14:31 <sadasu> Sukhdev: the line in your requirements.txt does not have an explicit stackforge pointer
16:14:31 <pmalik> Having the same issue since two days ago. Seems to only affect clean installations.
16:14:32 <Sukhdev> shivharis: can you elaborate
16:14:48 <Sukhdev> sadasu: ah there is a trick to that
16:14:51 <sadasu> is that going to come later, or is that an implicit assumption that it is in Stackforge?
16:15:16 <Sukhdev> sadasu: So, here is how this will work -
16:15:24 <armax> rkukura: it can be both
16:15:53 <armax> HenryG is going to work on a devstack patch that can be used by both the CI or developers if needed
16:15:58 <Sukhdev> we have pro here - I will let him explain
16:16:08 <shivharis> armax: how does the mech driver get pulled in along side neutron, can you please describe
16:16:18 <armax> shivharis: in which context?
16:16:56 <HenryG> Well, maybe not me personally. I have minions :)
16:17:30 <Sukhdev> HenryG: any ETA?
16:17:34 <shivharis> we were debating to fiugure out the process of pulling in MD from stackforge after neutron has been pulled in
16:18:08 <HenryG> Sukhdev: not yet, can you ping me in a day or two?
16:18:13 <shivharis> appears that something like devstack chnage is necessary
16:18:32 <Sukhdev> shivharis: yes to make your CI work
16:18:39 <armax> shivharis: there are a few altenatives…but the MD might not necessarily be in stackforge
16:19:02 <sadasu> Sukhdev: exactly
16:19:08 <shivharis> armax: what are these alternatives
16:19:34 <shivharis> armax: agreeed that MD may not be in stackforge
16:19:35 <armax> shivharis: HenryG and I had a similar discussion in channel a couple of days ago…in a nutshell…if you’re thinking about CI environments that are based on devstack..you can either do your trick out of band
16:19:58 <armax> shivharis: and this mean install whatever dependency required before doing the stack.sh process
16:20:48 <armax> however, another alternative (especially helpful for the developers who use DevStack) would be to add a hook that install the needed dependency on their behalf
16:20:58 <armax> HenryG was going to put something together to this aim
16:21:07 <armax> HenryG: did I say that correctly?
16:21:09 <HenryG> Right
16:21:30 <HenryG> And it will only be for those MDs that provide a requirements.txt
16:21:35 <rkukura> can the install be done via local.conf?
16:21:42 <HenryG> ODL doesn't, for example
16:21:58 <Sukhdev> HenryG: How do I tie MD requirements.txt with the one with devstack?
16:22:17 <HenryG> rkukura: in the local.conf you just specify the MD(s)
16:22:23 <shivharis> armax: cool, i get th idea that is what i mentioned in the meeting before but wanted some confirmation
16:22:32 <armax> shivharis: ok
16:23:00 <rkukura> HenryG: The local.conf needs to configure mechanism_drivers for ML2. Can it also pull in needed libraries?
16:23:54 <moshele> I used devstack externally-hosted-plugins  http://docs.openstack.org/developer/devstack/plugins.html#externally-hosted-plugins
16:24:15 <moshele> and it is working in networking-mlnx
16:24:29 <HenryG> Sukhdev: for example you would put yours in neutron/plugins/ml2/drivers/arista/requirements.txt
16:24:30 <armax> moshele: that’s another possibility
16:25:09 <armax> going back to my point…if we can rather live without touching DevStack at all I think it would be preferable
16:25:21 <HenryG> the patch to devstack would look for requirements.txt in the dir for the MD(s) configured, and install the reqs
16:25:40 <Sukhdev> HenryG: that is what my understanding is - thanks for clarification
16:26:20 <HenryG> armax: I agree, and would not be surprised if the proposed patch is not approved
16:26:22 <shivharis> HenryG: but before it can even read the requirements.txt is needs to be pulled fisrt
16:27:39 <shivharis> I have a horrible question: can neutron be in requiremnets.txt of the MD?
16:28:04 <Sukhdev> HenryG: if the patch does not make it, then CI's can install dependencies prior to stack.sh as armax mentioned
16:28:07 <HenryG> shivharis: Yuck :)
16:28:17 <Sukhdev> shivharis::-)
16:28:23 <HenryG> Sukhdev: yup
16:28:35 <armax> shivharis: yes, it can
16:28:45 <armax> and no, it’s not a horrible question
16:28:51 <Sukhdev> HenryG: In fact, I am manually testing it this way
16:29:16 <Sukhdev> shivharis, armax : why would one want to do it?
16:29:22 <shivharis> armax: in fact it can be a possible deployment model, needs more thought though
16:29:31 <armax> do what?
16:29:42 <armax> add neutron as a depedency for the MD library?
16:29:55 <Sukhdev> include neutron as dependancy into MD's requirements.txt
16:30:07 <Sukhdev> armax:correct
16:30:19 <rkukura> I suggest we avoid confusion by keeping the term “MD” or “Mechanism Driver” to mean the (usually in-tree) python entrypoint registered with ML2 in the mechanism_drivers config, and refer to the external library using some other term or phrase.
16:30:32 <Sukhdev> armax: I can see stackforge side will need neutron as depenancy - but, not the neutron side of MD
16:30:54 <armax> Sukhdev: the vendor library may depend on neutron, and in most cases it does
16:31:10 <armax> the vendor integration lives within neutron so it the dependency is implicit
16:31:55 <Sukhdev> armax: correct - that means the vendor side will have neutron dependancy not the MD in the tree, isn't it?
16:32:24 <armax> Sukhdev: correct
16:33:22 <Sukhdev> armax: I do not think shivharis was talking about that - that is why HenryG went Yuck :-)
16:34:34 <shivharis> yup, actually i was thinking of situations where i could potentially use neutron without the rest of openstack !
16:35:26 <Sukhdev> shivharis: I am a bit lost on your use case
16:35:47 <shivharis> Sukhdev: we can take it up later
16:35:52 <Sukhdev> anyways - if you want to test without devstack, it is very easy
16:36:26 <Sukhdev> I am installing the depenendancy ahead of time - there are few ways to do it
16:36:49 <Sukhdev> pip install -e <git- for stackforge>
16:37:24 <Sukhdev> or python setup.py install (useful if you are using debugger and want to run pdb from virtual environment)
16:38:49 <Sukhdev> Once all said and done, you will register your package (e.g. networking_arista) in the python
16:39:33 <Sukhdev> at that point - you (or your customers) can simply execute pip install networking_arista - like any other install and off you go
16:40:16 <sadasu> Sukhdev: thanks for outlining the options
16:40:57 <Sukhdev> for example - I asked mestery yesterday - they have not registered the networking_odl yet
16:41:36 <Sukhdev> he mentioned once they release it they will register it and hence it becomes available to public
16:41:48 <Sukhdev> Hope this makes sens
16:41:59 <moshele> I have question regarding policy.json, currently I duplicate to the netowrking-mlnx repository to pass jenkins
16:41:59 <Sukhdev> Anything else on this decomposition stuff?
16:42:07 <shivharis> what is this "registered" step?
16:42:11 <moshele> any workaround for this
16:42:55 <Sukhdev> shivharis: pip register <your stuff> - go ask google uncle, he will tell you everything :-):-)
16:43:05 <Sukhdev> moshele: I am seeing it as well -
16:43:06 <shivharis> ah ok, thanks
16:43:36 <manishg> Sukhdev: timecheck.  8:45
16:44:02 <Sukhdev> moshele: If you figure out a way around, I will be interested
16:44:11 <Sukhdev> manishg: Thanks for reminder sorry
16:44:19 <Sukhdev> lets move on
16:44:40 <moshele> no I have not I am asking if there is workaround
16:44:48 <Sukhdev> #topic: ML2 sync and taks flow update
16:45:07 <manishg> for this one I had a question for armax
16:45:23 <Sukhdev> I wanted to pick this topic from where we left last time
16:45:33 <manishg> there was a snippet posted about how this can be done but further work was put on holding pending the API/ RPC split.
16:45:37 <Sukhdev> manishg: I think armax is gone
16:46:23 <manishg> ok.
16:46:32 <manishg> so Angus Lees had put this patch out - https://review.openstack.org/#/c/136950/
16:46:36 <Sukhdev> manishg: can you elaborate please
16:47:09 <manishg> In Paris summit it was mentioned (and also work got started in mid-cycle) about API/ RPC split.
16:47:48 <manishg> of neutron.  That is , in neutron itself the flow will be divided such that API process will be separate from the RPC worker processes.
16:48:40 <manishg> The idea is that API should deal with validity and commit to db and the rest of the work (which may require talking to devices and other blocking tasks) could be handled by RPC workers.
16:49:45 <Sukhdev> manishg: so, while the back-ends are working, nothing goes into DB or some intermediate state goes into DB?
16:49:46 <manishg> Something to this effect.  If this is what's being accomplished in kilo timeframe then this might suffice and we maybe able to use TF at that level itself.
16:50:27 <manishg> There was talk about maintaining states.  And the workers will take appropriate measure to take the right action based on the states.
16:51:07 <shivharis> where is this being discussed
16:51:22 <shivharis> i would like to participate
16:51:51 <manishg> This was discussed in Paris as well in midcycle.  I was trying to get more information this week but haven't been able to .  I'll try to get it today.
16:52:15 <Sukhdev> manishg: Can I keep this on the agenda for next week and can you provide further update on this topic - we are running out of time today
16:52:15 <rkukura> shivharis: I think the idea is to resume this discussion with the hope of having a plan for the L summit.
16:52:16 <manishg> There were pretty long sessions to discuss the above split in Paris.
16:52:30 <manishg> Sukhdev: sure.
16:52:44 <shivharis> the problem i see here, is that the db cannot be trusted if the rpc fails
16:53:05 <Sukhdev> shivharis: that is why intermediate state
16:53:07 <manishg> shivharis: the state of db could be "CREATING" e.g.
16:53:31 <Sukhdev> Folks, can we table this and pick it up next week - when we have some more time?
16:53:44 <manishg> Sukhdev: yeah, let's move on
16:53:45 <Sukhdev> I would like to cover the bugs, if we can
16:53:56 <Sukhdev> #topic: Bugs
16:54:09 <Sukhdev> rkukura: do you want to cover the new bug
16:54:15 <shivharis> i would like to discuss if the db can also be manipulated as part of the task ( i need to understand why not)
16:54:26 <Sukhdev> https://bugs.launchpad.net/neutron/+bug/1415526
16:54:43 <Sukhdev> shivharis: lets cover it next week
16:54:52 <rkukura> I filed https://bugs.launchpad.net/neutron/+bug/1415526 for the issue that the HPB patches have been hitting in the DVR tempest tests.
16:55:12 <rkukura> I’ve got two different fixes, and will post a summary/plan/question to openstack-dev later today.
16:55:27 <shivharis> i would like to see high bugs addressed by next week's k2 (if possible)
16:56:18 <rkukura> This is closely related to https://bugs.launchpad.net/neutron/+bug/1367391, but much easier to fix (or work around).
16:57:14 <rkukura> I also hope to have a fix for https://bugs.launchpad.net/neutron/+bug/1367391 in review by kilo-2, but am not expecting it to merge in time.
16:57:17 <shivharis> rkukura: will these make it to k2?
16:57:50 <rkukura> I’m hoping the fix for https://bugs.launchpad.net/neutron/+bug/1415526 and the 2 remaining HBP patches can be merged for kilo-2.
16:57:54 <rkukura> HPB
16:58:12 <shivharis> rkukura: thanks
16:58:26 <Sukhdev> rkukura: looks like you are going to be busy this week :-)
16:58:35 <rkukura> Hard part is coming up with a UT for https://bugs.launchpad.net/neutron/+bug/1415526.
16:58:53 <shivharis> all: can you please update your bugs with a short message as to where we are on the bug (all bugs)
16:59:21 * Sukhdev 1 min
16:59:30 <Sukhdev> #topic: Open Discussion
16:59:35 <shivharis> thats all from me
16:59:47 <Sukhdev> anything quick ?
16:59:56 <manishg> Sukhdev: for the wiki tracking BP etc. can we wipe out R1/R2 C1/C2 etc. ?  do we need it?
17:00:09 <Sukhdev> manishg: yes,
17:00:14 <manishg> all we need is a list.
17:00:15 <manishg> ok. thx.
17:00:29 <Sukhdev> and also keep only the BPs that we are tracking for Kilo
17:00:35 <manishg> yep
17:01:00 <Sukhdev> anything else folks - we are out of time
17:01:15 <Sukhdev> Thanks everybody - great discussion
17:01:17 <manishg> thanks.  bye.
17:01:19 <banix> bye
17:01:24 <Sukhdev> #endmeeting