Bug 1251187 - [DOCS][KA] Update methods for CF 3.2/CFME 5.4
Summary: [DOCS][KA] Update methods for CF 3.2/CFME 5.4
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Documentation
Version: 5.5.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: GA
: 5.5.0
Assignee: Marianne Feifer
QA Contact: Jan Krocil
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-06 16:03 UTC by Marianne Feifer
Modified: 2015-08-14 15:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-14 15:20:43 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Article) 1564023 0 None None None Never

Description Marianne Feifer 2015-08-06 16:03:57 UTC
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:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Marianne Feifer 2015-08-06 16:07:49 UTC
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 18:00:00 UTC
Can you please review the article?  Thanks.

Comment 4 Jan Krocil 2015-08-14 08:38:00 UTC
Marianne,
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 15:20:43 UTC
Thanks, Jan.  Made your suggested changes.


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