16:00:36 <mestery> #startmeeting networking_policy
16:00:37 <openstack> Meeting started Thu Jan  9 16:00:36 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:40 <openstack> The meeting name has been set to 'networking_policy'
16:00:41 <mestery> Hi banix thinrichs
16:00:54 <mestery> #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Agenda
16:01:13 <mestery> So, we have a light agenda for today I believe, which will leave lots of time for questions/comments at the end. :)
16:01:28 <mestery> #topic PoC Discussion and Planning
16:01:45 <mestery> So, banix and I had an AI to start writing this up, which we've done.
16:01:59 <mestery> It's in very early stages, but covers the high level points banix s3wong and myself have been discussing this week.
16:02:13 <mestery> #link https://docs.google.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/edit?usp=sharing Group Policy PoC document
16:02:20 <alagalah> Morning
16:02:20 <mestery> s3wong: Hi!
16:02:24 <s3wong> Hello
16:02:25 <mestery> alagalah: Morning!
16:02:30 <alagalah> mestery:  hi
16:02:43 <mestery> So, for those who just joined, were discussing the PoC document now, which is in it's early stages.
16:02:52 <mestery> https://docs.google.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/edit?usp=sharing <--- Link to PoC document (also on Meeting page)
16:03:18 <nam_nguyen> Hi, I'm new here and listening first.
16:03:20 <mestery> banix s3wong and myself will finish fleshing this out the rest of this week.
16:03:31 <mestery> nam_nguyen: Welcome to the team!
16:03:35 <banix> welkome Nam
16:04:02 <songole> Hi all
16:04:03 <banix> I should introduce Nam, as one of my colleagues who will be joint us
16:04:03 <mestery> banix s3wong: Anything to add on PoC at this time?
16:04:13 <banix> joining us that is
16:04:18 <mestery> banix: Cool, glad to have more people joining the team!
16:04:21 <alagalah> nam_nguyen:  welcome
16:04:31 <s3wong> name_nguyen: welcome to the team!
16:04:32 <nam_nguyen> thx!
16:04:32 <FlorianOtel> alagalah, mestery Hello boys
16:04:41 <FlorianOtel> and all :)
16:04:45 <mestery> FlorianOtel: Great to see you here my friend. :)
16:04:49 <prasadv> hi this is prasad
16:04:50 <banix> mestery: No, I think the main issue is how we go about starting the work
16:04:58 <alagalah> prasadv:  hi
16:05:02 <mestery> banix: I agree. :)
16:05:08 <FlorianOtel> is this on IRC only, or you guys on hangout / smth else as well ?
16:05:11 <mestery> prasadv: Good morning!
16:05:23 <mestery> FlorianOtel: IRC only, we're not as advanced as the ODL stuff. ;)
16:05:25 * mestery ducks.
16:05:36 <FlorianOtel> ha ;)
16:06:08 <s3wong> mestery: the document captures in the high level what we need to do now
16:06:39 <s3wong> though once this is done we would like to test it against a use case, such as three-tier app using Heat template
16:06:46 <alagalah> Are we planning on assigning each of the 4 bullets out, do like a mini lead per bullet with teams?
16:07:03 <mestery> s3wong: Lets add the use case to the document, sound good?
16:07:33 <mestery> alagalah: We haven't decided on the division of labor yet, but if you want to help, that would be great!
16:07:40 <banix> s3wong: we need to also think about what we need to do on the Heat side; I presume it will be minimal at least to start with
16:07:44 <alagalah> mestery:  yes I do
16:07:53 <thinrichs> I'm not super familiar with ML2.  I have a question or two about the plans.
16:07:55 <prasadv> we internally built a heat template based on the discussions so far
16:08:05 <mestery> thinrichs: Shoot!
16:08:18 <mestery> prasadv: Awesome! We'll lean on you folks for that portion. Sound good banix?
16:08:23 <s3wong> mestery: banix: sure
16:08:23 <banix> prasadv: great; share when/if you can
16:08:38 <thinrichs> For the allow/drop case, I see how we can implement the policy via OVS.  But when we start getting to QOS, or some of the other actions, how will that work?
16:08:39 <prasadv> ok will do. we can put it into poc document
16:08:40 <banix> mestery: agree
16:09:03 <thinrichs> Do we only select actions that are implementable in OVS?
16:09:11 <s3wong> prasadv: wow, that is great!
16:09:32 <mestery> thinrichs: For QoS in particular, we need to work with scal68 (Sean Collins) who is doing QoS support for ML2+OVS.
16:10:44 <alagalah> mestery:  et al ... sorry , silly question but is OVS the initial use case with this to be extensible to other platforms later? Or limited? That will change the decisions
16:11:13 <thinrichs> alagalah: maybe I'm wondering the same kind of thing.
16:11:15 <banix> initial PoC
16:11:26 <s3wong> alagalah: ovs is selected as initial PoC ref. impl.
16:11:30 <mestery> Similar to how the existing Neutron APIs work in ML2, we'll want to make these new extension APIs work the same.
16:11:47 <alagalah> I think its ok to limit actions to OVS supported functions but to push features to rely on OVS would mean they would have to be written back in for other platforms
16:11:47 <mestery> e.g. if you look, they have pre/post methods for both so DB transactions are done in one place.
16:11:47 <banix> alagalah: thinrichs: Just a PoC; would like to see it used by others
16:12:30 <alagalah> mestery:  thanks, that helps... so it will be more extensible that way
16:12:48 <thinrichs> What if we don't actually have OVS underneath the hood, and instead we are using something that doesn't support QOS?  Is the policy just not enforceable?
16:13:11 <s3wong> alagalah: yes - even the APIs and optional action types will be expanded in the future, I am sure
16:13:17 <mestery> thinrichs: I think we decided that each MechanismDriver can fail the calls, similar to how it works today in ML2 for existing API calls.
16:13:42 <alagalah> thinrichs:  That was my understanding. Thanks mestery
16:13:47 <banix> thinrichs: depends on the mechanism driver; can "not" support
16:13:50 <alagalah> s3wong:  thanks
16:14:06 <thinrichs> And I'm not concerned so much about the PoC--it's that we're defining the language to have actions that are known to not be supported for some technology.
16:14:44 <thinrichs> But I suppose that some underlying architectures can simply render some policies unenforceable and so the users ought to know not to write those policies.  Is that right?
16:14:48 <s3wong> thinrichs: ha - we talked about that. We will add an API for users to query a set of action capabilities that is supported by a particular plugin
16:15:10 <alagalah> That was my understanding s3wong
16:15:18 * mestery nods in agreement.
16:15:24 <thinrichs> s3wong: but do we expect Heat to utilize that API before writing policy statements?
16:15:28 <banix> thinrichs: for QoS we haven't really worked out specifics; can discuss in parallel
16:15:53 <thinrichs> banix: the details of QoS aren't so important--it's just an example of something that isn't so easy to implement.
16:15:55 <s3wong> thinrichs: interesting question - how dynamic can a Heat template be?
16:15:56 <banix> I think we want the infrastructure setup first
16:16:13 <prasadv> thinrichs: Heat can call and do validation of a template if there is such a call
16:16:27 <thinrichs> Would Heat change the templates it accepts based on whether or not Neutron accepts Qos policies?
16:16:28 <s3wong> prasadv: Thank You!
16:16:29 <prasadv> wherein the plugin cannot support
16:17:40 <thinrichs> So before Heat (or whatever) even generates a UI to accept a template, it calls out to Neutron to figure out what policies it accepts and then customizes the UI so the user doesn't specify things that aren't implementable?
16:17:48 <prasadv> thinrichs: Instead of changing templates, wouldnt it be better to return error
16:18:05 * alagalah nods
16:18:07 <banix> I think Heat as is today won't change things dynamically
16:18:15 <prasadv> thinrichs:THat was original thought to have an query api
16:18:25 <alagalah> I think the application should re-request
16:18:25 <thinrichs> prasadv: But suppose the user spends a bunch of time writing a template, and then just gets an error in response?  Wouldn't that irritate her?
16:18:29 <alagalah> Send back an error
16:18:47 <banix> There is talk of extending Heat to do a lot more but as is it simply tries to create resources specified in template through calls to underlying services
16:19:00 <s3wong> thinrichs: the user should then consider having a different plugin
16:19:22 <alagalah> Well we talked about an API to query capabilities, so they should use that to make a template and if a template comes in that cant be fulfilled, we should return error
16:19:29 <thinrichs> s3wong: the user here doesn't get to change how the cloud is set up--they're just describing an app template.
16:19:38 <mestery> s3wong: In the case of a public cloud, the user doesn't have control over the plugins.
16:20:00 <prasadv> thinrichs: I think plugin can also document what it supports right? though this requires the person to know which plugin is being used.
16:20:16 <s3wong> in that case, it is up to the cloud provider to publish what it can support
16:20:26 <ashaikh> thinrichs: i don't think there is an expectation today that every template would just work -- e.g., the public cloud would make clear what it can/can't do
16:21:12 <thinrichs> s3wong/ashaikh: but there must be UIs for creating templates, right?  So suppose the UI tells you you've got 10 different actions you can use but in actuality, there is only allow/drop.
16:21:34 <alagalah> thinrichs:  Teh capability API should handle that shouldn't it ?
16:21:47 <alagalah> A UI should use that shouldn't it ? Or am I missing something ?
16:22:34 <mestery> thinrichs: Would it really be hard for the UI to query the plugin and ghost out which ones aren't supported by the underlying plugin?
16:23:20 <thinrichs> Maybe I'm wondering whether the right interface for Heat is to just say "and give me a policy using actions 1,2,3,4".
16:23:26 <s3wong> thinrichs: can you apply a Heat template in Horizon today? If so, if there is something within the Heat template that is not supported, would an error show up on Horizon?
16:24:02 <mestery> thinrichs: Since there is no requirement to use cinder, for example, what if cinder isn't running and the user tries to create volumes in a Heat template? What happens in that case now?
16:24:15 <mestery> Because there is no "official" definition of what OpenStack is.
16:24:16 <songole> s3wong: it does. stack creation fails
16:24:17 <thinrichs> I'm wondering if we would want to hide the details of the actions within higher-level concepts, and those concepts would be hard to define if the set of available actions were different for each plugin.
16:24:26 <mestery> I think we're solving a problem which is not just related to policy actions IMHO.
16:24:29 <mestery> OR rather, trying to solve.
16:24:41 <banix> As prasadv shares with us what they have done on the Heat front, we can discuss further
16:25:12 <s3wong> songole: Thanks! so for thinrichs: it would just fails as you apply the template from get-go
16:25:17 <thinrichs> Maybe this is all okay.  I'll think more and see if anything pops to mind.
16:25:28 <mestery> thinrichs banix: Sounds good.
16:25:30 <banix> mestery: agree. For now the Heat extension for us would be simply capable of creating newly defined Neutron objects
16:25:38 <mestery> But good to bring these points up thinrichs!
16:25:40 <prasadv> i agree with mestery. Policy is provding a query api and that help it quite a bit
16:25:54 * alagalah agrees with mestery
16:26:40 <s3wong> prasadv: Good to have you here to give us actual API consumer to come up with the required APIs
16:26:43 <mestery> OK, anything else related to the PoC to discuss right now?
16:26:48 <mestery> Let me assign a few actions:
16:26:56 <mestery> #action prasadv to add heat details to the PoC document
16:27:01 <s3wong> mestery: so who is doing what?
16:27:17 <mestery> #action mestery s3wong banix to flesh out more details in the document and assign tasks to interested parties
16:27:22 <mestery> s3wong: Just added that. :)
16:27:30 <s3wong> mestery: cool :-)
16:27:51 <mestery> If nothing else on PoC, I'll move the topic to Open Discussion in a minute.
16:27:59 <banix> Sounds good
16:28:09 <s3wong> mestery: sure
16:28:34 <mestery> #topic Open Discussion
16:28:38 <alagalah> Hi guys, just a nit, but a change was made to the taxonomy document to reflect "1 or more" when it accurately reflected that with a "+" as per the key
16:28:43 <banix> I will cleanup the original design doc this week.
16:28:50 <mestery> alagalah: Thanks for the update!
16:28:55 <mestery> banix: Thank you!
16:29:01 <alagalah> For classifiers
16:29:03 <s3wong> alaglah: Thanks!
16:29:11 <alagalah> Well actually.....
16:29:23 <alagalah> The update made was wrong... it should be put back to a "+"
16:29:25 <banix> Won't make any changes as such just a cleanup.
16:29:44 <alagalah> Any objections to me changing it back?
16:30:28 <prasadv> I still have an issue with classifiers for cases like L2 firewall not including IP addresses
16:31:16 <mestery> prasadv: Dually noted, should we flesh that out during the PoC?
16:31:16 <prasadv> mismith had issues with including them last time. How should we resolve that
16:31:20 <alagalah> prasadv:  Mine was more a cosmetic thing. the taxonom originally had + between policy rule and classifiers which means "1 or more" and it was changed to "1" to reflect "1 or more"
16:31:26 <s3wong> prasadv: sure, that was never finalized
16:31:26 <mestery> michsmit: You here?
16:31:30 <michsmit> yes
16:31:41 <prasadv> i am fine with that. we can resolve during PoC
16:31:43 <mestery> michsmit: Hi. See prasadv comment ^^^^
16:31:51 <mestery> michsmit prasadv: OK, cool.
16:31:56 <michsmit> my assumption was that IP addresses would be limited to external networks
16:32:18 <s3wong> alagalah: there should only be one classifier per policy-rule, so the '1' looks good
16:32:25 <michsmit> meaning that policies between groups should avoid IP addresses if at all possible
16:32:26 <alagalah> Oh!
16:32:35 <alagalah> s3wong:  Thanks!
16:32:50 <alagalah> s3wong:  Is it 0 or 1 ???
16:33:04 <alagalah> s3wong:  In that case it should be a "?" as per the key
16:33:06 <s3wong> alagalah: has to be 1, can't be 0
16:33:07 <banix> michsmith: agree
16:33:18 <alagalah> In that case I apologize and I will leave it
16:33:28 <alagalah> Thank you all for the clarification
16:33:33 <s3wong> michsmith: agree - never a fan in adding IP address in classifier
16:33:38 <prasadv> michsmit: I want to see if L2 scenario can be supported with you are saying and get back on that
16:33:50 <mestery> prasadv: Sounds good!
16:33:52 <michsmit> prasadv: sure
16:34:12 <mestery> OK, anything else to discuss here?
16:34:29 <s3wong> wow, short meeting :-)
16:34:35 <mestery> Yay to short meetings!
16:34:48 <michsmit> +1 to that
16:34:50 * alagalah cheers
16:34:55 <prasadv> +1 to that
16:35:00 <banix> Thanks everyone
16:35:00 <thinrichs> +1
16:35:07 <mestery> OK, thanks everyone! Looking forward to seeing some PoC action now! :)
16:35:08 <s3wong> Thanks!
16:35:10 <mestery> #endmeeting