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