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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
