<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi folks!</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks all for the feedback. Yeah, this definitely needs more discussions, and the Summit is good place to have them. Thanks to Serg for offering a spot in the schedule. </div><div class="gmail_default" style="font-size:small">I hope to have some PoC by that time, so we can have something which can be demoed.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I'll try to attend the AppCatalog sessions as well. I didn't finalize my summit schedule yet, but I'll do my best to attend as much as I can.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks!</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><font size="2">--<br></font><div dir="ltr"><font size="2">Regards,<br>Alexander Tivelkov</font></div></div></div></div>
<br><div class="gmail_quote">On Fri, Oct 16, 2015 at 10:07 PM, Christopher Aedo <span dir="ltr"><<a href="mailto:doc@aedo.net" target="_blank">doc@aedo.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Oct 15, 2015 at 3:04 AM, Alexander Tivelkov<br>
<<a href="mailto:ativelkov@mirantis.com">ativelkov@mirantis.com</a>> wrote:<br>
> Hi folks,<br>
><br>
> I’ve noticed that the Community Application Catalog has begun to implement<br>
> its own API, and it seems to me that we are going to have some significant<br>
> duplication of efforts with the code which has already been implemented in<br>
> Glance as Artifact Repository initiative (also known as Glance V3).<br>
> From the very beginning of the App Catalog project (and I’ve been involved<br>
> in it since February) I’ve been proposing to use Glance as its backend,<br>
> because from my point of view it covers like 90% of the needed<br>
> functionality. But it looks like we have some kind of miscommunication here,<br>
> as I am getting some confusing questions and assumptions, like the vision of<br>
> Glance V3 being dedicated backend for Murano (which is definitely<br>
> incorrect).<br>
> So, I am writing the email to clarify my vision of what Glance V3 is and how<br>
> its features may be used to provide the REST API for Community App Catalog.<br>
><br>
> 1.  Versioned schema<br>
> First of all, Glance V3 operates on entities called “artifacts”, and these<br>
> ones perfectly map to the Data Assets of community app catalog. The<br>
> artifacts are strongly typed: there are artifact types for murano packages,<br>
> glance images, heat templates - and there may be (and will be) more. Each<br>
> artifact type is represented by a plugin, defining the schema of objects’<br>
> data and metadata and - optionally - custom logic. So, this thing is<br>
> extensible: when a new type of asset needs to be added to a catalog it can<br>
> be done really quickly by just defining the schema and putting that schema<br>
> into a plugin. Also, these plugins are versioned, so the possible changes in<br>
> the schema are handled properly.<br>
><br>
> 2. Generic properties<br>
> Next, all the artifact types in Glance V3 have some generic metadata<br>
> properties (i.e. part of the schema which is common for all the types),<br>
> including the name, the version, description, authorship information and so<br>
> on. This also corresponds to the data schema of community app catalog. The<br>
> mapping is not 1:1, but we can work together on this to make sure that these<br>
> generic properties match the expectations of the catalog.<br>
><br>
> 3. Versioning<br>
> Versions are very important for catalogs of objects, so Glance V3 was<br>
> initially designed keeping versioning questions in mind: each artifact has a<br>
> semver-based version assigned, so the artifacts having the same name but<br>
> different versions are grouped into the proper sequences. API is able to<br>
> query artifacts based on their version spec, e.g. it is possible to fetch<br>
> the latest artifact with the name “foo” having the version greater than 2.1<br>
> and less than 3.5.7 - or any other version spec, similar to pip or any other<br>
> similar tool. As far as I know, community app catalog does not have such<br>
> capabilities right now - and I strongly believe that it is really a must<br>
> have feature for a catalog to be successful. At least it is absolutely<br>
> mandatory for Murano packages, which are the only “real apps” among the<br>
> asset types right now.<br>
><br>
> 4. Cross artifact dependencies<br>
> Glance V3 also has the dependency relations from the very beginning, so they<br>
> may be defined as part of artifact type schema. As a result, an artifact may<br>
> “reference” any number of other artifacts with various semantic. For<br>
> example, murano package may define a set of references to other murano<br>
> packages and call it “requires” - and this will act similar to the<br>
> requirements of a python package. Similar properties may be defined for heat<br>
> templates and glance images - they may reference each other with various<br>
> semantics.<br>
> Of course, the definitions of such dependencies may be done internally<br>
> inside the packages, so they may be resolved locally by the service which is<br>
> going to use it, but letting the catalog know about them will allow us to do<br>
> the import-export operations for any given artifacts and its dependencies<br>
> automatically, only by the means of the catalog itself.<br>
><br>
> 5. Search and filtering API<br>
> Right now Glance V3 API is in experimental state (we plan to stabilize it<br>
> during the Mitaka cycle), but it already provides quite good capabilities to<br>
> discover things. It can search artifacts by their type, name and<br>
> (optionally) aforementioned version specs, by tag or even by arbitrary set<br>
> of metadata properties. We have plans to integrate Glance V3 with the<br>
> Searchlight project to have even more index and search capabilities using<br>
> its elastic search engine.<br>
><br>
> 6. Data storage<br>
> As you probably know, Glance does not own the binary data of its images.<br>
> Instead, it provides an abstraction of the backend storage, which may be<br>
> swift, ceph, s3 or something else. The same approach is used in Glance V3<br>
> for artifacts data, but with more per-type control: particular artifact<br>
> types may be configured independently to store their blobs in different<br>
> backends. This may be of use for Community App Catalog which operates on<br>
> different storages for its assets.<br>
><br>
> 7. Sharing and access control.<br>
> Glance V3 inherits the same access mechanics present in Glance V2: an<br>
> artifact may be visible to its owner tenant only, be public (i.e. visible to<br>
> all the tenants) or directly shared by the owner to a specific tenant. Also,<br>
> Glance can act in the anonymous mode (i.e. without an access token), thus<br>
> providing access to public artifacts even to unauthenticated users.<br>
> This can be easily applied to a public web service, such as community app<br>
> catalog: regular unauthenticated users use anonymous mode to access only the<br>
> public assets (this is the current behavior of apps.o.o), while registered<br>
> users will have their own private spaces (“tenants”) with various access<br>
> restrictions.<br>
><br>
> 8. The federation.<br>
> The ultimate goal for Glance Artifact Repository is ability to build trees<br>
> of artifact repos in different clouds. The top node of that tree is some<br>
> Global Application Catalog (and the <a href="http://apps.openstack.org" rel="noreferrer" target="_blank">apps.openstack.org</a> may be this global<br>
> catalog - if it is glance-based or at least supports glance v3 federation),<br>
> then there are repositories of particular openstack vendors or distributors,<br>
> then - the catalogs of enterprises operating different openstack clouds. The<br>
> particular glance deployments in that clouds are the leafs of that tree,<br>
> being able to search for data assets in all the upstream repositories,<br>
> download them from there or - if permitted - submit their local assets back<br>
> upstream. This will be the ultimate network for application delivery and<br>
> exchange in openstack world - and this is one of the main reasons we’ve<br>
> began the Artifacts initiative in Glance.<br>
> Unlike other aforementioned features this one is not implemented yet, but we<br>
> are planning to add it as soon as we are done with API stabilization goal.<br>
><br>
><br>
> There are many other features which are present in V3’s roadmap and may be<br>
> useful for the app catalog, such as ability to sign artifacts with their<br>
> developers’ keys and verify that keys on usage to ensure the authenticity of<br>
> the artifact.<br>
><br>
> What we don’t have right now is the ability to associate ratings (“stars”)<br>
> and comments to the artifact, as well as aggregating different usage and<br>
> download statistics: such features are really needed only for the public<br>
> website such as apps.o.o but are not required for Glance’s in particular<br>
> clouds. But we may find some way to solve this, either by wrapping glance<br>
> API with additional middleware which would add appropriate info from a<br>
> different data source, or by having custom plugins which are able to do<br>
> that, or in some other way: I am sure we may find a solution for this.<br>
><br>
> So, this was just a brief description of what Glance v3 has to offer as a<br>
> backend for App Catalog API.<br>
> It also worths to mention that this API is in “EXPERIMENTAL” state right<br>
> now, which means that it is not fixed and we may modify it significantly if<br>
> there is a need to. So we may work closer together to adopt it for the needs<br>
> of Community App Catalog.<br>
><br>
> I would really prefer to not create any overlaps between Glance v3 and the<br>
> community app catalog: if the app catalog builds its own incompatible<br>
> implementation of assets discovery and distribution API then we’ll have a<br>
> huge duplication of efforts for developers and lots of confusion to the<br>
> end-users who will get two entirely different ways to do the same task.<br>
><br>
> So, I’d propose to discuss these potential overlaps, look at the features<br>
> need by App Catalog and see how Glance V3 may be of use here. I’ll be more<br>
> than happy to help with that. We can dive deeper into the details here in<br>
> the mailing list or meet in person in Tokyo. I'll try to have a<br>
> demonstratable prototype by that time.<br>
<br>
</div></div>Alexander, you make some great points here about the feature overlaps<br>
between the Glance v3 API and where we are heading with the App<br>
Catalog.  There's good potential to re-use some of this work for sure,<br>
and I'm really looking forward to what comes of the PoC you talked<br>
about.<br>
<br>
Two important considerations against adopting Glance v3 wholesale<br>
(aside from the experimental nature and the possibility that key bits<br>
won't be ultimately adopted in the finished stable product) are<br>
development velocity and deployment goals.  As glance is a key<br>
component in any OpenStack cloud, and is expected to be deployed in<br>
hundreds (or thousands!) of environments, the dependencies and default<br>
requirements are tightly coupled to most other OpenStack projects.<br>
Obviously any changes to glance are weighed against how those will<br>
impact all these clouds, how upgrades will work, backwards and<br>
forwards compatibility, etc.  For all the benefits that come with<br>
working on a distributed open source project like this, it also tends<br>
to mean we can't always move very fast because of the potential impact<br>
across the landscape of the whole project.<br>
<br>
The App Catalog is in a different position - to put it really simply,<br>
we're developing a web site intended to benefit user of OpenStack<br>
clouds, and including some integration points to make it much easier<br>
for users to find and share things that run on OpenStack clouds.  But<br>
we're not tightly coupled to any of the other projects, and we're not<br>
expecting this to be something that's deployed on it's own with every<br>
OpenStack cloud.  In fact I'd argue deploying a local/private App<br>
Catalog dilutes the value and harms the ecosystem as a whole.<br>
<br>
Ideally we'll find a balanced way to benefit from the great work<br>
coming from the Glance team without limiting our design considerations<br>
or encumbering the App Catalog with requirements or limitations that<br>
shouldn't impact us.<br>
<br>
I'm really looking forward to speaking more about this in person in<br>
Tokyo, hopefully you can make it to the App Catalog sessions!<br>
<div class="HOEnZb"><div class="h5"><br>
-Christopher<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>