14:01:30 <sc68cal> #startmeeting neutron_ipv6
14:01:31 <openstack> Meeting started Tue Feb 11 14:01:30 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:35 <openstack> The meeting name has been set to 'neutron_ipv6'
14:01:50 <sc68cal> Hello everyone
14:01:58 <aveiga> hello
14:02:01 <xuhanp> hello
14:02:12 <shshang> hola
14:02:24 <baoli> hello
14:02:30 <sc68cal> #topic recap previous meeting
14:03:10 <sc68cal> #link http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-02-04-13.59.html Previous meeting log
14:03:29 <sc68cal> So last week, I had two items, post to the ML about our devstack config
14:03:36 <sc68cal> and edit the horizon blueprint
14:04:01 <sc68cal> Thankfully, someone else has taken up the horizon BP - so I'm not a SPOF on that
14:04:18 <sc68cal> and I did post our devstack config to the mailing list
14:05:00 <sc68cal> aveiga: you had an item to post to the ML, and I saw it yesterday yes?
14:05:09 <aveiga> yup
14:05:24 <aveiga> #link http://lists.openstack.org/pipermail/openstack-dev/2014-February/026792.html ML discussion about modes and validation
14:05:38 <sc68cal> #topic blueprints
14:06:15 <sc68cal> Looks like we've got some good discussion about that on the ML - saw a couple e-mails this morning
14:07:21 <sc68cal> Do we have any blueprints, or any questions about the validation?
14:07:50 <shshang> not so far
14:08:27 <xuhanp> we need new blueprints for the validation?
14:09:04 <aveiga> I don't think that warrants a new BP
14:09:12 <aveiga> should be part and parcel of the API
14:09:28 <sc68cal> +1
14:09:46 <sc68cal> if you guys just give me clear direction on what combos to reject, I can add it to the API validation method
14:09:58 <sc68cal> as xuhanp commented in the review
14:10:44 <sc68cal> If there isn't anything else, I'll turn it over to open discussion
14:10:56 <aveiga> sc68cal: I brought up in the ML discussion that I think the only truly invalid combos are when the RA and addr modes conflict
14:11:10 <aveiga> example, one is set to slaac while the other is set to stateful or something
14:11:28 <aveiga> but we should give it a day or two for the ML to look at it
14:11:39 <aveiga> since this was (my apologies) only a recent discussion
14:12:14 <sc68cal> OK. Can the check simply be if ra_mode != address_mode -> validation error?
14:12:24 <sc68cal> or is stateful + stateless a valid combo
14:12:39 <aveiga> no
14:12:47 <aveiga> because mode/off are valid
14:13:06 <aveiga> addr = stateful, ra = off for example
14:13:34 <sc68cal> gotcha. OK, I'll eyeball shshang 's pdf and build a table of good/bad values
14:13:54 <shshang> thanks, sc68cal!
14:13:54 <aveiga> on the subjeft of the pdf, does the BP whiteboard support tables?
14:14:04 <xuhanp> stateless and slaac is also valid
14:14:09 <aveiga> I'd like to convert the PDF to something a bit less dependant on outside systems
14:14:13 <shshang> it doesn't seem like. I tried it, but I cannot insert table
14:14:28 <sc68cal> We have a big wiki space on Openstack
14:14:39 <aveiga> I'll try adding it to the wiki
14:14:48 <shshang> that may be the way to go
14:14:49 <aveiga> xuhanp: I'm worried about that combo
14:14:51 <sc68cal> #link https://wiki.openstack.org/wiki/Neutron/IPv6 IPv6 Wiki
14:15:01 <aveiga> technically, yes it's possible and it will work
14:15:15 <aveiga> but you'll never initiate the stateless transaction without the O bit set
14:15:16 <sc68cal> I believe the wiki supports tables :)
14:15:51 <xuhanp> I may need to revisit the RFC to find out the details
14:16:47 <aveiga> xuhanp: the crux is that setting ra mode to slaac would be A=on, O/M=off
14:17:01 <aveiga> stateless mode would be A/O=on, M=off
14:19:20 <xuhanp> oh, I see. So stateless by dnsmasq mean external router need to set O=on
14:19:45 <aveiga> xuhanp: yeah, the RA needs the O bit set
14:19:51 <aveiga> wherever it comes from
14:20:48 <xuhanp> so why in the table, stateless and stateless is valid?
14:21:05 <aveiga> it should be
14:21:21 <aveiga> stateless RA sets A and O
14:21:43 <aveiga> stateless addr means auto-calculate the SLAAC address, but also have dnsmasq server up DNS and other options
14:21:57 <xuhanp> Oh. Right. I see :-)
14:22:33 <xuhanp> it just get confusing each time I look back at the two modes :)
14:22:57 <xuhanp> thanks for the explanation
14:23:01 <aveiga> so if the addr mode and the RA mode are the same, it's always valid
14:23:10 <aveiga> if either mode is off, it's also always valid
14:23:26 <aveiga> BUT, if both are on but not the same, I think those are the only real invalid modes
14:25:01 <aveiga> although technically ra slaac and addr stateless is functional, it just would never use the dhcp server that we'd run for no reason :-P
14:27:22 <sc68cal> any other blueprint stuff - otherwise I'll go to open discussion
14:27:54 <xuhanp> I wonder how is it going with shshang's part
14:28:13 <xuhanp> seems still a lot of work to do
14:28:29 <shshang> xuhanp, any specific subjects?
14:28:48 <xuhanp> no. Just wondering about your submitted change
14:28:58 <xuhanp> seems like you changed a lot of code
14:29:15 <shshang> yes, indeed
14:29:30 <shshang> I saw your comments yesterday and i will clarify it
14:29:46 <xuhanp> thanks
14:29:48 <shshang> but thanks for providing the comments
14:30:01 <xuhanp> no problem
14:30:37 <baoli> I have a question, if both modes are off (as indicated in the first two rows in shshang's table), Is the CIDR still required while creating the ipv6 subnet?
14:30:38 <shshang> If you think I overlooked anything, shoot me an email
14:30:54 <absubram> hi.. sorry just catching up on comments form earlier in the meeting.. so not all combinations of ra and address are valid huh?
14:30:58 <aveiga> baoli: I think it should be
14:31:09 <aveiga> absubram: nope
14:31:20 <baoli> aveiga, can you explain why?
14:31:32 <sc68cal> absubram: the API will return you an error if you pick a bad combo, if you're worried about the horizon bp
14:31:41 <aveiga> because if you're creating a subnet anyway, you intend to use it
14:31:46 <aveiga> otherwise why create it?
14:31:49 <absubram> sc68cal: thanks! that was going to be next Q :)
14:32:02 <aveiga> to points being made on the ML about multiple connections to the same subnet, this would deter that
14:32:15 <aveiga> or at leawst make it follow the validation bounds if they change them for SRIOV
14:32:39 <absubram> sc68cal: how are things looking on the neutron side though? see the review is still in progress?
14:33:01 <sc68cal> absubram: they are in progress - how are things on the horizon side?
14:33:15 <baoli> aveiga, in that case, would the user simply say enable IPv6 on my network?
14:33:45 <aveiga> yes, because creating the subnet would allow for an RA to be issued from an outside source
14:34:21 <aveiga> perhaps a further refinement down the road would be for FWaaS to validate that the RA is on the right network or drop it
14:34:26 <absubram> sc68cal: well I've updated the BP.. we have our weekly irc in a couple hours so will bring this up then.. let's see.. I think the only concern will be that we need to get this in after the neutron review is approved
14:34:42 <aveiga> so I think we should require a scope to be added for other systems to be able to do validation
14:34:48 <aveiga> even if we aren't using them yet
14:35:06 <shshang> absubram, thanks a bunch for taking care of horizon piece.
14:35:37 <shshang> any risk the BP may not get in on time?
14:35:43 <sc68cal> absubram: Agreed- but you can still start the work. I don't remember off the top of my head if undefined attributes are silently discarded or an error is raised
14:36:00 <absubram> sc68cal: I was also wondering.. if I did have some code ready for testing.. would one of you be able to test it just to ensure no functionality is missing? I can do some basic testing using the review diffs
14:36:25 <shshang> absubram, I would love to help
14:36:27 <sc68cal> absubram: yes, just pull down my review into your neutron repo for devstack
14:36:53 <absubram> shshang: thanks! will keep you guys updated
14:37:14 <shshang> absubram, please send email to the ML when your code is ready, and we can all test it
14:37:15 <aveiga> baoli: does that make sense to you?
14:37:18 <xuhanp> aveiga, I wonder if today's neutron code allow create subnet without any IP specified?
14:37:20 <shshang> I know I will.
14:37:21 <aveiga> I don't want to go spouting off
14:37:36 <aveiga> xuhanp: good question, I haven't validated
14:37:37 <absubram> shshang: will do
14:37:46 <shshang> xuhanp, I think CIDR part is mandatory
14:37:47 <sc68cal> xuhanp: I don't think so
14:37:47 <xuhanp> I can do a quick check tomorrow.
14:37:56 <sc68cal> +1 - I think CIDR is mandatory
14:38:10 <sc68cal> and I think ip version
14:38:36 <aveiga> so we should follow along with parity there, since anything developed against neutron subnets will rely on it being there by assumption
14:38:51 <baoli> aveiga, I need to think about it.
14:39:00 <aveiga> do you have a use case in mind?
14:39:26 <xuhanp> so what can we input for the CIDR if we want SLAAC IP address work with outside RA
14:39:43 <baoli> Aveiga, I'm just thinking about the external router and service VM, etc.
14:39:54 <sc68cal> xuhanp: The correct CIDR
14:40:02 <aveiga> sc68cal: +1
14:40:04 <sc68cal> we have that patch that will calculate EUI64 addresses
14:40:11 <aveiga> baoli: it would be fine
14:40:12 <sc68cal> so neutron will agree with the network
14:40:18 <aveiga> you should just provide the addressing
14:40:50 <aveiga> meaning neutron should match what you'll be configuring with the external router
14:41:38 <xuhanp> still a little confuse. so neutron calculate EUI64 address, but that's after the subnet create is called, right?
14:41:53 <sc68cal> xuhanp: yes
14:42:05 <sc68cal> it's when a port is created from the subnet that the EUI64 address is calculated
14:42:05 <baoli> Aveiga, think about ipv6 prefix delegation. Would it be known beforehand the prefix for a subnet?
14:42:11 <sc68cal> for that port
14:42:47 <aveiga> baoli: nope, but your device could create the subnet in neutron from the delegated prefix
14:42:58 <aveiga> after all, until it's delegated, you have no network?
14:43:09 <xuhanp> yes. so from the user perspective, they need to input the right prefix align with RA from external?
14:43:57 <xuhanp> or the address in DB and in VM will mismatch, right?
14:44:07 <shshang> xuhanp, yes
14:44:09 <aveiga> xuhanp: it's worse than that
14:44:33 <aveiga> if someone sets up rules further on that validate RAs to be for the local network, it will fail
14:46:00 <shshang> also the iptable rule will block the traffic too
14:46:26 <aveiga> shshang: I think the iptables rules are port specific, except forr the RA source rules which are based on single addresses
14:47:04 <shshang> that is correct. If the CIDR you configure is different from the real one, the iptable rule won't allow traffic in or out
14:47:24 <baoli> ok, so it's about the iptable rules that have to be set based on the CIDR
14:47:39 <aveiga> baoli: it's more than just the iptables rules
14:47:47 <aveiga> it's what neutron has to provide to other sources
14:48:12 <aveiga> I think the answer to the PD question for now, is to crete the subnet after delegation occurs
14:48:22 <aveiga> until we can get some work done to properly handle PD
14:49:17 <sc68cal> +1 - eventually we'll add support for PD so openstack does it all by itself
14:49:25 <sc68cal> it may need to be an API extension however
14:49:48 <sc68cal> unless I can convince them to crowbar just one more itsy bitsy change into the API ;)
14:49:52 <aveiga> PD support is a lot of work
14:50:02 <aveiga> since it makes the neutron network a client at that point
14:50:42 <sc68cal> true - but Neutron was happy to be told a CIDR and when you switch off enable_dhcp it behaves nicely
14:50:53 <sc68cal> then with the EUI64 it'd match up
14:51:03 <baoli> Aveiga, I will take a close look at it from neutron side.
14:51:19 <aveiga> baoli: bring it up on the ML when you find something
14:51:28 <baoli> aveiga, sure thing
14:51:29 <aveiga> I'd like to make sure we cover everyone's needs
14:51:51 <aveiga> sc68cal: sort of, but neutron would have to actually run a dhcpv6 client
14:51:56 <aveiga> for pd to work
14:52:18 <sc68cal> aveiga: That's fine, that could be an async operation
14:52:38 <aveiga> I think that's a chat for after we've got more basic support in and workign
14:52:54 <sc68cal> just create a new subnet and specify PD
14:53:04 <sc68cal> we'd need to relax the cidr requirement, but that's OK
14:53:17 <sc68cal> if we made it an API extension, we'd actually not need to muck with that
14:53:36 <sc68cal> just do a request to the API extension, and it'd go create a new subnet with the PD
14:53:46 <aveiga> I'd go the other way, because the router would have to request the prefix
14:53:54 <aveiga> so it would just create the subnet on the fly
14:54:00 <aveiga> but again, that's a discussion for later
14:54:10 <sc68cal> right - obviously some RPC work to make it all communicate correctly
14:54:18 <aveiga> in any case, not yet relevant
14:55:12 <shshang> I have a quick question about code submission
14:55:28 <shshang> can anybody help me how to write testing code?
14:55:52 <shshang> I saw test.py in other code review, but not sure what it is for and how to build it.
14:57:07 <xuhanp> since we only have several minutes, I also want to mention that I submitted code for RA security group. Will be great if you can take a look.
14:57:08 <xuhanp> https://review.openstack.org/#/c/72252/
14:57:17 <xuhanp> thanks sc68cal for your review
14:57:24 <sc68cal> No problem, you did a great job
14:57:27 <xuhanp> shshang, sorry for the interrupt
14:57:35 <shshang> np
14:57:38 <sc68cal> hopefully my code was at least helpful
14:58:12 <sc68cal> shshang: If you look in the neutron/tests/unit directory there are unit tests for the DHCP server there
14:58:13 <xuhanp> it was very helpful, sc68cal
14:58:26 <xuhanp> and aveiga's talk with me was too
14:58:41 <sc68cal> shshang: Take a look at the console log from jenkins, find the unit tests that failed, and fix them up. Are you familiar with Mock?
14:58:52 <aveiga> glad to help
14:58:53 <shshang> no, not at all
14:59:36 <shshang> let me take a look at the tests/unit directory and I will send my questions to you, sc68cal?
14:59:54 <sc68cal> yeah let's talk via e-mail and set up a pair programming time
15:00:06 <shshang> sure, that will do. Thanks, sc68cal!
15:00:16 <sc68cal> if anyone else wants to join in, let me know - trying to do some dev doc for Neutron
15:00:37 <sc68cal> neutron is kind of a beast to learn
15:00:42 <dane_> I might be able to help... this is for adding unit test cases?
15:00:50 <shshang> yes
15:01:06 <sc68cal> Alright - well until next time! Thanks everyone
15:01:11 <sc68cal> #endmeeting