Bug 1317669

*** Bug 1317670 has been marked as a duplicate of this bug. ***

The way I read comment 0, this RFE requests two things:

1) The version of OSP itself

I think that this can be deduced by the installed RPMs, so I see it as more of a convenience thing.

2) The version of OSP-d

I wanted to voice my +1 for this idea. Sometimes 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 SOS report from a customer and it's from a controller/compute, I would love to be able to peak at /etc/osp-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 OSP-d can install different versions of OSP, so in some cases knowing which OSP version is running is not enough to know how it was installed. Maybe there was a bug in an early OSP-d release that results in bad configuration, and the deployment was installed before that bug was fixed. Maybe this deployment wasn't installed with OSP-d 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 OSP-d versions over time and this RFE would be a great step towards that.

(In reply to Assaf Muller from comment #3)
> The way I read comment 0, this RFE requests two things:
> 
> 1) The version of OSP itself
> 
> I think that this can be deduced by the installed RPMs, so I see it as more
> of a convenience thing.
> 
> 2) The version of OSP-d
> 
> I wanted to voice my +1 for this idea. Sometimes 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 SOS
> report from a customer and it's from a controller/compute, I would love to
> be able to peak at /etc/osp-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 OSP-d can install different
> versions of OSP, so in some cases knowing which OSP version is running is
> not enough to know how it was installed. Maybe there was a bug in an early
> OSP-d release that results in bad configuration, and the deployment was
> installed before that bug was fixed. Maybe this deployment wasn't installed
> with OSP-d 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 OSP-d versions over time and this RFE would be a great step
> towards that.

This is something different that would fall outside the Release Delivery team.  It would need to be in a file that the director lays down.  When does it get updated?  When an update or upgrade is triggered from director?  It wouldn't be an RPM in this case, it is just a file that the installer creates and maintains as it updates the deployment

What is the goal here?  Just a rhosp-release rpm that says:

Red Hat OpenStack Platform release 10.0 (Newton)

If that's it, then this is relatively trivial to do.

If we want more involved versioning, then I'll need more guidance.

Since there is no longer a separate version for director from OSP, I'm taking this as just an OSP version file.  A separate rfe for director to lay down a "installed by" file can be filed if there is a strong requirement for that

I've tested latest build 2016-09-22.2 and I see /etc/rhosp-release file with following content:

[heat-admin@controller-0 etc]$ cat rhosp-release 
Red Hat OpenStack Platform release 10.0 Beta (Newton)

However there this file does not exist on undercloud, therefore two questions:

1) Is this an expected behavior?

2) Is this expected output? IMO, Red Hat OpenStack Platform release 10.0 Beta (Newton) is quite vague and can be probably a bit more specific as to what build was used?

Yes, this is expected.  On the undercloud, you would need to manually yum install rhosp-release

Checked a just installed OSP 10 system and confirmed the rpm and /etc/rhosp-release file existed and did not include "Beta"

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-2948.html

*** Bug 1296946 has been marked as a duplicate of this bug. ***