16:01:09 #startmeeting networking_policy 16:01:10 Meeting started Thu Nov 21 16:01:09 2013 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:13 The meeting name has been set to 'networking_policy' 16:01:29 #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Agenda 16:01:43 Anyone besides banix and myself? 16:02:46 alagalah: Welcome! 16:02:57 mestery: Thank you sir 16:02:59 michsmit: yo 16:03:15 For those who missed it earlier: Agenda is here (https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy) 16:04:07 #link https://etherpad.openstack.org/p/NeutronIcehouseProjectPlan Neutron Icehouse Project Plan 16:04:19 I wanted to mention the Project Plan for Neutron in Icehouse first. 16:04:39 Per the Neutron IRC meeting on Monday, the policy work we're doing here is unlikely to make it into Icehouse. 16:04:53 But we should continue exploring it and prototyping it to make sure it gets into "J" release. 16:05:04 Any questions on that? 16:05:16 Yeah let's push the ball forward 16:05:33 banix: Agreed. And we should certainly shoot to get some WIP type patches out for review at some point as well. 16:06:04 #link https://wiki.openstack.org/wiki/Icehouse_Release_Schedule Icehouse Release Schedule (for reference) 16:06:10 Not the Icehouse dates there, for reference. 16:06:25 #topic Group Based Policy Discussion 16:07:05 So, what I'd like to start doing here is to make sure we all are in agreement around the high level constructs and terms. 16:07:17 That will make it easier to move forward in discussions and implementation. 16:08:03 #link https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing Group Policy Document 16:08:15 I encourage people to comment in the document as well as on the openstack-dev mailing list. 16:08:26 Questions on that? 16:08:48 I brought this up on the mailing list---I'd like to discuss whether there are plans to include a concrete policy language (or several). 16:09:47 thinrichs2: There are currently no plans at the moment, partially because of how high level the proposal currently is. 16:09:53 Perhaps it can evolve in this direction though. 16:10:13 I ask mainly because I'm trying to figure out how another OS component would use this API. 16:10:45 For example, if I were writing Heat, if I don't know what policy language to use, I can't figure out which API calls to make. 16:11:15 I think getting the constructs into the current model would come first and then a policy language could potentially be layered on top later. 16:11:15 I would know that I need to insert policy/group statements, but I wouldn't know which ones.--unless I knew which plugin we were using for Neutron. 16:11:19 Or am I missing something? 16:11:57 thinrichs2: how is this done in Heat now for other resources? 16:12:11 thinrichs2: I think the constructs would dictate what an API user could do, as michsmit is leading to. 16:12:15 Isn't the resource specified and the corresponding API called for it? 16:12:22 Heat knows what routers/switches/etc are, and uses them appropriately. 16:13:01 Banix: But this is different in that the API basically allows us to pass arbitrary strings (policy statements), and we don't know what strings are even syntactically valid, let alone what they mean. 16:13:38 The thought experiment I did was to assume I was trying to build a super-simple version of Heat where I only accepted app templates with a DB tier and a web tier. 16:13:51 So the template just said how many DB servers and how many Web servers we want. 16:14:29 I then need to write a function that takes as arguments number-of-db-servers and number-of-web-servers and outputs a sequence of neutron API policy calls that implements that app. 16:14:38 The policy should describe desired connectivity abstracted from topology i.e. group A can talk to group B using Web 16:14:42 But I can't write that down *unless* I know the policy language. 16:15:08 Does any of that make sense? 16:15:34 So to make it easier to begin with, let us assume someone will create the Heat template 16:16:04 The "language" could be fairly simple at first. L4 protocol and ports 16:16:12 L4 port that is 16:16:24 Resources are defined based on what Neutron objects are 16:18:43 I think based on this discussion it's clear we should flesh out the objects and attributes we're talking about a bit more. 16:18:47 banix: Agree, I would expect the more topology specific constructs to not be described in the policy such as network but rendered by the extension. 16:18:49 Any volunteers to do that in the Google doc? 16:18:51 I agree we could invent a bunch of different languages to do this. Each plugin, for example, could have its own language. But therein lies the problem. We don't want Heat to have to know which plugin is being used in order to use the policy API. 16:19:25 mestery: I can get it started 16:19:32 banix: Thanks! 16:19:33 For the policy API to be useful, we should be able to write the following function today, and that function should work for every plugin. 16:19:42 mestery: I can help as well 16:20:06 #action banix and michsmit to flesh out the objects and attributes we want to expose in more detail in the design document 16:20:10 void create_simple_app(int db-server-num, int web-server-num) { ... } 16:20:49 I'm happy to help as well. But I'm sure I understand what constructs we're talking about. 16:20:54 thinrichs2: I think the idea is to specify the desired connectivity, but let the plugins handle how that connectivity is achieved (michsmit correct me if I'm wrong here). 16:21:03 thinrich2: I think this where we want to get to but we are not there yet 16:21:14 thinrichs2: that abstraction seems to be more than what Neutron can handle, right? Nova has to be involved as well? 16:21:26 thinrhcs2: Great! DM me your gmail and I can add you to the google doc. 16:21:35 s3wong: Correct--but we *should* be able to write the Neutron API calls today. 16:21:47 mestery: I would like to be added to that Google Doc as well 16:21:49 What you are suggesting is perhaps done in an enhanced version of Heat engine or on something on top of it that produces appropriate Heat templates 16:21:56 thinrichs@nicira.com 16:22:09 s3wong: Sure, DM me your google ID so I can add you as well. 16:22:20 mestery: My email address is s3wong@midokura.com 16:22:28 But I'm still a bit unsure what we're proposing to put into the google doc. 16:22:54 Are we talking about a full language (grammar + semantics)? 16:23:54 Not a full language, but the actual objects/resources we're talking about adding for the extension API, along with attributes. 16:24:01 I think the Google doc should focus on what needs to be described so that the extension plugin would have enough information to render the existing Neutron objects 16:24:21 thinrich2: no, we were talking about Neutron object model here. 16:24:21 but yet be independent of network topology 16:24:50 If we only talk about the objects, we still aren't giving enough information to actually use the API. 16:25:16 Suppose I want to add a policy statement. I don't know which strings are syntactically valid to pass into that API call. 16:25:37 So if you look at the current doc, we are saying we will have these new objects, we want to specify them more precisely to begin with 16:27:08 Anyway--hope my position is clear at this point. I think that before we start talking about implementing the proposal, we need to hammer out a concrete policy language (that could be extended, etc.) 16:27:48 I'm happy to move onto other topics. 16:28:17 Well, this is pretty much the only topic for today per the agenda. :) 16:28:21 I think we are looking at this from different angles which is perfectly fine; thinrichs2, could you say a bit more, may be later on the dev list …. 16:28:50 Policy implies rules - wouldn't defining better rules premitives for Neutron be a pre-requisite? 16:29:02 I'm happy to write the example up and send to the dev list. 16:29:14 s3wong: could you elaborate? 16:29:28 thinrichs2: thanks 16:29:46 Policy is a set of rules, rules would be {classifier/match -> set of actions} 16:30:44 s3wong: agree, that's what we need to define too. At least start with a set of possible rules, or types of rules 16:31:01 banix: absolutely 16:31:22 banix: agreed. With the current proposal, it's impossible to write down 1 valid API call (and know it's valid for all plugins). 16:32:10 banix s3wong: Are you volunteering to define the initial rules? 16:32:11 Excuse my naivety, but if the end game is to make this a part of core Neutron, with Step1 being a plugin, does it make sense to create any missing Neutron primitives in the plugin first since they'll be rolled in eventually anyway? 16:32:35 alagalah: Not a plugin, an API extension at first, implemented in ML2 as the open source reference implementation. 16:32:40 mestery: certainly, I would love to 16:32:49 s3wong: Cool, thanks! 16:32:54 dont we have to define other APIs too such as connectivity group? What goes into the group? 16:33:09 mestery: yes sure 16:33:19 mestery: Sorry, I misread the paragraph in the doc on OpenSrouce Reference Implementation. 16:33:38 alagalah: No worries. 16:34:59 prasad_: yes, the group would contain the endpoints i.e. entities that source/sink traffic on the network 16:35:06 prasad_: yes, that is part of the extension. that's what we want to define more precisely. 16:35:18 #action banix and s3wong to make first pass at defining initial rules. 16:35:41 Could someone explain why we wouldn't want to define groups as part of the policy? Just curious. 16:35:57 the question is how are end points defined? VMs, IP addresses? 16:36:09 Groups are a fundamental primitive that could be used in higher layer policy languages 16:36:33 prasad_: 16:37:06 prasad_: yes, may be ports, as a first step 16:37:07 prasad_: vnic, ip address as well for external subnets 16:37:28 dont they have to be precise just like rule definition discussed above. Else it will again be pllugin dependent isnt it? 16:38:06 I think it's a safe assumption to assume that if we make any of this plugin dependent we've failed. 16:38:06 I only ask b/c often we end up defining groups implicitly within the policy itself. 16:38:19 mestery: agreed 16:38:29 The entire goal of this is to abstract things at a higher level, by exposing plugin primitives this doesn't by us anything. 16:38:42 Look at the current state of Neutron extension APIs per-plugin to get an idea of why this is a bad idea. 16:39:05 Cloud management vendors need to understand which plugin is running in Neutron before they can appropriately use Neutron, which is bad IMHO. 16:39:16 So these new APIs need to abstract that away and simplify that state of affairs. 16:39:57 what happens whrn the Plugin can't support a given policy? 16:40:11 quit 16:40:53 uri__: I would imagine we have a core policy language that *every* plugin must support, with extensions to the language that plugins can choose to support or not. 16:41:06 Sort of like the API and its extensions. 16:41:17 thinrichs2: I partially agree, although the extensions idea is a slippery slope. 16:41:28 The policy should express the intent of the connectivity independent of the low level networking details. This should allow the plugin some freedom in making it happen, but at some point if the intent cannot be realized, it would fail the call. 16:41:33 so the "bsic" set maybe a good starting point 16:41:38 It all comes down to the API user an the choices they make. 16:42:12 michsmit: agree, if a policy is not supported by a particular plugin, logically it should return error 16:43:03 mestery: I'm certainly happy to have a language w/o extensions. But extensions are something to keep in the back of our minds, if we find we need them. 16:43:24 thinrichs2: Realistically, I agree. 16:44:10 and in the first version, we assume all policies implemented by ONE plugin? any way for few Plugin to implement each a share? Will ML2 for example divide it up among its mechanism drivers? 16:45:17 uri__: These APIs will work similar to how the existing APIs work in ML2. 16:45:44 Well, I suppose if there are multiple segments in a network, the policy implementation may lead to different mechanism drivers. 16:46:02 For example, if a single MechanismDriver fails a create call, ML2 will roll things back and clean up the ones which succeeded prior. 16:47:06 mestery: so i'm not sure how ML2 will guarantee to teh User all policy has been implemented. i hope in the opensource we see how this happens and how policies are handled by more than one Mech Driver 16:47:49 uri__: It can guarantee success by the fact that each MechanismDriver returned success when it was called. 16:48:49 mestery: uri_: and I think that is necessary, otherwise if the policy is only applied partially, it would be a messy state 16:49:24 Yes, agreed. 16:49:37 OK, so we have about 10 minutes left, and I recored two action items so far. 16:49:52 Is there anything else we should focus on this week? 16:49:59 With regards to action items for future meetings 16:50:00 ? 16:50:48 The next meeting will be in two weeks. Right? 16:50:57 do we have timelines for the actions ? 16:51:04 are the api definition discussions going to take place on the mailing lists? 16:51:04 Thanksgiving next Thursday :-) 16:51:08 banix: I was going to get to that, hold on. :) 16:51:09 mestery: I'm sure you and I will talk before then.... 16:51:40 #info No meeting next week (11-28-2013) due to Thanksgiving holiday in the US. 16:51:56 michsmit: The action items will show up in the meeting logs, and I'll add them to the wiki page. 16:52:01 We'll cover those first at our next meeting. 16:52:22 prasad_: Mailing list and Google doc. If you want on that, please DM me your google ID so I can add you. 16:53:51 mestery_: prasad.vellanki@oneconvergence.com 16:53:56 Thanks prasad_ 16:54:05 OK, thanks everyone for joining the first Neutron Group Policy meeting! 16:54:13 mestery: thank you 16:54:14 Looking forward to continuing to make progress with everyone! 16:54:17 #endmeeting