Bug 965900
Summary: | Appendix: Installation Checklist | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Summer Long <slong> |
Component: | doc-Installation_and_Configuration_Guide | Assignee: | Summer Long <slong> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | ecs-bugs |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.0 | CC: | alyoung, sgordon |
Target Milestone: | --- | Keywords: | Documentation |
Target Release: | 3.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
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: | Environment: | ||
Last Closed: | 2013-07-01 20:23:40 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: |
Comment 2
Summer Long
2013-05-23 04:23:28 UTC
Put topic into spec, but commented out in case a docs snapshot is taken this monday for the QE folks. First draft finally into the backend. Need to figure out a tech reviewer. Comments from Russell Bryant (via RHOS-DEV): Comments: * 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" --> s/database/databases/ * 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. -Bob 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?: DIGEST-MD5 KERBEROS/GSSAPI EXTERNAL 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.) Finished reworks for Russell's and Dmitri's comments. Waiting for new build before sending over to QE. Removed s3 from Image backend possibilities, per Perry/Steve's recommendation. A.2 [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 A.7 [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. |