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