14:00:53 <mestery> #startmeeting networking
14:00:53 <openstack> Meeting started Tue Apr 21 14:00:53 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:55 <fawadkhaliq> hello!
14:00:57 <openstack> The meeting name has been set to 'networking'
14:01:02 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
14:01:08 <mestery> #topic Announcements
14:01:33 <mestery> #info The RC2 is open now and all backports are proposed and in process of merging
14:01:41 <mestery> #info Expect RC2 for Neutron to land tomorrow or Thursday at the latest
14:01:48 <mestery> Thanks to all who worked tirelessly to make this happen!
14:01:54 <mestery> I have one request
14:01:56 <mestery> #link https://review.openstack.org/#/c/174228/
14:02:10 <mestery> It would be great to land that patch in master today and get it cherry-picked back to stable/kilo today as well
14:02:21 <mestery> HenryG salv-orlando amotoki: Can you guys review that one ASAP?
14:02:31 <amotoki> mestery: sure
14:02:32 <mestery> It's a security fix so landing it prior to release woudl be good
14:02:35 * salv-orlando accepts bribes for reviews
14:02:38 <armax_> hello
14:02:45 <mestery> lol
14:02:55 <mestery> armax_: Also, your eyes here would be good https://review.openstack.org/#/c/174228/
14:03:01 <salv-orlando> I thought we already approved it last weekend...
14:03:02 <mestery> See discussion above
14:03:11 <armax_> mestery: looking
14:03:23 <mestery> salv-orlando: I guess it didn't make it in
14:03:41 <mestery> Anyways, lets not bike shed on this one right now, but if we coudl, lets try to get it in shape and merged today and proposed to stable/kilo (whew!)
14:03:48 <salv-orlando> I'm not sure if we want to ask the author to address pc_m 's comments. anyway
14:04:10 <mestery> salv-orlando: Me either, I looked and would be fine either way
14:04:23 <armax_> yeah I think so
14:04:24 <mestery> pc_m: Would you be ok removing yoru -1 so we can merge https://review.openstack.org/#/c/174228/
14:04:28 <armax_> that’s user input we’re talking about
14:04:35 <mestery> armax_: Makes sense
14:04:51 <pc_m> mestery: Checking, but should be able to.
14:04:53 <mestery> OK, lets keep moving
14:05:02 <mestery> We're still in announcements
14:05:03 <mestery> :)
14:05:10 <mestery> A reminder on the mid-cycle(s)
14:05:11 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/060713.html
14:05:17 <mestery> And one more announcement
14:05:29 <mestery> #info sc68cal has volunteered to be our Nova liaison
14:05:43 <mestery> He'll be attending nova meetings and working as the go-to for nova/neutron things
14:05:46 <Sukhdev> mestery: Is agenda for mid-cycle defined yet?
14:05:46 <mestery> Thanks for volunteering sc68cal!
14:05:52 <russellb> awesome
14:05:54 <xgerman> +1
14:05:55 <mestery> Sukhdev: It's on the etherpad and forming now
14:06:02 <sc68cal> :)
14:06:13 <sballe> o/
14:06:25 <emagana_> go for it sc68cal
14:06:25 <Sukhdev> mestery: I want to suggest an item for agenda - will ping you off line
14:06:32 <mestery> Any other announcements from anyone? If not, we'll move to bugs in 60 seconds.
14:06:36 <mestery> Sukhdev: Sounds good!
14:06:46 <salv-orlando> thanks sc68cal it takes some masochism to volunteer for nova liaisoning ;)
14:06:51 <emagana_> mestery: reminder on the Doc Day
14:07:07 <mestery> emagana_: Good call! Do you ahve a link we can #link?
14:07:12 <emagana_> mestery: Networking Guide needs your love folks!
14:07:15 <emagana_> hold on!
14:07:18 * mestery waits
14:07:26 <sc68cal> salv-orlando: :)
14:07:41 <sc68cal> Oh one more thing, I'm going to be using this etherpad to collect things - https://etherpad.openstack.org/p/nova-neutron
14:08:18 <mestery> #link https://etherpad.openstack.org/p/nova-neutron
14:08:39 <amotoki> doc sprint http://lists.openstack.org/pipermail/openstack-dev/2015-April/061850.html and subsequent mails in the thread.
14:08:44 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/061850.html
14:08:56 <mestery> Thanks amotoki
14:09:05 <emagana> The etherpad is: #link https://etherpad.openstack.org/p/networking-guide
14:09:10 <mestery> #link https://etherpad.openstack.org/p/networking-guide
14:09:12 <mestery> Thanks emagana!
14:09:18 <mestery> OK, we'll move on to bugs next.
14:09:21 <mestery> #topic Bugs
14:09:24 <mestery> enikanorov enikanorov__: Hi!
14:09:30 <armax> back
14:09:37 <mestery> armax: Is that really you this time?
14:09:39 <mestery> ;)
14:10:13 <mestery> OK, in lieu of enikanorov__ enikanorov being here
14:10:23 <mestery> I wanted to thank pc_m for taking the time to go through all 38 VPN bugs last week
14:10:24 <armax> mestery: I know you skipped the last summit
14:10:32 <mestery> He triaged them, tagged them, and cleaned them up
14:10:32 <mestery> Thanks pc_m!
14:10:37 <pc_m> sure np
14:11:08 <mestery> armax: Any gate issues we should be aware of today? OR bugs trackign those gate issues?
14:11:56 <armax> I am keeping an eye on it
14:12:06 <mestery> armax: I'll take that as "we're in good shape!"
14:12:06 <mestery> ;)
14:12:12 <pc_m> armax: Did you see Jenkins for https://review.openstack.org/#/c/171874/?
14:12:14 <armax> there are a few nuisances that cause the functional job to barf, but I don’t have enough data points yet
14:12:23 <mestery> armax: Yes, I noticed that as well.
14:12:33 <armax> pc_m: of course I did, I +2 it
14:12:45 <mestery> lol
14:12:45 <pc_m> armax: Keeps failing Jenkins...
14:12:51 <armax> pc_m: or you mean the functional job?
14:12:58 <pc_m> armax: yes
14:13:07 <armax> no, that I haven’t
14:13:32 <armax> pc_m: wow, that’s bad
14:13:41 <armax> something must’ve screwed up
14:13:46 <armax> I’ll look into it
14:13:50 <carl_baldwin> I’m working on bug 1446261
14:13:50 <openstack> bug 1446261 in neutron "gate-neutron-dsvm-functional race fails HA/DVR tests with network namespace not found" [High,In progress] https://launchpad.net/bugs/1446261 - Assigned to Carl Baldwin (carl-baldwin)
14:14:03 <pc_m> armax: It had a timeout error and I did a recheck, with a bunch other errors now.
14:14:35 <salv-orlando> so is the gate actually in a terrible shape
14:14:41 <yamamoto> armax: pc_m: https://review.openstack.org/#/c/175713/
14:14:58 <armax> salv-orlando: I have seen worse
14:14:59 <ihrachyshka> how did it sneak in
14:15:15 <mestery> yamamoto: thanks
14:15:17 <amotoki> All of the failure is due to AttributeError: 'ARPSpoofTestCase' object has no attribute '_create_namespace' and the review from yamamoto seems to fix it.
14:15:34 <ihrachyshka> there should be a hole in our gate
14:15:45 <mestery> lol
14:15:54 <amotoki> oh. it is already in the gate!
14:16:02 <mestery> amotoki: I was quick
14:16:05 <mestery> yamamoto: Thanks for that!
14:16:21 <yamamoto> mestery: you're welcome!
14:16:47 * mestery waits 30 seconds for any more bugs to pop up in the meeting before moving on
14:16:54 <armax> guys it’s 7am here…slow down I can’t keep up!
14:17:03 * mestery gets armax some coffee
14:17:18 <mestery> armax: I'm on my third cup already, try to keep up! :)
14:17:22 <armax> so what is in the gate?
14:17:24 * dougwig upgrades armax to red bull
14:17:45 <anteaya> o/
14:17:47 * armax scratches his eyes and yawns still
14:17:56 <mestery> armax: https://review.openstack.org/#/c/175713/
14:17:58 <anteaya> armax: I hear ya
14:18:22 <Sukhdev> me too armax :-)
14:18:23 <armax> mestery: gotcha, I was also looking at https://review.openstack.org/#/c/175609/ and I got confused
14:18:32 <mestery> lol
14:18:46 <mestery> As amotoki said, https://review.openstack.org/#/c/175713/ appears to fix the ARPSoofTestCase failures seen recently
14:18:55 * mestery watches snow fall outside his window
14:19:14 <armax> oh I see what’s going on
14:19:21 <SridharG> Can you pls review the following patch: https://review.openstack.org/#/c/175342/
14:19:32 <armax> until we plug the hole with https://review.openstack.org/#/c/171874/ I think we’re exposed
14:20:03 <pc_m> armax: Yeah, I have a VPN commit that depends on that (the fix added in)
14:20:04 <mestery> armax: Yes, but that one will fail until https://review.openstack.org/#/c/175713/ merges, right?
14:20:14 <armax> yes
14:20:29 <HenryG> We also need https://review.openstack.org/175462 but amuller need to update it
14:20:48 * mestery hopes armax is writing all this down
14:21:32 <mestery> OK, shall we move on?
14:21:43 <salv-orlando> I have not followed the history of these issues. But can you shed some light on what led us to a situation where we need 3 indepdent patches to get to gate stability?
14:21:55 <salv-orlando> (if you want, otherwise do not mind)
14:22:02 <mestery> lol
14:22:34 <marun> Is that really unprecedented?
14:22:38 <salv-orlando> well, let's conclude that it has been an unlucky coincidence of events and move on
14:23:04 <HenryG> salv-orlando: it's all in the functional tests job
14:23:22 <mestery> Yes, lets keep rolling
14:23:24 <HenryG> the bugs are in the tests
14:23:24 <mestery> Lots more to cover
14:23:38 <salv-orlando> HenryG: do you mean that if I look at the functional test job I'll have my answers? Anyway, it does not matter - I was just curious
14:24:06 <mestery> #topic Docs
14:24:09 * mestery waves at emagana
14:24:21 <armax> salv-orlando: there was a problem with discoverability of tests whereby failures made the tests be silently dropped
14:24:23 <mestery> emagana: Looks like the sprint is coming up quickly!
14:24:24 <emagana> mestery: nothing more!
14:24:33 <mestery> emagana: :)
14:24:33 <mestery> I'll juist link it here
14:24:37 <emagana> mestery: already mentioned the sprint...
14:24:39 <mestery> #info Networking Guide Doc Day: April 23rd 2015
14:24:43 <armax> salv-orlando: therefore rather than having a failed run, we were only running only the tests that worked
14:24:47 <armax> salv-orlando: pretty nasty stuff
14:25:03 <mestery> #topic Liberty Design Summit
14:25:06 <mestery> #link https://etherpad.openstack.org/p/liberty-neutron-summit-topics
14:25:06 <salv-orlando> armax: so multiple failures sneaked it unknowingly
14:25:07 <armax> salv-orlando: that led us to the situation were errors were sneaking in undetected
14:25:13 <mestery> There are ... lots of ideas on that etherpad.
14:25:22 <armax> salv-orlando: once marun  restored order in the kingdom the errors started to pop up
14:25:25 <mestery> However, I thought it would be obvious that people should put their names next to ideas
14:25:27 <mestery> But it wasn't
14:25:33 <mestery> So, please put your names next to your ideas
14:25:51 <mestery> Otherwise, it will be hard for me to set the schedule up if I have no idea who proposed an idea
14:26:02 * mestery waits for etherpad.openstack.org to go down as people rush to fill in their names
14:26:11 <mestery> Once RC2 is out this week, I'll work in earnest to get the schedule setup
14:26:11 <salv-orlando> armax: thanks, but we moved on now. Just let's make sure that fixes are backported if they need to.
14:26:11 <xgerman> lol
14:26:23 <mestery> #link https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit#gid=569963128
14:26:25 <armax> salv-orlando: they will
14:26:27 <anteaya> if folks are seeing etherpad issues now, let us know
14:26:29 <mestery> That's the master blaster spreadsheet for the summit
14:26:43 <mestery> We have a split schedule
14:26:50 <mestery> Fishbowls in the morning, working groups in the afternoon
14:27:02 <mestery> And I'm working with nova folks (including anteaya) on a nova/neutron session around nova-network
14:27:16 <mestery> Any questions on the Summit?
14:27:37 <marun> Nova neutron interaction?
14:27:51 <salv-orlando> I think he mean joint session
14:27:56 <marun> Is there interest from nova this cycle?
14:28:17 <mestery> marun: Yes
14:28:26 <salv-orlando> I know beagles started some work, but I lost track of it back in february
14:28:27 <mestery> marun: I'm working with jonthetubaguy on this right now in fact
14:28:38 <marun> Cool
14:28:48 <mestery> marun: I expect you in attendance at that session now you realize ;)
14:29:03 <salv-orlando> mestery: if johnthetubaguy does not comply...
14:29:07 <dougwig> that's the session where the first half is nova telling us what they want, and the second half is us telling them they really don't, and why they want something else instead. it's super fun, and not at all dysfunctional.
14:29:08 <salv-orlando> I know where he lives ;)))
14:29:29 <anteaya> let's have a postive outlook please
14:29:33 <mestery> dougwig: I expect you and kevinbenton to just keep saying "provider networks" over and over.
14:29:38 <mestery> And I agree with anteaya
14:29:40 <anteaya> many people wnat to find a solution to this for many reasons
14:29:47 <mestery> anteaya: ++
14:29:49 <anteaya> let's be open to finding a solution
14:29:59 <dougwig> indeed, my positivity sounds negative before noon.  sorry. :)
14:30:07 <anteaya> okay thanks
14:30:15 <salv-orlando> mestery, anteaya, dougwig: so we definetely need a fishbowl session ;)
14:30:23 <mestery> salv-orlando: It's already penciled in ;)
14:30:35 <mestery> OK folks, if there are no more summit things, lets keep rolling
14:30:37 <salv-orlando> mestery: thanks a lot for sorting this out.
14:30:38 <anteaya> I'd prefer 12 folks in a locked room but I don't get what I want
14:30:46 <mestery> lol
14:30:51 <mestery> #topic Neutron as the default in devstack
14:30:52 <dougwig> anteaya: +1
14:30:54 <mestery> sc68cal: HEre?
14:31:01 <sc68cal> hello
14:31:07 <mestery> sc68cal: This is your section
14:31:13 <sc68cal> mestery: thanks
14:31:49 <sc68cal> So, we *do* have linux bridge almost passing at the gate. There is just some things we need to sort out for the ironic job
14:31:59 <johnthetubaguy> salv-orlando: yeah, he does know where I live. would love to catch up before the summit so the summit is more productive
14:32:10 <mestery> #info linux bridge agent passing at the gate, a few issues with the ironic job to sort out
14:32:18 <johnthetubaguy> s/he does/you do/
14:32:28 <mestery> johnthetubaguy: I've been in meetings all morning, replying to yoru email in a bit to sort that out
14:32:34 <salv-orlando> johnthetubaguy: anyplace but the pub in cambourne works for me
14:32:56 <sc68cal> I've tried to say a couple times on the ML thread that yes, there is controversy about switching to LB as default, but we get nova-network deprecated / not the default anymore
14:33:01 <sc68cal> that puts us ahead in my book
14:33:05 <johnthetubaguy> salv-orlando: lol, I am good with greens sometime, ping me
14:33:09 <salv-orlando> anyway sc68cal what's going to be the test matrix for ovs/linux bridge in the gate
14:33:27 <mestery> salv-orlando: That's really the crux of it I think
14:33:32 <sc68cal> salv-orlando: we'd add jobs to test both ovs and lb
14:33:34 <dougwig> sc68cal: i'm not sure I heard disagreement so much as the usual sdn versus flat arguments.
14:33:50 <sc68cal> i've spoken with sdague and he thinks that having jobs for ovs and jobs for lb is a good step
14:33:50 <dougwig> sc68cal: the answer to which is 'both', imo, so it's not an issue.
14:33:56 <mestery> sc68cal: ++
14:34:03 <mestery> dougwig: Exactly
14:34:14 <mestery> And I agree that getting to default to neutron with LB is a good first step
14:34:17 <mestery> Thanks for driving this sc68cal!
14:34:38 <sc68cal> can field further questions, otherwise I yield my time
14:34:55 <mestery> In the interest of keeping moving, lets take questions to you in #openstack-neutron post meeting
14:35:02 <mestery> Thanks sc68cal!
14:35:03 <sc68cal> good idea
14:35:06 <mestery> #topic Moving stackforge/networking-* repos into openstack/ and under the Neutron team.
14:35:09 <mestery> russellb: Hi!
14:35:12 <russellb> o/
14:35:28 <russellb> so ... i'm working on OVN and the stackforge/networking-ovn thing to hook Neutron up to it.
14:35:39 <russellb> It seems to me that it makes perfect sense for networking-ovn to be considered an OpenStack project
14:35:47 <russellb> all OpenStack projects are owned by an official team
14:36:03 <russellb> so, my request is to see what you all think of adopting this under Neutron
14:36:14 <russellb> and then, if yes to that, what else that implies for the rest of the networking-foo projects
14:36:33 <mestery> The obvious initial answer is: "All open source networking-foo things under stackforge"
14:36:46 <salv-orlando> russellb: while I agree that ovn is open source, and it is more suitable to be openstack than some commercial integration thing
14:36:52 <russellb> as in, networking-foo where foo is an open source thing?
14:36:59 <salv-orlando> russellb: yeah
14:37:02 <mestery> russellb: Yeah
14:37:06 <marun> I think it needs to mature before we want to take ownership.
14:37:16 <mestery> For instance, networking-odl
14:37:20 <mestery> networking-ofagent
14:37:20 <mestery> etc.
14:37:21 <salv-orlando> russellb: for instance, why should ovn be openstack and not, for instance, midonet?
14:37:29 <russellb> why not midonet?
14:37:30 <marun> We've been pushing stuff off our plate so we can focus on stabilizing common elements.
14:37:32 <mestery> salv-orlando: Yes, networking-midonet
14:37:35 <russellb> i'd argue that they should all be under neutron, personally
14:37:40 <russellb> all of them that want to be
14:37:52 <marun> russellb: someday
14:37:53 <mestery> Right, we won't just unilaterally acquire them all :)
14:37:55 <marun> But not yet
14:38:00 <armax> my take would be to defer this type of decision once we can definitely claim that the decomp effort is complete
14:38:01 <russellb> i'm also not arguing that you should have to pay attention to them
14:38:09 <russellb> let them be run like they are
14:38:12 <armax> I don’t think we’re at that point yet
14:38:13 <mestery> They have their own core review teams already
14:38:13 <egon> Maybe gate move them only at some level of maturity/usability?
14:38:15 <russellb> but recognize that they're efforts under Neutron
14:38:23 <marun> Then why do they need to be under our umbrella?
14:38:25 <salv-orlando> russellb, mestery: my only argument are that are either all openstack or none. Notwithstanding that being openstack or stackforge is pretty much just a badge for me
14:38:36 <russellb> salv-orlando: +1 fwiw
14:38:42 <mestery> +1
14:38:44 <marun> If the intent isn't to gain attention away from other more important stuffz
14:38:52 <russellb> no attention needed
14:38:56 <mestery> I'm in favor of this proposal to be honest
14:39:01 <armax> to me a namespace change makes very little difference, so either openstack or stackforge I am not really swayed one way or another
14:39:02 <mestery> These projects already have their own core teams
14:39:04 <marun> salv-orlando: +1
14:39:08 <russellb> just think it makes sense to consider it openstack, get ATC status, etc
14:39:09 <mestery> We just want them in our (bigger) tent
14:39:12 <mestery> Big Tent!
14:39:20 <mestery> It's a networking big tent!
14:39:23 <dougwig> can i suggest a spec in gerrit where the discussion can continue?
14:39:34 <armax> but I’d rather have less churn for the time being
14:39:35 <mestery> Or a patch to project-config?
14:39:35 <salv-orlando> it used to be a tent. Now it's a stadium
14:39:39 <mestery> lol
14:39:40 <russellb> what would a spec say
14:39:47 <mestery> I'd say a patch in gerrit
14:39:51 <mestery> russellb: What agbout that?
14:39:52 <russellb> it's a 1 line governance repo patch
14:40:03 <mestery> Yup
14:40:03 <mestery> We coudl discuss there?
14:40:04 <russellb> i can do that ..
14:40:17 <dougwig> russellb: under devref, a new process for networking- stackforge projects to be considered under the neutron project in openstack/
14:40:32 <mestery> I sense we won't get to conclusion in this meeting on this issue, thus the patch for discussion?
14:40:39 <salv-orlando> mestery: yes the discussion should be move there. It's one of those things where people outside of neutron would probably like to chime in
14:40:44 <mestery> dougwig: So, in neutron not neutron-specs? Interesting.
14:40:45 <armax> it’s not about the complexity of the change per se
14:41:26 <armax> I just don’t like the idea of changing something like a namespace whilst things in flight
14:41:27 <mestery> I think it's simply a matter of moving open source thigns from stackforge to neutron
14:41:31 <mestery> No change to core teams
14:41:34 <mestery> they already have their own
14:41:37 <mestery> They just fall into our stadium
14:41:45 <mestery> What issues do people have with that?
14:41:46 <russellb> i think they should have all been openstack/* in the first place, personally :)
14:41:54 <dougwig> as defined today, it does add load to these specs team.
14:41:59 <russellb> anyway, will propose some stuff in gerrit.
14:42:00 <dougwig> /these/the/
14:42:07 <ihrachyshka> russellb, arista? midonet? bigswitch? cisco? all of them?
14:42:15 <salv-orlando> hdn?
14:42:17 <ijw> You called?
14:42:20 <russellb> all of them that want to be, yes
14:42:21 <mestery> *sigh*
14:42:24 <dougwig> salv-orlando: of course hdn.
14:42:49 <mestery> #action russellb to propose patch to governance to move stackforge networking-foo projects under neutron
14:42:53 <salv-orlando> dougwig: I have also a blueprint for "mmaas" - middle man as a service.
14:42:53 <russellb> and meet base openstack project criteria, passes the "one of us" test
14:43:11 <egon> +1
14:43:19 <russellb> mestery: i'd prefer to only propose ovn, because others should make a positive action to indicate they want to
14:43:27 <mestery> russellb: Makes sense
14:43:38 <russellb> but i can also write some neutron docs around it
14:43:40 <mestery> Honestly
14:43:45 <mestery> In the spirit of the giant stadium
14:43:51 <mestery> I think we'll open the floodgates
14:43:52 <mestery> But
14:44:02 <mestery> Maybe that's ok
14:44:03 <salv-orlando> also because I frankly do not think "benefits" like ATC status should be given to contributors whose only goal is integrating a specific technology with neutron
14:44:03 <mestery> I don't know
14:44:21 <salv-orlando> you have to bring some benefits to the project - either to its user, to it developers, or operators.
14:44:29 <emagana> salv-orlando: +1
14:44:52 <salv-orlando> but if you do integration only with your technology, and that's commercial, you're likely to be benefiting only your employer and/or your customers
14:44:59 <marun> I think the onus is on these projects to justify being in the namespace.
14:45:03 <mestery> marun: ++
14:45:05 <salv-orlando> for instance, would you every take stackforge/vmware-nsx to be an openstack project?
14:45:18 <marun> The default, frankly, should be 'no'.
14:45:20 <salv-orlando> s/every/ever/
14:45:21 <amotoki> one point I would like to say from another view is what is a difference between dirvers for opensource one and vendor one. For cinder, driver maintainers will get ATC status and for neutron NOT. It is inconsistent.
14:45:39 <mestery> amotoki: Not true, we still have shims in-tree
14:45:46 <marun> Why does consistency matter, exactly?
14:45:49 <mestery> amotoki: Also, we're a year ahead of cinder
14:45:53 <mestery> They are lagging us by a year
14:45:59 <amotoki> mestery: right.
14:46:01 <salv-orlando> amotoki: that is a fair point, but I'm not entirely sure that cinder is doing the right thing. Still we should be consistent.
14:46:03 <mestery> they will get to decomp once they realize what a mess it is to have everything in-tree
14:46:07 <mestery> salv-orlando: ++
14:46:10 <amotoki> i just want to raise a question we will have.
14:46:12 <mestery> salv-orlando: -- to consistent
14:46:17 <mestery> Why do we need to be consistent?
14:46:28 <marun> I'd rather we do right by our project than be consistent for its own sake.
14:46:32 <mestery> We can't force cinder to adopt our policies much as they can't force us to adopt theirs.
14:46:33 <mestery> marun: ++
14:46:37 <salv-orlando> mestery: by "we" I meant us and cinder... cinder should be consistent with us, I think ;)
14:46:50 <anteaya> amotoki: I am working to try to bring projects with third party interactions to more consistency but there is work to do
14:46:50 <mestery> salv-orlando: Fair enough
14:46:52 <emagana> mestery: because neutron by itself is nothing.. we all together are openstack!
14:46:52 <marun> salv-orlando: if it makes sense for them, sure.
14:47:06 <mestery> emagana: That's great in theory, but each project is also a microcasm
14:47:09 <salv-orlando> marun, mestery: right. Ultimately it's their call.
14:47:17 <marun> But different community, different vendors, maybe the same rules don't make sense?
14:47:17 <mestery> Lets not get into forcing poilicy and culture from the top down
14:47:20 <emagana> mestery: well, we need to find the way to influence properly the other teams
14:47:22 <mestery> That's a shed I have no interest in painting today
14:47:33 <mestery> OK
14:47:34 <mestery> Lets move on
14:47:38 <salv-orlando> as russellb pointed out being "openstack" is just a badge from a technical perspective, but brings some benefits such as ATC status
14:47:38 <mestery> We're done here with this for now.
14:47:40 <mestery> #topic LBaaS
14:47:42 <salv-orlando> ok done
14:47:45 <mestery> xgerman: You're up!
14:47:51 <emagana> mestery: in every operators meetup... neutron is the weak link.. and we are doing the best compare with other projects.. mmhh something is wrong!
14:47:57 <xgerman> I am
14:48:24 <mestery> xgerman: What did you want to discuss today?
14:48:37 <xgerman> So we ran into the problem that you can specify a random (non existant) tenant-id when you are crerating an lb as an admin
14:48:40 <dougwig> from his agenda item: "We ran into the problem that if an admin user adds a loadbalancer he can specify any, even a wrong id. We have been referred to https://bugs.launchpad.net/neutron/+bug/1200585 and we don't agree with the consensus that because an admin knows what they are doing there shouldn't be any validation/verification of that parameter."
14:48:40 <openstack> Launchpad bug 1200585 in neutron "floatingip-create doesn't check if tenant_id exists or enabled" [Undecided,Invalid] - Assigned to Jian Wen (wenjianhn)
14:48:46 <xgerman> we feel that this tenant-id should be validated
14:49:07 <xgerman> and when we file that bug we always get told that bug already covers it
14:49:18 <salv-orlando> xgerman: the same applies to every operation
14:49:21 <xgerman> and I disagree that an admin can't make mistakes and we should balidate
14:49:53 <dougwig> salv-orlando: i think he's disagreeing with the general answer, not that it relates.
14:49:55 <mestery> xgerman: Seems like as salv-orlando indicates, this is the same for every operation
14:49:58 <salv-orlando> xgerman: that's fine by me. Doing a validation requires an extra round trip to keystone or some sort of cache
14:50:15 <salv-orlando> if you can make that in a way that it does not affect scalability I'm fine to have it
14:50:25 <salv-orlando> so that we can go and implement that validation also in nova for instance
14:50:46 <egon> Is there any value to an admin being able to create an LB for an ID that is *going* to exist?
14:50:47 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1200585
14:50:47 <openstack> Launchpad bug 1200585 in neutron "floatingip-create doesn't check if tenant_id exists or enabled" [Undecided,Invalid] - Assigned to Jian Wen (wenjianhn)
14:50:51 * mestery links the bug for meeting logs
14:50:52 <xgerman> ok, so we all agree it should be done but we don't know how
14:51:08 <marun> Admin use isn't likely to cause a scale issue
14:51:10 <xgerman> egon, yes: If you get a support call
14:51:26 <xgerman> marun +1
14:51:36 <marun> How does nova handle this?
14:51:52 <marun> All openstack projects must have this problem
14:52:00 <salv-orlando> marun: yeah they have
14:52:27 <salv-orlando> Some might have added a keystone check in the pipeline in the meanwhile but I'm not aware of that
14:52:30 <marun> salv-orlando: they have the problem or already address it?
14:52:42 <salv-orlando> I think the tenant-id is not validated.
14:52:58 <salv-orlando> which btw is project-id in most projects now
14:53:08 <egon> xgerman: I agree with the support call case, but doesn't that argue for not validating?
14:53:21 <xgerman> people mistype stuff all the time
14:53:36 <xgerman> so I am advocating for validating
14:53:53 <marun_> this sounds like something keystone middleware should take care of
14:54:01 <marun_> rather then every project doing it independently
14:54:05 <mestery> marun_: ++
14:54:26 <mestery> What is the action item here then>
14:54:27 <mestery> ?
14:54:42 <mestery> xgerman: Are you going to talk to the keystone folks to see what can be done there?
14:54:50 <xgerman> yes, will do
14:54:56 <marun> keystone middleware -> keystone client api
14:55:16 <xgerman> #action xgerman talk to keystone about project id validation
14:55:19 <marun> Since we won't know whether validation is required until after the initial auth check
14:55:20 <mestery> Thanks xgerman !
14:55:32 <mestery> OK, < 5 minutes left lets move on
14:55:33 <mestery> #topic neutron-lib
14:55:35 <mestery> dougwig: 4 minutes sir :)
14:55:38 <dougwig> https://review.openstack.org/#/c/154736/
14:56:17 <mestery> #link https://review.openstack.org/#/c/154736/
14:56:35 <dougwig> this agenda item is to get some eyeballs on the neutron-lib spec.  we'd like to get some of the groundwork laid *before* the summit, so we can do some work during one of the friday sprints.  if the summit decides against it, we can always abandon, but i can't speed up the repo creation/skeleton process.
14:57:03 <mestery> dougwig: Note we only have a single firday sprint in the morning
14:57:17 <mestery> #info Please review neutron-lib sprint so we can work to consensus and use sprint time at the summit to make progress
14:57:22 <mestery> Thanks dougwig!
14:57:23 <anteaya> dougwig: I suggested to mestery and I'll suggest to you it wouldn't hurt to have an item on the infra agenda to ensure the steps for splitting are supported
14:57:32 <mestery> #topic Open Discussion
14:57:34 <dougwig> anteaya: it's already there for today.  :)
14:57:37 <xek> I'd like to mention that I submitted a spec for versioned-objects https://review.openstack.org/168955
14:57:42 <anteaya> dougwig: awesome thanks
14:57:46 <salv-orlando> mestery: if neutron-lib is approved.... why don't we agree to put on hold all the other "refactorings"
14:57:50 <xek> there will also be two meetings (hopefuly) related to versioned-objects at the summit https://etherpad.openstack.org/p/liberty-oslo-summit-planning
14:57:58 <salv-orlando> we know we can hardly deal with one.
14:58:03 <mestery> salv-orlando: Even the splitting out of the reference implementation?
14:58:14 <mestery> #link https://review.openstack.org/168955
14:58:16 <mestery> thanks xek!
14:58:17 <marun> if we split out the reference impl, that will change the game for neutron lib I think
14:58:25 <xek> (I'll be at the summit)
14:58:49 <salv-orlando> mestery: possibly, but I do not know how many things pertaining to agents neutron-lib refactoring will touch
14:59:03 <mestery> I think we have to split out the reference implementation
14:59:04 <dougwig> marun: i've heard that, and i'd like to hear more.  i'm not sure i agree, since neutron will still be about agents and rest and whatnot.  it'll get skinnier, yes.
14:59:07 <mestery> I'll work with dougwig on the order there
14:59:11 <salv-orlando> knowing how entangled things are in neutron, I would be cautious
14:59:16 <mestery> salv-orlando: ++
14:59:16 <marun> dougwig: agents get shunted out
14:59:18 <mestery> Wise words
14:59:21 <mestery> OK 30 seconds left
14:59:21 <marun> dougwig: they are part of ref impl
14:59:24 <mestery> Thanks for attending!
14:59:31 <mestery> Be on the lookout for an RC2 in the next two days!
14:59:32 <salv-orlando> adieeeuuuuu
14:59:34 <xgerman> bye
14:59:38 <mestery> #endmeeting