diff --git a/doc/admin-guide-cloud/bk-admin-guide-cloud.xml b/doc/admin-guide-cloud/bk-admin-guide-cloud.xml index 46e9256ff6..5d0827b47d 100644 --- a/doc/admin-guide-cloud/bk-admin-guide-cloud.xml +++ b/doc/admin-guide-cloud/bk-admin-guide-cloud.xml @@ -22,7 +22,7 @@ 2013 OpenStack Foundation - havana + icehouse OpenStack diff --git a/doc/admin-guide-cloud/image/section_glance-property-protection.xml b/doc/admin-guide-cloud/image/section_glance-property-protection.xml index 33837af522..9d7e1ef378 100644 --- a/doc/admin-guide-cloud/image/section_glance-property-protection.xml +++ b/doc/admin-guide-cloud/image/section_glance-property-protection.xml @@ -8,7 +8,7 @@ Service: "core properties," which are defined by the system, and "additional properties," which are arbitrary key/value pairs that can be set on an image. - With the Havana release, any such property can be protected + Any such property can be protected through configuration. When you put protections on a property, it limits the users who can perform CRUD operations on the property based on their user role. The use case is to enable the cloud @@ -23,4 +23,4 @@ Property protection can be set in /etc/glance/property-protections.conf, using roles found in policy.json. - \ No newline at end of file + diff --git a/doc/admin-guide-cloud/networking/section_networking-adv-config.xml b/doc/admin-guide-cloud/networking/section_networking-adv-config.xml index 1d570395d9..74b2048875 100644 --- a/doc/admin-guide-cloud/networking/section_networking-adv-config.xml +++ b/doc/admin-guide-cloud/networking/section_networking-adv-config.xml @@ -419,7 +419,7 @@ external_network_bridge = br-ex-2 dhcp-agents with load being split across those agents, but the tight coupling of that scheduling with the location of the VM is not supported in - Grizzly. The Havana release is expected to include + Icehouse. The Juno release is expected to include an exact replacement for the --multi_host flag in nova-network. diff --git a/doc/admin-guide-cloud/networking/section_networking_introduction.xml b/doc/admin-guide-cloud/networking/section_networking_introduction.xml index 66f769df7e..03f7c2a18d 100644 --- a/doc/admin-guide-cloud/networking/section_networking_introduction.xml +++ b/doc/admin-guide-cloud/networking/section_networking_introduction.xml @@ -313,8 +313,8 @@ NEC OpenFlow Plug-in http://wiki.openstack.org/Quantum-NEC-OpenFlow-Plugin + xlink:href="https://wiki.openstack.org/wiki/Neutron/NEC_OpenFlow_Plugin" + >https://wiki.openstack.org/wiki/Neutron/NEC_OpenFlow_Plugin Open vSwitch diff --git a/doc/admin-guide-cloud/section_multi_backend.xml b/doc/admin-guide-cloud/section_multi_backend.xml index 69d964beba..5d2247e4ec 100644 --- a/doc/admin-guide-cloud/section_multi_backend.xml +++ b/doc/admin-guide-cloud/section_multi_backend.xml @@ -3,9 +3,8 @@ xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.0"> Configure a multiple-storage back-end - This section presents the multi back-end storage feature - introduced with the Grizzly release. Multi back-end allows the - creation of several back-end storage solutions serving the + With multiple storage back-ends configured, you can create + several back-end storage solutions serving the same OpenStack Compute configuration. Basically, multi back-end launches one cinder-volume for each back-end. @@ -95,15 +94,6 @@ volume_backend_name=LVM_iSCSI_b pick the best back-end to handle the request, and explicitly creates volumes on specific back-ends through the use of volume types. - - To enable the filter scheduler, add this line to the - cinder.conf configuration - file: - scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler - While the Block Storage Scheduler defaults to - in Grizzly, this - setting is not required. - diff --git a/doc/admin-guide-cloud/section_volume-migration.xml b/doc/admin-guide-cloud/section_volume-migration.xml index a13a13d03a..5012976e58 100644 --- a/doc/admin-guide-cloud/section_volume-migration.xml +++ b/doc/admin-guide-cloud/section_volume-migration.xml @@ -4,7 +4,7 @@ xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"> Migrate volumes - The Havana release of OpenStack introduces the ability to + OpenStack has the ability to migrate volumes between back-ends. Migrating a volume transparently moves its data from the current back-end for the volume to a new one. This is an administrator function, and diff --git a/doc/common/app_support.xml b/doc/common/app_support.xml index 72ccf1c3b1..2215d6f6f4 100644 --- a/doc/common/app_support.xml +++ b/doc/common/app_support.xml @@ -267,12 +267,12 @@ Be sure to include the software and package versions that you are using, especially if you are using a development branch, such as, - "Icehouse release" vs git commit + "Juno release" vs git commit bc79c3ecc55929bac585d04a03475b72e06a3208. Any deployment specific information is helpful, - such as Ubuntu 12.04 or multi-node install. + such as Ubuntu 14.04 or multi-node install. The Launchpad Bugs areas are available here: diff --git a/doc/common/section_cli_cinder_manage_volumes.xml b/doc/common/section_cli_cinder_manage_volumes.xml index ff7f470456..dded5121d2 100644 --- a/doc/common/section_cli_cinder_manage_volumes.xml +++ b/doc/common/section_cli_cinder_manage_volumes.xml @@ -74,14 +74,14 @@ | Name | Status | +-----------------------+----------------------------------------+ | internal | available | -| |- devstack-grizzly | | +| |- devstack | | | | |- nova-conductor | enabled :-) 2013-07-25T16:50:44.000000 | | | |- nova-consoleauth | enabled :-) 2013-07-25T16:50:44.000000 | | | |- nova-scheduler | enabled :-) 2013-07-25T16:50:44.000000 | | | |- nova-cert | enabled :-) 2013-07-25T16:50:44.000000 | | | |- nova-network | enabled :-) 2013-07-25T16:50:44.000000 | | nova | available | -| |- devstack-grizzly | | +| |- devstack | | | | |- nova-compute | enabled :-) 2013-07-25T16:50:39.000000 | +-----------------------+----------------------------------------+ @@ -155,7 +155,7 @@ | display_name | my-new-volume | | id | 573e024d-5235-49ce-8332-be1576d323f8 | | metadata | {} | -| os-vol-host-attr:host | devstack-grizzly | +| os-vol-host-attr:host | devstack | | os-vol-tenant-attr:tenant_id | 66265572db174a7aa66eba661f58eb9e | | size | 8 | | snapshot_id | None | diff --git a/doc/common/section_cli_nova_resizerebuild.xml b/doc/common/section_cli_nova_resizerebuild.xml index 34daccaccc..c7ae4576ba 100644 --- a/doc/common/section_cli_nova_resizerebuild.xml +++ b/doc/common/section_cli_nova_resizerebuild.xml @@ -30,14 +30,14 @@ | status | ACTIVE | | updated | 2013-07-18T15:08:20Z | | OS-EXT-STS:task_state | None | -| OS-EXT-SRV-ATTR:host | devstack-grizzly | +| OS-EXT-SRV-ATTR:host | devstack | | key_name | None | | image | cirros-0.3.2-x86_64-uec (397e713c-b95b-4186-ad46-6126863ea0a9) | | private network | 10.0.0.3 | | hostId | 6e1e69b71ac9b1e6871f91e2dfc9a9b9ceca0f05db68172a81d45385 | | OS-EXT-STS:vm_state | active | | OS-EXT-SRV-ATTR:instance_name | instance-00000005 | -| OS-EXT-SRV-ATTR:hypervisor_hostname | devstack-grizzly | +| OS-EXT-SRV-ATTR:hypervisor_hostname | devstack | | flavor | m1.small (2) | | id | 84c6e57d-a6b1-44b6-81eb-fcb36afd31b5 | | security_groups | [{u'name': u'default'}] | diff --git a/doc/common/section_cli_nova_usage_statistics.xml b/doc/common/section_cli_nova_usage_statistics.xml index 44bd124fbd..8ae31c6312 100644 --- a/doc/common/section_cli_nova_usage_statistics.xml +++ b/doc/common/section_cli_nova_usage_statistics.xml @@ -15,29 +15,29 @@ To show host usage statistics List the hosts and the nova-related services that run on them:$ nova host-list -+------------------+-------------+----------+ -| host_name | service | zone | -+------------------+-------------+----------+ -| devstack-grizzly | conductor | internal | -| devstack-grizzly | compute | nova | -| devstack-grizzly | cert | internal | -| devstack-grizzly | network | internal | -| devstack-grizzly | scheduler | internal | -| devstack-grizzly | consoleauth | internal | -+------------------+-------------+----------+ ++-----------+-------------+----------+ +| host_name | service | zone | ++-----------+-------------+----------+ +| devstack | conductor | internal | +| devstack | compute | nova | +| devstack | cert | internal | +| devstack | network | internal | +| devstack | scheduler | internal | +| devstack | consoleauth | internal | ++-----------+-------------+----------+ Get a summary of resource usage of all of the instances running on the host. - $ nova host-describe devstack-grizzly -+------------------+----------------------------------+-----+-----------+---------+ -| HOST | PROJECT | cpu | memory_mb | disk_gb | -+------------------+----------------------------------+-----+-----------+---------+ -| devstack-grizzly | (total) | 2 | 4003 | 157 | -| devstack-grizzly | (used_now) | 3 | 5120 | 40 | -| devstack-grizzly | (used_max) | 3 | 4608 | 40 | -| devstack-grizzly | b70d90d65e464582b6b2161cf3603ced | 1 | 512 | 0 | -| devstack-grizzly | 66265572db174a7aa66eba661f58eb9e | 2 | 4096 | 40 | -+------------------+----------------------------------+-----+-----------+---------+ + $ nova host-describe devstack ++-----------+----------------------------------+-----+-----------+---------+ +| HOST | PROJECT | cpu | memory_mb | disk_gb | ++----------+----------------------------------+-----+-----------+---------+ +| devstack | (total) | 2 | 4003 | 157 | +| devstack | (used_now) | 3 | 5120 | 40 | +| devstack | (used_max) | 3 | 4608 | 40 | +| devstack | b70d90d65e464582b6b2161cf3603ced | 1 | 512 | 0 | +| devstack | 66265572db174a7aa66eba661f58eb9e | 2 | 4096 | 40 | ++----------+----------------------------------+-----+-----------+---------+ The cpu column shows the sum of the virtual CPUs for instances running on the host. The memory_mb column shows the diff --git a/doc/common/section_fibrechannel.xml b/doc/common/section_fibrechannel.xml index bf08a2c5be..fffa1b28c6 100644 --- a/doc/common/section_fibrechannel.xml +++ b/doc/common/section_fibrechannel.xml @@ -5,6 +5,7 @@ Fibre Channel support in Compute Fibre Channel support in OpenStack Compute is remote block storage attached to compute nodes for VMs. + In the Grizzly release, Fibre Channel supported only the KVM hypervisor. Compute and Block Storage for Fibre Channel do not support automatic diff --git a/doc/common/section_getstart_compute.xml b/doc/common/section_getstart_compute.xml index b742bf4bb3..1458ff9f62 100644 --- a/doc/common/section_getstart_compute.xml +++ b/doc/common/section_getstart_compute.xml @@ -117,12 +117,6 @@ through a VNC connection. Supports browser-based novnc clients. - - nova-console - daemon. Deprecated for use with Grizzly. Instead, the - nova-xvpnvncproxy - is used. - nova-xvpnvncproxy daemon. A proxy for accessing running instances through a VNC diff --git a/doc/common/section_keystone-concepts-group-management.xml b/doc/common/section_keystone-concepts-group-management.xml index 74bf1e927b..94e45e9a76 100644 --- a/doc/common/section_keystone-concepts-group-management.xml +++ b/doc/common/section_keystone-concepts-group-management.xml @@ -5,11 +5,12 @@ xml:id="identity-groups"> Groups A group is a collection of users. Administrators can - create groups and add users to them. Then, rather than - assign a role to each user individually, assign a role to - the group. Every group is in a domain. Groups were - introduced with version 3 of the Identity API (the Grizzly - release of Identity Service). + create groups and add users to them. Then, rather than assign + a role to each user individually, assign a role to the group. + Every group is in a domain. Groups were introduced with the + Identity API v3. + Identity API V3 provides the following group-related operations: diff --git a/doc/config-reference/compute/section_compute-conductor.xml b/doc/config-reference/compute/section_compute-conductor.xml index 19f6de9a3e..41f72954f3 100644 --- a/doc/config-reference/compute/section_compute-conductor.xml +++ b/doc/config-reference/compute/section_compute-conductor.xml @@ -18,7 +18,7 @@ horizontally. You can run multiple instances of nova-conductor on different machines as needed for scaling purposes. -In the Grizzly release, the methods exposed by The methods exposed by nova-conductor are relatively simple methods used by nova-compute to offload its database diff --git a/doc/config-reference/compute/section_hypervisor_kvm.xml b/doc/config-reference/compute/section_hypervisor_kvm.xml index bf8af00c6b..22bd8d48a4 100644 --- a/doc/config-reference/compute/section_hypervisor_kvm.xml +++ b/doc/config-reference/compute/section_hypervisor_kvm.xml @@ -134,14 +134,13 @@ libvirt_cpu_model=Nehalem QEMU) If your nova.conf file contains libvirt_cpu_mode=none, libvirt does not specify a CPU model. - Instead, the hypervisor chooses the default model. This setting is equivalent to the - Compute service behavior prior to the Folsom release. + Instead, the hypervisor chooses the default model.
Guest agent support - With the Havana release, support for guest agents was added, allowing optional access - between compute nods and guests through a socket, using the qmp protocol. + Use guest agents to enable optional access between compute nodes and guests through a + socket, using the QMP protocol. To enable this feature, you must set hw_qemu_guest_agent=yes as a metadata parameter on the image you wish to use to create guest-agent-capable instances from. You can explicitly disable the feature by setting diff --git a/doc/high-availability-guide/aa-network.txt b/doc/high-availability-guide/aa-network.txt index 67105b0d27..7929509be4 100644 --- a/doc/high-availability-guide/aa-network.txt +++ b/doc/high-availability-guide/aa-network.txt @@ -18,13 +18,13 @@ highly available. ==== Running Neutron DHCP Agent -Since the Grizzly release, OpenStack Networking service has a scheduler that +OpenStack Networking service has a scheduler that lets you run multiple agents across nodes. Also, the DHCP agent can be natively highly available. For details, see http://docs.openstack.org/trunk/config-reference/content/app_demo_multi_dhcp_agents.html[OpenStack Configuration Reference]. ==== Running Neutron L3 Agent -Since the Grizzly release, the Neutron L3 Agent is scalable thanks to the scheduler +The Neutron L3 Agent is scalable thanks to the scheduler that allows distribution of virtual routers across multiple nodes. But there is no native feature to make these routers highly available. At this time, the Active / Passive solution exists to run the Neutron L3 diff --git a/doc/high-availability-guide/aa-rabbitmq.txt b/doc/high-availability-guide/aa-rabbitmq.txt index e3c067e0fb..98fe548041 100644 --- a/doc/high-availability-guide/aa-rabbitmq.txt +++ b/doc/high-availability-guide/aa-rabbitmq.txt @@ -83,8 +83,7 @@ http://www.rabbitmq.com/ha.html[More information about High availability in Rabb ==== Configure OpenStack Services to use RabbitMQ -Since the Grizzly Release, most of the OpenStack components using queuing have supported the feature. -We have to configure them to use at least two RabbitMQ nodes. +We have to configure the OpenStack components to use at least two RabbitMQ nodes. Do this configuration on all services using RabbitMQ: diff --git a/doc/image-guide/bk-imageguide.xml b/doc/image-guide/bk-imageguide.xml index ba5862bb00..e39f68aa81 100644 --- a/doc/image-guide/bk-imageguide.xml +++ b/doc/image-guide/bk-imageguide.xml @@ -24,7 +24,7 @@ 2013 OpenStack Foundation - havana + icehouse OpenStack diff --git a/doc/security-guide/bk_openstack-sec-guide.xml b/doc/security-guide/bk_openstack-sec-guide.xml index 459f16a3f9..998ec17e7b 100644 --- a/doc/security-guide/bk_openstack-sec-guide.xml +++ b/doc/security-guide/bk_openstack-sec-guide.xml @@ -18,7 +18,7 @@ 2013 OpenStack Foundation - havana + icehouse OpenStack diff --git a/doc/security-guide/ch026_compute.xml b/doc/security-guide/ch026_compute.xml index 4dfcef517b..5fc519837a 100644 --- a/doc/security-guide/ch026_compute.xml +++ b/doc/security-guide/ch026_compute.xml @@ -35,6 +35,7 @@ The nova-novncproxyand nova-xvpvncproxy services by default open public-facing ports that are token authenticated. + By default, the remote desktop traffic is not encrypted. Havana is expected to have VNC connections secured by Kerberos. diff --git a/doc/security-guide/ch032_networking-best-practices.xml b/doc/security-guide/ch032_networking-best-practices.xml index e44f86a369..a824efd4d1 100644 --- a/doc/security-guide/ch032_networking-best-practices.xml +++ b/doc/security-guide/ch032_networking-best-practices.xml @@ -68,8 +68,13 @@
Network Services Extensions Here is a list of known plug-ins provided by the open source community or by SDN companies that work with OpenStack Networking: - Big Switch Controller Plugin, Brocade Neutron Plugin Brocade Neutron Plugin, Cisco UCS/Nexus Plugin, Cloudbase Hyper-V Plugin, Extreme Networks Plugin, Juniper Networks Neutron Plugin, Linux Bridge Plugin, Mellanox Neutron Plugin, MidoNet Plugin, NEC OpenFlow Plugin, Open vSwitch Plugin, PLUMgrid Plugin, Ruijie Networks Plugin, Ryu OpenFlow Controller Plugin, VMware NSX plugin - For a more detailed comparison of all features provided by plug-ins as of the Folsom release, see Sebastien Han's comparison. + Big Switch Controller plug-in, Brocade Neutron plug-in + Brocade Neutron plug-in, Cisco UCS/Nexus plug-in, Cloudbase + Hyper-V plug-in, Extreme Networks plug-in, Juniper Networks + Neutron plug-in, Linux Bridge plug-in, Mellanox Neutron plug-in, + MidoNet plug-in, NEC OpenFlow plug-in, Open vSwitch plug-in, + PLUMgrid plug-in, Ruijie Networks plug-in, Ryu OpenFlow + Controller plug-in, VMware NSX plug-in.
Networking Services Limitations diff --git a/doc/security-guide/ch038_transport-security.xml b/doc/security-guide/ch038_transport-security.xml index 7814ffce8a..1f3ed68437 100644 --- a/doc/security-guide/ch038_transport-security.xml +++ b/doc/security-guide/ch038_transport-security.xml @@ -83,7 +83,6 @@ rabbit_password=password kombu_ssl_keyfile=/etc/ssl/node-key.pem kombu_ssl_certfile=/etc/ssl/node-cert.pem kombu_ssl_ca_certs=/etc/ssl/cacert.pem - NOTE: A bug exists in the current version of OpenStack Grizzly where if 'kombu_ssl_version' is currently specified in the configuration file for any of the OpenStack services it will cause the following python traceback error: 'TypeError: an integer is required'. The current workaround is to remove 'kombu_ssl_version' from the configuration file. Refer to bug report 1195431 for current status.
Authentication Configuration Example - Qpid diff --git a/doc/security-guide/ch055_security-services-for-instances.xml b/doc/security-guide/ch055_security-services-for-instances.xml index a24c1982f1..2002c51a63 100644 --- a/doc/security-guide/ch055_security-services-for-instances.xml +++ b/doc/security-guide/ch055_security-services-for-instances.xml @@ -27,22 +27,19 @@
Scheduling Instances to Nodes Before an instance is created, a host for the image instantiation must be selected. This selection is performed by the nova-scheduler which determines how to dispatch compute and volume requests. - The default nova scheduler in Grizzly is the Filter - Scheduler, although other schedulers exist (see the section - Scheduling - in the OpenStack Configuration - Reference). The filter scheduler works in - collaboration with 'filters' to decide where an instance should - be started. This process of host selection allows administrators - to fulfill many different security requirements. Depending on the - cloud deployment type for example, one could choose to have - tenant instances reside on the same hosts whenever possible if - data isolation was a primary concern, conversely one could - attempt to have instances for a tenant reside on as many - different hosts as possible for availability or fault tolerance - reasons. The following diagram demonstrates how the filter - scheduler works: + The filter scheduler is the default scheduler for OpenStack Compute, + although other schedulers exist (see the section Scheduling in the OpenStack Configuration + Reference). The filter scheduler works in collaboration with + 'filters' to decide where an instance should be started. This process of + host selection allows administrators to fulfill many different security + requirements. Depending on the cloud deployment type for example, one + could choose to have tenant instances reside on the same hosts whenever + possible if data isolation was a primary concern, conversely one could + attempt to have instances for a tenant reside on as many different hosts + as possible for availability or fault tolerance reasons. The following + diagram demonstrates how the filter scheduler works: diff --git a/doc/user-guide-admin/bk-admin-user-guide.xml b/doc/user-guide-admin/bk-admin-user-guide.xml index b87113da4b..99f6397150 100644 --- a/doc/user-guide-admin/bk-admin-user-guide.xml +++ b/doc/user-guide-admin/bk-admin-user-guide.xml @@ -22,10 +22,10 @@ - 2013 + 2014 OpenStack Foundation - havana + icehouse OpenStack diff --git a/doc/user-guide-admin/section_cli_nova_services.xml b/doc/user-guide-admin/section_cli_nova_services.xml index 28cf13e447..1682de76bc 100644 --- a/doc/user-guide-admin/section_cli_nova_services.xml +++ b/doc/user-guide-admin/section_cli_nova_services.xml @@ -30,12 +30,6 @@ +----------+--------------+----------+-------------------+ | devstack | nova-compute | disabled | Trial log | +----------+--------------+----------+-------------------+ - - The Havana release introduces the optional - --reason parameter that - enables you to log a reason for disabling a - service. - Check the service list: diff --git a/doc/user-guide-admin/section_cli_nova_specify_host.xml b/doc/user-guide-admin/section_cli_nova_specify_host.xml index b55891d8df..f64addc5c9 100644 --- a/doc/user-guide-admin/section_cli_nova_specify_host.xml +++ b/doc/user-guide-admin/section_cli_nova_specify_host.xml @@ -37,26 +37,4 @@ +----+---------------------+ - - - - - Beginning in the Folsom release, the - --availability_zone - zone:host - parameter replaces the - --force_hosts scheduler - hint parameter. - - - Beginning in the Grizzly release, you can - enable the - create:forced_host - option in the policy.json - file to specify which roles can launch an - instance on a specified host. - - - -
diff --git a/doc/user-guide/bk-user-guide.xml b/doc/user-guide/bk-user-guide.xml index 5f823c28a7..5d7744c315 100644 --- a/doc/user-guide/bk-user-guide.xml +++ b/doc/user-guide/bk-user-guide.xml @@ -22,10 +22,10 @@ - 2013 + 2014 OpenStack Foundation - havana + icehouse OpenStack