<font size=2 face="sans-serif">+1</font>
<br>
<br><font size=2 face="sans-serif">Brad</font>
<br><font size=2 face="sans-serif"><br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet:  btopol@us.ibm.com<br>
Assistant: Cindy Willman (919) 268-5296</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">"Yee, Guang"
<guang.yee@hp.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">06/19/2013 12:24 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
[keystone] Inherited domain roles</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>+1<br>
<br>
<br>
Guang<br>
<br>
<br>
-----Original Message-----<br>
From: Henry Nash [</font></tt><a href=mailto:henryn@linux.vnet.ibm.com><tt><font size=2>mailto:henryn@linux.vnet.ibm.com</font></tt></a><tt><font size=2>]
<br>
Sent: Wednesday, June 19, 2013 8:48 AM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] [keystone] Inherited domain roles<br>
<br>
Hi<br>
<br>
So I don't doubt there are many ways of articulating the targeted objects
-<br>
and a more comprehensive solution might involve the mapping you mention<br>
(although that's definitely not a Havana discussion!).<br>
<br>
We do, however, have an existing serious hole in our current apis &
policy<br>
protection that limits the ability of a cloud provider to delegate admin<br>
responsibility for a domain to a customer, while still ensuring they<br>
maintain certain roles over all projects created in that customer domain<br>
(without the ability of the customer admin removing them!).  This
is the use<br>
case I am trying to solve first and foremost.  This is a subset of
the<br>
general problem, and using the domain as the container to specify applying<br>
to all current and future projects (which I call inheritance) is, I believe,<br>
the most appropriate.  However, as we agreed, this should be an extension,<br>
since we are likely to settle on a more comprehensive re-write of these
APIs<br>
for IceHouse.<br>
<br>
As per the keystone IRC meeting, I have now done the following:<br>
<br>
1) Removed all mention of multiple target objects (and hence inheritance)<br>
from the newly proposed GET /role-assignment API (that replaces the various<br>
broken ones we have removed from the spec).  This updated API is now<br>
available for review at: </font></tt><a href=https://review.openstack.org/#/c/32394/8><tt><font size=2>https://review.openstack.org/#/c/32394/8</font></tt></a><tt><font size=2><br>
<br>
2) Moved the "inherit roles from parent domain" extension to
role assignment<br>
setting to an extension.  This API is available for review at:<br>
</font></tt><a href=https://review.openstack.org/#/c/29781/15><tt><font size=2>https://review.openstack.org/#/c/29781/15</font></tt></a><tt><font size=2><br>
<br>
I think this is a good way to proceed, unless anyone has significant<br>
objections.<br>
<br>
Henry<br>
On 19 Jun 2013, at 15:36, Adam Young wrote:<br>
<br>
> The more I think about it, the more I think that tying the inheritance
to<br>
the domain assignment is the wrong solution.<br>
> <br>
> David/Kristy originally had the Mapping blueprint and patch.  It
contained<br>
the ability to provide arbitrary rules for mapping from the identity<br>
attributes to the roles.  I think that it is time to implement that.<br>
> <br>
> It would be more correct to say that all users in a specific group<br>
(fetched out of Identity/LDAP) would get a specific role in a project than<br>
to say that a user with a domain role should therefore inherit a role in
all<br>
projects.<br>
> <br>
> When creating a scoped token, we need to query a subset of the users<br>
identity information.  I think that the right direction for this query
to<br>
flow would be:<br>
> <br>
> project->roles->role-mappings->groups<br>
> <br>
> as opposed to what we do now, which is to do a global query: give
me all<br>
groups for this user and select which ones apply.  For LDAP/SQL Identity<br>
backends we want to trigger the miniaml query which is "let me know
if the<br>
user is in groups G1, G2, G3..."  as those are the groups that
potentially<br>
apply to role assignments for this project.<br>
> <br>
> <br>
> So I'd like to redefine the problem definition here:<br>
> <br>
> "Provide a mechanism by which role assignments can be specified
for more<br>
than one project."  One such rule would obviously be "all
projects in<br>
domain D1"<br>
> <br>
> But it should be based on groups, not on domain role assignments.<br>
> <br>
> <br>
> <br>
> <br>
> On 06/10/2013 11:41 AM, David Chadwick wrote:<br>
>> <br>
>> <br>
>> On 10/06/2013 16:02, Henry Nash wrote:<br>
>>> Hi David,<br>
>>> <br>
>>> I wasn't suggesting that we encode "inhertitness"
in the name, just<br>
>>> that if you want to have a role that is non-inherited and
one that is<br>
>>> inherited that relate to the same type of permission, then
since role<br>
>>> name must be globally unique, then the two roles must have
different<br>
>>> names....hence potentially leading to the complication in
the policy<br>
>>> file.<br>
>> <br>
>> I dont see why different role names would lead to complications
in the<br>
policy file, since policies are there to assign different permissions to<br>
different roles.<br>
>> <br>
>> What can happen is that policy files can get very large and complex,
but<br>
that can happen regardless of whether roles are inherited or not, and<br>
mistakes can be made by assigning the wrong roles to users or the wrong<br>
permissions to roles, but again this is independent of the role definition.<br>
>> <br>
>> regards<br>
>> <br>
>> David<br>
>>> <br>
>>> Henry On 10 Jun 2013, at 15:57, David Chadwick wrote:<br>
>>> <br>
>>>> Hi Henry<br>
>>>> <br>
>>>> on the definition of inherited roles, I dont think this
should be<br>
>>>> part of the role name, but rather, each role should have
meta<br>
>>>> information attached to it, in its role table definition,
that<br>
>>>> indicates the properties of the role definition. In this
way, you<br>
>>>> can make the role definition extensible by adding new
columns to<br>
>>>> the table as and when needed e.g. if in future you want
to have<br>
>>>> global roles inherited by domains, you add a new column,
say<br>
>>>> GlobalToDomain, which could be a boolean with a default
value of<br>
>>>> false, and with a value true indicating that it is inherited
from<br>
>>>> global to domain. All pre-existing roles would not be
of this type,<br>
>>>> and therefore all pre-existing code would work without
this new<br>
>>>> inheritance.<br>
>>>> <br>
>>>> I would not alter the role-user assignment API as this
should<br>
>>>> simply specify the role and user and project. The code
may need<br>
>>>> enhancing in the future, if new types of inheritance are
added, in<br>
>>>> order to cater for cases where the role is wrongly specified
by the<br>
>>>> administrator i.e. it does not apply to the project in
question<br>
>>>> through lack of inheritance.<br>
>>>> <br>
>>>> regards<br>
>>>> <br>
>>>> David<br>
>>>> <br>
>>>> On 08/06/2013 11:38, Henry Nash wrote:<br>
>>>>> So on the idea of using the role def for inheritance
definition,<br>
>>>>> there were a couple of things that concerned me about
it:<br>
>>>>> <br>
>>>>> 1) While it definitely can simply the api changes
required for<br>
>>>>> the current requirements, I worry that we are passing
the<br>
>>>>> complexity on to the creation of the policy file.
 Since the role<br>
