It looks like /etc/issue + an extraction from rpm db. On Sat, Jul 25, 2015 at 1:20 AM, Andrew Woodward <xar...@gmail.com> wrote:
> Vladimir, > > I agree that the content of this file nearly completely depreciated, but > slightly disagree with removing it entirely. > > 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 > > On Fri, Jul 24, 2015 at 10:25 AM Vladimir Kozhukalov < > vkozhuka...@mirantis.com> wrote: > >> 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. >> > 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 > >> 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. >> > there is no longer not docker, so just drop it. > >> 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. >> > 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 > >> 7) *X_sha* - This does not even require any explanation. It should be >> rpm -qa instead. >> > 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 > >> >> 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 >> >> __________________________________________________________________________ >> 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 >> > -- > > -- > > Andrew Woodward > > Mirantis > > Fuel Community Ambassador > > Ceph Community > > __________________________________________________________________________ > 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 > > -- Andrey Danin ada...@mirantis.com skype: gcon.monolake
__________________________________________________________________________ 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