15:04:43 <carl_baldwin> #startmeeting neutron-drivers
15:04:44 <openstack> Meeting started Tue Jul 14 15:04:43 2015 UTC and is due to finish in 60 minutes.  The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:48 <openstack> The meeting name has been set to 'neutron_drivers'
15:05:06 <carl_baldwin> #topic wiki
15:05:21 <carl_baldwin> #action carl_baldwin will fix up the wiki after the meeting to show the correct time and channel.
15:05:37 <carl_baldwin> kevinbenton: dougwig: ping
15:06:03 <carl_baldwin> amotoki_: Just the two of us from the drivers team so far.  :)
15:06:14 <carl_baldwin> #topic Get me a Network
15:06:28 <carl_baldwin> haleyb: sc68cal: Are you around?
15:06:43 <carl_baldwin> #link https://review.openstack.org/196803
15:06:44 <haleyb> carl_baldwin: in three places at once :)
15:06:54 <sc68cal> carl_baldwin: looking
15:07:02 <amotoki_> haleyb: :-)
15:07:09 <haleyb> that looks like the dvr patch
15:07:24 <haleyb> oh, it's not
15:07:54 <amotoki_> it was merged. I just wonders where we are collecting infomration.
15:08:10 <carl_baldwin> Looks like it was approved.  Do we need to discuss it further here?
15:08:24 <sc68cal> I'm good with it
15:08:28 <carl_baldwin> amotoki_: What sort of information?  Design?
15:08:41 <haleyb> i need to work on the RFE, but wanted to discuss with mark mcclain about some options
15:08:42 <amotoki_> carl_baldwin: which blueprint? which bug?
15:09:28 <carl_baldwin> haleyb: Is the rfe filed?  If so, do you have URL?
15:09:54 <haleyb> carl_baldwin: no, it's not filed yet
15:10:03 <amotoki_> we need to have a RFE bug to track the progress.
15:10:11 <amotoki_> haleyb: could you file it?
15:10:53 <haleyb> amotoki: i will do it by tomorrow
15:11:07 <carl_baldwin> haleyb: Thanks.
15:11:09 <amotoki_> haleyb: thanks
15:11:26 <carl_baldwin> #topic Segmented, L3-Only routed networks
15:12:01 <carl_baldwin> I feel like we got good consensus on https://review.openstack.org/#/c/196812
15:12:10 <carl_baldwin> neiljerram: Do you have the link handy to yours?
15:12:19 <neiljerram> Just a mo...
15:12:31 <amotoki_> carl_baldwin: i could not find time to review it last week. will look it.
15:12:46 <neiljerram> carl_baldwin: https://review.openstack.org/#/c/198439/
15:13:05 * kevinbenton is watching meeting on phone
15:14:13 <sc68cal> neiljerram: I saw the conversation posted in the comments between you and carl_baldwin - the takeaway I got was that the implementation will differ, but does it have to differ all the way up into the API?
15:15:07 <neiljerram> sc68cal: I don't think we know that yet.  But certainly the use cases differ a bit.
15:15:38 <sc68cal> nibalizer: thanks - I guess I want to at least keep it to one kob or dial to cover both your usecases, if at all possible
15:15:45 <sc68cal> *knob
15:16:07 <neiljerram> sc68cal: Well I'm personally absolutely open to that.
15:16:14 * sc68cal has regrets sometimes about the two ipv6 attrs
15:16:30 <neiljerram> sc68cal: Ah yes, indeed, I wondered about those :-)
15:16:35 <carl_baldwin> sc68cal: I think that knob is the network type.  Each of our proposals uses a different provider network type to distinguish.
15:17:26 <carl_baldwin> The way my proposal models segments with Neutron networks doesn’t seem to make sense for a pure L3 network.
15:17:29 <carl_baldwin> sc68cal:
15:17:36 <carl_baldwin> Is there more you might suggest?
15:17:50 * sc68cal is pulling up carl_baldwin's spec
15:18:15 <carl_baldwin> neiljerram: Is there an rfe filed for this?  My quick glance over the list didn’t see one.
15:18:19 <neiljerram> sc68cal: But I'm concerned we're getting slightly ahead of ourselves...  In this meeting, what I'd really appreciate is just a decision on whether I can continue work on my use case, and if so in what form (a spec?)
15:18:29 <neiljerram> Yes, there is an RFE...
15:18:37 <amotoki_> i haven't follow both of them, but it seems we need a bug for neiljerram case and if possible we need to coordinate both
15:18:41 <neiljerram> https://bugs.launchpad.net/neutron/+bug/1472704
15:18:41 <openstack> Launchpad bug 1472704 in neutron "Support networks that work through routing instead of bridging" [Undecided,New]
15:19:27 <markmcclain> hate to be the bearer of bad news, but as spec'd this will break lots of apis
15:19:29 * carl_baldwin would’ve found it had I searched for routing instead of routed.
15:19:44 <carl_baldwin> markmcclain: elaborate?
15:20:05 <carl_baldwin> markmcclain: One or the other or both?  In what way?
15:20:15 <markmcclain> 196812
15:20:30 <markmcclain> the front network is supposed to hide the backing networks
15:20:44 <markmcclain> but teh port info object will have the backing networks as the network_id
15:21:07 <markmcclain> so tooling will break where it's trying to find the network_id
15:21:13 <carl_baldwin> kevinbenton: dougwig: amotoki_: BTW, did we ever write down a decoder for the various rfe bug statuses and other bug fields?
15:21:39 <kevinbenton> Not that I know of
15:21:42 <markmcclain> even if we lie in the response and return the front net-id it will break the internals of many plugins
15:22:52 <carl_baldwin> markmcclain: The network still exists.  The only thing that hides it is the owner is admin and it is not shared.  Do the plugins expect it to be visible to the tenant?
15:23:11 <markmcclain> yes
15:23:31 <markmcclain> otherwise when I do port-list as a tenant I think I'm getting bad data
15:23:44 <markmcclain> because there is no way to correlate the port to a network
15:24:43 <kevinbenton> So main issue is that we lose whatever parent network the person requested?
15:24:52 <markmcclain> right
15:24:59 <carl_baldwin> markmcclain: Please add that feedback to the review and we can discuss further.  This had crossed my mind and we should discuss it more.
15:26:41 <kevinbenton> carl_baldwin: check out _model_query in the base plugin
15:27:03 <kevinbenton> carl_baldwin: that's the bit that scopes db queries to tenants
15:27:26 <carl_baldwin> Let’s add this feedback to the review and continue there.
15:27:47 <kevinbenton> carl_baldwin: which lots of plugins use
15:29:49 <carl_baldwin> We also need more input on neiljerram ’s rfe, especially how it relates to this one.  amotoki_:  will you review them?  sc68cal: Will you try to elaborate on what you think needs to improve?
15:30:04 <amotoki_> carl_baldwin: sure
15:30:16 <neiljerram> amotoki_: Thanks
15:30:27 <carl_baldwin> We’ll discuss again next week and collecting some more thoughts.
15:30:48 <neiljerram> Shall I put up a Gerrit job as a spec, though?
15:31:11 <neiljerram> I think that's probably a more useful format than an RFE bug?
15:32:08 <amotoki_> neiljerram: what do you mean? elaborate?
15:32:31 <carl_baldwin> kevinbenton: amotoki_:  Would a spec help?  spec, devref?  I’m confused about what the process should be myself.
15:33:02 <amotoki_> carl_baldwin: me too. we need to calrify we use neutron-sepcs or devref to discuss details.
15:33:09 <neiljerram> amotoki_: Well, so far I've followed a slightly confused process here.  I began as a devref, because that's what Carl's similar spec was.
15:33:34 <sc68cal> carl_baldwin: I think your point about it just being a type inside the provider attrs is correct
15:33:47 <sc68cal> so I think my concern is addressed
15:34:07 <neiljerram> Neutron process is to file an RFE, but I think part of the motivation there is to allow folk to describe _what_ they want when they don't yet know _how_ to achieve that.
15:34:28 <amotoki_> neiljerram: good point.
15:34:34 <neiljerram> In my case, I already have a good idea how to achieve it, so suspect that a spec (or devref) is the better format.
15:34:41 <amotoki_> personally specs repo works more because neutron repo has many reviews.
15:34:49 <neiljerram> (Although also very open to people telling me that there is a better way!)
15:35:33 <carl_baldwin> Sounds like we still don’t have consensus on when a spec vs devref should be used.
15:35:57 <kevinbenton> I'm fine with either
15:36:10 <kevinbenton> If it's in neutron I will actually pay more attention to it
15:36:26 <kevinbenton> I always forget to look at neutron-specs
15:36:49 <neiljerram> kevinbenton: You're definitely pushing me one way! :-)
15:37:04 <carl_baldwin> I’m fine with either and I propose that we keep the devref linked to the rfe for now and we’ll follow up to clarify the process.
15:37:14 <kevinbenton> neiljerram: Yeah, the rfe is where quit if you don't care about the implementation
15:37:28 <carl_baldwin> #action carl_baldwin will follow up to clarify when specs should be used and when devrefs.
15:37:37 <kevinbenton> neiljerram: since you want to develop this, writing the spec/devref makes more sense
15:37:49 <neiljerram> OK, great, thanks.  I'll carry on with the devref for now.
15:37:57 <amotoki_> i am fine with either. once the process is clarified.
15:38:18 <carl_baldwin> Thanks.
15:38:31 <carl_baldwin> Let’s move on.  There are a bunch of other rfes.
15:40:09 * carl_baldwin is still confused about rfe bug “status”, “importance”, and “milestone"
15:40:33 <carl_baldwin> There are three rfe bugs marked “new”
15:40:45 <carl_baldwin> One is the one we’ve just been discussing.
15:41:30 <carl_baldwin> Here is the next:  https://bugs.launchpad.net/neutron/+bug/1468934
15:41:30 <openstack> Launchpad bug 1468934 in neutron "Neutron might use robust quota enforcement" [Wishlist,New]
15:42:05 <amotoki_> it is about better quotas blueprint and just a conversion. I think we can mark it as triaged.
15:42:09 <carl_baldwin> Looks like this is salv-orlando ’s long lost rfe.
15:43:22 <kevinbenton> I think this is good
15:43:49 <amotoki_> I changed it to Triaged.
15:43:52 <carl_baldwin> Anyone have a link to the bug handy?
15:44:02 <neiljerram> https://bugs.launchpad.net/neutron/+bug/1468934
15:44:02 <openstack> Launchpad bug 1468934 in neutron "Neutron might use robust quota enforcement" [Wishlist,Triaged]
15:44:02 <salv-orlando> carl_baldwin: yeah I was submitting bugs against vmware-nsx and ended up reporting the rfe against vmware-nsx too!
15:44:02 <carl_baldwin> s/bug/bp/
15:44:05 <kevinbenton> Because right now anyone can get (number of API workers in the entire datacenter) over their quota
15:45:15 <neiljerram> Is this the BP? https://blueprints.launchpad.net/neutron/+spec/better-quotas
15:46:01 <carl_baldwin> So, are we beating a dead horse here?  salv-orlando, was this already approved?
15:46:20 <carl_baldwin> If not, I’m +1 for this and I think it is good.
15:46:40 <salv-orlando> carl_baldwin: the spec was approved for kilo. I failed resubmitting it by liberty-1 and then filed a RFE
15:46:41 <kevinbenton> +1
15:46:53 <amotoki_> +1
15:47:06 <salv-orlando> I hope I followed the process in a correct and pedant way
15:47:20 <carl_baldwin> I think we’re all good to go.
15:47:20 <salv-orlando> now if you excuse me I have a yak to shave
15:47:34 <kevinbenton> dougwig: you've been awfully quiet
15:49:13 <carl_baldwin> The next new one is https://bugs.launchpad.net/neutron/+bug/1472727
15:49:13 <openstack> Launchpad bug 1472727 in neutron "Subnet pools and the quota on subnets" [Undecided,New]
15:50:58 <kevinbenton> Those both have the word quota in them, that means salv-orlando will do it :)
15:51:09 <carl_baldwin> I think I need to read this some more.  It doesn’t quite make sense to me what the submitter is after.
15:51:30 <carl_baldwin> I’ll also ask tidwellr to read it and comment.
15:51:37 <carl_baldwin> So, let’s leave it for next week.
15:51:41 <amotoki_> I havent understood what is really requested...
15:52:20 <kevinbenton> It seems the idea is to restrict a tenant to X subnetpools
15:52:28 <kevinbenton> Where X is this new quota
15:52:47 <carl_baldwin> kevinbenton: That is pretty close to what I was thinking.
15:52:58 <kevinbenton> But I'm not sure I understand why
15:53:02 <carl_baldwin> #topic rfes
15:53:07 * carl_baldwin forgot to change the topic.
15:53:19 <carl_baldwin> kevinbenton: Me neither
15:53:38 <carl_baldwin> Do we need to go through the rfe bugs marked confirmed here?
15:53:54 <salv-orlando> re bug 1472727 I reckon the drivers team should ask for clarifications
15:53:54 <openstack> bug 1472727 in neutron "Subnet pools and the quota on subnets" [Undecided,New] https://launchpad.net/bugs/1472727
15:54:16 <kevinbenton> carl_baldwin: Yeah, for this one mark it as incomplete
15:55:18 <carl_baldwin> kevinbenton: I had just marked it incomplete when I read that.  :)
15:57:00 <kevinbenton> Ok, shall we end this?
15:57:21 <kevinbenton> Or do we want to wait for dougwig to give us the all clear :)
15:57:34 <carl_baldwin> I’ll take my action items to clarify a few things around process.  We’ll probably have a discussion or two on the ML.
15:57:56 <carl_baldwin> Anything else for today?
15:58:13 <amotoki_> none from me
15:58:19 <kevinbenton> Nope
15:59:51 <carl_baldwin> Thanks!
16:00:00 <carl_baldwin> #endmeeting