https://blueprints.launchpad.net/fuel/+spec/reduce-tarball-size
Let’s reduce size of our fuel upgrade tarball, since it’s huge and uncomfortable for distribution.
We need to reduce upgrade tarball’s size in order to simplify distribution workflow, boost up downloading/unpacking speed and reduce used space on master node’s file system.
An OpenStack bundle is a set of artifacts which together constitute an openstack release in terms of Nailgun. The bundle contains next artifacts:
Since Fuel 5.1 an upgrade tarball may contain few OpenStack bundles and each OpenStack bundle includes a self-sufficient repo. The “self-sufficient” here means that the repo contains not only OpenStack packages, but system.
The system packages are rarely changed so in most cases we can distribute within OpenStack bundle a small repo which contains only those packages that were changed regarding to some base previous release.
The changes have to be detected by packages’ checksum, since we can’t rely on package versions due to the following issue - LP1376694.
To achieve this goal we need to resolve next points:
Information about base repo should be added through metadata.yaml. The YAML should be generated by make system and should be in the following format:
diff_releases:
2014.2-6.0: 2014.1.1-5.1
where 2014.2-6.0 is a release to be installed and 2014.1.1-5.1 is a base release for 2014.2-6.0. The metadata.yaml should be located in upgrade/releases/metadata.yaml folder inside upgrade tarball.
There should be only one major Fuel master node upgrade chain. For example:
5.1 -> 6.0
5.1.1 -> 6.0
In other words, there shouldn’t be a situation when we upgrade to 6.0 from 5.0.x series.
We can distribute just a set of changed packages instead of a small repo. In that case we will need to create a new repo on fly during fuel upgrade procedure. Creating repos on fly is not trivial procedure and may fail time to time due to outside factors.
A deployment info (a one that Nailgun sends to Astute and Astute saves it as astute.yaml) should have a repo_metadata field, which is a JSON object (or Python dictionary).
The repo_metadata has next structure:
"repo_metadata": {
"repo_name_1": "repo_path_1",
"repo_name_2": "repo_path_2",
}
and will be converted into following yum’s repo file:
[repo_name_1]
name=repo_name_1
baseurl=repo_path_1
gpgcheck=0
[repo_name_2]
name=repo_name_2
baseurl=repo_path_2
gpgcheck=0
and into next apt’s sources list:
deb repo_path_1
deb repo_path_2
The changes that was described above are already implemented in both Nailgun and Astute, and therefore should be kept as is.
Master node IP is not a constant value, so we need to support some sort of macro replacement in the release handler. In other words if we want to add a Nailgun’s release with the following orchestrator data:
{
"puppet_manifests_source":
"rsync://{MASTER_IP}:/puppet/{OPENSTACK_VERSION}/manifests/",
"puppet_modules_source":
"rsync://{MASTER_IP}:/puppet/{OPENSTACK_VERSION}/modules/",
"repo_metadata": { ... }
}
the {MASTER_IP} and the {OPENSTACK_VERSION} will be replaced by Nailgun with an actual master node ip address and an openstack version respectively.
The Fuel Upgrade script has to be able to add new “OpenStack releases” with one, two or more repos.
None
None
None
None
Primary assignee:
Other contributors:
None
Existing Fuel Upgrade / OpenStack patching tests are enough since it’s about improvements, not about entirely new feature.
But next tests may be added:
The documentation about release management should be added and it should resolve next questions: