[openstack-dev] [all] the trouble with names

Ryan Brown rybrown at redhat.com
Fri Feb 5 18:22:55 UTC 2016

On 02/05/2016 01:00 PM, Sean Dague wrote:
> On 02/05/2016 12:16 PM, Ryan Brown wrote:
>> On 02/05/2016 09:08 AM, michael mccune wrote:
>>> On 02/04/2016 12:57 PM, Hayes, Graham wrote:
>>>> On 04/02/2016 15:40, Ryan Brown wrote:
>> [snipped lots]
>>>>> This isn't a perfect solution, but maybe instead of projects.yml there
>>>>> could be a `registry.yml` project that would (of course) have all the
>>>>> project.yml "in-tent" projects, but also merge in external project
>>>>> requests for namespaces?
>>>> Where ever it is stored, could this be a solid place for the api-wg to
>>>> codify the string that should be shown in the catalog / headers /
>>>> other places by services?
>>> this seems like a reasonable approach, the big downside might be
>>> grooming the "dibs" list. we could have projects that expect to go
>>> somewhere, register their name, then never achieve "lift-off". in these
>>> cases we would need to release those names back into the free pool.
>> There could be some kind of reaping process, say every January send an
>> email to every project with outstanding "dibs" to check that they still
>> exist and want that name.
>> I think a 1 year TTL would be a good starting spot, does that help?
>> [snipped more]
> Personally, I don't feel like reservations should exist for non
> OpenStack projects. That's just squatting and locks away resources from
> actual openstack projects.

Yeah, but I feel like there would be a lot of benefit to some kind of 
system where not-openstack-yet projects could say "we want to use X as a 
generic name" so it's not a surprise when two projects show up and want 
in the tent, but then one of them has to go change its service.

For example, I think "containers" will be one of those words that 
everyone wants to use (buzzbuzzbuzzbuzz). Having at least a way for 
projects to say "hm, someone else wants this" would be nice.

Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

More information about the OpenStack-dev mailing list