<div dir="ltr">It looks like /etc/issue + an extraction from rpm db.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 25, 2015 at 1:20 AM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Vladimir,<div><br></div><div>I agree that the content of this file nearly completely depreciated, but slightly disagree with removing it entirely.</div><div><br></div><div>I think the data should be moved from a single static file like you see here, to something that reads the data from the underlying packages and can still show all of the information in one place (/api/version). So we can, and should do away with this file but we need the data in the api response, and saved in the diag snapshot. So my comments below are about possibly keeping these around, but not in the file</div><br><div class="gmail_quote"><span class=""><div dir="ltr">On Fri, Jul 24, 2015 at 10:25 AM Vladimir Kozhukalov <<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote></span><div>This should just be expressed as a value in the DB, it never made sense to store this in a file since it's runtime state </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote></span><div>there is no longer not docker, so just drop it. </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote></span><div>These are useful to track which iso the issue occurred in and if my iso or another might have the issue. I find it the attributes I use the most in this data. Again is un-related to packages so it should only be copied off the iso for development reasons </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>7) <b>X_sha</b> - This does not even require any explanation. It should be rpm -qa instead.</div></div></blockquote></span><div>We need this information. It can easily be replaced with the identifier from the package, but it still needs to describe source. We need to know exactly which commit was the head. It's solved many other hard to find problems that we added it for in the first place </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr"><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" target="_blank">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" target="_blank">https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml</a></div><div> </div><div>Vladimir Kozhukalov<br></div>
</div></span>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">--</p><p dir="ltr"><span style="font-size:13.1999998092651px">Andrew Woodward</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Mirantis</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Fuel Community Ambassador</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Ceph Community</span></p>
</div>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Andrey Danin<br><a href="mailto:adanin@mirantis.com" target="_blank">adanin@mirantis.com</a><br>skype: gcon.monolake<br></div>
</div>