Bug 965900 - Appendix: Installation Checklist
Appendix: Installation Checklist
Product: Red Hat OpenStack
Classification: Red Hat
Component: doc-Installation_and_Configuration_Guide (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.0
Assigned To: Summer Long
: Documentation
Depends On:
  Show dependency treegraph
Reported: 2013-05-21 20:12 EDT by Summer Long
Modified: 2013-07-01 16:23 EDT (History)
2 users (show)

See Also:
Fixed In Version: Red_Hat_OpenStack-Installation_and_Configuration_Guide-3-en-US-3-13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-01 16:23:40 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)

  None (edit)
Comment 2 Summer Long 2013-05-23 00:23:28 EDT
Going through the install, and creating the checklist as I go (can then do a good job of 'validate the install'). Topic created: 16962.
Comment 3 Summer Long 2013-05-24 01:46:06 EDT
Put topic into spec, but commented out in case a docs snapshot is taken this monday for the QE folks.
Comment 4 Summer Long 2013-05-27 20:36:10 EDT
First draft finally into the backend. Need to figure out a tech reviewer.
Comment 6 Summer Long 2013-05-30 20:35:49 EDT
Comments from Russell Bryant (via RHOS-DEV):


 * table B.1, This lists a kerberos server as required.  This is not a
requirement that I know of.

 * table B.1, The requirement for knowing IP addresses makes sense.
However, the list given to be filled in does not.  Many of these
services may be running on one or more machines, so it's not quite as
simple as the checklist implies.

 * table B.1, "... installing the Red Hat OpenStack cloud" --> s/the/a/

 * table B.1, "ability to add both database and users" -->

 * table B.2, "If using external SSL Certificates, must know where the
database and certificates are located, as well as access to them." seems
grammatically broken.

 * table B.2, "If using LDAP, must have administrative access to
configure a new directory server schema." also seems grammatically broken.

 * In table B.2, s/OpenSTack/OpenStack/

 * table B.3, There are two references to the XFG filesystem.
Presumably this is supposed to be XFS.

 * table B.3, "Connections", you can use Object Storage without any of
these things, so all of these connections are optional.

 * table B.4, Backend Storage.  This should probably refer to "Object
Storage" instead of "Swift" for consistency.  S3 the backend store, not
S3 Authentication.  This lists "Cephx" as a supported backend.  I would
double check that we support that before listing it.  I'm not sure we do.

* table B.5, GlusterFS should be listed as a backend here.

* table B.5, I don't think "iSCSI" is appropriate for this list.  There
a bunch of storage vendor backends, though, similar to what is listed in
the Networking service table.

* table B.7, Hardware virt support, "Note: a procedure is included in
the this Guide to verify this.	"  How about an <xref> to the procedure here?

* table B.7, VNC client, "The Compute service supports VNC support".  I
would remove the second instance of "support" here.

* table B.7, VNC client, a traditional VNC client is *not* supported.

* table B.7, For CPU, Memory, and Host resources, if we're going ot have
these listed, it would be helpful to the reader to point to the
nova.conf option to change if they would like to change this.  It's not
really something you strictly need to know before doing an install, though.

* table B.7, libvirt Version, "Depending on your plugins ...", what plugins?

Comments from Robert Kukura (via rhos-dev):
Kerberos installation: A Kerberos server must already be configured and available. Must know the domain names and Kerberos realm for the network environment.

Adam has verified that kerberos is not a requirement for keystone, and
I'm not sure where else it would be required.

Response from Steve Gordon to Bob:I believe it's come out of the fact that I listed Kerberos as a supported SASL authentication mechanism for Qpid [1] (this content was largely lifted from an MRG guide). This section needs a rework and probably a number of the authentication schemes for Qpid dropped from the RHOS version. Do the OpenStack clients support the use of any of these SASL authentication mechanisms with Qpid?:

Comment 7 Summer Long 2013-06-02 17:37:17 EDT
Per Dmitri Pal:Moving forward (read next release) we will configure RHOS to use
Kerberos and SASL out of box. We plan to provide IdM as an identity backbone. So the answer is not yet. This section can be cleaned for now with the intent to be significantly reworked when IdM integration is implemented (hopefully by next RHOS release).
So am removing the Kerberos line from the checklist. (966791 dealing with Steve's main section.)
Comment 8 Summer Long 2013-06-02 19:23:23 EDT
Finished reworks for Russell's and Dmitri's comments. Waiting for new build before sending over to QE.
Comment 10 Summer Long 2013-06-04 22:34:41 EDT
Removed s3 from Image backend possibilities, per Perry/Steve's recommendation.
Comment 13 Summer Long 2013-06-23 21:44:27 EDT
[comment] as above this sentence doesn't flow quite right. Suggest something like '...database and certificates are located, and have access to them' instead.
[FIX] Done 

[typo] missing closing )
[FIX] Done
table A.7, VNC client, "The Compute service supports VNC support".  I
[comment] I support this suggestion from comment6
[FIX] Rewritten to: "The Compute service supports the Virtual Network Computing (VNC) console to instances through a web browser."
Ready for QE with the next doc release.

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