Excerpts from Sean Dague's message of 2016-02-04 08:33:59 -0500: > On 02/04/2016 08:18 AM, 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? > > It seems like it's a feature. > > That being said, projects.yaml is pretty full right now. And, it's not > clear that common name <-> project name is a 1 to 1 mapping. > > For instance, Nova is getting very close to exposing a set of scheduler > resources. For future proofing we would like to do that on a dedicated > new endpoint from day one so that potential future split out of the code > would not impact how APIs look in the service catalog or to consumers. > There would be no need to have proxy apis in Nova for compatibility in > the future. > > So this feels like a separate registry for service common name, which > maps N -> 1 to a project.
We already map multiple repos to multiple deliverables to multiple projects. So I don't think the schema concerns are a reason not to have it in projects.yaml. That said, it doesn't *have* to be there, it would just make it convenient to manage publication. Doug > > -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
