Open Stack

+1 on all of Jay's conclusions. :)

I¹m pretty new to OpenStack, but not at all to API, REST API, and web
development in general, and I concur : ŒNova¹, ŒSwift¹, ŒKeystone¹ and so
on makes it very hard to learn how things work in OpenStack and what each
of those parts are responsible with.
I¹ll be honest, I had to print this schema
(http://getcloudify.org/img/blog/openstackdiagram.jpg) and put the name on
it to be able to sort myself out of it. :)
I would also agree that projects/teams can keep their secret Œin the
family¹ name for differentiation (and also facilitate coopetition) and
tools, but I would love to be able to abstract it at some level (the
service level seems perfect for that).


As a dev, this get my votes. All of them in fact :)
As long as we can agree on the function of each service and associate a
name that has a natural don¹t-need-a-map-to-get-it, I¹m all for it.


Best,

Bruno Morel
Internap / iWeb Technologies

On 2015-07-05, 11:45, "Jay Pipes" <jaypipes at gmail.com> wrote:

>On 06/25/2015 02:19 PM, Monty Taylor wrote:
>> On 06/25/2015 01:35 PM, Devananda van der Veen wrote:
>>> Sean's point and Dmitri's are similar.
>>>
>>> There are APIs for projects which do not have official team or
>>>"program"
>>> names. And some teams may produce more than one forward-facing service.
>>> Naming the API based in the team name doesn't make sense.
>>>
>>> My previous point is that restricting the API name to the team/program
>>>name
>>> will prevent any competition among projects. It'll be impossibly
>>>confusing
>>> to users if more than one "monitoring" project exists, they all have
>>> different API, but each claim to be the one true
>>>OpenStack-Monitoring-API
>>
>> I believe that it is important that there is only one api in OpenStack
>> that provides a given short name. Even with the big tent.
>
>So do I. I've been saying that for quite some time. Which is why I've
>been arguing for referring to things like they are referred to on the
>API documentation site:
>
>http://developer.openstack.org/#api
>
>By the name of the API, which is "The OpenStack Compute API", not "The
>Nova API".
>
>> I say that because, as a user, I ask the service catalog for a well
>> known service type - "compute" or "baremetal" or "network" - and I get
>> back a REST endpoint that is ostensibly for that purpose.
>
>Precisely correct.
>
>> If I then have to introspect that service to find out what it really is,
>> we have fully jumped the shark and started prioritizing our own
>> navel-gazing over any hope of any human ever using what we're doing.
>>
>> So - yes, this is potentially, although not actually, a problem right
>> now. And we need to solve it before it moves from being an actual
>>problem.
>
>Right. Which is why I was trying to prevent this problem from becoming
>bigger than it needs to be, and trying to convince people to use the
>service type that appears in the Keystone Service Catalog as the {NAME}
>in X-OpenStack-{NAME}-API-Version header.
>
>Best,
>-jay
>
>>> On Jun 25, 2015 9:37 AM, "Sean Dague" <sean at dague.net> wrote:
>>>
>>>> On 06/25/2015 12:04 PM, Anne Gentle wrote:
>>>>>
>>>>>
>>>>> On Thu, Jun 25, 2015 at 10:55 AM, Dmitry Tantsur <dtantsur at redhat.com
>>>>> <mailto:dtantsur at redhat.com>> wrote:
>>>> <snip>
>>>>>
>>>>>
>>>>>      I'm not sure where the assumption comes from that people will
>>>>>know
>>>>>      "compute" better than "nova".
>>>>>
>>>>>
>>>>> I have been supporting developer end users on the Rackspace cloud for
>>>>> nearly four years now. I gave a talk in Paris at the Summit about
>>>>> supporting developers. Developers using cloud resources expect to use
>>>>> computing power or storage capacity to accomplish a broader task.
>>>>>Nova
>>>>> and swift have nothing to do with their expectations.
>>>>
>>>> That's good feedback, and clearly moves the needle in my head.
>>>>
>>>> It also does open up a question about the big tent nature, because
>>>>it's
>>>> unclear what projects that do not yet have a generic name allocated to
>>>> them would use.
>>>>
>>>>          -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
>>>>
>>>
>>>
>>>
>>> 
>>>________________________________________________________________________
>>>__
>>> 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
>>>
>>
>>
>> 
>>_________________________________________________________________________
>>_
>> 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
>>
>
>__________________________________________________________________________
>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