14:00:50 <sc68cal> #startmeeting neutron_ipv6
14:00:51 <openstack> Meeting started Tue Jan 14 14:00:50 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:55 <openstack> The meeting name has been set to 'neutron_ipv6'
14:00:58 <xuhanp> hello. Good morning Sean
14:01:19 <sc68cal> #topic recap last meeting actions
14:01:39 <sc68cal> #link http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-01-07-15.00.html last week's actions
14:02:11 <sc68cal> OK - I had two actions that needed to be done, first was to schedule the meeting time for a non-conflicting time - and that's been done ;)
14:02:29 <sc68cal> The second action was to register a blueprint for Horizon support for the IPv6 subnet modes
14:03:00 <sc68cal> #link https://blueprints.launchpad.net/horizon/+spec/neutron-subnet-mode-support Horizon blueprint for ipv6 subnet configuration
14:03:36 <sc68cal> It's a bit light on details, but we can always add more info
14:03:37 <xuhanp> Wonderful. Thanks for the quick actions!
14:04:22 <sc68cal> let me see if I can fetch the people that are responsible for the other items
14:05:36 <sc68cal> OK - well we can circle back later if need be
14:05:55 <sc68cal> #topic blueprints
14:06:59 <sc68cal> We're still hammering out the subnet mode keyword review
14:07:38 <sc68cal> We had one core reviewer suggest it become an API extension, but I punted to the mailing list to solicit more feedback on what we should do
14:07:50 <shshang> hola
14:07:57 <sc68cal> shshang: hello
14:07:59 <aveiga> recheck your email, we had another punt on it
14:08:13 <sc68cal> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/024179.html API extension vs core api
14:09:26 <sc68cal> That's pretty much all I have - if we want to circle back to the keyword action from last meeting
14:09:48 <sc68cal> aveiga: shshang: you guys along with ijw were going to figure out how to get the dnsmasq-isms out?
14:10:11 <sc68cal> I saw an e-mail from ijw on the mailing list, but I don't know if there's anything more
14:10:25 <aveiga> yup
14:10:32 <shshang> yup
14:10:33 <aveiga> shshang: any progress on the writeup?
14:11:06 <shshang> aveiga, still have one question needing your help
14:11:13 <shshang> Need to grab your brain
14:11:31 <shshang> regarding your last comment about seperating the RA and address assignment
14:13:19 <shshang> I have been thinking about how to differentiate the use case you mentioned (i.e. external router sends RA, dnsmasq as DHCPv6), and the case that dnsmasq will send RA and act as DHCPv6
14:14:08 <aveiga> I think ijw and I have gone over this a few times at this point, but the commands to enable addressing and the commands for routing need to be separated
14:14:22 <aveiga> and this is why they won't fit in the API in the enable_dhcp attribute
14:14:31 <shshang> yes
14:15:15 <shshang> in other words, we need a separate keyword to capture the address assignment part, since the one we discussed is on RA announcment side.
14:15:44 <aveiga> I think we need to reword them too
14:15:55 <aveiga> we make statements in the RA configuration that refer to addressing
14:16:03 <aveiga> we should completely separate them
14:16:12 <shshang> either way, as long as we can carry the information precisely and concisely
14:16:24 <aveiga> yup
14:17:22 <shshang> The fastest way is to separate them by adding a switch to indicate whether dnsmasq will act as dhcpv6 server.
14:17:44 <aveiga> nope, going right back down the hole we were digging out of
14:17:51 <aveiga> don't link yourself to dnsmasq
14:17:58 <aveiga> and this isn't a switch
14:18:05 <aveiga> it's a pair of keywords that combine to make functionality
14:18:11 <aveiga> I think we should just plain have two keywords
14:18:17 <shshang> that is what I mean
14:18:21 <shshang> two keywords
14:18:28 <shshang> keep our current one for RA only
14:18:50 <shshang> and another keyword to signal whether we need OpenStack to provide dhcpv6 function or not
14:19:03 <aveiga> well, it's not boolean
14:19:14 <aveiga> it's off, stateless or stateful
14:19:19 <aveiga> but yes
14:19:29 <shshang> rename our current keyword set to something accurate, --enable-ipv6-ra
14:19:47 <aveiga> agreed
14:19:53 <aveiga> and reword the descriptions
14:19:59 <aveiga> I can help with that
14:20:04 <shshang> add another keywords like something --enable-ipv6-dhcpv6
14:20:16 <shshang> if you can help, that will be awesome
14:20:28 <sc68cal> The only question I have is, the current attribute for subnets, enable_dhcp
14:20:37 <sc68cal> ah...
14:20:42 <sc68cal> that's a boolean isn't it.
14:20:46 <aveiga> yeah
14:20:53 <shshang> like TRUE or FALSE. :D
14:21:01 <aveiga> so we need to have a powwow with Mark and Salvatore :-D
14:21:12 <sc68cal> what about changing it to take options instead of just T/F ?
14:21:34 <shshang> like REMOTE or LOCAL?
14:21:40 <aveiga> I think we should take this to the ML and ask for a chat with the cores for Neutron about this
14:21:43 <baoli__> --disable-dhcp        Disable DHCP for this subnet
14:21:58 <aveiga> baoli__: that's the problem, we need 3 modes
14:22:01 <aveiga> not boolean
14:22:20 <sc68cal> Right - that sets the enable_dhcp attribute on a subnet to False
14:22:27 <sc68cal> via the neutron cli
14:22:35 <ijw> Just to get it into the meeting minutes: bugger.
14:22:50 <aveiga> ijw: rough afternoon, eh?
14:23:00 <baoli__> If you create a ipv6 subnet, would that parameter work ?
14:23:09 <ijw> I was in openstack-meeting-alt, cos I had a meeting there just before, and Sean's evil and moved channels
14:23:25 <aveiga> baoli__: the issue is that we need off, stateful and stateless as modes
14:23:33 <sc68cal> I don't debate that I'm evil, although I swear I did this channel because alt is in use
14:23:42 <baoli__> I see
14:23:49 <ijw> It's supposed to be, but no, completely dead
14:24:05 <ijw> Sorry, I see I've come in in the middle of the attribute wars - what's the debate this time?
14:24:23 <aveiga> in any case, I think we need to hammer this out with the Neutron cores, there's no way we can get away with reusing enable_dhcp
14:24:51 <sc68cal> ok - who wants to grab that nettle?
14:25:02 <baoli__> does it have to be specified per subnet?
14:25:06 <aveiga> baoli__: yes
14:25:08 <sc68cal> baoli__: yes
14:25:09 <shshang> yes
14:25:18 <aveiga> sorry, didn't mean to gang up on you
14:25:25 <shshang> :D
14:25:27 <sc68cal> we have consensus :)
14:25:30 <aveiga> but at least we have consensus
14:25:41 <baoli__> that's fine.
14:25:52 <shshang> sc68cal, grabbing that nettle is an action item?
14:26:06 <aveiga> I think it needs to be a few of us
14:26:16 <sc68cal> shshang: yes
14:26:24 <shshang> I can raise my hand(s)
14:26:29 <aveiga> I'll take an AI to write up the proposal
14:26:30 <ijw> aveiga: we had two cores onside anyway
14:26:42 <ijw> (Mark, Salvatore)
14:26:55 <aveiga> ijw: I'm referring to them telling us to reuse enable_dhcp
14:26:56 <sc68cal> #action shshang send e-mail to mailing list regarding new attribute
14:26:58 <aveiga> that's not going to work
14:27:08 <ijw> Didn't I do that yesterday?
14:27:11 <ijw> ... are those my feet?
14:27:17 <aveiga> they fired back about it
14:27:45 <ijw> They agreed strenuously, I think that's fine
14:28:20 <ijw> They say 'backwards compatible with enable_dhcp' - I'll check what Mark has in mind on IRC when he turns up too if you like
14:28:32 <aveiga> yes, I'd like to have that chat with him
14:28:37 <aveiga> we need two keywords
14:28:47 <ijw> Ok, keep an eye in #openstack-neutron later
14:28:57 <aveiga> or perhaps we'll have to write all the permutations out as enumerations (ick)
14:29:14 <ijw> Yup, agreed, and unless he's telling us to control dhcp6 from the dhcp flag (I don't think so) then we just reserve enable_dhcp for v4 behaviour
14:29:36 <ijw> Since v6 is busted that is backwards compatible, I think
14:29:43 <ijw> I'll check with evan too
14:29:58 <aveiga> sc68cal: I think we're settled here
14:30:20 <sc68cal> OK.
14:30:25 <sc68cal> #topic open discussion
14:30:43 <sc68cal> We're making some headway on the hairpinning bug
14:31:00 <baoli__> Question about dnsmasq instances. how to determine one needs started? separate ipv6 instance?
14:31:28 <ijw> As far as I'm concerned, shshang can do what he pleases as long as it implements the spec ;)
14:31:32 <sc68cal> baoli__: I believe dnsmasq processes are launched per subnet
14:31:37 <aveiga> baoli__: if the option we pick for enabling dhcp is set to anything but off, you'll have to start one
14:31:46 <sc68cal> or possibly per network -
14:31:57 <baoli__> sc68cal, it's per network.
14:32:08 <ijw> baoli__: not for v6 it isn't
14:32:14 <ijw> You need it in your router namespaces
14:33:19 <baoli__> ijw, if you add a subnet into a router, then you will have one instance per subnet?
14:33:30 <ijw> The minimal number that will do is one per router (for RAs) plus one for all the subnets that don't have routers (which you could load all the dhcpv6 work onto)
14:34:06 <baoli__> My qeustion is what if the subnet is not added into a router, but enabled with ipv6?
14:34:25 <sc68cal> it's the other way around, I believe
14:34:33 <sc68cal> routers are added to subnets
14:34:44 <sc68cal> via the API
14:35:11 <aveiga> I think it only depends on our mode settings
14:35:19 <ijw> Either way, you need (at least) one dnsmasq per net with detached subnets that have address discovery enabled.
14:35:29 <aveiga> if we set the RA mode off and the address mode off, you don't need one
14:35:34 <baoli__> usage: neutron router-interface-add [-h] [--request-format {json,xml}]                                     router-id INTERFACE  Add an internal network interface to a router.  positional arguments:   router-id             ID of the router   INTERFACE             The format is "SUBNET|subnet=SUBNET|port=PORT". Either                         a subnet or port must be specified. Both ID and name                         are acc
14:35:36 <aveiga> otherwise, you follow the settings
14:35:49 <baoli__> sorry, the format is not good to see
14:36:14 <ijw> Yeah, that port doesn't really work for us any more.  Ports are in one of the subnets for v4 but all of them for v6
14:36:28 <aveiga> I think this will be clarified better one the keyword stuff is nailed down
14:36:32 <aveiga> once*
14:36:52 <shshang> baoli, in your case (private network), all modes and keywords we discussed here is still valid, however, inside the code, the way I am writing it now is to detect whether gateway exist and launch dnsmasq accordingly
14:37:13 <aveiga> shshang: I think it doesn't need to detect anything
14:37:17 <aveiga> just follow the keywords
14:37:29 <shshang> the CLI doesn't, but code need to
14:37:32 <aveiga> I don't want to go down that hole where we have to detect things
14:37:52 <baoli__> shshang, so without a router, the VM won't be able talk ipv6?
14:37:56 <shshang> the code need to differetiate whether the subnet has router port, or not
14:38:08 <shshang> it still can
14:38:26 <shshang> but the code needs to decide where to launch the dnsmasq
14:38:29 <aveiga> baoli__: without a router, you'd either have link local only or you set dnsmasq to issue RAs for SLAAC
14:38:43 <shshang> yup
14:39:15 <baoli__> aveiga, so you need to enable ipv6 in the dnsmasq running in the dhcp namespace?
14:39:27 <aveiga> that was my next question
14:39:36 <shshang> the answer is yet
14:39:38 <shshang> yes
14:39:42 <aveiga> are we running one dnsmasq per network, or one per subnet?
14:39:48 <sc68cal> per network
14:40:02 <baoli__> per network as far as I saw it from my test
14:40:16 <shshang> per subnet
14:40:27 <aveiga> that begs the question
14:40:30 <sc68cal> If anything, dnsmasq was being too helpful - it was adding entries to the leases file for ports that were on subnets that didn't have dhcp enabled
14:40:40 <aveiga> when you want an RA on the router port, you have to run another dnsmasq
14:40:47 <aveiga> is this the case?
14:40:50 <shshang> yup
14:40:54 <sc68cal> #link https://review.openstack.org/#/c/64578/ Ensure entries in dnsmasq belong to a subnet using DHCP
14:41:01 <shshang> that is the hardest part
14:41:15 <shshang> aveiga, I have been pulling my teeth to get that work...
14:41:43 <aveiga> I'm sure
14:41:55 <aveiga> this is why I suggested running radvd instead of an extra dnsmasq
14:42:06 <aveiga> but that complicates matters when you don't have a router
14:42:19 <aveiga> damned if you do, damned if you don't
14:42:26 <shshang> LOL...very true
14:42:36 <sc68cal> Should we hook into the code that creates a router in neutron
14:42:39 <sc68cal> to launch rtadvd?
14:43:05 <aveiga> sc68cal: your BSDisms are showing :-P
14:43:22 <sc68cal> :)
14:43:36 <baoli__> just tried to add a subnet, and here it is:ps -ef | grep dnsmasqnobody    2898     1  0 14:42 ?        00:00:00 dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tap7c0d258a-dc --except-interface=lo --pid-file=/opt/stack/data/neutron/dhcp/133288d6-9b9a-42ff-9eed-daee8a539410/pid --dhcp-hostsfile=/opt/stack/data/neutron/dhcp/133288d6-9b9a-42ff-9eed-daee8a539410/host --dhcp-optsfile=/opt/stack/data/
14:44:08 <sc68cal> s/rtadvd/radvd/
14:44:17 <aveiga> sc68cal: I knew what you meant
14:44:47 <baoli__> --leasefile-ro --dhcp-range=set:tag0,10.0.0.0,static,86400s --dhcp-range=set:tag1,20.20.20.0,static,86400s --dhcp-lease-max=512 --conf-file= --domain=openstacklocal 1000      3225  3025  0 14:42 pts/3    00:00:00 grep --color=auto dnsmasq
14:45:16 <sc68cal> I believe "133288d6-9b9a-42ff-9eed-daee8a539410" is the network id
14:45:28 <baoli__> two subnets 10.0.0.0/24 & 20.20.20.0/24.
14:45:54 <aveiga> right, it's one instance per network
14:46:20 <baoli__> yes
14:46:30 <shshang> in IPv6, you have to be one instance per subnet, due to default route
14:46:43 <shshang> assuming you want dnsmasq to send out RA
14:46:52 <aveiga> shshang: only if you're issuing DHCPv6 from the router namespace
14:47:04 <aveiga> and actually, not even
14:47:09 <aveiga> it's still one per network
14:47:14 <aveiga> you issue the RA per subnet
14:47:37 <aveiga> dnsmasq should be able to issue multiple RAs
14:47:58 <shshang> Yes, dnsmasq will issue the RA per subnet, and, dnsmasq needs to bind to the default gw port
14:48:16 <baoli__> I'm not sure if the router port is numbered with IP addresses from multiple subnets in the same network
14:48:26 <aveiga> oh, that's the problem
14:48:33 <aveiga> it's because you can't do that in ipv4
14:48:51 <aveiga> ugh, that means we have to run one per subnet
14:48:58 <shshang> yup
14:49:11 <aveiga> however
14:49:21 <ijw> Well, we would want to fix the port addressing
14:49:24 <aveiga> if you ran dnsmasq on the dhcp namespace
14:49:31 <ijw> Or, at least, we could
14:49:37 <aveiga> you could probably run radvd on the router namespace for each port
14:49:58 <aveiga> I still think it's better to decouple them, even in the actual code
14:50:01 <aveiga> makes it cleaner
14:50:29 <shshang> you mean, decouple which two?
14:50:37 <aveiga> addressing and RA
14:50:49 <aveiga> i.e. run dnsmasq where it normally runs
14:50:55 <aveiga> and run radvd on the router namespace
14:51:14 <aveiga> just don't have dnsmasq do the RAs at all
14:51:26 <shshang> agreed. I think you successfully convinced me. :D
14:51:35 <ijw> If it were me, for the sake of simplicity and also so that dhcp doesn't jump addresses when you attach a router, I would run one process for DHCP and one for RA.  And, if it were me, I would also run the v6 process indepdently of v4, at least until we've established things are working.
14:51:54 <ijw> Optimise later.
14:51:54 <shshang> now I can only use what we have...i.e. dnsmasq.
14:52:13 <aveiga> ijw: I'd agree with you, except for the fact that neutron mlk has been abuzz with performance issues recently
14:52:19 <aveiga> ml*
14:52:36 <baoli__> aveiga, that's probably a good idea
14:52:58 <ijw> Yes, though I don't know that we would necessarily be making performance much worse by doing this (where specifically we're talking about the turnaround for adding a port)
14:53:17 <aveiga> ijw: I agree
14:53:24 <aveiga> so let's try it
14:53:31 <ijw> It's kill -HUP on more processes - but we're going to be doing that anyway, and it's a function call not a command (ovs-vsctl is the root of all evil tbh)
14:53:33 <aveiga> just expecet a mislead -1 here and there
14:54:29 <baoli__> Another question, are we going to support ipv6 prefix delegation with dhcp?
14:54:44 <shshang> yes, that is in Sean's original proposal
14:54:52 <baoli__> ok
14:54:54 <aveiga> baoli__: yes, but I think that's a J thing
14:55:02 <aveiga> it's too much to get out the door for Icehouse
14:55:02 <baoli__> I see
14:55:06 <shshang> but not sure whether it makes to icehouse....
14:55:08 <baoli__> agree
14:55:19 <aveiga> it's in my backlog to writeup though
14:55:26 <ijw> I'd put that the other way - fundamental addressing, then fundamental routing, then whatever we can fit in
14:55:28 <aveiga> we'll need it for advanced services VMs
14:56:01 <aveiga> we have 5 minutes left
14:56:11 <aveiga> anyone else have anything they want to bring up?
14:56:19 <ijw> shshang: ping me when you have a patch up and I'll come check it out
14:56:25 <baoli__> Sean, how can I access to your original proposal? Are they all accessible from the meeting wiki?
14:56:29 <ijw> Daniel B has -1'ed the hairpin, I see
14:56:44 <ijw> Can't track him down on here, I thought he was berrange but if he is he ain't on
14:57:00 <ijw> Looks very like he's been out a week.  I'll deal with it
14:57:02 <sc68cal> baoli__: check the blueprints
14:57:22 <sc68cal> I believe our wiki page for the subteam meetings will have links
14:57:24 <baoli__> ok, thanks
14:57:48 <baoli__> Do you think I can work on it?
14:58:53 <sc68cal> baoli__: the prefix delegation?
14:58:59 <baoli__> Sean, yes
14:59:26 <sc68cal> I don't know if we have a specific blueprint to cover it - feel free to register it and start the work
14:59:37 <baoli__> cool, thanks
14:59:40 <sc68cal> make sure you base it on top of the dnsmasq topic
14:59:48 <baoli__> absolutely
15:00:19 <sc68cal> ok everyone, till next week
15:00:22 <sc68cal> #endmeeting