Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150724/b9b87b0d/attachment.html>