Re: [openstack-dev] [all] the trouble with names

[michael mccune]

On 02/05/2016 04:36 PM, Chris Dent wrote:

On Fri, 5 Feb 2016, Sean Dague wrote:

I'd ask for folks to try to stay on the original question:

What possible naming standards could we adopt, and what are the
preferences.


1. service type as described in option 2
2. managed by the api-wg with appeal to the TC
3. be limited to those services that (wish to/need to/should) be present
in the service catalog

As discussed elsewhere 3 is a feature not a bug. We should endeavor
to keep the service catalog clean, tidy, and limited as a control on
OpenStack itself is clean, tidy and limited.


i think this sounds very reasonable

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

Re: [openstack-dev] [all] the trouble with names

[Fox, Kevin M]

Sorry. SWIFT beat you to it. ;)

Kevin

From: gordon chung [g...@live.ca]
Sent: Friday, February 05, 2016 1:00 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] the trouble with names

On 05/02/2016 1:22 PM, Ryan Brown wrote:
> For example, I think "containers" will be one of those words that
> everyone wants to use (buzzbuzzbuzzbuzz). Having at least a way for
> projects to say "hm, someone else wants this" would be nice.

too late, magnum[1] beat you to it. i'm not sure what the other docker
projects are using. plenty of alternatives though[2]?

#2 is the lesser of the evils but not by much. if we do choose it, we
need a formalised taxonomy, CADF is one example (see line 2656[3]), and
we need to be specific. it doesn't really solve the issue of projects
that do the same thing but i believe that issue is not part of the
discussion.

regarding some collisions so far, to a certain extent i believe it's
because the projects are really features masquerading as discrete
services. [disclaimer: following might be ignorant, apologies] for
something like backups, i'm not sure why it isn't a part of an existing
services api (compute|blockstorage/.../backup) and why it needs to be
it's own endpoint.

[1] https://github.com/openstack/magnum/blob/master/devstack/lib/magnum#L111
[2] http://www.thesaurus.com/browse/container?s=t
[3]
https://www.dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf

cheers,

--
gord

__
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

Re: [openstack-dev] [all] the trouble with names

[Chris Dent]

On Fri, 5 Feb 2016, Sean Dague wrote:


I feel like this is gone a bit "dead horse" of track from the question
at hand. Which brings us in danger of ending up on solution #3 (do
nothing, we're all burned out from having to discuss things anyway, lets
farm goats).


We should revisit this ^ issue at some point because honestly if people
can't spend the time and energy to reach consensus, we're screwed and
we're going to continue to look like a giant enterprisey boondoggle
rather than a legitimate and useful "Ubiquitous Open Source Cloud
Platform".

But fine:


I'd ask for folks to try to stay on the original question:

What possible naming standards could we adopt, and what are the preferences.


1. service type as described in option 2
2. managed by the api-wg with appeal to the TC
3. be limited to those services that (wish to/need to/should) be present
   in the service catalog

As discussed elsewhere 3 is a feature not a bug. We should endeavor
to keep the service catalog clean, tidy, and limited as a control on
OpenStack itself is clean, tidy and limited.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [all] the trouble with names

[gordon chung]

On 05/02/2016 1:22 PM, Ryan Brown wrote:
> For example, I think "containers" will be one of those words that
> everyone wants to use (buzzbuzzbuzzbuzz). Having at least a way for
> projects to say "hm, someone else wants this" would be nice.

too late, magnum[1] beat you to it. i'm not sure what the other docker 
projects are using. plenty of alternatives though[2]?

#2 is the lesser of the evils but not by much. if we do choose it, we 
need a formalised taxonomy, CADF is one example (see line 2656[3]), and 
we need to be specific. it doesn't really solve the issue of projects 
that do the same thing but i believe that issue is not part of the 
discussion.

regarding some collisions so far, to a certain extent i believe it's 
because the projects are really features masquerading as discrete 
services. [disclaimer: following might be ignorant, apologies] for 
something like backups, i'm not sure why it isn't a part of an existing 
services api (compute|blockstorage/.../backup) and why it needs to be 
it's own endpoint.

[1] https://github.com/openstack/magnum/blob/master/devstack/lib/magnum#L111
[2] http://www.thesaurus.com/browse/container?s=t
[3] 
https://www.dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf

cheers,

-- 
gord

__
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

Re: [openstack-dev] [all] the trouble with names

[Tim Bell]

On 05/02/16 20:09, "Jay Pipes"  wrote:

