Re: [openstack-dev] [all] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

2017-02-16 Thread Monty Taylor
On 02/16/2017 11:21 AM, Jay Pipes wrote:
> On 02/16/2017 08:14 AM, Dean Troyer wrote:
>> On Thu, Feb 16, 2017 at 7:06 AM, Andrey Kurilin
>>  wrote:
>>> Yes, I forgot about it. But it changes nothing.
>>> Custom implementation of particular service should cover the same API
>>> as an
>>> official one. For me, as for user, it doesn't metter if there is
>>> Keystone or
>>> MyAwesomeKeystone, I want just an service which implements Keystone
>>> functionality.
>>
>> Actually it is the name field that we really do not need, nor want.
> 
> Yes, +100 to this.
> 
>> Its continued existence is mostly driven by a desire by deployers to
>> brand their services, nothing should currently be using to as a
>> selector.
> 
> Not sure that the name vs. type thing is actually driven by a deployer
> desire for branding. More likely it's just a vestige of a time when
> project developers didn't care or know all that much about the
> difference between type and name and just put whatever they thought made
> sense.
> 
>>  The type field is what (should be) used in places like the
>> base URL for services under a combined endpoint (ie,
>> host/compute/v2.1/...) on a single port.
> 
> 100% agree.

+1 billion to all of this.


__
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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

2017-02-16 Thread Jay Pipes

On 02/16/2017 08:14 AM, Dean Troyer wrote:

On Thu, Feb 16, 2017 at 7:06 AM, Andrey Kurilin  wrote:

Yes, I forgot about it. But it changes nothing.
Custom implementation of particular service should cover the same API as an
official one. For me, as for user, it doesn't metter if there is Keystone or
MyAwesomeKeystone, I want just an service which implements Keystone
functionality.


Actually it is the name field that we really do not need, nor want.


Yes, +100 to this.


Its continued existence is mostly driven by a desire by deployers to
brand their services, nothing should currently be using to as a
selector.


Not sure that the name vs. type thing is actually driven by a deployer 
desire for branding. More likely it's just a vestige of a time when 
project developers didn't care or know all that much about the 
difference between type and name and just put whatever they thought made 
sense.


>  The type field is what (should be) used in places like the

base URL for services under a combined endpoint (ie,
host/compute/v2.1/...) on a single port.


100% agree.

Best,
-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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

2017-02-16 Thread Sean Dague
On 02/16/2017 08:47 AM, Ian Cordasco wrote:
> -Original Message-
> From: Andrey Kurilin <akuri...@mirantis.com>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Date: February 16, 2017 at 07:08:19
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [all] Do we need service types at all?!
> (Re: [octavia][sdk] service name for octavia)
> 
>> On Thu, Feb 16, 2017 at 1:57 PM, Radomir Dopieralski > > wrote:
>>
>>> I think that you have to remember that OpenStack doesn't only work with
>>> officially approved OpenStack services, but with any services that have a
>>> conforming API.
>>>
>>
>> Yes, I forgot about it. But it changes nothing.
>> Custom implementation of particular service should cover the same API as an
>> official one. For me, as for user, it doesn't metter if there is Keystone
>> or MyAwesomeKeystone, I want just an service which implements Keystone
>> functionality.
> 
> As others are trying to explain, what you want is the "OpenStack
> Identity API", not a service whose name matches "*Keystone*". Keystone
> is the implementation "Identity" is the thing it does and what you're
> looking for from a service that is not Keystone.
> 
> Same goes for clouds that swap out RadosGW for Swift. They're looking
> for an OpenStack Object Store API. They're not fuzzy matching on
> project name.

Agree.

That was the general recommendation that has come out of the service
catalog discussions in the past.

Remove the name field, only keep the type field. Only use generic names
in the type field - https://github.com/openstack/service-types-authority

-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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

2017-02-16 Thread Ian Cordasco
-Original Message-
From: Andrey Kurilin <akuri...@mirantis.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: February 16, 2017 at 07:08:19
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] Do we need service types at all?!
(Re: [octavia][sdk] service name for octavia)

> On Thu, Feb 16, 2017 at 1:57 PM, Radomir Dopieralski > > wrote:
>
> > I think that you have to remember that OpenStack doesn't only work with
> > officially approved OpenStack services, but with any services that have a
> > conforming API.
> >
>
> Yes, I forgot about it. But it changes nothing.
> Custom implementation of particular service should cover the same API as an
> official one. For me, as for user, it doesn't metter if there is Keystone
> or MyAwesomeKeystone, I want just an service which implements Keystone
> functionality.

As others are trying to explain, what you want is the "OpenStack
Identity API", not a service whose name matches "*Keystone*". Keystone
is the implementation "Identity" is the thing it does and what you're
looking for from a service that is not Keystone.

