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" > > > parent/child1/child2 > > > 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: https://review.openstack.org/#/c/310048/ --abandoned https://review.openstack.org/#/c/318605/ --abandoned https://review.openstack.org/#/c/332940/ 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, domain/username/password). 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 limitation anyway). 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, getting close... 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 character limit. 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. __________________________________________________________________________ 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