18:00:33 #startmeeting networking_policy 18:00:34 Meeting started Thu Feb 19 18:00:33 2015 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:38 The meeting name has been set to 'networking_policy' 18:00:40 hello 18:00:59 #info agenda https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#Feb_19th.2C_12th.2C_2015 18:01:25 #info kilo-1 was released on Feb 16th 18:01:59 #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/057115.html 18:02:33 our next milestone is March 16th 18:02:41 anything else anyone would like to share? 18:03:22 SumitNaiksatam: Is there a plan to release stable-juno? 18:03:31 SumitNaiksatam: Hi 18:04:20 rkukura: i think we have a bunch of juno-backport potentials which have to be either backported or are waiting to be fixed 18:04:34 my hope was to get as many of those in before doing the next stable/juno 18:04:46 SumitNaiksatam: Right. Was wondering if there is a target date. 18:04:59 however if you think it makes sense to do the stable/juno now, i dont have any objections 18:05:29 Lets see after we discuss bugs whether there are backportable fixes coming soon. 18:05:31 rkukura: i personally dont have a date in mind, though i was kind of considering this as an asap activity 18:06:06 rkukura: good point to bring up, perhaps fixing a date will speed up the backport acitivity 18:06:17 #topic Bugs 18:06:43 we touched on a number of bugs in the last couple of meetings 18:07:00 anyone wants to report any updates on those 18:07:11 a few fixes were merged 18:07:32 but there is still a bunch that we need to close on 18:07:40 I’ve added followup questions on a couple that were assigned to me, but haven’t seen responses yet. 18:07:49 rkukura: which ones? 18:08:14 https://bugs.launchpad.net/group-based-policy/+bug/1417206/comments/1 18:08:16 Launchpad bug 1417206 in Group Based Policy "GBP: PTG delete at times not cleaning neutron resources" [Undecided,New] - Assigned to Robert Kukura (rkukura) 18:08:39 https://bugs.launchpad.net/group-based-policy/+bug/1416527/comments/4 18:08:40 Launchpad bug 1416527 in Group Based Policy "GBP: PTG delete errors out" [Undecided,New] 18:09:13 rkukura: okay let me follow up on those two 18:09:21 SumitNaiksatam: thanks 18:09:47 hopefully i can get jishnu to join the meetings in the future, so that he can participate directly rather me being a proxy 18:09:53 I should be able to knock off https://bugs.launchpad.net/group-based-policy/+bug/1417724 soon. 18:09:54 Launchpad bug 1417724 in Group Based Policy "GBP: Changing L3P of a in-use L2P, does not reflect in change in subnet of PTG" [High,Confirmed] - Assigned to Robert Kukura (rkukura) 18:10:04 rkukura: nice! 18:10:31 #action SumitNaiksatam to follow up with jishnub on 1416527 and 1417206 18:11:09 KrishnaK updated offline that he is working on the bug in his plate, and he should be done soon 18:12:21 we dont have enough time in this meeting to a complete bug scrub, but if our bug count grows or we are not able to clean up the current ones, we will need to schedule one separately 18:12:45 my request to everyone is to look at the bugs assigned to them and target them for the appropriage milestone 18:13:03 right now i have targeted mostly everything for K-2 18:13:21 which may be actually be the case, but if its not please target appropriately 18:14:05 i think we have a “future” milestone as well for anything that cannot be immediately fixed in kilo 18:14:13 or is not considered immediately relevant 18:14:20 any other blockers on the bugs 18:14:29 i dont see any new criticals so thats good 18:15:08 btw, i noticed some issues in the CLI as well especially when pointing to “neutron” resources 18:15:12 I’d actually like to see more bugs being reported - evidence that the code is being used 18:16:01 rkukura: agree, but too many criticals would mean we are not doing a good job reviewing :-) 18:16:45 on the CLI issue, so if you try to creat a group, and point to a pre-created subnet, the CLI will fail 18:16:52 just in case if it anyone tries this 18:17:15 this is because we try to do a validation of the neutron resource in the CLI and the reference to the neutron client is not correct 18:17:32 i will check if there is a bug for this, else i will file one 18:17:47 anything else to discuss in bugs today? 18:17:53 anyone blocked on anything? 18:18:06 LouisF: hi 18:18:09 hi 18:18:14 ok moving on 18:18:31 #topic Re-factor Group Based Policy with Neutron RESTful APIs 18:18:42 #link https://review.openstack.org/#/c/153126 18:18:49 did folks get a chance to review this spec? 18:19:14 the Yi_ yapeng team is in full force there today 18:19:15 I read through it again, and will file a couple minor comments 18:19:21 rkukura: okay 18:19:33 I’ll try to do that by the end of today 18:19:39 rkukura: thanks! 18:19:43 i am really hoping that at least at a spec level we close on this by enf of today 18:19:48 *end 18:19:52 SumitNaiksatam: +1 18:19:57 ivar-lazzaro: okay 18:19:58 rkukura, thanks, I updated the spec based on previous comments. 18:20:05 everybody else think thats doable? 18:20:09 +1 18:20:21 +1 18:20:26 we can always give comments on the implementation, but i think the spec has been waiting for a long time 18:20:31 rkukura: LouisF: ok thanks 18:21:04 Yi_: yapeng: lets work on this today close the spec, based on any outstanding review comments 18:21:11 mageshgv: did you get a chance to read? 18:21:22 SumitNaiksatam: sure 18:21:25 *read/review 18:21:25 SumitNaiksatam: sounds great! 18:21:32 SumitNaiksatam: Yes, looks ok 18:21:46 ok good, so we have some loose consensus here 18:22:05 thanks yapeng and Yi_ for your patience on this! 18:22:28 oh, and Yi_ you posted a WIP patch: #link https://review.openstack.org/#/c/156856/ 18:22:37 thanks 18:23:05 as well as https://review.openstack.org/#/c/156776/ 18:23:15 ah sorry, i missed that 18:23:53 Yapeng and I also did some manual testing on this 18:24:00 Yi_: sweet 18:24:03 following the devstack example 18:24:17 for the base cases, we were able to do it 18:24:18 Yi_ yapeng: are there any blockers for you at this point (apart from the reviews) 18:24:29 anything that you would like to get resolved within the team? 18:24:41 SumitNaiksatam: so far so good 18:24:46 not right now. 18:24:46 i know you had questions on the external connectivity 18:24:55 ok 18:25:15 I’ve got a question on the client library 18:25:19 yes, if we can have clear instruction to test external connectivity, it would be great 18:25:20 rkukura: please 18:25:32 go ahead 18:26:06 Will this mean all our current unit tests for the mapping_driver (and maybe others) will depend on a running neutron server? 18:27:12 rkukura: I don't think the client code should introduce any new dependency, but I miss something? 18:27:19 rkukura: good question 18:27:30 rkukura: the usual approach would be to mock, right? 18:27:35 rkukura, depends, UT can mock some data 18:27:45 yapeng: yeah 18:28:00 Right now our “unit” tests depend pretty heavily on the direct calls into the neutron core plugin actually functioning. 18:28:28 We obviously need to break this dependency, and this BP may be when we need to do it. 18:28:29 rkukura: I see your concern 18:28:32 rkukura: correct, i think you are also referring to some of the functional tests which are masquerading as “unit” tests :-) 18:28:53 SumitNaiksatam: That’s why I quoted “unit” 18:29:02 those tests are very helpful though 18:29:34 I’m not really clear on how neutron defines “functional test”, but could our functional tests depend on a running neutron-server? 18:29:35 i would have hoped that we dont lose the validation provided those tests when do this mock (meaning we actually trigger functional tests separately) 18:30:09 rkukura: this again goes to the tempest lib usage per project, right? 18:30:12 SumitNaiksatam: Right, I’m thinking we’d move/copy the existing “unit” tests to be functional tests. 18:30:25 Not really sure if tempest comes into play for this. 18:30:30 rkukura: and run the neutron server for those? 18:31:05 right 18:31:11 are these tests belong to tempest instead of UT? 18:32:09 yapeng: I don’t think these specific tests really require tempest and a full deployment, but they could be done that way. 18:32:33 yapeng: i think the guidance is to move to a model of using a tempest lib, and putting the tests in each project 18:32:46 Right now, these tests call the GBP API and then use neutron APIs to verify the resources were mapped correctly. 18:32:51 though i am not completely clear on the specifics of that 18:33:14 We could do that with just the gbp-server and neutron-server, and not a full devstack/tempest setup. 18:33:23 SumitNaiksatam rkukura: shouldn't we have a seperated project/BP to tract such a movement? 18:33:33 Yi_: agreed 18:33:44 rkukura: any chance that you can investigate this? 18:34:00 Yi_: I agree for the new server, but I’m concern about this BP breaking the existing test strategy 18:34:27 I don’t think neutron will actually accept client HTTP connections when run in unit tests. 18:34:35 But I could be wrong 18:35:05 If it does work in the current UT setup, then there is no immediate issue 18:35:10 rkukura: so if i understand your suggestion, as part of this refactoring, and before we actually move to a different service, your suggestion is move these tests to a “funcationa” test directory 18:35:26 SumitNaiksatam: Maybe - if needed 18:35:27 rkukura: and not use the client lib 18:35:36 just keep the tests the way they are 18:35:47 i think i like that as an interim solution 18:35:47 But the rmd is going to be using the client lib 18:36:27 The question is whether mocking at the client lib level makes sense with the existing tests 18:36:47 Or if those tests should become function tests where neutron-server does access client connections 18:36:56 s/access/accept/ 18:37:28 rkukura: in the cases where you are using the direct neutron calls to validate the neutron resources, mocking would not make sense, right? 18:37:29 I’ll include this test impact in a comment on the BP 18:37:38 on the spec I mean 18:38:01 SumitNaiksatam: Right, I think the tests would have to change drastically 18:38:20 And I kind of agree these tests really should be functional rather than unit tests 18:38:33 So maybe we should do proper mock-based unit tests for RMD. 18:38:58 was disconnected. I will check the spec comments. 18:38:59 rkukura: Yi_ yapeng_, if you guys dont mind can we meet sometime today in #openstack-gbp to close on this? 18:39:11 SumitNaiksatam: sure 18:39:14 sure 18:39:24 SumitNaiksatam: sure 18:39:30 great 18:39:52 i think we need rkukura to provide guidance on this since he has mostly written the RMD tests 18:40:06 ivar-lazzaro: if you have time, please do join as well, but no pressure 18:40:14 I’ll need to look over thest current tests to refresh my memory 18:40:18 mageshgv: i know it will be late for you, so you are excused ;-) 18:40:30 SumitNaiksatam: sure 18:40:35 rkukura: yes, lets not meet right after this, i will communicate offline with you guys 18:40:43 ok 18:40:44 okay lets move on for now 18:40:49 ok. 18:41:06 #topic Floating IP support 18:41:18 #link https://review.openstack.org/157298 18:41:26 mageshgv: thanks for posting the spec 18:41:34 did anyone get a chance to review? 18:41:46 i did a quick read before the meeting 18:42:30 I have not yet 18:42:32 but did not get a chance to post coments 18:43:45 mageshgv: per ivar-lazzaro’s comment from last week, i think we need to clarify how the “nat_pool” resource relates to all this 18:43:51 SumitNaiksatam: It will be good to discuss here. Last week we did not reach a consensus in the meeting 18:43:57 okay 18:44:30 SumitNaiksatam: Right, I feel that nat_pool is not useful unless gbp does the natting by itself 18:45:39 mageshgv: NAT pool should be the Neutron equivalent of a FIP pool 18:45:49 mageshgv: scoped per external segment 18:46:05 In Neutron, a FIP pool today is a portion of the external subnet, is that correct? 18:46:48 ivar-lazzaro: i believe so 18:46:50 ivar-lazzaro: Ah, I get what you mean, but is the nat_pool originally intended to be used this way ? I still really get its use case as it is not used today 18:47:13 Is this for SNAT or DNAT? 18:47:18 rkukura: good question 18:47:21 mageshgv: it's not used today, but that was exactly the intention 18:47:48 rkukura: it's for Floating IPs, so SNAT 18:48:10 Is’nt that DNAT ivar-lazzaro ? 18:48:11 rkukura: DNAT is activated by the "PAT" attribute on the segment 18:48:12 ivar-lazzaro: thats DNAT, right? 18:48:30 ivar-lazzaro: thanks for the clarification 18:48:35 ivar-lazzaro: PAT is for SNAT (going from inside to the outside) 18:49:15 per the neutron model, doing the PAT one does not necessarily have to use the floating ip (or at least that was my understanding) 18:49:22 SumitNaiksatam: PAT is Dynamic NAT 18:49:29 SumitNaiksatam: or port address translation 18:49:31 ivar-lazzaro: yes 18:49:38 SumitNaiksatam: FIP are 1:1 addresses 18:49:50 ivar-lazzaro: that's right 18:49:52 SumitNaiksatam: so Static NAT 18:49:59 when we say DNAT here, it means destination NAT, not dynamic NAT 18:50:07 oh 18:50:12 SNAT is static NAT 18:50:17 FIP is DNAT since the destination is modified as packets enter 18:50:42 rkukura: yes, thats the terminology i am familiar with as well 18:50:48 DNAT for me means dynamic NAT, but thanks for clarifying 18:51:12 ok that aside, i think the nat_pool will still tie into the current spec, right? 18:51:21 ok that's the thing, the NAT pool is the pool from which you retrieve addresses for 1:1 mapping 18:51:35 i think the current spec is talking in terms of using the entire subnet from the external subnet 18:51:40 1:1 means that the SRC address gets modified for outgoing packets 18:51:49 whereas nat_pool provides a way to restrict it 18:51:50 and DST address modified for incoming packets 18:53:09 ivar-lazzaro: is it necessary to do the 1:1 for the outgoing packets (even when a floating IP is assigned)? 18:53:17 the PAT flag, on the other hand, is like the one we have on traditional IPv4 networks at home. N internal addresses are translated on the outgoing traffic into M (with M < N tipically) 18:53:26 and the translation is done by port number 18:53:48 ivar-lazzaro: yes, PAT can be independent of the floating ip association 18:53:49 SumitNaiksatam: if it is NOT FIP, 1:1 is not required 18:53:52 SumitNaiksatam: not sure how Neutron does today 18:54:16 ivar-lazzaro: my understanding was that, for outgoing, neutron does a PAT 18:54:23 SumitNaiksatam: but I would guess that a VM with a FIP reaching the outside world will have that FIP as source address 18:54:38 and if floating IP is defined, then it does a SNAT based on the floating IP for incoming 18:55:19 so i think we are discussing two points here: 18:55:21 SumitNaiksatam: and outgoing IMHO. but that's an implementation detail isn't it? 18:55:50 1. how/whether to use the “nat_pool” currently defined in the model 18:56:23 2. how do we achieve outgoing address translation when a floating IP is defined for a port 18:56:53 i think for the later we will have to follow the neutron model (whichever way its implemented) 18:57:08 so we should investigate that and document it in the spec 18:57:10 SumitNaiksatam: note that the NAT pool may not restrict the external segment subnet! It may be a completely different set of addresses. 18:57:24 ivar-lazzaro: okay 18:57:49 and for (1), instead of using the external subnet, use the “nat_pool” for drawing the floating_ips 18:57:58 ivar-lazzaro: mageshgv: does that sound, right? 18:58:20 SumitNaiksatam: that sounds like the initial intent for that model :) 18:58:34 ivar-lazzaro: which model? 18:58:35 sumitNaiksatam: sounds good 18:58:52 SumitNaiksatam: the "nat_pool" object 18:59:11 SumitNaiksatam, mageshgv: the current nat-pool in neutron is related wirh LBaas, is that right? 18:59:15 ivar-lazzaro: okay, is it documented somewhere, that way mageshgv make use of that reference 18:59:23 Yi_: no, not really 18:59:39 Yi_: the current “nat_pool” is a place holder, its not used 18:59:46 hence the confusion 18:59:59 SumitNaiksatam: the External connectivity spec should do the trick IIRC 19:01:22 ivar-lazzaro: the spec says this: “Nat Policy A pool of IP addresses (range/cidr) that will be used by the drivers to implement NAT capabilities when needed. How and whether the Nat Policy will be used by the reference implementation is out of scope of this blueprint.” 19:01:31 we are in a minute over 19:01:33 good discussion 19:01:54 mageshgv: do you think you have enough information now to wrap up the spec? 19:02:12 I think we can continue tomorrow on IRC 19:02:42 mageshgv: okay sure, perhaps you can factor the current discussion into the spec and the rest of the team can review based on that, and we take it from there 19:02:46 mageshgv: thanks for working on this 19:02:52 #topic Open Discussion 19:03:13 we skipped the taskflow discussion and the update on packaging 19:03:23 I would like to bring up a couple of Vancouver talks we are proposing 19:03:50 ivar-lazzaro: yes, we have a bunch of talks around GBP 19:04:16 #link https://www.openstack.org/vote-vanvouver/presentation/taking-security-groups-to-ludicrous-speed-with-open-vswitch 19:04:18 let post the talks on the wiki page 19:04:29 (not really GBP related that one, but still interesting) 19:04:31 so that everyone can see them 19:04:43 Ok good idea 19:04:49 we also are proposing a Lab session 19:05:12 cool 19:05:22 all please check the wiki page by end of today for the talks 19:05:29 and please vote :-) 19:05:32 thanks all 19:05:35 bye 19:05:39 thank you 19:05:40 Me and rkukura are driving this, but it would be great to have at least one more core with deep experience on GBP's SC 19:05:51 bye 19:05:52 so let me know if you are interested :) byw! 19:06:00 ivar-lazzaro: needless to say, i will be participating as well 19:06:09 bye 19:06:14 bye 19:06:14 #endmeeting