16:01:21 #startmeeting ironic_neutron 16:01:24 Meeting started Mon Jan 4 16:01:21 2016 UTC and is due to finish in 60 minutes. The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:27 The meeting name has been set to 'ironic_neutron' 16:01:43 Good morning folks - 16:01:56 who is here to attend the ironic-neutron meeting? 16:02:02 jroll : are you here? 16:02:08 \o 16:02:21 lazy_prince, vsaienko ? 16:02:31 hello to all 16:02:54 #topic: Agenda 16:03:01 #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Meeting_January_4.2C_2016 16:03:21 #topic: Announcements 16:03:35 Happy New Year to everybody 16:03:53 hope everybody had a relaxing holidays!! 16:04:12 o/ happy new year! 16:04:43 I was trying to catch up on the action I missed in last two weeks - 16:05:17 0/ 16:05:33 lazy_prince : hi 16:05:47 #topic: Patches under review 16:05:50 lazy_prince: hi 16:05:53 #link: https://etherpad.openstack.org/p/ironic-neutron-mid-cycle 16:06:15 * jroll wonders if devananda is around 16:06:49 I noticed there were bunch of updates to the patches - which is excellent 16:07:26 yup.. Thanks to vsaienko 16:07:35 and lots of review comments as well 16:07:51 yes noticed that vsaienko has been busy :-) 16:08:00 vsaienko : are we ready to ship :-) 16:08:10 yep 16:08:27 vsaienko : perhaps you can give us an update and bring everybody to speed 16:08:57 that would be helpful assuming I missed couple of meetings.. 16:09:13 I've rebased patches and resolved comments 16:09:42 is there anything left for me to work on.. :) 16:09:58 I test all of them together, guide is on review also https://review.openstack.org/#/c/258596/7/doc/source/dev/ironic-neutron-integration.rst 16:10:33 deva also mentioned he was able to test, mostly successfully 16:10:38 I would be perfect if any body else also test them and provide feedback 16:10:57 he found it wasn't isolating between two tenants, but it looks like the devstack stuff isn't intended to do so? 16:11:38 jroll: it should 16:12:06 if tags are applied properly, they should be isolated.. 16:12:07 vsaienko: maybe it was because the default is a provider network 16:12:17 from Newtron side each network in the tenant has unique VLAN 16:12:19 I'd have to look back at irc logs 16:12:21 jroll : based upon the devstack patches, it should have 16:12:53 ah, yes, I've missed part that configured network_provider in Ironic 16:13:15 but already fixed it in last patchset, thanks vdrok! 16:13:40 hrm, he said it isolated control plane okay 16:13:55 anyway, not much use dwelling on that now 16:14:31 vsaienko : the list of patches on https://etherpad.openstack.org/p/ironic-neutron-mid-cycle is up-to-date, right? 16:15:16 sukhdev: looks like yes 16:15:32 vsaienko : before I went on PTO, there was an issue with the devstack patches, which needed to be pushed again - wonder if those are listed correctly 16:15:48 I have not had time to verify recently 16:16:01 o/ 16:16:05 they look right, Sukhdev 16:16:06 hello devananda 16:16:10 hai devananda :) 16:16:26 Sukhdev, jroll: I tested the devstack support for that patch chain last week and confirmed it works 16:16:37 nodes are moved between the provisioning provider network and the tenant network, etc, as expected 16:16:43 \o/ 16:16:44 devananda : Wow!! cool - thanks 16:16:51 however I had difficulty creating >1 tenant network and separating traffic from tenant A and tenant B 16:17:01 I suspect I was doing something wrong with regards to creating the neutron networks 16:17:43 devananda : oh I see - 16:17:46 I started reviewing the patch chain over the weekend, but haven't gotten too far. at this point, it will be mostly nitpicks -- little things in the db code that I would like to see improved, etc 16:18:31 devananda : I wonder how you were creating neutron networks? 16:19:01 as tenant A: neutron net-create; neutron subnet-create; nova boot ... --nic net=aaaa; 16:19:24 so neutron assigned an IP from that range to the instance, but there wasn't actually an OVS network on the host that matched / routed to it 16:19:25 devananda : as an admin, when you create a network, you can specify which tenant it is for, etc.. 16:19:47 Sukhdev: does the admin need to create a network for each tenant (eg, when creating the tenant) ? 16:20:28 devananda: but there wasn't actually an OVS network on the host that matched / routed to it what do you mean/ 16:20:40 vsaienko: yes 16:21:59 devananda : I believe so.. 16:22:19 first off, I created two tenants, did not define any networks for them, and just booted two servers. Neutron assigned a private IP to each one -- on the same subnet 16:22:24 and I was able to route traffic between them 16:22:44 so while provisioning network was not visible to tenants, they were visible to each other 16:23:21 then, as each tenant (not the admin), I issued "neutron net-create ...; neutron subnet-create ...;" commands with non-overlapping IP ranges 16:23:39 and booted a server on that network 16:24:02 neutron assigned an IP from the new subnet range, but it was inaccessible. 16:24:22 devananda: did you checked that VLAN ID has been changed in OVS with ovs-vsctl show? 16:24:38 vsaienko: I did not see any new networks on the host 16:25:36 devananda : your sequence of steps seems right 16:26:30 devananda: that is trange, since once you create new neutron network, neutron should create new IP namespace for it 16:26:34 only difference is that I would create a networks from admin context and specify the tenant for these networks and then create subnets from the tenant's context 16:26:37 *strange 16:27:00 but, your sequence should work as well 16:27:32 Sukhdev: if this were hardware switches instead of OVS, in a real deployment, would the non-admin tenant be able to create a neutron network? 16:27:57 devananda : yes 16:27:59 devananda: it should 16:28:04 hmm ... 16:28:21 neutron should call create_network() from ML2 driver and it will do all the rest 16:28:47 I mean ML2 should create missing VLANs on the switches 16:28:53 devananda : I think you are doing everything correct 16:29:17 I see 16:29:35 that's good - but then I don't know why it didn't work locally 16:29:35 devananda : we need to triage a bit to dig deep - as vsaienko pointed, we need to check if correct vlan ID are being used 16:30:05 I don't know if I'll have time to rebuild that env today, but I'll try to help as much as I can 16:30:29 devananda : are you using HW switches or OVS ? 16:30:32 OVS 16:30:39 I don't have that kind of fancy hardware at home ;) 16:31:21 devananda : in that case, I think OVS plumbing may be missing something - 16:31:27 ovs-vsctl show output will be helpful 16:31:47 devananda: if you still have environment, I'm ready to debug issues with you 16:32:20 vsaienko: I do not 16:33:07 I will set up the test setup this week and play with it as well - and will ping you guys with the feedback 16:33:38 vsaienko : did you test the same way as devananda is trying to do? 16:33:45 yes 16:33:50 hmmm... 16:34:24 OK - lets try to reproduce it then....I will get on it this week as well 16:34:47 Sukhdev: what I want to get as output of this test is confirmation of isolation between tenants 16:34:50 I will triple check all 16:35:29 devananda : understood - and, actually, that leads me to the next topic on agenda 16:35:56 Is Yuri here? 16:36:15 sukhdev: he is on PTO this week 16:36:21 he was writing a tempest scenario test to test exactly the same thing 16:36:31 \o/ 16:36:41 https://review.openstack.org/#/c/258934/ 16:36:47 devananda : see here - https://bugs.launchpad.net/tempest/+bug/1520230 16:36:48 Launchpad bug 1520230 in tempest "Test Case: Create a test scenario to verify that Ironic supports multitenancy" [Undecided,In progress] - Assigned to Yuriy Yekovenko (yyekovenko) 16:37:49 vsaienko : do you know if he was able to test this patch? 16:38:16 jroll: aren't we moving tempest scenario tests into ironic's tree soon? 16:38:21 #link: https://review.openstack.org/#/c/258934/ 16:38:34 as far I know he is still working on that patch 16:38:43 devananda: that's a goal, yes 16:39:38 yea, found it 16:39:47 vsaienko: he may want to rebase on top of https://review.openstack.org/#/c/253982/ or something 16:40:27 devananda, I will ping him about it 16:41:07 devananda: I'm curious what other work is needed there, but probably a good idea 16:41:11 Looks like this test will be very helpful in testing this scenario 16:41:21 jroll: I think we were bike shedding on the folder name 16:41:38 devananda: oh good 16:41:49 devananda: I meant in project-config and such though :) 16:41:50 yep. https://review.openstack.org/#/c/246161/7 16:42:00 jroll: oh. that I'm not sure about 16:42:10 devananda: yeah, it's fine though 16:43:35 i'm not saying we shouldn't land the multitenancy testing in tempest - just making sure folks are aware of the move to tempest-lib 16:45:50 I am hoping Yuriy is aware of this tempest-lib stuff 16:46:24 it has been a long time since I touched tempest stuff - I am not up-to-date in that regard :-):-0 16:46:58 For now, as long as we can test multi-tenancy manually, we should be good 16:47:21 Anything else to discuss on this topic? 16:47:55 #topic: Integration Status 16:48:27 We have mostly covered the integration status already, but, I wanted to specifically talk about item 7 on https://etherpad.openstack.org/p/ironic-neutron-mid-cycle 16:49:00 This is based upon two week old information - perhaps this has been addressed while I was gone 16:49:05 any update on this? 16:49:29 that patch still needs a major update 16:49:36 it's on my todo list, apologies for not getting to it 16:50:47 jroll: this will impact the portgroups, which no body is testing as of now 16:50:49 i am sorry.. which item 7.. under issues o rpatches..? 16:50:57 lazy_prince : yes 16:51:08 Sukhdev: yes I know 16:51:09 lazy_prince : issues 16:51:15 aha.. okay.. 16:51:51 folks, at the moment we don't test portgroups at all, OVS allows to create portchannels with LACP I think we should try to cover portgroups with OVS also 16:51:59 OK - I was just making sure that I am up-to-date on this status 16:52:34 vsaienko: ironic code is not upto date with portgroups yet.. we will have to wait for that... 16:53:47 The question for the team is - should we consider merging the patches for M2 (mid Jan)? 16:54:05 and do the portgroups after that for M3? 16:54:18 where are we with nova patches...? 16:54:20 we should merge all the things as soon as they're ready :P 16:54:38 lazy_prince: 2 patches, one has a +2, the other is the portgroups thing that needs a major update 16:54:42 before we merge, we need to be ready from nova side too.. 16:55:00 cool.. 16:55:29 update on etherpad is two weeks old - but, one of the patches was merged back then 16:55:43 I'm asking to review devstack related patches so we have consensus on global variables names and can proceed with https://review.openstack.org/#/c/252814/ 16:56:20 vsaienko: will do 16:56:30 jroll: thanks~ 16:56:52 * Sukhdev time check - 4 min left 16:57:21 lazy_prince : have you had a chance to test the devstack patches? 16:57:47 Sukhdev: I only saw one devstack patch when I was testing last week? 16:58:19 hmm... was busy all this time but free from now on.. I will test and update... 16:58:21 devananda : I try to keep the list of all patches on - https://etherpad.openstack.org/p/ironic-neutron-mid-cycle 16:58:59 hence, I was asking earlier in the meeting to make sure the team updates this etherpad - 16:59:08 this keeps things simple to track 16:59:16 ah, thx 16:59:17 devananda: there's a bunch in the chain 17:00:10 Lets all try to review devstack patches this week 17:00:21 We are out of time - folks 17:00:29 thanks for attending - this was great discusion 17:00:30 o/ 17:00:34 bye 17:00:39 #endmeeting