Same goes for clouds that swap out RadosGW for Swift. They're looking
for an OpenStack Object Store API. They're not fuzzy matching on
project name.

--
Ian Cordasco

__
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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

2017-02-16 Thread Dean Troyer
On Thu, Feb 16, 2017 at 7:06 AM, Andrey Kurilin  wrote:
> Yes, I forgot about it. But it changes nothing.
> Custom implementation of particular service should cover the same API as an
> official one. For me, as for user, it doesn't metter if there is Keystone or
> MyAwesomeKeystone, I want just an service which implements Keystone
> functionality.

Actually it is the name field that we really do not need, nor want.
Its continued existence is mostly driven by a desire by deployers to
brand their services, nothing should currently be using to as a
selector.  The type field is what (should be) used in places like the
base URL for services under a combined endpoint (ie,
host/compute/v2.1/...) on a single port.  For any alternate
implementations of a service that a deployer wants to take the place
of an OpenStack service this is how that is done seamlessly, no lying
about the name like the browser User-Agent header nonsense.

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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

2017-02-16 Thread Andrey Kurilin
On Thu, Feb 16, 2017 at 1:57 PM, Radomir Dopieralski  wrote:

> I think that you have to remember that OpenStack doesn't only work with
> officially approved OpenStack services, but with any services that have a
> conforming API.
>

Yes, I forgot about it. But it changes nothing.
Custom implementation of particular service should cover the same API as an
official one. For me, as for user, it doesn't metter if there is Keystone
or MyAwesomeKeystone, I want just an service which implements Keystone
functionality.


> OpenStack itself provides implementations of those services, and you are
> right that it's unlikely that there will be two competing implementations
> for the same service type officially endorsed by OpenStack. But you are
> ignoring 3rd-party services that are being used, and also the possibility
> that the services will change in the future. Since it doesn't really cost
> us to keep this flexibility, I think it's reasonable to keep doing it.
>
> On Thu, Feb 16, 2017 at 11:55 AM, Andrey Kurilin 
> wrote:
>
>> Hi everyone!
>>
>> When I started contribution to OpenStack long time ago, I asked about the
>> reason of having two entities - service type and name; at that time I got
>> an answer that service name is a name of the project that implements
>> particular service type, so it is possible to have several projects which
>> implement one service type. That answer satisfied me.
>>
>> The reality of OpenStack is that there is no and there will not be
>> several implementations of one "service type". Even when we had nova-net
>> and neutron, only the neutron registered his service in the catalog.
>>
>> An example of Octavia shows that everybody was ok about having service
>> name equal with type before inconsistency was found. That is why I want to
>> ask again: Do we need two separate entities and if yes - why? Maybe service
>> name and description fields should be enough?
>>
>> On Wed, Feb 15, 2017 at 3:08 AM, Qiming Teng 
>> wrote:
>>
>>> When reviewing a recent patch that adds openstacksdk support to octavia,
>>> I found that octavia is using 'octavia' as its service name instead of
>>> 'loadbalancing' or 'loadbalancingv2' or something similar.
>>>
>>> The overall suggestion is to use a word/phrase that indicates what a
>>> service do instead of the name of the project providing that service.
>>>
>>> Below is the list of the service types currently supported by
>>> openstacksdk:
>>>
>>> 'alarming',# aodh
>>> 'baremetal',   # ironic
>>> 'clustering',  # senlin
>>> 'compute', # nova
>>> 'database',# trove
>>> 'identity',# keystone
>>> 'image',   # glance
>>> 'key-manager', # barbican
>>> 'messaging',   # zaqar
>>> 'metering',# ceilometer
>>> 'network', # neutron
>>> 'object-store',   # swift
>>> 'octavia',# <--- this is an exception
>>> 'orchestration',  # heat
>>> 'volume', # cinder
>>> 'workflowv2', # mistral
>>>
>>> While I believe this has been discussed about a year ago, I'm not sure
>>> if there are things we missed so I'm brining this issue to a broader
>>> audience for discussion.
>>>
>>> Reference:
>>>
>>> [1] Patch to python-openstacksdk:
>>> https://review.openstack.org/#/c/428414
>>> [2] Octavia service naming:
>>> http://git.openstack.org/cgit/openstack/octavia/tree/devstac
>>> k/plugin.sh#n52
>>>
>>> Regards,
>>>  Qiming
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
Best regards,
Andrey Kurilin.
__
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] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

2017-02-16 Thread Radomir Dopieralski
I think that you have to remember that OpenStack doesn't only work with
officially approved OpenStack services, but with any services that have a
conforming API. OpenStack itself provides implementations of those
services, and you are right that it's unlikely that there will be two
competing implementations for the same service type officially endorsed by
OpenStack. But you are ignoring 3rd-party services that are being used, and
also the possibility that the services will change in the future. Since it
doesn't really cost us to keep this flexibility, I think it's reasonable to
keep doing it.