>On 02/05/2016 08:38 AM, Dean Troyer wrote:
>> On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent > > wrote:
>>
>> I think this discussion is dancing around the edges of a referendum on
>> the "duplication" aspect of the big tent.
>>
>> It is also dancing around the separation of 'API' from
>> 'implementation'.  There is a long-standing disagreement on whether
>> OpenStack APIs can/should stand on their own, or simply be defined as
>> 'whatever project Foo implements'.
>
>I think you know my opinion on this matter :)
>
>My belief is that we should have a single curated, consistent, and 
>governed OpenStack API, a reference implementation of that API, and the 
>ability to have competing implementations of that API to encourage 
>innovation.
>
> > We already have seen independent
>> implementations of OpenStack APIs, although not (yet?) as OpenStack
>> projects.  Duplication is already happening in the wild.
>
>I'm aware of multiple competing APIs for the same general problem space 
>(Ceilometer and Monasca are the canonical example of this), but I'm not 
>aware of competing implementations of identical APIs. Could you point us 
>to where this has happened?

SWIFT and Ceph object stores ? There is pretty good compatibility between the 
two solutions such that you can advertise a Ceph object store as SWIFT and not 
have too many problems.

This was one of the areas of concern around the mandatory code for OpenStack 
trademarks. Could a cloud offer a ceph backed object store yet still obtain the 
OpenStack trademark ?

The decision in the management board was that a minimum set of common code was 
required although a future trademark of OpenStack compatible was accepted as a 
possibility.

Tim

>
>-jay
>
>__
>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

smime.p7s
Description: S/MIME cryptographic signature
__
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

Re: [openstack-dev] [all] the trouble with names

[Jay Pipes]

#2

On 02/05/2016 02:24 PM, Sean Dague wrote:

On 02/05/2016 02:09 PM, Jay Pipes wrote:

On 02/05/2016 08:38 AM, Dean Troyer wrote:

On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent mailto:cdent...@anticdent.org>> wrote:

 I think this discussion is dancing around the edges of a
referendum on
 the "duplication" aspect of the big tent.

It is also dancing around the separation of 'API' from
'implementation'.  There is a long-standing disagreement on whether
OpenStack APIs can/should stand on their own, or simply be defined as
'whatever project Foo implements'.


I think you know my opinion on this matter :)

My belief is that we should have a single curated, consistent, and
governed OpenStack API, a reference implementation of that API, and the
ability to have competing implementations of that API to encourage
innovation.


I feel like this is gone a bit "dead horse" of track from the question
at hand. Which brings us in danger of ending up on solution #3 (do
nothing, we're all burned out from having to discuss things anyway, lets
farm goats).

I'd ask for folks to try to stay on the original question:

What possible naming standards could we adopt, and what are the preferences.

 From that we can move towards any implementation needed for that.

-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

Re: [openstack-dev] [all] the trouble with names

[Sean Dague]

On 02/05/2016 02:09 PM, Jay Pipes wrote:
> On 02/05/2016 08:38 AM, Dean Troyer wrote:
>> On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent > > wrote:
>>
>> I think this discussion is dancing around the edges of a
>> referendum on
>> the "duplication" aspect of the big tent.
>>
>> It is also dancing around the separation of 'API' from
>> 'implementation'.  There is a long-standing disagreement on whether
>> OpenStack APIs can/should stand on their own, or simply be defined as
>> 'whatever project Foo implements'.
> 
> I think you know my opinion on this matter :)
> 
> My belief is that we should have a single curated, consistent, and
> governed OpenStack API, a reference implementation of that API, and the
> ability to have competing implementations of that API to encourage
> innovation.

I feel like this is gone a bit "dead horse" of track from the question
at hand. Which brings us in danger of ending up on solution #3 (do
nothing, we're all burned out from having to discuss things anyway, lets
farm goats).

I'd ask for folks to try to stay on the original question:

What possible naming standards could we adopt, and what are the preferences.

>From that we can move towards any implementation needed for that.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [all] the trouble with names

[Jay Pipes]

On 02/05/2016 08:38 AM, Dean Troyer wrote:

On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent mailto:cdent...@anticdent.org>> wrote:

I think this discussion is dancing around the edges of a referendum on
the "duplication" aspect of the big tent.

It is also dancing around the separation of 'API' from
'implementation'.  There is a long-standing disagreement on whether
OpenStack APIs can/should stand on their own, or simply be defined as
'whatever project Foo implements'.


I think you know my opinion on this matter :)

My belief is that we should have a single curated, consistent, and 
governed OpenStack API, a reference implementation of that API, and the 
ability to have competing implementations of that API to encourage 
innovation.


> We already have seen independent

implementations of OpenStack APIs, although not (yet?) as OpenStack
projects.  Duplication is already happening in the wild.


I'm aware of multiple competing APIs for the same general problem space 
(Ceilometer and Monasca are the canonical example of this), but I'm not 
aware of competing implementations of identical APIs. Could you point us 
to where this has happened?


-jay

__
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

Re: [openstack-dev] [all] the trouble with names

[Nick Yeates]

