15:00:18 <mestery> #startmeeting neutron-drivers
15:00:19 <openstack> Meeting started Tue Jul 21 15:00:18 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:23 <openstack> The meeting name has been set to 'neutron_drivers'
15:00:26 <carl_baldwin> hi
15:00:32 <mestery> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers Agenda
15:00:50 <mestery> OK, lets get started, I'd like to just walk through some RFE bugs today.
15:00:57 <mestery> Does anyone have any other agenda items?
15:01:09 <mestery> #link https://goo.gl/xtBJkU RFE bug link
15:02:07 <mestery> #link https://goo.gl/xtBJkU
15:02:09 <mestery> #undo
15:02:10 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0xad70250>
15:02:14 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1370033
15:02:15 <openstack> Launchpad bug 1370033 in neutron "Admin should be able to manually select the active instance of a HA router" [Medium,Confirmed] - Assigned to yong sheng gong (gongysh)
15:02:16 <uvirtbot> Launchpad bug 1370033 in neutron "Admin should be able to manually select the active instance of a HA router" [Medium,Confirmed]
15:02:17 <uvirtbot> Launchpad bug 1370033 in neutron "Admin should be able to manually select the active instance of a HA router" [Medium,Confirmed] https://launchpad.net/bugs/1370033
15:02:51 <mestery> This one needs a spec, which I've commented on
15:02:59 <neiljerram> Hi there.
15:03:00 <mestery> Anyone want to add color to this particualr bug?
15:03:07 <mestery> neiljerram: Greetings!
15:03:17 <neiljerram> Just reminder that I think you wanted to look at my RFE/devref.
15:03:26 <neiljerram> But perhaps that comes under the general RFE section
15:03:50 <mestery> neiljerram: Lets do that one now, do you have a link?
15:04:19 <neiljerram> https://review.openstack.org/#/c/198439/
15:04:30 <mestery> #link https://review.openstack.org/#/c/198439/
15:04:30 <amotoki> mestery: does a spec means to use neutron-spec?
15:04:58 <amotoki> I remember we had a question which we use spec repo or devref last week.
15:05:12 <mestery> amotoki: Yes
15:05:35 * carl_baldwin did not finish the follow-up for that question
15:05:43 <amotoki> we still continues to use neutron-spec. clear!
15:06:07 <mestery> amotoki: ++
15:06:12 <mestery> neiljerram: So, looks like armax had an interesting comment on this devref
15:06:17 <mestery> carl_baldwin: ^^^ See armax'scomment as well
15:06:30 <neiljerram> Yes.  I was just about to get to that.
15:06:51 <neiljerram> He had good comments on the DHCP change, too.
15:06:58 <mestery> armax always has good comments :)
15:07:10 <mestery> I think the thing is, the model being proposed is obviously calico specific
15:07:59 <neiljerram> I've tried to draw a line between something that would be a useful more-generic Neutron concept, on one hand, and the specific Calico implementation, on the other hand
15:08:23 <mestery> neiljerram: Have you considered armax's idea about the type driver living in networking-calico?
15:08:37 <mestery> That might be a good place for it to start, but it may tie it even closer to calico.
15:08:38 <neiljerram> Yes.
15:08:44 <mestery> I also worry about how this work will tie into and possibly derail carl_baldwin's routed network work
15:08:53 <mestery> I don't want to slow that down given the operator requirements there
15:09:18 <neiljerram> Agreed, and I am trying to help there too.
15:09:37 <mestery> Excellent! I do appreciate your help in all these areas :)
15:09:59 <neiljerram> But also - to be clear - my team has many partners who are very interested in the Calico approach, and would love that to be under Neutron's wing, in some sense.
15:10:21 <mestery> Ugh, net split :(
15:10:24 <carl_baldwin> I keep getting comments from people that mine and neiljerram ’s proposals should be aligned more.  But, I still am having trouble seeing how they can be combined.
15:10:46 <mestery> neiljerram: If you were to keep the type driver in networking-calico, it's part of neutron, as that project is under the neutron stadium
15:10:54 <neiljerram> Sure, yes.
15:10:56 <mestery> It could evolve there, similar to other things like L2GW, SFC, etc.
15:11:06 <mestery> I'm just thinking out loud here
15:11:26 <neiljerram> The only specific thing why I need something in core Neutron, is to act as a trigger for the DHCP agent changes that we need.
15:11:49 <mestery> neiljerram: Is that in the devref? I'm looking again.
15:12:00 <neiljerram> That's a different change...
15:12:12 <neiljerram> https://review.openstack.org/#/c/197578/
15:13:46 <mestery> neiljerram: Yes, I've reviewed that a bit.
15:13:53 * carl_baldwin realizes he needs to look over that change.
15:14:29 <neiljerram> In other words it boils down to: if I want to make a DHCP agent change that is triggered by my particular network:provider-type, does that network:provider-type need to exist in core Neutron, in order to motivate that?
15:14:30 <amotoki> neiljerram: i haven't looked thru your reviews, but is there any pointer which describes the mertis of your approach from oeprators perspective?
15:15:03 <neiljerram> amotoki: Yes, sure, although not really in the review jobs I have up at the moment.
15:15:38 <amotoki> if we go to the way of a new type driver, we need to have a guidance of choosing a type driver. It is the one of the hearts of RFE.
15:15:39 <neiljerram> amotoki: Those are more written from a dev/community perspective.
15:16:07 <neiljerram> amotoki: Not quite sure what you mean there...
15:17:13 <mestery> I think we need to discuss this in the broader neutron meeting. carl_baldwin amotoki: What do you think?
15:17:20 <amotoki> neiljerram: I am trying to understand the motivation, but perhaps I need to read yours more and it will answer it.
15:17:33 <mestery> These changes are fundamentally changing the underlying neutron logical model, and I'm still concerned that we'll have this implementation and carl_baldwin's version of routed networks
15:17:37 <mestery> And they will be different
15:17:38 <amotoki> mestery: agree.
15:17:39 <mestery> And we'll have a mess
15:17:49 <neiljerram> amotoki: In broad terms, we many partners who like the simplicity of our approach.
15:17:52 <mestery> #info Discuss neiljerram's routed network and DHCP changes in meeting next week
15:18:07 <neiljerram> amotoki: But I can certainly find more for you than that, I think.
15:18:22 <mestery> OK, lets discuss in a future meeting, neiljerram, pelase add this to the agenda here: https://wiki.openstack.org/wiki/Network/Meetings under "On Demand"
15:18:25 <carl_baldwin> Now that I have a pretty good understanding of the calico ML2 piece, I need to wrap my head around this DHCP change.
15:18:46 <neiljerram> OK, thanks everyone for considering this!
15:19:08 <amotoki> neiljerram: perhaps what yoru partners see is one of the answers. let me check this week.
15:19:14 <mestery> cool, thanks neiljerram carl_baldwin amotoki
15:19:16 <carl_baldwin> #action carl_baldwin will review DHCP change.
15:19:20 <mestery> awesome
15:19:21 <mestery> OK
15:19:22 <mestery> lets move on
15:19:30 <mestery> I know rmoats had one for us to discuss
15:19:32 <mestery> rmoats: You around?
15:20:27 * mestery waits 60 seconds for rmoats to jump up
15:20:27 <rmoats> here
15:20:32 <mestery> excellent!
15:20:37 <mestery> Have a link to your RFE?
15:20:52 <rmoats> I was afraid you were going to ask for that :)
15:21:31 <mestery> lol
15:21:57 <rmoats> https://bugs.launchpad.net/neutron/+bug/1475736
15:21:58 <openstack> Launchpad bug 1475736 in neutron "Add instrumentation to Neutron" [Undecided,New]
15:21:59 <uvirtbot> Launchpad bug 1475736 in neutron "Add instrumentation to Neutron" [Undecided,New]
15:22:00 <uvirtbot> Launchpad bug 1475736 in neutron "Add instrumentation to Neutron" [Undecided,New] https://launchpad.net/bugs/1475736
15:22:39 <rmoats> (found it)
15:22:45 <mestery> rmoats: Are you going to work on this one should it get approved?
15:23:00 <rmoats> mestery: yes - I'm planning on putting in the cycles
15:23:17 <rmoats> and grabbing other resources as needed
15:23:37 <mestery> OK
15:23:50 <rmoats> I don't foresee this landing fulling in liberty
15:23:58 <mestery> :)
15:24:03 <rmoats> parts, hopefully :)
15:24:07 <mestery> rmoats: That's good, because I don't either ;)
15:24:13 <rmoats> but it will stretch into mitaka
15:24:17 <rmoats> and maybe beyond
15:24:36 <rmoats> note: this will be a lightning talk at the operator midcycle next month
15:24:58 <amotoki> we have several similar proposals: statistics, logging, usage, and so on.
15:25:31 <amotoki> one of big questions is how we define API URL structure.
15:25:42 <mestery> ++
15:26:13 <rmoats> amotoki: what do you see the API URL structure doing?
15:26:19 <mestery> So, this seems pretty straightorward to me, the hardest part will be coalescing with the other projects and the ceilometer integration
15:26:33 <rmoats> mestery: that's not in this rfe
15:26:46 <rmoats> on purpose - that's a separate headache
15:26:49 <mestery> rmoats: The ceilometer integration?
15:27:04 <rmoats> yes... that's *not* part of this rfe
15:27:15 <mestery> This RFE is just about collecting and storing the statiscis?
15:27:24 <rmoats> mestery: yes
15:27:28 <amotoki> rmoats: if so my comment is a bit different
15:27:31 <rmoats> more collecting
15:27:45 <rmoats> I'm not really interested in becoming big data
15:28:11 <mestery> lol
15:28:24 <amotoki> for logging or usage, others requests REST API to retrieve usage or logging of event (e.g, operations for resources, seggroup logging... )
15:28:36 <amotoki> rmoats: reasonalbe requests to me.
15:28:44 <rmoats> amotoki: yes, that's why I asked what the API URL would be for
15:29:10 <mestery> There's no API proposed here, this is literally just collecting and storing stats
15:29:10 <amotoki> rmoats: thanks for the clarification.
15:29:12 <mestery> Am I right?
15:29:29 <amotoki> do we need a counterpart for ceilometer?
15:29:42 <rmoats> amotoki: yes, if you look at the etherpad, that is part II
15:29:43 <mestery> amotoki: That's what I was thinking
15:30:08 <rmoats> mestery: my hope was to avoid storing large amounts of data
15:30:24 <mestery> rmoats: OK, so more of a cache until it lands somewhere like ceilometer?
15:30:30 <rmoats> mestery: ++
15:31:42 <carl_baldwin> I’m not following.  We’re going to collect data and then do what with it?
15:32:11 <rmoats> part I: we make sure we can collect the data
15:32:16 <rmoats> that's this RFE
15:32:24 <rmoats> part II: we get it over to Ceilometer
15:32:32 <rmoats> (that will be a different RFE/project)
15:32:55 <carl_baldwin> For part I, is the data going to a big bottomless bit-bucket then?
15:32:56 <rmoats> part III: we get Celiometer to share the info with operators in their preferred method - outside scope of neutron
15:33:10 <rmoats> carl_baldwin: no - as mestery said, a cache that refreshes
15:33:23 <rmoats> I do *NOT* want to be "big data"
15:33:33 <rmoats> "big data" == "bottomless bit-bucket"
15:33:45 <amotoki> a kind of new notification APIs from neutron to ceilometer :)  like MIB counters (in my understaindng)
15:33:55 <mestery> OK
15:34:01 <rmoats> amotoki: that's where I'm going
15:34:14 <carl_baldwin> rmoats: I just wanted to be sure I understood the scope.
15:34:21 <rmoats> carl_baldwin: sure -
15:34:30 <rmoats> and I'm very sensitive to storing too much data
15:34:41 * rmoats has the scars from other projects trying to do that
15:34:48 <carl_baldwin> I now see that phase I is a stepping stone to something but not useful by itself.
15:35:07 <mestery> carl_baldwin: Always to the point :)
15:35:11 <carl_baldwin> That’s ok sometimes.
15:35:14 <rmoats> carl_baldwin: unfortunately yes, but I wanted to divide and conquer
15:35:17 <mestery> But yes, I thikn that's it
15:35:25 <mestery> OK, this makes sense to me at least
15:35:27 <mestery> Lets get the infra in place
15:35:35 <mestery> And then use it to transfer data out of neutron
15:35:36 <mestery> and not store it
15:35:49 <carl_baldwin> +1 to not storing big data in Neutron.
15:35:58 <rmoats> mestery: my next step was going to be a BP/spec that catalogued where everything is going to come from
15:36:16 <rmoats> to see what we need to add and what is already there waiting to be harvested
15:36:33 <amotoki> rmoats: one nit question: we have metering-agent which not so many folks seem interested in... is it related?
15:36:40 <rmoats> carl_baldwin: I'm +max_int to not storing big data in Neutron
15:36:50 <rmoats> amotoki: I view metering-agent as orthogonal
15:37:02 <rmoats> that (as I understand it) is aimed at collecting data for billing
15:37:13 <rmoats> and this is aimed at collecting data for operations folks
15:37:18 <rmoats> they are similar, but not the same
15:37:23 <amotoki> rmoats: it is collecting traffic across routers.
15:38:02 <amotoki> okay we can go first and if there are overlapped areas we can improve it.
15:38:06 <rmoats> amotoki: and the right answer may be to reformat it into something that can go into the MIB
15:38:12 <rmoats> I'm open to reusing what's already there
15:38:33 <rmoats> well "into the MIB" was a bit strong
15:38:42 <rmoats> I meant to say "look like what the MIB expects"
15:39:03 <amotoki> rmoats: sounds good to me as a first step.
15:39:14 <mestery> amotoki rmoats: ++
15:39:24 <rmoats> amotoki: that's the reason for the BP/spec - to see what can already be harvested
15:39:31 * rmoats not interested in reinventing wheels
15:39:31 <mestery> Shall we let this one proceed at this point with a solid devref as a starting point?
15:39:40 <rmoats> mestery: devref or spec?
15:39:49 <carl_baldwin> +1
15:39:52 * rmoats was thinking spec, but is flexible
15:40:21 <mestery> lol
15:40:28 <mestery> The spec is very slim
15:40:30 <mestery> There's no API for this change
15:40:40 <mestery> So I think a devref seems appropriate to me
15:40:47 <rmoats> mestery: but there may be lots of options for implementation :)
15:41:02 <mestery> rmoats: Your job is to simplify those as much as possible and document in the devref :)
15:41:10 <rmoats> ok, I can do devref then
15:42:29 <mestery> cool!
15:42:53 <mestery> OK
15:43:07 <mestery> Any other specific RFEs people want to discuss? carl_baldwin amotoki ???
15:44:10 <rmoats> thanks, folks ...
15:44:19 <mestery> thanks rmoats
15:44:58 <mestery> Lets discuss this one:
15:44:58 <mestery> https://bugs.launchpad.net/neutron/+bug/1475792
15:45:00 <openstack> Launchpad bug 1475792 in neutron "Change Neutron so that it can auto-allocate networks" [Undecided,Confirmed] - Assigned to Brian Haley (brian-haley)
15:45:00 <uvirtbot> Launchpad bug 1475792 in neutron "Change Neutron so that it can auto-allocate networks" [Undecided,Confirmed]
15:45:01 <uvirtbot> Launchpad bug 1475792 in neutron "Change Neutron so that it can auto-allocate networks" [Undecided,Confirmed] https://launchpad.net/bugs/1475792
15:46:05 <mestery> I think this is a good start by haleyb
15:46:11 <mestery> And I think this covers what the nova folks are looking for
15:48:08 <mestery> OK
15:48:24 <mestery> Lets call this meeting now.
15:48:32 <mestery> Please, keep reviewing the RFE bugs.
15:48:35 <amotoki> mestery: what is the next step for this? The goal is clear and we need to define API or others.  moving to a spec after some discussion?
15:48:42 <mestery> amotoki: Yes!
15:48:47 <mestery> Lets move it to a spec since it's an API change
15:48:50 <mestery> And we can iterate there
15:49:17 <amotoki> does it mean we can triage it?
15:49:40 <mestery> amotoki: yes
15:49:42 <mestery> please mark it triaged
15:49:46 <mestery> I commented in the bug as well
15:52:25 <amotoki> none from me as existing RFE bugs.
15:52:31 <mestery> OK
15:52:37 <mestery> Thanks for attending folks!
15:52:39 <mestery> Keep reviewing RFE bugs
15:52:41 <amotoki> perhaps I need to file a rfe for neutron-ironic integration.
15:52:42 <mestery> We'll see you next week!
15:52:46 <mestery> amotoki: ++
15:52:48 <mestery> #endmeeting