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" <[email protected]> | To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]> | 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: [email protected] | > To: [email protected] | > 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" <[email protected]> | > | To: "OpenStack Development Mailing List (not for usage questions)" | > | <[email protected]> | > | 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: [email protected] | > | > To: [email protected] | > | > 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" <[email protected]> | > | > | To: "OpenStack Development Mailing List (not for usage | > | > | questions)" <[email protected]> | > | > | 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: [email protected] | > | > | To: [email protected] | > | > | 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" <[email protected]> | > | > | To: "OpenStack Development Mailing List (not for usage | > | > | questions)" | > | > | <[email protected]> | > | > | 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: [email protected] | > | > | To: [email protected] | > | > | 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 [email protected] | > | > | 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 | > | > | [email protected] | > | > | 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 [email protected] | > | > | 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 | > | > | [email protected] | > | > | 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 | > | > [email protected] | > | > 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 | > | [email protected] | > | 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 | > [email protected] | > 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 | [email protected] | 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
