14:00:02 <sc68cal> #startmeeting neutron_ipv6
14:00:03 <openstack> Meeting started Tue Jun 10 14:00:02 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:06 <openstack> The meeting name has been set to 'neutron_ipv6'
14:00:10 <baoli> Hi
14:00:40 <xuhanp> hi
14:00:41 <SridharG> hello everyone..
14:00:58 <sc68cal> #link https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_June_10th
14:01:27 <sc68cal> #topic blueprints
14:02:15 <sc68cal> Do we have any new blueprints to discuss?
14:04:33 <sc68cal> If not, we'll continue to code reviews
14:04:50 <xuhanp> sc68cal, I saw Shixiong just joined, so shall we discuss the dnsmasq review?
14:05:08 <sc68cal> xuhanp: sure, that's a good idea
14:05:11 <aveiga> silence indicates acceptance, sc68cal
14:05:14 <sc68cal> #topic code review
14:05:17 <aveiga> might as well go to reviews
14:05:46 <Shixiong> sure
14:06:31 <sc68cal> xuhanp: you wanted to take on part of the dnsmasq changes, that was part of Shixiong's large patch?
14:07:14 <xuhanp> sure. depends how to divide it.
14:07:55 <sc68cal> #link https://review.openstack.org/#/c/70649/
14:08:05 <xuhanp> we already tested the code. Most of it works, except the one pid problem. And I will file a bug for DHCP security rule to allow dhcpv6 from dnsmasq
14:08:36 <sc68cal> xuhanp: Cool. I saw you had a patch get accepted yesterday to allow DHCPv6 solicit through?
14:08:45 <sc68cal> err - out of a guest
14:09:03 <xuhanp> yep.
14:09:04 <Shixiong> xuhanp, I am still investigating that pid problem
14:09:30 <xuhanp> Shixiong, we also did some investigation on that. Can share with you if you need.
14:09:45 <xuhanp> I think we need to break your patch into smaller ones and submit for code review ASAP.
14:09:52 <xuhanp> give we are already at Juno-1
14:10:06 <Shixiong> That will be awesome.
14:10:21 <Shixiong> Do you want to have a meeting to talk about that, or you think email exchange should be fine?
14:10:40 <xuhanp> I can talk with you after this meeting on openstack-neutron if that's OK
14:11:18 <sc68cal> #link https://launchpad.net/neutron/+milestone/juno-1 J-1 milestone
14:11:24 <sc68cal> #link https://launchpad.net/neutron/+milestone/juno-2 J-2 milestone
14:11:33 <sc68cal> We've got a couple v6 BPs in both milestones
14:11:47 <aveiga> j1 is one week
14:12:22 <sc68cal> less than that :(
14:12:30 <sc68cal> I believe this thursday
14:13:22 <aveiga> 6/12
14:13:27 <aveiga> according to the link
14:13:45 <sc68cal> xuhanp: Shixiong: baoli: Take a look at J-2 milestone, there's two IPv6 blueprints in for J-2
14:14:13 <sc68cal> #link https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac
14:14:23 <sc68cal> #link https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-radvd-ra
14:14:29 <baoli> saw that.
14:15:02 <baoli> sc68scal, thanks for your review on my spec
14:15:26 <sc68cal> baoli: you're very kind to say so, since I -1'd it..
14:16:07 <sc68cal> During the main meeting yesterday we brought up the issue of the 1 attribute vs 2 attributes (see the los)
14:16:12 <sc68cal> *logs
14:16:37 <baoli> sc68cal, is there a decision on that?
14:16:39 <sc68cal> There was only one dissenting opinion from the core team regarding 1 attr vs 2 attrs
14:17:14 <Shixiong> @xuhanp, I will have a meeting until noon today EST time. Is it possible we can chat at different time on the pid issue?
14:17:16 <sc68cal> this was in regards to getting the python-neutronclient change in
14:17:36 <xuhanp> Shixiong, sure.
14:18:15 <sc68cal> baoli: I *think* that for the most part the 2 attr is the way we're going to go
14:18:16 <Shixiong> I prefer give you and Jian Li a call so we can talk, which is more efficient
14:18:39 <xuhanp> Shixiong, sure.
14:18:45 <xuhanp> that works too.
14:18:56 <baoli> sc68cal, what's the reason for my bp to be on the j2 list?
14:19:10 <sc68cal> baoli: the radvd one?
14:19:18 <baoli> sc68cal, yes
14:19:49 <sc68cal> Do you think it can be done by J-2? or should we move it to j-3?
14:20:55 <xuhanp> sc68cal, are we already decided to go to the "1" attribute one proposed by baoli? I saw your comment on that spec still objects it.
14:21:16 <baoli> sc68cal, it's going to be a different implementation than what's currently being worked on. So schedule wise is not the concern for now
14:21:40 <sc68cal> xuhanp: No, we are still on the 2 attr track :)
14:22:04 <aveiga> baoli: what's different about it?
14:22:20 <baoli> aveiga, can you be more specific on your question?
14:22:27 <aveiga> it looks to me like that BP is for setting up radvd in the qrouter namespace to act as an RA daemon, and I fully support doing that
14:22:37 <Shixiong> xuhanp, I just sent you an email to your gmail account with proposed date. Please let me know if it works for you.
14:22:49 <xuhanp> Shixiong, got it. will reply
14:23:14 <baoli> aveiga, it's proposing one attribute in the subnet API.
14:23:45 <aveiga> https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-radvd-ra doesn't seem to propose any api changes
14:24:04 <sc68cal> Ah. I see the confusion
14:24:08 <aveiga> unless you meant a different BP
14:24:22 <sc68cal> Your Blueprint in LP talks about doing radvd and is a child of the two attributes BP
14:24:34 <sc68cal> but your spec in gerrit that you link to that bp is about the single attribute
14:25:19 <baoli> sc68cal, sorry for the confusion. I probably should've started a new BP.
14:25:37 <aveiga> +1 to that, because the LP version is something I'd love to see
14:26:05 <aveiga> it would actually make my idea for ipv6 floats incredibly easy
14:26:11 <baoli> aveiga, does that mean that there will be implementation in openstack to support slaac?
14:26:20 <aveiga> of course
14:26:33 <baoli> sorry, two implemenation in openstack to support slaac
14:26:59 <aveiga> sure, and why not? It should be a config/build option to pick dnsmasq vs radvd
14:27:00 <aveiga> besides, I think we need unicast RA
14:27:08 <baoli> aveiga, I agree with you that with the RA, a lot of other things may become easier.
14:27:32 <aveiga> unicast RA lets me add a float by just sending a new subnet advertisement to a single host :)
14:27:39 <aveiga> I'm writing a BP for this now, actually
14:28:32 <sc68cal> Yes, also if you have something slated for J-2, please make sure you have a spec in neutron-specs
14:28:45 <sc68cal> people are chomping at the bit to -1 and -2 stuff that does not have a spec in neutron-specs
14:29:15 <dane_leblanc> aveiga, if we're adding unicast RAs, that will impact the design spec I wrote for muliple prefixes per port
14:29:41 <aveiga> how does that implement selective prefix allocation?
14:29:51 <aveiga> I'd think it would actually be easier with unicast
14:30:04 <sc68cal> dane_leblanc: do you have a link for that spec?
14:30:17 <dane_leblanc> I was assuming SLAAC woudl be automatic... and not selective per port
14:30:35 <dane_leblanc> https://review.openstack.org/#/c/98217/
14:30:35 <aveiga> oh, misunderstanding
14:30:45 <aveiga> slaac for the fixed would be multicast still
14:31:20 <aveiga> we would only unicast RAs for extra features, like floats or prefix delegation nodes
14:31:22 <dane_leblanc> aveiga, okay... was thinking differently about floating ips
14:31:44 <dane_leblanc> I was thinking floating IPs would only use DHCP.
14:32:08 <aveiga> dane_leblanc: absolutely, buit the dhcpv6 solicit has to be initiated by RA still
14:32:12 <dane_leblanc> But your idea is less restrictive on admin
14:32:58 <aveiga> you either do this via unicasting RA's (easy) or filtering the multicasted RA to select hosts (harder, more state/config to track)
14:33:09 <sc68cal> baoli: What should we do about your launchpad blueprint, and the spec?
14:33:37 <baoli> sc68cal, I would create a new BP and link that to my spec.
14:33:57 <dane_leblanc> aveiga, agreed, unicast RA's would be less complicated
14:34:10 <sc68cal> OK. So I assume that we should remove https://blueprints.launchpad.net/neutron/+spec/neutron-ipv6-radvd-ra from the J-2 milestone
14:34:34 <baoli> sc68cal, well I'd still like to see the new bps put in the j-2
14:34:52 <sc68cal> baoli: you mean for the single attribute?
14:35:06 <aveiga> I'd like to see the radvd BP created as a -spec
14:35:44 <aveiga> either that or I'm going to file a bug against the dnsmasq implementation for not supporting unicast RA
14:35:46 <baoli> sc68cal, yes. it's for both single attr and radvd. Becasue I'm going to use radvd to implement it
14:35:57 <aveiga> baoli: can we split that?
14:36:15 <aveiga> one for the radvd implementation, and one for single that depends on radvd
14:36:29 <sc68cal> OK - so here's my concern. I already -1'd your spec for the single attribute saying that it'd kill momentum. Now we're removing a blueprint from J-2 for adding radvd, because you want to continue on this single attribute path
14:36:38 <baoli> aveiga, one attr doesn't depend on radvd.
14:36:48 <baoli> aveiga, it's the opposite
14:37:02 <aveiga> radvd doesn't depend on an api attribute
14:38:10 <baoli> sc68cal, you seem to suggest in the review that use one attr in the CLI
14:39:05 <baoli> So if one attr simplify the API, which is more important, I don't know the reason why we have to stick with the two attr.
14:39:07 <aveiga> baoli: the suggestion is that you could provide a method for using one attr in the cli if people feel that it's "too complicated" to use two
14:39:31 <aveiga> I am strongly against a signle api attribute, as I really need those knobs for finer grained configurations
14:40:06 <baoli> aveiga, any specific case that two attr can do but one attr can not?
14:40:18 <sc68cal> Let's take this off line
14:40:19 <aveiga> selectively toggling provider networks
14:40:29 <sc68cal> baoli: I asked you to send an e-mail to the mailing list about this last week, if I recall
14:41:02 <baoli> sc68cal, sorry, did you ask me to send configuration on dual stack?
14:41:48 <sc68cal> I'd have to check the logs to be certain
14:41:49 <baoli> sc68cal, didn't get a chance to do that. But the devstack patch commit message pretty much described how to do that.
14:42:39 <sc68cal> I don't believe everyone is aware of the devstack patch, so it's always useful to start a thread on the ML and link things
14:42:45 <baoli> https://review.openstack.org/#/c/87987/
14:44:09 <baoli> sc68cal, it will be on the review alias, if not on the developer alias
14:45:41 <baoli> aveiga, there is one value from my spec: provider_slaac, which excplicitly indicates provider net
14:46:20 <baoli> aveiga, that should cover the use case you guys are working on.
14:46:26 <sc68cal> Shixiong: xuhanp: So I think for now we have only one BP that is slated for j-2
14:46:34 <sc68cal> https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac
14:46:46 <sc68cal> Do you need help creating a spec for it in neutron-specs?
14:46:51 <Shixiong> Maybe this should be the one we focus on
14:47:21 <xuhanp> Shixiong, do you have plan to do that? I can certainly help if you need
14:47:38 <Shixiong> I am not sure what I need to do...to be honest....
14:47:51 <Shixiong> "creating a spec for it in neutron-specs"?
14:48:01 <xuhanp> We need to create a new code review in neutron-specs project
14:48:03 <sc68cal> I agree - plus I did some of the legwork for you, the patch for provider-nets slaac checks for constants.DHCPV6_STATELESS and does an eui64 address calculation, so I think the API is all set, we just need to do the dnsmasq piece
14:48:48 <sc68cal> https://review.openstack.org/#/c/86044/7/neutron/db/db_base_plugin_v2.py
14:48:52 <xuhanp> sc68cal, yep. that one is based on dazhao's patch, right?
14:49:01 <xuhanp> I have some memory on that one.
14:49:46 <xuhanp> Shixiong, I can help on the spec create if you are not familiar with that. and we can talk about how to speed up the dnsmasq code in our talk this week.
14:50:04 <xuhanp> if we are OK with that.
14:50:08 <Shixiong> Yup, that will definitely help.
14:50:12 <Shixiong> Thanks, Xuhan!
14:50:19 <xuhanp> Shixiong, welcome
14:52:19 <sc68cal> xuhanp: yup
14:55:13 <sc68cal> Does the ipv6-radvd-ra blueprint depend on the single attribute? I don't think it does
14:55:26 <sc68cal> so I'd like to sign someone up for the work, or else it's going to get moved out of J-2
14:55:36 <baoli> sc68cal, it talks about RA support in neutron
14:55:55 <baoli> and the supporting implementation will be using radvd
14:55:59 <sc68cal> yes, but it was a child of the two attribute blueprint
14:56:01 <sc68cal> in launchpad
14:56:13 <sc68cal> which meant that it was going to use the two attribute changes to the API
14:56:35 <sc68cal> I believe your neutron-spec review needed to link to a new blueprint in launchpad
14:56:41 <sc68cal> since that was an API change
14:56:49 <sc68cal> I'm sorry I didn't catch it sooner
14:57:47 <baoli> sc68cal, i didn't realize until today. Thanks for that. So I'm going to create a new BP and link the spec to the new BP
14:58:45 <sc68cal> OK, then I'm going to ask cores to move the radvd blueprint out of J-2 unless we have someoneone who wants to work on it
14:59:02 <aveiga> it needs a -spec first
14:59:06 <sc68cal> indeed
14:59:20 <aveiga> I guess I can work on the spec, but there's no way I'd be able to implement it
15:00:08 <sc68cal> OK, well that's all we have time for
15:00:25 <sc68cal> see everyone next week, let's start some threads on the ML
15:00:29 <sc68cal> #endmeeting