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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to