I have the benefit here of being a beginner to openstack and having experienced 
AWS as a user. I think that the current "nova", "cinder" etc naming was 
confusing to me at first, but that it's a needed stumbling block for devs and 
deployers/ops to be precise. 

However, for end-users, probably mostly in a GUI, you need to be smart about 
labels/names. Amazon currently uses a hybrid approach. They call 'compute' 
"ec2", but in the UI, the top dashboard explain all user-accessible services 
with both of the names and a short description. 

Basically, I think you keep the naming as is, and focus on clarification in the 
UI.

- Nick Yeates

> On Feb 5, 2016, at 7:56 AM, Chris Dent  wrote:
> 
>> On Thu, 4 Feb 2016, 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.
> 
> This is the only option presented thus far which meets the needs of
> end users and also some of our stated goals about creating
> interoperable OpenStack-based clouds.
> 
> It does, however, require some integration and orchestration between
> TC, Service Catalog work, and API-WG guidelines.
> 
>> Downside, yet another contention point.
> 
> What's the issue with contention? Contention is one of several tools
> that humans use to resolve disagreement and reached a shared
> understanding of the problem space. Without shared understanding
> in a community there's zero chance a community will create and work
> towards shared goals. Because even if everyone is using the same
> words for the goals, if they aren't using the same meanings, it's
> all bunk.
> 
> When we, as a group, start to contend over terms and identifiers
> that's just a signal that we don't really know what we're trying to
> do and need to work at it. A lot of people, frustrated with all this
> talk, will call it bikeshedding and then go off and do their own
> thing, potentially not in concert with other people's goals. Making
> all that talk is sometimes necessary if we want to be headed in the
> same direction[1].
> 
> The economics of our situation often make that kind of cross-project
> noodling challenging. As a group of open source devs we likely need
> to keep our patrons clearly aware of the value and amount of what
> some would call overhead.
> 
> It is not overhead. It's a major part of the work.
> 
> The big tent, in some sense, has been an invitation to allow people
> to work on a more diverse set of goals. At the edge this is
> beneficial as it means more useful stuff, but it has diffused
> understanding of what "OpenStack" is. For consumers of OpenStack (and
> for devs who are primarily concerned with making a thing called
> OpenStack that is useful for those consumers) there needs to be a
> thing which is OpenStack and that thing needs to be consistent and
> coherent. And limited[2].
> 
> A tool we have at our disposal for creating that consistency is the
> service catalog and specifically the service catalog types.
> 
> Some will argue that this will lead to people contending over who
> should occupy a type, as if that were a bad thing. It is not. Having
> that discussion will help identify the flaws in the proposed
> occupiers and keep the discussion of "what are we" alive and
> healthy[3].
> 
>> 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.
> 
> I'm happy for the API-wg to handle some of this if mike and Everett
> are as well. Making it work well will require everybody plays well
> with the service catalog too[4]
> 
> The biggest challenge I predict is when we need to change things, as
> we inevitably will. Many currently hold dear that we cannot impose
> change upon the existing user base. Sometimes you do and really it's
> not that much of a big deal compared to the pain of running
> OpenStack in the first place.
> 
> [1] It's perfectly okay for tools to not head in the same
> direction, especially if they can be consumed as independent
> libraries or services and are not embedded in the world of
> OpenStack. This is a good thing. There's far too much stuff _in_
> OpenStack that should just be _used by_ OpenStack (or used by
> OpenStack users).
> 
> [2] Yes, this means we need to have an opinion about what OpenStack
> is and build that opinion into the system. That's good. OpenStack is
> insufficiently generic to be unopinionated. Let's just get over
> that.
> 
> [3] At the moment it appears that much of the time the goal of
> OpenStack is to keep the gate running. This is classic statism at
> its worst. Straight out of the movie Brazil.
> 
> [4] 
> http://specs.openstack.org/openstack/openstack-specs/specs/service-catalog.html
> 
> -- 
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent
> __

Re: [openstack-dev] [all] the trouble with names

[Ryan Brown]

On 02/05/2016 01:00 PM, Sean Dague wrote:

On 02/05/2016 12:16 PM, Ryan Brown wrote:

On 02/05/2016 09:08 AM, michael mccune wrote:

On 02/04/2016 12:57 PM, Hayes, Graham wrote:

On 04/02/2016 15:40, Ryan Brown wrote:

[snipped lots]

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.


There could be some kind of reaping process, say every January send an
email to every project with outstanding "dibs" to check that they still
exist and want that name.

I think a 1 year TTL would be a good starting spot, does that help?

[snipped more]


Personally, I don't feel like reservations should exist for non
OpenStack projects. That's just squatting and locks away resources from
actual openstack projects.


Yeah, but I feel like there would be a lot of benefit to some kind of 
system where not-openstack-yet projects could say "we want to use X as a 
generic name" so it's not a surprise when two projects show up and want 
in the tent, but then one of them has to go change its service.


