Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151022/f98fffd9/attachment.html>