Looks like most people thing that building backup/re-install approach is more viable. So, we certainly need to invent completely new upgrade from and thus my suggestion is disable building/testing upgrade tarball right now, because anyway it makes no sense.
Vladimir Kozhukalov On Fri, Nov 6, 2015 at 8:21 PM, Vladimir Kuklin <vkuk...@mirantis.com> wrote: > 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 > >
__________________________________________________________________________ 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