For example, I think "containers" will be one of those words that 
everyone wants to use (buzzbuzzbuzzbuzz). Having at least a way for 
projects to say "hm, someone else wants this" would be nice.


--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

__
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

Re: [openstack-dev] [all] the trouble with names

[Sean Dague]

On 02/05/2016 12:16 PM, Ryan Brown wrote:
> On 02/05/2016 09:08 AM, michael mccune wrote:
>> On 02/04/2016 12:57 PM, Hayes, Graham wrote:
>>> On 04/02/2016 15:40, Ryan Brown wrote:
> [snipped lots]
 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.
> 
> There could be some kind of reaping process, say every January send an
> email to every project with outstanding "dibs" to check that they still
> exist and want that name.
> 
> I think a 1 year TTL would be a good starting spot, does that help?
> 
> [snipped more]

Personally, I don't feel like reservations should exist for non
OpenStack projects. That's just squatting and locks away resources from
actual openstack projects.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [all] the trouble with names

[Ryan Brown]

On 02/05/2016 09:08 AM, michael mccune wrote:

On 02/04/2016 12:57 PM, Hayes, Graham wrote:

On 04/02/2016 15:40, Ryan Brown wrote:

[snipped lots]

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.


There could be some kind of reaping process, say every January send an 
email to every project with outstanding "dibs" to check that they still 
exist and want that name.


I think a 1 year TTL would be a good starting spot, does that help?

[snipped more]

--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

__
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

Re: [openstack-dev] [all] the trouble with names

[Neil Jerram]

On 05/02/16 13:50, Dean Troyer wrote:
> On Fri, Feb 5, 2016 at 7:13 AM, Neil Jerram  > wrote:
>
> On 04/02/16 11:40, Sean Dague wrote:
> > 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.
>
> This is my preference.  Yes, it means that there is an education hurdle
> for anyone new to OpenStack to overcome.  But once that is done, there
> is a concise and precise term that they and we can all use and
> understand.
>
>
> Have a look at the browser User-Agent headers and let me know how that
> has worked out for them:
>
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36
>
> Two of those product/code names are lies for compatibility purposes.  We
> (OpenStack) should not be promoting that sort of nonsense on our users
> just to save us a little bit of inconvenience in the development process.

I'm not clear how that's a good analogy.  Is it?

> To add something positive to the discussion, we should remember how much
> of OpenStack consists of plugin-capable architecture, specifically so
> that out-of-tree components can be accommodated for whatever reason.
> The projects play the role of arbitrator of namespaces in the case of
> many back-end drivers.

Perhaps my response here is overly detailed, but it appears that you're 
making a quite detailed technical point.  So:

1. Actually, at least for Neutron ML2 drivers, Neutron does not provide 
namespace arbitration.  There is a setup.cfg entry point space with the 
name 'neutron.ml2.mechanism_drivers', and each 3rd party driver adds its 
name to that space.  But there is no explicit protocol here (i.e. where 
networking-calico would say 'Can I use the name calico?' and Neutron 
might answer 'Yes').  De facto we just hope that there will never be 
clashing names in a given deployment.

2. Note that the names used here are project or code names.  For example 
'calico', not 'OpenStack L3-only Networking'.

>  Having someone do this for OpenStack as a whole
> is a necessary part of having a community-wide namespace such as service
> types.

Yes, but that doesn't necessarily mean 'OpenStack Networking' rather 
than 'Neutron', I think.

Neil



__
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

Re: [openstack-dev] [all] the trouble with names

[michael mccune]

On 02/05/2016 07:56 AM, Chris Dent wrote:

On Thu, 4 Feb 2016, 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.


This is the only option presented thus far which meets the needs of
end users and also some of our stated goals about creating
interoperable OpenStack-based clouds.

It does, however, require some integration and orchestration between
TC, Service Catalog work, and API-WG guidelines.


Downside, yet another contention point.


What's the issue with contention? Contention is one of several tools
that humans use to resolve disagreement and reached a shared
understanding of the problem space. Without shared understanding
in a community there's zero chance a community will create and work
towards shared goals. Because even if everyone is using the same
words for the goals, if they aren't using the same meanings, it's
all bunk.

When we, as a group, start to contend over terms and identifiers
that's just a signal that we don't really know what we're trying to
do and need to work at it. A lot of people, frustrated with all this
talk, will call it bikeshedding and then go off and do their own
thing, potentially not in concert with other people's goals. Making
all that talk is sometimes necessary if we want to be headed in the
same direction[1].

The economics of our situation often make that kind of cross-project
noodling challenging. As a group of open source devs we likely need
to keep our patrons clearly aware of the value and amount of what
some would call overhead.

It is not overhead. It's a major part of the work.

