Modify grammatical errors

Change-Id: I0f7218fa9299c9c1e7a6d8fb9108159e87967b45

specs/juno/approved/nova-pagination.rst

@@ -178,13 +178,13 @@ returned from a detailed query is a valid sort key.
 Performance data was gathered by running on a simple devstack VM with 2GB
 memory. 5000 instances were inserted into the DB. The data shows that the
 sort time on the main data table is dwarfed (see first table below) when
-running a detailed query -- most of the time is spent querying the the other
+running a detailed query -- most of the time is spent querying the other
 tables for each item; therefore, the impact of the sort key on a detailed
 query is minimal.
 
 For example, the data below compares the processing time of a GET request for
 a non-detailed query to a detailed query with various limits using the default
-sort keys. The purpose of this table is to show the the processing time for a
+sort keys. The purpose of this table is to show the processing time for a
 detailed query is dominated by getting the additional details for each item.
 
 +-------+--------------------+----------------+---------------------------+

specs/kilo/implemented/nova-pagination.rst

@@ -186,13 +186,13 @@ returned from a detailed query is a valid sort key.
 Performance data was gathered by running on a simple devstack VM with 2GB
 memory. 5000 instances were inserted into the DB. The data shows that the
 sort time on the main data table is dwarfed (see first table below) when
-running a detailed query -- most of the time is spent querying the the other
+running a detailed query -- most of the time is spent querying the other
 tables for each item; therefore, the impact of the sort key on a detailed
 query is minimal.
 
 For example, the data below compares the processing time of a GET request for
 a non-detailed query to a detailed query with various limits using the default
-sort keys. The purpose of this table is to show the the processing time for a
+sort keys. The purpose of this table is to show the processing time for a
 detailed query is dominated by getting the additional details for each item.
 
 +-------+--------------------+----------------+---------------------------+

specs/liberty/approved/hyper-v-vtpm-devices.rst

@@ -180,7 +180,7 @@ Contradicting image property and flavor extra spec will result in failing to
 create instance.
 
 Any key data should be stored into Barbican as secrets and create the image
-property ``os_vtpm_keys`` containing the the comma separated references to the
+property ``os_vtpm_keys`` containing the comma separated references to the
 secrets (maximum 6 references, due to a length limitation - maximum 255
 characters), otherwise the instances will be spawned with no data stored in the
 vTPMs. Example value: UUID1,UUID2,UUID3

specs/liberty/implemented/api-relax-validation.rst

@@ -121,7 +121,7 @@ make it more compatible, as mentioned above.
 In addition /v2 endpoint thats powered by the v2.1 code should never accept
 any requests not accepted by /v2, and should only return /v2 like responses.
 Basically, it should always ignore any X-OpenStack-Nova-API-Version
-just like the the v2 code base does today.
+just like the v2 code base does today.
 
 For consistency, /v1.1 will be the same as /v2
 

specs/mitaka/approved/hyper-v-vtpm-devices.rst

@@ -180,7 +180,7 @@ Contradicting image property and flavor extra spec will result in failing to
 create instance.
 
 Any key data should be stored into Barbican as secrets and create the image
-property ``os_vtpm_keys`` containing the the comma separated references to the
+property ``os_vtpm_keys`` containing the comma separated references to the
 secrets (maximum 6 references, due to a length limitation - maximum 255
 characters), otherwise the instances will be spawned with no data stored in the
 vTPMs. Example value: UUID1,UUID2,UUID3

specs/mitaka/approved/os-vif-library.rst

@@ -260,7 +260,7 @@ in the "VIFConfig" class shown earlier. This object corresponds to the
 data that can be provided in the <portprofile>...</portprofile> XML
 block. This is required data when a VIF is connected to OpenVSwitch,
 or when using one of the two VEPA modes. This could have been provided
-inline in the the VIFConfig subclasses, but there are a few cases
+inline in the VIFConfig subclasses, but there are a few cases
 where the same data is needed by different VIF types, so breaking it
 out into a separate object allows better reuse, without increasing
 the number of VIF types.

specs/mitaka/implemented/rbd-instance-snapshots.rst

@@ -207,7 +207,7 @@ To use this in an existing installation with authx, adding 'allow
 rwx pool=images' to nova's ceph user capabilities is necessary. The
 'ceph auth caps' command can be used for this [1]. If these permissions
 are not updated, nova will continue using the existing full copy
-mechanism for instance snapshots because the the fast snapshot will fail
+mechanism for instance snapshots because the fast snapshot will fail
 and nova compute will fall back to the full copy method.
 
 Developer impact

specs/mitaka/implemented/versioned-notification-api.rst

@@ -150,7 +150,7 @@ aggregate.removehost.start, filterscheduler.select_destinations.end.
 The notification model will do basic validation on the content of the
 event_type e.g. enum for valid phases will be created.
 
-The value of the the priority field of the envelope on the wire can be selected
+The value of the priority field of the envelope on the wire can be selected
 from the predefined priorities in oslo.messaging (audit, debug, info, warn,
 error, critical, sample) except 'warning' (use warn instead).
 The notification model will do validation of the priority by providing an enum

specs/newton/implemented/neutron-routed-networks.rst

@@ -180,7 +180,7 @@ Alternatives
 
 One alternative was considered around trying to eliminate races for IP resource
 between Nova and Neutron.  It involved significantly more active maintenance of
-the reserved field on the resource provider and required that the the
+the reserved field on the resource provider and required that the
 allocation was conditionally recorded depending on the scenario.
 
 This method was rejected in favor of the current proposal for its complexity.