15:00:40 <sc68cal> #startmeeting neutron_ipv6
15:00:41 <openstack> Meeting started Tue Jan  7 15:00:40 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:42 <heyongli> sure, see you next meeting
15:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:45 <openstack> The meeting name has been set to 'neutron_ipv6'
15:00:50 <ijw> yo Sean
15:00:52 <sc68cal> Good morning!
15:00:56 <aveiga> hello
15:00:58 <ijw> it was
15:01:10 <xuhanp> hello, Xu Han is here
15:01:18 <sc68cal> Good Evening as well!
15:01:27 <baoli> Hello, everyone
15:01:38 <dzyu> hi Sean
15:01:50 <sc68cal> Agenda for today: https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Jan_7th
15:02:13 <sc68cal> #topic recap last meeting
15:02:49 <sc68cal> Technically last meeting was last week, but I think the holiday, so not much occured
15:03:12 <sc68cal> So we'll just hop right into blueprints
15:03:20 <flaper87> mmh, guys, are you sure this is your time slot?
15:03:22 <flaper87> https://wiki.openstack.org/wiki/Meetings/Marconi
15:03:56 <sc68cal> flaper87: was this changed recently?
15:04:05 <kgriffs> we have had this slot for about a month
15:04:08 <kgriffs> (marconi)
15:04:15 <flaper87> what kgriffs said
15:04:24 <sc68cal> I don't see it on https://wiki.openstack.org/wiki/Meetings
15:04:39 <kgriffs> ah crap
15:04:39 <sc68cal> which I used to double check before moving our meeting
15:04:48 <kgriffs> somehow the day didn't get updated
15:04:53 <kgriffs> was supposed to be tuesday
15:04:54 <kgriffs> my bad
15:05:01 <kgriffs> Marconi (queues) team meeting
15:05:12 <kgriffs> it used to be mondays but was changed a while back to tuesdays
15:05:17 <kgriffs> looks like the wiki wasn't updated.
15:05:18 <kgriffs> hmmm
15:05:32 <flaper87> sc68cal: when did you guys moved it?
15:05:39 <flaper87> move*
15:05:45 <sc68cal> flaper87: earlier this week, and we updated our section on the wiki
15:06:06 * ijw makes popcorn and settles down for the fight
15:06:13 <kgriffs> heh
15:06:34 <kgriffs> well, i think this one is our fault for missing the day change under our section
15:06:54 <flaper87> what about you guys doing the meeting here today and finding another slot for next week?
15:07:06 <flaper87> we can take our meeting to #openstack-marconi this week
15:07:10 <flaper87> I guess, kgriffs thoughts ?
15:07:25 <kgriffs> sounds fine, but it is our fault so this would be asking a favor. :D
15:07:44 <sc68cal> Sure - sorry for running over you guys
15:07:46 <aveiga> you guys legitimately had it before
15:07:51 <aveiga> just a mix up in docs
15:07:55 <ijw> I think we're fairly flexible for next week, but maybe we can sort this out on the ML afterward.
15:07:58 <aveiga> sounds fair to me
15:08:11 <flaper87> thanks a lot guys! Sorry for the whole mess
15:08:15 <kgriffs> yeah. sorry guys for the misunderstanding. carry on. We'll move our party over to #openstack-marconi this week
15:08:24 <ijw> kgriffs: is there beer?
15:08:28 <kgriffs> lol
15:08:30 * kgriffs wishes
15:08:43 <sc68cal> #topic blueprints
15:08:47 <flaper87> ijw: If you contribute to marconi, I'll make sure you get beer
15:08:50 * flaper87 out
15:09:05 <sc68cal> #undo
15:09:05 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x30e63d0>
15:09:20 <sc68cal> OK need to do another ML to find a new day
15:09:26 <sc68cal> I think Fridays are way open
15:09:47 <ijw> Sounds good if it's going to be around this time
15:10:09 <sc68cal> #action sc68cal create new thread, find new meeting slot - current slot conflicts with marconi
15:10:10 <shshang> Does Tuesday 9am work?
15:10:23 <ijw> ... which 9am...
15:10:32 <sc68cal> 1400 UTC doesn't work for #alt
15:10:37 <shshang> I see.
15:10:42 * sc68cal checks #openstack-meeting
15:10:52 <aveiga> let's take time selection to the ML, there's a lot to cover catching up from a break
15:11:08 <sc68cal> openstack meeting might be free at 1400 UTC
15:11:13 <sc68cal> we'll put it on the ML
15:11:27 <sc68cal> #topic blueprints
15:11:31 <baoli> we may change pci passthough to utc 1300 permanently, so utc 1400 may be available
15:12:02 <sc68cal> xuhanp: ping
15:12:15 <xuhanp> pong
15:12:27 <sc68cal> First time we've been able to chat in real time - quite a bit of work we've done on the subnet mode keyword
15:12:56 <sc68cal> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/dnsmasq-mode-keyword,n,z dnsmasq-mode-keyword reviews
15:13:23 <shshang> @xuhanp, welcome!
15:13:29 <sc68cal> Thankfully we were able to get things straightened out with the Tail-F jenkins third party test - all the -1's have been reviewed
15:13:39 <sc68cal> *removed
15:13:48 <dzyu> sc68cal, I saw https://review.openstack.org/#/c/52983/ just some monir comments
15:14:13 <xuhanp> yep. including my -1 :-)
15:15:14 <sc68cal> yep - some good points that both you and Carl Baldwin made about the code - I plan on integrating the suggestions
15:16:00 <sc68cal> dzyu: have anything to add - sorry, mixed up a bit
15:16:24 <dzyu> And maybe we should involve more guys to review the two code change
15:16:28 <ijw> That does still seem to have the problem of too many options available and all tied to dnsmasq
15:16:40 <ijw> What's the plan, do that then refine it?
15:17:24 <xuhanp> Also I have some concerns about how to support SLAAC and DHCPv6 at the same time ( one port having two kinds of addresses), and the code seems doesn't handle this right now. So maybe worth mentioning here.
15:18:34 <sc68cal> ijw: I believe that once shshang and Randy__ work on their blueprints for adding v6 modes to dnsmasq, that'll give us a good idea of what options are really going to be used, then perhaps prune it down
15:18:34 <dzyu> xuhanp: yes, we need more consider about the combination of dhcp mode
15:18:59 <shshang> How are these variables passed to the code? Via CLI command?
15:19:19 <xuhanp> both CLI and API, I think
15:19:22 <ijw> shshang: they'll come in on the API call that's equivalent to subnet-create, I think
15:19:31 <sc68cal> yeah it's an extra couple flags to the CLI
15:19:33 <Randy__> should be CLI and via Horizon dash
15:19:41 <dzyu> yes
15:19:43 <aveiga> should we wait for the definitions first?  If it's going to be passed via cli, we shouldn't change the keywords very frequently
15:19:44 <sc68cal> which I believe dzyu has a review for
15:20:21 <shshang> If they are passed via CLI, how are about Horizon?
15:20:35 <shshang> On dashboard, we should provide the same options, right?
15:20:41 <sc68cal> Yep
15:20:51 <aveiga> yes
15:20:55 <shshang> Is there any plan to cover dashboard too?
15:21:07 <xuhanp> https://review.openstack.org/#/c/54250/  dzyu's CLI code change
15:21:09 <aveiga> so the UI will need to reflect the defnitions as well, which is why we should get them out the door first
15:21:10 <ijw> shshang: absolutely, but the steps need to be first the Neutron API, then the python-neutronclient command, and then Horizon, I think - they have to be three separate changes because they're in the three projects
15:21:26 <aveiga> ijw: +1
15:21:40 <aveiga> though we should get a blueprint started for the Horizon part too
15:21:44 <ijw> Indeed
15:21:56 <shshang> yes, this is what I am concerning
15:22:23 <shshang> I only saw the keywords for CLI. Would like to make sure we cover API and Dashboard too
15:22:35 <sc68cal> cool - someone want to volunteer to create the BP for horizon?
15:22:41 <dzyu> +1, need support in Dashboard
15:22:52 <ijw> In that first patch there's not even CLI commands, that's the JSON.
15:23:35 <xuhanp> ijw: which first patch?
15:24:01 <sc68cal> #link https://review.openstack.org/#/c/54250/ Neutron CLI - subnet mode keyword support review
15:24:08 <ijw> https://review.openstack.org/#/c/52983/14 (versus the one on the commandline client)
15:25:45 <sc68cal> #action sc68cal register blueprint for horizon support
15:25:50 <xuhanp> I think we got the CLI subnet input change covered in https://review.openstack.org/#/c/54250/
15:26:02 <xuhanp> am I missing something?
15:26:24 <shshang> @xuhanp, yes, I can see CLI part is covered by your code submission
15:26:31 <ijw> No, we're just talking at cross purposes.  Carry on
15:27:03 <sc68cal> I'll try and coordinate with dzyu more on those patch sets
15:27:09 <dzyu> sc68cal: I will restore https://review.openstack.org/#/c/54250/ later, and I think we need https://review.openstack.org/#/c/52983/  and https://review.openstack.org/#/c/56184/ be merged ASAP
15:27:22 <sc68cal> dzyu: +1
15:27:37 <sc68cal> as shshang asked on the mailing list - time is a bit tight
15:27:42 <aveiga> so just out of curiosity, there's no option in there for not setting it at all?
15:27:54 <aveiga> what about people using provider networks and their own router for the RAs?
15:28:02 <sc68cal> aveiga: It supports not being set at all
15:28:19 <Randy__> isn't there a default?
15:28:21 <sc68cal> In fact, provider nets and routers, we do not set it, and disable dhcp
15:28:25 <ijw> Well, similarly, the issue of two routers on a network, or none
15:28:28 <Randy__> ..when not provided, right
15:28:39 <sc68cal> ATTR_NOT_SPECIFIED is the default
15:28:58 <Randy__> sc68cal: thx
15:28:59 <aveiga> sorry, I'm not as well versed in the actual code part of this
15:29:08 <aveiga> my forte is more protocol/network engineering...
15:29:53 <dzyu> cool
15:29:55 <sc68cal> OK - I'll be working to clean up my patches, and coordinate with dzyu so we can get this merged ASAP
15:30:06 <shshang> So as long as sc68cal and dzyu and xuhap's code can save the user's selection to somewhere, which can be retrieved by dnsmasq, it should be fine.
15:30:43 <sc68cal> shshang: Randy__: How is the rebase going, for the work that you guys did, on top of the subnet mode bp?
15:30:48 <ijw> This doesn't make sense to me.
15:30:58 <shshang> if I undrstand https://review.openstack.org/#/c/52983/ correctly, it will be subnet attributes, right?
15:31:19 <ijw> I mean, we've gone quite a long way down the path of giving the user control of dnsmasq-specific modes and options that they shouldn't have access to, and we agreed that they shouldn't have access to
15:31:34 <sc68cal> shshang: yes
15:31:46 <aveiga> ijw: user, or admin?
15:32:05 <ijw> aveiga: user
15:32:10 <sc68cal> ijw: I don't recall that specifically, I do recall your concern about the modes being tied to the dnsmasq implementation
15:32:10 <aveiga> I agree that the user shouldn't have access here, but admins need to be able to set these modes
15:32:17 <ijw> API user at least, but unprivileged users can play with subnet attrs
15:32:27 <shshang> @sc68cal, cool, thanks
15:32:33 <sc68cal> ijw: We can lock that down via policy.conf
15:32:41 <ijw> That's not really the point
15:33:07 <sc68cal> ijw: While I respect your viewpoint, do you have a concrete proposal to fix?
15:33:10 <ijw> The user is going to want to elect to use RAs, DHCPv6 or both on their networks, and that's fine - there's a limited number of combinations that are going to work for them, and that's also fine
15:33:37 <sc68cal> We're getting close to Icehouse-2, I would appreciate code that addresses the problem
15:33:40 <aveiga> ijw: there might be a need for user access.  Say a user creates a tenant-only network with a load balancer on it to act as a gateway, we need to let the user set the modes there
15:34:02 <aveiga> so policy.conf might actually be the right method
15:34:10 <ijw> aveiga: there's always a need for user access, any user can create a network and subnet and will want to configure the addressing mode.
15:34:25 <ijw> This is not something you would lock the user away from, in fact
15:34:30 <ijw> It's not locked away from them right now
15:35:04 <aveiga> so do you have something specific to point out that we shouldn't be providing?
15:35:05 <sc68cal> ijw: If i recall correctly, updating a subnet is a admin or owner only operation
15:35:18 <ijw> Nope
15:35:20 <xuhanp> so I think we are talking about creating some sort of mapping between IPv6 words to dnsmasq mode?
15:35:36 <ijw> sc68cal: sorry, I didn't mean to start screwing up the timeline, but I thought the plan here was to divorce the options we gave to that addressing mode from the options that we passed to dnsmasq - and that's particularly important if xuhanp is already changing the neutronclient code based on what's going to go in
15:35:47 <aveiga> xuhanp: I think the issue might be backward in that we should specify IPv6 modes
15:36:01 <aveiga> and then implementations can map them (one implementation being dnsmasq)
15:36:06 <ijw> aveiga: indeed
15:36:25 <aveiga> which is why defining the modes should be a priority
15:36:29 <Randy__> can we table user priv from the keyword discussion??
15:36:43 <aveiga> and I believe I was assigned that as an action item and apologize for not getting to it
15:36:58 <aveiga> I know it's not an excuse, but I was out of commission due to surgery for the past two weeks
15:37:11 <shshang> aveiga, hope you get well soon
15:37:24 <aveiga> shshang: thanks, I'm better now
15:37:36 <ijw> faster. stronger.
15:38:05 <ijw> .me hums the 6 million dollar man tune
15:38:14 <aveiga> in any case, the question remains: push the patches to acceptance and change their usage after definition, or push the definition quickly?
15:38:35 <aveiga> and by quickly I mean this week, and harp on it until we get acceptance or rejection
15:38:43 <ijw> I'm good either way, I think even what we have is a statement of intent
15:39:11 <aveiga> so in the interest of expediency, let's push what we have
15:39:13 <aveiga> and retrofit it
15:39:21 <aveiga> knowing I-2 is soon
15:39:31 <xuhanp> +1
15:39:50 <sc68cal> Anyone who wants to take on that task, feel free to create a patch on top of the topic, that redefines the keywords to a more neutral usage
15:40:08 * aveiga raises hand as volunteer
15:40:08 <sc68cal> since we're using the constants, the change should be easy
15:40:27 <shshang> I can volunteer
15:40:39 <shshang> agree with aveiga's suggestion
15:40:59 <sc68cal> #action ijw aveiga shshang work on vendor neutral dns mode keywords
15:41:34 <sc68cal> OK - open discussion?
15:41:46 <sc68cal> or any other blueprints we want to discuss?
15:41:57 <shshang> back to the use case we discussed prior to the holiday
15:42:32 <shshang> we already got code in place to differentiate the use case aveiga and sc68cal referred to
15:42:34 <ijw> There's the annoying hairpin thing - anyone who wants to, weigh in on the mailing list, but we need that patch or something like it in by I2
15:42:50 <ijw> shshang: have you got the code up somewhere?  I was looking
15:43:03 <aveiga> I think ijw's comments on the ML about the hairpin are spot on
15:43:11 <aveiga> but there's a -1 on that review that is also valid
15:43:19 <aveiga> depending on if nova-networks gets deprecated or not
15:43:24 <shshang> Randy and I are working on the triggering point now to cover the scenario that, when tenant network is attatched to the router, we need to reload the dnsmasq in different mode
15:43:30 <ijw> aveiga: the patch as it is works either way
15:43:46 <ijw> shshang: I have an issue with your theory, I think
15:44:03 <aveiga> ijw: does it work for a neutron-owned nova-network mode?
15:44:17 <ijw> aveiga: no such thing - you're either Neutron or not
15:44:33 <ijw> aveiga: we're in the clear all ways around, anyway, I think
15:44:48 <aveiga> ijw: they're talking about a mode in neutron that replicates the functionality of nova-network for upgrade path's sake
15:45:00 <ijw> shshang: I know you're attached to the one namespace thing, but I still think that having a DHCP namespace for solely DHCP would be a good idea
15:45:15 <ijw> aveiga: that should be fine, it'd still need a router
15:45:34 <ijw> Well, it'd still use a router, they wouldn't be adding port rewrite rules, I would hope
15:46:14 <aveiga> floats would still need it for the time being
15:46:16 <ijw> Firstly, I think the number of routers on a network is going to be 0+ at some point - we're already talking about multiple external networks - which means you don't have just the one router namespace
15:46:25 <aveiga> I think it's something worth bringing up in #openstack-neutron though
15:46:31 <ijw> Secondly the DHCPv4 server has to have a home namespace too
15:46:42 <Randy__> ijw: the two namespaces will remain. you're either attached to the dhcp namespace with 0 routers or to qrouter namespace
15:46:47 <ijw> Can't we just have one namespace and process for DHCPv* and then an RA process in each router?
15:46:57 <shshang> ijw, just want to clarify one more time, there is no such thing called one namespace
15:47:08 <ijw> OK, so then it's one process.  Why not two processes?
15:47:46 <ijw> (noting there is not exclusively one qrouter process if there's more than one attached router)
15:47:51 <ijw> qrouter namespace)
15:48:27 <ijw> Please, feel free to shoot down the idea, but I'm trying to understand
15:48:58 <baoli> One question, an ipv6 subnet is added into a network. Until it's attached to a router, it has not relationship with a router, right? So until it's added to the router, it's restricted to the the dhcp namespace, right?
15:49:27 <shshang> As aveiga and sc68cal suggested prior to the holiday, we changed the code in the way that, in case there is no router for tenant network, we will launch dnsmasq in qdhcp namespace; In other cases, we launch it in qrouter namespace.
15:49:50 <shshang> What I referred to is purely ipv6 dnsmasq process
15:49:56 <ijw> Yes - so why not launch a separate process in each namespace with different responsibilities?
15:49:59 <shshang> for ipv4, still stayin qdhcp
15:51:00 <sc68cal> ijw: shshang: is it possible that this can be an additional patch - to make it so it launches more processes in new namespaces?
15:51:17 <sc68cal> My concern is that we're getting bogged down, making perfect the enemy of the good
15:51:35 <aveiga> sc68cal +1
15:51:40 <ijw> Yes, indeed, though I think shshang has to stop the process in the qdhcp namespace and start it in the qrouter namespace when a router is first added
15:51:52 <sc68cal> If we just sit around arguing about how to make it perfect, we're never going to get things merged, and we'll go through yet another release where neutron ipv6 is broken and unusable
15:51:57 <ijw> So my point is this might make what he's doing slightly *less* complicated
15:52:11 <shshang> sc68cal, agree
15:52:21 <shshang> plus, I don't think we have time right now
15:52:36 <dzyu> sc68cal:+1
15:52:39 <ijw> Okay
15:52:48 <ijw> Let's get the patch up then
15:53:42 <shshang> ijw, we can always associate more ideas in the ML or offline.
15:53:51 <shshang> sorry, socialize
15:54:02 <ijw> shshang: I think it'll actually be easier to discuss when we have code to point too, too
15:54:09 <shshang> agree,
15:54:22 <shshang> right now, the keywords has to be in and approved first
15:54:43 <ijw> yup
15:54:54 <shshang> afterwards, my focus is to refine the code based on keywords, so everybody can test it
15:55:33 <shshang> I like your ideas, and let us revisit it again when we at least have some common ground to start with
15:56:30 <aveiga> ok, sounds like this one is in the bag and we can move on next week
15:56:41 <aveiga> anything else to bring up for the last 3 minutes?
15:56:59 <ijw> shshang: how do you feel about just laying down the options we want on subnets, then sticking a couple of very very small patches that just implement those attrs with no backend functionality?  I imagine if we did it that way we could get it in in a day or two because there'd be nothing to object to
15:57:00 <sc68cal> #topic open discussion
15:57:07 <shshang> only one thing, happy new year to everybody!
15:57:33 <xuhanp> Thank you, happy new year!  and Chinese new year is coming!!!
15:57:48 <dzyu> :) happy new year!
15:57:50 <baoli> happy new year to you all.
15:57:52 <shshang> Yup! look forward to it, xuhanp and dzyu
15:57:53 <sc68cal> xuhanp: dzyu: thanks for joining!
15:58:09 <baoli> My lights are still up for Chinese new year
15:58:12 <xuhanp> very glad to be here, guys
15:58:25 <shshang> feel excited to see IBM teams here today
15:58:30 <ijw> shshang, aveiga: you likely to be in #openstack-neutron after?
15:58:45 <aveiga> I should be around most of the day, in and out
15:58:55 <ijw> OK, let's clear up the options thing
15:58:57 <aveiga> lots of meetings this week thanks to the holiday
15:58:57 <shshang> ijw, too bad, I will have a meeting in 2 mins
15:58:59 <shshang> :(
15:59:07 <ijw> shshang: later's also fine?
15:59:11 <ijw> Just pick a time
15:59:35 <ijw> If we can get this done today that will be one hurdle out of the way
15:59:49 <shshang> I will be free this afternoon around 4pm EST. Which time zone are you in, ijw?
16:00:10 <shshang> I can start webex meeting, so we can talk to each other. typing is a pain
16:00:14 <ijw> CET physically.  Mentally, I'm never sure
16:00:23 <sc68cal> #endmeeting