The big tent, in some sense, has been an invitation to allow people
to work on a more diverse set of goals. At the edge this is
beneficial as it means more useful stuff, but it has diffused
understanding of what "OpenStack" is. For consumers of OpenStack (and
for devs who are primarily concerned with making a thing called
OpenStack that is useful for those consumers) there needs to be a
thing which is OpenStack and that thing needs to be consistent and
coherent. And limited[2].



well said


A tool we have at our disposal for creating that consistency is the
service catalog and specifically the service catalog types.

Some will argue that this will lead to people contending over who
should occupy a type, as if that were a bad thing. It is not. Having
that discussion will help identify the flaws in the proposed
occupiers and keep the discussion of "what are we" alive and
healthy[3].


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.


I'm happy for the API-wg to handle some of this if mike and Everett
are as well. Making it work well will require everybody plays well
with the service catalog too[4]



i'm open to this, assuming we create a well defined process to keeping 
the names in order.



The biggest challenge I predict is when we need to change things, as
we inevitably will. Many currently hold dear that we cannot impose
change upon the existing user base. Sometimes you do and really it's
not that much of a big deal compared to the pain of running
OpenStack in the first place.

[1] It's perfectly okay for tools to not head in the same
direction, especially if they can be consumed as independent
libraries or services and are not embedded in the world of
OpenStack. This is a good thing. There's far too much stuff _in_
OpenStack that should just be _used by_ OpenStack (or used by
OpenStack users).

[2] Yes, this means we need to have an opinion about what OpenStack
is and build that opinion into the system. That's good. OpenStack is
insufficiently generic to be unopinionated. Let's just get over
that.

[3] At the moment it appears that much of the time the goal of
OpenStack is to keep the gate running. This is classic statism at
its worst. Straight out of the movie Brazil.

[4]
http://specs.openstack.org/openstack/openstack-specs/specs/service-catalog.html




__
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

Re: [openstack-dev] [all] the trouble with names

[michael mccune]

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 +:

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

Re: [openstack-dev] [all] the trouble with names

[Dean Troyer]

On Fri, Feb 5, 2016 at 7:13 AM, Neil Jerram 
wrote:

> On 04/02/16 11:40, Sean Dague wrote:
> > 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.
>
> This is my preference.  Yes, it means that there is an education hurdle
> for anyone new to OpenStack to overcome.  But once that is done, there
> is a concise and precise term that they and we can all use and understand.
>

Have a look at the browser User-Agent headers and let me know how that has
worked out for them:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36

Two of those product/code names are lies for compatibility purposes.  We
(OpenStack) should not be promoting that sort of nonsense on our users just
to save us a little bit of inconvenience in the development process.

To add something positive to the discussion, we should remember how much of
OpenStack consists of plugin-capable architecture, specifically so that
out-of-tree components can be accommodated for whatever reason.  The
projects play the role of arbitrator of namespaces in the case of many
back-end drivers.  Having someone do this for OpenStack as a whole is a
necessary part of having a community-wide namespace such as service types.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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

Re: [openstack-dev] [all] the trouble with names

[Dean Troyer]

On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent  wrote:

> I think this discussion is dancing around the edges of a referendum on
> the "duplication" aspect of the big tent.


It is also dancing around the separation of 'API' from 'implementation'.
There is a long-standing disagreement on whether OpenStack APIs can/should
stand on their own, or simply be defined as 'whatever project Foo
implements'.  We already have seen independent implementations of OpenStack
APIs, although not (yet?) as OpenStack projects.  Duplication is already
happening in the wild.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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

Re: [openstack-dev] [all] the trouble with names

[Neil Jerram]

On 04/02/16 11:40, Sean Dague wrote:
> 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.

This is my preference.  Yes, it means that there is an education hurdle
for anyone new to OpenStack to overcome.  But once that is done, there
is a concise and precise term that they and we can all use and understand.

To look at the case that I'm most familiar with:  For me the pervasive
use of 'OpenStack Networking' - rather than 'Neutron' - in docs is both
cumbersome and potentially confusing.  'Networking' can have different
connotations outside the OpenStack context from those inside, and often
doc must talk about both those concepts at the same time.  It would be
much simpler, IMO, just to say 'Neutron' when that is what we mean.

Regards,
Neil


__
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

Re: [openstack-dev] [all] the trouble with names

[Chris Dent]

On Thu, 4 Feb 2016, gordon chung wrote:


my concern with #2 is, we will just end up going to thesaurus.com and
searching for alternate words that mean the same general thing and
this will be equally confusing. with the big tent, we essentially
agreed that duplication is possible, so no matter how granular we make
the scope, i'm not sure there's a way for any project to own a domain
anymore. it seems this question is better addressed by addressing how
the TC should handle big tent first?


It's just like you to cut straight to the crux of the biscuit.

