Open Stack

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 <http://twitter.com/ronaldbradford>
Skype:     RonaldBradford
GTalk:     Ronald.Bradford
IRC:         rbradfor


On Thu, Feb 4, 2016 at 10:45 AM, Sean Dague <sean at dague.net> 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
> > <http://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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160204/13854dfa/attachment.html>