>>>>> names of an inherited and non-inherited role will
obviously have<br>
>>>>> to be different, is there a danger that policy files
end up with<br>
>>>>> lots of rules that have "role: xxxx and role:
xxxx_inherited"?  I<br>
>>>>> guess we can make the argument that since (with today's<br>
>>>>> requirements at least) the only objects that will
end of<br>
>>>>> inheriting an assignment will be projects, the likelihood
is that<br>
>>>>> the api lines in the policy file that contains inherited
and<br>
>>>>> non-inherited will be different, hence avoiding the
problem.<br>
>>>>> However, if, in the future, we were to expand inheritance
to<br>
>>>>> support all domains, or all projects in all domains,
then this<br>
>>>>> problem would arise for domain-relevant apis lines
in the policy<br>
>>>>> file.<br>
>>>>> <br>
>>>>> 2) If, again, in the future we support inheritance
across all<br>
>>>>> domains/projects - would we need to more fine grained
control of<br>
>>>>> the inheritance?  For instance, we want a role
that was inherited<br>
>>>>> by all domains, but not the projects in each domain?
Perhaps,<br>
>>>>> one could imagine expanding the role-def to somehow
indicate this<br>
>>>>> (maybe rather than just having a simple "inherited"
boolean, we<br>
>>>>> specify "project_inherited", to which we
could, in the future,<br>
>>>>> add "domain_inherited"?).  We also
have the problem of how you<br>
>>>>> assign such a role?  I guess you would still
need some kind of<br>
>>>>> modification to the assignment APIs to indicate "all
domains"<br>
>>>>> (perhaps the "domains/*" that was suggested)?<br>
>>>>> <br>
>>>>> I'd be interested in views on the above - I'm Ok fi
we decide<br>
>>>>> that role-def is the right way to go, but want to
make sure we<br>
>>>>> clearly understand how we would expand this in the
future.<br>
>>>>> <br>
>>>>> Henry On 7 Jun 2013, at 18:12, Dolph Mathews wrote:<br>
>>>>> <br>
>>>>>> <br>
>>>>>> <br>
>>>>>> On Thu, Jun 6, 2013 at 5:48 AM, David Chadwick<br>
>>>>>> <d.w.chadwick@kent.ac.uk <</font></tt><a href=mailto:d.w.chadwick@kent.ac.uk><tt><font size=2>mailto:d.w.chadwick@kent.ac.uk</font></tt></a><tt><font size=2>>><br>
>>>>>> wrote:<br>
>>>>>> <br>
>>>>>> Hi Henry<br>
>>>>>> <br>
>>>>>> My take on this is that whether a role is automatically<br>
>>>>>> inheritable or not should be an attribute of the
role itself,<br>
>>>>>> and should be independent of who the role is assigned
to.<br>
>>>>>> Therefore when the role is initially defined,
it should be<br>
>>>>>> stated by the Keystone admin whether it is an
inherited role or<br>
>>>>>> not.<br>
>>>>>> <br>
>>>>>> Role assignment is a separate issue and should
not be confused<br>
>>>>>> with the basic definition of the role. Role assignment
should<br>
>>>>>> simply be a matter of naming the subject (domain,
project or<br>
>>>>>> user) and the role. If you dont want the role
to be inherited<br>
>>>>>> then use a non-inheritable role.<br>
>>>>>> <br>
>>>>>> The problem with all the APIs below is that they
conflate role<br>
>>>>>> definition and role assignment together in the
same API call.<br>
>>>>>> There should be no need to have user_ids in the
definition of<br>
>>>>>> a role. Similarly there should be no mention of
inherited in<br>
>>>>>> the assignment of a role to a user.<br>
>>>>>> <br>
>>>>>> regards<br>
>>>>>> <br>
>>>>>> David<br>
>>>>>> <br>
>>>>>> +1; I really like the simplicity of this approach,
and it<br>
>>>>>> sounds like something we can migrate to easily
(e.g. default<br>
>>>>>> inheritable=False for existing roles). Then global
role<br>
>>>>>> assignments would follow an API like:<br>
>>>>>> <br>
>>>>>> GET /users/{user_id}/roles  # list global
roles HEAD<br>
>>>>>> /users/{user_id}/roles/{inheritable_role_id}  #
check if a<br>
>>>>>> global role is assigned PUT<br>
>>>>>> /users/{user_id}/roles/{inheritable_role_id}  #
assign a global<br>
>>>>>> role DELETE /users/{user_id}/roles/{inheritable_role_id}
#<br>
>>>>>> revoke a global role<br>
>>>>>> <br>
>>>>>> where a non-inheritable role assigned a user without
a domain<br>
>>>>>> or project for context wouldn't make any sense.
In fact,<br>
>>>>>> assigning an inheritable role to a user on a project
wouldn't<br>
>>>>>> be very useful (as it wouldn't inherit to anything
in the core<br>
>>>>>> API), but I don't see a reason to deny it.<br>
>>>>>> <br>
>>>>>> <br>
>>>>>> On 05/06/2013 15:31, Henry Nash wrote:<br>
>>>>>> <br>
>>>>>> Hi<br>
>>>>>> <br>
>>>>>> As per the discussion during the keystone IRC
meeting<br>
>>>>>> yesterday, I have been reviewing the proposals
for this<br>
>>>>>> functionality.  There have been two objections
to the current<br>
>>>>>> proposal (which can be found here:<br>
>>>>>> </font></tt><a href=https://review.openstack.org/#__/c/29781/10><tt><font size=2>https://review.openstack.org/#__/c/29781/10</font></tt></a><tt><font size=2><br>
>>>>>> <</font></tt><a href=https://review.openstack.org/#/c/29781/10><tt><font size=2>https://review.openstack.org/#/c/29781/10</font></tt></a><tt><font size=2>>),
which are:<br>
>>>>>> <br>
>>>>>> 1) The api changes should allow for a logical,
generic future<br>
>>>>>> extension for support of inherited roles across
all domains<br>
>>>>>> etc., should we chose to go that route 2) The
use of a single<br>
>>>>>> api to list the various grants, filtered by a
query string if<br>
>>>>>> necessary.<br>
>>>>>> <br>
>>>>>> My proposal for handling these two objections
is as follows:<br>
>>>>>> <br>
>>>>>> 1) API extensions.<br>
>>>>>> <br>
>>>>>> There are several aspects of inherited roles that
we are trying<br>
>>>>>> to cement, which are:<br>
>>>>>> <br>
>>>>>> a) The are dynamic - i.e. this isn't a case of
a short hand for<br>
>>>>>> saying add this role to all the current projects
in the domain<br>
>>>>>> - rather it is a role assignment that is attached
to the domain<br>
>>>>>> but is added to the effective roles of any project
(now and in<br>
>>>>>> the future) that exists in this domain b) The
are separate from<br>
>>>>>> a role that is on the domain itself - i.e.  we
need to ensure<br>
>>>>>> that we keep separate inherited and non-inherited
roles. c)<br>
>>>>>> Maintain the philosophy that If you can create
a role<br>
>>>>>> assignment with a given API, there should be an
equivalent to<br>
>>>>>> read it back and delete it (i.e. you mustn't have
the case<br>
>>>>>> where, for instance you can list a grant, but
can't delete it<br>
>>>>>> at the conceptual level)<br>
>>>>>> <br>
>>>>>> The current proposal had been to do this by adding
an<br>
>>>>>> "inherited" component of the url for
create, check and delete<br>
>>>>>> grants to a domain, e.g.<br>
>>>>>> <br>
>>>>>> PUT /domains/{domain_id}/users/{__user_id}/roles/{role_id}
PUT<br>
>>>>>> /domains/{domain_id}/users/{__user_id}/roles/{role_id}/__inherited<br>
>>>>>> <br>
>>>>>> <br>
>> GET /domains/{domain_id}/users/{__user_id}/roles/{role_id}<br>
>>>>>> GET<br>
>>>>>> /domains/{domain_id}/users/{__user_id}/roles/{role_id}/__inherited<br>
>>>>>> <br>
>>>>>> <br>
>> DELETE /domains/{domain_id}/users/{__user_id}/roles/{role_id}<br>
>>>>>> DELETE<br>
>>>>>> /domains/{domain_id}/users/{__user_id}/roles/{role_id}/__inherited<br>
>>>>>> <br>
>>>>>> <br>
>> etc.<br>
>>>>>> <br>
>>>>>> A counter proposal has been made to expand this,
along this<br>
>>>>>> lines of:<br>
>>>>>> <br>
>>>>>> Role applicable to all projects within a domain
PUT<br>
>>>>>> /domains/{domain_id}/users/{__user_id}/roles/{role_id}/__projects<br>
>>>>>> <br>
>>>>>> <br>
>>>>>> <br>
>> Roles inherited by all projects in all domains<br>
>>>>>> PUT /usrs/{user_id}/roles/{role___id}/projects<br>
>>>>>> <br>
>>>>>> Roles inherited by all domains, at the domain
level PUT<br>
>>>>>> /usrs/{user_id}/roles/{role___id}/domains<br>
>>>>>> <br>
>>>>>> While I understand the desire to have extensibility
if we wish<br>
>>>>>> to provide more "global-ness" of roles,
I think the above<br>
>>>>>> proposal is less clear about whether these assignments
are<br>
>>>>>> dynamic (see item a) above).  How about this
as a counter<br>
>>>>>> proposal:<br>
>>>>>> <br>
>>>>>> Role applicable inherited by all projects within
a domain (this<br>
>>>>>> is the same as the current proposal) PUT<br>
>>>>>> /domains/{domain_id}/users/{__user_id}/roles/{role_id}/__inherited<br>
>>>>>> <br>
>>>>>> <br>
>>>>>> <br>
>> Roles inherited by all projects in all domains - if we were to<br>
>>>>>> ever support this (not part of the current proposal)
PUT<br>
>>>>>> /domains/users/{user_id}/__roles/{role_id}/inherited<br>
>>>>>> <br>
>>>>>> Roles inherited by all domains, at the domain
level - if we<br>
>>>>>> were to ever support this (not part of the current
proposal)<br>
>>>>>> PUT  /domains/users/{user_id}/__roles/{role_id}/inherited<br>
>>>>>> <br>
>>>>>> To go along with the above, you would have the
respective GET,<br>
>>>>>> CHECK & DELETE versions of those apis.<br>
>>>>>> <br>
>>>>>> 2) Single vs multiple apis I think this comment
is actually<br>
>>>>>> misplaced in the gerrit review, and is intended
to directed at<br>
>>>>>> the api extensions I proposed to allow the list
of a users<br>
>>>>>> "effective" roles on a project (i.e.
directly assigned, those<br>
>>>>>> by virtue of group membership and inheritance
from the parent<br>
>>>>>> domain).  For this, I proposed adding an
optional "effective"<br>
>>>>>> query parameter to each of:<br>
>>>>>> <br>
>>>>>> List user's roles on project: `GET<br>
>>>>>> /projects/{project_id}/users/{__user_id}/roles
List group's<br>
>>>>>> roles on project: `GET<br>
>>>>>> /projects/{project_id}/groups/__{group_id}/roles
Check user's<br>
>>>>>> role on project: `GET<br>
>>>>>> /projects/{project_id}/users/{__user_id}/role/{role_id}
Check<br>
>>>>>> group's roles on project: `GET<br>
>>>>>> /projects/{project_id}/groups/__{group_id}/role/{role_id}<br>
>>>>>> <br>
>>>>>> e.g. GET<br>
>>>>>> /projects/{project_id}/users/{__user_id}/roles?effective<br>
>>>>>> ...would get you the effective roles the user
has on that<br>
>>>>>> project, as opposed to only the directly assigned
ones if you<br>
>>>>>> issue the call without the "effective"
query parameter.<br>
>>>>>> <br>
>>>>>> Dolph and I had already been discussing that the
existing v3<br>
>>>>>> api of:<br>
>>>>>> <br>
>>>>>> GET /users/{user_id}/roles<br>
>>>>>> <br>
>>>>>> ...which is meant to return all the role assignments
for a<br>
>>>>>> user, but is in fact broken in the current Grizzly
code (it<br>
>>>>>> always returns an error).  So I agree with
the proposal that we<br>
>>>>>> should scrap the "effective" query parameter
for the specific<br>
>>>>>> list/check calls for the project - and instead
properly<br>
>>>>>> implement the "get all assignments for a
user" call. I propose<br>
>>>>>> the amended spec for this call is:<br>
>>>>>> <br>
>>>>>> #### List a user's effective role assignments:
`GET<br>
>>>>>> /users/{user_id}/role-__assignments`<br>
>>>>>> <br>
>>>>>> query_string: page (optional) query_string: per_page
(optional,<br>
>>>>>> default 30) query_string: id, project_id, domain_id<br>
>>>>>> <br>
>>>>>> Response:<br>
>>>>>> <br>
>>>>>> Status: 200 OK<br>
>>>>>> <br>
>>>>>> [ { "id": "--role-id--", "name":
"--role-name--", "project_id":<br>
>>>>>> "--project-id--", "source":
{ "direct": true,  (optional)<br>
>>>>>> "domain_inherited: "--domain-id--",
(optional)<br>
>>>>>> "group_membership: "--group-id--"
(optional) } }, {<br>
>>>>>> "domain_id": "--domain-id--",
"id": "--role-id--", "name":<br>
>>>>>> "--role-name--", "source":
{ "direct": true, (optional)<br>
>>>>>> "group_membership: "--group-id--"
(optional) } } ]<br>
>>>>>> <br>
>>>>>> The "source" structure must have at
least one of the values<br>
>>>>>> given above (and could have more than one, e.g.
both<br>
>>>>>> domain_inherited and global_membership for a project
where the<br>
>>>>>> role is due to a group role that is inherited
from the domain).<br>
>>>>>> If were even to support global roles across all
domains, then<br>
>>>>>> we would extend the "source structure"
accordingly.   I'm open<br>
>>>>>> to other options for the above format. however,
so comments<br>
>>>>>> welcome.<br>
>>>>>> <br>
>>>>>> Does this sounds like a reasonable plan overall?<br>
>>>>>> <br>
>>>>>> Henry<br>
>>>>>> <br>
>>>>>> <br>
>>>>>> <br>
>>>>>> _________________________________________________
OpenStack-dev<br>
>>>>>> mailing list OpenStack-dev@lists.openstack.__org<br>
>>>>>> <</font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size=2>mailto:OpenStack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
>>>>>> </font></tt><a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev"><tt><font size=2>http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev</font></tt></a><tt><font size=2><br>
>>>>>> <br>
>>>>>> <br>
>> <</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2>><br>
>>>>>> <br>
>>>>>> <br>
>>>>>> _________________________________________________
OpenStack-dev<br>
>>>>>> mailing list OpenStack-dev@lists.openstack.__org<br>
>>>>>> <</font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size=2>mailto:OpenStack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
>>>>>> </font></tt><a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev"><tt><font size=2>http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev</font></tt></a><tt><font size=2><br>
>>>>>> <br>
>>>>>> <br>
>> <</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2>><br>
>>>>>> <br>
>>>>>> <br>
>>>>>> _______________________________________________
OpenStack-dev<br>
>>>>>> mailing list OpenStack-dev@lists.openstack.org<br>
>>>>>> <</font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size=2>mailto:OpenStack-dev@lists.openstack.org</font></tt></a><tt><font size=2>><br>
>>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>> <br>
>>>>> <br>
>>>>> <br>
>>>>> <br>
>>>>>> <br>
>> _______________________________________________<br>
>>>>> OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<br>
>>>>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
>>>>> <br>
>>>> <br>
>>> <br>
>> <br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> OpenStack-dev@lists.openstack.org<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
[attachment "smime.p7s" deleted by Brad Topol/Raleigh/IBM] _______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>