Security Guide - Remove out of date reference to OpenStack versions
Bug #1343562 reported by
Lucas Fisher
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openstack-manuals |
Fix Released
|
High
|
N Dillon |
Bug Description
The Security Guide includes numerous references to OpenStack release names. Use of these names make the guide appear outdated. Re-evaluate if these references are needed and remove if appropriate.
-------
Built: 2014-07-17T19:36:06 00:00
git SHA: 5ce4ae8b6c47080
URL: http://
source File: file:/home/
xml:id: os-security-guide
Changed in openstack-manuals: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in openstack-manuals: | |
assignee: | nobody → N Dillon (sicarie) |
To post a comment you must log in.
Ran 'grep -i 'havana\ |grizzly\ |folsom\ |essex\ diablo\ |cactus\ |bexar\ |austin' against the book and saw:
bk-openstack- security- guide.xml: <para>Havana release.</para> openstack. redhat. com/forum/ discussion/ 67/resolved- spice-support- in-rdo- grizzly/ p1">SPICE support in RDO Grizzly< /link>< /para> access- control. xml: <para>Finally, it should be noted that as of the Grizzly release, gaps exist where <systemitem class=" service" >nova-conductor </systemitem> is not used throughout OpenStack Compute. Depending on one's configuration, the use of <systemitem class=" service" >nova-conductor </systemitem> may not allow deployers to avoid the necessity of providing database GRANTs to individual compute host systems.</para> access- control. xml: <para>Implementors should weigh the benefits and risks of both configurations before enabling or disabling the <systemitem class=" service" >nova-conductor </systemitem> service. We are not yet prepared to recommend the use of <systemitem class=" service" >nova-conductor </systemitem> in the Grizzly release. However, we do believe that this recommendation will change as additional features are added into OpenStack.</para> encryption. xml: <para>A feature aimed for the Havana release provides encryption of the VM's data before it is written to disk. This allows the privacy of data to be maintained while residing on the storage device. The idea is similar to how self-encrypting drives work. This feature presents a normal block storage device to the VM but encrypts the bytes in the virtualization host before writing them to the disk. The block server operates exactly as it does when reading and writing unencrypted blocks, except special handling will be required for Block Storage features such as snapshots and live migration. Note that this feature uses an independent key manager.</para> interfaces. xml: <para><link xlink:href="https:/ /wiki.openstack .org/wiki/ ReleaseNotes/ Grizzly"><citetitle> Grizzly Release Notes</ citetitle> </link> </para> services. xml: <para>OpenStack Networking currently only supports GRE encapsulation with planned future support of VXLAN due in the Havana release.</para> services. xml: <para>The ability to set QoS on the virtual interface ports of tenant instances is a current deficiency for OpenStack Networking. The application of QoS for traffic shaping and rate-limiting at the physical network edge device is insufficient due to the dynamic nature of workloads in an OpenStack deployment and can not be leveraged in the traditional way. QoS-as-a-Service (QoSaaS) is currently in development for the OpenStack Networking Havana release as an experimental feature. QoSaaS is planning to provide the following services:</para> services. xml: <para>An experimental feature in the Grizzly release of OpenStack Networking is Load-Balancer- as-a-service (LBaaS). The LBaaS API gives early adopters and vendors a chance to build implementations of the technology. The reference implementation however, is still experimental and...
ch_compute.xml: <para><link xlink:href="http://
ch_database-
ch_database-
ch_data-
ch_management-
ch_networking-
ch_networking-
ch_networking-