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