16:00:24 <mestery> #startmeeting networking_policy
16:00:24 <openstack> Meeting started Thu Dec  5 16:00:24 2013 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:27 <openstack> The meeting name has been set to 'networking_policy'
16:00:38 <mestery> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Agenda
16:00:42 <s3wong> Hello
16:00:42 <SumitNaiksatam> hi!
16:00:57 <mestery> #topic Action Items from last week
16:01:06 <mestery> I guess it's from two weeks ago. :)
16:01:10 <alagalah> Hi
16:01:15 <mestery> First one: banix and michsmit
16:01:29 <mestery> Any progress on fleshing things out on abojects and attributes?
16:01:48 <banix> I added a few tables to the doc describing the attributes of new objects
16:02:06 <mestery> banix: Near the end of the doc, right?
16:02:08 <ywu> ehllo
16:02:15 <banix> Have you guys had a chance to have a look: https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#
16:02:20 <banix> mestery: yes
16:02:27 <mestery> #link https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing Neutron Policy Google Doc
16:02:39 <mestery> banix: I briefly looked this morning, thanks for starting on this.
16:03:17 <banix> mestery: sure
16:03:25 <mestery> Has anyone else had a chance to look at the work banix has done on the document?
16:03:34 <thinrichs> I took a quick look.
16:03:46 <s3wong> yes
16:04:05 <mestery> #topic Object and Attribute Discussion
16:04:11 <mestery> Lets move to discussing those now.
16:04:17 <alagalah> reading
16:04:44 <banix> So I think the first question to answer is:
16:05:10 <banix> Do we start with or without "endpoint" as a Neutron object.
16:05:46 <mestery> banix: I think we should start with that assumption, yes, but I'm curious what others think.
16:05:56 <banix> I think we should have them but the question is if starting without them will make things simpler without limiting us too much
16:06:10 <thinrichs> I don't know how we could have non-Neutron objects as endpoints.
16:06:18 <thinrichs> What would those objects mean?
16:06:33 <mestery> thinrichs: Exactly, thus I think we need the endpoint concept from the start.
16:06:36 <thinrichs> How would, e.g. Heat, know what an object that Neutron doesn't understand represent?
16:06:39 <s3wong> How are endpoints as non-Neutron object be represented?
16:06:44 <ywu> i assume we start with Neutron objects first.
16:07:01 <prasadv> i think neutron needs to know
16:07:24 <alagalah> Doesn't neutron need to know the capabilities of the underlying resources around which it is making a policy?
16:07:32 <alagalah> ie QoS, policing etc?
16:07:44 <mestery> banix: Correct me if I'm wrong, but if we start without the endpoint concept, we would instead directly be putting ports and possibly networks into groups, right?
16:07:59 <banix> Well, if we do not have "endpoint" as a Neutron object, we will be limited to using ports and networks, etc.
16:08:02 <banix> mestery: yes
16:08:45 <thinrichs> But even if we had "endpoint" as an object, how could Neutron enforce a policy over endpoints--when they're not objects it understands in any fundamental way?
16:08:47 <mestery> banix: I think it makes sense to start with the endpoints then, and we can map those internally to ports/networks if we need to.
16:09:16 <dttocs> I think we need endpoint as an abstract neutron object - they are objects, but they don't necessarily live in a specific place in the existing Neutron hierarchy
16:09:32 <ywu> metery, i like this idea.
16:09:45 <thinrichs> mestery/dttocs: I'm not convinced.
16:09:53 <mestery> thinrichs: We would be exposing endpoints into the neutron object model per banix's notes in the document.
16:10:03 <thinrichs> How can Neutron implement a policy when it doesn't know what those objects represent?
16:10:30 <dttocs> Core neutron wouldn't necessarily know, but the plugin responsible for that endpoint would certainly need to
16:10:41 <banix> thinrichs: If we have them as objects then Neutron know what to do with them
16:10:46 <thinrichs> dttocs: but then the semantics of the policy is plugin-dependent.
16:10:49 <banix> dttocs: exactly
16:11:02 <sc68cal> We already have a case of semantics of policy being plugin dependent
16:11:06 * sc68cal points to the QoS API
16:11:10 <thinrichs> We don't want the same policy to mean 2 different things, depending on which plugin we're using.
16:11:16 <sc68cal> at least that's what I've been trying to do
16:11:33 <banix> thinrichs: well, it will be extension-dependent
16:11:37 <thinrichs> This is the same issue we discussed last week, but instead of not knowing the syntax of the policy, here other OS components don't know the semantics.
16:11:56 <alagalah> banix: So with the Attributes tables, regarding Endpoints, would it be useful to define what Actions: they can perform or provide which gives context to WHAT they do as an endpoint even if outside of Neutron control ? ie it shows its capabilities?
16:12:00 <thinrichs> Happy to have extensions, but the core language must have a syntax/semantics that everyone agrees on.
16:12:12 <michsmit> thinrichs: the intent is the same, the rendering of the policy may be different
16:12:47 <mestery> michsmit: Yes, that's exactly it.
16:12:49 <thinrichs> michsmit: great--but what is the intent if the basic objects change meaning from plugin to plugin.
16:13:23 <banix> alagalah: that would make things a bit too complicated to start with. Don't you think?
16:14:03 <alagalah> Well I guess I'm trying to think of this as action "providers" and action "consumers" and work out where they meet in the middle rather than look at "endpoint" per se and branch out from there
16:14:09 <thinrichs> If WE described the semantics of these objects in the language, then great.  Every plugin can implement those however they like.
16:14:49 <banix> I think if we have endpoints for now they will refer to known Neutron objects (that's why we could not use them at the moment). No?
16:15:22 <mestery> banix: Yes.
16:15:22 <alagalah> banix: If that comment was to me, then yes, I think that at least confines the problem space
16:15:37 <thinrichs> If we said that 'foozle' means <connecting internal net to external net> then great.  Or if we used common terms like 'router', 'switch', where everyone knows the semantics, that works too.
16:15:38 <michsmit> banix: agreed
16:16:17 <thinrichs> But what I'm worried about is if we just say there's a collection of objects, and each plugin defines what that object does--what its properties are, what its functionality is, etc.
16:16:20 <alagalah> But to thinrichs point, banix, if we think in terms of "provider" "consumer" semantics it (potentially) could make it more extensible (ie I thinking ODL integration with various switching platforms etc)
16:16:21 <mestery> thinrichs: That's what the google document is trying to do.
16:16:21 <banix> So would the Alternative Option in the doc a reasonable start?
16:16:55 <alagalah> banix: The Alternative option appeals to me
16:17:56 <mestery> banix: Just to be clear, you are referring to the alternative option around Endpoints/Groups you wrote up, correct?
16:18:07 <thinrichs> Took another peak at the google doc.
16:18:10 <banix> mestery: yes
16:18:40 <thinrichs> The Alternate option basically allows, say Heat, to create uuids and put them in groups, yes?
16:18:47 <michsmit> banix: Under endpoint attributes, the member field indicates the group in the alternative option ?
16:19:09 <thinrichs> Then we write a policy that says UUID1 and UUID2 can't exchange packets on port 80 (or something similar).
16:19:26 <banix> mestery: sorry for not being clear, no
16:19:51 <banix> There is no reference back to the group but we could add that; this way an endpoint can belong to multiple groups
16:20:07 <banix> member is essential a reference to say the "port" or "network"
16:20:18 <banix> should change the name; it is confusing
16:20:27 <alagalah> banix: Is it worth buildign a taxonomy like pp2 of this document: http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf
16:21:29 <alagalah> banix (for your alternative option)
16:21:59 <banix> alagalah: thanks for the reference; doesn't the table provide the same info? We can obviously make it more complete.
16:22:20 <mestery> alagalah banix: I agree, lets flesh out the work banix has done on the table in the doc.
16:22:22 <alagalah> alagalah: The table is good, but there was questions about where members/groups are referenced
16:22:32 <thinrichs> alagalah: something like that where we spell out the meaning of all the possible objects would make me happy.
16:22:33 <alagalah> mestery / banix : No worries
16:22:37 <dttocs> Taxonomy seems worthwhile - I got lost in the details with the table
16:22:41 <banix> alagalah: got it.
16:23:05 <mestery> banix: Can I give you an action item to flesh this out a bit based on the discussion here?
16:23:08 <dttocs> e.g. question about what QoS parameters should be supported - we need the taxonomy first, then can get into those details imho
16:23:30 <michsmit> a diagram showing the relationships between the tables may help
16:23:38 <banix> dttocs: sure. will do.
16:23:41 <mestery> #action banix to flesh out the tables he put in the document.
16:23:42 <alagalah> banix: I can have a crack at it if you like, and you can chastise me for getting it wrong and I can fix
16:23:53 <mestery> #undo
16:23:53 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x26b7950>
16:24:01 <mestery> alagalah banix: You guys want to collaborate on this one?
16:24:03 <banix> alagalah: sounds good. Thanks.
16:24:09 * alagalah ack
16:24:15 <banix> mestery: yes.
16:24:27 <mestery> #action banix and alagalah to flesh out the tables started in the document, possibly adding a diagram showing the relationship
16:24:28 <prasadv> is the endpoint to group association automatic
16:24:34 <mestery> banix alagalah: Thanks!
16:24:59 <prasadv> i mean say a vm gets created and does it get associated to groups automatically because there is a metadata for vm in that group
16:25:02 <banix> prasadv: so in some case
16:25:32 <banix> so if the network is part of the group, then all ports on it would be automatically. For ports, I assume it should be specified explicitly.
16:25:45 <rudrarugge> banix: if network has to be associated with a group then how many UUIDs are in the picture
16:26:09 <prasadv> banix: the association might not be network only right?
16:26:11 <rudrarugge> endpoint UUID (pointing to network UUID). Group UUID containing this network UUID?
16:26:40 <banix> rudrarugge: yes
16:26:46 <rudrarugge> I meant group UUID containing this endpoint UUID which in effect points to a network UUID
16:26:47 <rudrarugge> ok
16:26:59 <prasadv> I could have say load balancing group that I would like to represent.
16:27:27 <alagalah> Reliance on UUID as a form of naming abstraction is key IMHO... makes service chaining more generic
16:27:43 <alagalah> Rely on the underlying object and its methods it represents (and its data model) ...
16:28:04 <thinrichs> prasadv: are you concerned that the size of these groups will be massive?
16:28:11 <prasadv> banix: what  I mean is is Nova pass this group association to neutron when a endpoint gets created so this may be automatic
16:28:39 <mestery> prasadv: I follow that now. The interactions with nova are something we have not fleshed out quite yet.
16:28:55 <prasadv> thinrichs: no I want to know that there is automatic way to associate
16:28:57 <mestery> Once we finalize the object model here, I think we should look at that next, as it's the obvious first use case.
16:28:58 <banix> prasadv: So if the network is the endpoint, adding a new VM which will require a new port with put that endpoint/port/vm in the group...
16:29:09 <prasadv> mestery: thanks
16:29:34 <banix> prasadv mastery: yes that would a neat first use case
16:29:45 <prasadv> banix: network is simple but groups might be more narrow than that
16:30:04 <banix> prasadv: yes agree
16:30:50 <s3wong> a VM should not be an endpoint, right? rather a port on a VM is an endpoint?
16:30:55 <mestery> #info The nova use case is an interesting first one to cover once the object model is completed.
16:31:00 <prasadv> just wanted to make sure that a user can pass metadata of some sort during endpoint creation which will then get reflected to neutron
16:31:31 <banix> prasadv: makes sense; we have to figure this out.
16:31:31 <mestery> s3wong: Correct.
16:32:08 <banix> s3wong: yes; i oversimplified in above statement.
16:32:33 <mestery> So, we have 30 minutes left, should we discuss the Actions section banix added next?
16:32:34 <banix> s3wong: when I used "endpoint/port/vm"
16:32:47 <s3wong> banix: cool :-)
16:32:51 <mestery> I think that is the only other thing new on the agenda for this week.
16:32:57 <mestery> Else we can open it up for open discussion
16:33:32 <banix> mestery: yes lets look at the rest
16:33:38 <banix> s3wong added the action type descriptions
16:33:46 <mestery> #topic Action Types Discussion
16:33:55 <s3wong> mestery: for the action section, banix and I talked about it, and the action description should not be Neutron objects, so I will update
16:33:59 <mestery> s3wong banix: Thanks for adding those into the document.
16:34:13 <mestery> s3wong: OK, that makes sense.
16:34:23 <banix> mestery: sure
16:34:30 <mestery> #action s3wong to update action section in document to not reflect neutron objects directly.
16:35:39 <mestery> sc68cal: It may be good for you to look at the examples of using actions for QoS in the document, would appreciate your feedback there.
16:36:08 <sc68cal> add an action item for me, I've glanced at it a couple times but my concern is how to get from where my code is to where it needs to be to integrate with this work
16:36:30 <sc68cal> mostly I just need to do a little more research and catch up with you guys
16:36:33 <dttocs> As I just noted in the doc comments, I think we need a set of core action attributes that all plugins must implement and then some mechanism to extend.  Make sense?
16:36:34 <alagalah> sc68cal Are you scottd in the gdoc ?
16:36:44 <mestery> #action sc68cal Look over action example for QoS and provide feedback
16:36:45 <alagalah> dttocs ...
16:36:50 <sc68cal> alagalah: no
16:36:51 <dttocs> No scottd=dttocs=Scott Drennan - Nuage Networks
16:36:55 <s3wong> sc68cal: perhaps we can discuss the use case and see whether the model fit?
16:37:11 <alagalah> dttocs  I see your comments to my comments on QoS in the gdoc, thanks
16:38:10 <banix> dttocs: yes we should specify a minim set to begin with.
16:38:26 <s3wong> dttocs: yes, that makes sense
16:38:48 <thinrichs> dttocs: is it the action attributes or the action functionality that we want all plugins to implement?
16:38:55 <mestery> I would advise folks who are interested to review the action section and provide feedback in the google doc in detail.
16:39:54 <s3wong> actions are also classifed by action_type - and currently the first set of primitives are type security, qos, and redirect
16:40:50 <mestery> thinrichs dttocs: I think it has to be the action attributes vs. the functionality.
16:41:25 <dttocs> thinrichs: I think this goes back to the initial discussion about what common behaviour/capabilities we have between plugins
16:41:26 <thinrichs> So 1 plugin could interpret 'redirect' in a completely different way than another plugin?
16:42:09 <thinrichs> Meaning that 1 plugin could interpret 'redirect' to mean 'push packets through a proxy' and another to mean 'drop packets'?
16:42:17 <s3wong> thinrichs: one plugin can implement it differently, but the end behavior should be the same
16:42:32 <thinrichs> s3wong: agreed.
16:42:48 <mestery> Yes, what s3wong indicated.
16:43:00 <thinrichs> s3wong: wouldn't that mean we need to spell out the meaning (functionality) of those actions?
16:43:09 <mestery> So that means the action's need to be defined such that the end goal makes is understood.
16:43:21 <mestery> The semantics of how each plugin reaches the end goal is the nebulous part.
16:43:22 <s3wong> thinrichs: absolutely
16:43:29 <mestery> :)
16:43:31 <dttocs> thinrichs:  Taking QoS as an example, DHCP marking would be common behaviour, but if we added policing/shaping as a common attribute every network device implements those differently
16:43:33 <mestery> I think we all just said the same thing.
16:43:56 <s3wong> mestery: right :-)
16:44:01 <prasadv> can a plugin say that there are certain types it does not implement, and how does that get reflected
16:44:06 <thinrichs> mestery: agreed, except I don't see a end-goal as part of the doc, or am I missing it?
16:44:28 <mestery> thinrichs: I need to re-read the document myself at this point to verify if that's in there. :)
16:44:30 <s3wong> prasadv: I believe that's what dttocs indicated above. A core set where all plugins have to implement
16:44:55 <mestery> prasadv: If a plugin doesn't implement one, it would fail the API call for those attributes I suspect, rather than silently ignore them.
16:45:14 <s3wong> and for those that are not supported, the API call should fail
16:45:26 <s3wong> (the non-required ones, that is)
16:45:32 <thinrichs> mastery prasadv: I would imagine we'd want more transparency than just "tried to add a policy statement and got an error".
16:45:57 <sc68cal> Have we decided on the minimum requirements for qos policies that each plugin must support?
16:46:00 <thinrichs> I would think Heat would want to know which policy fragment the plugin supports and then utilize that policy fragment.
16:46:02 <prasadv> instead of failing when called, wouldnt it better that user know that it does not implement and hence in UI or something it get blanked out
16:46:33 <s3wong> sc68cal: we have not. The writing at this point is to translate directly into DSCP marking
16:46:37 <mestery> prasadv thinrichs: I didn't mean to get into specifics of the failure case, just that if a plugin doesn't support things, it has to fail and somehow alert the user.
16:47:03 <sc68cal> s3wong: OK, i'll add a comment to the doc highlighting another use case
16:47:12 <michsmit> wouldn't multiple plugins be possible ?  and each may deal with only part of the policy ?
16:47:16 <s3wong> sc68cal: certainly
16:47:40 <banix> So i think the question is if the extension can be asked what it supports. Is there a mechanism for that used by other extensions?
16:47:43 <prasadv> mestery: my point is that there could be a query where one would return what types it supports.
16:47:43 <s3wong> michsmit: that sounds complicated...
16:48:04 <s3wong> michsmit: who is going to do the coordination and dispatch?
16:48:19 <mestery> michsmit: I could see that if we're talking ML2, which uses an L3 service plugin, and part of this is handled by the L2 MechanismDriver and part by the L3 ServicePlugin.
16:48:28 <thinrichs> prasadv: I think your suggestion is necessary as well.
16:48:32 <mestery> michsmit: But that would only apply in an ML2/ML3 world I thnk.
16:49:12 <banix> mastery michsmit: yes. In the new world order: ML2 only :)
16:49:23 <michsmit> mestery:  exactly. I was assuming an ML2 world
16:49:48 <mestery> OK, so we have 10 minutes left, I'd like to discuss some next steps for the coming week now.
16:49:59 <mestery> #topic Next Steps For the Next Meeting
16:50:05 <ywu> mestery: is networking policy and ML2 are mutual exclusive?
16:50:05 * mestery likes that topic title for some reason.
16:50:16 <mestery> ymu: No, they are not.
16:50:23 <mestery> OK, so we have a bunch of action items for next week.
16:50:42 <mestery> I think we as a team should really strive to come to agreement on the document now as much as possible in the next 2 weeks.
16:50:52 <s3wong> mesteryL though we may want to avoid making group-policy exclusively work with ML2
16:51:06 <mestery> s3wong: Completely agree, this is not ML2 specific.
16:51:22 <mestery> So to that end, lets please iterate over the Google Document this week.
16:51:23 <banix> mestery: agreed. Lets flash out the difference and address them as soon as we can
16:51:40 <s3wong> before Chirstmas :-) I see what you guys did there :-)
16:51:50 <mestery> If something isn't clear, please start a thread on the openstack-dev ML using tags "[neutron] [policy]"
16:51:57 <mestery> s3wong: :)
16:52:08 <mestery> Sound like a plan for the next week?
16:52:15 <banix> yes
16:52:17 <s3wong> sure
16:52:25 <thinrichs> Yep
16:52:26 <mestery> Perfect!
16:52:45 <mestery> OK, thanks to everyone for attending today!
16:52:51 <mestery> I need to drop out of this a bit early, so will end the meeting now.
16:52:59 <banix> Thank you.
16:53:00 <s3wong> Thanks!
16:53:03 <mestery> Lets iterate on the ML, Google Doc, and #openstack-neutron if needed as well.
16:53:06 <prasadv> thanks
16:53:07 <ywu> Thanks!
16:53:08 <mestery> See you all next week!
16:53:09 <mestery> #endmeeting