On Thu, Feb 16, 2017 at 11:55 AM, Andrey Kurilin 
wrote:

> Hi everyone!
>
> When I started contribution to OpenStack long time ago, I asked about the
> reason of having two entities - service type and name; at that time I got
> an answer that service name is a name of the project that implements
> particular service type, so it is possible to have several projects which
> implement one service type. That answer satisfied me.
>
> The reality of OpenStack is that there is no and there will not be
> several implementations of one "service type". Even when we had nova-net
> and neutron, only the neutron registered his service in the catalog.
>
> An example of Octavia shows that everybody was ok about having service
> name equal with type before inconsistency was found. That is why I want to
> ask again: Do we need two separate entities and if yes - why? Maybe service
> name and description fields should be enough?
>
> On Wed, Feb 15, 2017 at 3:08 AM, Qiming Teng 
> wrote:
>
>> When reviewing a recent patch that adds openstacksdk support to octavia,
>> I found that octavia is using 'octavia' as its service name instead of
>> 'loadbalancing' or 'loadbalancingv2' or something similar.
>>
>> The overall suggestion is to use a word/phrase that indicates what a
>> service do instead of the name of the project providing that service.
>>
>> Below is the list of the service types currently supported by
>> openstacksdk:
>>
>> 'alarming',# aodh
>> 'baremetal',   # ironic
>> 'clustering',  # senlin
>> 'compute', # nova
>> 'database',# trove
>> 'identity',# keystone
>> 'image',   # glance
>> 'key-manager', # barbican
>> 'messaging',   # zaqar
>> 'metering',# ceilometer
>> 'network', # neutron
>> 'object-store',   # swift
>> 'octavia',# <--- this is an exception
>> 'orchestration',  # heat
>> 'volume', # cinder
>> 'workflowv2', # mistral
>>
>> While I believe this has been discussed about a year ago, I'm not sure
>> if there are things we missed so I'm brining this issue to a broader
>> audience for discussion.
>>
>> Reference:
>>
>> [1] Patch to python-openstacksdk:
>> https://review.openstack.org/#/c/428414
>> [2] Octavia service naming:
>> http://git.openstack.org/cgit/openstack/octavia/tree/devstac
>> k/plugin.sh#n52
>>
>> Regards,
>>  Qiming
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best regards,
> Andrey Kurilin.
>
> __
> 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-dev] [all] Do we need service types at all?! (Re: [octavia][sdk] service name for octavia)

2017-02-16 Thread Andrey Kurilin
Hi everyone!

When I started contribution to OpenStack long time ago, I asked about the
reason of having two entities - service type and name; at that time I got
an answer that service name is a name of the project that implements
particular service type, so it is possible to have several projects which
implement one service type. That answer satisfied me.

The reality of OpenStack is that there is no and there will not be several
implementations of one "service type". Even when we had nova-net and
neutron, only the neutron registered his service in the catalog.

An example of Octavia shows that everybody was ok about having service name
equal with type before inconsistency was found. That is why I want to ask
again: Do we need two separate entities and if yes - why? Maybe service
name and description fields should be enough?

On Wed, Feb 15, 2017 at 3:08 AM, Qiming Teng 
wrote:

> When reviewing a recent patch that adds openstacksdk support to octavia,
> I found that octavia is using 'octavia' as its service name instead of
> 'loadbalancing' or 'loadbalancingv2' or something similar.
>
> The overall suggestion is to use a word/phrase that indicates what a
> service do instead of the name of the project providing that service.
>
> Below is the list of the service types currently supported by
> openstacksdk:
>
> 'alarming',# aodh
> 'baremetal',   # ironic
> 'clustering',  # senlin
> 'compute', # nova
> 'database',# trove
> 'identity',# keystone
> 'image',   # glance
> 'key-manager', # barbican
> 'messaging',   # zaqar
> 'metering',# ceilometer
> 'network', # neutron
> 'object-store',   # swift
> 'octavia',# <--- this is an exception
> 'orchestration',  # heat
> 'volume', # cinder
> 'workflowv2', # mistral
>
> While I believe this has been discussed about a year ago, I'm not sure
> if there are things we missed so I'm brining this issue to a broader
> audience for discussion.
>
> Reference:
>
> [1] Patch to python-openstacksdk:
> https://review.openstack.org/#/c/428414
> [2] Octavia service naming:
> http://git.openstack.org/cgit/openstack/octavia/tree/
> devstack/plugin.sh#n52
>
> Regards,
>  Qiming
>
>
> __
> 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
>



-- 
Best regards,
Andrey Kurilin.
__
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