Just my 2 cents here - let's do docker backup and roll it up onto brand new Fuel 8 node.
On Fri, Nov 6, 2015 at 7:54 PM, Oleg Gelbukh <ogelb...@mirantis.com> wrote: > Matt, > > You are talking about this part of Operations guide [1], or you mean > something else? > > If yes, then we still need to extract data from backup containers. I'd > prefer backup of DB in simple plain text file, since our DBs are not that > big. > > [1] > https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#howto-backup-and-restore-fuel-master > > -- > Best regards, > Oleg Gelbukh > > On Fri, Nov 6, 2015 at 6:03 PM, Matthew Mosesohn <mmoses...@mirantis.com> > wrote: > >> Oleg, >> >> All the volatile information, including a DB dump, are contained in the >> small Fuel Master backup. There should be no information lost unless there >> was manual customization done inside the containers (such as puppet >> manifest changes). There shouldn't be a need to back up the entire >> containers. >> >> The information we would lose would include the IP configuration >> interfaces besides the one used for the Fuel PXE network and any custom >> configuration done on the Fuel Master. >> >> I want #1 to work smoothly, but #2 should also be a safe route. >> >> On Fri, Nov 6, 2015 at 5:39 PM, Oleg Gelbukh <ogelb...@mirantis.com> >> wrote: >> >>> Evgeniy, >>> >>> On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L <e...@mirantis.com> wrote: >>> >>>> Also we should decide when to run containers >>>> upgrade + host upgrade? Before or after new CentOS is installed? >>>> Probably >>>> it should be done before we run backup, in order to get the latest >>>> scripts for >>>> backup/restore actions. >>>> >>> >>> We're working to determine if we need to backup/upgrade containers at >>> all. My expectation is that we should be OK with just backup of DB, IP >>> addresses settings from astute.yaml for the master node, and credentials >>> from configuration files for the services. >>> >>> -- >>> Best regards, >>> Oleg Gelbukh >>> >>> >>>> >>>> Thanks, >>>> >>>> On Fri, Nov 6, 2015 at 1:29 PM, Vladimir Kozhukalov < >>>> vkozhuka...@mirantis.com> wrote: >>>> >>>>> Dear colleagues, >>>>> >>>>> At the moment I'm working on deprecating Fuel upgrade tarball. >>>>> Currently, it includes the following: >>>>> >>>>> * RPM repository (upstream + mos) >>>>> * DEB repository (mos) >>>>> * openstack.yaml >>>>> * version.yaml >>>>> * upgrade script itself (+ virtualenv) >>>>> >>>>> Apart from upgrading docker containers this upgrade script makes >>>>> copies of the RPM/DEB repositories and puts them on the master node naming >>>>> these repository directories depending on what is written in >>>>> openstack.yaml >>>>> and version.yaml. My plan was something like: >>>>> >>>>> 1) deprecate version.yaml (move all fields from there to various >>>>> places) >>>>> 2) deliver openstack.yaml with fuel-openstack-metadata package >>>>> 3) do not put new repos on the master node (instead we should use >>>>> online repos or use fuel-createmirror to make local mirrors) >>>>> 4) deliver fuel-upgrade package (throw away upgrade virtualenv) >>>>> >>>>> Then UX was supposed to be roughly like: >>>>> >>>>> 1) configure /etc/yum.repos.d/nailgun.repo (add new RPM MOS repo) >>>>> 2) yum install fuel-upgrade >>>>> 3) /usr/bin/fuel-upgrade (script was going to become lighter, because >>>>> there should have not be parts coping RPM/DEB repos) >>>>> >>>>> However, it turned out that Fuel 8.0 is going to be run on Centos 7 >>>>> and it is not enough to just do things which we usually did during >>>>> upgrades. Now there are two ways to upgrade: >>>>> 1) to use the official Centos upgrade script for upgrading from 6 to 7 >>>>> 2) to backup the master node, then reinstall it from scratch and then >>>>> apply backup >>>>> >>>>> Upgrade team is trying to understand which way is more appropriate. >>>>> Regarding to my tarball related activities, I'd say that this package >>>>> based >>>>> upgrade approach can be aligned with (1) (fuel-upgrade would use official >>>>> Centos upgrade script as a first step for upgrade), but it definitely can >>>>> not be aligned with (2), because it assumes reinstalling the master node >>>>> from scratch. >>>>> >>>>> Right now, I'm finishing the work around deprecating version.yaml and >>>>> my further steps would be to modify fuel-upgrade script so it does not >>>>> copy >>>>> RPM/DEB repos, but those steps make little sense taking into account >>>>> Centos >>>>> 7 feature. >>>>> >>>>> Colleagues, let's make a decision about how we are going to upgrade >>>>> the master node ASAP. Probably my tarball related work should be reduced >>>>> to >>>>> just throwing tarball away. >>>>> >>>>> >>>>> Vladimir Kozhukalov >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> 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 >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> 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 >>> >>> >> >> __________________________________________________________________________ >> 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 >> >> > > __________________________________________________________________________ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@mirantis.com
__________________________________________________________________________ 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
