Open Stack

Hi stackers,

It has been some time since the announcement of Artifacts initiative
within the Glance. The feature was not complete in Juno, but is being
actively developed now and has good chances for landing in Kilo.
However, recently on the Glance Virtual Mini-summit we had a
discussions which lead to an idea to change one of the core design
concepts of the Glance Artifact repository [1]

Initially we planned to run Artifact repository as part of existing
Glance service(s): all the APIs to handle artifacts were supposed to
be hosted by glance-api service, with glance-registry as optional
backend. Artifact-related endpoints were designed to be in the /v2/
branch of the API hierarchy, and were supposed to be similar in syntax
and semantics to the existing v2/images endpoints.

Now it is suggested to host artifacts as a standalone process
listening to a different port (and probably deployed on a different
host) and registered in the keystone as a separate service type.
The code will be still part of the primary Glance repo - so this is
not the question of starting another project or program, this is just
about having a new daemon in the openstack deployment.

This approach has some obvious pros and some less-obvious cons.
Most important is the ability to load-balance images and artifacts
independenly, being sure that any load on artifacts repo does no
affect the performance of images - and vice versa. Also, this will
allow us to provide different configuration options (including
different backing storages) to these different components which will
increase the overall flexibility and customizability of the system.
We'll be able to design the artifacts API "from scratch" without the
need to comply with the existing semantics and architecture of
images-part, reusing only the components which are really needed.

At the same time we'll loose the transparency between the concepts of
"image" and "artifact": initially we planned to make them very
similar, so when we are finally ready to make images just one of the
available artifact types, the migration may be trivial. If we now
separate them into different services, we draw a strict border and
potentially complicate the migration.

IMHO, the pros outweigh the cons, so I personally like the idea of
service separation - and all the participants of our virtual summit
seemed to share the same opinion. However, it is a serious design
change, so I'd like to hear the opinions of the wider audience.

We have planned a design session in Paris  ([2]) to discuss this
change in more details (the topic is applicable not only to Artifacta,
but to other initiatives under the hood of Glance as well, e.g.
metadef catalog, index service etc) - please feel free to join and
discuss. And please do not hesitate to share any concerns in the
mailing list before the summit starts: the more opinions we have, the
better solution we will make.



[1] https://etherpad.openstack.org/p/kilo-glance-artifacts-current-state-of-development
[2] https://etherpad.openstack.org/p/kilo-glance-summit-topics-final

--
Regards,
Alexander Tivelkov