I think this discussion is dancing around the edges of a referendum on
the "duplication" aspect of the big tent.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [all] the trouble with names

[Chris Dent]

On Thu, 4 Feb 2016, 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.


This is the only option presented thus far which meets the needs of
end users and also some of our stated goals about creating
interoperable OpenStack-based clouds.

It does, however, require some integration and orchestration between
TC, Service Catalog work, and API-WG guidelines.


Downside, yet another contention point.


What's the issue with contention? Contention is one of several tools
that humans use to resolve disagreement and reached a shared
understanding of the problem space. Without shared understanding
in a community there's zero chance a community will create and work
towards shared goals. Because even if everyone is using the same
words for the goals, if they aren't using the same meanings, it's
all bunk.

When we, as a group, start to contend over terms and identifiers
that's just a signal that we don't really know what we're trying to
do and need to work at it. A lot of people, frustrated with all this
talk, will call it bikeshedding and then go off and do their own
thing, potentially not in concert with other people's goals. Making
all that talk is sometimes necessary if we want to be headed in the
same direction[1].

The economics of our situation often make that kind of cross-project
noodling challenging. As a group of open source devs we likely need
to keep our patrons clearly aware of the value and amount of what
some would call overhead.

It is not overhead. It's a major part of the work.

The big tent, in some sense, has been an invitation to allow people
to work on a more diverse set of goals. At the edge this is
beneficial as it means more useful stuff, but it has diffused
understanding of what "OpenStack" is. For consumers of OpenStack (and
for devs who are primarily concerned with making a thing called
OpenStack that is useful for those consumers) there needs to be a
thing which is OpenStack and that thing needs to be consistent and
coherent. And limited[2].

A tool we have at our disposal for creating that consistency is the
service catalog and specifically the service catalog types.

Some will argue that this will lead to people contending over who
should occupy a type, as if that were a bad thing. It is not. Having
that discussion will help identify the flaws in the proposed
occupiers and keep the discussion of "what are we" alive and
healthy[3].


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.


I'm happy for the API-wg to handle some of this if mike and Everett
are as well. Making it work well will require everybody plays well
with the service catalog too[4]

The biggest challenge I predict is when we need to change things, as
we inevitably will. Many currently hold dear that we cannot impose
change upon the existing user base. Sometimes you do and really it's
not that much of a big deal compared to the pain of running
OpenStack in the first place.

[1] It's perfectly okay for tools to not head in the same
direction, especially if they can be consumed as independent
libraries or services and are not embedded in the world of
OpenStack. This is a good thing. There's far too much stuff _in_
OpenStack that should just be _used by_ OpenStack (or used by
OpenStack users).

[2] Yes, this means we need to have an opinion about what OpenStack
is and build that opinion into the system. That's good. OpenStack is
insufficiently generic to be unopinionated. Let's just get over
that.

[3] At the moment it appears that much of the time the goal of
OpenStack is to keep the gate running. This is classic statism at
its worst. Straight out of the movie Brazil.

[4] 
http://specs.openstack.org/openstack/openstack-specs/specs/service-catalog.html

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [all] the trouble with names

[Hayes, Graham]

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 +:
>> 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

Re: [openstack-dev] [all] the trouble with names

[Ronald Bradford]

While we all consider to look at this problem from within the perspective
of OpenStack, the consumer of OpenStack is somebody that is wanting to run
a cloud, and not develop a cloud (granted there is overlap in said
implementation).  They are also comparing clouds and features (e.g.
compute, storage), reading about the new features of cloud providers etc.
 The service catalog, the UI (i.e. names inside Horizon like Compute) need
to present generic names.

It would make it easier for consumers of API's to not need a translation
registry to know nova means compute.   This means that the translation is
internal with us developers. We should be able to live with that.

#2  IMO opinion serves best what OpenStack software is used for, and who it
is designed for.



Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford 
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Thu, Feb 4, 2016 at 10:45 AM, Sean Dague  wrote:

> On 02/04/2016 10:31 AM, Nick Chase wrote:
> > What about using a combination of two word names, and generic names. For
> > example, you might have
> >
> > cinder-blockstorage
> >
> > and
> >
> > foo-blockstorage
> >
> > The advantage there is that we don't need to do the thesaurus.com
> >  thing, but also, it enables to specify just
> >
> > blockstorage
> >
> > via a registry.  The advantage of THAT is that if a user wants to change
> > out the "default" blockstorage engine (for example) we could provide
> > them with a way to do that.  The non-default would have to support the
> > same API, of course, but it definitely fits with the "pluggable" nature
> > of OpenStack.
>
> This feels a bit like all the downsides of #1 (people have to know about
> codenames, and make projects know about the codenames of other projects)
> + all the downsides of #2 (we still need a naming registry).
>
> I do agree it is a 4th option, but the downsides seem higher than either
> #1 or #2.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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

