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

Andrew Woodward awoodward at mirantis.com
Wed Jun 3 20:17:43 UTC 2015


There have been a number of comments regarding this in IRC in the last
week. I think we should at least straighten out how to do this even if it's
by hand.

On Mon, Jun 1, 2015 at 7:15 AM Sergii Golovatiuk <sgolovatiuk at mirantis.com>
wrote:

> 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
>>
> __________________________________________________________________________
> 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
>
-- 
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150603/059afab6/attachment.html>


More information about the OpenStack-dev mailing list