<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi Alexander, Thank you for your input.<br></div><div><br></div><div>I think we need to clearly define what a version means for an artifact.</div><div>First, I would like to comeback to the definition of an artifact: this broader audience might not be aware of this concept. </div><div>As of today, my understanding is the following:</div><div>An artifact is a set of metadata without any pre-defined structure. The only contract is that these artifacts will reference one or many blocks of bits (potentially images) stored in the Glance storage backends.</div><div>With that in mind, I can see two types of versions: metadata version and the version of the actual bits.</div><div>I think the version you are talking about is a mix of two versions you I mention above. Could you confirm? </div><div><br></div><div>Now, I have another question: you mention that you have can several versions of an artifact accessible in the system: does that mean that the previous versions are still available (i.e. both metadata and actual blocks of data are available)? Can I rollback and use version #1 if the latest version of my artifact is version #2? Based on your question, I think the answer is Yes in which case this comes with a lot of other issues: we are dealing with block of data that can have big sizes: you need to give the ability to the user to say: "I want to store only the last 2 versions and not the full history". So, to answer you question, I would like to see an API which is providing all the versions available (accessible) for a given artifact. Then, it's up to the artifact using it to decide which one it should "import".</div><div><br></div><div>Thanks,</div><div>Arnaud</div><div><br></div><div><br></div><div><br></div><hr id="zwchr"><div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Alexander Tivelkov" <ativelkov@mirantis.com><br><b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org><br><b>Sent: </b>Tuesday, February 25, 2014 3:57:41 AM<br><b>Subject: </b>[openstack-dev] [Glance][Artifacts] Artifact dependencies: Strict vs Soft<br><div><br></div>
<div dir="ltr"><div class="gmail_default" style="font-size:small"><div class="gmail_default">Hi folks,</div><div class="gmail_default"><br></div><div class="gmail_default">While I am still working on designing artifact-related APIs (sorry, the task is taking me longer then expected due to a heavy load in Murano, related to the preparation of incubation request), I've got a topic I wanted to discuss with the broader audience.</div>
<div class="gmail_default"><br></div><div class="gmail_default">It seems like we have agreed on the idea that the artifact storage should support dependencies between the artifacts: ability for any given artifact to reference some other artifacts as its dependencies, and the API call which will allow to retrieve all the dependency graph of the given artifact (i.e. its direct and transitive dependecies)</div>
<div class="gmail_default"><br></div><div class="gmail_default">Another idea which was always kept in mind when we were designing the artifact concept was artifact versioning: the system should allow to store different artifact having the identical name but different versions, and the API should be able to return the latest (based on some notation) version of the artifact. Being able to construct such a queries actually gives an ability to define kind of aliases, so the url like /v2/artifacts?type=image&name=ubuntu&version=latest will always return the latest version of the given artifact (ubuntu image in this case). The need to be able to define such "aliaces" was expressed in [1], and the ability to satisfy this need with artifact API was mentioned at [2]</div>
<div class="gmail_default"><br></div><div class="gmail_default">But combining these two ideas brings up an interesting question: how should artifacts define their dependencies? Should this be an explicit strict reference (i.e. referencing the specific artifact by its id), or it should be an implicit soft reference, similar to the "alias" described above (i.e. specifying the dependency as "A requires the latest version of B" or even "A requires 0.2<=B<0.3")?</div>
<div class="gmail_default">The later seems familiar: it is similar to pip dependency specification, right? This approach obviosuly may be very usefull (at least I clearly see its benefits for Murano's application packages), but it implies lazy evaluation, which may dramatically impact the performance.</div>
<div class="gmail_default">In contrary, the former approach - with explicit references - requires much less computation. Even more, if we decide that the artifact dependencies are immutable, this will allow us to denormalize the storage of the dependency graph and store all the transitive dependencies of the given artifact in a flat table, so the dependency graph may be returned by a sinle SQL query, without a need for recursive calls, which are otherwise unavoidable in the normalized database storing such hierarchical structures. </div>
<div class="gmail_default"><br></div><div class="gmail_default">Meanwhile, the mutability of dependencis is also unclear to me: ability to modify them seems to have its own pros and cons, so this is another topic to dicsuss.</div>
<div class="gmail_default"><br></div><div class="gmail_default">I'd like to hear your opinion on all of these. Any feedback is welcome, and we may come back to this topic on the Thursday's meeting.</div><div class="gmail_default">
<br></div><div class="gmail_default"><br></div><div class="gmail_default">Thanks!</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">[1] <a href="https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/glance/%2Bspec/glance-image-aliases&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0A&m=p6%2F5LWbuDtV6ZeR2XDpWSDIAO91xoGxjIvFTiGSUsx8%3D%0A&s=0d0ffafafb44cdfcb348325679cf826b74c31d3b8e4fd63d36940035dcfaad10" target="_blank">https://blueprints.launchpad.net/glance/+spec/glance-image-aliases</a></div>
<div class="gmail_default">[2] <a href="https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/glance/%2Bspec/artifact-repository-api&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0A&m=p6%2F5LWbuDtV6ZeR2XDpWSDIAO91xoGxjIvFTiGSUsx8%3D%0A&s=a0d6196fec100b4e94ee2e97d4874d38cc2c7b5098279f67cfef29f30232095e" target="_blank">https://blueprints.launchpad.net/glance/+spec/artifact-repository-api</a></div><div class="gmail_default"><br>
</div><div class="gmail_default"><br></div></div><div><div dir="ltr"><span>--<br></span><div dir="ltr"><span>Regards,<br>Alexander Tivelkov</span></div></div></div>
</div>
<br>_______________________________________________<br>OpenStack-dev mailing list<br>OpenStack-dev@lists.openstack.org<br>https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=5wWaXo2oVaivfKLCMyU6Z9UTO8HOfeGCzbGHAT4gZpo%3D%0A&m=p6%2F5LWbuDtV6ZeR2XDpWSDIAO91xoGxjIvFTiGSUsx8%3D%0A&s=28b9108941ca902bab4841c1cae5287ba4d253953b5b43f8d1b6ce13f8cc843d<br></div><div><br></div></div></body></html>