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