[openstack-dev] [Glance][Artifacts] Object Version format: SemVer vs pep440
Jay Pipes
jaypipes at gmail.com
Tue Feb 10 19:55:55 UTC 2015
On 02/10/2015 12:15 PM, Ian Cordasco wrote:
> So Semantic Versioning, as I’ve already mentioned in the past, isn’t
> really a de facto standard in any language community but it is a language
> agnostic proposal. That said, just because it’s language agnostic does not
> mean it won’t conflict with other language’s versioning semantics. Since
> we’re effectively reinventing an existing open source solution here, I
> think we should look to how Artifactory [1] handles this.
"Reinventing an existing open source solution" is a bit off-the-mark
IMO. Artifactory is more of a SaaS solution through bintray.com --
paying some lip-service to open source more than anything else.
> I haven’t used artifactory very much but a cursory look makes it apparent
> that it is strongly decoupling the logic of version management with
> artifact management (which this set of changes isn’t doing in Glance).
Alex's spec is merely proposing to standardize on a single way of
managing versioning. It isn't coupling artifact *management* with
anything whatsoever. In fact, the idea of Glance being an artifact
repository has nothing to do with the management of said artifacts --
which things like Heat, Murano or Solum handle in different ways.
The idea behind the Glance artifact repository was to store a
discoverable *schema* for various objects, along with the object
metadata itself. I can see Nova and Cinder flavors, Glance, Docker or
AppC image metadata, Cinder snapshot and differential metadata, Murano
application manifests, Heat templates, and Solum deployment components
all being described (schemas) and stored in the Glance artifact repository.
What I have not heard from anyone is the idea to marry the management of
the things that this artifact metadata with Glance itself.
> The primary argument (as I understand it) for using SemVer with Artifacts
> in glance is to have a way to automatically have the service create the
> version number for the uploader. Artifactory (and it’s “Pro” version) seen
> to leave that to the build tooling. In other words, it is purely storage.
> It seems to sort versions alphabetically (which everyone can agree is not
> only suboptimal but wrong) but it also provides the user a way to alter
> how it performs sorting.
I don't know where you get the idea that a service (Glance, you mean?)
would automatically create the version number for some artifact. The
spec talks only about the ability of the artifact registry to sort a set
of artifacts by incrementing version number, and do so in a reasonably
short time frame -- i.e. have a database column indexed for that purpose.
> Is there a reason (beyond not being an OpenStack project) that Artifactory
> isn’t being considered by those pushing for Artifacts to provide a CD
> service?
Because we're not looking to create a CD service? :) AFAIK, the artifact
repository is a generic storage system for schemas and metadata, nothing
more.
Best,
-jay
> Judging by the support it seems to roughly have for other
> services (via a “Pro” version) it would appear to be able to suit any this
> need well with little work by the deployer who needs to serve more than
> one use case.
>
> [1] http://www.jfrog.com/open-source/#os-arti
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
More information about the OpenStack-dev
mailing list