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: >>> A few issues have crept up recently with the service catalog, API >>> headers, API end points, and even similarly named resources in >>> different resources (e.g. backup), that are all circling around a key >>> problem. Distributed teams and naming collision. >>> >>> Every OpenStack project has a unique name by virtue of having a git >>> tree. Once they claim 'openstack/foo', foo is theirs in the >>> OpenStack universe for all time (or until trademarks say otherwise). >>> Nova in OpenStack will always mean one project. >>> >>> There has also been a desire to replace project names with >>> common/generic names, in the service catalog, API headers, and a few >>> other places. Nova owns 'compute'. Except... that's only because we >>> all know that it does. We don't *actually* have a registry for those >>> values. >>> >>> So the code names are well regulated, the common names, that we >>> encourage use of, are not. Devstack in tree code defines some >>> conventions. However with the big tent, things get kind of squirely >>> pretty quickly. Congress registering 'policy' as their endpoint type >>> is a good example of that - >>> https://github.com/openstack/congress/blob/master/devstack/plugin.sh#L147 >>> >>> Naming is hard. And trying to boil down complicated state machines >>> to one or two word shiboliths means that inevitably we're going to >>> find some words just keep cropping up: policy, flavor, backup, meter. >>> We do however need to figure out a way forward. >>> >>> Lets start with the top level names (resource overlap cascades from >>> there). >>> >>> What options do we have? >>> >>> 1) Use the names we already have: nova, glance, swift, etc. >>> >>> Upside, collision problem is solved. Downside, you need a secret >>> decoder ring to figure out what project does what. >>> >>> 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 imagine collisions are going to be contentious - but having a central >> source makes finding potential collisions much easier. >> >>> >>> 3) Use either, inconsistently, hope for the best. (aka - status quo) >>> >>> Upside, no long mailing list thread to figure out the answer. >>> Downside, it sucks. >>> >>> >>> Are there other options missing? Where are people leaning at this >>> point? >>> >>> Personally I'm way less partial to any particular answer as long as >>> it's not #3. >>> >>> >>> -Sean >>> >> > > __________________________________________________________________________ > 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
