Open Stack

It looks like /etc/issue + an extraction from rpm db.

On Sat, Jul 25, 2015 at 1:20 AM, Andrew Woodward <xarses at 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 <
> vkozhukalov at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Andrey Danin
adanin at mirantis.com
skype: gcon.monolake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150725/089873e6/attachment.html>