[openstack-dev] [Congress] Policy types

Tim Hinrichs thinrichs at vmware.com
Tue Mar 18 16:31:34 UTC 2014


Hi Prabhakar,

No IRC meeting this week.  Our IRC is every *other* week, and we had it last week.

Though there's been enough activity of late that maybe we should consider making it weekly.

I'll address the rest later.

Tim

----- Original Message -----
| From: "prabhakar Kudva" <nandavarpk at hotmail.com>
| To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
| Sent: Monday, March 17, 2014 7:45:53 PM
| Subject: Re: [openstack-dev] [Congress] Policy types
| 
| Hi Tim,
|  
| Definitely would like to learn more about the Data Integration component
| and how best to contribute. Can't find it in the latest git, perhaps we can
| discuss during the meeting tomorrow. Where can I find some code and/or
| document?
|  
| I like the idea of using an 'evauate' wrapper.  And the idea of a builtin
| library of functions.  Having strict rules for builtins and an evaluate
| wrapper
| to do type checking (primitive or builtin) and so on reduces the silent
| errors or weird outcomes.
|  
| I also agree, raw python using methods like 'calleable' (or other ways
| of checking if the function can be called in python) may not always give
| definitive answers. Even the definition of callable says, that a True only
| says that the object 'appears' calleable.
|  
| So silent and weird problems are possible if we try to execute. On the other
| hand,
| if we are looking at module which contains only user defined functions or
| builtine
| , i.e., there  are strict rules to what exactly constitute allowed-functions,
| then there
| is a higher likelihood that it is correct.  But still a likelihood.
|  
| I like the 'evaluate' idea which could do the checking within
| to make sure the function is indeed calleable, and silent and weird side
| effects
| are filtered inside the 'evaluate'. In addition, it can do checking if it is
| a  primitive or some other valid format. Needs more thought on this.
|  
| Let's discuss implementation paths if possible at the meeting. Would like to
| carve out a small implementation goal either in the 'data integration' line
| or
| the discussion above.
|  
| Prabhakar
|  
|  
|  
| 
|  
| > Date: Mon, 17 Mar 2014 08:57:05 -0700
| > From: thinrichs at vmware.com
| > To: openstack-dev at lists.openstack.org
| > Subject: Re: [openstack-dev] [Congress] Policy types
| > 
| > Hi Prabhakar,
| > 
| > One big piece we're missing in terms of code right now is the Data
| > Integration component.  The job of this component is to integrate data
| > sources available in the cloud so that tables like nova:virtual_machine,
| > neutron:owner, etc. reflect the information stored in Nova, Neutron, etc.
| > Rajdeep is making progress on that (he's got some code up on review that
| > we're iterating on), and Peter had worked on integrating AD a while back.
| > 
| > Typically I've seen the Python functions (which I usually call 'builtins')
| > integrated into a Datalog system have explicit declarations (e.g. inputs,
| > outputs, etc.).  This is good if we need to do deeper analysis of the
| > policy (which is one of the reasons to use a policy language) and
| > typically requires information about how that builtin works.
| > 
| > I dug through some old (Lisp) code to see how I've done this in the past.
| > 
| > // (defbuiltin <datalog-name> <lisp-function> <list of types of args> <list
| > of types of returns> [<internal>])
| > (defbuiltin plus + (integer integer) integer)
| > (defbuiltin minus - (integer integer) integer)
| > (defbuiltin times * (integer integer) integer)
| > (defbuiltin div (lambda (x y) (floor (/ x y))) (integer integer) integer)
| > (defbuiltin lt numlessp (integer integer) nil)
| > (defbuiltin lte numleqp (integer integer) nil)
| > (defbuiltin gte numgeqp (integer integer) nil)
| > (defbuiltin gt numgreaterp (integer integer) nil)
| > 
| > But maybe you're right in that we could do away with these explicit
| > declarations and just assume that everything that (i) is calleable, (ii)
| > not managed by the Data Integration component, and (iii) does not appear
| > in the head of a rule is a builtin.  My only worry is that I could imagine
| > silent and weird problems showing up, e.g. someone forgot to define a
| > table with rules and there happens to be a function in Python by that
| > name.  Or someone supplies the wrong number of arguments, and we just get
| > an error from Python, which we'd have no direct way to communicate to the
| > policy-writer, i.e. there's no compile-time argument-length checking.
| > 
| > The other thing I've seen done is to have a single builtin 'evaluate' that
| > lets us call an arbitrary Python function, e.g.
| > 
| > p(x, y) :- q(x), evaluate(mypyfunc(x), y)
| > 
| > Then we wouldn't need to declare the functions.  Errors would still be
| > silent.  But it would be clear whether we were using a Python function or
| > not.
| > 
| > Thoughts?
| > Tim
| > 
| > 
| > 
| > 
| > ----- Original Message -----
| > | From: "prabhakar Kudva" <nandavarpk at hotmail.com>
| > | To: "OpenStack Development Mailing List (not for usage questions)"
| > | <openstack-dev at lists.openstack.org>
| > | Sent: Saturday, March 15, 2014 8:28:27 PM
| > | Subject: Re: [openstack-dev] [Congress] Policy types
| > | 
| > | 
| > | 
| > | Hi Tim,
| > | 
| > | Here is a small change I wanted to try in runtime.py
| > | It may already exist in MaterializedViewTheory, but wasn't clear to
| > | me.
| > | Checking to see if this is something that:1. makes sense 2. already
| > | exists
| > | 3. worth implementing? in that order.
| > | 
| > | Let's take the example from private_public_network.classify
| > | 
| > | error(vm) :- nova:virtual_machine(vm), nova:network(vm, network),
| > | not neutron:public_network(network),
| > | neutron:owner(network, netowner), nova:owner(vm, vmowner), not
| > | same_group(netowner, vmowner)
| > | 
| > | same_group(user1, user2) :- cms:group(user1, group), cms:group(user2,
| > | group)
| > | 
| > | nova:virtual_machine("vm1")
| > | nova:virtual_machine("vm2")
| > | nova:virtual_machine("vm3")
| > | nova:network("vm1", "net_private")
| > | nova:network("vm2", "net_public")
| > | neutron:public_network("net_public")
| > | nova:owner("vm1", "tim")
| > | nova:owner("vm2", "pete")
| > | nova:owner("vm3", "pierre")
| > | neutron:owner("net_private", "martin")
| > | 
| > | 
| > | In this example, if as in Scenario 1:
| > | 
| > | Cloud services at our disposal:
| > | nova:virtual_machine(vm)
| > | nova:network(vm, network)
| > | nova:owner(vm, owner)
| > | neutron:public_network(network)
| > | neutron:owner(network, owner)
| > | cms:group(user, group)
| > | 
| > | are all python functions called through some nova/neutron api,
| > | then, we just execute them to get a true/false value in runtime.py
| > | They should be first checked to make sure they are python functions
| > | and
| > | not condition primitives using 'callable' and os.dir or some such
| > | combination.
| > | 
| > | If not, and they are assertions made in the file, not directly
| > | related to OS
| > | state, then in Scenario 2
| > | 
| > | nova:owner("vm1", "tim")
| > | nova:owner("vm2", "pete")
| > | nova:owner("vm3", "pierre")
| > | 
| > | Are assertions made in the file. In a dynamic environment,
| > | a python function could query an OS client to actually find the
| > | current owner,
| > | since some other OS command could have been used to change the owner
| > | without an entry being made in this file, i.e., without explicitly
| > | informing Congres.
| > | This may not occur currently with vms, but may be implemented
| > | in a future release. Similar other examples are possible
| > | https://urldefense.proofpoint.com/v1/url?u=https://ask.openstack.org/en/question/5582/how-to-change-ownership-between-tenants-of-volume/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=6da252434cf8f03e99ab04dcc042d3eb646b7c4ea0390b9d0b96f04534d05574
| > | https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/cinder/%2Bspec/volume-transfer&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=dd07239a911392850af6d2ea72ecce3ea39997c1c93c7f235868a4919144296e
| > | 
| > | 
| > | So, I was thinking that python_nova_owner("vm1"), is first checked as
| > | a python
| > | function which calls the appropriate OS client to check the current
| > | owner.
| > | As in nova:owner("vm1", python_nova_owner("vm1"))
| > | 
| > | So, in runtime.py, in either scenario, condition primitives are first
| > | checked to
| > | see if it they are callable
| > | python functions (by using python 'callable' with os.dir). In which
| > | case, it is
| > | executed to get the name of the owner. All non-callable primitives
| > | are assumed
| > | assumed to be congress and/or datalog primitives, and unified through
| > | the
| > | Materializedviewtheory.
| > | 
| > | 
| > | Thanks,
| > | 
| > | 
| > | > Date: Thu, 13 Mar 2014 08:55:24 -0700
| > | > From: thinrichs at vmware.com
| > | > To: openstack-dev at lists.openstack.org
| > | > Subject: Re: [openstack-dev] [Congress] Policy types
| > | > 
| > | > Hi Prabhakar,
| > | > 
| > | > I'm not sure the functionality is split between 'policy' and
| > | > 'server' as cleanly as you describe.
| > | > 
| > | > The 'policy' directory contains the Policy Engine. At its core, the
| > | > policy engine has a generic Datalog implementation that could
| > | > feasibly be used by other OS components. (I don't want to think
| > | > about pulling it out into Oslo though. There are just too many
| > | > other things going on and no demand yet.) But there are also
| > | > Congress-specific things in that directory, e.g. the class Runtime
| > | > in policy/runtime.py will be the one that we hook up external API
| > | > calls to.
| > | > 
| > | > The 'server' directory contains the code for the API web server
| > | > that calls into the Runtime class.
| > | > 
| > | > So if you're digging through code, I'd suggest focusing on the
| > | > 'policy' directory and looking at compile.py (responsible for
| > | > converting Datalog rules written as strings into an internal
| > | > representation) and runtime.py (responsible for everything else).
| > | > The docs I mentioned in the IRC should have a decent explanation
| > | > of the functions in Runtime that the API web server will hook
| > | > into.
| > | > 
| > | > Be warned though that unless someone raises some serious objections
| > | > to the proposal that started this thread, we'll be removing some
| > | > of the more complicated functions from Runtime. The compile.py
| > | > code won't change (much). All of the 3 new theories will be
| > | > instances of MaterializedViewTheory. That's also the code that
| > | > must change to add in the Python functions we talked about (more
| > | > specifically see MaterializedViewTheory::propagate_rule(), which
| > | > calls TopDownTheory::top_down_evaluation(), which is what will
| > | > need modification).
| > | > 
| > | > Tim
| > | > 
| > | > 
| > | > 
| > | > 
| > | > ----- Original Message -----
| > | > | From: "prabhakar Kudva" <nandavarpk at hotmail.com>
| > | > | To: "OpenStack Development Mailing List (not for usage
| > | > | questions)" <openstack-dev at lists.openstack.org>
| > | > | Sent: Wednesday, March 12, 2014 1:38:55 PM
| > | > | Subject: Re: [openstack-dev] [Congress] Policy types
| > | > | 
| > | > | 
| > | > | 
| > | > | 
| > | > | Hi Tim,
| > | > | 
| > | > | Thanks for your comments.
| > | > | Would be happy to contribute to the propsal and code.
| > | > | 
| > | > | The existing code already reflects the thoughts below, and got me
| > | > | in the line of ideas. Please orrect me if I am wrong as I am
| > | > | learning with these discussions:
| > | > | 
| > | > | One part (reflected by code in "policy" directory is the generic
| > | > | "condition-> action engine" which could take logic primitives and
| > | > | (in the future) python functions, evaluate the conditions and
| > | > | execute the action. This portable core engine be used for any
| > | > | kind of
| > | > | policy enforcement
| > | > | (as by other OS projects), such as for data center monitoring and
| > | > | repair,
| > | > | service level enforcement, compliance policies, optimization
| > | > | (energy,
| > | > | performance) etc... at any level of the stack. This core engine
| > | > | seems
| > | > | possibly
| > | > | a combination of logic reasoning/unification and python function
| > | > | evaluation, and python code actions.
| > | > | 
| > | > | Second part (reflected by code in "server") are the applications
| > | > | for various purposes. These could be project specific, task
| > | > | specific.
| > | > | We could add a diverse set of examples. The example I have worked
| > | > | with seems closer to compliance (as in net owner, vm owner
| > | > | check),
| > | > | and we will add more.
| > | > | 
| > | > | Prabhakar
| > | > | 
| > | > | 
| > | > | 
| > | > | Date: Wed, 12 Mar 2014 12:33:35 -0700
| > | > | From: thinrichs at vmware.com
| > | > | To: openstack-dev at lists.openstack.org
| > | > | Subject: Re: [openstack-dev] [Congress] Policy types
| > | > | 
| > | > | 
| > | > | 
| > | > | Hi Prabhakar,
| > | > | 
| > | > | 
| > | > | Thanks for the feedback. I'd be interested to hear what other
| > | > | policy
| > | > | types you have in mind.
| > | > | 
| > | > | 
| > | > | To answer your questions...
| > | > | 
| > | > | 
| > | > | We're planning on extending our policy language in such a way
| > | > | that
| > | > | you can use Python functions as conditions ("<atom>" in the
| > | > | grammar)
| > | > | in rules. That's on my todo-list but didn't mention it yesterday
| > | > | as
| > | > | we were short on time. There will be some syntactic restrictions
| > | > | so
| > | > | that we can properly execute those Python functions (i.e. we need
| > | > | to
| > | > | always be able to compute the inputs to the function). I had
| > | > | thought
| > | > | it was just an implementation detail I hadn't gotten around to
| > | > | (all
| > | > | Datalog implementations I've seen have such things), but it
| > | > | sounds
| > | > | like it's worth writing up a proposal and sending it around
| > | > | before
| > | > | implementing. If that's a pressing concern for you, let me know
| > | > | and
| > | > | I'll bump it up the stack (a little). If you'd like, feel free to
| > | > | draft a proposal (or remind me to do it once in a while).
| > | > | 
| > | > | 
| > | > | As for actions, I typically think of them as API calls to other
| > | > | OS
| > | > | components like Nova. But they could just as easily be Python
| > | > | functions. But I would want to avoid an action that changes
| > | > | Congress's internal data structures directly (e.g. adding a new
| > | > | policy statement). Such actions have caused trouble in the past
| > | > | for
| > | > | policy languages (though for declarative programming languages
| > | > | like
| > | > | Prolog they are less problematic). I don't think there's anyway
| > | > | we
| > | > | can stop people from creating such actions, but I think we should
| > | > | advocate against them.
| > | > | 
| > | > | 
| > | > | Tim
| > | > | 
| > | > | 
| > | > | 
| > | > | From: "prabhakar Kudva" <nandavarpk at hotmail.com>
| > | > | To: "OpenStack Development Mailing List (not for usage
| > | > | questions)"
| > | > | <openstack-dev at lists.openstack.org>
| > | > | Sent: Wednesday, March 12, 2014 11:34:04 AM
| > | > | Subject: Re: [openstack-dev] [Congress] Policy types
| > | > | 
| > | > | 
| > | > | 
| > | > | Hi Tim, All,
| > | > | 
| > | > | I was in the discussion yesterday (kudva), and would like to
| > | > | start
| > | > | gradually
| > | > | contributing to the code base.
| > | > | 
| > | > | So, this discussion below is based on my limited exploration of
| > | > | Congress
| > | > | code, running it. I am trying some small pieces to implement to
| > | > | familiarize.
| > | > | Please view it as such. As I start adding code, I am sure, my
| > | > | thoughts will
| > | > | be more evolved.
| > | > | 
| > | > | I agree with the three types you outline. I also agree that these
| > | > | will grow.
| > | > | We are already thinking of expanding congress for various other
| > | > | types
| > | > | of
| > | > | policies. But those would be a manageable start.
| > | > | 
| > | > | Regarding the comment below. I was wondering if all conditions,
| > | > | and
| > | > | actions
| > | > | could be both:
| > | > | 1. python functions (for conditions they eval
| > | > | 2. policy primitives.
| > | > | 
| > | > | The advantage of 1, is that it is just executed and a True or
| > | > | False
| > | > | returned
| > | > | by Python for conditions. For actions, python functions are
| > | > | executed
| > | > | to respond to conditions.
| > | > | This controls the growth of policies and adding more primitives,
| > | > | and
| > | > | makes it flexible (say
| > | > | to use alarms, monitors, os clients, nova actions etc).
| > | > | 
| > | > | The advantage of 2, is the ability to use unification (as in
| > | > | unify.py) and do
| > | > | some logic reduction. This gives us the full strength of
| > | > | extensive
| > | > | and mature
| > | > | logic reasoning and reduction methods.
| > | > | 
| > | > | One possibility is that it checks which one the two it is and
| > | > | does
| > | > | the appropriate
| > | > | evaluation for condition and action.
| > | > | 
| > | > | 
| > | > | 
| > | > | 
| > | > | >There are drawbacks to this proposal as well.
| > | > | >- We will have 3 separate policies that are conceptually very
| > | > | >similar. As the policies grow larger, it will become
| > | > | >>increasingly
| > | > | >difficult to keep the policies synchronized. This problem can be
| > | > | >mitigated to some extent by having >all 3 share a library of
| > | > | >policy
| > | > | >statements that they all apply in different ways (and such a
| > | > | >library mechanism is >already implemented).
| > | > | >- As cloud services change their behavior, policies may need to
| > | > | >be
| > | > | >re-written. For example, right now Nova does >not consult
| > | > | >Congress
| > | > | >before creating a VM; thus, to enforce policy surrounding VMs,
| > | > | >the
| > | > | >best we could do is >write a Condition-Action policy that
| > | > | >adjusts
| > | > | >VM configuration when it learns about new VMs being created. If
| > | > | >we
| > | > | >>later make Nova consult with Congress before creating a VM, we
| > | > | >need to write an Access-control policy that puts >the proper
| > | > | >controls in place.
| > | > | Thanks,
| > | > | 
| > | > | Prabhakar Kudva
| > | > | 
| > | > | 
| > | > | 
| > | > | 
| > | > | 
| > | > | 
| > | > | 
| > | > | 
| > | > | Date: Wed, 12 Mar 2014 10:05:23 -0700
| > | > | From: thinrichs at vmware.com
| > | > | To: openstack-dev at lists.openstack.org
| > | > | Subject: [openstack-dev] [Congress] Policy types
| > | > | 
| > | > | 
| > | > | 
| > | > | 
| > | > | Hi all,
| > | > | 
| > | > | 
| > | > | We started a discussion on IRC yesterday that I'd like to
| > | > | continue.
| > | > | The main question is what kind of policy does a Congress user
| > | > | actually write? I can see three options. The first two focus on
| > | > | actions (API calls that make changes to the state of the cloud)
| > | > | and
| > | > | the last focuses on just the cloud state. (By "state of the
| > | > | cloud" I
| > | > | mean all the information Congress can see about all the cloud
| > | > | services it is managing, e.g. all the information we can get
| > | > | through
| > | > | API calls to Nova, Neutron, Cinder, Heat, ...).
| > | > | 
| > | > | 
| > | > | 1) Access Control (e.g. Linux, XACML, AD): which *actions* can be
| > | > | performed by other cloud services (for each state of the cloud)
| > | > | 2) Condition Action: which *actions* Congress should execute (for
| > | > | each state of the cloud)
| > | > | 3) Classification (currently supported in Congress): which
| > | > | *states*
| > | > | violate real-world policy. [For those of you who have read
| > | > | docs/white-papers/etc. I'm using "Classification" in this note to
| > | > | mean the combination of the current "Classification" and "Action
| > | > | Description" policies.]
| > | > | 
| > | > | 
| > | > | The important observation is that each of these policies could
| > | > | contain different information from each of the others.
| > | > | 
| > | > | 
| > | > | 
| > | > | - Access Control vs Condition Action. The Access Control policy
| > | > | tells
| > | > | *other cloud services* which actions they are *allowed* to
| > | > | execute.
| > | > | The Condition Action policy tells *Congress* which actions it
| > | > | *must*
| > | > | execute. These policies differ because they constrain different
| > | > | sets
| > | > | of cloud services.
| > | > | 
| > | > | 
| > | > | - Access Control vs. Classification. The Access Control policy
| > | > | might
| > | > | permit some users to violate the Classification policy in some
| > | > | situations (e.g. to fix violation A, we might need to cause
| > | > | violation B before eliminating both). These policies differ
| > | > | because
| > | > | a violation in one policy might be be a violation in the other.
| > | > | 
| > | > | 
| > | > | - Classification vs. Condition Action. The Classification policy
| > | > | might imply which actions *could* eliminate a given violation,
| > | > | but
| > | > | the Condition Action policy would dictate which of those actions
| > | > | *should* be executed (e.g. the Classification policy might tell
| > | > | us
| > | > | that disconnecting a network and deleting a VM would both
| > | > | eliminate
| > | > | a particular violation, but the Condition Action policy would
| > | > | tell
| > | > | us which to choose). And the Condition Action policy need not
| > | > | eliminate all the violations present in the Classification
| > | > | policy.
| > | > | Again these policies differ because a violation in one policy
| > | > | might
| > | > | not be a violation in the other.
| > | > | 
| > | > | 
| > | > | 
| > | > | I'm proposing that for the first release of Congress we support
| > | > | all 3
| > | > | of these policies. When a user inserts/deletes a policy
| > | > | statement,
| > | > | she chooses which policy it belongs to. All would be written in
| > | > | basically the same syntax but would be used in 3 different
| > | > | scenarios:
| > | > | 
| > | > | 
| > | > | - Prevention: If a component wants to consult Congress before
| > | > | taking
| > | > | action to see if that action is allowed, Congress checks the
| > | > | Access
| > | > | Control policy.
| > | > | 
| > | > | 
| > | > | - Reaction: When Congress learns of a change in the cloud's
| > | > | state, it
| > | > | checks the Condition Action policy to see which actions should be
| > | > | executed (if any).
| > | > | 
| > | > | 
| > | > | - Monitoring: If a user wants to simply check if the cloud's
| > | > | state is
| > | > | in compliance and monitor compliance over time, she writes and
| > | > | queries the Classification policy.
| > | > | 
| > | > | 
| > | > | There are several benefits to this proposal.
| > | > | - It allows users to choose any of the policy types, if they only
| > | > | want one of them. From our discussions with potential users, most
| > | > | seem to want one of these 3 policy types (and are uninterested in
| > | > | the others).
| > | > | - It makes the introduction to Congress relatively simple. We
| > | > | describe 3 different uses of policy (Prevention, Reaction,
| > | > | Monitoring) and then explain which policy to use in which case.
| > | > | 
| > | > | - This allows us to focus on implementing a single policy-engine
| > | > | technology (a Datalog policy language and evaluation algorithms),
| > | > | which gives us the opportunity to make it solid.
| > | > | 
| > | > | 
| > | > | There are drawbacks to this proposal as well.
| > | > | - We will have 3 separate policies that are conceptually very
| > | > | similar. As the policies grow larger, it will become increasingly
| > | > | difficult to keep the policies synchronized. This problem can be
| > | > | mitigated to some extent by having all 3 share a library of
| > | > | policy
| > | > | statements that they all apply in different ways (and such a
| > | > | library
| > | > | mechanism is already implemented).
| > | > | - As cloud services change their behavior, policies may need to
| > | > | be
| > | > | re-written. For example, right now Nova does not consult Congress
| > | > | before creating a VM; thus, to enforce policy surrounding VMs,
| > | > | the
| > | > | best we could do is write a Condition-Action policy that adjusts
| > | > | VM
| > | > | configuration when it learns about new VMs being created. If we
| > | > | later make Nova consult with Congress before creating a VM, we
| > | > | need
| > | > | to write an Access-control policy that puts the proper controls
| > | > | in
| > | > | place.
| > | > | 
| > | > | 
| > | > | These drawbacks were the original motivation for supporting only
| > | > | the
| > | > | Classification policy and attempting to derive the Access Control
| > | > | and Condition Action policies from it. But given that we can't
| > | > | always derive the proper Access Control and Condition Action
| > | > | policies from the Classification policy, we will eventually need
| > | > | support for all 3. In addition, the technical complexity of
| > | > | supporting all 3 is much lower than supporting just the
| > | > | Classification policy and deriving the others.
| > | > | 
| > | > | 
| > | > | I'll stop there for now.
| > | > | 
| > | > | 
| > | > | Comments, thoughts, questions?
| > | > | Tim
| > | > | 
| > | > | 
| > | > | _______________________________________________ OpenStack-dev
| > | > | mailing
| > | > | list OpenStack-dev at lists.openstack.org
| > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883
| > | > | _______________________________________________
| > | > | OpenStack-dev mailing list
| > | > | OpenStack-dev at lists.openstack.org
| > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=4QiYdqIhBIaa%2FY1uu8c2Wq%2F92NWfXkaUvJLsncl4ccI%3D%0A&s=a18a843e031ec87277e04caa8396b5cf71bc7a2e5252247084abacf0b9e51409
| > | > | 
| > | > | 
| > | > | 
| > | > | _______________________________________________ OpenStack-dev
| > | > | mailing
| > | > | list OpenStack-dev at lists.openstack.org
| > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883
| > | > | _______________________________________________
| > | > | OpenStack-dev mailing list
| > | > | OpenStack-dev at lists.openstack.org
| > | > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=SMheq3u5q7x9wYFjxnNx6C%2F9lZgxydUP452rygu28MY%3D%0A&s=5c1cf9f3a5adc86ce59d2bf582891e0da033394f43a6ffa72127843c8cf78f80
| > | > | 
| > | > 
| > | > _______________________________________________
| > | > OpenStack-dev mailing list
| > | > OpenStack-dev at lists.openstack.org
| > | > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883
| > | 
| > | _______________________________________________
| > | OpenStack-dev mailing list
| > | OpenStack-dev at lists.openstack.org
| > | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=QvFCD7z%2FP29TE6KUtbaOJzeGxlOtxzdiGCdlm1LkcOY%3D%0A&s=8f7ec7cc8312dd84709bc99d725e9934b5403a43e8f1f2d02c638e504009ea71
| > | 
| > 
| > _______________________________________________
| > OpenStack-dev mailing list
| > OpenStack-dev at lists.openstack.org
| > https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883
|  		 	   		  
| _______________________________________________
| OpenStack-dev mailing list
| OpenStack-dev at lists.openstack.org
| https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=d%2Bh3pVuaRTb%2BTqwqUiF3b5p6jMziF19D3RFSqwM9hKw%3D%0A&s=7d10f41d7960d2203631d1d1f67e80dcd6c1a0f845607674d244601a0b251883
| 



More information about the OpenStack-dev mailing list