<html><head><base href="x-msg://1677/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">So there are a couple of issues intertwined in this thread:<div><br></div><div>1) Uniqueness of identifiers in Swift given the keystone Identity v3 api. This is the issue of whether Swift uses tenant names (now called project names) at all to uniquely identify any objects - if it did, then it would need to also consider storing a domain name or id. From the discussion, it sounds like tenant/project ID is used instead, which (from a uniqueness point of view) is fine. A separate issue exists needs to be discussed around swift ACLs and whether username potentially becoming unique only within a domain will have an impact.</div><div><br></div><div>2) Given that keystone identity v3 domains are likely to be usually used to represent an enterprise (or "account holder" in common cloud terminology) and contain the collection of projects owned by that enterprise, is it important for Swift to have that domain knowledge? Will there be operations either within swift (or more likely layered on top of swift) that need that information? E.g. How would someone layer a billing engine on top of swift that could collate all the swift containers that were part of one domain? Obviously that engine could call keystone with each project_id in turn and find the domain_id.....but that sounds pretty inefficient.</div><div><br></div><div>Henry</div><div><br><div><div>On 9 Jan 2013, at 00:08, Yee, Guang wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1" style="page: WordSection1; "><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Yeah, I don’t see a need to add domain_id to Swift account either as project ID is globally unique. Since domain name/id are returned as part of token validation, you may be able to use them with Swift ACLs. I am sure Swift ACLs will need to be updated if and when we remove the globally uniqueness name requirement.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Guang<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "><span class="Apple-converted-space"> </span>Dolph Mathews [mailto:dolph.mathews@gmail.com]<span class="Apple-converted-space"> </span><br><b>Sent:</b><span class="Apple-converted-space"> </span>Tuesday, January 08, 2013 2:38 PM<br><b>To:</b><span class="Apple-converted-space"> </span>OpenStack Development Mailing List<br><b>Subject:</b><span class="Apple-converted-space"> </span>Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift<o:p></o:p></span></div></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">TENANT_ID in v2 is exactly equal to PROJECT_ID in v3. ID's are guaranteed to be globally unique (implemented as service-defined UUID's) and are url-friendly.<o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">Names in keystone are freeform, user-supplied unicode strings. They may not work in URL's without proper encoding and may collide in the future...<o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">On that note, TENANT_NAME in v2 will become PROJECT_NAME in v3, however we're also talking about namespacing project names to the owning domain, so that two domains may have otherwise conflicting project names. Once we open up the namespace, we can't go back, so we're going about it very carefully. This may apply to user names, as well, but that's a subtly different conversation.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">If we do make this change then you also need to identify the domain for a project name to be meaningful.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">ID's will still uniquely identify a project regardless of domain or deployment.<o:p></o:p></div></div><div><div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">-Dolph<o:p></o:p></div></div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 12pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></p><div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">On Tue, Jan 8, 2013 at 2:11 PM, Alexandra Shulman-Peleg <<a href="mailto:SHULMANA@il.ibm.com" target="_blank" style="color: blue; text-decoration: underline; ">SHULMANA@il.ibm.com</a>> wrote:<o:p></o:p></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-family: Arial, sans-serif; ">I think that there is a problem with simply using<span class="Apple-converted-space"> </span></span><a href="https://swift/AUTH_" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">https://SWIFT/AUTH_</span></tt></a><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">{PROJECT_ID}</span></tt><span style="font-family: Arial, sans-serif; "><span class="Apple-converted-space"> </span>instead of the current </span><a href="https://swift/AUTH_" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">https://SWIFT/AUTH_</span></tt></a><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">{TENANT_ID}<span class="Apple-converted-space"> </span></span></tt><span style="font-family: Arial, sans-serif; ">since it will loose the proper level in the hierarchy. We need something that will represent the hosted enterprises and this is the goal of domains. Project are more fine-grained and can represent departments or projects. For example, following the description of Henry if two different enterprises with use the project name "Test" both with map to<span class="Apple-converted-space"> </span></span><a href="https://swift/AUTH_" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">https://SWIFT/AUTH_</span></tt></a><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">Test.<span class="Apple-converted-space"> </span></span></tt><br><br><span style="font-family: Arial, sans-serif; ">I think that we need to have both the domain id and the project id in the URL/account name. For example as</span><a href="https://swift/AUTH_" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">https://SWIFT/AUTH_</span></tt></a><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">{DOMAIN_ID}_{PROJECT_ID} or as<span class="Apple-converted-space"> </span></span></tt><a href="https://swift/" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">https://SWIFT/</span></tt></a><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">{DOMAIN_ID}_{PROJECT_ID}.<span class="Apple-converted-space"> </span></span></tt><span style="font-family: Arial, sans-serif; ">In the second option we may try using the existing reseller prefix mechanism to simplify the implementation. Having the doman_id in the account name/URL is important to isolate the accounts that belong to different domains and remove the requirements for the global uniqueness of project names.<span class="Apple-converted-space"> </span></span><br><br><span style="font-family: Arial, sans-serif; ">Best Regards,</span><span class="Apple-converted-space"> </span><br><span style="font-family: Arial, sans-serif; ">Alex.<span class="Apple-converted-space"> </span></span><br><br><br><br><span style="font-size: 7.5pt; font-family: Arial, sans-serif; color: rgb(95, 95, 95); ">From: </span><span style="font-size: 7.5pt; font-family: Arial, sans-serif; ">Chuck Thier <<a href="mailto:cthier@gmail.com" target="_blank" style="color: blue; text-decoration: underline; ">cthier@gmail.com</a>></span><span class="Apple-converted-space"> </span><br><span style="font-size: 7.5pt; font-family: Arial, sans-serif; color: rgb(95, 95, 95); ">To: </span><span style="font-size: 7.5pt; font-family: Arial, sans-serif; ">OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank" style="color: blue; text-decoration: underline; ">openstack-dev@lists.openstack.org</a>>,<span class="Apple-converted-space"> </span></span><br><span style="font-size: 7.5pt; font-family: Arial, sans-serif; color: rgb(95, 95, 95); ">Date: </span><span style="font-size: 7.5pt; font-family: Arial, sans-serif; ">08/01/2013 09:38 PM</span><span class="Apple-converted-space"> </span><br><span style="font-size: 7.5pt; font-family: Arial, sans-serif; color: rgb(95, 95, 95); ">Subject: </span><span style="font-size: 7.5pt; font-family: Arial, sans-serif; ">Re: [openstack-dev] [swift] [keystone] Keystone v3 API domains in Swift</span><o:p></o:p></div><div class="MsoNormal" align="center" style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; text-align: center; "><hr size="3" width="100%" noshade="" align="center" style="color: rgb(160, 160, 160); "></div><div><div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 12pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><br><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">Hi Henry,</span></tt><span style="font-size: 10pt; font-family: 'Courier New'; "><br><br><tt style="font-family: 'Courier New'; ">From a swift perspective, I think we are fine there, as we do not use</tt><br><tt style="font-family: 'Courier New'; ">the user name or project name anywhere. At the moment, I'm thinking</tt><br><tt style="font-family: 'Courier New'; ">that we can do auth in a similar way as we did with v2.0 api. An</tt><br><tt style="font-family: 'Courier New'; ">"account" in swift is still tied to the project_id (which used to be</tt><br><tt style="font-family: 'Courier New'; ">tennant_id), which is in the storage url like:</tt><br></span><a href="https://swift/AUTH_" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">https://SWIFT/AUTH_</span></tt></a><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">{PROJECT_ID}. Keystone middleware in swift</span></tt><span style="font-size: 10pt; font-family: 'Courier New'; "><br><tt style="font-family: 'Courier New'; ">validates that the given token has permission for the given Project</tt><br><tt style="font-family: 'Courier New'; ">ID.</tt><br><br><tt style="font-family: 'Courier New'; ">From this point of view domains are an abstract concept in keystone</tt><br><tt style="font-family: 'Courier New'; ">only, and wouldn't mean anything directly in swift.</tt><br><br><tt style="font-family: 'Courier New'; ">Please let me know if any of my assumptions are incorrect.</tt><br><br><tt style="font-family: 'Courier New'; ">Thanks,</tt><br><br><tt style="font-family: 'Courier New'; ">--</tt><br><tt style="font-family: 'Courier New'; ">Chuck</tt><br><br><tt style="font-family: 'Courier New'; ">On Tue, Jan 8, 2013 at 1:23 PM, Henry Nash <<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank" style="color: blue; text-decoration: underline; ">henryn@linux.vnet.ibm.com</a>> wrote:</tt><br><tt style="font-family: 'Courier New'; ">> Chuck,</tt><br><tt style="font-family: 'Courier New'; ">></tt><br><tt style="font-family: 'Courier New'; ">> So user_id and project_id are always globally unique - so we are safe there. The problem is when you specify user name or project name in the cases when we have to handle enterprises being represented by a domain and they insist that their name attributes (e.g. user names, project names etc.) be private to that domain (e.g. "what do you mean I can't call my project "Test" because some other customer in another domain got there first!?!"). See the following blueprint which introduces this ability as optional for domains:<span class="Apple-converted-space"> </span></tt></span><a href="https://review.openstack.org/#/c/18805/" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">https://review.openstack.org/#/c/18805/</span></tt></a><span style="font-size: 10pt; font-family: 'Courier New'; "><br><tt style="font-family: 'Courier New'; ">></tt><br><tt style="font-family: 'Courier New'; ">> For such domains, we cannot assume that user_name or project_name (or tenant_name as it used to be called) are globally unique. "Domain_name (or id) plus user_name" as well as "Domain_name (or id) plus project_name" will be unique however.</tt><br><tt style="font-family: 'Courier New'; ">></tt><br><tt style="font-family: 'Courier New'; ">> Henry</tt><br><tt style="font-family: 'Courier New'; ">> On 8 Jan 2013, at 19:05, Chuck Thier wrote:</tt><br><tt style="font-family: 'Courier New'; ">></tt><br><tt style="font-family: 'Courier New'; ">>> Yeah, I was hoping for more clarity, as it would help to figure out</tt><br><tt style="font-family: 'Courier New'; ">>> how to best map the concepts in swift. A couple of quick questions</tt><br><tt style="font-family: 'Courier New'; ">>> come to mind. When a request is validated, is the domain required, or</tt><br><tt style="font-family: 'Courier New'; ">>> is a user_id and project_id sufficient? Is the concept of a domain</tt><br><tt style="font-family: 'Courier New'; ">>> useful in the context of swift?</tt><br><tt style="font-family: 'Courier New'; ">>></tt><br><tt style="font-family: 'Courier New'; ">>> --</tt><br><tt style="font-family: 'Courier New'; ">>> Chuck</tt><br><tt style="font-family: 'Courier New'; ">>></tt><br><tt style="font-family: 'Courier New'; ">>> On Tue, Jan 8, 2013 at 11:37 AM, heckj <<a href="mailto:heckj@mac.com" target="_blank" style="color: blue; text-decoration: underline; ">heckj@mac.com</a>> wrote:</tt><br><tt style="font-family: 'Courier New'; ">>>> The best is probably<span class="Apple-converted-space"> </span></tt></span><a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md</span></tt></a><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">, but it's a bit light on use-cases around the concepts I'm afraid.</span></tt><span style="font-size: 10pt; font-family: 'Courier New'; "><br><tt style="font-family: 'Courier New'; ">>>></tt><br><tt style="font-family: 'Courier New'; ">>>> -joe</tt><br><tt style="font-family: 'Courier New'; ">>>></tt><br><tt style="font-family: 'Courier New'; ">>>> On Jan 8, 2013, at 9:19 AM, Chuck Thier <<a href="mailto:cthier@gmail.com" target="_blank" style="color: blue; text-decoration: underline; ">cthier@gmail.com</a>> wrote:</tt><br><tt style="font-family: 'Courier New'; ">>>>> Is there documentation anywhere that defines all of these, and the use</tt><br><tt style="font-family: 'Courier New'; ">>>>> cases? That would help us figure out how to map these concepts to</tt><br><tt style="font-family: 'Courier New'; ">>>>> swift.</tt><br><tt style="font-family: 'Courier New'; ">>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>> --</tt><br><tt style="font-family: 'Courier New'; ">>>>> Chuck</tt><br><tt style="font-family: 'Courier New'; ">>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>> On Tue, Jan 8, 2013 at 11:13 AM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com" target="_blank" style="color: blue; text-decoration: underline; ">dolph.mathews@gmail.com</a>> wrote:</tt><br><tt style="font-family: 'Courier New'; ">>>>>> I think it would be practical to expose the authenticated user's DOMAIN_ID</tt><br><tt style="font-family: 'Courier New'; ">>>>>> and DOMAIN_NAME into the request environment for the underlying service /</tt><br><tt style="font-family: 'Courier New'; ">>>>>> middleware to consume, as we do today with TENANT_ID / TENANT_NAME (soon to</tt><br><tt style="font-family: 'Courier New'; ">>>>>> be deprecated in favor of PROJECT_ID / PROJECT_NAME).</tt><br><tt style="font-family: 'Courier New'; ">>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>> -Dolph</tt><br><tt style="font-family: 'Courier New'; ">>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>> On Tue, Jan 8, 2013 at 7:22 AM, Alexandra Shulman-Peleg</tt><br><tt style="font-family: 'Courier New'; ">>>>>> <<a href="mailto:SHULMANA@il.ibm.com" target="_blank" style="color: blue; text-decoration: underline; ">SHULMANA@il.ibm.com</a>> wrote:</tt><br><tt style="font-family: 'Courier New'; ">>>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>>> Hi,</tt><br><tt style="font-family: 'Courier New'; ">>>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>>> As most of you know, Keystone v3 API will introduce the notions of</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> "domains" and "projects" which will replace the existing notion of tenants.</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> It is important to allow using the same concepts in Swift. Since different</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> domains may represent different companies, it is important to allow</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> reflecting the Keystone "domain name" in the Swift "account name", providing</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> an option to isolate the requests of different domains. Are there existing</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> plans of adjusting Swift to Keystone v3 API? If not, I would like to start</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> discussing the potential solutions.</tt><br><tt style="font-family: 'Courier New'; ">>>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>>> Thank you all,</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> Alex.</tt><br><tt style="font-family: 'Courier New'; ">>>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>>> ----------------------------------------------------------</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> Alexandra Shulman-Peleg, PhD</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> Storage Research, Cloud Platforms Dept.</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> IBM Haifa Research Lab</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> Tel:<span class="Apple-converted-space"> </span><a href="tel:%2B972-3-7689530" target="_blank" style="color: blue; text-decoration: underline; ">+972-3-7689530</a><span class="Apple-converted-space"> </span>| Fax:<span class="Apple-converted-space"> </span><a href="tel:%2B972-3-7689545" target="_blank" style="color: blue; text-decoration: underline; ">+972-3-7689545</a></tt><br><tt style="font-family: 'Courier New'; ">>>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>>> _______________________________________________</tt><br><tt style="font-family: 'Courier New'; ">>>>>>> OpenStack-dev mailing list</tt><br><tt style="font-family: 'Courier New'; ">>>>>>><span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" style="color: blue; text-decoration: underline; ">OpenStack-dev@lists.openstack.org</a></tt><br><tt style="font-family: 'Courier New'; ">>>>>>><span class="Apple-converted-space"> </span></tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style="font-size: 10pt; font-family: 'Courier New'; "><br><tt style="font-family: 'Courier New'; ">>>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>>> _______________________________________________</tt><br><tt style="font-family: 'Courier New'; ">>>>>> OpenStack-dev mailing list</tt><br><tt style="font-family: 'Courier New'; ">>>>>><span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" style="color: blue; text-decoration: underline; ">OpenStack-dev@lists.openstack.org</a></tt><br><tt style="font-family: 'Courier New'; ">>>>>><span class="Apple-converted-space"> </span></tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style="font-size: 10pt; font-family: 'Courier New'; "><br><tt style="font-family: 'Courier New'; ">>>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>></tt><br><tt style="font-family: 'Courier New'; ">>>>> _______________________________________________</tt><br><tt style="font-family: 'Courier New'; ">>>>> OpenStack-dev mailing list</tt><br><tt style="font-family: 'Courier New'; ">>>>><span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" style="color: blue; text-decoration: underline; ">OpenStack-dev@lists.openstack.org</a></tt><br><tt style="font-family: 'Courier New'; ">>>>><span class="Apple-converted-space"> </span></tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style="font-size: 10pt; font-family: 'Courier New'; "><br><tt style="font-family: 'Courier New'; ">>>></tt><br><tt style="font-family: 'Courier New'; ">>>></tt><br><tt style="font-family: 'Courier New'; ">>>> _______________________________________________</tt><br><tt style="font-family: 'Courier New'; ">>>> OpenStack-dev mailing list</tt><br><tt style="font-family: 'Courier New'; ">>>><span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" style="color: blue; text-decoration: underline; ">OpenStack-dev@lists.openstack.org</a></tt><br><tt style="font-family: 'Courier New'; ">>>><span class="Apple-converted-space"> </span></tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style="font-size: 10pt; font-family: 'Courier New'; "><br><tt style="font-family: 'Courier New'; ">>></tt><br><tt style="font-family: 'Courier New'; ">>> _______________________________________________</tt><br><tt style="font-family: 'Courier New'; ">>> OpenStack-dev mailing list</tt><br><tt style="font-family: 'Courier New'; ">>><span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" style="color: blue; text-decoration: underline; ">OpenStack-dev@lists.openstack.org</a></tt><br><tt style="font-family: 'Courier New'; ">>><span class="Apple-converted-space"> </span></tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style="font-size: 10pt; font-family: 'Courier New'; "><br><tt style="font-family: 'Courier New'; ">>></tt><br><tt style="font-family: 'Courier New'; ">></tt><br><tt style="font-family: 'Courier New'; ">></tt><br><tt style="font-family: 'Courier New'; ">> _______________________________________________</tt><br><tt style="font-family: 'Courier New'; ">> OpenStack-dev mailing list</tt><br><tt style="font-family: 'Courier New'; ">><span class="Apple-converted-space"> </span><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" style="color: blue; text-decoration: underline; ">OpenStack-dev@lists.openstack.org</a></tt><br><tt style="font-family: 'Courier New'; ">><span class="Apple-converted-space"> </span></tt></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style="font-size: 10pt; font-family: 'Courier New'; "><br><br><tt style="font-family: 'Courier New'; ">_______________________________________________</tt><br><tt style="font-family: 'Courier New'; ">OpenStack-dev mailing list</tt><br><tt style="font-family: 'Courier New'; "><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank" style="color: blue; text-decoration: underline; ">OpenStack-dev@lists.openstack.org</a></tt><br></span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" style="color: blue; text-decoration: underline; "><tt style="font-family: 'Courier New'; "><span style="font-size: 10pt; ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</span></tt></a><span style="font-size: 10pt; font-family: 'Courier New'; "><br><br></span><o:p></o:p></p></div></div><p class="MsoNormal" style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 12pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><br>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" style="color: blue; text-decoration: underline; ">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" style="color: blue; text-decoration: underline; ">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div></div></div></div></div>_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</div></span></blockquote></div><br></div></body></html>