Re: [openstack-dev] [all] the trouble with names

[Sean Dague]

On 02/04/2016 10:31 AM, Nick Chase wrote:
> What about using a combination of two word names, and generic names. For
> example, you might have 
> 
> cinder-blockstorage
> 
> and
> 
> foo-blockstorage
> 
> The advantage there is that we don't need to do the thesaurus.com
>  thing, but also, it enables to specify just
> 
> blockstorage
> 
> via a registry.  The advantage of THAT is that if a user wants to change
> out the "default" blockstorage engine (for example) we could provide
> them with a way to do that.  The non-default would have to support the
> same API, of course, but it definitely fits with the "pluggable" nature
> of OpenStack.

This feels a bit like all the downsides of #1 (people have to know about
codenames, and make projects know about the codenames of other projects)
+ all the downsides of #2 (we still need a naming registry).

I do agree it is a 4th option, but the downsides seem higher than either
#1 or #2.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [all] the trouble with names

[Ryan Brown]

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 +:

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?


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


--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

__
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

Re: [openstack-dev] [all] the trouble with names

[Nick Chase]

What about using a combination of two word names, and generic names. For
example, you might have

cinder-blockstorage

and

foo-blockstorage

The advantage there is that we don't need to do the thesaurus.com thing,
but also, it enables to specify just

blockstorage

via a registry.  The advantage of THAT is that if a user wants to change
out the "default" blockstorage engine (for example) we could provide them
with a way to do that.  The non-default would have to support the same API,
of course, but it definitely fits with the "pluggable" nature of OpenStack.

  Nick
__
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

Re: [openstack-dev] [all] the trouble with names

[gordon chung]

On 04/02/2016 9:04 AM, Morgan Fainberg wrote:


On Thu, Feb 4, 2016 at 4:51 AM, Doug Hellmann 
mailto:d...@doughellmann.com>> wrote:
Excerpts from Sean Dague's message of 2016-02-04 06:38:26 -0500:
> 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.
>
> 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
>

This feels like something that should be designed with end-users
in mind, and that means making choices about descriptive words
rather than quirky in-jokes.  As much as I hate to think about the
long threads some of the contention is likely to introduce, not to
mention the bikeshedding over the terms themselves, I have become
convinced that our best long-term solution is a term/name registry
(option 2). We already have that pattern in the governance repository
where official projects describe their service type.

To reduce contention, we could agree in advance to support multi-word
names ("block storage" and "object storage", "block backup" and
"file backup", etc.). Decisions about noun-verb vs. verb-noun,
punctuation, etc. can be dealt with by the group that takes on the
task of setting standards.

As I said in the TC meeting, this seems like something the API working
group could do, if they wanted to take on the responsibility. If not,
then we should establish a new group with a mandate from the TC. Since
we have something like a product catalog already in the governance repo,
we can keep the new data there.

Doug

I am a fan of option #2. I also want to point out that os-client-config has 
encoded some of these names as well[1], which is pushing us in the direction of 
#2.  I 100% agree that the end user perspective also leans us towards option #2.

I am very against "hope for the best options".
i'm inclined to say #2 as well since the code names, based on my experience, 
lead to assumptions of what the project covers/does based on an elevator pitch 
description someone heard one time.

i definitely agree that we shouldn't concern ourselves with non big tent 
projects.

my concern with #2 is, we will just end up going to thesaurus.com and searching 
for alternate words that mean the same general thing and this will be equally 
confusing. with the big tent, we essentially agreed that duplication is 
possible, so no matter how granular we make the scope, i'm not sure there's a 
way for any project to own a domain anymore. it seems this question is better 
addressed by addressing how the TC should handle big tent first?

cheers,

--
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-r

Re: [openstack-dev] [all] the trouble with names

[Doug Hellmann]

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 +:
> >> 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

Re: [openstack-dev] [all] the trouble with names

[Sean Dague]

On 02/04/2016 09:35 AM, Anne Gentle wrote:
> 
> 
> On Thu, Feb 4, 2016 at 7:33 AM, Sean Dague  > wrote:
> 
> On 02/04/2016 08:18 AM, Doug Hellmann wrote:
> > Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:
> >> 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.
> 
> 
> Project names should not be exposed to end users.
> 
> Maybe the service names belong in an example, vetted service catalog as
> a place to look to see if your name is already taken. I sense we have to
> first start with endpoints, then move to the resources, and honestly I
> feel lately "let the best API design win." For example, with PayPal and
> Stripe, there are differentiators that would cause a dev to choose one
> over another. PayPal has a /payments resource and Stripe has a /charges
> resource. Those resources are where some of the conflict is starting to
> be seen for us in OpenStack with backups. If we expect end users to use
> the whole cloud then we need to outline the resources that are reserved
> already to avoid end-user confusion. Believe me, I document this stuff,
> and I know it's difficult to understand. We have to advocate for our end
> users now, today, here.
> 
> For the schedule example, is it the Compute endpoint that intakes the
> scheduling operations? Or is there a new endpoint?

