[openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download

Sergii Golovatiuk sgolovatiuk at mirantis.com
Mon Jun 1 14:14:29 UTC 2015


Hi,

Are we going to add this feature to 7.0? There are some customers who tried
Fuel from nightly or technical previews builds. However, they don't want to
install fuel master node once again. There are several reasons for that. As
a sample it's dev environment, though production environment should be done
with GA code and packages. Though, the customers want to upgrade Fuel
master node to GA. That will allow them to create new environments with GA
code and package base. Also, they will be able to reset environment to
install GA code. How are we going to support such clients?

Thanks,

On Wed, Sep 3, 2014 at 5:37 PM Dmitry Pyzhov <dpyzhov at mirantis.com> wrote:

> Dmitry,
>
> I totally agree that we should support nightly builds in upgrades. I've
> created a blueprint for this:
> https://blueprints.launchpad.net/fuel/+spec/upgrade-nightly
>
>
> On Tue, Sep 2, 2014 at 3:24 AM, Dmitry Borodaenko <
> dborodaenko at mirantis.com> wrote:
>
>> We should not confuse beta and rc builds, normally betas predate RCs and
>> serve a different purpose. In that sense, the nightlies we currently
>> publish are closest to what beta builds should be.
>>
>> As discussed earlier in the thread, we already have full versioning and
>> provenance information in each build, so there is not a lot of value in
>> inventing a parallel versioning scheme just for the time period when our
>> builds are feature complete but not yet stable enough to declare an RC. The
>> only benefit is to explicitly indicate the beta status of these builds, and
>> we can achieve that without messing with versions. For example, by
>> generating a summary table of all community builds that have passed the
>> tests (using same build numbers we already have).
>>
>> Not supporting upgrades from/to intermediate builds is a limitation that
>> we should not discard as inevitable, overcoming it should be in our
>> backlog. Image based provisioning should make it much easier to support.
>>
>> My 2c,
>> -Dmitry
>> I would not use "beta" word anywhere at all. These are nightly builds,
>> pre-5.1. So it will become 5.1 eventually, but for the moment - it is just
>> master branch. We've not even reached HCF.
>>
>> After we reach HCF, we will start calling builds as Release Candidates
>> (RC1, RC2, etc.)  - and QA team runs acceptance testing against them. This
>> can be considered as another name instead of "beta-1", etc.
>>
>> Anyone can go to <fuel-master-IP>:8000/api/version to get sha commits of
>> git repos a particular build was created of. Yes, these are development
>> builds, and there will be no upgrade path provided from development build
>> to 5.1 release or any other release. We might want to think about it
>> though, if we could do it in theory, but I confirm what Evgeny says - we do
>> not support it now.
>>
>>
>>
>> On Wed, Aug 27, 2014 at 1:11 PM, Evgeniy L <eli at mirantis.com> wrote:
>>
>>> Hi guys, I have to say something about beta releases.
>>>
>>> As far as I know our beta release has the same version
>>> 5.1 as our final release.
>>>
>>> I think this versions should be different, because in case
>>> of some problem it will be much easier to identify what
>>> version we are trying to debug.
>>>
>>> Also from the irc channel I've heard that somebody wanted
>>> to upgrade his system to stable version, right now it's impossible
>>> because upgrade system uses this version for names of
>>> containers/images/temporary directories and we have
>>> validation which prevents the user to run upgrade to the
>>> same version.
>>>
>>> In upgrade script we use python module [1] to compare versions
>>> for validation.
>>> Let me give an example how development versions can look like
>>>
>>>     5.1a1 # alpha
>>>     5.1b1 # beta 1
>>>     5.1b1 # beta 2
>>>     5.1b1 # beta 3
>>>     5.1    # final release
>>>
>>> [1]
>>> http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html
>>>
>>> Thanks,
>>>
>>>
>>> On Tue, Aug 26, 2014 at 11:15 AM, Mike Scherbakov <
>>> mscherbakov at mirantis.com> wrote:
>>>
>>>> Igor,
>>>> thanks a lot for improving UX over it - this table allows me to see
>>>> which ISO passed verification tests.
>>>>
>>>>
>>>> On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin <vkuklin at mirantis.com>
>>>> wrote:
>>>>
>>>>> I would also like to add that you can use our library called devops
>>>>> along with system tests we use for QA and CI. These tests use libvirt and
>>>>> kvm so that you can easily fire up an environment with specific
>>>>> configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the
>>>>> documentation how to use this library is here:
>>>>> http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs
>>>>> or gaps in documentation, please feel free to file bugs to
>>>>> https://launchpad.net/fuel.
>>>>>
>>>>>
>>>>> On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin <ishishkin at mirantis.com
>>>>> > wrote:
>>>>>
>>>>>> Hi all,
>>>>>> along with building your own ISO following instructions [1], you can
>>>>>> always download nightly build [2] and run it, by using virtualbox scripts
>>>>>> [3], for example.
>>>>>>
>>>>>> For your conveniency, you can see a build status table on CI [4].
>>>>>> First tab now refers to pre-5.1 builds, and second - to master builds.
>>>>>> BVT columns stands for Build Verification Test, which is essentially
>>>>>> full HA deploy deployment test.
>>>>>>
>>>>>> Currently pre-5.1 and master builds are actually built from same
>>>>>> master branch. As soon as we call for Hard Code Freeze, pre-5.1 builds will
>>>>>> be reconfigured to use stable/5.1 branch.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> [1]
>>>>>> http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso
>>>>>> [2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds
>>>>>> [3] https://github.com/stackforge/fuel-main/tree/master/virtualbox
>>>>>> [4] https://fuel-jenkins.mirantis.com/view/ISO/
>>>>>> --
>>>>>> Igor Shishkin
>>>>>> DevOps
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Yours Faithfully,
>>>>> Vladimir Kuklin,
>>>>> Fuel Library Tech Lead,
>>>>> Mirantis, Inc.
>>>>> +7 (495) 640-49-04
>>>>> +7 (926) 702-39-68
>>>>> Skype kuklinvv
>>>>> 45bk3, Vorontsovskaya Str.
>>>>> Moscow, Russia,
>>>>> www.mirantis.com <http://www.mirantis.ru/>
>>>>> www.mirantis.ru
>>>>> vkuklin at mirantis.com
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Mike Scherbakov
>>>> #mihgen
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20150601/4ff3b773/attachment.html>


More information about the OpenStack-dev mailing list