Open Stack

I agree with Alexander on this. We should certainly learn what we can from existing software. That said, the Solum team really wants this feature in Glance so we can leverage that instead of having our own repository for Heat templates we generate when building apps. We want to keep our requirements list small, and Glance is already there.

Adrian

On Feb 10, 2015, at 10:01 AM, Alexander Tivelkov <ativelkov at mirantis.com> wrote:

> Hi Ian,
> 
> Automatic version generation is not the only and not the primary
> reason for the version concept. In fact, the implementation which is
> planned to land in this cycle does not contain this feature at all:
> currently we also leave the version assignment up to uploader (version
> is a regular immutable generic artifact property). Auto-increments as
> part of clone-and-modify scenarios are postponed for the next cycle.
> 
> However, even now we do need to have some sorting order - so, we need
> rules to determine precedence. That's the reason for having some
> notation defined: if we leave the notation up to the end-user we won't
> be able to compare artifacts having versions in different notations.
> And we even can't leave it up to the Artifact Type developer, since
> this is a generic property, thus common for all the artifact types.
> And of course, the chosen solution should be mappable to database, so
> we may do sorting and filtering on the DB-side.
> So, having it as a simple string and letting the user to decide what
> it means is not an option.
> 
> Speaking about Artifactory - that's entirely different thing. It is
> indeed a continuous delivery solution, composed around build machines,
> deployment solutions and CI systems. That's definitely not what Glance
> Artifact Repository is. Even the concepts of "Artifact" are entirely
> different.  So, while Artifact Repository may be used to build some CD
> solutions on top of it (or to be integrated with the existing ones) it
> is not a storage solution for build outputs and thus I can barely see
> how we may compare them.
> 
> --
> Regards,
> Alexander Tivelkov
> 
> 
> On Tue, Feb 10, 2015 at 8:15 PM, Ian Cordasco
> <ian.cordasco at rackspace.com> wrote:
>> 
>> 
>> On 2/10/15, 10:35, "Alexander Tivelkov" <ativelkov at mirantis.com> wrote:
>> 
>>> Thanks Monty!
>>> 
>>> Yup, probably I've missed that. I was looking at pbr and its version
>>> implementation, but didn't realize that this is actually a fusion of
>>> semver and pep440.
>>> 
>>> So, we have this as an extra alternative to choose from.
>>> 
>>> It would be an obvious choice if we were just looking for some common
>>> solution to version objects within openstack. However, I am a bit
>>> concerned about applying it to Artifact Repository. As I wrote before,
>>> we are trying to make the Repository to be language- and
>>> platform-agnostic tool for other developers, including the ones
>>> originating from non-python and non-openstack worlds. Having a
>>> versioning notation which is non-standard for everybody but openstack
>>> developers does not look like a good idea to me.
>>> --
>>> Regards,
>>> Alexander Tivelkov
>>> 
>>> 
>>> On Tue, Feb 10, 2015 at 6:55 PM, Monty Taylor <mordred at inaugust.com>
>>> wrote:
>>>> On 02/10/2015 10:28 AM, Alexander Tivelkov wrote:
>>>>> Hi folks,
>>>>> 
>>>>> One of the key features that we are adding to Glance with the
>>>>> introduction of Artifacts is the ability to have multiple versions of
>>>>> the same object in the repository: this gives us the possibility to
>>>>> query for the latest version of something, keep track on the changes
>>>>> history, and build various continuous delivery solutions on top of
>>>>> Artifact Repository.
>>>>> 
>>>>> We need to determine the format and rules we will use to define,
>>>>> increment and compare versions of artifacts in the repository. There
>>>>> are two alternatives we have to choose from, and we are seeking advice
>>>>> on this choice.
>>>>> 
>>>>> First, there is Semantic Versioning specification, available at [1].
>>>>> It is a very generic spec, widely used and adopted in many areas of
>>>>> software development. It is quite straightforward: 3 mandatory numeric
>>>>> components for version number, plus optional string labels for
>>>>> pre-release versions and build metadata.
>>>>> 
>>>>> And then there is PEP-440 spec, which is a "recommended approach to
>>>>> identifying versions and specifying dependencies when distributing
>>>>> Python". It is a "pythonic" way to set versions of python packages,
>>>>> including PIP version strings.
>>>>> 
>>>>> Conceptually PEP-440 and Semantic Versioning are similar in purpose,
>>>>> but slightly different in syntax. Notably, the count of version number
>>>>> components and rules of version precedence resolution differ between
>>>>> PEP-440 and SemVer. Unfortunately, the two version string formats are
>>>>> not compatible, so we have to choose one or the other.
>>>>> 
>>>>> According to my initial vision, the Artifact Repository should be as
>>>>> generic as possible in terms of potential adoption. The artifacts were
>>>>> never supposed to be python packages only, and even the projects which
>>>>> will create and use these artifacts are not mandatory limited to be
>>>>> pythonic, the developers of that projects may not be python
>>>>> developers! So, I'd really wanted to avoid any python-specific
>>>>> notations, such as PEP-440 for artifacts.
>>>>> 
>>>>> I've put this vision into a spec [3] which also contains a proposal on
>>>>> how to convert the semver-compatible version strings into the
>>>>> comparable values which may be mapped to database types, so a database
>>>>> table may be queried, ordered and filtered by the object version.
>>>>> 
>>>>> So, we need some feedback on this topic. Would you prefer artifacts to
>>>>> be versioned with SemVer or with PEP-440 notation? Are you interested
>>>>> in having some generic utility which will map versions (in either
>>>>> format) to database columns? If so, which version format would you
>>>>> prefer?
>>>>> 
>>>>> We are on a tight schedule here, as we want to begin landing
>>>>> artifact-related code soon. So, I would appreciate your feedback
>>>>> during this week: here in the ML or in the comments to [3] review.
>>>> 
>>>> Because you should have more things to look at:
>>>> 
>>>> http://docs.openstack.org/developer/pbr/semver.html
>>>> 
>>>> We've already done some work to try to reconcile the world of semver
>>>> with the world of PEP440 over in PBR land.
>>>> 
>>>> 
>>>> _________________________________________________________________________
>>>> _
>>>> 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
>>> 
>>> __________________________________________________________________________
>>> 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
>> 
>> 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.
>> 
>> 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).
>> 
>> 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.
>> 
>> 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? 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
> 
> __________________________________________________________________________
> 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