22:00:13 <mlavalle> #startmeeting neutron_drivers
22:00:14 <openstack> Meeting started Thu Oct 12 22:00:13 2017 UTC and is due to finish in 60 minutes.  The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:17 <openstack> The meeting name has been set to 'neutron_drivers'
22:00:23 <armax> yello
22:00:27 <mlavalle> o/
22:00:50 <yamamoto> hi
22:01:42 <armax> amotoki: around?
22:02:08 <mlavalle> he said he was going to join
22:02:15 <armax> ok
22:02:20 <mlavalle> let's give him a couple of minutes
22:04:37 <mlavalle> ok, let's start
22:04:51 <armax> let's
22:04:58 <mlavalle> yamamoto: I sent you an email with a doodle survey
22:05:20 <yamamoto> i found it in my inbox
22:05:25 <mlavalle> when you have a chance, please respond with your availability for alternate time
22:05:31 <mlavalle> no rush right now
22:05:36 <yamamoto> ok
22:06:15 <mlavalle> This is the list of triaged RFEs that we want to process today:
22:06:23 <mlavalle> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:06:53 <mlavalle> First one in the list is https://bugs.launchpad.net/neutron/+bug/1690425
22:06:54 <openstack> Launchpad bug 1690425 in neutron "[RFE] neutron cells aware" [Wishlist,Triaged]
22:07:36 <armax> this one came  from the boston forun
22:07:38 <armax> forum
22:07:53 <mlavalle> it was only time before someone was to bring this up
22:07:58 <armax> in a nutshell, it’d be nice if we can make neutron able to deal with more than a single rabbit cluster
22:08:13 <armax> in a similar way nova cells does it
22:08:22 <armax> however, there’s more than one way to do that
22:08:46 <armax> we could potentially fall back on using the cells hierarchy to find how to route the messages across the deployment
22:09:01 <armax> or use something like message routing (latest link) on the bug report
22:09:16 <armax> this requirement keeps coming up but no-one steps up to do the work :)
22:09:28 <mlavalle> yeah, I goit myself thorugh that presentation right before they start the demo
22:09:57 <mlavalle> I think this something we won't be able to avoid indefinitily
22:10:38 <mlavalle> if Nova Cells V2 starts to get adopted, the pressure will only gow on Neutron
22:10:56 <armax> mlavalle: that’s a good point
22:11:01 <mlavalle> so I think it is better if we are proactive
22:11:08 <armax> cell v2 is already default in th gate
22:11:26 <armax> so there’s going to be an uptake for sure
22:11:43 <mlavalle> what about the DB?
22:11:55 <armax> what do you mean?
22:12:00 <armax> how to shard the DB?
22:12:03 <armax> don’t go there :)
22:12:18 <mlavalle> just clarifying the prposal
22:12:39 <mlavalle> do we want to keep a centralized Neutron server
22:13:05 <mlavalle> and the use a super fast messaging bus to talk to agents across cells?
22:15:18 <armax> mlavalle: I’d say so
22:15:27 <armax> mlavalle: the neutron server can already be scaled out infinitely
22:15:38 <armax> agents can be deployed per AZ
22:15:55 <armax> the chokepoint has always been the bus for us
22:16:47 <mlavalle> now if I understood the presentation you posted in the RFE, we could adopt that messaging approach
22:17:04 <armax> that’s one way to tackle the messaging chokepoint
22:17:29 <yamamoto> how about tricircle?
22:17:35 <mlavalle> without necessarily aligning completly with de cells on the Nova side, right?
22:18:50 <armax> while tricircle introduces a hierarchy of neutron systems
22:19:04 <armax> it’s like killing a fly with a cannon if the bottleneck is just the bus
22:20:24 <mlavalle> would the next step be a PoC?
22:20:43 <mlavalle> and maybe get feedback from large operators in Sydney
22:21:07 <armax> mlavalle: PoC about what exactly?
22:21:28 <mlavalle> some code using this new messaging approach
22:21:45 <armax> oh
22:21:48 <armax> well
22:21:57 <mlavalle> I am just trying to get to the next step
22:22:02 <armax> yeah, makes sense
22:22:32 <armax> I suppose we could recommend to look into the routing messaging approach to avoid the bottleneck
22:22:35 <mlavalle> if we believe the premise that this is something that will catch up with us sooner or later
22:22:44 <armax> we’d need the scale to validate that the approach is sound, no?
22:22:52 <mlavalle> yeah
22:23:19 <mlavalle> and if the premise above is true^^^^, let's start learning asap
22:25:01 <yamamoto> armax: if the cannon works well, i guess it's ok. do you have any particular downside in your mind?
22:25:41 <armax> yamamoto: complexity!
22:26:59 <yamamoto> ok. i don't know how complex tricircle is.
22:27:25 <mlavalle> has it been deployed at large scale succesfuly, you know?
22:27:28 <armax> anything that involves a hierarchical structure can’t be simple :)
22:27:43 <armax> it’s like linkedlist vs BSTs :)
22:27:48 <armax> or AVL trees
22:28:14 <armax> I let you decide which structure is easier to understand :P
22:28:21 <armax> mlavalle: you mean tricircle?
22:28:25 <mlavalle> yeah
22:28:49 <armax> mlavalle: you’re best position to find the answer the question as it’s been a project spearheaded by huaweii
22:29:02 <armax> I think proposing tricircle has some merits too
22:29:12 <mlavalle> I know, that is why I am asking
22:29:24 <mlavalle> maybe we can decide to next setps here for today
22:29:27 <armax> but again, that comes with a lot more than just overcome the bus chokepoint
22:29:44 <armax> next step is probably add a documentation section to our guide
22:29:51 <armax> to plot some of these stop-gap solutions
22:30:00 <mlavalle> 1) Dig deeper in the messaging approach
22:31:18 <armax> any other?
22:31:37 <mlavalle> 2) I could do some fact finding about tricircle
22:31:38 <armax> I send a 2)
22:31:40 <armax> sense
22:31:47 <armax> is there a 3)? :)
22:31:53 <mlavalle> no
22:32:00 <armax> so 0) being the doc effort/
22:32:01 <mlavalle> not from my anyway
22:32:01 <armax> ?
22:32:23 <mlavalle> yeah
22:32:33 <armax> yamamoto, amotoki what’s your experience? heard complaint about the MQ bus?
22:34:14 <yamamoto> i've heard comlaints about amqp. in many cases "we" propose midonet as a solution. :-)
22:34:44 <armax> lol
22:34:54 <armax> there you go, problem solved!
22:34:55 <armax> :)
22:35:01 <mlavalle> lol
22:35:32 <armax> OK, shall we move on? I think we have enough to take this a bit more farther
22:35:45 <mlavalle> yeap
22:35:59 <armax> who summarizes this on teh report?
22:36:01 <armax> mlavalle: you?
22:36:03 <armax> or you?
22:36:04 <mlavalle> yeah
22:36:06 <armax> or maybe you?
22:36:12 <mlavalle> I will
22:36:19 <armax> ok, then if you volunteer
22:36:29 <armax> I am happy to bow
22:37:00 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1690438
22:37:01 <openstack> Launchpad bug 1690438 in neutron "[RFE] make get-me-a-network work with any network topology" [Wishlist,Triaged]
22:37:45 <mlavalle> I looked at this one earlier today and I liked it
22:37:50 <mlavalle> including the spec
22:38:01 <mlavalle> yamamoto has a comment I believe
22:38:50 <armax> mlavalle: I need to refresh it one more time based on a chat I had with kevinbenton
22:39:03 <armax> but other than that I think the work is a great example of a starter bug
22:39:03 <mlavalle> the spec?
22:39:06 <armax> ya
22:39:17 <mlavalle> I am good to approve the RFE
22:39:17 <armax> as it’s just orchestration on top of easy stuff
22:39:37 <mlavalle> yamamoto: what do you think?
22:39:42 <armax> OK, we need to advertisize that’s free for takers next team meeting
22:39:50 <mlavalle> will do
22:39:55 <armax> mlavalle: actually I even had a PoC code lying around somewhere
22:39:58 <armax> but I think I lost it
22:39:59 <armax> :(
22:40:02 <yamamoto> i think it's fine to approve the RFE and sort out details in spec review
22:40:13 <mlavalle> I will actually add a section to the Neutron meeting to advertise this
22:40:40 <mlavalle> like we have a section for docs, neutron-libe, bugs, etc
22:40:56 <mlavalle> starting on Monday
22:41:29 <mlavalle> ok, approved
22:41:39 <armax> woot
22:42:07 <mlavalle> Next one is https://bugs.launchpad.net/neutron/+bug/1690439
22:42:08 <openstack> Launchpad bug 1690439 in neutron "[RFE] Deal with NetworkAmbiguous error" [Wishlist,Triaged] - Assigned to hongbin (hongbin034)
22:43:19 <armax> that’s another one that came out of the forum in bost
22:43:21 <armax> boston
22:43:22 <mlavalle> wow, we even got a volunteer for this RFE since I wrote a comment this morning
22:43:36 <armax> we need to mark a network in neutron to be default
22:43:41 <mlavalle> yeah
22:43:42 <armax> but most orchestration is in nova
22:43:54 <armax> honestly we even have the code in neutron
22:44:03 <armax> because today we can mark an external network as default
22:44:08 <armax> so it’s a bit of shuffling
22:45:10 <mlavalle> would it be a be a starter's RFE on our side?
22:47:21 <armax> I think so
22:47:25 <mlavalle> well, we already have hongbin as volunteer
22:47:44 <mlavalle> My opinion is let's approve it
22:48:00 <mlavalle> yamamoto: what do you think?
22:48:03 <yamamoto> +1 to approve
22:48:35 <mlavalle> approved it is
22:49:12 <mlavalle> Next up is https://bugs.launchpad.net/neutron/+bug/1692126
22:49:13 <openstack> Launchpad bug 1692126 in neutron "[RFE] Detailed error responses for failed VPN connections" [Wishlist,Triaged]
22:49:45 <armax> last comment from yamamoto makes sense, I mean about the description being a standard attribute
22:50:24 <armax> though it’s be nice for those resources that have a status to have a status description that is done consistently
22:51:07 <yamamoto> can we have another stdattr-like thing?  say HasStatusAndItsDescription
22:51:47 <armax> probably no worth the hassle
22:53:02 <mlavalle> so would we pursue this only for VPN?
22:54:58 <yamamoto> i guess we can start from the given use case (vpn) but with future consistency for other resources in mind
22:55:21 <mlavalle> I think that is a good approach
22:56:42 <yamamoto> any precedence of "status details" in neutron?
22:57:31 <mlavalle> what do you mean? have we tried this before?
22:57:59 <armax> there’s no such field/capability in neutron
22:58:05 <armax> I don’t recall
22:58:07 <yamamoto> i meant, if there's a precedence, we should be consistent with it.
22:58:30 <yamamoto> i don't recall anything either
22:58:37 <mlavalle> me neither
22:59:07 <mlavalle> so I say let's move ahead with this for VPN
22:59:56 <mlavalle> armax, yamamoto: what to do say?
23:01:50 <armax> It’s say it’s up to the vpnaas core team to decide
23:02:01 <armax> I think it’s a reasonable addition
23:02:47 <mlavalle> ok, I'll make a note in the RFE to this effect
23:02:57 <mlavalle> Time is up
23:03:08 <mlavalle> thanks for attending
23:03:11 <yamamoto> +1 to make vpnaas decide.
23:03:16 <yamamoto> thank you
23:03:21 <mlavalle> #endmeeting