<font size=2 face="sans-serif">Hi, </font>
<br>
<br><font size=2 face="sans-serif">It will be very useful to allow granting
access by emails. However, when validating the ACLs it is important to
reduce the performance overhead of contacting the Keystone and the identity
backend to check that the accessing user indeed has the email on ACLs.
Thus, it is important that the stored/cached ACLs will contain some identifier
that is present in the token provided by the accessing user and we can
efficiently check that there is a match with the one on ACLs. I think
there are two approaches to address this. Either we can make emails mandatory
in the tokens. Or, we can adopt the S3 approach and even when the user
grants access by specifying an email, the system we will add an identifier
that is mandatory in tokens to the ACLs. </font>
<br>
<br><font size=2 face="sans-serif">Also, getting back to the uniqueness
of project names on Swift ACLs for Keystone V3. I posted a Swift
blueprint suggesting a simple solution that can be done for Grizzly: </font><a href="https://blueprints.launchpad.net/swift/+spec/keystone-v3-acls"><font size=2 face="sans-serif">https://blueprints.launchpad.net/swift/+spec/keystone-v3-acls</font></a><font size=2 face="sans-serif">.</font>
<br>
<br><font size=2 face="sans-serif">Best Regards,</font>
<br><font size=2 face="sans-serif">Alex. </font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">David Chadwick <d.w.chadwick@kent.ac.uk></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Ali, Haneef"
<haneef.ali@hp.com>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</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">04/02/2013 08:39 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[swift] [keystone] Keystone v3 API domains in Swift</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>You can make sure an email-address is unique by sending
an email to it.<br>
It has to be globally unique in order for SMTP to route to it correctly.<br>
<br>
But I think your implied question might have been<br>
either,<br>
How can we be sure that the email address belongs to the user whose<br>
account it is stored in,<br>
or<br>
How can we be sure that only one user is using each email address.<br>
<br>
It is the responsibility of the administrator who registers the user <br>
into Keystone to ensure that he enters<br>
the correct email address for the user (answer to 1) and that<br>
he does not give multiple users the same email address (answer to 2) <br>
unless he wants multiple users to have common attributes (and therefore
<br>
implicitly the same privileges)<br>
<br>
In a federated system we trust the IDP to register the user correctly.<br>
<br>
regards<br>
<br>
David<br>
<br>
<br>
On 04/02/2013 18:04, Ali, Haneef wrote:<br>
> The problem is, I can provide "proof of age" if I have one.
In<br>
> keystone v3 echo system, I can create a user and use it across all<br>
> the services. But to use it with swift, the user should
have been<br>
> created with email address. This seems odd. If email address is a<br>
> required attribute in keystone, then we won't be discussing this<br>
> issue. I don't understand why email address is not in v3, since it
is<br>
> an important attribute if anyone wants to implement password reset<br>
> feature.<br>
><br>
> a) Assuming we create an user with email-address, how are we going
to<br>
> make sure it is unique? Keystone is not going to do this.<br>
><br>
><br>
> Thanks Haneef<br>
><br>
><br>
><br>
> -----Original Message----- From: David Chadwick<br>
> [</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>]
Sent: Saturday, February 02, 2013<br>
> 6:54 AM To: OpenStack Development Mailing List Cc: Ali, Haneef<br>
> Subject: Re: [openstack-dev] [swift] [keystone] Keystone v3 API<br>
> domains in Swift<br>
><br>
> There is nothing wrong in principle in having access control rules<br>
> based on attributes that a subject might or might not have provided.<br>
> When I go to the cinema to see a +15 movie I might have to provide<br>
> proof of age. If I have forgotten to bring it with me, then I dont<br>
> get in to see the film. It is up to the user to provide the<br>
> attributes that are required by the service in order to gain access.<br>
> If the service's policy is that subjects need to provide email<br>
> addresses, then users would know that they need to do this in order<br>
> to gain access. Services should publish their policies to users if<br>
> they are different to the expected norms.<br>
><br>
> In summary, it is for the service to decide which attributes are<br>
> needed.<br>
><br>
> regards<br>
><br>
> David<br>
><br>
> On 01/02/2013 21:16, Ali, Haneef wrote:<br>
>> Do we really want swift to make ACL decision based
on an<br>
>> attribute which may or may not be there( since it is optional)?<br>
>><br>
>> Thanks<br>
>><br>
>> Haneef<br>
>><br>
>> *From:*Adam Young [</font></tt><a href=mailto:ayoung@redhat.com><tt><font size=2>mailto:ayoung@redhat.com</font></tt></a><tt><font size=2>]
*Sent:* Friday,<br>
>> February 01, 2013 12:47 PM *To:* openstack-dev@lists.openstack.org<br>
>> *Subject:* Re: [openstack-dev] [swift] [keystone] Keystone v3
API<br>
>> domains in Swift<br>
>><br>
>> On 02/01/2013 01:27 PM, Dolph Mathews wrote:<br>
>><br>
>> It's not; we dropped it from the list of required attributes,
but<br>
>> you can still provide one.<br>
>><br>
>> According to GYee's latest submission, it would be in<br>
>><br>
>> extra:{email:address}<br>
>><br>
>> But we haven;t yet nailed down that proposal<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> -Dolph<br>
>><br>
>> On Fri, Feb 1, 2013 at 11:56 AM, Ali, Haneef <haneef.ali@hp.com<br>
>> <</font></tt><a href=mailto:haneef.ali@hp.com><tt><font size=2>mailto:haneef.ali@hp.com</font></tt></a><tt><font size=2>>>
wrote:<br>
>><br>
>> Are you sure that token contains email-address? I don't
see that<br>
>> as required field in user creation in v3.<br>
>><br>
>> Thanks Haneef<br>
>><br>
>><br>
>> -----Original Message----- From: David Chadwick<br>
>> [</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>
<</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>
>><br>
>> Sent: Friday, February 01, 2013 3:06 AM To: OpenStack Development<br>
>> Mailing List Subject: Re: [openstack-dev] [swift] [keystone]<br>
>> Keystone v3 API domains in Swift<br>
>><br>
>> Since the token contains the email address of the user, isnt it<br>
>> possible to use this in the ACL?<br>
>><br>
>> regards<br>
>><br>
>> David<br>
>><br>
>> On 23/01/2013 10:23, Alexandra Shulman-Peleg wrote:<br>
>>> Hi,<br>
>>><br>
>>> I would like to get back to this discussion and specify the<br>
>>> exact syntax of ACLs that can be used when removing the global<br>
>>> uniqueness constraint on user names. I wander whether we really<br>
>>> need to prefix both the project_name and the username with
the<br>
>>> domain id? Especially, since on ACLs we mainly need to properly<br>
>>> identify the user and not<br>
>> the project.<br>
>>> So the notion of a project may not be required in this context?<br>
>>> For example, in NFSv4 ACLs (also adopted by CDMI) users are<br>
>>> identified by username@domain. So I wander whether on ACLs,
in V3<br>
>>> we can simply switch from tenant_id:username to<br>
>>> domain_id:username? This seems to fulfill the identification<br>
>>> requirements and will give a very simple solution for the<br>
>>> migration of existing v2 customers to private domains in V3
-<br>
>>> assigning the new domain_id to match the old tenant_id will
allow<br>
>>> preserving all of the stored containers without the need to<br>
>>> modify the containers' meta data.<br>
>>><br>
>>> Best Regards, Alex.<br>
>>><br>
>>><br>
>>><br>
>>> From: "Yee, Guang" <guang.yee@hp.com <</font></tt><a href=mailto:guang.yee@hp.com><tt><font size=2>mailto:guang.yee@hp.com</font></tt></a><tt><font size=2>>><br>
>>> To: OpenStack Development Mailing List<br>
>>> <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>
>>> Date: 11/01/2013 10:31 PM Subject: Re: [openstack-dev] [swift]<br>
>>> [keystone] Keystone v3 API domains in Swift<br>
>>> ----------------------------------------------------------------------<br>
>><br>
>>><br>
> --<br>
>>><br>
>>><br>
>>><br>
>>> As long as Swift URL stay the same we should be OK. Frankly,<br>
>>> there aren't any strong arguments for changing it at this
point.<br>
>>> Whenever we remove the globally uniqueness constraint on names,<br>
>>> new Swift ACLs probably will need to switch over to using<br>
>>> namespacing.<br>
>>><br>
>>> domain_name.project_name:domain_name.username<br>
>>><br>
>>> something like that. Existing Swift ACLs should work fine
since<br>
>>> if the given domain is the default (migrated) system domain,<br>
>>> auth_token middleware should not set the domains headers.<br>
>>><br>
>>><br>
>>> Guang<br>
>>><br>
>>><br>
>>> -----Original Message----- From: David Chadwick<br>
>>> [</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>
>> <</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>
>>> Sent: Friday, January 11, 2013 8:36 AM To: OpenStack Development<br>
>>> Mailing List Subject: Re: [openstack-dev] [swift] [keystone]<br>
>>> Keystone v3 API domains in Swift<br>
>>><br>
>>> Hi Chuck<br>
>>><br>
>>> On 11/01/2013 15:59, Chuck Thier wrote:<br>
>>>> The Tenant_ID is in the URL<br>
>>>> (https://{SWIFT_IP}/v1/AUTH_{TENANT_ID}/{CONTAINER}/{OBJECT})<br>
>>>><br>
>>>> I think we have beaten this part to death a bit now, as
we seem<br>
>>>> to<br>
>>> all > agree that we can continue this pattern with
the V3 API.<br>
>>> The one > concern that I still have is how the ACLs
will work,<br>
>>> and weather or > not that will need to change.<br>
>>>><br>
>>>> I'm also curious how the Keystone V3 API will work alongside
V2<br>
>>>> apis.<br>
>>><br>
>>> My opinion (only, I dont speak for anyone else) is as follows:<br>
>>><br>
>>> 1. A v2 API system has no problems as it is working OK today
2. A<br>
>>> v3 API system only, with domains added, should work OK tomorrow<br>
>>> otherwise the v3 API has problems 3. So the main point as
you say<br>
>>> is how do v2 and v3 systems interwork. I suggest there is
an<br>
>>> intercept module, say in the Keystone pipeline, that knows
it is<br>
>>> operating in a v2/v3 environment, and when it receives a v2<br>
>>> request already containing a tenant_ID it knows it will comprise<br>
>>> domain:project and it can unpack it, and give the separate<br>
>>> elements to the rest of the V3 code for processing as in a
v3<br>
>>> system. When the intercept module receives a v2 request that<br>
>>> needs a tenant ID returning to it, it will encode up the domain<br>
>>> and project as a tenant ID, and return this to the v2 client.
The<br>
>>> v2 client will be blissfully unaware that what it thinks is
a<br>
>>> tenant ID is actually a combination of domain and project.<br>
>>><br>
>>> regards<br>
>>><br>
>>> david<br>
>>><br>
>>><br>
>>><br>
>>>><br>
>>>> -- Chuck<br>
>>>><br>
>>>> On Thu, Jan 10, 2013 at 4:16 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>
>>>>> You have to ask, where does the Swift client get the<br>
>>>>> tenant_Id from?<br>
>>> Isnt it<br>
>>>>> Keystone? So if Keystone returns project_ID:tenant_Id
to<br>
>>>>> swift as<br>
>>> the >> project_id string, then Swift can continue
to use this as<br>
>>> if nothing has >> changed. Its just a string whose
content has<br>
>>> no meaning to Swift, but whose >> content does
have meaning to<br>
>>> Keystone. The Swift policy simply needs to >>
change the value<br>
>>> of the tenant_id in its policy to the new value and it >>
should<br>
>>> work the same >> >> regards >>
>> David >> >> >> On<br>
>>> 09/01/2013 20:21, heckj wrote:<br>
>>>>>><br>
>>>>>> Given that domains are a segmentation of projects/tenants,<br>
>>>>>> then I<br>
>>> wouldn't >>> expect to want to change it from
a project_id<br>
>>> representation to anything >>> else.<br>
>>>>>><br>
>>>>>> -joe<br>
>>>>>><br>
>>>>>> On Jan 9, 2013, at 12:13 PM, Chuck Thier <cthier@gmail.com<br>
>> <</font></tt><a href=mailto:cthier@gmail.com><tt><font size=2>mailto:cthier@gmail.com</font></tt></a><tt><font size=2>>>
wrote:<br>
>>>>>>><br>
>>>>>>> Things are always easy, until you start thinking
about<br>
>>>>>>> backwards compatibility. The storage
urls for swift with<br>
>>>>>>> keystone are<br>
>>> currently >>>> keyed off of the tenant_id
(soon to be<br>
>>> project_id), so you end up with >>>> an
endpoint url that looks<br>
>>> something like >>>> http://{SWIFT_IP}/v1/AUTH_{TENANT_ID}
if<br>
>>> you change that by adding<br>
>>>>>>> the domain, then you break any current users
in your<br>
>>>>>>> system, and<br>
>>> you >>>> can't use v2 and v3 auth contracts
simultaneously.<br>
>>>>>>><br>
>>>>>>> -- Chuck<br>
>>>>>>><br>
>>>>>>> On Wed, Jan 9, 2013 at 1:37 PM, 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>
>>>>>>>> I would have thought that the solution
is conceptually<br>
>>>>>>>> rather straightforward. If domains can
have their own<br>
>>>>>>>> project names and usernames, >>>>>
then you prefix the<br>
>>>>>>>> names with the domain ID<br>
>>> or domain name to make them >>>>> globally
unique again.<br>
>>>>>>>><br>
>>>>>>>> regards<br>
>>>>>>>><br>
>>>>>>>> David<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> On 09/01/2013 19:14, Yee, Guang wrote:<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Yes. Swift ACLs <tenant_id>:<user_name>,<br>
>>> <tenant_id>:<user_name>, and >>>>>>
*:<user_name> will be<br>
>>> impacted if project (formely tenant) name and >>>>>>
user<br>
>>> >>>>>> name are no longer globally unique.
We'll need to figure<br>
>>> out a >>>>>> migration<br>
>>>>>>>>> path before relaxing that constraint.<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Guang<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> -----Original Message----- From: Chuck
Thier<br>
>>>>>>>>> [</font></tt><a href=mailto:cthier@gmail.com><tt><font size=2>mailto:cthier@gmail.com</font></tt></a><tt><font size=2><br>
>> <</font></tt><a href=mailto:cthier@gmail.com><tt><font size=2>mailto:cthier@gmail.com</font></tt></a><tt><font size=2>>]
>>>>>> Sent:<br>
>>> Wednesday, January 09, 2013 10:48 AM >>>>>>
To: OpenStack<br>
>>> Development Mailing List >>>>>> Subject:
Re: [openstack-dev]<br>
>>> [swift] [keystone] Keystone v3 API domains >>>>>>
in >>>>>><br>
>>> Swift >>>>>> >>>>>>
Se responses inline:<br>
>>>>>>>>><br>
>>>>>>>>> On Wed, Jan 9, 2013 at 4:01 AM, Henry
Nash<br>
>>> <henryn@linux.vnet.ibm.com <</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>
>>>>>>>> wrote:<br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> So there are a couple of issues
intertwined in this<br>
>>>>>>>>>> thread:<br>
>>>>>>>>>><br>
>>>>>>>>>> 1) Uniqueness of identifiers in
Swift given the<br>
>>>>>>>>>> keystone<br>
>>> Identity v3 >>>>>>> api.<br>
>>>>>>>>>> This is the issue of whether Swift
uses tenant<br>
>>>>>>>>>> names (now<br>
>>> called >>>>>>> project >>>>>>>
names) at all to uniquely<br>
>>> identify any objects - if it did, then it >>>>>>>
would >>>>>>><br>
>>> need to also consider storing a domain name or id. From
the<br>
>>> >>>>>>> discussion,<br>
>>>>>>>>>>>>>>>>>>>>>
it >>>>>>> >>>>>>>
>>>>>>><br>
>>>>>>>>>>>>>>>>>>>>>
sounds like<br>
>>> tenant/project ID is used instead, which (from a >>>>>>><br>
>>> uniqueness<br>
>>>>>>>>>> point of view) is fine. A
separate issue exists<br>
>>>>>>>>>> needs to be<br>
>>> discussed >>>>>>> around swift
ACLs and whether username<br>
>>> potentially becoming unique >>>>>>>
only >>>>>>> within a<br>
>>> domain will have an impact.<br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> For AuthN, you are correct, in that
it only relies<br>
>>>>>>>>> on<br>
>>> tenant/project >>>>>> ID. So,
nothing has to be changed from<br>
>>> that perspective. AuthZ is a >>>>>>
little more tricky. For<br>
>>> ACLs with keystone, they are set as >>>>>>
TENANT:USER in any of<br>
>>> the following patterns:<br>
>>>>>>>>><br>
>>>>>>>>> *:user_name - that user from any tenant
has access<br>
>>>>>>>>> >>>>>><br>
>>> tenant_id:user_name - that user from that tenant id has access<br>
>>> >>>>>> tenant_name:user_name - that user
from that tenant name<br>
>>> has access<br>
>>>>>>>>>>>>>>> If project_name
will not be unique in v3,<br>
>>>>>>>>>>>>>>> then the<br>
>>>>>>>>> tenant_name:user_name format may have
to be<br>
>>>>>>>>> deprecated.<br>
>>>>>>>>><br>
>>>>>>>>> I would be interested to hear from
providers that are<br>
>>>>>>>>> using<br>
>>> keystone >>>>>> with swift and hear
which of the above use<br>
>>> cases<br>
>> they are using.<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>>> 2) Given that keystone identity
v3 domains are<br>
>>>>>>>>>> likely to be<br>
>>> usually >>>>>>> used >>>>>>
>>>>>> >>>>>> to >>>>>>><br>
>>> >>>>>>><br>
>>>>>>>>>> represent an enterprise (or "account
holder" in<br>
>>>>>>>>>> common cloud terminology) >>>>>>>
and contain the<br>
>>>>>>>>>> collection of projects<br>
>>> owned by that enterprise, is it >>>>>>>
important for Swift to<br>
>>> have that domain knowledge? Will there be >>>>>>
>>>>>><br>
>>> >>>>>> operations >>>>>>>
>>>>>>> >>>>>>> either
within swift<br>
>>> (or more likely layered on top of swift) that need >>>>>><br>
>>> >>>>>> >>>>>> that<br>
>>>>>>>>>>>>>>>>>>>>>>>>
information? E.g. How<br>
>>>>>>>>>>>>>>>>>>>>>>>>
would someone layer a<br>
>>> billing engine on top of >>>>>> >>>>>>
>>>>>> swift >>>>>>><br>
>>>>>>>>>>>>>>>>> that
could collate all the swift<br>
>>>>>>>>>>>>>>>>> containers
that were<br>
>>> part of one >>>>>>> domain?<br>
>>>>>>>>>> Obviously that engine could call
keystone with<br>
>>>>>>>>>> each<br>
>>> project_id in turn >>>>>>> and
>>>>>>> find the<br>
>>> domain_id.....but that sounds pretty inefficient.<br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> As is, containers can already be collated
for a<br>
>>>>>>>>> given<br>
>>> tenant/project >>>>>> id. The
containers for a domain is then<br>
>>> an aggregate of the project >>>>>>
ids associated to that<br>
>>> domain.<br>
>>>>>>>>><br>
>>>>>>>>> I think the default should be that
domains are not<br>
>>>>>>>>> mapped in<br>
>> swift.<br>
>>> I<br>
>>>>>>>>> believe that this will also be required
to<br>
>>>>>>>>> facilitate<br>
>>> backwards >>>>>> compatibility, which
brings up another<br>
>>> interesting question -- Is >>>>>>
there an expectation that<br>
>>> people will be able to run keystone auth >>>>>>
v2.0 and v3.0<br>
>>> side by side?<br>
>>>>>>>>><br>
>>>>>>>>> -- Chuck<br>
>>>>>>>>><br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> OpenStack-dev mailing list<br>
>>>>>>>>> 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<br>
>>>>>>>>> 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>
>>>>>>>> OpenStack-dev mailing list<br>
>>>>>>>> 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>
>>>>>>> OpenStack-dev mailing list<br>
>>>>>>> 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<br>
>>>>>> 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>
>>>>> _______________________________________________ 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>
>>>> _______________________________________________ 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>
>>> _______________________________________________ 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>
> [attachment "smime.p7s" deleted by Alexandra<br>
> Shulman-Peleg/Haifa/IBM]<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>
>>> _______________________________________________ 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>
>> _______________________________________________ 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>
>> _______________________________________________ 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<br>
>><br>
>> 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>
>><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<br>
>> 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>
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>
</font></tt>
<br>