Open Stack

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
>