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? > 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-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
