[openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

Ian Cordasco ian.cordasco at RACKSPACE.COM
Fri Dec 11 20:13:19 UTC 2015

On 12/11/15, 12:25, "Alexander Tivelkov" <ativelkov at mirantis.com> wrote:

>Hi folks!
>As it was decided during the Mitaka design summit, we are separating the
>experimental Artifact Repository API from the main Glance API. This API
>will have a versioning sequence independent from the main Glance API and
>will be run as a standalone optional
> service, listening on the port different from the standard glance-api
>port (currently the proposed default is 9393). Meanwhile, it will remain
>an integral part of the larger Glance project, sharing the database,
>implementation roadmap, development and review
> teams etc.

+1 to 9494 for DevStack so developers can run Arti and Searchlight along
side each other.

>Since this API will be consumed by both end-users and other Openstack
>services, its endpoint should be discoverable via regular service catalog
>API. This rises the question: what should be the service name and service
>type for the appropriate entree in
> the service catalog?
>We've came out with the idea to call the service "glare" (this is our
>internal codename for the artifacts initiative, being an acronym for
>"GLance Artifact REpository") and set its type to "artifacts". Other
>alternatives for the name may be "arti" or "glance_artifacts"
> and for the type - "assets" or "objects" (the latter may be confusing
>since swift's type is object-store, so I personally don't like it).

For the type, I would think either "asset" or "artifact" (along the lines
of how glance is "image", and neutron is "network"). I tend to lean
towards "artifact" though.

As for the "default" (I assume DevStack) name, why not just "glare", the
description should be "Glance Artifact Service" (which I think is slightly
more end-user important than the name).

>Well... we all know, naming is complicated... anyway, I'll appreciate any
>feedback on this. Thanks!
>Alexander Tivelkov


More information about the OpenStack-dev mailing list