13:59:45 <sc68cal> #startmeeting neutron_ipv6
13:59:46 <openstack> Meeting started Tue Mar 11 13:59:45 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:59:49 <openstack> The meeting name has been set to 'neutron_ipv6'
14:00:25 <sc68cal> #info last week was the merge window for I-3
14:00:33 <xuhanp> hello
14:00:49 <sc68cal> xuhanp: hello
14:01:16 <baoli> Hi
14:01:23 <sc68cal> There is a process for getting features into Icehouse, after the merge window has closed
14:01:32 <xuhanp> did we miss the chance to merge already?
14:02:25 <sc68cal> xuhanp: Yes - but but we can lobby for a feature freeze exception
14:02:54 <sc68cal> my concern though is that we're still undergoing code reviews
14:03:20 <sc68cal> and we don't have anything in tempest to test everything we've written
14:03:23 <xuhanp> sc68cal, I saw L3 HA making the request. I guess we should do the same?
14:03:55 <sc68cal> I think they're getting merged as an experimental feature
14:04:25 <sc68cal> not sure if we can have the same leeway
14:04:53 <absubram__> hi
14:06:08 <sc68cal> So - I guess we can think on it for a bit while we go through the regular agenda
14:06:25 <sc68cal> #topic blueprints
14:07:04 <sc68cal> #link https://wiki.openstack.org/wiki/Neutron/IPv6 Ipv6 blueprint list
14:07:50 <sc68cal> Do we have any new blueprints to discuss?
14:08:13 <baoli> sc68cal, I added the prefix delegation BP
14:08:55 <xuhanp> baoli, did you add just now? I didn't see that yet.
14:08:58 <sc68cal> #link https://blueprints.launchpad.net/neutron/+spec/ipv6-prefix-delegation PD blueprint
14:09:06 <baoli> a few days agao
14:09:15 <baoli> s/agao/ago
14:09:57 <xuhanp> guess we need to add it to the wiki, then :-)
14:10:11 <sc68cal> I think it shows up in the search
14:10:31 <sc68cal> for the first link in the wiki that searches for bps w/ ipv6 in them
14:10:32 <baoli> sc68cal, yes
14:10:51 <baoli> Do you want me to add it as a separate link?
14:11:01 <baoli> in the wiki?
14:12:03 <sc68cal> I think it's OK for now
14:12:11 <baoli> sc68cal, ok.
14:12:23 <sc68cal> we may make a new wiki page under ipv6 for it so we can hash it out
14:12:37 <sc68cal> once we start figuring out how to implement it
14:13:13 <sc68cal> My initial thought is that it'll be an API extension
14:13:20 <xuhanp> sc68cal, shall we try to propose some summit sessions for the blueprints?
14:13:32 <xuhanp> I heard that's open now.
14:14:14 <sc68cal> xuhanp: yes that would be good
14:14:20 <sc68cal> worst case they may get merged with http://summit.openstack.org/cfp/details/21
14:14:46 <xuhanp> we don't need to wait for that to start the design and discussion, for sure
14:15:27 <sc68cal> agreed
14:15:47 <sc68cal> Do we have any other BPs to discuss??
14:16:14 <baoli> sc68cal, I'll propose a ipv6 PD session
14:16:26 <sc68cal> baoli: perfect
14:16:58 <xuhanp> I haven't think about the details of the security group BP, yet.
14:17:17 <xuhanp> I can propose one for security group
14:17:33 <xuhanp> several improvements to make
14:17:40 <baoli> cool
14:18:45 <xuhanp> do we need a BP for privacy extension?
14:18:59 <aveiga> xuhanp: I'm not sure we can
14:19:05 <sc68cal> I think in the past we chose not to
14:19:16 <aveiga> how can you predict the PE address?
14:19:19 <aveiga> also, they rotate
14:19:27 <aveiga> I don't think that's feasible
14:21:40 <sc68cal> Anything else? or we'll continue on to bugs
14:21:43 <absubram__> Hi Sean.. any update on the existing review for - https://review.openstack.org/#/c/52983/  The two new IPv6 attributes?. I see that it is marked as a WIP..
14:21:56 <absubram__> is it still going to make it into I?
14:22:05 <sc68cal> we'll discuss that in a bit
14:22:14 <absubram__> ok thanks!
14:22:20 <sc68cal> #topic bugs
14:23:07 <sc68cal> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 Bugs tagged ipv6
14:23:43 <sc68cal> If you have any existing bugs that do not have the ipv6 tag, please add it for tracking purposes
14:24:00 <sc68cal> but I think we've got the majority tagged
14:24:28 <shshang> Do we need to mention them in our code review?
14:25:26 <sc68cal> if your code review fixes them, and does not implement a blueprint
14:26:25 <sc68cal> Anything else, or we can move on to the code review topic
14:26:52 <xuhanp> For your information, I created a new bug to fire RA rule when router is created or updated. As the follow up action from last time.
14:26:58 <xuhanp> #link https://bugs.launchpad.net/neutron/+bug/1290252
14:27:08 <sc68cal> excellent
14:27:11 <xuhanp> will try to submit a patch soon
14:28:06 <sc68cal> #topic code review
14:28:28 <baoli> xuhanp, I saw your latest update on the RA rule bug. It looks better
14:28:33 <sc68cal> absubram__: We're still working on reviewer comments on the ipv6 two attribute reviews
14:28:58 <xuhanp> baoli, thanks. I think I followed our discussion. Please let me know if you still have comments.
14:29:23 <baoli> One general question. If a gateway with LLA is provided in the subnet, shall we allow the subnet to be added to a router?
14:29:27 <sc68cal> aveiga: Refresh my memory, we said that the enable_dhcp flag is meant to govern if the v6 attributes can be set or now?
14:29:34 <sc68cal> *or not?
14:29:47 <aveiga> well, we didn't specify that
14:29:54 <absubram__> sc68cal: ok.. I've been asked if the Horizon BP should be moved out to J
14:29:57 <aveiga> just that is enable_dhcp was false we'd ignore flags
14:30:12 <aveiga> s/is/if
14:30:21 <sc68cal> aveiga: OK - because a recent comment from salvatore was about that
14:30:32 <aveiga> I don't know if we should force them to not be set at all, or just ignore them
14:30:44 <aveiga> that one is tricky
14:30:48 <sc68cal> https://review.openstack.org/#/c/52983/34/neutron/db/db_base_plugin_v2.py
14:31:13 <sc68cal> line 863
14:31:38 <xuhanp> aveiga, I think we should prompt error message since it confuses user.
14:32:17 <aveiga> xuhanp: I'm tempted to agree with you. But what about cases when the v6 attrs are set, then someone later sets enable_dhcp to false?
14:32:49 <sc68cal> I actually have a unit test for that
14:32:56 <sc68cal> and the validation blocks the update
14:32:57 <aveiga> in that case...
14:33:05 <aveiga> sure, throw a warning
14:33:17 <sc68cal> it actually throws an error currently
14:33:41 <sc68cal> if you want to switch enable_dhcp to false, you need to clear the v6 attributes
14:33:54 <xuhanp> still prefer an error to force user to update the IPv6 attributes first before setting dhcp to false.
14:33:55 <absubram__> sorry.. I didn't follow.. so the new IPv6 attributes can now be set only if enable_dhcp is set?
14:34:12 <aveiga> absubram__: this was always the case
14:34:21 <absubram__> I see
14:34:27 <aveiga> the cores wanted the old enable_dhcp flag to still be there and be an override
14:34:34 <aveiga> for backwards compat
14:35:23 <shshang> so we have to zero out all ipv6 attribute if user set "enable_dhcp" to False??
14:36:04 <xuhanp> shshang, I think this was agreed when we started the two attributed design :-)
14:36:49 <shshang> yes...I vaguely remember that discussion....I am not sure what value we expect user to unset the IPv6 attributes to....
14:36:53 <shshang> You know what I mean?
14:37:24 <xuhanp> I guess just need to set to nothing
14:37:28 <aveiga> shshang: they would go back to being off
14:37:39 <aveiga> if I remember correctly, "off" was really unset
14:37:54 <shshang> Yup...I remember we discusssed "off" mode too...
14:37:54 <xuhanp> aveiga, yep
14:37:57 <absubram__> ok.. will this check be done in neutron? Will you need me to add the check in Horizon too? By default I see that we set enable_dhcp in Horizon
14:38:24 <aveiga> absubram__: neutron will do this.  Horizon should just read the current attr for a network
14:39:47 <shshang> I would like to point out one thing....we don't have "off" mode defined in the constant file.
14:40:02 <sc68cal> yes - because we keep confusing "off" with ATTR_NOT_SPECIFIED
14:40:03 <shshang> And in my opinion, we should have one, and it should be treated differently with NONE
14:40:16 <aveiga> shshang: why? It's not actually different
14:40:35 <shshang> for coding efficiency and testing efficieny
14:40:47 <sc68cal> actually it makes the code more complex
14:41:00 <sc68cal> now I have to check for ATTR_NOT_SPECIFIED, as well as the string value "off"
14:42:03 <sc68cal> I had to spend a couple hours on the validation for enable_dhcp and the attributes
14:42:06 <shshang> Current way to validate the input cannot differentiate between off mode and invalid mode
14:42:19 <sc68cal> especially with updating a subnet - the logic got a bit messy
14:42:23 <shshang> what if user type in bogus value, such as "active"?
14:42:35 <sc68cal> shshang: that would get denied at the API layer
14:42:41 <sc68cal> it's not a valid value from the constants
14:43:12 <shshang> off mode, invalid mode, and nothing specified.
14:43:20 <sc68cal> the validation of the correct modes, along with the enable_dhcp setting is at the DB layer, once all the attributes have been validated as proper
14:44:28 <absubram__> sc68cal: Additionally, I got my question about the update subnet answered in the mailer thanks.. but looks like there is an inherent issue in Horizon with subnet update that needs to be fixed first.. so Horizon doesn't support update just yet
14:44:49 <sc68cal> absubram__: OK - that's fine
14:45:01 <shshang> sc68cal, let us discuss this constant offline.
14:45:18 <sc68cal> shshang: agreed.
14:45:24 <sc68cal> we can take it to the ML
14:45:33 <shshang> sure
14:46:09 <shshang> I also had a code review question needing your help. :)
14:46:55 <baoli> A couple of questions related to this review
14:47:12 <absubram__> yes please.. please let me know if the values for the attributes change.. I had the same confusion with the "off"
14:47:13 <baoli> in the port-create, the user can specify extra dhcp options
14:47:33 <shshang> absubram__, we will keep everybody updated
14:47:39 <baoli> Would that be blocked if it won't be used at all?
14:49:04 <baoli> also in the subnet-create api, user can specify dns nameserver
14:50:36 <xuhanp> baoli, do you mean the --extra-dhcp-opt option for port create?
14:50:46 <baoli> xuhanp, yes
14:52:04 <xuhanp> I think it get passed to dnsmasq, but I am not sure about the validation
14:52:16 <xuhanp> I think the extra-dhcp-opt extension itself has some validation, right?
14:53:08 <shshang> Will --extra-dhcp-opt value be saved to dnsmasq opt files?
14:53:17 <baoli> It looks like that dnsmasq opts file is generated based on that
14:53:42 <sc68cal> There are unit tests that check all that
14:53:54 <sc68cal> Provided shshang's patch passes all unit tests
14:53:56 <sc68cal> we are not breaking that
14:54:01 <xuhanp> shshang, I think it does for IPv4. not if you processed them for IPv6 in your patch.
14:54:36 <shshang> I did...the dnsmasq also load the opt file for IPv6 subnet
14:56:56 <baoli> It appears with the ipv6 patch, whether or not the opt file should be added in the command line is based on the two modes?
14:57:17 <shshang> baoli, that is correct
14:57:44 <shshang> the ipv6 subnet process that opt file, so as long as the values are dumped to opt file, ipv6 subnet should be aware of it.
14:57:45 <xuhanp> dns-server is also passed to opt file.
14:58:04 <shshang> but whether the opt is loaded to dnsmasq is determined by the modes combo
14:58:23 <xuhanp> I think baoli means we should throw error when opt file is not needed?
14:58:41 <xuhanp> I mean when extra dhcp opt is specified.
14:58:50 <xuhanp> and opt file is not needed
14:59:13 <shshang> oh, when user specify the extra dhcp opt, but actually opt file is not needed?
14:59:19 <shshang> that is a good point...
14:59:27 <sc68cal> looks like we're going to have to move this to the ML
14:59:30 <sc68cal> we're out of time
14:59:32 <baoli> xuhanp, shshang, the user should be aware in some cases that those info are not needed.
14:59:37 <shshang> yes
14:59:38 <shshang> agree
14:59:42 <xuhanp> +1
14:59:43 <shshang> send email to ML and let us continue
14:59:45 <sc68cal> See everyone next week
14:59:53 <sc68cal> #endmeeting