diff --git a/doc/common/section_cli_nova_quotas.xml b/doc/common/section_cli_nova_quotas.xml index da6c0e2214..cd83958b43 100644 --- a/doc/common/section_cli_nova_quotas.xml +++ b/doc/common/section_cli_nova_quotas.xml @@ -13,7 +13,7 @@ Manage Compute service quotas As an administrative user, you can use the nova quota-* commands, which are provided by the python-novaclient - package, to update the Compute Service quotas for a specific tenant or + package, to update the Compute service quotas for a specific tenant or tenant user, as well as update the quota defaults for a new tenant. diff --git a/doc/common/section_getstart_compute.xml b/doc/common/section_getstart_compute.xml index 3b6a23e712..b742bf4bb3 100644 --- a/doc/common/section_getstart_compute.xml +++ b/doc/common/section_getstart_compute.xml @@ -14,7 +14,7 @@ example, the number of instances). The Compute service scales horizontally on standard hardware, and downloads images to launch instances as required. - The Compute Service is made up of the following functional + The Compute service is made up of the following functional areas and their underlying components: API @@ -198,7 +198,7 @@ and development work), MySQL, and PostgreSQL. - The Compute Service interacts with other OpenStack services: + The Compute service interacts with other OpenStack services: Identity Service for authentication, Image Service for images, and the OpenStack dashboard for a web interface. diff --git a/doc/common/section_using-vnc-console.xml b/doc/common/section_using-vnc-console.xml index d8174af9c1..c6ef816169 100644 --- a/doc/common/section_using-vnc-console.xml +++ b/doc/common/section_using-vnc-console.xml @@ -13,7 +13,7 @@ xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="getting-an-access-url"> Get an access URL - The Compute Service enables you to create access_urls + The Compute service enables you to create access_urls through the os-consoles extension. Support for accessing this URL is provided by the nova client: $ nova get-vnc-console [server_id] [novnc|xvpvnc] diff --git a/doc/config-reference/block-storage/drivers/xen-sm-driver.xml b/doc/config-reference/block-storage/drivers/xen-sm-driver.xml index 99939d4636..c4175826d4 100644 --- a/doc/config-reference/block-storage/drivers/xen-sm-driver.xml +++ b/doc/config-reference/block-storage/drivers/xen-sm-driver.xml @@ -125,7 +125,7 @@ Ensure all hosts running volume and - compute services have connectivity to the + Compute services have connectivity to the storage system. diff --git a/doc/config-reference/compute/section_compute-conductor.xml b/doc/config-reference/compute/section_compute-conductor.xml index 8aba81df9c..f041dd2cce 100644 --- a/doc/config-reference/compute/section_compute-conductor.xml +++ b/doc/config-reference/compute/section_compute-conductor.xml @@ -30,7 +30,7 @@ currently in nova-compute up to the nova-conductor layer. The - compute service will start to look like a less intelligent + Compute service will start to look like a less intelligent slave service to nova-conductor. The conductor service will implement long running complex operations, ensuring forward diff --git a/doc/config-reference/compute/section_compute-configure-service-groups.xml b/doc/config-reference/compute/section_compute-configure-service-groups.xml index c43a1a3d89..6e46d6ecc0 100644 --- a/doc/config-reference/compute/section_compute-configure-service-groups.xml +++ b/doc/config-reference/compute/section_compute-configure-service-groups.xml @@ -12,7 +12,7 @@ xmlns:ns3="http://www.w3.org/1998/Math/MathML" xmlns:ns="http://docbook.org/ns/docbook" version="5.0"> - Configuring Compute Service Groups + Configuring Compute service groups To effectively manage and utilize compute nodes, the Compute service must know their statuses. For example, when a user launches a new VM, the Compute scheduler should send the request to a live node (with enough capacity too, of course). From the Grizzly release diff --git a/doc/config-reference/compute/section_compute-sample-configuration-files.xml b/doc/config-reference/compute/section_compute-sample-configuration-files.xml index 96b011eaeb..4ab80e45b1 100644 --- a/doc/config-reference/compute/section_compute-sample-configuration-files.xml +++ b/doc/config-reference/compute/section_compute-sample-configuration-files.xml @@ -5,7 +5,7 @@ Files in this section can be found in /etc/nova.
api-paste.ini - The Compute Service stores its API configuration settings in the + The Compute service stores its API configuration settings in the api-paste.ini file. @@ -13,7 +13,7 @@
policy.json - The policy.json file defines additional access controls that apply to the Compute Service. + The policy.json file defines additional access controls that apply to the Compute service. @@ -21,7 +21,7 @@
rootwrap.conf The rootwrap.conf file defines configuration - values used by the rootwrap script when the Compute Service + values used by the rootwrap script when the Compute service needs to escalate its privileges to those of the root user. diff --git a/doc/glossary/glossary-terms.xml b/doc/glossary/glossary-terms.xml index e756f5c05f..afadaaa99d 100644 --- a/doc/glossary/glossary-terms.xml +++ b/doc/glossary/glossary-terms.xml @@ -114,7 +114,7 @@ accounting - The Compute Service provides accounting information + The Compute service provides accounting information through the event notification and system usage data facilities. @@ -200,7 +200,7 @@ alert - The Compute Service can send alerts through its + The Compute service can send alerts through its notification system, which includes a facility to create custom notification drivers. Alerts can be sent to and displayed on the horizon dashboard. @@ -1036,7 +1036,7 @@ Compute The OpenStack core project that provides compute - services. The project name of the Compute Service is nova. + services. The project name of the Compute service is nova. @@ -1076,7 +1076,7 @@ - compute service + Compute service Name for the Compute component that manages VMs. diff --git a/doc/install-guide/section_neutron-network-node.xml b/doc/install-guide/section_neutron-network-node.xml index e4f9918d23..1648170a4f 100644 --- a/doc/install-guide/section_neutron-network-node.xml +++ b/doc/install-guide/section_neutron-network-node.xml @@ -363,7 +363,7 @@ local_ip = DATA_INTERFACE_IP Compute metadata service. On the controller, edit the /etc/nova/nova.conf file to define a - secret key that will be shared between the Compute Service + secret key that will be shared between the Compute service and the Networking metadata agent. Add to the [DEFAULT] section: diff --git a/doc/install-guide/section_nova-compute.xml b/doc/install-guide/section_nova-compute.xml index 3742fb8a36..09daefcbcf 100644 --- a/doc/install-guide/section_nova-compute.xml +++ b/doc/install-guide/section_nova-compute.xml @@ -138,19 +138,19 @@ admin_user = nova admin_password = NOVA_PASS - Configure the Compute Service to use the + Configure the Compute service to use the Qpid message broker by setting these configuration keys: # openstack-config --set /etc/nova/nova.conf \ DEFAULT rpc_backend nova.openstack.common.rpc.impl_qpid # openstack-config --set /etc/nova/nova.conf DEFAULT qpid_hostname controller - Configure the Compute Service to use + Configure the Compute service to use the RabbitMQ message broker by setting these configuration keys in the [DEFAULT] configuration group of the /etc/nova/nova.conf file: rpc_backend = nova.rpc.impl_kombu rabbit_host = controller rabbit_password = RABBIT_PASS - Configure the Compute Service to use the RabbitMQ message broker + Configure the Compute service to use the RabbitMQ message broker by setting these configuration keys: # openstack-config --set /etc/nova/nova.conf \ DEFAULT rpc_backend nova.rpc.impl_kombu diff --git a/doc/install-guide/section_nova-controller.xml b/doc/install-guide/section_nova-controller.xml index 6081cd0bd6..a8624bbb7c 100644 --- a/doc/install-guide/section_nova-controller.xml +++ b/doc/install-guide/section_nova-controller.xml @@ -58,7 +58,7 @@ connection = mysql://nova:NOVA_DBPASS@controller/nova # openstack-config --set /etc/nova/nova.conf DEFAULT qpid_hostname controller - Configure the Compute Service to use the RabbitMQ message broker by + Configure the Compute service to use the RabbitMQ message broker by setting these configuration keys in the [DEFAULT] configuration group of the /etc/nova/nova.conf file: diff --git a/doc/security-guide/ch004_book-introduction.xml b/doc/security-guide/ch004_book-introduction.xml index 1856e77178..cd0576c5c2 100644 --- a/doc/security-guide/ch004_book-introduction.xml +++ b/doc/security-guide/ch004_book-introduction.xml @@ -120,12 +120,12 @@
Compute - OpenStack Compute Service (Nova) provides services to + OpenStack Compute service (nova) provides services to support the management of virtual machine instances at scale, instances that host multi-tiered applications, dev/test environments, "Big Data" crunching Hadoop clusters, and/or high performance computing. - The Compute Service facilitates this management through an + The Compute service facilitates this management through an abstraction layer that interfaces with supported hypervisors, which we address later on in more detail. Later in the guide, we focus generically on the @@ -206,8 +206,8 @@ Image Service The OpenStack Image Service (Glance) provides disk image management services. The Image Service provides image - discovery, registration, and delivery services to Compute, the - compute service, as needed. + discovery, registration, and delivery services to the + Compute service, as needed. Trusted processes for managing the life cycle of disk images are required, as are all the previously mentioned issues with respect to data security. diff --git a/doc/security-guide/ch005_security-domains.xml b/doc/security-guide/ch005_security-domains.xml index 708da13b3a..ef3d4a670a 100644 --- a/doc/security-guide/ch005_security-domains.xml +++ b/doc/security-guide/ch005_security-domains.xml @@ -107,7 +107,7 @@
Outbound attacks and reputational risk - Careful consideration should be given to potential outbound abuse from a cloud deployment.  Whether public or private, clouds tend to have lots of resource available. An attacker who has established a point of presence within the cloud, either through hacking in or via entitled access (rogue employee), can bring these resources to bear against the internet at large. Clouds with compute services make for ideal DDoS and brute force engines. This is perhaps a more pressing issue for public clouds as their users are largely unaccountable, and can quickly spin up numerous disposable instances for outbound attacks.  Major damage can be inflicted upon a company's reputation if it becomes known for hosting malicious software or launching attacks on other networks. Methods of prevention include egress security groups, outbound traffic inspection, customer education and awareness, and fraud and abuse mitigation strategies. + Careful consideration should be given to potential outbound abuse from a cloud deployment.  Whether public or private, clouds tend to have lots of resource available. An attacker who has established a point of presence within the cloud, either through hacking in or via entitled access (rogue employee), can bring these resources to bear against the internet at large. Clouds with Compute services make for ideal DDoS and brute force engines. This is perhaps a more pressing issue for public clouds as their users are largely unaccountable, and can quickly spin up numerous disposable instances for outbound attacks.  Major damage can be inflicted upon a company's reputation if it becomes known for hosting malicious software or launching attacks on other networks. Methods of prevention include egress security groups, outbound traffic inspection, customer education and awareness, and fraud and abuse mitigation strategies.
Attack Types diff --git a/doc/security-guide/ch024_authentication.xml b/doc/security-guide/ch024_authentication.xml index 7310bdf76b..d96eab2e8b 100644 --- a/doc/security-guide/ch024_authentication.xml +++ b/doc/security-guide/ch024_authentication.xml @@ -264,7 +264,7 @@ taken as some internal services will need sufficient time to complete their work. The cloud may not provide services if tokens expire too early. An example of this would be the time - needed by the Compute Service to transfer a disk image onto the + needed by the Compute service to transfer a disk image onto the hypervisor for local caching. The following example shows a PKI token. Note that, in practice, the token id value is about 3500 bytes. We shorten it diff --git a/doc/security-guide/ch026_compute.xml b/doc/security-guide/ch026_compute.xml index e5acf171bd..4dfcef517b 100644 --- a/doc/security-guide/ch026_compute.xml +++ b/doc/security-guide/ch026_compute.xml @@ -1,11 +1,11 @@ Compute - The Compute Service (Nova) is one of the more complex OpenStack services.  It runs in many locations throughout the cloud and interacts with a variety of internal services.  For this reason, most of our recommendations regarding best practices for Compute Service configuration are distributed throughout this book. We provide specific details in the sections on Management, API Endpoints, Messaging, and Database. + The Compute service (nova) is one of the more complex OpenStack services.  It runs in many locations throughout the cloud and interacts with a variety of internal services.  For this reason, most of our recommendations regarding best practices for Compute service configuration are distributed throughout this book. We provide specific details in the sections on Management, API Endpoints, Messaging, and Database.
Virtual Console Selection One decision a cloud architect will need to make regarding - Compute Service configuration is whether to use VNC or SPICE. Below we provide some details on the differences between these options. diff --git a/doc/training-guides/module001-ch005-vm-provisioning-walk-through.xml b/doc/training-guides/module001-ch005-vm-provisioning-walk-through.xml index 1dea1aca46..9ee9069a83 100644 --- a/doc/training-guides/module001-ch005-vm-provisioning-walk-through.xml +++ b/doc/training-guides/module001-ch005-vm-provisioning-walk-through.xml @@ -137,7 +137,7 @@ for the storage and management of images within OpenStack. Instances are the individual virtual machines running on - physical compute nodes. The OpenStack Compute Service manages + physical compute nodes. The OpenStack Compute service manages instances. Any number of instances maybe started from the same image. Each instance is run from a copy of the base image so runtime changes made by an instance do not change the image it diff --git a/doc/training-guides/module001-ch009-vm-placement.xml b/doc/training-guides/module001-ch009-vm-placement.xml index 9785f75e5b..f98f56f15e 100644 --- a/doc/training-guides/module001-ch009-vm-placement.xml +++ b/doc/training-guides/module001-ch009-vm-placement.xml @@ -9,8 +9,9 @@ dispatch compute and volume requests. For example, the nova-scheduler service determines which host a VM should launch on. The term host in the context of filters means a physical node - that has a nova-compute service running on it. You can configure - the scheduler through a variety of options. + that has a nova-compute + service running on it. You can configure the scheduler through a + variety of options.
Nova @@ -91,7 +92,7 @@ ComputeCapabilitiesFilter - checks that the - capabilities provided by the host compute service satisfy + capabilities provided by the host Compute service satisfy any extra specifications associated with the instance type. It passes hosts that can create the specified instance type. @@ -140,7 +141,7 @@ Next standard filter to describe is AvailabilityZoneFilter and it isn’t difficult too. This filter just looks at the availability zone of compute node and availability zone from - the properties of the request. Each compute service has its + the properties of the request. Each Compute service has its own availability zone. So deployment engineers have an option to run scheduler with availability zones support and can configure availability zones on each compute host. This @@ -169,7 +170,7 @@ capabilities satisfy the requested specifications. All hosts are passed if no extra_specs are specified. ComputeFilter is quite simple and passes any host whose - compute service is enabled and operational. + Compute service is enabled and operational. Now we are going to IsolatedHostsFilter. There can be some special hosts reserved for specific images. These hosts are called isolated. So the images to run on the isolated hosts diff --git a/doc/user-guide-admin/section_cli_keystone_set_quotas.xml b/doc/user-guide-admin/section_cli_keystone_set_quotas.xml index db16c5b4c8..3d5d9f055b 100644 --- a/doc/user-guide-admin/section_cli_keystone_set_quotas.xml +++ b/doc/user-guide-admin/section_cli_keystone_set_quotas.xml @@ -19,8 +19,8 @@ Quotas can be enforced at both the tenant (or project) and the tenant-user level. Using the command-line interface, you can manage quotas for - the OpenStack Compute Service, the OpenStack Block Storage Service, - and the OpenStack Networking Service. + the OpenStack Compute service, the OpenStack Block Storage service, + and the OpenStack Networking service. Typically, default values are changed because a tenant requires more than 10 volumes, or more than 1 TB on a compute node. diff --git a/doc/user-guide-admin/section_dashboard_admin_set_quotas.xml b/doc/user-guide-admin/section_dashboard_admin_set_quotas.xml index 85953a0f59..e51695ebd8 100644 --- a/doc/user-guide-admin/section_dashboard_admin_set_quotas.xml +++ b/doc/user-guide-admin/section_dashboard_admin_set_quotas.xml @@ -23,8 +23,8 @@ quotas for new tenants, as well as update quotas for existing tenants. Using the command-line interface, you can manage quotas for the - OpenStack Compute Service, the OpenStack Block Storage Service, and - the OpenStack Networking Service (see ). + OpenStack Compute service, the OpenStack Block Storage service, and + the OpenStack Networking service (see ). Additionally, you can update Compute service quotas for tenant users. @@ -197,4 +197,4 @@ command-line client. See .
-
\ No newline at end of file +
Compute quota descriptions