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