Hi, On Fri, Nov 6, 2015 at 11:29 AM, 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) > We should think about separating packages for master node and openstack. I guess we should use 2 repository: 1. MOS - repository for OpenStack related nodes 2. MasterNode - repository for packages that are used for master node only. #2 is very important as it will allow to speed up the package delivery to end user. User will see the exact packages for master node and controllers/compute. Also, master node development can be boosted also as we might reconfigure jobs to install and test package on master node without spinning up OpenStack environment. That will save hours for our CI. Concerning 'upstream' it should be done in the same way we do for Ubuntu. Master node shouldn't redistribute CentOS packages. The customer should decide which mirror to use. The customer might want to use official CentOS 7 mirror or own copy on own facilities. * 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 > +1 for 2. We cannot guarantee that #1 will work smoothly. Also, there is some technical dept we cannot solve with #1 (i.e. - Docker device mapper). Also, the customer might have environments running on CentOS 6 so supporting all scenarios is quite hard. IF we do this we can redesign docker related part so we'll have huge profit later on. A a company we will help the clients who might want to upgrade from 5.1-7.0 to 8.0, but that will include analysing environment/plugins and making personal scenario for upgrade. It might be 'fuel-octane' to migrate workload to a new cloud or some script/documentation to perform upgrade. > > 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. > +1. > 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. > +2. That will allow us to: 1. Reduce ISO size 2. Increase ISO compilation by including -j8 3. Speed up CI > > 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