The intent is a new dedicated endpoint, to ensure an easy migration to

Re: [openstack-dev] [all] the trouble with names

[Anne Gentle]

On Thu, Feb 4, 2016 at 7:33 AM, Sean Dague  wrote:

> On 02/04/2016 08:18 AM, Doug Hellmann wrote:
> > Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:
> >> 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.
>

Project names should not be exposed to end users.

Maybe the service names belong in an example, vetted service catalog as a
place to look to see if your name is already taken. I sense we have to
first start with endpoints, then move to the resources, and honestly I feel
lately "let the best API design win." For example, with PayPal and Stripe,
there are differentiators that would cause a dev to choose one over
another. PayPal has a /payments resource and Stripe has a /charges
resource. Those resources are where some of the conflict is starting to be
seen for us in OpenStack with backups. If we expect end users to use the
whole cloud then we need to outline the resources that are reserved already
to avoid end-user confusion. Believe me, I document this stuff, and I know
it's difficult to understand. We have to advocate for our end users now,
today, here.

For the schedule example, is it the Compute endpoint that intakes the
scheduling operations? Or is there a new endpoint?

API design and developer experience must become our first thought.

Anne


>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
_

Re: [openstack-dev] [all] the trouble with names

[michael mccune]

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 +:

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)


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

Re: [openstack-dev] [all] the trouble with names

[Morgan Fainberg]

On Thu, Feb 4, 2016 at 4:51 AM, Doug Hellmann  wrote:

> Excerpts from Sean Dague's message of 2016-02-04 06:38:26 -0500:
> > 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.
> >
> > 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
> >
>
> This feels like something that should be designed with end-users
> in mind, and that means making choices about descriptive words
> rather than quirky in-jokes.  As much as I hate to think about the
> long threads some of the contention is likely to introduce, not to
> mention the bikeshedding over the terms themselves, I have become
> convinced that our best long-term solution is a term/name registry
> (option 2). We already have that pattern in the governance repository
> where official projects describe their service type.
>
> To reduce contention, we could agree in advance to support multi-word
> names ("block storage" and "object storage", "block backup" and
> "file backup", etc.). Decisions about noun-verb vs. verb-noun,
> punctuation, etc. can be dealt with by the group that takes on the
> task of setting standards.
>
> As I said in the TC meeting, this seems like something the API working
> group could do, if they wanted to take on the responsibility. If not,
> then we should establish a new group with a mandate from the TC. Since
> we have something like a product catalog already in the governance repo,
> we can keep the new data there.
>
> Doug
>

I am a fan of option #2. I also want to point out that os-client-config has
encoded some of these names as well[1], which is pushing us in the
direction of #2.  I 100% agree that the end user perspective also leans us
towards option #2.

I am very against "hope for the best options".

[1]
https://github.com/openstack/os-client-config/blob/master/os_client_config/constructors.json

--Morgan
__
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

Re: [openstack-dev] [all] the trouble with names

[Sean Dague]

On 02/04/2016 08:18 AM, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:
>> 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.

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [all] the trouble with names

[Thierry Carrez]

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 +:

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 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).


--
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [all] the trouble with names

[Hayes, Graham]

On 04/02/2016 13:24, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:
>> 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

Re: [openstack-dev] [all] the trouble with names

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:
> 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?

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

Re: [openstack-dev] [all] the trouble with names

[Hayes, Graham]

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.

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

Re: [openstack-dev] [all] the trouble with names

[Doug Hellmann]

Excerpts from Sean Dague's message of 2016-02-04 06:38:26 -0500:
> 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.
> 
> 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
> 

This feels like something that should be designed with end-users
in mind, and that means making choices about descriptive words
rather than quirky in-jokes.  As much as I hate to think about the
long threads some of the contention is likely to introduce, not to
mention the bikeshedding over the terms themselves, I have become
convinced that our best long-term solution is a term/name registry
(option 2). We already have that pattern in the governance repository
where official projects describe their service type.

To reduce contention, we could agree in advance to support multi-word
names ("block storage" and "object storage", "block backup" and
"file backup", etc.). Decisions about noun-verb vs. verb-noun,
punctuation, etc. can be dealt with by the group that takes on the
task of setting standards.

As I said in the TC meeting, this seems like something the API working
group could do, if they wanted to take on the responsibility. If not,
then we should establish a new group with a mandate from the TC. Since
we have something like a product catalog already in the governance repo,
we can keep the new data there.

Doug

__
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-dev] [all] the trouble with names

[Sean Dague]

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.

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

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
__
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