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 <sgolovat...@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 <dpyz...@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 < >> dborodae...@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 <e...@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 < >>>> mscherba...@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 <vkuk...@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 < >>>>>> ishish...@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@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 >>>>>> vkuk...@mirantis.com >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-dev mailing list >>>>>> OpenStack-dev@lists.openstack.org >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Mike Scherbakov >>>>> #mihgen >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> OpenStack-dev@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> OpenStack-dev@lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> -- >>> Mike Scherbakov >>> #mihgen >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> 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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community
__________________________________________________________________________ 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