Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Hi Folks,
As we have discussed in the last Keystone meeting, we created an etherpad
with the alternatives to solve this problem:
https://etherpad.openstack.org/p/reseller-project-token
We have also decided to take a vote to choose the best option in the next
Keystone Meeting (#openstack-meeting - June 16th - 18:00 UTC).
It would be great if you could take a look before the meeting, so we could
discuss and improve this document before the vote.
Best regards,
On Tue, Jun 9, 2015 at 12:12 PM Dolph Mathews dolph.math...@gmail.com
wrote:
On Mon, Jun 8, 2015 at 10:44 PM, Jamie Lennox jamielen...@redhat.com
wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk
To: openstack-dev@lists.openstack.org
Sent: Saturday, 6 June, 2015 6:01:10 PM
Subject: Re: [openstack-dev] [keystone][reseller] New way to get a
project scoped token by name
On 06/06/2015 00:24, Adam Young wrote:
On 06/05/2015 01:15 PM, Henry Nash wrote:
I am sure I have missed something along the way, but can someone
explain to me why we need this at all. Project names are unique
within a domain, with the exception of the project that is acting as
its domain (i.e. they can only every be two names clashing in a
hierarchy at the domain level and below). So why isn’t specifying
“is_domain=True/False” sufficient in an auth scope along with the
project name?
The limitation of Project names are unique within a domain is
artificial and somethi8ng we should not be enforcing. Names should
only
be unique within parent project.
+++1
I said the exact same thing as Henry in the other thread that seems to be
on the same topic. You're correct the limitation of Project names are
unique within a domain is completely artificial, but it's a constraint
that allows us to maintain the auth systems we currently have and will not
harm the reseller model (because they would be creating new domains).
It's also a constraint that we can relax later when multitenancy is a bit
more established and someone has a real issue with the limitation - it's
not something we can ever claw back again if we allow some looking up
projects by name with delimiters.
I think for the time being it's an artificial constraint we should
maintain.
+1
This whole thing started by trying to distinguish a domain from a
project within that domain that both have the same name. We can
special
case that, but it is not a great solution.
Henry
On 5 Jun 2015, at 18:02, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well
more to the point there should be a common one across OpenStack
installations to ensure we are providing a good and consistent (and
more to the point inter-operable) experience to our users. I'm
worried a custom defined delimiter (even at the domain level) is
going to make it difficult to consume this data outside of the
context of OpenStack (there are applications that are written to
use
the APIs directly).
We have one already. We are working JSON, and so instead of project
name being a string, it can be an array.
Nothing else is backwards compatible. Nothing else will ensure we
don;t break exisiting deployments.
Moving forward, we should support DNS notation, but it has to be an
opt in
The alternative is to explicitly list the delimiter in the project
(
e.g. {hierarchy: {delim: ., domain.project.project2}} ).
The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience
than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the
domain
entity? That seems like a good idea, although it does not
solve the
problem Morgan's mentioned that is the global hierarchy
delimiter.
There would be no global hierarchy delimiter. Each domain would
define
its own and this would be carried in the JSON as a separate
parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Sent via mobile
On Jun 9, 2015, at 05:44, Jamie Lennox jamielen...@redhat.com wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk
To: openstack-dev@lists.openstack.org
Sent: Saturday, 6 June, 2015 6:01:10 PM
Subject: Re: [openstack-dev] [keystone][reseller] New way to get a project
scoped token by name
On 06/06/2015 00:24, Adam Young wrote:
On 06/05/2015 01:15 PM, Henry Nash wrote:
I am sure I have missed something along the way, but can someone
explain to me why we need this at all. Project names are unique
within a domain, with the exception of the project that is acting as
its domain (i.e. they can only every be two names clashing in a
hierarchy at the domain level and below). So why isn’t specifying
“is_domain=True/False” sufficient in an auth scope along with the
project name?
The limitation of Project names are unique within a domain is
artificial and somethi8ng we should not be enforcing. Names should only
be unique within parent project.
+++1
I said the exact same thing as Henry in the other thread that seems to be on
the same topic. You're correct the limitation of Project names are unique
within a domain is completely artificial, but it's a constraint that allows
us to maintain the auth systems we currently have and will not harm the
reseller model (because they would be creating new domains).
It's also a constraint that we can relax later when multitenancy is a bit
more established and someone has a real issue with the limitation - it's not
something we can ever claw back again if we allow some looking up projects by
name with delimiters.
I think for the time being it's an artificial constraint we should maintain.
+1
This whole thing started by trying to distinguish a domain from a
project within that domain that both have the same name. We can special
case that, but it is not a great solution.
Henry
On 5 Jun 2015, at 18:02, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well
more to the point there should be a common one across OpenStack
installations to ensure we are providing a good and consistent (and
more to the point inter-operable) experience to our users. I'm
worried a custom defined delimiter (even at the domain level) is
going to make it difficult to consume this data outside of the
context of OpenStack (there are applications that are written to use
the APIs directly).
We have one already. We are working JSON, and so instead of project
name being a string, it can be an array.
Nothing else is backwards compatible. Nothing else will ensure we
don;t break exisiting deployments.
Moving forward, we should support DNS notation, but it has to be an
opt in
The alternative is to explicitly list the delimiter in the project (
e.g. {hierarchy: {delim: ., domain.project.project2}} ). The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the domain
entity? That seems like a good idea, although it does not
solve the
problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would
define
its own and this would be carried in the JSON as a separate
parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we
want a
domain, we
should always reference the namespace as we do today.
Basically, if we
ask for a project name we need to also provide it's
namespace (your
option #1). This clearly lines up with how we handle
projects in
domains
today.
I would, however, focus on how to represent the
namespace in a single
(usable) string. We've been delaying the work on this
for a while
since
we have historically not provided a clear way to delimit the
hierarchy.
If we solve the issue with what is the delimiter
between domain,
project, and subdomain/subproject, we end up solving the
usability
why not allow the top level domain/project to define the
delimiter for
its tree, and to carry the delimiter in the JSON as a new
parameter.
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
On Mon, Jun 8, 2015 at 10:44 PM, Jamie Lennox jamielen...@redhat.com
wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk
To: openstack-dev@lists.openstack.org
Sent: Saturday, 6 June, 2015 6:01:10 PM
Subject: Re: [openstack-dev] [keystone][reseller] New way to get a
project scoped token by name
On 06/06/2015 00:24, Adam Young wrote:
On 06/05/2015 01:15 PM, Henry Nash wrote:
I am sure I have missed something along the way, but can someone
explain to me why we need this at all. Project names are unique
within a domain, with the exception of the project that is acting as
its domain (i.e. they can only every be two names clashing in a
hierarchy at the domain level and below). So why isn’t specifying
“is_domain=True/False” sufficient in an auth scope along with the
project name?
The limitation of Project names are unique within a domain is
artificial and somethi8ng we should not be enforcing. Names should
only
be unique within parent project.
+++1
I said the exact same thing as Henry in the other thread that seems to be
on the same topic. You're correct the limitation of Project names are
unique within a domain is completely artificial, but it's a constraint
that allows us to maintain the auth systems we currently have and will not
harm the reseller model (because they would be creating new domains).
It's also a constraint that we can relax later when multitenancy is a bit
more established and someone has a real issue with the limitation - it's
not something we can ever claw back again if we allow some looking up
projects by name with delimiters.
I think for the time being it's an artificial constraint we should
maintain.
+1
This whole thing started by trying to distinguish a domain from a
project within that domain that both have the same name. We can special
case that, but it is not a great solution.
Henry
On 5 Jun 2015, at 18:02, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well
more to the point there should be a common one across OpenStack
installations to ensure we are providing a good and consistent (and
more to the point inter-operable) experience to our users. I'm
worried a custom defined delimiter (even at the domain level) is
going to make it difficult to consume this data outside of the
context of OpenStack (there are applications that are written to use
the APIs directly).
We have one already. We are working JSON, and so instead of project
name being a string, it can be an array.
Nothing else is backwards compatible. Nothing else will ensure we
don;t break exisiting deployments.
Moving forward, we should support DNS notation, but it has to be an
opt in
The alternative is to explicitly list the delimiter in the project (
e.g. {hierarchy: {delim: ., domain.project.project2}} ). The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the
domain
entity? That seems like a good idea, although it does not
solve the
problem Morgan's mentioned that is the global hierarchy
delimiter.
There would be no global hierarchy delimiter. Each domain would
define
its own and this would be carried in the JSON as a separate
parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we
want a
domain, we
should always reference the namespace as we do today.
Basically, if we
ask for a project name we need to also provide it's
namespace (your
option #1). This clearly lines up with how we handle
projects in
domains
today.
I would, however, focus on how to represent the
namespace in a single
(usable) string. We've been delaying the work on this
for a while
since
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk
To: openstack-dev@lists.openstack.org
Sent: Saturday, 6 June, 2015 6:01:10 PM
Subject: Re: [openstack-dev] [keystone][reseller] New way to get a project
scoped token by name
On 06/06/2015 00:24, Adam Young wrote:
On 06/05/2015 01:15 PM, Henry Nash wrote:
I am sure I have missed something along the way, but can someone
explain to me why we need this at all. Project names are unique
within a domain, with the exception of the project that is acting as
its domain (i.e. they can only every be two names clashing in a
hierarchy at the domain level and below). So why isn’t specifying
“is_domain=True/False” sufficient in an auth scope along with the
project name?
The limitation of Project names are unique within a domain is
artificial and somethi8ng we should not be enforcing. Names should only
be unique within parent project.
+++1
I said the exact same thing as Henry in the other thread that seems to be on
the same topic. You're correct the limitation of Project names are unique
within a domain is completely artificial, but it's a constraint that allows us
to maintain the auth systems we currently have and will not harm the reseller
model (because they would be creating new domains).
It's also a constraint that we can relax later when multitenancy is a bit more
established and someone has a real issue with the limitation - it's not
something we can ever claw back again if we allow some looking up projects by
name with delimiters.
I think for the time being it's an artificial constraint we should maintain.
This whole thing started by trying to distinguish a domain from a
project within that domain that both have the same name. We can special
case that, but it is not a great solution.
Henry
On 5 Jun 2015, at 18:02, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well
more to the point there should be a common one across OpenStack
installations to ensure we are providing a good and consistent (and
more to the point inter-operable) experience to our users. I'm
worried a custom defined delimiter (even at the domain level) is
going to make it difficult to consume this data outside of the
context of OpenStack (there are applications that are written to use
the APIs directly).
We have one already. We are working JSON, and so instead of project
name being a string, it can be an array.
Nothing else is backwards compatible. Nothing else will ensure we
don;t break exisiting deployments.
Moving forward, we should support DNS notation, but it has to be an
opt in
The alternative is to explicitly list the delimiter in the project (
e.g. {hierarchy: {delim: ., domain.project.project2}} ). The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the domain
entity? That seems like a good idea, although it does not
solve the
problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would
define
its own and this would be carried in the JSON as a separate
parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we
want a
domain, we
should always reference the namespace as we do today.
Basically, if we
ask for a project name we need to also provide it's
namespace (your
option #1). This clearly lines up with how we handle
projects in
domains
today.
I would, however, focus on how to represent the
namespace in a single
(usable) string. We've been delaying the work on this
for a while
since
we have historically not provided a clear way to delimit the
hierarchy.
If we solve the issue with what is the delimiter
between domain,
project, and
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
On 06/06/2015 00:24, Adam Young wrote:
On 06/05/2015 01:15 PM, Henry Nash wrote:
I am sure I have missed something along the way, but can someone
explain to me why we need this at all. Project names are unique
within a domain, with the exception of the project that is acting as
its domain (i.e. they can only every be two names clashing in a
hierarchy at the domain level and below). So why isn’t specifying
“is_domain=True/False” sufficient in an auth scope along with the
project name?
The limitation of Project names are unique within a domain is
artificial and somethi8ng we should not be enforcing. Names should only
be unique within parent project.
+++1
This whole thing started by trying to distinguish a domain from a
project within that domain that both have the same name. We can special
case that, but it is not a great solution.
Henry
On 5 Jun 2015, at 18:02, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well
more to the point there should be a common one across OpenStack
installations to ensure we are providing a good and consistent (and
more to the point inter-operable) experience to our users. I'm
worried a custom defined delimiter (even at the domain level) is
going to make it difficult to consume this data outside of the
context of OpenStack (there are applications that are written to use
the APIs directly).
We have one already. We are working JSON, and so instead of project
name being a string, it can be an array.
Nothing else is backwards compatible. Nothing else will ensure we
don;t break exisiting deployments.
Moving forward, we should support DNS notation, but it has to be an
opt in
The alternative is to explicitly list the delimiter in the project (
e.g. {hierarchy: {delim: ., domain.project.project2}} ). The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the domain
entity? That seems like a good idea, although it does not
solve the
problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would
define
its own and this would be carried in the JSON as a separate
parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we
want a
domain, we
should always reference the namespace as we do today.
Basically, if we
ask for a project name we need to also provide it's
namespace (your
option #1). This clearly lines up with how we handle
projects in
domains
today.
I would, however, focus on how to represent the
namespace in a single
(usable) string. We've been delaying the work on this
for a while
since
we have historically not provided a clear way to delimit the
hierarchy.
If we solve the issue with what is the delimiter
between domain,
project, and subdomain/subproject, we end up solving the
usability
why not allow the top level domain/project to define the
delimiter for
its tree, and to carry the delimiter in the JSON as a new
parameter.
That provides full flexibility for all languages and locales
David
issues with proposal #1, and not breaking the current
behavior you'd
expect with implementing option #2 (which at face value
feels to
be API
incompatible/break of current behavior).
Cheers,
--Morgan
On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com wrote:
Hi folks,
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
I am sure I have missed something along the way, but can someone explain to me
why we need this at all. Project names are unique within a domain, with the
exception of the project that is acting as its domain (i.e. they can only every
be two names clashing in a hierarchy at the domain level and below). So why
isn’t specifying “is_domain=True/False” sufficient in an auth scope along with
the project name?
Henry
On 5 Jun 2015, at 18:02, Adam Young ayo...@redhat.com wrote:
On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well more to the
point there should be a common one across OpenStack installations to ensure
we are providing a good and consistent (and more to the point
inter-operable) experience to our users. I'm worried a custom defined
delimiter (even at the domain level) is going to make it difficult to
consume this data outside of the context of OpenStack (there are
applications that are written to use the APIs directly).
We have one already. We are working JSON, and so instead of project name
being a string, it can be an array.
Nothing else is backwards compatible. Nothing else will ensure we don;t
break exisiting deployments.
Moving forward, we should support DNS notation, but it has to be an opt in
The alternative is to explicitly list the delimiter in the project ( e.g.
{hierarchy: {delim: ., domain.project.project2}} ). The additional
need to look up the delimiter / set the delimiter when creating a domain is
likely to make for a worse user experience than selecting one that is not
different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the domain
entity? That seems like a good idea, although it does not solve the
problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would define
its own and this would be carried in the JSON as a separate parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we want a
domain, we
should always reference the namespace as we do today. Basically, if
we
ask for a project name we need to also provide it's namespace (your
option #1). This clearly lines up with how we handle projects in
domains
today.
I would, however, focus on how to represent the namespace in a single
(usable) string. We've been delaying the work on this for a while
since
we have historically not provided a clear way to delimit the
hierarchy.
If we solve the issue with what is the delimiter between domain,
project, and subdomain/subproject, we end up solving the usability
why not allow the top level domain/project to define the delimiter for
its tree, and to carry the delimiter in the JSON as a new parameter.
That provides full flexibility for all languages and locales
David
issues with proposal #1, and not breaking the current behavior you'd
expect with implementing option #2 (which at face value feels to
be API
incompatible/break of current behavior).
Cheers,
--Morgan
On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
henriquecostatr...@gmail.com mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com wrote:
Hi folks,
In Reseller[1], we’ll have the domains concept merged into
projects,
that means that we will have projects that will behave as
domains.
Therefore, it will be possible to have two projects with the same
name in a hierarchy, one being a domain and another being a
regular
project. For instance, the following hierarchy will be valid:
A - is_domain project, with domain A
|
B - project
|
A - project with domain A
That hierarchy faces a problem when a user requests a project
scoped
token by name, once she’ll pass “domain = ‘A’” and
project.name http://project.name/
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well more
to the point there should be a common one across OpenStack
installations to ensure we are providing a good and consistent (and
more to the point inter-operable) experience to our users. I'm worried
a custom defined delimiter (even at the domain level) is going to make
it difficult to consume this data outside of the context of OpenStack
(there are applications that are written to use the APIs directly).
We have one already. We are working JSON, and so instead of project
name being a string, it can be an array.
Nothing else is backwards compatible. Nothing else will ensure we don;t
break exisiting deployments.
Moving forward, we should support DNS notation, but it has to be an opt in
The alternative is to explicitly list the delimiter in the project (
e.g. {hierarchy: {delim: ., domain.project.project2}} ). The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the domain
entity? That seems like a good idea, although it does not solve the
problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would define
its own and this would be carried in the JSON as a separate
parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we want a
domain, we
should always reference the namespace as we do today.
Basically, if we
ask for a project name we need to also provide it's
namespace (your
option #1). This clearly lines up with how we handle
projects in
domains
today.
I would, however, focus on how to represent the namespace
in a single
(usable) string. We've been delaying the work on this for
a while
since
we have historically not provided a clear way to delimit the
hierarchy.
If we solve the issue with what is the delimiter between
domain,
project, and subdomain/subproject, we end up solving the
usability
why not allow the top level domain/project to define the
delimiter for
its tree, and to carry the delimiter in the JSON as a new
parameter.
That provides full flexibility for all languages and locales
David
issues with proposal #1, and not breaking the current
behavior you'd
expect with implementing option #2 (which at face value
feels to
be API
incompatible/break of current behavior).
Cheers,
--Morgan
On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com wrote:
Hi folks,
In Reseller[1], we’ll have the domains concept merged into
projects,
that means that we will have projects that will behave
as domains.
Therefore, it will be possible to have two projects
with the same
name in a hierarchy, one being a domain and another
being a
regular
project. For instance, the following hierarchy will be
valid:
A - is_domain project, with domain A
|
B - project
|
A - project with domain A
That hierarchy faces a problem when a user requests a
project
scoped
token by name, once she’ll pass “domain = ‘A’” and
project.name http://project.name http://project.name
http://project.name = “A”. Currently, we have no way to
distinguish which project we are referring to. We have two
proposals
for
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
First I have some questions: if we are going to add a delimiter, how can we
handle OpenStack API Stability guidelines [1]? If we add this delimiter in
keystone.conf (and having the default value being . or /), do we fall
into the same API stability problems?
Personally, I'm in favor of having a way to represent the hierarchy since
it will loose the naming restrictions across projects and domains entities
- resulting in a better UX. The only remaining restriction will be that we
won't be able to create an entity with the same name in the same level of
the hierarchy. In addition, besides the token request, using a delimiter
also solves the problem of representing a hierarchy in SAML Assertions
generated by a keystone identity provider as well.
Also, if we are going to use a delimiter, we need to update the way
projects names are returned in the GET v3/projects API to include the
hierarchy so the user (or client) knows how to request a token using the
project name.
On Thu, Jun 4, 2015 at 4:33 AM, David Chadwick d.w.chadw...@kent.ac.uk
wrote:
I agree that it is better to choose one global delimiter (ideally this
should have been done from day one, when hierarchical naming should have
been used as the basic name form for Openstack). Whatever you choose now
will cause someone somewhere some pain, but perhaps the overall pain to
the whole community will be less if you dictate what this delimiter is
going to be now, but dont introduce for a year. This allows everyone a
year to remove the delimiter from their names.
regards
David
On 03/06/2015 22:05, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well more to
the point there should be a common one across OpenStack installations to
ensure we are providing a good and consistent (and more to the point
inter-operable) experience to our users. I'm worried a custom defined
delimiter (even at the domain level) is going to make it difficult to
consume this data outside of the context of OpenStack (there are
applications that are written to use the APIs directly).
The alternative is to explicitly list the delimiter in the project (
e.g. {hierarchy: {delim: ., domain.project.project2}} ). The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the domain
entity? That seems like a good idea, although it does not solve the
problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would
define
its own and this would be carried in the JSON as a separate
parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we want a
domain, we
should always reference the namespace as we do today.
Basically, if we
ask for a project name we need to also provide it's
namespace (your
option #1). This clearly lines up with how we handle
projects in
domains
today.
I would, however, focus on how to represent the namespace in
a single
(usable) string. We've been delaying the work on this for a
while
since
we have historically not provided a clear way to delimit the
hierarchy.
If we solve the issue with what is the delimiter between
domain,
project, and subdomain/subproject, we end up solving the
usability
why not allow the top level domain/project to define the
delimiter for
its tree, and to carry the delimiter in the JSON as a new
parameter.
That provides full flexibility for all languages and locales
David
issues with proposal #1, and not breaking the current
behavior you'd
expect with implementing option #2 (which at face value
feels to
be API
incompatible/break of current behavior).
Cheers,
--Morgan
On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
On Thu, Jun 4, 2015 at 10:10 AM Rodrigo Duarte rodrigodso...@gmail.com wrote: Also, if we are going to use a delimiter, we need to update the way projects names are returned in the GET v3/projects API to include the hierarchy so the user (or client) knows how to request a token using the project name. This comment made me think of something (maybe crazy)... I'm hoping that we are not expecting a client to understand how to create the hierarchical representation of the fully qualified project name and instead feed it to them in the JSON responses. If this is the case we can probably control the delimiter on the server side without the client even knowing that there is a delimiter. We could have the first character of this new property actually contain the delimiter used. .A.B.C - would mean that . is the delimiter - vs - #A#B#C - would mean that # is the delimiter The challenge left is to figure out which delimiter to use. -- David __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
I agree that it is better to choose one global delimiter (ideally this
should have been done from day one, when hierarchical naming should have
been used as the basic name form for Openstack). Whatever you choose now
will cause someone somewhere some pain, but perhaps the overall pain to
the whole community will be less if you dictate what this delimiter is
going to be now, but dont introduce for a year. This allows everyone a
year to remove the delimiter from their names.
regards
David
On 03/06/2015 22:05, Morgan Fainberg wrote:
Hi David,
There needs to be some form of global hierarchy delimiter - well more to
the point there should be a common one across OpenStack installations to
ensure we are providing a good and consistent (and more to the point
inter-operable) experience to our users. I'm worried a custom defined
delimiter (even at the domain level) is going to make it difficult to
consume this data outside of the context of OpenStack (there are
applications that are written to use the APIs directly).
The alternative is to explicitly list the delimiter in the project (
e.g. {hierarchy: {delim: ., domain.project.project2}} ). The
additional need to look up the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the domain
entity? That seems like a good idea, although it does not solve the
problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would define
its own and this would be carried in the JSON as a separate parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we want a
domain, we
should always reference the namespace as we do today.
Basically, if we
ask for a project name we need to also provide it's
namespace (your
option #1). This clearly lines up with how we handle projects in
domains
today.
I would, however, focus on how to represent the namespace in
a single
(usable) string. We've been delaying the work on this for a
while
since
we have historically not provided a clear way to delimit the
hierarchy.
If we solve the issue with what is the delimiter between
domain,
project, and subdomain/subproject, we end up solving the
usability
why not allow the top level domain/project to define the
delimiter for
its tree, and to carry the delimiter in the JSON as a new
parameter.
That provides full flexibility for all languages and locales
David
issues with proposal #1, and not breaking the current
behavior you'd
expect with implementing option #2 (which at face value feels to
be API
incompatible/break of current behavior).
Cheers,
--Morgan
On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com wrote:
Hi folks,
In Reseller[1], we’ll have the domains concept merged into
projects,
that means that we will have projects that will behave
as domains.
Therefore, it will be possible to have two projects with
the same
name in a hierarchy, one being a domain and another being a
regular
project. For instance, the following hierarchy will be
valid:
A - is_domain project, with domain A
|
B - project
|
A - project with domain A
That hierarchy faces a problem when a user requests a
project
scoped
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the domain
entity? That seems like a good idea, although it does not solve the
problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would define
its own and this would be carried in the JSON as a separate parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we want a
domain, we
should always reference the namespace as we do today. Basically, if we
ask for a project name we need to also provide it's namespace (your
option #1). This clearly lines up with how we handle projects in
domains
today.
I would, however, focus on how to represent the namespace in a single
(usable) string. We've been delaying the work on this for a while
since
we have historically not provided a clear way to delimit the
hierarchy.
If we solve the issue with what is the delimiter between domain,
project, and subdomain/subproject, we end up solving the usability
why not allow the top level domain/project to define the delimiter for
its tree, and to carry the delimiter in the JSON as a new parameter.
That provides full flexibility for all languages and locales
David
issues with proposal #1, and not breaking the current behavior you'd
expect with implementing option #2 (which at face value feels to
be API
incompatible/break of current behavior).
Cheers,
--Morgan
On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com wrote:
Hi folks,
In Reseller[1], we’ll have the domains concept merged into
projects,
that means that we will have projects that will behave as domains.
Therefore, it will be possible to have two projects with the same
name in a hierarchy, one being a domain and another being a
regular
project. For instance, the following hierarchy will be valid:
A - is_domain project, with domain A
|
B - project
|
A - project with domain A
That hierarchy faces a problem when a user requests a project
scoped
token by name, once she’ll pass “domain = ‘A’” and
project.name http://project.name
http://project.name = “A”. Currently, we have no way to
distinguish which project we are referring to. We have two
proposals
for this.
1.
Specify the whole hierarchy in the token request body, which
means that when requesting a token for the child project for
that hierarchy, we’ll have in the scope field something like:
project: {
domain: {
name: A
},
name: [“A”', “B”, “A”]
}
If the project name is unique inside the domain (project “B”, for
example), the hierarchy is optional.
2.
When a conflict happen, always provide a token to the child
project. That means that, in case we have a name clashing as
described, it will only be possible to get a project scoped
token to the is_domain project through its id.
The former will give us more clarity and won’t create any more
restrictions than we already have. As a con, we currently are not
able to get the names of projects in the hierarchy above a given
project. Although the latter seems to hurt fewer people, it
has the
disadvantage of creating another set of constraints that might
difficult the UX in the future.
What do you think about that? We want to hear your oppinion, so we
can discuss it at today’s Keystone Meeting.
[1]
https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Hi David,
There needs to be some form of global hierarchy delimiter - well more to
the point there should be a common one across OpenStack installations to
ensure we are providing a good and consistent (and more to the point
inter-operable) experience to our users. I'm worried a custom defined
delimiter (even at the domain level) is going to make it difficult to
consume this data outside of the context of OpenStack (there are
applications that are written to use the APIs directly).
The alternative is to explicitly list the delimiter in the project (
e.g. {hierarchy:
{delim: ., domain.project.project2}} ). The additional need to look
up the delimiter / set the delimiter when creating a domain is likely to
make for a worse user experience than selecting one that is not different
across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick d.w.chadw...@kent.ac.uk
wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute in the domain
entity? That seems like a good idea, although it does not solve the
problem Morgan's mentioned that is the global hierarchy delimiter.
There would be no global hierarchy delimiter. Each domain would define
its own and this would be carried in the JSON as a separate parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we want a
domain, we
should always reference the namespace as we do today. Basically,
if we
ask for a project name we need to also provide it's namespace (your
option #1). This clearly lines up with how we handle projects in
domains
today.
I would, however, focus on how to represent the namespace in a
single
(usable) string. We've been delaying the work on this for a while
since
we have historically not provided a clear way to delimit the
hierarchy.
If we solve the issue with what is the delimiter between domain,
project, and subdomain/subproject, we end up solving the usability
why not allow the top level domain/project to define the delimiter
for
its tree, and to carry the delimiter in the JSON as a new parameter.
That provides full flexibility for all languages and locales
David
issues with proposal #1, and not breaking the current behavior
you'd
expect with implementing option #2 (which at face value feels to
be API
incompatible/break of current behavior).
Cheers,
--Morgan
On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com
mailto:henriquecostatr...@gmail.com wrote:
Hi folks,
In Reseller[1], we’ll have the domains concept merged into
projects,
that means that we will have projects that will behave as
domains.
Therefore, it will be possible to have two projects with the
same
name in a hierarchy, one being a domain and another being a
regular
project. For instance, the following hierarchy will be valid:
A - is_domain project, with domain A
|
B - project
|
A - project with domain A
That hierarchy faces a problem when a user requests a project
scoped
token by name, once she’ll pass “domain = ‘A’” and
project.name http://project.name
http://project.name = “A”. Currently, we have no way to
distinguish which project we are referring to. We have two
proposals
for this.
1.
Specify the whole hierarchy in the token request body,
which
means that when requesting a token for the child project
for
that hierarchy, we’ll have in the scope field something
like:
project: {
domain: {
name: A
},
name: [“A”', “B”, “A”]
}
If the project name is unique inside the domain (project “B”,
for
example), the hierarchy is optional.
2.
When a conflict happen, always provide a token to the child
project. That means that, in case we have a name clashing
as
described, it will only be possible to get a project scoped
token to the is_domain project through its id.
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we want a domain, we
should always reference the namespace as we do today. Basically, if we
ask for a project name we need to also provide it's namespace (your
option #1). This clearly lines up with how we handle projects in domains
today.
I would, however, focus on how to represent the namespace in a single
(usable) string. We've been delaying the work on this for a while since
we have historically not provided a clear way to delimit the hierarchy.
If we solve the issue with what is the delimiter between domain,
project, and subdomain/subproject, we end up solving the usability
why not allow the top level domain/project to define the delimiter for
its tree, and to carry the delimiter in the JSON as a new parameter.
That provides full flexibility for all languages and locales
David
issues with proposal #1, and not breaking the current behavior you'd
expect with implementing option #2 (which at face value feels to be API
incompatible/break of current behavior).
Cheers,
--Morgan
On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
henriquecostatr...@gmail.com mailto:henriquecostatr...@gmail.com wrote:
Hi folks,
In Reseller[1], we’ll have the domains concept merged into projects,
that means that we will have projects that will behave as domains.
Therefore, it will be possible to have two projects with the same
name in a hierarchy, one being a domain and another being a regular
project. For instance, the following hierarchy will be valid:
A - is_domain project, with domain A
|
B - project
|
A - project with domain A
That hierarchy faces a problem when a user requests a project scoped
token by name, once she’ll pass “domain = ‘A’” and project.name
http://project.name = “A”. Currently, we have no way to
distinguish which project we are referring to. We have two proposals
for this.
1.
Specify the whole hierarchy in the token request body, which
means that when requesting a token for the child project for
that hierarchy, we’ll have in the scope field something like:
project: {
domain: {
name: A
},
name: [“A”', “B”, “A”]
}
If the project name is unique inside the domain (project “B”, for
example), the hierarchy is optional.
2.
When a conflict happen, always provide a token to the child
project. That means that, in case we have a name clashing as
described, it will only be possible to get a project scoped
token to the is_domain project through its id.
The former will give us more clarity and won’t create any more
restrictions than we already have. As a con, we currently are not
able to get the names of projects in the hierarchy above a given
project. Although the latter seems to hurt fewer people, it has the
disadvantage of creating another set of constraints that might
difficult the UX in the future.
What do you think about that? We want to hear your oppinion, so we
can discuss it at today’s Keystone Meeting.
[1]
https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Hi David,
You mean creating some kind of delimiter attribute in the domain entity?
That seems like a good idea, although it does not solve the problem
Morgan's mentioned that is the global hierarchy delimiter.
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick d.w.chadw...@kent.ac.uk
escreveu:
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we want a domain, we
should always reference the namespace as we do today. Basically, if we
ask for a project name we need to also provide it's namespace (your
option #1). This clearly lines up with how we handle projects in domains
today.
I would, however, focus on how to represent the namespace in a single
(usable) string. We've been delaying the work on this for a while since
we have historically not provided a clear way to delimit the hierarchy.
If we solve the issue with what is the delimiter between domain,
project, and subdomain/subproject, we end up solving the usability
why not allow the top level domain/project to define the delimiter for
its tree, and to carry the delimiter in the JSON as a new parameter.
That provides full flexibility for all languages and locales
David
issues with proposal #1, and not breaking the current behavior you'd
expect with implementing option #2 (which at face value feels to be API
incompatible/break of current behavior).
Cheers,
--Morgan
On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
henriquecostatr...@gmail.com mailto:henriquecostatr...@gmail.com
wrote:
Hi folks,
In Reseller[1], we’ll have the domains concept merged into projects,
that means that we will have projects that will behave as domains.
Therefore, it will be possible to have two projects with the same
name in a hierarchy, one being a domain and another being a regular
project. For instance, the following hierarchy will be valid:
A - is_domain project, with domain A
|
B - project
|
A - project with domain A
That hierarchy faces a problem when a user requests a project scoped
token by name, once she’ll pass “domain = ‘A’” and project.name
http://project.name = “A”. Currently, we have no way to
distinguish which project we are referring to. We have two proposals
for this.
1.
Specify the whole hierarchy in the token request body, which
means that when requesting a token for the child project for
that hierarchy, we’ll have in the scope field something like:
project: {
domain: {
name: A
},
name: [“A”', “B”, “A”]
}
If the project name is unique inside the domain (project “B”, for
example), the hierarchy is optional.
2.
When a conflict happen, always provide a token to the child
project. That means that, in case we have a name clashing as
described, it will only be possible to get a project scoped
token to the is_domain project through its id.
The former will give us more clarity and won’t create any more
restrictions than we already have. As a con, we currently are not
able to get the names of projects in the hierarchy above a given
project. Although the latter seems to hurt fewer people, it has the
disadvantage of creating another set of constraints that might
difficult the UX in the future.
What do you think about that? We want to hear your oppinion, so we
can discuss it at today’s Keystone Meeting.
[1]
https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Hi Henrique,
I don't think we need to specifically call out that we want a domain, we
should always reference the namespace as we do today. Basically, if we ask
for a project name we need to also provide it's namespace (your option #1).
This clearly lines up with how we handle projects in domains today.
I would, however, focus on how to represent the namespace in a single
(usable) string. We've been delaying the work on this for a while since we
have historically not provided a clear way to delimit the hierarchy. If we
solve the issue with what is the delimiter between domain, project, and
subdomain/subproject, we end up solving the usability issues with proposal
#1, and not breaking the current behavior you'd expect with implementing
option #2 (which at face value feels to be API incompatible/break of
current behavior).
Cheers,
--Morgan
On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta henriquecostatr...@gmail.com
wrote:
Hi folks,
In Reseller[1], we’ll have the domains concept merged into projects, that
means that we will have projects that will behave as domains. Therefore, it
will be possible to have two projects with the same name in a hierarchy,
one being a domain and another being a regular project. For instance, the
following hierarchy will be valid:
A - is_domain project, with domain A
|
B - project
|
A - project with domain A
That hierarchy faces a problem when a user requests a project scoped token
by name, once she’ll pass “domain = ‘A’” and project.name = “A”.
Currently, we have no way to distinguish which project we are referring to.
We have two proposals for this.
1.
Specify the whole hierarchy in the token request body, which means
that when requesting a token for the child project for that hierarchy,
we’ll have in the scope field something like:
project: {
domain: {
name: A
},
name: [“A”', “B”, “A”]
}
If the project name is unique inside the domain (project “B”, for
example), the hierarchy is optional.
1.
When a conflict happen, always provide a token to the child project.
That means that, in case we have a name clashing as described, it will only
be possible to get a project scoped token to the is_domain project through
its id.
The former will give us more clarity and won’t create any more
restrictions than we already have. As a con, we currently are not able to
get the names of projects in the hierarchy above a given project. Although
the latter seems to hurt fewer people, it has the disadvantage of creating
another set of constraints that might difficult the UX in the future.
What do you think about that? We want to hear your oppinion, so we can
discuss it at today’s Keystone Meeting.
[1]
https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone][reseller] New way to get a project scoped token by name
Hi folks,
In Reseller[1], we’ll have the domains concept merged into projects, that
means that we will have projects that will behave as domains. Therefore, it
will be possible to have two projects with the same name in a hierarchy,
one being a domain and another being a regular project. For instance, the
following hierarchy will be valid:
A - is_domain project, with domain A
|
B - project
|
A - project with domain A
That hierarchy faces a problem when a user requests a project scoped token
by name, once she’ll pass “domain = ‘A’” and project.name = “A”. Currently,
we have no way to distinguish which project we are referring to. We have
two proposals for this.
1.
Specify the whole hierarchy in the token request body, which means that
when requesting a token for the child project for that hierarchy, we’ll
have in the scope field something like:
project: {
domain: {
name: A
},
name: [“A”', “B”, “A”]
}
If the project name is unique inside the domain (project “B”, for example),
the hierarchy is optional.
1.
When a conflict happen, always provide a token to the child project.
That means that, in case we have a name clashing as described, it will only
be possible to get a project scoped token to the is_domain project through
its id.
The former will give us more clarity and won’t create any more restrictions
than we already have. As a con, we currently are not able to get the names
of projects in the hierarchy above a given project. Although the latter
seems to hurt fewer people, it has the disadvantage of creating another set
of constraints that might difficult the UX in the future.
What do you think about that? We want to hear your oppinion, so we can
discuss it at today’s Keystone Meeting.
[1]
https://github.com/openstack/keystone-specs/blob/master/specs/liberty/reseller.rst
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
