15:00:29 <sc68cal> #startmeeting neutron_ipv6
15:00:30 <openstack> Meeting started Tue Jan  6 15:00:29 2015 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:35 <openstack> The meeting name has been set to 'neutron_ipv6'
15:00:51 <xuhanp> hello
15:00:57 <SridharG> hi everyone..
15:00:59 <johnbelamaric> hi
15:01:28 <aveiga> hello
15:02:06 <sc68cal> K-2 milestone is approaching
15:02:28 <sc68cal> mestery just put an e-mail on the ML that people should take a look at if you have a BP set for k-2, and it has been set to blocked
15:02:48 <mestery> sc68cal: Ack :)
15:03:12 <sc68cal> xuhanp: I saw you have a BP for k-2 that is set as blocked, for dhcp opts, but I knwo you have code submitted, please ping mestery regarding
15:03:27 <xuhanp> sc68cal, will do
15:03:47 <mestery> xuhanp: Can you make sure the reviews are in the LP BP? I'll mark it as "In Progress" at that point. Thanks!
15:04:12 <sc68cal> xuhanp: I think you need to update the commit message to have the implements bp line so it'll associate
15:04:15 <xuhanp> mestery, I will add the review links if they are not there. Thanks!
15:04:30 <mestery> awesome, thank you xuhanp and sc68cal!
15:04:40 <xuhanp> I thought I already did. Will double check
15:05:08 <sc68cal> #link https://launchpad.net/neutron/+milestone/kilo-2 kilo 2 milestone bps
15:06:41 <sc68cal> That's all I had really for today - I imagine people are coming back from holidays and such
15:07:45 <xuhanp> sc68cal, I have one topic to discuss.
15:07:54 <sc68cal> xuhanp: all yours :)
15:08:30 <xuhanp> I opened a bug for if we should create DHCP port and spawn dnsmasq when ipv6_address_mode is None or SLAAC.
15:08:51 <xuhanp> Currently the port is created and dnsmasq is spawned.
15:09:15 <xuhanp> Since the dhcp driver only checks if dhcp is enabled.
15:09:47 <xuhanp> and dhcp is enabled for backward compatibility as long as ra or address mode is set.
15:09:59 <xuhanp> https://review.openstack.org/#/c/144943/
15:10:51 <HenryG> xuhanp: I think the concept is fine
15:11:23 <xuhanp> HenryG, you mean dhcp is enabled although dhcpv6 is "Not" enabled?
15:11:23 <HenryG> xuhanp: I am still thinking about Armando's comment
15:11:26 <sc68cal> interesting - I know we have a check in other parts of the code
15:11:40 <sc68cal> it may be for populating entries in the hosts file
15:11:59 <sc68cal> but yeah it may still spawn the dnsmasq process
15:12:09 <xuhanp> sc68cal, right. But I was thinking it's not even needed to create the port and spawn the dnsmasq process.
15:12:23 <xuhanp> or create the dhcp namespace.
15:12:25 <sc68cal> xuhanp: agreed
15:12:54 <HenryG> xuhanp: I mean the concept of your change is fine
15:13:08 <xuhanp> HenryG, I see.
15:13:42 <xuhanp> HenryG, I was thinking about Armando's comment as well. And I think maybe we can do more checking when subnet is created.
15:14:22 <HenryG> xuhanp: great, looking forward to see what you come up with
15:14:22 <xuhanp> if enable_dhcp is not really true (conflict with address mode), we could just give a Invalid input error.
15:15:04 <xuhanp> but I am not sure if this makes the two attributes even more complicated.
15:15:26 <sc68cal> I think we already have some logic to block that
15:15:39 <sc68cal> where if enable_dhcp = false we don't let you set the ipv6 attrs
15:15:50 <sc68cal> i'll have to double check
15:16:24 <HenryG> xuhanp: Also be aware of this review: https://review.openstack.org/#/c/145102/1/neutron/agent/linux/dhcp.py
15:16:32 <xuhanp> sc68cal, that's right. But now I think we should enforce enable_dhcp = false when address_mode is None or SLAAC.
15:16:42 <xuhanp> since dhcpv6 is not enabled.
15:16:55 <sc68cal> ah
15:17:27 <sc68cal> sadly i think that overcomplicates - I already kind of dislike the enable_dhcp flag ...
15:17:53 <xuhanp> sc68cal, that's my worry too.
15:18:05 <SridharG> +1
15:18:16 <sc68cal> I don't have a better answer then clapping my hands over my ears and going LALALLALALAL
15:18:41 <HenryG> yeah
15:19:30 <xuhanp> Then I will stick to my original fix and see if Armando can be convinced.
15:19:36 <rprakash> Can we have seperation as enable_dhcp_ipv4 and dhcp_enable_ipv6 to avoid any conflicts?
15:20:23 <aveiga> rprakash: that's proposing an API change
15:20:24 <sc68cal> rprakash: we could, but I kind of dislike having all these flags floating all over the place
15:20:38 <sc68cal> it makes validating all the possible combos a nightmare
15:20:57 <aveiga> it might also break backward compatibility
15:21:02 * sc68cal hopes Neutron V3 API will fix everything and give him a pony
15:21:32 <SridharG> Personally I feel that enable_dhcp should be de-coupled from IPv6 attributes. As IPv6 has its own set of valid/in-valid combinations.
15:22:12 <HenryG> Another possibility might be to say that for v6, the dhcp setting is inferred from the two mode attributes and so we "suggest" that enable_dhcp is not specified for v6 subnets.
15:22:26 <sc68cal> SridharG: the trouble is that enable_dhcp flag was used basically to determine if Neutron was going to do anything about a network, it had a lot of overloaded meaning
15:22:43 <HenryG> If it is specified then it should not conflict with the modes.
15:23:33 <HenryG> But that leaves the issue of the default value if it is not specified. :(
15:23:44 <HenryG> Ugh.
15:23:57 <SridharG> sc68cal: Agree. But if there is any re-factoring in place, it would be good to consider de-coupling this.
15:24:14 <sc68cal> HenryG: I think enable_dhcp is set to true by default...
15:24:26 <xuhanp> sc68cal, that's correct.
15:25:23 <rprakash> So if IPAM is external will this flag carry same meaning as DHCP is then not in neutron?
15:25:53 <sc68cal> rprakash: I think we have to wait for an extrnal ipam implementation first
15:25:59 <rprakash> ok
15:26:34 <sc68cal> but yeah there's all kinds of fun corners to explore :)
15:27:03 <HenryG> So I think the best we can do now is reject a dhcp setting that conflicts with the modes?
15:28:20 <xuhanp> agree. I can try that in my review and see how the comments go.
15:29:55 <SridharG> when you get sometime, can you please have a look at the following patch and comment on it - https://review.openstack.org/#/c/136733/
15:32:20 <sc68cal> SridharG: sure, I'll take a look
15:32:31 <SridharG> thanks sc68cal
15:33:50 <HenryG> The only question left there is, Do we allow a (None, None) subnet to be associated with a router?
15:34:21 <sc68cal> Yes
15:34:26 <rprakash> Correct but what's the interpretaion of both modes being None?
15:34:27 <HenryG> The answer seems to be "The user might have their own reason for it, so yes."
15:34:39 <sc68cal> There may be implementations that can do IPv6 without requiring the option ipv6 attrs
15:34:50 <sc68cal> s/implementations/plugins
15:35:04 <rprakash> I see
15:35:13 <sc68cal> I don't know if there actually are, but in theory it is possible
15:35:38 <HenryG> I think we can allow it. If it doesn't work then it's not really neutron's fault.
15:37:15 <rprakash> Sice no tests have been set to check this we should let it go
15:38:52 <HenryG> I will change my vote to +1 and allow a day or two for objections.
15:39:52 <rprakash> May be setup a new bug asking invetigating if the mode none combo is allowed and let this patch be released
15:40:47 <rprakash> makes sense
15:41:18 <SridharG> cool. HenryG I'll update the patch with the review comments you had (some minor nits).
15:41:41 <HenryG> thanks SridharG
15:45:22 <sc68cal> If we don't have anything else to discuss I'll give everyone back 15 minutes
15:46:14 <dane_leblanc> I have a question about licensing for a 3rd party utility, don't know if anyone is an expert on that here
15:46:53 <sc68cal> I think typically bsd/apache license is required
15:47:00 <dane_leblanc> Specifically we might want to use dibbler for prefix delegation, but it has a GNU GPL license
15:47:15 <rprakash> +1
15:47:51 <sc68cal> dane_leblanc: dnsmasq is gpl
15:48:12 <dane_leblanc> So sounds like GNU GPL license is acceptable
15:48:18 <sc68cal> I think they just don't want GPL libraries, but python code that orchestrates a 3rd party utility like dibbler is ok
15:48:26 <rprakash> note for reference check Opensosurce Initiative OSI site opensource.org
15:48:54 <rprakash> link http://opensource.org
15:50:46 <rprakash> the royalty free usage comes with apache and bsd so derivatives can be used freely with no no copyright issues ulike GNUP GPL copyleft criterions
15:52:10 <rprakash> otherwise GNU LGPL earlier called Library based now Larger is preferred by commercial users
15:54:01 <rprakash> possibly we can close with this ...
15:54:13 <sc68cal> OK everyone - I'll be in #openstack-neutron if anyone needs anything - otherwise see everyone next week
15:54:20 <dane_leblanc> Sounds like we're okay as long as we don't have to modify the original
15:54:36 <sc68cal> dane_leblanc: yeah I think so
15:54:57 <dane_leblanc> Thanks rprakash
15:55:58 <sc68cal> #endmeeting