Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1417754

Summary:	Ceph nodes in an OSPd-based deployment require OSP SKU on Satellite 6
Product:	Red Hat OpenStack	Reporter:	August Simonelli <asimonel>
Component:	rhosp-director-images	Assignee:	Paul Grist <pgrist>
Status:	CLOSED ERRATA	QA Contact:	Yogev Rabl <yrabl>
Severity:	high	Docs Contact:	Derek <dcadzow>
Priority:	high
Version:	10.0 (Newton)	CC:	amdas, asimonel, assingh, cdevine, cylopez, dbecker, dcain, ebarrera, emacchi, eriley, flucifre, hfukumot, jbiao, jefbrown, jjoyce, jliberma, jschluet, mariel, mburns, mcornea, mfuruta, morazi, nbarcet, nlevine, pgrist, rcernin, rhel-osp-director-maint, scohen, shan, sputhenp
Target Milestone:	z4	Keywords:	Triaged, ZStream
Target Release:	13.0 (Queens)	Flags:	scohen: needinfo+
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	rhosp-director-images-13.0-20190103.1.el7ost	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-01-16 17:01:22 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:
Embargoed:
Bug Depends On:	1476282, 1677777
Bug Blocks:

Description August Simonelli 2017-01-30 21:42:09 UTC

Description of problem:
When deploying OSP with OSPd (3 controllers, 2 computes, 3 ceph) and subscribing to Satellite 6 the Ceph nodes consumed OSP SKUs even though they had both "Red Hat Ceph Storage (RS00036) and "Smart Management" subs assigned to them via activation key.

Version-Release number of selected component (if applicable):

How reproducible:
Create an activation key for Ceph nodes that has "Red Hat Ceph Storage (RS00036)" and "Smart Management" subs for allocation. Deploy OSP with OSPd and subscribe Ceph nodes to Satellite 6 Ceph key.

Steps to Reproduce:
1. create activation key in satellite with auto-attach off that allocated Ceph Storage subs
2. deploy OSP with OSPd
3. subscribe ceph node to activation key for ceph subs.

Actual results:
The ceph nodes get awarded the subs for Ceph and Smart Management. But Satellite also allocated them an OSP SKU from outside the allocated key. This is the correct behavior from satellite as there are certs on the overcloud nodes for ceph AND OSP:

# ls -l /etc/pki/product
total 16
-rw-r--r--. 1 root root 2151 Dec 2 20:32 286.pem
-rw-r--r--. 1 root root 2151 Dec 2 20:32 288.pem
-rw-r--r--. 1 root root 2195 Dec 2 20:50 326.pem
-rw-r--r--. 1 root root 2244 Dec 2 20:50 83.pem

Expected results:
I'd expect to NOT need an OSP sub for a Ceph node and for a standard ceph node to only need Ceph.

Additional info:
Conversation has shown that perhaps the OSP SKU is supposed to provide the mon and osd components for the ceph nodes (and controllers) as this is OSPd.

Comment 1 August Simonelli 2017-01-30 21:44:13 UTC

As the OSPd-deployed overcloud nodes are all the same software I do think they need some kind of OSP subs on them for security purposes. Without them if there is an exploit in an OSP component it won't get patched. Even though it's not used, it is a risk so I think the storage nodes also need OSP repos somehow.

But in general it needs to be clarified if the Ceph nodes need both OSP and Ceph?

Comment 2 Andrew Hatfield 2017-01-30 22:19:59 UTC

I dont understand why the Ceph OSD nodes would need any OSP software or channels.

It purely runs Ceph, no OSP.  Having OSP software on there increases the surface attack space and risk.

Comment 3 August Simonelli 2017-01-30 22:39:03 UTC

(In reply to Andrew Hatfield from comment #2)
> I dont understand why the Ceph OSD nodes would need any OSP software or
> channels.
> 
> It purely runs Ceph, no OSP.  Having OSP software on there increases the
> surface attack space and risk.

All overcloud nodes use the same base image and that image has all the OpenStack rpms on them; the role of "ceph node" is simply the enabling of the ceph components. OSP components are not removed, just not used.

So while it purely runs ceph there are all the other packages present. If one of those packages has an exploit I'd prefer it was patched to ensure no one can use it in an unpatched state after compromising the box.

Comment 4 James Biao 2017-02-01 02:25:51 UTC

I observe similar issue in pervious cases, but vince-versa. Customer needs to update OSP controller nodes but requires Ceph repo to go through the yum update. As the pre-built image contains both osp and ceph packages.

in that case we followed https://access.redhat.com/solutions/2196011. Provided a temp subscription to get over the issue.

BZ https://bugzilla.redhat.com/show_bug.cgi?id=1405881

Comment 5 August Simonelli 2017-02-01 11:39:18 UTC

(In reply to James Biao from comment #4)
> I observe similar issue in pervious cases, but vince-versa. Customer needs
> to update OSP controller nodes but requires Ceph repo to go through the yum
> update. As the pre-built image contains both osp and ceph packages.
> 
> in that case we followed https://access.redhat.com/solutions/2196011.
> Provided a temp subscription to get over the issue.
> 
> BZ https://bugzilla.redhat.com/show_bug.cgi?id=1405881

Same for us. We have OSP eval subs now attached to the ceph nodes and removed the smart management and everything is happy. we preferred not to alter the image and remove the pems on it, so the eval cert "solves" this for the moment but we need a long term solution.

Comment 8 August Simonelli 2017-03-29 01:19:02 UTC

RFE for Ceph-only OSP overcloud nodes: https://bugzilla.redhat.com/show_bug.cgi?id=1435500

Comment 20 Amit Kumar Das 2017-10-02 01:55:49 UTC

Any progress on this issue ? Thanks,

Comment 32 Dave Cain 2018-03-08 20:20:51 UTC

Any updates here?

Comment 41 Yogev Rabl 2019-01-10 15:37:18 UTC

Verified

Verification steps:
1) Created activation key for ceph storage node
2) deployed a overcloud with 13
3) activated the key within the ceph storage node

got the following:
# ls -l /etc/pki/product
total 4
-rw-r--r--. 1 root root 2244 Nov  7 21:05 83.pe

Comment 43 errata-xmlrpc 2019-01-16 17:01:22 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://access.redhat.com/errata/RHBA-2019:0071