<div dir="ltr"><div>Dear colleagues,</div><div><br></div><div>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.</div><div><br></div><div>Here is how version.yaml looks like</div><div><br></div><div><div>VERSION:</div><div>  feature_groups:</div><div>    - mirantis</div><div>  production: "docker"</div><div>  release: "7.0"</div><div>  openstack_version: "2015.1.0-7.0"</div><div>  api: "1.0"</div><div>  build_number: "82"</div><div>  build_id: "2015-07-23_10-59-34"</div><div>  nailgun_sha: "d1087923e45b0e6d946ce48cb05a71733e1ac113"</div><div>  python-fuelclient_sha: "471948c26a8c45c091c5593e54e6727405136eca"</div><div>  fuel-agent_sha: "bc25d3b728e823e6154bac0442f6b88747ac48e1"</div><div>  astute_sha: "b1f37a988e097175cbbd14338286017b46b584c3"</div><div>  fuel-library_sha: "58d94955479aee4b09c2b658d90f57083e668ce4"</div><div>  fuel-ostf_sha: "94a483c8aba639be3b96616c1396ef290dcc00cd"</div><div>  fuelmain_sha: "68871248453b432ecca0cca5a43ef0aad6079c39"</div></div><div><br></div><div><br></div><div>Let's go through this file.</div><div><br></div><div>1) <b>feature_groups</b> - This is, in fact, runtime parameter rather then build one, so we'd better store it in astute.yaml or other runtime config file.</div><div>2) <b>production</b> - 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.</div><div>3) <b>release </b>- 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].</div><div>4) <b>openstack_version </b>- It is just an extraction from openstack.yaml [2].</div><div>5) <b>api </b>- 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.</div><div>6) <b>build_number </b>and <b>build_id </b>- 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.</div><div>7) <b>X_sha</b> - This does not even require any explanation. It should be rpm -qa instead.</div><div><br></div><div>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. </div><div><br></div><div><br></div><div>[1] <a href="https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec">https://github.com/stackforge/fuel-main/blob/master/specs/fuel-main.spec</a></div><div>[2] <a href="https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml">https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml</a></div><div> </div><div>Vladimir Kozhukalov<br></div>
</div>