Open Stack

On 02/04/2016 12:57 PM, Hayes, Graham wrote:
> On 04/02/2016 15:40, Ryan Brown wrote:
>> On 02/04/2016 09:32 AM, michael mccune wrote:
>>> On 02/04/2016 08:33 AM, Thierry Carrez wrote:
>>>> Hayes, Graham wrote:
>>>>> On 04/02/2016 13:24, Doug Hellmann wrote:
>>>>>> Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +0000:
>>>>>>> On 04/02/2016 11:40, Sean Dague wrote:
>>>>>>>> 2) Have a registry of "common" names.
>>>>>>>>
>>>>>>>> Upside, we can safely use common names everywhere and not fear
>>>>>>>> collision down the road.
>>>>>>>>
>>>>>>>> Downside, yet another contention point.
>>>>>>>>
>>>>>>>> A registry would clearly be under TC administration, though all the
>>>>>>>> heavy lifting might be handed over to the API working group. I still
>>>>>>>> imagine collision around some areas might be contentious.
>>>>>>>
>>>>>>> ++ to a central registry. It could easily be added to the
>>>>>>> projects.yaml
>>>>>>> file, and is a single source of truth.
>>>>>>
>>>>>> Although I realized that the projects.yaml file only includes official
>>>>>> projects right now, which would mean new projects wouldn't have a place
>>>>>> to register terms. Maybe that's a feature?
>>>>>
>>>>> That is a good point - should we be registering terms for non tent
>>>>> projects? Or do projects get terms when they get accepted into the tent?
>>>>
>>>> I don't see why we would register terms for non-official projects. I
>>>> don't see under what authority we would do that, or where it would end.
>>>> So yes, that's a feature.
>>>>
>>>
>>> i have a question about this, as new, non-official, projects start to
>>> spin up there will be questions about the naming conventions they will
>>> use within the project as to headers and the like. given that the
>>> current guidance trend in the api-wg is towards using "service type" in
>>> these cases, how would these projects proceed?
>>>
>>> (i'm not suggesting these projects should be registered, just curious)
>>
>> 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.

>> Say there's an LDAP aaS project, it could ask to reserve "directory" or
>> whatever and have a reasonable hope that when they're tented they'll be
>> able to use it. This would help avoid having multiple projects expecting
>> to use the same name, while also not meaning we force anyone to use or
>> not use some name.
>>
>> Effectively, it's a gerrit-backed version of "dibs".
>>
>>>> I think solution 2 is the best. To avoid too much contention, that can
>>>> easily be delegated to the API WG, and escalated to the TC for
>>>> resolution only in case of conflict between projects (or between a
>>>> project and the API WG).
>>>>
>>>
>>> i'm +1 for solution 2 as well. as to the api-wg participation in the
>>> name registration side of things , i don't have an objection but i am
>>> very curious to hear Everett's and Chris' opinions.
>>>
>>> regards,
>>> mike
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>