18:01:36 <SumitNaiksatam> #startmeeting networking_policy
18:01:37 <openstack> Meeting started Thu Apr 30 18:01:36 2015 UTC and is due to finish in 60 minutes.  The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:40 <openstack> The meeting name has been set to 'networking_policy'
18:01:47 <igordcard> hello all
18:01:55 <SumitNaiksatam> #info agenda https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy#April_30th.2C_23rd.2C_2015
18:02:11 <SumitNaiksatam> #topic Bugs
18:03:04 <SumitNaiksatam> i think only the back port for this is not merged: #link https://bugs.launchpad.net/group-based-policy/+bug/1432779
18:03:04 <openstack> Launchpad bug 1432779 in Group Based Policy "redirect actions don't work with external policies" [Critical,In progress] - Assigned to Ivar Lazzaro (mmaleckk)
18:03:31 <SumitNaiksatam> other than that, i dont think we have any reported outstanding critical bugs
18:04:04 <SumitNaiksatam> any other bugs to discuss today?
18:04:47 <SumitNaiksatam> okay perhaps not
18:04:58 <SumitNaiksatam> #topic Functional/Integration Tests
18:05:10 <SumitNaiksatam> #link https://review.openstack.org/#/c/174267
18:05:54 <SumitNaiksatam> the above patch starts running jishnu’s test suite which performs integration testing by exercising GBP REST and client interfaces
18:06:06 <ivar-lazzaro> nice!
18:06:09 <SumitNaiksatam> at this point all tests are passing in that test suite
18:06:21 <ivar-lazzaro> do we know what is covered by the tests?
18:06:22 <SumitNaiksatam> we have to fix some bugs which this test suite caught
18:06:46 <SumitNaiksatam> it covers all the resources we had in juno
18:07:03 <SumitNaiksatam> and some  scenarios
18:07:05 <rkukura> are tests disabled due to bugs?
18:07:16 <SumitNaiksatam> rkukura: no tests are currently disabled
18:07:29 <SumitNaiksatam> i mean no tests in that test suite are disabled
18:07:49 <rkukura> if they all pass, why do we have to fix some bugs?
18:07:59 <SumitNaiksatam> rkukura: they were not passing before
18:08:10 <rkukura> OK, so they have already been fixed?
18:08:19 <SumitNaiksatam> yeah, as of yesterday
18:08:35 <SumitNaiksatam> so you see the job passing today
18:08:41 <rkukura> great, I was confused by “we have to fix” implying they weren’t already fixed
18:08:49 <ivar-lazzaro> rkukura: +1 :)
18:09:09 <SumitNaiksatam> oh, sorry, i meant to say “had” not “have”…my bad
18:09:22 <rkukura> no problem
18:09:36 <SumitNaiksatam> in some cases the bugs were fixed but the tests were not updated
18:09:50 <SumitNaiksatam> in the sense that the tests were not checking for the right result
18:09:57 <SumitNaiksatam> so a combination of things
18:10:08 <SumitNaiksatam> but anyway, right now its clean
18:10:34 <SumitNaiksatam> it would have been good to have jishnu in this meeting to answer specific questions on the extent of coverage
18:10:45 <SumitNaiksatam> but he is in travel right now
18:11:31 <SumitNaiksatam> the patch itself is just shell script enabling the tests
18:12:14 <ivar-lazzaro> SumitNaiksatam: is the test suite published anywhere?
18:12:20 <SumitNaiksatam> yapeng: songole: hi thanks for joining
18:12:29 <songole> hello
18:12:33 <ivar-lazzaro> SumitNaiksatam: It would be good to have a feeling of which datapath scenario are covered
18:12:36 <ivar-lazzaro> songole: hi
18:12:41 <rkukura> do the same tests run for both master and stable/juno?
18:12:47 <songole> ivar-lazzaro: hi
18:13:38 <SumitNaiksatam> ivar-lazzaro: firstly the test suite is not doing data path testing
18:14:06 <SumitNaiksatam> ivar-lazzaro: the tests are published in pypi package
18:14:31 <SumitNaiksatam> rkukura: the same tests run for both master and stable/juno
18:15:29 <rkukura> SumitNaiksatam: What will we do when master diverges from stable/juno so that we need different tests? Can we branch the test repo too?
18:15:37 <SumitNaiksatam> rkukura: yes
18:15:54 <SumitNaiksatam> rkukura: right now the test suite mostly covers the juno features
18:17:04 <SumitNaiksatam> any other questions on this test case?
18:18:52 <SumitNaiksatam> hopefully we can get the patch merged soon
18:18:56 <SumitNaiksatam> #topic Packaging Update
18:19:13 <SumitNaiksatam> rkukura: anything to update here?
18:20:02 <rkukura> I have not made any progress on fedora/RDO packages (was on PTO last week).
18:20:15 <rkukura> I checked today and it looks like all the tarballs on launchpad are at least a month old. Are we waiting for new ones?
18:20:29 <SumitNaiksatam> rkukura: we havent cut kilo-3 yet
18:20:36 <rkukura> that’s what I thought
18:20:45 <SumitNaiksatam> if thats what you are looking for
18:20:59 <rkukura> that, and a new stable/juno release I think
18:21:07 <SumitNaiksatam> or were you looking for another stable/juno?
18:21:13 <SumitNaiksatam> ah just asking that
18:21:38 <rkukura> I can certainly update to the stable/juno tarballs we have, but thought we had lots of fixes since then
18:21:39 <SumitNaiksatam> rkukura: okay lets sync up after this meeting on this
18:21:42 <rkukura> sure
18:22:04 <SumitNaiksatam> #topic Kilo Sync
18:22:05 <rkukura> I’d like to get the fedora packages update soon enough that the RDO packags will be updated by the summit.
18:22:23 <SumitNaiksatam> rkukura: okay, lets work towards getting you need for that
18:22:29 <SumitNaiksatam> *what you
18:22:32 <rkukura> SumitNaiksatam: thanks
18:22:42 <SumitNaiksatam> rkukura: i will ping you after this meeting
18:23:04 <SumitNaiksatam> regarding kilo sync
18:23:42 <SumitNaiksatam> the last vestiges of kilo sync are complete meaning - GBP-UI and GBP-Automation projects are is sync with kilo
18:24:00 <SumitNaiksatam> also the kilo-gbp devstack branch is functional with kilo
18:24:35 <igordcard> SumitNaiksatam, nice
18:24:38 <SumitNaiksatam> by functional with kilo I mean, it uses stable/kilo branches for openstack projects
18:24:48 <igordcard> SumitNaiksatam, was the kilo-gbp devstack branch broken last saturday?
18:25:02 <SumitNaiksatam> igordcard: yes it was broken at different times :-)
18:25:08 <igordcard> SumitNaiksatam, okay
18:25:18 <SumitNaiksatam> i have tested this, but please let me know if you see any issues
18:25:22 <ivar-lazzaro> mac died, sorry about that
18:25:30 <SumitNaiksatam> ivar-lazzaro: np
18:25:47 <ivar-lazzaro> did I miss anything exciting?
18:25:58 <SumitNaiksatam> the kilo-gbp branch itself is based on upstream devstack stable/juno
18:26:06 <SumitNaiksatam> ivar-lazzaro: no, same old boring stuff! ;-)
18:26:26 <igordcard> last night (your afternoon) kilo-gbp ran without any issues here
18:26:27 <SumitNaiksatam> at this point i consider the kilo-sync acitivity to be complete
18:26:34 <SumitNaiksatam> ivar-lazzaro: ah okay, good to know
18:27:11 <SumitNaiksatam> one thing to note, especially rkukura - the gbp client also has progressed to sync with kilo
18:27:31 <SumitNaiksatam> it means that for using GBP stable/juno we have to use 0.9.1 version of the client
18:28:03 <rkukura> SumitNaiksatam: For fedora and RDO, we’ll need to be compatible with the client versions included in those releases
18:28:06 <SumitNaiksatam> by version, i mean its a 0.9.1 tag in the repo
18:28:29 <igordcard> will python-openstackclient be extended to support gbp?
18:28:44 <SumitNaiksatam> rkukura: so 0.9.1 should work with openstack stable/juno
18:29:34 <SumitNaiksatam> igordcard: my understanding is that  python-openstackclient has a modular architecture such that we could extend it without us having to push anything into python-openstackclient, is that correct?
18:30:27 <igordcard> SumitNaiksatam, I haven't seen the internals of python-openstackclient but the individual clients seem to be getting deprecated, so I asked
18:31:07 <SumitNaiksatam> igordcard: i believe this discussion came up in the context of neutron as well, and the last i heard they were not planning to move immediately (or at least were not being forced to)
18:31:18 <SumitNaiksatam> but i have not been uptodate with that
18:31:24 <SumitNaiksatam> that said i dont think we are targeting any of this acitivity for kilo
18:31:32 <SumitNaiksatam> unless we are forced to
18:31:43 <SumitNaiksatam> of course, definitely something we do plan to do
18:31:53 <SumitNaiksatam> igordcard: in case you want to scope out what it involves, that would be great
18:32:20 <igordcard> SumitNaiksatam, I can do that
18:32:20 <SumitNaiksatam> just to assess the amount of work both from a technical and resource perspective
18:32:25 <SumitNaiksatam> igordcard: great, thanks
18:32:56 <SumitNaiksatam> #topic Floating IP
18:33:07 <SumitNaiksatam> i think magesh is on PTO
18:33:28 <SumitNaiksatam> but i did notice that he addresses the review comments and has posted a new version of the spec
18:33:37 <SumitNaiksatam> Spec #link https://review.openstack.org/#/c/167174
18:33:48 <SumitNaiksatam> Implementation #link https://review.openstack.org/#/c/167174/
18:34:31 <SumitNaiksatam> at this point i believe whatever was discussed in the numerous discussions has been captured and mostly implemented
18:34:55 <SumitNaiksatam> since magesh is not here, comments will have to go to the review
18:35:53 <SumitNaiksatam> #topic Service Chain provider refactor
18:36:08 <SumitNaiksatam> Spec #link https://review.openstack.org/#/c/174118
18:36:17 <SumitNaiksatam> Impl #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master+topic:bp/sc-refactor,n,z
18:36:46 <SumitNaiksatam> so there were few revs on the spec, and ivar-lazzaro has posted WIP patches as well per the current state of the spec
18:36:54 <ivar-lazzaro> #link https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master+topic:bp/node-centric-chain-plugin,n,z
18:37:34 <ivar-lazzaro> The topic is different, just to be more specific
18:37:49 <ivar-lazzaro> there was no blueprint yet in launchpad
18:38:15 <SumitNaiksatam> ivar-lazzaro: okay i will add it
18:38:48 <ivar-lazzaro> SumitNaiksatam: it's there now, just with a different topic #link https://blueprints.launchpad.net/openstack/?searchtext=node-centric-chain-plugin
18:39:16 <ivar-lazzaro> SumitNaiksatam: I arbitrarily chose it, but we can change it at any time if we want to
18:40:30 <SumitNaiksatam> ivar-lazzaro: nit comment - i prefer calling this a “nodes composition plugin” NCP
18:41:02 <ivar-lazzaro> SumitNaiksatam: I like node composition better too
18:41:13 <ivar-lazzaro> SumitNaiksatam: however I would use "Chain" instead of "Plugin"
18:41:31 <SumitNaiksatam> ivar-lazzaro: i would intentionally avoid “chain"
18:41:39 <ivar-lazzaro> SumitNaiksatam: plugin would be implicit in this case, but it's at least clear that it's a servicechain implementation
18:41:43 <SumitNaiksatam> other than that, the ability to pass service-specific key-value pairs also needs to be there
18:42:21 <ivar-lazzaro> SumitNaiksatam: about that, I was wondering if we need to introduce the concept of "tag"
18:42:35 <ivar-lazzaro> It would be a different URI, something like /tags
18:42:56 <ivar-lazzaro> in which you could define metadata for all the GBP objects (and SC) without changing them directly
18:43:33 <ivar-lazzaro> The main point of Tags is that they will be for consumption of entities outside of GBP itself
18:43:39 <ivar-lazzaro> (eg. UI, Automation, etc...)
18:43:39 <SumitNaiksatam> thats definitely an option as we discussed
18:44:17 <SumitNaiksatam> i would prefer to not call it tags, since we also have the notion of policy “labels” and can be confusing
18:44:29 <ivar-lazzaro> So that every "internal" API (eg. service_profile, that needs to be consumed by the Node Drivers) can be defined by APIs and Extensions
18:44:30 <SumitNaiksatam> but names aside, it would be good to hear from the rest of the team on this
18:45:20 <ivar-lazzaro> SumitNaiksatam: Difference between labels and tags is that the latter won't be understood by internal GBP components
18:45:39 <ivar-lazzaro> SumitNaiksatam: but we can choose a different name for that nonetheless
18:45:59 <SumitNaiksatam> ivar-lazzaro: i dont think it will never be the case that a node driver does not use a service-specific meta-data attribute - that is an implementation detail for the node driver
18:46:37 <ivar-lazzaro> SumitNaiksatam: right, but since the node understands it, then it could as well just be an extension of service_profile
18:46:47 <ivar-lazzaro> SumitNaiksatam: instead of a generic key-value pair
18:47:07 <SumitNaiksatam> the benefit of having this common metadata resource approach is that it allows us to associate aribitrary meta-data with any GBP resources
18:47:13 <ivar-lazzaro> SumitNaiksatam: while for externally consumed metadata, we can use tags (of course the driver could tag a node)
18:47:21 <rkukura> This is not sounding very intent-oriented :(
18:47:58 <SumitNaiksatam> the downside is that it requires the user to correlate information
18:48:05 <ivar-lazzaro> rkukura: tags are not intended to change the resource behavior, they are useful for external automation more than anythig
18:48:22 <ivar-lazzaro> rkukura: for example: which UI should I use to manage this Node?
18:49:00 <rkukura> I don’t see how “nodes” have much to do with “intent”
18:49:17 <SumitNaiksatam> rkukura: i agree that the level of the node driver its not an intent abstraction any more
18:49:51 <ivar-lazzaro> rkukura: on that I agree. However keep in mind that we are talking about an operator API
18:49:54 <rkukura> I admit I have not been following previous discussions on this, or the BP, so I’m not even sure what a “node driver” is.
18:50:08 <igordcard> but the user does not need to deal with a Node directly
18:50:12 <SumitNaiksatam> rkukura: however its not the “nodes”, its the “nodes driver”
18:50:28 <rkukura> ivar-lazzaro: If its purely operation API, I’m not as concerned.
18:50:34 <rkukura> operator
18:50:36 <ivar-lazzaro> igordcard: +1
18:50:43 <SumitNaiksatam> rkukura: yes, per igordcard, the node driver is not visible to the user
18:50:49 <rkukura> thanks
18:50:49 <ivar-lazzaro> igordcard: that's for operator consumption
18:51:07 <SumitNaiksatam> rkukura: and yes this configuration is for opertaional reasons
18:51:37 <SumitNaiksatam> the confusion is happening because so far we have been dealing only with tenant facing resources
18:51:46 <ivar-lazzaro> rkukura: Service chain Specs/Nodes/Instances are purely Operator oriented, mostly like L2/L3 policies
18:51:53 <rkukura> Just to clarify, we mean “cloud operator” here, not the application deployment role, right?
18:51:55 <igordcard> the user simply chooses a service to be put into the service chain, eventually assigning some meaningful tags that the system supports, which could then be used internally for, e.g. as ivar-lazzaro said, show a different UI
18:52:02 <ivar-lazzaro> rkukura: yes
18:52:16 <SumitNaiksatam> however a new resource is being proposed here called “service profile”
18:52:33 <SumitNaiksatam> this resource is managed by the operator (cloud operator)
18:52:45 <ivar-lazzaro> igordcard: the user would simply chose the policy rule (REDIRECT to some chain)
18:52:46 <SumitNaiksatam> but is visible to the user
18:53:04 <igordcard> ivar-lazzaro, and the tags are predefined for the nodes that compose the chain right?
18:53:14 <ivar-lazzaro> igordcard: how the chain is implemented and which metadata are associated with it is a Cloud Operator's concern
18:53:52 <SumitNaiksatam> i would have preferred to not immediately model these as a resource, but hide them as operational details (driven via configuration)
18:54:02 <ivar-lazzaro> igordcard: this may be one use, yes. But the tag resource I have in mind actually covers *all* the GBP resources for API consistency
18:54:57 <ivar-lazzaro> SumitNaiksatam: but this would mean adding key-value attributes to certain resources, so an API change is still required right?
18:55:20 <igordcard> any thought been given on allowing users to influence the behaviour of resources by applying tags  themselves?
18:55:54 <SumitNaiksatam> ivar-lazzaro: in that case the service profile is completely internal, you only expose its description to the user
18:55:55 <ivar-lazzaro> igordcard: I think those are "labels", and no we haven't discussed them yet
18:56:00 <igordcard> in this case the tag resource would probably be something else
18:56:11 <igordcard> ivar-lazzaro, yeah
18:56:30 <SumitNaiksatam> lets not call them tags, since it casuses confusion, i think meta-date is more appropriate here :-)
18:56:46 <SumitNaiksatam> otherwise we will go around in circles even in this small group
18:57:04 <ivar-lazzaro> SumitNaiksatam: I say we call them Endpoints!
18:57:36 <SumitNaiksatam> ivar-lazzaro: amen
18:58:07 <ivar-lazzaro> SumitNaiksatam: eheh :)
18:58:08 <igordcard> so, just to clarify, you intend to have service profiles defined by operators and used by tenants
18:58:19 <SumitNaiksatam> igordcard: yes
18:58:33 <SumitNaiksatam> perhaps we might not expose all attributes to users
18:59:23 <igordcard> and "config" is the field where the user can input additional constraints/metadata/configs for the service?
18:59:48 <igordcard> per https://review.openstack.org/#/c/174118/7/specs/kilo/gbp-service-chain-driver-refactor.rst : "Node Driver": "This configures the service based on the “config” provided in the Service Node definition."
18:59:49 <ivar-lazzaro> igordcard: I actually think that the user should never interact with the services
18:59:53 <SumitNaiksatam> igordcard: we already have a config in the “node” definition
19:00:42 <SumitNaiksatam> igordcard: the meta-data i am referring to goes beyond that “config"
19:01:04 <ivar-lazzaro> The final user should only think "intent
19:01:18 <SumitNaiksatam> ivar-lazzaro: true, user will never directly interact with the service, that doesnt happen today either
19:01:44 <SumitNaiksatam> *will never -> should never
19:01:54 <SumitNaiksatam> okay we are a minute over
19:02:04 <SumitNaiksatam> #topic Vancouver Summit prep
19:02:14 <SumitNaiksatam> ivar-lazzaro: rkukura: anything quick to discuss?
19:02:18 <igordcard> ivar-lazzaro, yes, yes, but if the intent can be expressed in a richer way, it may be beneficial
19:02:22 <SumitNaiksatam> igordcard: you are coming to the summit?
19:02:30 <SumitNaiksatam> yapeng: you are coming to the summit?
19:02:31 <igordcard> SumitNaiksatam, unfortunately not :(
19:02:38 <SumitNaiksatam> igordcard: oh bummer!
19:02:42 <ivar-lazzaro> SumitNaiksatam: I'm trying to figure out a way to implement shared PRS for the RMD
19:02:50 <yapeng> yes i will come
19:02:54 <SumitNaiksatam> ivar-lazzaro: ah correct
19:02:55 <ivar-lazzaro> SumitNaiksatam: I have a couple of ideas but I'm still trying to validate them
19:03:07 <SumitNaiksatam> ivar-lazzaro: that part was challenging as you mentioned
19:03:10 <ivar-lazzaro> Should we discuss them in the gbp channel?
19:03:14 <SumitNaiksatam> ivar-lazzaro: thanks for taking that up
19:03:19 <SumitNaiksatam> ivar-lazzaro: sure
19:03:26 <SumitNaiksatam> yapeng: good
19:03:35 <ivar-lazzaro> I'd like to hear from the rest of the team, especially those with a richer Neutron background
19:03:50 <Yi> SumitNaiksatam: unfortunately, I cannot
19:04:06 <Yi> I won't be able to go to summit
19:04:10 <SumitNaiksatam> Yi: sorry, i did not notice that you had joinied, earlier i checked you were not
19:04:17 <SumitNaiksatam> Yi: damn thats a bummer
19:04:22 <Yi> was stuck in another meeting
19:04:24 <rkukura> ivar-lazzaro: Is there something for us to look at to understand your ideas?
19:04:26 <SumitNaiksatam> Yi: lets sync up offline on that
19:04:33 <Yi> sure
19:04:59 <ivar-lazzaro> rkukura: I have nothing besides some code, but it's not published yet... Maybe we can discuss it on IRC and then I can publish a WIP?
19:05:14 <rkukura> ivar-lazzaro: sure
19:05:18 <ivar-lazzaro> rkukura: I wanted to write a spec but I don't know yet what will work! So it's not easy
19:05:50 <SumitNaiksatam> one last thing
19:05:51 <rkukura> ivar-lazzaro: IRC, email, hangout, whatever works best
19:05:55 <SumitNaiksatam> #topic Refactor feature branch
19:06:05 <SumitNaiksatam> yi and yapeng’s patches are finally all in
19:06:20 <yapeng> cool :)
19:06:21 <ivar-lazzaro> rkukura: anything is good for me, the sooner we discuss the best. Do you have time after the meeting?
19:06:22 <SumitNaiksatam> Yi: thanks so much for pursuing the last patch
19:06:37 <SumitNaiksatam> we will work towards merging them from the feature branch once we are done with the summit
19:06:38 <Yi> my pleasure
19:06:45 <ivar-lazzaro> yapeng: Yi: Thanks guys!
19:06:51 <SumitNaiksatam> okay lets move to -gbp
19:07:00 <SumitNaiksatam> thanks all, and apologies for going over
19:07:02 <SumitNaiksatam> bye!
19:07:06 <igordcard> cya
19:07:08 <Yi> bye
19:07:08 <ivar-lazzaro> ciaooo
19:07:09 <SumitNaiksatam> #endmeeting