Bug 1251187 - [DOCS][KA] Update methods for CF 3.2/CFME 5.4
[DOCS][KA] Update methods for CF 3.2/CFME 5.4
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Documentation (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: GA
: 5.5.0
Assigned To: Marianne Feifer
Jan Krocil
Depends On:
  Show dependency treegraph
Reported: 2015-08-06 12:03 EDT by Marianne Feifer
Modified: 2015-08-14 11:20 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-08-14 11:20:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Article) 1564023 None None None Never

  None (edit)
Description Marianne Feifer 2015-08-06 12:03:57 EDT
Description of problem:

Need article on how to perform maintenance updates for 5.4, including what is needed if you need to automate it via script.

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

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 1 Marianne Feifer 2015-08-06 12:07:49 EDT
e-mail from jkrocil

Hello Marianne,
yup, that one definitely needs to be updated.

I think the most crucial section is the RHSM registration and it currently incorrectly states to 'console into the appliance and run "yum-config-manager --enable cf-me-5.2-for-rhel-6-rpms"'.
That should be changed to instructing the customer to only register through the UI, as that is now completely sufficient as it auto-enables the repos.
The repositories to enable (in UI) that are necessary for updating should be left at the default ones (CFME & RHSCL), at least in case of RHSM.

For Satellite 5, the UI registration should be sufficient if username/password credentials are used. Activation keys are not supported through the UI.
If the customer needs more than that -> use rhnreg_ks, rhn_register, rhn-channel.

For Satellite 6, the same thing applies pretty much. Username/password combination is the only supported way to register through the UI.
If they need more (like activation keys) -> use subscription-manager.

Then there is the RHN content proxy server role that is able to server packages to appliances in the same region.
But the appliance with the proxy enabled still has to be registered using one of the above-mentioned ways.

Last time I thoroughly tested the RHN content proxy though, there were dependency issues caused by the way the feature is implemented and I wouldn't be surprised if those still persisted.

Throughout whole article, there are also mentions of specific channels/repositories like 'RHN channel "rhel-x86_64-server-6-cf-me-2"'.
I'm not so sure we should be using specific channel/repo names?
Comment 3 Marianne Feifer 2015-08-13 14:00:00 EDT
Can you please review the article?  Thanks.
Comment 4 Jan Krocil 2015-08-14 04:38:00 EDT
a single suggestion - I'd change this line

"For reference, the following repositories or channels are enabled when you register using the CFME Web Interface"

to add, that the channels mentioned below are the default ones and can be changed in the UI =>

"For reference, the following repositories or channels are enabled by default when you register using the CFME Web Interface - they can be changed in the UI prior to registration, if necessary"

something like that?

Otherwise, it's easy to understand yet info-rich. +1 :)
Comment 5 Marianne Feifer 2015-08-14 11:20:43 EDT
Thanks, Jan.  Made your suggested changes.

Note You need to log in before you can comment on or make changes to this bug.