Open Stack

Folks,

I want to bring this up again. There were no progress since last
Oleg's mail, and we must decide. It's good that we still have
"2015.1.0-8.0" version while OpenStack uses "Liberty" name for
versions.

Let's decide which name to use, file a bug and finally resolve it.

- Igor

On Thu, Oct 22, 2015 at 10:23 PM, Oleg Gelbukh <ogelbukh at mirantis.com> wrote:
> Igor, it is interesting that you mention backward compatibility in this
> context.
>
> I can see lots of code in Nailgun that checks for release version to
> enable/disable features that were added or removed more than 2 releases
> before [1] [2] [3] (there's a lot more).
>
> What should we do about that code? I believe we could 'safely' delete it. It
> will make our code base much more compact and supportable without even
> decoupling serializers, etc. Is my assumption correct, or I just missing
> something?
>
> This will also help to switch to another scheme of versioning of releases,
> since there will be much less places where those version scheme is
> hardcoded.
>
> [1]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/objects/release.py#L142-L145
> [2]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L554-L555
> [3]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/objects/serializers/node.py#L124-L126
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Mon, Oct 19, 2015 at 6:34 PM, Igor Kalnitsky <ikalnitsky at mirantis.com>
> wrote:
>>
>> Oleg,
>>
>> I think we can remove this function for new releases and keep them
>> only for backward compatibility with previous ones. Why not? If
>> there's a way to do things better let's do them better. :)
>>
>> On Sat, Oct 17, 2015 at 11:50 PM, Oleg Gelbukh <ogelbukh at mirantis.com>
>> wrote:
>> > In short, because of this:
>> >
>> > https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/db/sqlalchemy/models/release.py#L74-L99
>> >
>> > Unless we use dashed 2-component version where OpenStack version comes
>> > first, followed by version of Fuel, this will break creation of a
>> > cluster
>> > with given release.
>> >
>> > -Oleg
>> >
>> > On Sat, Oct 17, 2015 at 10:24 PM, Sergii Golovatiuk
>> > <sgolovatiuk at mirantis.com> wrote:
>> >>
>> >> Why can't we use 'liberty' without 8.0?
>> >>
>> >> On Sat, 17 Oct 2015 at 19:33, Oleg Gelbukh <ogelbukh at mirantis.com>
>> >> wrote:
>> >>>
>> >>> After closer look, the only viable option in closer term seems to be
>> >>> 'liberty-8.0' version. It does not to break comparisons that exist in
>> >>> the
>> >>> code and allows for smooth transition.
>> >>>
>> >>> --
>> >>> Best regards,
>> >>> Oleg Gelbukh
>> >>>
>> >>> On Fri, Oct 16, 2015 at 5:35 PM, Igor Kalnitsky
>> >>> <ikalnitsky at mirantis.com>
>> >>> wrote:
>> >>>>
>> >>>> Oleg,
>> >>>>
>> >>>> Awesome! That's what I was looking for. :)
>> >>>>
>> >>>> - Igor
>> >>>>
>> >>>> On Fri, Oct 16, 2015 at 5:09 PM, Oleg Gelbukh <ogelbukh at mirantis.com>
>> >>>> wrote:
>> >>>> > Igor,
>> >>>> >
>> >>>> > Got your question now. Coordinated point (maintenance) releases are
>> >>>> > dropped.
>> >>>> > [1] [2]
>> >>>> >
>> >>>> > [1]
>> >>>> >
>> >>>> > http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html
>> >>>> > [2]
>> >>>> >
>> >>>> >
>> >>>> > https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fliberty_releases
>> >>>> >
>> >>>> > --
>> >>>> > Best regards,
>> >>>> > Oleg Gelbukh
>> >>>> >
>> >>>> > On Fri, Oct 16, 2015 at 3:30 PM, Igor Kalnitsky
>> >>>> > <ikalnitsky at mirantis.com>
>> >>>> > wrote:
>> >>>> >>
>> >>>> >> Oleg,
>> >>>> >>
>> >>>> >> Yes, I know. Still you didn't answer my question - are they
>> >>>> >> planning
>> >>>> >> to release stable branches time-to-time? Like I said, Liberty is
>> >>>> >> something similar 2015.2.0. How they will name release of
>> >>>> >> something
>> >>>> >> like 2015.2.1 (stable release, with bugfixes) ? Or they plan to
>> >>>> >> drop
>> >>>> >> it?
>> >>>> >>
>> >>>> >> Thanks,
>> >>>> >> Igor
>> >>>> >>
>> >>>> >> On Fri, Oct 16, 2015 at 1:02 PM, Oleg Gelbukh
>> >>>> >> <ogelbukh at mirantis.com>
>> >>>> >> wrote:
>> >>>> >> > Igor,
>> >>>> >> >
>> >>>> >> > The point is that there's no 2015.2.0 version anywhere in
>> >>>> >> > OpenStack. So
>> >>>> >> > every component will be versioned separately, for example, in
>> >>>> >> > Libery,
>> >>>> >> > Nova
>> >>>> >> > has version 12.0.0, and minor release of it is going to have
>> >>>> >> > version
>> >>>> >> > 12.0.1,
>> >>>> >> > while Keystone, for instance, will have version 11.0.0 and
>> >>>> >> > 11.0.1
>> >>>> >> > for
>> >>>> >> > minor
>> >>>> >> > release.
>> >>>> >> >
>> >>>> >> > The problem in Fuel is that coordinated release version is used
>> >>>> >> > in
>> >>>> >> > several
>> >>>> >> > places, the most important being installation path of the
>> >>>> >> > fuel-library.
>> >>>> >> > We
>> >>>> >> > won't be able to use it the same way since Liberty. I'd like to
>> >>>> >> > understand
>> >>>> >> > how we are going to handle that.
>> >>>> >> >
>> >>>> >> > My suggestion actually is to move away from using OpenStack
>> >>>> >> > version
>> >>>> >> > as a
>> >>>> >> > part of Fuel version. Then the path to install the fuel-library
>> >>>> >> > will be
>> >>>> >> > '/etc/puppet/8.0.0/'.
>> >>>> >> >
>> >>>> >> > --
>> >>>> >> > Best regards,
>> >>>> >> > Oleg Gelbukh
>> >>>> >> >
>> >>>> >> > On Fri, Oct 16, 2015 at 12:45 PM, Igor Kalnitsky
>> >>>> >> > <ikalnitsky at mirantis.com>
>> >>>> >> > wrote:
>> >>>> >> >>
>> >>>> >> >> Hey Oleg,
>> >>>> >> >>
>> >>>> >> >> I've read the post [1] and I didn't get how exactly minor
>> >>>> >> >> releases
>> >>>> >> >> of
>> >>>> >> >> *stable* branch will be versioned?
>> >>>> >> >>
>> >>>> >> >> Let's say 2015.2.0 is Liberty. How 2015.2.1 will be versioned?
>> >>>> >> >>
>> >>>> >> >> [1] http://ttx.re/new-versioning.html
>> >>>> >> >>
>> >>>> >> >> Thanks,
>> >>>> >> >> Igor
>> >>>> >> >>
>> >>>> >> >>
>> >>>> >> >> On Thu, Oct 15, 2015 at 6:59 PM, Oleg Gelbukh
>> >>>> >> >> <ogelbukh at mirantis.com>
>> >>>> >> >> wrote:
>> >>>> >> >> > Hello,
>> >>>> >> >> >
>> >>>> >> >> > I would like to highlight a problem that we are now going to
>> >>>> >> >> > have in
>> >>>> >> >> > Fuel
>> >>>> >> >> > regarding versioning of OpenStack.
>> >>>> >> >> >
>> >>>> >> >> > As you know, with introduction of the Big Tent policy it was
>> >>>> >> >> > decided
>> >>>> >> >> > that
>> >>>> >> >> > since Liberty dev cycle versioning schema of the whole
>> >>>> >> >> > project
>> >>>> >> >> > changes.
>> >>>> >> >> > Year-based versions won't be assigned to individual projects,
>> >>>> >> >> > nor the
>> >>>> >> >> > coordinated release is going to have unified number [1].
>> >>>> >> >> > Individual
>> >>>> >> >> > projects
>> >>>> >> >> > will have semver version numbers, while numbering of the
>> >>>> >> >> > release
>> >>>> >> >> > itself
>> >>>> >> >> > seems to be dropped.
>> >>>> >> >> >
>> >>>> >> >> > However, in Fuel there is a lot of places where we use
>> >>>> >> >> > year-based
>> >>>> >> >> > version of
>> >>>> >> >> > OpenStack release. [2] How are we going to handle this? Shall
>> >>>> >> >> > we
>> >>>> >> >> > have
>> >>>> >> >> > openstack_version: 2015.2 all over the place? Or we should
>> >>>> >> >> > come
>> >>>> >> >> > up
>> >>>> >> >> > with
>> >>>> >> >> > something more sophisticated? Or just drop OpenStack version
>> >>>> >> >> > component
>> >>>> >> >> > from
>> >>>> >> >> > our versioning schema for good?
>> >>>> >> >> >
>> >>>> >> >> > Please, share your opinions here or in corresponding reviews.
>> >>>> >> >> >
>> >>>> >> >> > [1] http://ttx.re/new-versioning.html
>> >>>> >> >> > [2] https://review.openstack.org/#/c/234296/
>> >>>> >> >> >
>> >>>> >> >> > --
>> >>>> >> >> > Best regards,
>> >>>> >> >> > Oleg Gelbukh
>> >>>> >> >> >
>> >>>> >> >> >
>> >>>> >> >> >
>> >>>> >> >> >
>> >>>> >> >> >
>> >>>> >> >> > __________________________________________________________________________
>> >>>> >> >> > 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
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > __________________________________________________________________________
>> >>>> >> > 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
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > __________________________________________________________________________
>> >>>> > 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
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> __________________________________________________________________________
>> >>> 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
>> >>
>> >
>> >
>> >
>> > __________________________________________________________________________
>> > 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
>
>
>
> __________________________________________________________________________
> 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
>