Just my two cents, since I won't be able to make it to summit: When the artifact repository was proposed, I personally really liked the idea that images were just another artifact type eventually, even if they stayed separate for the time being.
However, the pros that you bring up do seem to make a lot of sense -- being able to design an API "from scratch" can lead to nicer APIs, and having the ability to use different backends for images vs artifacts could be quite useful from a performance perspective. Thus, let me propose this: what if you allowed different "pools" of artifacts to be housed on different backends and/or endpoints? This way, you could still put images in their own little bubble without losing the image --> artifact abstraction. It would also allow you to extend some of the "pros" of the split to other artifact types, since a cloud admin could have other artifacts besides images that needed to be in their own little bubble for performance reasons. For instance, a cloud administrator could define three "pools" (for lack of a better term ATM): "images", "general", and "critical-data", "images" and "critical-data" might be stored on specially-tuned high-performance backends, while "critical-data" might be on a large general-purpose backend. Best Regards, Solly Ross ----- Original Message ----- > From: "Alexander Tivelkov" <ativel...@mirantis.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Sent: Monday, October 27, 2014 8:08:47 AM > Subject: [openstack-dev] [Glance][Artifacts] Glance Artifacts Repository as > a standalone service > > 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 > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
