Open Stack

Hi folks,

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.

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)

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]

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")?
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.
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.

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.

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.


Thanks!


[1] https://blueprints.launchpad.net/glance/+spec/glance-image-aliases
[2] https://blueprints.launchpad.net/glance/+spec/artifact-repository-api


--
Regards,
Alexander Tivelkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140225/adad13f7/attachment.html>