16:01:21 <Sukhdev> #startmeeting networking_ml2
16:01:21 <openstack> Meeting started Wed Jun 18 16:01:21 2014 UTC and is due to finish in 60 minutes.  The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:25 <openstack> The meeting name has been set to 'networking_ml2'
16:01:47 <Sukhdev> #topic: Agenda
16:02:11 <Sukhdev> #link: https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_June_18.2C_2014
16:02:31 <Sukhdev> #topic: Announcements
16:02:51 <Sukhdev> I do not have any announcements today
16:03:07 <shivharis> sukhdev: you want say something about
16:03:10 <Sukhdev> anybody has any?
16:03:10 <amotoki> hi
16:03:23 <shivharis> the CI failing and remidiation
16:03:54 <Sukhdev> shivharis: Oh yes - we have a fiasco about the CI's failing this week
16:04:01 <banix> ;)
16:04:11 <Sukhdev> Our Arista CI got hit three times last week
16:04:24 <Sukhdev> This is all about the upgrades to 3.x version
16:04:47 <rkukura> Sukhdev: 3.x version of what?
16:04:58 <Sukhdev> I sent out an announcement on the ML to warn all CI owners
16:05:04 <Sukhdev> rkukura:python
16:05:22 <Sukhdev> pip version had to be upgraded
16:05:35 <trinaths> what is that failure?
16:05:37 <Sukhdev> then setuptools need to be upraded
16:05:59 <banix> have a link to your email by anychance? or date/time
16:06:21 <Sukhdev> I sent it out on Saturday
16:06:30 <banix> Sukhdev: ok thx
16:06:32 <Sukhdev> Do not have a link handy
16:06:59 <Sukhdev> I was with Infra folks all afternoon getting this fixed.
16:07:17 <Sukhdev> The fix has been merged upstream and now everything is fine
16:07:19 <yamamoto> this? http://lists.openstack.org/pipermail/openstack-dev/2014-June/037713.html
16:07:20 <shivharis> in openstack-neutron ML look for subject "Most Third Party CI's Failing"
16:07:21 <trinaths> Sukhdev, what is the fix required for this.
16:07:36 <Sukhdev> shivharis:yes
16:07:58 <Sukhdev> trinaths: nothing now - it has been fixed in the upstream -
16:08:13 <chuckC> Is there impact on devstack?
16:08:39 <Sukhdev> Also, want to mention that Kyle sent out an email asking all CI's to conform to third party requirements -
16:08:44 <trinaths> Sukhdev, do CI owners need to do an upgrade.
16:08:53 <Sukhdev> deadline is Juno-2
16:09:09 <trinaths> okay
16:09:14 <Sukhdev> trinaths: no - it turned out the upstream was broken, hence no change is needed now
16:09:23 <trinaths> Sukhdev, thanks
16:09:24 <amotoki> for setuptools, the fix is http://git.openstack.org/cgit/openstack-dev/devstack/commit/tools/install_pip.sh?id=76ed427ca17fb271974b4882c0b5e3c18ed3d889
16:10:09 <Sukhdev> amotoki: thanks
16:10:26 <Sukhdev> Anything else for announcements?
16:10:45 <shivharis> can we put a link for CI requiremnts in the ML2 wiki page
16:11:27 <Sukhdev> shivharis: I guess that will be OK
16:11:44 <Sukhdev> I'll add the link later
16:12:26 <Sukhdev> ##topic: Action items from last week
16:12:43 <Sukhdev> banix: floor is yours
16:12:49 <banix> yes sure
16:13:01 <Sukhdev> banix: I saw the wiki - looks good
16:13:15 <banix> the wiki for tracking specs has been up; removed the etherpad (left a link to the wiki only)
16:13:33 <amotoki> looks good, but i wonder why some L3 related reviews are included.
16:13:34 <banix> there was a request for possibly tracking code review as well
16:14:23 <Sukhdev> banix: it will be a good idea to have a link to the code in one column
16:14:41 <banix> amotoki: yeah we can remove if not related to ML2
16:15:03 <banix> Sukhdev: since we have just a few specs already merged i added a column to the table for merged specs
16:15:18 <amotoki> banix: np. thanks.
16:15:20 <banix> I am not sure if people are updating the table though… We will see
16:15:37 <trinaths> banix: me updated.
16:15:40 <amotoki> i would like to suggest removing +/- score from the table.
16:16:01 <rkukura> I forgot to update the table after approving the partial specs spec
16:16:03 <Sukhdev> I do not believe folks are updating the table -
16:16:23 <banix> amotoki: because it may prevent people from reviewing those with -1s?
16:16:45 <trinaths> amotoki, +1/-1 will be helpful as a summary of the review.
16:16:49 <amotoki> banix: no. scores are changed too frequently.
16:17:00 <banix> amotoki: yes that is true
16:17:41 <amotoki> Does "Cx" mean a core reviewer and "Rx" mean a Reviewer?
16:17:50 <amotoki> where x is a number.
16:17:56 <banix> Considering people are not updating the tables I am wondering if simply having a table cotaining the first couple of columns would be enough but we can wait and see
16:17:59 <banix> amotoki: yes
16:18:00 <slogan> actually, I forgot yesterday to update the table after reviewing the ML2 VXLAN spec. I'll do that now
16:18:54 <banix> we have to also assign priority if we want to take this to the wider Neutron group I think
16:19:07 <amotoki> the table is useful. Hopefully reviewer owner updates a corresponding entry. I believe it helps owners.
16:19:31 <banix> I did not want to assign priority on my own but added the guideline to the end of the wiki page
16:19:38 <shivharis> should we assign the prirorty instead of the wider group
16:19:40 <banix> amotoki: ok. makes sense
16:19:53 <Sukhdev> Some of the owners are not aware of this table. I sent an email to one of the owners to put their ML2 BP in this table
16:19:58 <rkukura> we should identify the BPs that we think should be high or medium
16:20:38 <banix> now we can sort the table based on priority (once those are assigned) :) it’s like we are using computers :)
16:20:48 <Sukhdev> who wants to take an action to assign the priorities?
16:20:51 <Sukhdev> :-)
16:21:24 <rkukura> Can people here suggest BPs that more than one driver depend on?
16:21:28 <amotoki> how about splitting the table into categories: ML2 common, mech driver specific?
16:22:04 <Sukhdev> amotoki: that would automatically put the priority -
16:22:19 <Sukhdev> ML2 common are higher priority
16:22:33 <amotoki> Sukhdev: yeah. it helps us :-)
16:22:45 <rkukura> I think some common BPs should be higher prioiry than others
16:22:48 <banix> amotoki: using priority may do the same within a single table
16:23:21 <rkukura> for example, if several drivers need extensions, it should be higher than if only one driver needs that BP
16:23:57 <amotoki> rkukura: makes sense much
16:24:16 <Sukhdev> rkukura: if we moved such BP under ML2 common, it will get higher priority?
16:25:42 <Sukhdev> banix: can we ask you to volunteer to baby sit it for a bit longer to get it fully in order?, please...
16:25:43 <padkrish> rkukura: So, should there be a column in the wiki that says ML2 common?
16:25:58 <banix> Sukhdev: sure no problem
16:26:02 <rkukura> Sukhdev: as a start we could put the common ones higher in the list than the non-common BPs
16:26:10 <banix> Sukhdev: what specifically do you want to be done
16:26:40 <Sukhdev> banix: I liked amotoki suggestion of ML2 common and ML2 drivers
16:26:53 <rkukura> I’d like to identify if there are any BPs here that absolutely must get done in juno, from more than a single vendor’s perspective.
16:27:19 <banix> Sukhdev: sure will split up the table into two and see how it goes
16:27:20 <rkukura> Those should be high
16:27:25 <Sukhdev> banix: Once we split them into categories
16:27:50 <Sukhdev> then we can use rkukura idea to further prioritize within a given category
16:28:08 <banix> sounds good
16:28:26 <shivharis> it is best to minimize baby sitting, the table is not too big. as rkukura says maybe a column that says Juno-must
16:28:42 <banix> i guess rkukura is asking if there is any bp that needs to be set to high priority; please speak up
16:28:54 <rkukura> We should also try to identify anything other subteams depend on, and raise priority of these BPs to match their dependent BPs
16:29:04 <Sukhdev> #Action: banix to re-organize the wiki to categorize the specs and add a column for code reviews
16:29:05 <banix> shivharis: i agree; i think just a priority would do imho
16:29:11 <nlahouti> the VDP one
16:29:29 <slogan> there is already a priority column. Just invent a new number - 0 (Juno-must)
16:29:39 <rkukura> nlahouti: Is the VDP spec need by more than one vendor?
16:29:42 <banix> Sukhdev: i added the column for code review for the table that is for approved specs
16:29:44 <slogan> then 1, 2, 3 ...
16:29:47 <banix> would that work?
16:29:51 <nlahouti> rkukura: not for now.
16:30:05 <Sukhdev> banix: ah OK
16:30:06 <rkukura> priority 1 (high) is for the juno-musts
16:30:12 <nlahouti> rkukura: the cisco dfa MD need it
16:30:26 <rkukura> priority 2 (medium) is for common features needed by multiple drivers
16:30:52 <shivharis> banix: agree
16:30:53 <rkukura> priority 3 is for vendor drivers and common features only needed by single vendor drivers
16:31:08 <yamamoto> rkukura: sounds reasonable
16:31:10 <slogan> rkukura: fie. maybe we need some text on the page that says this then
16:31:13 <rkukura> its a start
16:31:31 <nlahouti> rkukura: which prority is juno must
16:31:33 <amotoki> sounds good. it is a good startline.
16:31:38 <Sukhdev> Looks like we are converging on this
16:31:38 <banix> slogan: had some text at the bottom about priority
16:31:50 <shivharis> 30 mins left
16:31:50 <sadasu> nlahouti: 0
16:32:13 <banix> Ok let me go through and do the assignment
16:32:19 <slogan> banix: ah. hrmmm, wrap it with a blink tag? :-P
16:32:23 <banix> you can beat me up next time or on the mailing list
16:32:35 <rkukura> But we will need to use judgement on things that don’t fit these categories, like QoS or partial specs, …
16:32:56 <banix> slogan: :)
16:32:58 <rkukura> banix: +1
16:33:09 <Sukhdev> rkukura: agreed
16:33:25 <Sukhdev> shall we move on?
16:33:25 <banix> yes we can change if the priority assigned is not correct
16:33:31 <banix> yes pls
16:33:46 <Sukhdev> #topic: Modular L2 agent
16:33:54 <banix> there was one more action item
16:34:02 <banix> the bug for bulk item
16:34:25 <banix> I looked into it; Shall I discuss that first?
16:34:31 <Sukhdev> banix: Opps… please go ahead and provide update
16:34:35 <shivharis> what did you find?
16:34:58 <banix> Yes so as the bug says the bulk creates are done in one transaction
16:35:23 <banix> so for ML2 drivers create network for example is called multiple times from within a transaction
16:35:52 <banix> This will include calls to postcommit operations
16:35:55 <rkukura> calling the postcommit methods within transactions is definitely a bug, IMHO
16:36:06 <banix> rkukura: agress
16:36:38 <banix> so the fix would be having create_network_bulk for example in plugin.py (rather than using one in the mixin)
16:36:40 <Sukhdev> I was planning on taking to ML and discuss it there - we touched on it a bit last week
16:37:24 <banix> Sukhdev: that would work
16:37:25 <Sukhdev> but, banix go on if you have details
16:37:36 <banix> yeah so the bulk aps are to be atomic
16:37:55 <banix> right now that is achieved by having multiple calls for create operations in a transaction
16:37:59 <banix> here:
16:38:12 <banix> context.session.begin(subtransactions=True)
16:38:13 <banix> try:
16:38:14 <banix> for item in items:
16:38:15 <banix> obj_creator = getattr(self, 'create_%s' % resource)
16:38:16 <banix> objects.append(obj_creator(context, item))
16:38:17 <banix> context.session.commit()
16:38:20 <banix> Sorry dhould have used paste
16:39:18 <Sukhdev> banix: the problem is how would you unwind if one of these fails
16:40:14 <banix> Sukhdev: yeah; since these are only for creates (are there bulks for other operations?) that would be deleting all newly created resources
16:40:48 <Sukhdev> banix: according to documentation - bulk is only for creates - which is problematic as well
16:40:50 <slogan> seems like that subtransactions arg is a clue as to how to fix this (and implies it is ok to do in multiple transactions)
16:41:21 <rkukura> banix: Seems there are at least two possible strategies: 1) call create outide transactions and delete the already-created resources if any creates fail, or 2) do all the precommit method calls in one transaction, then all the postcommits afterwards
16:42:28 <rkukura> slogan: I wouldn’t read too much into ontext.session.begin(subtransactions=True) since almost every transaction in neutron looks like this
16:42:41 <banix> rkukura: even in 2 you may need to delte already created resources. right?
16:42:41 <slogan> ok
16:42:52 <Sukhdev> rkukura: I like 2
16:43:06 <rkukura> banix: Any failure in any precommit would rollback the entire transaction
16:43:09 <shivharis> for 2: if all precommits are done first, and later one of postcommit fails, are all precommits un-done?
16:43:27 <Sukhdev> rkukura: with this approach, if any post-commit fails, sync can take care of it - and we do not need to unwind
16:43:31 <rkukura> shivharis: Good question
16:43:33 <banix> shivharis: yes that was my point
16:43:51 <rkukura> Sukhdev: I agree, once we have a sync strategy
16:44:06 <banix> yeah right now for a single create if post commit fail we rollback
16:44:30 <banix> considering that bulk operations are to be atomic by defnition then we have to rollback i belive
16:44:54 <rkukura> I think to be consistent with our current error handling, we’d need to delete all the resources if any postcommit fails
16:45:04 <shivharis> banix: but some postcommits may have succeeded so that is a can of worms
16:45:13 <Sukhdev> I think we need to solve this in conjunction with sync - things will get much better and less error prone
16:45:22 <banix> shivharis: sync :) will save you
16:45:27 <banix> shivharis: i know
16:45:39 <rkukura> and if we do delete them all on any postcommit failure, I don’t think this really has much advantage over option 1.
16:45:47 <amotoki> I have another point of view. Once precommit completes, resources under being created are visible to API and they can be used. it seems not to be atomic.
16:46:16 <amotoki> Ideally we need additional state for resources.
16:46:22 <rkukura> seems like maybe we should consider option 1 for the short term, and option 2 as part of a solving the sync/recovery issue
16:46:36 <banix> amotoki: that’s a good point
16:46:50 <shivharis> will this work as "tasks" that mark is working on?
16:47:01 <rkukura> maybe we need to get sync/recovery back on the agenda soon
16:47:22 <rkukura> I still have an action to discuss using tasks for this with markmcclain
16:47:30 <Sukhdev> rkukura: Yes - I think we should look for cleaner solution, and sync will do it
16:48:03 <shivharis> 12 mins left
16:48:05 <Sukhdev> Any volunteers to work on sync with Bob and I?
16:48:12 <shivharis> i can
16:48:17 <banix> Even with sync the issue raised by amotoki will be there
16:48:24 <Sukhdev> shivharis: cool - we should discuss
16:48:31 <Sukhdev> Lets move on folks
16:48:33 <shivharis> sukhdev: k
16:48:45 <Sukhdev> banix: anything on ML2 agent?
16:48:49 <banix> yes
16:49:01 <banix> please read and make comments/suggestions
16:49:14 <shivharis> banix: pics in the docs dont render, any suggestions
16:49:15 <banix> there have been just a few emails from yesterday on the ML
16:49:35 <banix> shivharis: hmmm sorry will try to fix
16:50:14 <Sukhdev> Lets all spend some time this week to review this - I will do it..
16:50:22 <Sukhdev> moving on
16:50:23 <yamamoto> do you have a plan to write something which can work?
16:50:28 <Sukhdev> #topic: Bugs
16:50:38 <banix> Sukhdev: thanks; please do
16:50:39 <Sukhdev> shivharis: want to sat anything?
16:50:52 <Sukhdev> s/sat/say
16:50:57 <chuckC> amotoki: is that a bulk create issue, or even single create?
16:50:59 <shivharis> I had been using a set of bugs that I was
16:51:13 <banix> yamamoto: if I get a green light from all you guys that this approach is reasonable, then i will go ahead. yes.
16:51:22 <chuckC> sorry, my client hung for a bit
16:51:26 <shivharis> tracking. based on the last meeting we decided to do it based on a search criteria
16:51:26 <amotoki> chuckC: good point. I think it is not specific to bulk operation.
16:51:42 <shivharis> so lets look at the link from the agends on bugs?
16:51:46 <Sukhdev> banix: lets try to reach to conclusion next week
16:51:57 <banix> Sukhdev: ok sounds good
16:52:01 <shivharis> we need to get "confirmed" picked up by folks
16:52:44 <banix> chuckC: that’s a very good point.
16:52:51 <Sukhdev> We need volunteers -
16:53:14 <Sukhdev> shivharis: have you been chasing folks for this?
16:53:29 <shivharis> yup, looking for volunteers. if not i am going to switch back to old way and ask specific help
16:53:42 <slogan> newbie question: I can do code reviews, for bug fixes (if any) what do i do, find a peer who is willing to take a patch and commit. I know I can probably read about it, but since we are talking about bugs and volunteers
16:53:43 <Sukhdev> we are running short on time...
16:54:10 <shivharis> slogan: need folks like you. will ping you. any other folks
16:54:19 <banix> i can work on the bulk operation one … need to figure out the role of sync or perhaps have that as a separate work item
16:54:21 <shivharis> s/folks/volunteers/
16:54:48 <Sukhdev> banix: cool - lets chat on IRC afterwards
16:54:57 <banix> Sukhdev: ok
16:55:05 <Sukhdev> shivharis: anything else?
16:55:14 <sadasu> are there any bugs that are confirmed and unassigned?
16:55:23 <shivharis> no, need volunteers !!
16:55:26 <amotoki> I categorized reviews on the wiki page during the meeting.
16:55:30 <Sukhdev> #topic: Spec Reviews
16:55:33 <slogan> shivharis: thanks
16:55:43 <Sukhdev> We have covered it already
16:55:53 <padkrish_> #shivharis# count me in
16:56:10 <shivharis> padkrish_: will do
16:56:12 <nlahouti> shivharis: me  too
16:56:22 <Sukhdev> wanted to mention that everybody is not logging there BPs in our table here is an example https://review.openstack.org/#/c/97490/
16:56:26 <shivharis> nlahouti: will do
16:57:04 <Sukhdev> I wanted to cover which BPs are ready for core reviewers - but, we are out of time
16:57:07 <shivharis> 3 mins left
16:57:20 <Sukhdev> I added couple of them to the agenda - Please look at them
16:57:27 <nlahouti> sukhdev: is there any timeline for core to approve the 'ready to approve BP'?
16:57:29 <sadasu> Sukhdev: I answered your question on my BP review
16:57:37 <sadasu> could you pls take a look again?
16:57:38 <Sukhdev> #topic: Open Discussion
16:58:19 <banix> Sukhdev: Will try to add the priority today so you and rkukura can see how it looks and decide what to take to neutron meeting
16:58:30 <banix> Sukhdev: if any
16:58:33 <Sukhdev> nlahouti: rkukura and I will take it to the cores to get them approved as soon as this sub-team gives thumbs up
16:58:33 <rkukura> banix: ok
16:58:45 <sadasu> Sukhdev: BP is : https://review.openstack.org/#/c/95236/
16:58:58 <yamamoto> why not assert that postcommit is not in a transaction?
16:59:00 <shivharis> acknowledging bug volunteers: slogan, nlhouti, banix, padkrish_ Appreciate it !!
16:59:01 <nlahouti> sukhdev: thx
16:59:09 <nlahouti> rkukura: I updated the MD extension BP in the etherpad can you please take a look it and give comments?
16:59:15 <Sukhdev> sadasu: I reviewed it
16:59:22 <rkukura> nlahouti: will do
16:59:32 <Sukhdev> folks we are out of time…sorry
16:59:34 <chuckC> newbie question: better to have small unit test review partially fixes a bug, or do the whole bug (https://review.openstack.org/99129)
16:59:37 <amotoki> banix: I rearranged the spec review pages you created. please check it.
16:59:39 <nlahouti> rkukura: it has some sample code.
16:59:43 <sadasu> Sukhdev: yes...u posted questions...which I have answered...so can u look again, pls?
16:59:58 <Sukhdev> #endmeeting networking_ml2