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

Radomir Dopieralski openstack at sheep.art.pl
Thu Feb 16 11:57:39 UTC 2017

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 <akurilin at mirantis.com>

> 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 <tengqim at linux.vnet.ibm.com>
> 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-request at 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-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/20170216/7d0f45fd/attachment.html>

More information about the OpenStack-dev mailing list