[RFE] Add a way to figure out the TripleO version from an overcloud node

Bug #1595228 reported by Assaf Muller on 2016-06-22
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
tripleo
Wishlist
Unassigned

Bug Description

It is useful to know which installer, and what version of the installer, installed an overcloud node when we do not have access to the undercloud. For example, when we get a report from a user and it's from a controller/compute, I would love to be able to peak at /etc/tripleo-release (Or any other equivalent process) to grab this information. That way I wouldn't have to ask and we could save some ping pong. Furthermore, consider that TripleO can install different versions of OpenStack, so in some cases knowing which OpenStack version is running is not enough to know how it was installed.

Maybe there was a bug in an early TripleO release that results in bad configuration, and the deployment was installed before that bug was fixed. Maybe this deployment wasn't installed with TripleO at all. That is useful information when debugging an issue.

The last use case would be for statistics gathering - We'd love to know the adoption rate of TripleO versions over time and this RFE would be a great step towards that.

Emilien Macchi (emilienm) wrote :

It could be a simple Puppet fact in puppet-tripleo, that we could consume from anywhere (shell, ansible and THT itself, with Hiera).

Or it could be something in packaging, but I don't know where.

Emilien Macchi (emilienm) wrote :

the thing is tripleo version is already provided if you run 'rpm -qa | grep tripleo' so I wonder where we would consume this information.

John Trowbridge (trown) wrote :

Being able to tell what version of TripleO deployed an overcloud given only information on one of the overcloud nodes is likely impossible at the moment. Though it could definitely be useful to know if TripleO was used at all, and if so, what version of the heat templates was used for deploy.

Checking package versions won't help, because packages are installed at image build time and not deploy time. It is pretty unlikely that someone successfully deployed mismatched tripleo-heat-templates and overcloud puppet modules, but this feature would be most useful in the unsuccessful case.

I think puppet-tripleo would have a similar issue, in that it is installed in the overcloud image at image build time rather than deploy time.

That leaves tripleo-heat-templates. Adding something there that writes /etc/tripleo-release to the overcloud nodes seems like it would not be too hard to implement, and would solve this use case. It could even go a step further and write the templates/environments that were used to deploy the cloud somewhere on the overcloud, but maybe that is overkill.

I would also like to solve the corollary use case of determining what version of OpenStack is actually installed (vs. what version of OpenStack ran on the installer), but that would be better solved by packaging.

Changed in tripleo:
importance: Undecided → Wishlist
status: New → Triaged
Assaf Muller (amuller) wrote :

> It could even go a step further and write the templates/environments that were used to deploy the cloud somewhere on the overcloud, but maybe that is overkill.

That would be an *awesome* next step. Huge +1.

John Trowbridge (trown) on 2016-06-22
tags: added: fruit hanging low
tags: added: low-hanging-fruit
removed: fruit hanging low
Emilien Macchi (emilienm) wrote :

This bug was last updated over 180 days ago, as tripleo is a fast moving project and we'd like to get the tracker down to currently actionable bugs, this is getting marked as Invalid. If the issue still exists, please feel free to reopen it.

Changed in tripleo:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers