[openstack-dev] [Keystone] Project name DB length
adriant at catalyst.net.nz
Mon Oct 24 23:20:38 UTC 2016
On 21/10/16 04:30, Adam Young wrote:
> No. keep them short. We are working toward a scheme where you can
> nest the names like this"
> But if you make them too long, that becomes a disaster. There is a
> strict option in the config file that prevents you from making names
> with non-URL safe characters. Set that option.
Nested names is the exact reason I want 64+ char project names. I
apologies for the long in email in advance, but let me give you the
context for this.
I do remember a series of specs that were meant to work towards your
suggestion but they all seemed to have been abandoned.
This is the review/spec series that I remember reading through:
The latter of which still doesn't really solve the problem in a useful
way. I was looking forward to project names being unique only in the
parent scope. I can understand why that isn't possible, because people
still use project names rather than ids (a bad practice), and because
without a full path a name doesn't make sense. Are there any other specs
around this topic I've missed?
I'm trying to make single domain HMT work via a service that will
enforce the full project hierarchy and url safety in the name. Much like
was proposed here: https://review.openstack.org/#/c/318605
We are running a public cloud and while we would love to transition to
giving each client a domain, we aren't able to do that yet, and it will
complicate matters a hell of a lot (especially for customer login,
With emails as our usernames we get around the username constraint in a
single domain easily enough, and a management service which allows for
per project user management for clients to invite their own users once
given access. So the only problem we have is no HMT support right now
and project name uniqueness. Also no groups, as groups make no sense
outside of having your own domain (although I may have ideas around this
The project name uniqueness per domain still stings though because even
given a full domain a client can't do this:
MyCompanyName (as domain) > CompanyDepartment1 > Project1 > development
MyCompanyName (as domain) > CompanyDepartment1 > Project1 > production
MyCompanyName (as domain) > CompanyDepartment1 > Project2 > development
MyCompanyName (as domain) > CompanyDepartment1 > Project2 > production
MyCompanyName (as domain) > CompanyDepartment2 > Project1 > development
MyCompanyName (as domain) > CompanyDepartment2 > Project1 > production
Having 'CompanyDepartment_' as a subdomain would help, but only a little.
Making those full paths would work, but would mean longer names:
MyCompanyName (as domain) > CompanyDepartment1
MyCompanyName (as domain) > CompanyDepartment1/Project1
MyCompanyName (as domain) > CompanyDepartment1/Project1/development - 39
chars, so not to bad, still room to go deeper
MyCompanyName (as domain) > CompanyDepartment1/Project1/production
In single domain:
default (as domain) >
MyCompanyName/CompanyDepartment1/Project1/development - 53 chars,
64 characters still gives most people enough to work with, but does
impose a limit I'd rather not inflict on customers. Even 100 would be
better. While I could simply edit the code and migrate our own
deployment I would prefer to make the change upstream and backport in
the knowledge we won't be carrying it forever.
Although... if there is a better solution to this, I'd take it, but from
what I've been reading true HMT has mostly been pushed aside with the
suggestion to just give everyone their own domain (which still has the
project name constraint, and isn't an option for us right now).
I just want to get useful HMT working for our cloud and I think I can
get it mostly there through our management tasks service (a proxy
service that works with keystone on a user's behalf and allows us more
control), and the current features keystone supports (project parents,
inherited roles). The only real barrier I can see is people reaching the
Hopefully that explains why I'd prefer longer project names than 64
char, but if you can give me an alternative I'd take it.
More information about the OpenStack-dev