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