On 2/10/15, 13:55, "Jay Pipes" <jaypi...@gmail.com> wrote: >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.
Except the base service is entirely free and open and thus can be deployed anywhere. And people looking to rebuild CD services in OpenStack should probably refer to existing implementations (of which I only pointed out the one I had already heard about). > >> 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. Except that Alex is proposing that this would include a number of things, some of which can and will be versioned in a way that will not work with the proposed solution. >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. Right. That’s the other concern I have with Artifacts. Images /can/ be /eventually/ represented as artifacts, but for now we’re grafting what will functionally be an entirely separate project (for at least the next cycle, if not longer) onto Glance while that new project is unstable and at best experimental. >> 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. Several discussions in IRC have happened around Artifacts and the SemVer spec in which this is a feature that Alex wants to add as a consequence of this. > >> 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. Except the common explanation for why we /need/ Artifacts is the example of people wanting to set up a CD system and the discussions that have been held elsewhere point to this being so much more than just that in terms of responsibility of managing versions and other (specifically, build) artifacts. > >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 __________________________________________________________________________ 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
