Bug 1317669

Summary: [RFE] Version release file
Product: Red Hat OpenStack Reporter: Chris Lincoln <clincoln>
Component: rhosp-releaseAssignee: Mike Burns <mburns>
Status: CLOSED ERRATA QA Contact: Gurenko Alex <agurenko>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0 (Kilo)CC: achernet, agurenko, amuller, apevec, dchia, dmacpher, dmaley, jliberma, jschluet, lhh, markmc, mburns, nbarcet, nlevinki, oblaut, sclewis, srevivo
Target Milestone: betaKeywords: FutureFeature, Triaged
Target Release: 10.0 (Newton)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: rhosp-release-10.0-1.el7ost Doc Type: Enhancement
Doc Text:
This update includes a release file to identify the overcloud version deployed with OSP director. This gives a clear indication of the installed version and aids debugging. The overcloud-full image includes a new package (rhosp-release). Upgrades from older versions also install this RPM. All versions starting with OSP 10 will now have a release file. This only applies to Red Hat OpenStack Platform director-based installations. However, users can manually the install the rhosp-release package and achieve the same result.
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-14 15:28:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Chris Lincoln 2016-03-14 20:05:19 UTC
Description of problem:

Customer requests version release file (akin to the /etc/redhat-release) for OpenStack and Director (for example, /etc/osp-release) that would indicate versioning information of OpenStack

Comment 1 Dave Maley 2016-03-15 17:19:30 UTC
*** Bug 1317670 has been marked as a duplicate of this bug. ***

Comment 3 Assaf Muller 2016-06-22 15:34:51 UTC
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.

Comment 5 Mike Burns 2016-08-16 14:41:17 UTC
(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

Comment 6 Mike Burns 2016-08-16 14:50:08 UTC
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.

Comment 7 Mike Burns 2016-08-16 15:15:39 UTC
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

Comment 9 Gurenko Alex 2016-09-27 06:22:15 UTC
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?

Comment 10 Mike Burns 2016-09-29 12:31:16 UTC
Yes, this is expected.  On the undercloud, you would need to manually yum install rhosp-release

Comment 13 Mike Burns 2016-10-13 19:57:59 UTC
Checked a just installed OSP 10 system and confirmed the rpm and /etc/rhosp-release file existed and did not include "Beta"

Comment 18 errata-xmlrpc 2016-12-14 15:28:31 UTC
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

Comment 19 Mike Burns 2017-01-04 16:48:03 UTC
*** Bug 1296946 has been marked as a duplicate of this bug. ***