14:02:03 <sc68cal> #startmeeting neutron_ipv6
14:02:03 <openstack> Meeting started Tue Mar 25 14:02:03 2014 UTC and is due to finish in 60 minutes.  The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:06 <openstack> The meeting name has been set to 'neutron_ipv6'
14:02:20 <xuhanp> hello, sc68cal
14:02:26 <sc68cal> Hello everyone
14:02:28 <aveiga> hello
14:02:31 <baoli> Hi
14:03:33 <sc68cal> So - we are currently nearing RC1
14:03:50 <sc68cal> so current
14:04:07 <sc68cal> so currently most of the things getting merged are for existing bugs
14:05:10 <xuhanp> sc68cal, I think we need some core member's attention on those bugs :-)
14:05:53 <sc68cal> xuhanp: agreed - I was hoping we could get your patch merged
14:06:11 <sc68cal> #link https://review.openstack.org/#/c/72252/2 Permit RAs from known routers
14:06:45 <xuhanp> sc68cal, I kind of worried comments will come late and then we won't have time to address them all.
14:07:49 <xuhanp> so should we send a email to ML to get them reviewed or just ping some core members on IRC?
14:08:25 <sc68cal> probably ping on IRC
14:08:46 <xuhanp> sc68cal, Ok. sound good
14:08:58 <sc68cal> I didn't get a chance to talk IPv6 at yesterday's main meeting, to bring it up
14:10:01 <sc68cal> In the meantime, if everyone could take a look at the review, that would be helpful
14:10:35 <sc68cal> xuhanp: I saw you got bit by a gate bug, we should probably do a recheck
14:11:16 <xuhanp> sc68cal, yep. I am not sure why comment can try a new Jenkins job.
14:11:27 <xuhanp> s/try/trigger
14:11:51 <sc68cal> xuhanp: the Elastic Recheck comment has the format for triggering
14:12:20 <sc68cal> "recheck bug 1288918"
14:12:22 <uvirtbot> Launchpad bug 1288918 in tempest "tempest.api.object_storage.test_account_quotas_negative.AccountQuotasNegativeTest:test_upload_large_object" [Low,Confirmed] https://launchpad.net/bugs/1288918
14:12:49 <xuhanp> yep. but there is no recheck between the two Jenkins especially when previous one was successful
14:13:24 <xuhanp> anyway, I rechecked that bug again after the failure.
14:14:20 <sc68cal> ok - just post a comment in your review to have it re-run jenkins
14:14:46 <sc68cal> that -1 due to a gate bug is probably what is keeping core reviewers from looking at the patch
14:14:54 <xuhanp> sc68cal, thanks
14:15:48 <sc68cal> Do we have any other reviews that are going to try and make RC1?
14:16:28 <xuhanp> sc68cal, I hope the fix which trigger provider rule when router update can be reviewed as well.
14:16:48 <xuhanp> #link https://review.openstack.org/#/c/80932/
14:18:31 <sc68cal> perfect, I've added myself to that review
14:20:47 <sc68cal> xuhanp: for that review, a couple of the unit tests, for the plugins appear to have a lot in common
14:20:54 <sc68cal> could they be folded into test_sg.SecurityGroupDBTestCase ?
14:21:15 <sc68cal> or do they all have subtle differences?
14:21:56 <xuhanp> the changed code is trigger from the different plugin
14:22:43 <xuhanp> trying to open the link
14:23:10 <sc68cal> ok - we can take it off line, I'll poke at it a bit
14:23:19 <xuhanp> sc68cal, sure
14:24:08 <sc68cal> Do we have any new bugs or blueprints to discuss?
14:25:32 <sc68cal> ok - i'll turn it over to open discussion if there are none
14:26:06 <sc68cal> #topic open discussion
14:26:19 <xuhanp> I have a question about Shi Xiong's code change
14:26:55 <xuhanp> actually two questions.
14:27:06 <xuhanp> 1. is dnsmasq for each subnet needed?
14:27:21 <xuhanp> ipv6 uses dnsmasq for each network I think
14:28:41 <sc68cal> I think I saw a reviewer comment bringing up that point recently
14:29:01 <sc68cal> it doesn't look like shshang is here today
14:29:26 <xuhanp> yep. we can discuss offline too.
14:30:25 <sc68cal> It may be worth discussing if it is able to be split into pieces
14:30:59 <sc68cal> 40 reviwer comments on the most recent patch, in just one file. A bit overwhelming
14:31:54 <xuhanp> sc68cal, yep. we may need to reply the comments before submit a new patch. otherwise people will feel like their comments are not addressed
14:31:57 <baoli> xuhanp, I did a little research on that. A broadcast to one qr-xxx port will be heard by all the VMs that are on different subnets from the same network, with the ovs plugin.
14:32:48 <xuhanp> baoli, will that be a problem for current dhcp port?
14:33:21 <baoli> so this relates to your question about one dnsmasq per qr-xxx port (or per subnet)
14:33:56 <xuhanp> baoli, yep. Got you about that. what about current IPv4 case?
14:34:06 <sc68cal> We may need to determine if it is possible to have multiple subnets on the same network
14:34:22 <baoli> This also raises a question about multiple ipv6 subnets per network, what are the relationships between the subnets
14:34:49 <aveiga> technically, it should be possible to have multiple v6 subnets
14:34:55 <baoli> with ipv4, dnsmasq is running in the dhcp namespace, and no slaac!
14:35:40 <aveiga> you should be able to receive multiple RAs and assign an addr per advertised scope
14:36:24 <xuhanp> aveiga, you mean multiple addr on one interface, right?
14:36:53 <aveiga> yes
14:37:10 <aveiga> the problem would be showing neutron that you have multiple
14:37:17 <aveiga> can the port show the extras?
14:37:24 <sc68cal> aveiga: yes
14:37:29 <aveiga> then you should be fine
14:37:37 <sc68cal> It already does for v4 + single v6 address
14:37:43 <aveiga> right
14:37:56 <aveiga> sounds like it's just a matter of testing..
14:37:56 <sc68cal> but we may need to tweak a bit for slaac calculations
14:38:05 <sc68cal> make sue it calculates a EUI per subnet
14:38:08 <sc68cal> *sure
14:38:11 <aveiga> yup
14:38:59 <xuhanp> also I guess we need to change the current logic when VM is assigned with subnet's IP.
14:39:09 <xuhanp> I think neutron select one subnet as VM's IP
14:39:15 <xuhanp> different from nova-network
14:39:29 <xuhanp> when --nic net-id= is not specified
14:39:39 <xuhanp> to nova boot
14:40:04 <xuhanp> again, this need testing
14:40:34 <sc68cal> HenryG put together some tests in tempest for testing IPv6 subnets
14:40:56 <sc68cal> so - we may be able to put some tests into tempest for two v6 subnets on the same network
14:41:16 <sc68cal> see what the current behavior is - and then push code to fix if needed
14:41:34 <xuhanp> sc68cal, sounds great
14:42:04 <baoli> a VM receives one ip from each address family
14:47:47 <sc68cal> Ok - if we don't have anything else to discuss - I can give everyone back 15 minutes
14:49:22 <sc68cal> alright everyone - see you next week. I'm always on #openstack-neutron during US EST
14:49:52 <sc68cal> #endmeeting