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 <ikalnit...@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 <ogelb...@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 > > <sgolovat...@mirantis.com> wrote: > >> > >> Why can't we use 'liberty' without 8.0? > >> > >> On Sat, 17 Oct 2015 at 19:33, Oleg Gelbukh <ogelb...@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 < > ikalnit...@mirantis.com> > >>> wrote: > >>>> > >>>> Oleg, > >>>> > >>>> Awesome! That's what I was looking for. :) > >>>> > >>>> - Igor > >>>> > >>>> On Fri, Oct 16, 2015 at 5:09 PM, Oleg Gelbukh <ogelb...@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 > >>>> > <ikalnit...@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 < > ogelb...@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 > >>>> >> > <ikalnit...@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 > >>>> >> >> <ogelb...@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-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 > >>>> >> > > >>>> >> > >>>> >> > >>>> >> > __________________________________________________________________________ > >>>> >> 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 > >>> > >>> > >>> > >>> > __________________________________________________________________________ > >>> 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 > > > > __________________________________________________________________________ > 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