[openstack-dev] [Fuel] version.yaml in the context of packages

Vladimir Kozhukalov vkozhukalov at mirantis.com
Fri Jul 24 17:21:41 UTC 2015


Dear colleagues,

Although we are focused on fixing bugs during next few weeks I still have
to ask everyone's opinion about /etc/fuel/version.yaml. We introduced this
file when all-inclusive ISO image was the only way of delivering Fuel. We
had to have somewhere the information about SHA commits for all Fuel
related git repos. But everything is changing and we are close to flexible
package based delivery approach. And this file is becoming kinda fifth
wheel.

Here is how version.yaml looks like

VERSION:
  feature_groups:
    - mirantis
  production: "docker"
  release: "7.0"
  openstack_version: "2015.1.0-7.0"
  api: "1.0"
  build_number: "82"
  build_id: "2015-07-23_10-59-34"
  nailgun_sha: "d1087923e45b0e6d946ce48cb05a71733e1ac113"
  python-fuelclient_sha: "471948c26a8c45c091c5593e54e6727405136eca"
  fuel-agent_sha: "bc25d3b728e823e6154bac0442f6b88747ac48e1"
  astute_sha: "b1f37a988e097175cbbd14338286017b46b584c3"
  fuel-library_sha: "58d94955479aee4b09c2b658d90f57083e668ce4"
  fuel-ostf_sha: "94a483c8aba639be3b96616c1396ef290dcc00cd"
  fuelmain_sha: "68871248453b432ecca0cca5a43ef0aad6079c39"


Let's go through this file.

1) *feature_groups* - This is, in fact, runtime parameter rather then build
one, so we'd better store it in astute.yaml or other runtime config file.
2) *production* - It is always equal to "docker" which means we deploy
docker containers on the master node. Formally it comes from one of
fuel-main variables, which is set into "docker" by default, but not a
single job in CI customizes this variable. Looks like it makes no sense to
have this.
3) *release *- It is the number of Fuel release. Frankly, don't need this
because it is nothing more than the version of fuel meta package [1].
4) *openstack_version *- It is just an extraction from openstack.yaml [2].
5) *api *- It is 1.0 currently. And we still don't have other versions of
API. Frankly, it contradicts to the common practice to make several
different versions available at the same time. And a user should be able to
ask API which versions are currently available.
6) *build_number *and *build_id *- These are the only parameters that
relate to the build process. But let's think if we actually need these
parameters if we switch to package based approach. RPM/DEB repositories are
going to become the main way of delivering Fuel, not ISO. So, it also makes
little sense to put store them, especially if we upgrade some of the
packages.
7) *X_sha* - This does not even require any explanation. It should be rpm
-qa instead.

I am raising this topic, because it is kind of blocker for switching to
package based upgrades. Our current upgrade script assumes we have this
file version.yaml in the tarball and we put this new file instead of old
one during upgrade. But this file could not be packaged into rpm because it
can only be built together with ISO.


[1] https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec
[2]
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml

Vladimir Kozhukalov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150724/b48ce229/attachment.html>


More information about the OpenStack-dev mailing list