Open Stack

I have a few changes in review [0] that implement a plan outlined in the
bug [1] for seamless merge of the new versioning schema (liberty-8.0). With
those changes merged in order, we should be OK without changing ISO in Fuel
infra.

I also have version of ISO with green BVT that incorporates changes listed
above. It could replace the current ISO in Fuel infra any time we're ready
for it. Currently I'm trying to get green system tests on it as well.

We just need to decide on what path we want to take.

[0]
https://review.openstack.org/#/q/status:open+branch:master+topic:bug/1503663,n,z
[1] https://bugs.launchpad.net/fuel/+bug/1503663/comments/10

--
Best regards,
Oleg Gelbukh

On Tue, Dec 15, 2015 at 8:58 PM Dmitry Klenov <dklenov at mirantis.com> wrote:

> Hi folks,
>
> I would propose to keep current versioning schema until fuel release
> schedule is fully aligned with OpenStack releases. AFAIK it is expected to
> happen since 9.0. After it we can switch to OpenStack version names.
>
> BR,
> Dmitry.
>
> On Tue, Dec 15, 2015 at 8:41 PM, Igor Kalnitsky <ikalnitsky at mirantis.com>
> wrote:
>
>> 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
>> >
>>
>> __________________________________________________________________________
>> 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/20151215/4af904d6/attachment-0001.html>