<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/01/2013 01:27 PM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gXGaJtzgem9B+i-K8owo1-OmSsedmk146f5kiMzBLA4Jw@mail.gmail.com"
type="cite">
<div dir="ltr">It's not; we dropped it from the list of required
attributes, but you can still provide one.</div>
</blockquote>
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>
<blockquote
cite="mid:CAC=h7gXGaJtzgem9B+i-K8owo1-OmSsedmk146f5kiMzBLA4Jw@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br clear="all">
<div>
<div><br>
</div>
-Dolph</div>
<br>
<br>
<div class="gmail_quote">On Fri, Feb 1, 2013 at 11:56 AM, Ali,
Haneef <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:haneef.ali@hp.com" target="_blank">haneef.ali@hp.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Are you sure that token contains email-address? I don't see
that as required field in user creation in v3.<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">Haneef<br>
</font></span>
<div class="im HOEnZb"><br>
-----Original Message-----<br>
From: David Chadwick [mailto:<a moz-do-not-send="true"
href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>]<br>
</div>
<div class="im HOEnZb">Sent: Friday, February 01, 2013 3:06
AM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] [swift] [keystone] Keystone
v3 API domains in Swift<br>
<br>
</div>
<div class="HOEnZb">
<div class="h5">Since the token contains the email address
of the user, isnt it 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 exact<br>
> syntax of ACLs that can be used when removing the
global uniqueness<br>
> constraint on user names. I wander whether we
really need to prefix<br>
> both the project_name and the username with the
domain id? Especially,<br>
> since on ACLs we mainly need to properly identify
the user and not the project.<br>
> So the notion of a project may not be required in
this context? For<br>
> example, in NFSv4 ACLs (also adopted by CDMI) users
are identified by<br>
> username@domain. So I wander whether on ACLs, in V3
we can simply<br>
> switch from tenant_id:username to
domain_id:username? This seems to<br>
> fulfill the identification requirements and will
give a very simple<br>
> solution for the migration of existing v2 customers
to private domains<br>
> in V3 - assigning the new domain_id to match the
old tenant_id will<br>
> allow preserving all of the stored containers
without the need to<br>
> modify the containers' meta data.<br>
><br>
> Best Regards,<br>
> Alex.<br>
><br>
><br>
><br>
> From: "Yee, Guang" <<a moz-do-not-send="true"
href="mailto:guang.yee@hp.com">guang.yee@hp.com</a>><br>
> To: OpenStack Development Mailing List<br>
> <<a moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>,<br>
> Date: 11/01/2013 10:31 PM<br>
> Subject: Re: [openstack-dev] [swift] [keystone]
Keystone v3 API<br>
> domains in Swift<br>
>
----------------------------------------------------------------------<br>
> --<br>
><br>
><br>
><br>
> As long as Swift URL stay the same we should be OK.
Frankly, there<br>
> aren't any strong arguments for changing it at this
point. Whenever we<br>
> remove the globally uniqueness constraint on names,
new Swift ACLs<br>
> probably will need to switch over to using
namespacing.<br>
><br>
> domain_name.project_name:domain_name.username<br>
><br>
> something like that. Existing Swift ACLs should
work fine since if the<br>
> given domain is the default (migrated) system
domain, auth_token<br>
> middleware should not set the domains headers.<br>
><br>
><br>
> Guang<br>
><br>
><br>
> -----Original Message-----<br>
> From: David Chadwick [mailto:<a
moz-do-not-send="true"
href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>]<br>
> Sent: Friday, January 11, 2013 8:36 AM<br>
> To: OpenStack Development Mailing List<br>
> Subject: Re: [openstack-dev] [swift] [keystone]
Keystone v3 API<br>
> 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>
> >
(<a class="moz-txt-link-freetext" href="https://">https://</a>{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 to<br>
> all > agree that we can continue this pattern
with the V3 API. The<br>
> one > concern that I still have is how the ACLs
will work, and<br>
> weather or > not that will need to change.<br>
> ><br>
> > I'm also curious how the Keystone V3 API will
work alongside V2 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 v3<br>
> API system only, with domains added, should work OK
tomorrow otherwise<br>
> the v3 API has problems 3. So the main point as you
say is how do v2<br>
> and v3 systems interwork. I suggest there is an
intercept module, say<br>
> in the Keystone pipeline, that knows it is
operating in a v2/v3<br>
> environment, and when it receives a v2 request
already containing a<br>
> tenant_ID it knows it will comprise domain:project
and it can unpack<br>
> it, and give the separate elements to the rest of
the V3 code for<br>
> processing as in a v3 system. When the intercept
module receives a v2<br>
> request that needs a tenant ID returning to it, it
will encode up the<br>
> domain and project as a tenant ID, and return this
to the v2 client.<br>
> The 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>
> > --<br>
> > Chuck<br>
> ><br>
> > On Thu, Jan 10, 2013 at 4:16 AM, David
Chadwick<br>
> <<a moz-do-not-send="true"
href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>><br>
> wrote:<br>
> >> You have to ask, where does the Swift
client get the tenant_Id from?<br>
> Isnt<br>
> it<br>
> >> Keystone? So if Keystone returns
project_ID:tenant_Id to swift as<br>
> the >> project_id string, then Swift can
continue to use this as if<br>
> nothing has >> changed. Its just a string
whose content has no<br>
> meaning to Swift, but whose >> content does
have meaning to Keystone.<br>
> The Swift policy simply needs to >> change
the value of the tenant_id<br>
> in its policy to the new value and it >>
should work the same >> >><br>
> regards >> >> David >>
>> >> On 09/01/2013 20:21, heckj wrote:<br>
> >>><br>
> >>> Given that domains are a segmentation
of projects/tenants, 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 <<a moz-do-not-send="true"
href="mailto:cthier@gmail.com">cthier@gmail.com</a>>
wrote:<br>
> >>>><br>
> >>>> Things are always easy, until you
start thinking about backwards<br>
> >>>> compatibility. The storage urls
for swift with keystone are<br>
> currently >>>> keyed off of the
tenant_id (soon to be project_id), so<br>
> you end up with >>>> an endpoint url
that looks something like >>>><br>
> <a class="moz-txt-link-freetext" href="http://">http://</a>{SWIFT_IP}/v1/AUTH_{TENANT_ID} if you
change that by adding<br>
> >>>> the domain, then you break any
current users in your system, and<br>
> you >>>> can't use v2 and v3 auth
contracts simultaneously.<br>
> >>>><br>
> >>>> --<br>
> >>>> Chuck<br>
> >>>><br>
> >>>> On Wed, Jan 9, 2013 at 1:37 PM,
David Chadwick<br>
> <<a moz-do-not-send="true"
href="mailto:d.w.chadwick@kent.ac.uk">d.w.chadwick@kent.ac.uk</a>>
>>>> wrote:<br>
> >>>>><br>
> >>>>> I would have thought that the
solution is conceptually rather<br>
> >>>>> straightforward. If domains
can have their own project names and<br>
> >>>>> usernames,
>>>>> then you prefix the 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
impacted if<br>
> project (formely tenant) name and
>>>>>> user >>>>>>
name are no<br>
> longer globally unique. We'll need to figure out a
>>>>>> migration<br>
> >>>>>> path before relaxing that
constraint.<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> Guang<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> -----Original
Message-----<br>
> >>>>>> From: Chuck Thier
[mailto:<a moz-do-not-send="true"
href="mailto:cthier@gmail.com">cthier@gmail.com</a>]
>>>>>> Sent:<br>
> Wednesday, January 09, 2013 10:48 AM
>>>>>> To: OpenStack Development<br>
> Mailing List >>>>>> Subject: Re:
[openstack-dev] [swift] [keystone]<br>
> Keystone v3 API domains >>>>>>
in >>>>>> Swift
>>>>>> >>>>>> Se<br>
> responses inline:<br>
> >>>>>><br>
> >>>>>> On Wed, Jan 9, 2013 at
4:01 AM, Henry Nash<br>
> <<a moz-do-not-send="true"
href="mailto:henryn@linux.vnet.ibm.com">henryn@linux.vnet.ibm.com</a>>
>>>>>> wrote:<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>> So there are a couple
of issues intertwined in this thread:<br>
> >>>>>>><br>
> >>>>>>> 1) Uniqueness of
identifiers in Swift given the keystone<br>
> Identity v3 >>>>>>> api.<br>
> >>>>>>> This is the issue of
whether Swift uses tenant names (now<br>
> called >>>>>>> project
>>>>>>> names) at all to uniquely
identify<br>
> any objects - if it did, then it
>>>>>>> would
>>>>>>> need to also<br>
> consider storing a domain name or id. From the
>>>>>>> discussion,<br>
> >>>>>> >>>>>>
>>>>>> it
>>>>>>>
>>>>>>>
>>>>>>> sounds like<br>
> tenant/project ID is used instead, which (from a
>>>>>>> uniqueness<br>
> >>>>>>> point of view) is
fine. A separate issue exists needs to be<br>
> discussed >>>>>>> around
swift ACLs and whether username potentially<br>
> becoming unique >>>>>>> only
>>>>>>> within a domain will have
an<br>
> impact.<br>
> >>>>>>><br>
> >>>>>><br>
> >>>>>> For AuthN, you are
correct, in that it only relies on<br>
> tenant/project >>>>>> ID. So,
nothing has to be changed from that<br>
> perspective. AuthZ is a >>>>>>
little more tricky. For ACLs with<br>
> keystone, they are set as >>>>>>
TENANT:USER in any of the following<br>
> patterns:<br>
> >>>>>><br>
> >>>>>> *:user_name - that user
from any tenant has access >>>>>><br>
> tenant_id:user_name - that user from that tenant id
has access >>>>>><br>
> tenant_name:user_name - that user from that tenant
name has access<br>
> >>>>>> >>>>>>
If project_name will not be unique in v3, then the<br>
> >>>>>> tenant_name:user_name
format may have to be deprecated.<br>
> >>>>>><br>
> >>>>>> I would be interested to
hear from providers that are using<br>
> keystone >>>>>> with swift and
hear which of the above use cases they are using.<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>>> 2) Given that
keystone identity v3 domains are likely to be<br>
> usually >>>>>>> used
>>>>>> >>>>>>
>>>>>> to
>>>>>>>
>>>>>>><br>
> >>>>>>> represent an
enterprise (or "account holder" in common cloud<br>
> >>>>>>> terminology)
>>>>>>> and contain the collection
of projects<br>
> owned by that enterprise, is it
>>>>>>> important for Swift to
have<br>
> that domain knowledge? Will there be
>>>>>> >>>>>>
>>>>>><br>
> operations >>>>>>>
>>>>>>>
>>>>>>> either within swift (or
more<br>
> likely layered on top of swift) that need
>>>>>> >>>>>>
>>>>>> that<br>
> >>>>>>>
>>>>>>>
>>>>>>> information? E.g. How
would someone layer a<br>
> billing engine on top of >>>>>>
>>>>>> >>>>>>
swift >>>>>>><br>
> >>>>>>>
>>>>>>> that could collate all the
swift containers that were<br>
> part of one >>>>>>> domain?<br>
> >>>>>>> Obviously that engine
could call keystone with each<br>
> project_id in turn >>>>>>>
and >>>>>>> find the
domain_id.....but<br>
> that sounds pretty inefficient.<br>
> >>>>>>><br>
> >>>>>><br>
> >>>>>> As is, containers can
already be collated for a given<br>
> tenant/project >>>>>> id. The
containers for a domain is then an<br>
> aggregate of the project >>>>>>
ids associated to that domain.<br>
> >>>>>><br>
> >>>>>> I think the default
should be that domains are not mapped in swift.<br>
> I<br>
> >>>>>> believe that this will
also be required to facilitate<br>
> backwards >>>>>> compatibility,
which brings up another interesting<br>
> question -- Is >>>>>> there an
expectation that people will be able<br>
> to run keystone auth >>>>>> v2.0
and v3.0 side by side?<br>
> >>>>>><br>
> >>>>>> --<br>
> >>>>>> Chuck<br>
> >>>>>><br>
> >>>>>>
_______________________________________________<br>
> >>>>>> OpenStack-dev mailing
list<br>
> >>>>>> <a
moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
>>>>>><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>>
_______________________________________________<br>
> >>>>>> OpenStack-dev mailing
list<br>
> >>>>>> <a
moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
>>>>>><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>>>><br>
> >>>>><br>
> >>>>>
_______________________________________________<br>
> >>>>> OpenStack-dev mailing list<br>
> >>>>> <a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
>>>>><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>><br>
> >>>><br>
> >>>>
_______________________________________________<br>
> >>>> OpenStack-dev mailing list<br>
> >>>> <a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
>>>><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >>><br>
> >>><br>
> >>>
_______________________________________________<br>
> >>> OpenStack-dev mailing list<br>
> >>> <a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
>>><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >><br>
> >>
_______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >> <a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> >> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> >
_______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> [attachment "smime.p7s" deleted by Alexandra
Shulman-Peleg/Haifa/IBM]<br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>