18:03:18 #startmeeting networking_policy 18:03:19 Meeting started Thu Jul 30 18:03:18 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:03:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:03:22 The meeting name has been set to 'networking_policy' 18:03:38 #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#July_30th.2C_23rd_2015 18:04:00 #topic Bugs 18:04:00 Hi 18:04:11 hi 18:04:35 hi rkukura Yi 18:04:40 few new ones that need immediate attention 18:04:44 #link https://bugs.launchpad.net/group-based-policy/+bug/1479169 18:04:46 Launchpad bug 1479169 in Group Based Policy "GBP default security group allows outbound access to the Internet" [Undecided,In progress] - Assigned to Ivar Lazzaro (mmaleckk) 18:05:13 #link https://review.openstack.org/207250 18:05:20 ivar-lazzaro: has posted the patch ^^^ 18:05:25 ivar-lazzaro: there? 18:06:15 hi 18:06:43 hi ransari 18:06:45 so the issue we were seeing is that we were opening up th SG rules for all egress traffic by default 18:07:03 this meant that you didnt have to consume and external policy to get connectivity to the external world 18:07:15 ivar-lazzaro: is trying to address that in his patch 18:07:18 ransari: ho 18:07:20 hi 18:07:38 i was hoping to discuss the solution he has proposed in the patch 18:07:47 there was another bug which posted today: 18:07:58 #link https://bugs.launchpad.net/group-based-policy/+bug/1479706 18:07:59 Launchpad bug 1479706 in Group Based Policy "GBP Service chaining errors are are not vsible to the user because of not having status attribute" [Undecided,New] 18:08:06 i dont see magesh around 18:08:13 but i believe ransari is here 18:08:39 some of us discussed the adding the status field earlier for the resources 18:09:33 the bug seems to suggest that you want to present an async interface to the user with this status field 18:09:56 ransari: does the service chain API become difficult to use without this addition? 18:10:24 yes to some extent 18:10:42 I think it has an impact in terms of usability 18:11:25 ransari: is it the case that with service chain API the backend operation is almost always going to be a long running operation? 18:12:16 yes 18:12:22 ransari: okay 18:12:23 SumitNaiksatam: even more when real VMs be used as nodes 18:12:30 igordcard: true 18:12:58 however I believe rkukura has concerns with the usability of completely async API too 18:13:36 cna we review what those concerns are. 18:14:20 my concern is just to keep simple things simple 18:14:54 ransari: mainly that forcing the user to poll or check the status for a resource’s availability makes the system more difficult to use 18:15:32 many client apps don’t need/want concurrency - they can’t do the next step until the prior one completes, so a sync API serves them well 18:16:28 so currently is teh expectation that the service node driver is expected to poll for status and fail an operation if tehre are errors- for ex in launching a VM? 18:17:50 I’m not arguing we need 100% guarantee that everything in the data plane is synchronized before calls return, just that the needed results can be returned 18:18:45 rkukura: but currently there is no way for the user to know with what is returned that the service chain instantiation has actually failed 18:20:19 i think this is probably a longer discussion 18:20:38 Even if the VM gets created, it could fail later, so status attributes seem necessary 18:20:56 rkukura: right 18:21:11 And we should always try to detect user errors before returning 18:21:33 rkukura: ransari: can we set some time aside to have this discussion offline on #openstack-gbp? 18:21:40 sure 18:21:40 I’m not so sure about resource exhaustion errors 18:22:14 okay i will try to coordinate with magesh (who posted the bug), will let others know 18:22:56 there is another user request: #link https://bugs.launchpad.net/group-based-policy/+bug/1479460 18:22:57 Launchpad bug 1479460 in Group Based Policy "GBP create group API does not allow specification of DNS nameservers" [High,In progress] - Assigned to Magesh GV (magesh-gv) 18:23:24 and the patch has been posted: #link https://review.openstack.org/207383 18:23:53 rkukura: please eye ball the above when you have time 18:23:58 sure 18:24:34 rkukura: we took the conf approach to solve this as a shorter term solution 18:24:52 since the user is fine having a global setting 18:25:07 ok 18:25:23 we can later evolve this to allow tenant or group-specific granularity 18:25:31 any other bugs that we need to discuss? 18:26:07 #topic Testing 18:26:26 update on the rally testing - i have added a new job for the rally tests 18:27:17 so for example if you see: #link https://review.openstack.org/#/c/207250/ 18:27:42 you will see a new non-voting job: gate-group-based-policy-dsvm-rally 18:28:08 i need to fix a small issue in the post-hook script 18:28:19 after you should hopefully see it running properly 18:28:32 with this new job, we can start planning to move the tests in-tree 18:28:53 #topic Packaging 18:29:06 rkukura: anything to discuss update at your end? 18:29:19 nothing new yet 18:30:08 rkukura: okay 18:31:09 #topic Client stable branch 18:31:32 rkukura: we have this one pending - Service Profile backport 18:32:03 Forgot about that - I can do it. 18:32:34 rkukura: thanks 18:32:56 #topic New features 18:33:22 please review #link: https://review.openstack.org/#/c/203226/ 18:33:38 “Plumbing Terminology” ^^^ 18:33:47 i know a few people aloready have 18:34:13 igordcard: have your comments been adequately addressed? 18:34:49 SumitNaiksatam: yes 18:35:04 igordcard: great 18:35:20 igordcard: anything you want to discuss regarding: https://review.openstack.org/#/c/168733/ (Traffic Steering NCP Plumber) 18:35:25 SumitNaiksatam: for now I am putting the transparent plumbing type inside the traffic steering plumber, and then we'll see how it merges into the TScP 18:35:38 igordcard: okay 18:36:00 SumitNaiksatam: yes, I have made a simple node driver called manual node driver, which is like a nova driver but is manually fed with an existing neutron port already attached to a VM 18:36:12 igordcard: okay 18:36:19 igordcard: are you planning to post a new spec document for the traffic steering plumber? 18:36:24 I will use that to interact with the traffic steering plumber I have just started so that I can exercise traffic steering in practice 18:36:41 igordcard: can be very minimal but will help people to understand what approach you have taken 18:36:43 I will have some code up until the next meeting 18:36:51 igordcard: sounds good 18:36:56 SumitNaiksatam: yes, I can do that 18:37:00 igordcard: thanks 18:37:15 igordcard: dont have to spend too much time, just high level to begin with 18:37:30 and I'm already following the general idea around ivar's plumbing spec 18:37:38 SumitNaiksatam: okay 18:37:41 igordcard: okay cool! 18:38:02 rkukura: anything you want to discuss on the nova driver? 18:38:57 finally got to where VMs get launched connected to the PTGs from the plumber 18:39:09 rkukura: sweet!! 18:39:14 So mainly just cleanup work needed now be able to review 18:39:29 rkukura: okay 18:39:29 rkukura: nice! 18:39:49 This does depend on ivar-lazzaro’s patch https://review.openstack.org/#/c/166424/ so that the neutron ports are owned by the same tenant as the nova VMs. 18:40:36 rkukura: okay 18:41:08 #topic Open Discussion 18:41:23 anything more to discuss? 18:41:27 Its also a bit inconvenient to have to configure this tenant by UUID rather than name, so I’m wondering if ivar’s patch should convert tenant names to UUIDs. 18:42:15 rkukura: okay, so get the implementation would get the tenant ID from keystone? 18:42:33 I think it would need to 18:42:59 otherwise, with devstack you need to edit neutron.conf manually and restart the server once you get the UUID from keystone 18:43:05 rkukura: is the tenant name udatable in keystone? 18:43:18 rkukura: that makes sense 18:43:44 I know ivar-lazzaro has concerns about name duplication and change, but I’d think we could support specifying name or UUID 18:43:49 rkukura: i meant to ask if the tenant name can be updated in keystone 18:44:29 If keystone reported a duplicate name, we could log and error and terminate 18:44:36 rkukura: okay 18:46:16 Of course, we don’t want a denial of service attack where any user can create a new tenant in keystone stealing the admin or service name, so I’d hope keystone didn’t allow duplicates. Authenticating by name+password to keystone would also seem broken if duplicate names are allowed. 18:46:50 rkukura: okay, i was wondering if the name is changed for the same tenant 18:47:04 and if a different tenant is given that name 18:47:48 that could be a problem, but admins should know not to change the name of the ‘admin’ or ‘service’ users, or a new user specifically used for this. 18:48:04 rkukura: :-) 18:48:43 rkukura: from a usability perspective, there is no arguing that have the name is better 18:48:56 rkukura: especially the devstack workflow that you point out 18:49:09 I don’t see any real risk, especially of either name or UUID is accepted. 18:49:54 rkukura: okay 18:50:09 anything else anyone wants to discuss today? 18:50:35 else we get 10 mins back 18:50:42 thanks everyone for your time today 18:50:58 bye 18:51:29 #endmeeting