diff --git a/doc/source/devref/address_scopes.rst b/doc/source/devref/address_scopes.rst index 8a2a08b777a..f763c565e87 100644 --- a/doc/source/devref/address_scopes.rst +++ b/doc/source/devref/address_scopes.rst @@ -83,13 +83,13 @@ from tenancy. Prior to the Mitaka release, there was implicitly only a single 'shared' address scope. Arbitrary address overlap was allowed making it pretty much a -"free for all". To make things seem somewhat sane, normal tenants are not able -to use routers to cross-plug networks from different tenants and NAT was used +"free for all". To make things seem somewhat sane, normal users are not able +to use routers to cross-plug networks from different projects and NAT was used between internal networks and external networks. It was almost as if each -tenant had a private address scope. +project had a private address scope. The problem is that this model cannot support use cases where NAT is not -desired or supported (e.g. IPv6) or we want to allow different tenants to +desired or supported (e.g. IPv6) or we want to allow different projects to cross-plug their networks. An AddressScope covers only one address family. But, they work equally well diff --git a/doc/source/devref/network_ip_availability.rst b/doc/source/devref/network_ip_availability.rst index 8cd2ad403e3..9cfbca2f180 100644 --- a/doc/source/devref/network_ip_availability.rst +++ b/doc/source/devref/network_ip_availability.rst @@ -75,7 +75,7 @@ Example response :: "used_ips": 3 } ], - "tenant_id": "test-tenant", + "tenant_id": "test-project", "total_ips": 253, "used_ips": 3 }, @@ -83,7 +83,7 @@ Example response :: "network_id": "47035bae-4f29-4fef-be2e-2941b72528a8", "network_name": "net2", "subnet_ip_availability": [], - "tenant_id": "test-tenant", + "tenant_id": "test-project", "total_ips": 0, "used_ips": 0 }, @@ -100,7 +100,7 @@ Example response :: "used_ips": 2 } ], - "tenant_id": "test-tenant", + "tenant_id": "test-project", "total_ips": 253, "used_ips": 2 } @@ -137,7 +137,7 @@ Example response :: "used_ips": 3 } ], - "tenant_id": "test-tenant", + "tenant_id": "test-project", "total_ips": 253, "used_ips": 3 } @@ -154,7 +154,7 @@ This API currently supports the following query parameters: * **network_name**: Returns availability for network matching the provided name * **tenant_id**: Returns availability for all networks owned by the provided - tenant ID. + project ID. * **ip_version**: Filters network subnets by those supporting the supplied ip version. Values can be either 4 or 6. @@ -162,8 +162,8 @@ Query filters can be combined to further narrow results and what is returned will match all criteria. When a parameter is specified more than once, it will return results that match both. Examples: :: - # Fetch IPv4 availability for a specific tenant uuid - GET /v2.0/network-ip-availabilities?ip_version=4&tenant_id=example-tenant-uuid + # Fetch IPv4 availability for a specific project uuid + GET /v2.0/network-ip-availabilities?ip_version=4&tenant_id=example-project-uuid # Fetch multiple networks by their ids GET /v2.0/network-ip-availabilities?network_id=uuid_sample_1&network_id=uuid_sample_2 diff --git a/doc/source/devref/openvswitch_agent.rst b/doc/source/devref/openvswitch_agent.rst index 62104cd190f..7e5f9d7f69a 100644 --- a/doc/source/devref/openvswitch_agent.rst +++ b/doc/source/devref/openvswitch_agent.rst @@ -29,7 +29,7 @@ connectivity for instances, along with bridges created in conjunction with OpenStack Nova for filtering. ovs-neutron-agent can be configured to use different networking technologies -to create tenant isolation. +to create project isolation. These technologies are implemented as ML2 type drivers which are used in conjunction with the OpenVSwitch mechanism driver. @@ -72,7 +72,7 @@ Bridge Management In order to make the agent capable of handling more than one tunneling technology, to decouple the requirements of segmentation technology -from tenant isolation, and to preserve backward compatibility for OVS +from project isolation, and to preserve backward compatibility for OVS agents working without tunneling, the agent relies on a tunneling bridge, or br-tun, and the well known integration bridge, or br-int. @@ -82,7 +82,7 @@ externally). The VLAN id of this local VLAN is mapped to the physical networking details realizing that virtual network. For virtual networks realized as VXLAN/GRE tunnels, a Logical Switch -(LS) identifier is used to differentiate tenant traffic on inter-HV +(LS) identifier is used to differentiate project traffic on inter-HV tunnels. A mesh of tunnels is created to other Hypervisors in the cloud. These tunnels originate and terminate on the tunneling bridge of each hypervisor, leaving br-int unaffected. Port patching is done diff --git a/doc/source/devref/policy.rst b/doc/source/devref/policy.rst index 83a1c891bad..f30311d6974 100644 --- a/doc/source/devref/policy.rst +++ b/doc/source/devref/policy.rst @@ -61,7 +61,7 @@ This step uses the ``neutron.policy.enforce`` routine. This routine raises REST API controllers catch this exception and return: * A 403 response code on a ``POST`` request or an ``PUT`` request for an - object owned by the tenant submitting the request; + object owned by the project submitting the request; * A 403 response for failures while authorizing API actions such as ``add_router_interface``; * A 404 response for ``DELETE``, ``GET`` and all other ``PUT`` requests. @@ -177,7 +177,7 @@ OwnerCheck: Extended Checks for Resource Ownership This class is registered for rules matching the ``tenant_id`` keyword and overrides the generic check performed by oslo_policy in this case. -It uses for those cases where neutron needs to check whether the tenant +It uses for those cases where neutron needs to check whether the project submitting a request for a new resource owns the parent resource of the one being created. Current usages of ``OwnerCheck`` include, for instance, creating and updating a subnet. @@ -214,7 +214,7 @@ FieldCheck: Verify Resource Attributes This class is registered with the policy engine for rules matching the 'field' keyword, and provides a way to perform fine grained checks on resource attributes. For instance, using this class of rules it is possible to specify -a rule for granting every tenant read access to shared resources. +a rule for granting every project read access to shared resources. In policy.json, a FieldCheck rules is specified in the following way:: @@ -250,11 +250,11 @@ served by Neutron "core" and for the APIs served by the various Neutron policy engine for evaluation; * The ``tenant_id`` attribute is a fundamental one in Neutron API request authorization. The default policy, ``admin_or_owner``, uses it to validate - if a tenant owns the resource it is trying to operate on. To this aim, + if a project owns the resource it is trying to operate on. To this aim, if a resource without a tenant_id is created, it is important to ensure that ad-hoc authZ policies are specified for this resource. * There is still only one check which is hardcoded in Neutron's API layer: - the check to verify that a tenant owns the network on which it is creating + the check to verify that a project owns the network on which it is creating a port. This check is hardcoded and is always executed when creating a port, unless the network is shared. Unfortunatelu a solution for performing this check in an efficient way through the policy engine has not yet been @@ -274,9 +274,9 @@ Notes AMQP channel. For all these requests a neutron admin context is built, and the plugins will process them as such. * For ``PUT`` and ``DELETE`` requests a 404 error is returned on request - authorization failures rather than a 403, unless the tenant submitting the + authorization failures rather than a 403, unless the project submitting the request own the resource to update or delete. This is to avoid conditions - in which an API client might try and find out other tenants' resource + in which an API client might try and find out other projects' resource identifiers by sending out ``PUT`` and ``DELETE`` requests for random resource identifiers. * There is no way at the moment to specify an ``OR`` relationship between two diff --git a/doc/source/devref/quota.rst b/doc/source/devref/quota.rst index a32b12de326..af0ff2fc920 100644 --- a/doc/source/devref/quota.rst +++ b/doc/source/devref/quota.rst @@ -29,10 +29,10 @@ The Neutron API exposes an extension for managing such quotas. Quota limits are enforced at the API layer, before the request is dispatched to the plugin. Default values for quota limits are specified in neutron.conf. Admin users -can override those defaults values on a per-tenant basis. Limits are stored -in the Neutron database; if no limit is found for a given resource and tenant, +can override those defaults values on a per-project basis. Limits are stored +in the Neutron database; if no limit is found for a given resource and project, then the default value for such resource is used. -Configuration-based quota management, where every tenant gets the same quota +Configuration-based quota management, where every project gets the same quota limit specified in the configuration file, has been deprecated as of the Liberty release. @@ -71,10 +71,10 @@ component handles quota enforcement. This API extension is loaded like any other extension. For this reason plugins must explicitly support it by including "quotas" in the support_extension_aliases attribute. -In the Quota API simple CRUD operations are used for managing tenant quotas. -Please note that the current behaviour when deleting a tenant quota is to reset -quota limits for that tenant to configuration defaults. The API -extension does not validate the tenant identifier with the identity service. +In the Quota API simple CRUD operations are used for managing project quotas. +Please note that the current behaviour when deleting a project quota is to reset +quota limits for that project to configuration defaults. The API +extension does not validate the project identifier with the identity service. Performing quota enforcement is the responsibility of the Quota Engine. RESTful API controllers, before sending a request to the plugin, try to obtain @@ -84,7 +84,7 @@ operation to the plugin. For a reservation to be successful, the total amount of resources requested, plus the total amount of resources reserved, plus the total amount of resources -already stored in the database should not exceed the tenant's quota limit. +already stored in the database should not exceed the project's quota limit. Finally, both quota management and enforcement rely on a "quota driver" [#]_, whose task is basically to perform database operations. @@ -99,25 +99,25 @@ controller class [#]_. This class does not implement the POST operation. List, get, update, and delete operations are implemented by the usual index, show, update and delete methods. These method simply call into the quota driver for either -fetching tenant quotas or updating them. +fetching project quotas or updating them. The _update_attributes method is called only once in the controller lifetime. This method dynamically updates Neutron's resource attribute map [#]_ so that an attribute is added for every resource managed by the quota engine. Request authorisation is performed in this controller, and only 'admin' users -are allowed to modify quotas for tenants. As the neutron policy engine is not +are allowed to modify quotas for projects. As the neutron policy engine is not used, it is not possible to configure which users should be allowed to manage quotas using policy.json. The driver operations dealing with quota management are: * delete_tenant_quota, which simply removes all entries from the 'quotas' - table for a given tenant identifier; - * update_quota_limit, which adds or updates an entry in the 'quotas' tenant for - a given tenant identifier and a given resource name; - * _get_quotas, which fetches limits for a set of resource and a given tenant + table for a given project identifier; + * update_quota_limit, which adds or updates an entry in the 'quotas' project + for a given project identifier and a given resource name; + * _get_quotas, which fetches limits for a set of resource and a given project identifier - * _get_all_quotas, which behaves like _get_quotas, but for all tenants. + * _get_all_quotas, which behaves like _get_quotas, but for all projects. Resource Usage Info @@ -238,12 +238,12 @@ Reservations are committed or cancelled by respectively calling the commit_reservation and cancel_reservation methods in neutron.quota.QuotaEngine. Reservations are not perennial. Eternal reservation would eventually exhaust -tenants' quotas because they would never be removed when an API worker crashes +projects' quotas because they would never be removed when an API worker crashes whilst in the middle of an operation. Reservation expiration is currently set to 120 seconds, and is not configurable, not yet at least. Expired reservations are not counted when calculating resource usage. While creating a reservation, if any expired -reservation is found, all expired reservation for that tenant and resource +reservation is found, all expired reservation for that project and resource will be removed from the database, thus avoiding build-up of expired reservations. diff --git a/doc/source/devref/security_group_api.rst b/doc/source/devref/security_group_api.rst index 72bc3977b0e..802f7dbd53d 100644 --- a/doc/source/devref/security_group_api.rst +++ b/doc/source/devref/security_group_api.rst @@ -30,7 +30,7 @@ https://wiki.openstack.org/wiki/Neutron/SecurityGroups API Extension ------------- -The API extension is the 'front' end portion of the code, which handles defining a `REST-ful API`_, which is used by tenants. +The API extension is the 'front' end portion of the code, which handles defining a `REST-ful API`_, which is used by projects. .. _`REST-ful API`: https://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/securitygroup.py @@ -46,7 +46,7 @@ The Security Group API extension adds a number of `methods to the database layer Agent RPC --------- -This portion of the code handles processing requests from tenants, after they have been stored in the database. It involves messaging all the L2 agents +This portion of the code handles processing requests from projects, after they have been stored in the database. It involves messaging all the L2 agents running on the compute nodes, and modifying the IPTables rules on each hypervisor. diff --git a/doc/source/devref/services_and_agents.rst b/doc/source/devref/services_and_agents.rst index fcb9fa714d7..13fb12fe5ef 100644 --- a/doc/source/devref/services_and_agents.rst +++ b/doc/source/devref/services_and_agents.rst @@ -32,7 +32,7 @@ services. Among those of special interest: #. neutron-server that provides API endpoints and serves as a single point of access to the database. It usually runs on nodes called Controllers. #. Layer2 agent that can utilize Open vSwitch, Linuxbridge or other vendor - specific technology to provide network segmentation and isolation for tenant + specific technology to provide network segmentation and isolation for project networks. The L2 agent should run on every node where it is deemed responsible for wiring and securing virtual interfaces (usually both Compute and Network nodes). diff --git a/doc/source/policies/bugs.rst b/doc/source/policies/bugs.rst index 34cb64ebb13..3912a10a066 100644 --- a/doc/source/policies/bugs.rst +++ b/doc/source/policies/bugs.rst @@ -199,7 +199,7 @@ following these suggestions: the 'why' is important, but can be omitted if obvious (not to you of course). * Pre-conditions: what is the initial state of your system? Please consider enumerating resources available in the system, if useful in diagnosing - the problem. Who are you? A regular tenant or a super-user? Are you + the problem. Who are you? A regular user or a super-user? Are you describing service-to-service interaction? * Step-by-step reproduction steps: these can be actual neutron client commands or raw API requests; Grab the output if you think it is useful.