diff --git a/specs/mitaka/api-microversions.rst b/specs/mitaka/api-microversions.rst index 45cdc6fb..5e2ab115 100644 --- a/specs/mitaka/api-microversions.rst +++ b/specs/mitaka/api-microversions.rst @@ -71,11 +71,11 @@ Use Cases Proposed change =============== -Cinder will use a framework we will call ‘API Microversions’ for allowing +Cinder will use a framework we will call 'API Microversions' for allowing changes to the API while preserving backward compatibility. The basic idea is that a user has to explicitly ask for their request to be treated with a particular version of the API. So breaking changes can be added to the API -without breaking users who don’t specifically ask for it. This is done with +without breaking users who don't specifically ask for it. This is done with an HTTP header X-OpenStack-Cinder-API-Version which is a monotonically increasing semantic version number starting from 2.1. diff --git a/specs/ocata/ha-aa-job-distribution.rst b/specs/ocata/ha-aa-job-distribution.rst index 57e6cd2e..cd836230 100644 --- a/specs/ocata/ha-aa-job-distribution.rst +++ b/specs/ocata/ha-aa-job-distribution.rst @@ -168,7 +168,7 @@ on where to perform operations. In a similar way to the Service state reporting we need to prevent concurrent access to the data structure when updating this information. Fortunately for us we are storing this information in a Python dictionary on the schedulers, and -since we are using an eventlet executor for the RPC server we don’t have to +since we are using an eventlet executor for the RPC server we don't have to worry about using locks, the inherent behavior of the executor will prevent concurrent access to the dictionary. So no changes are needed there to have exclusive access to the data structure. diff --git a/specs/queens/v3-api-validation.rst b/specs/queens/v3-api-validation.rst index 9ef12527..29201c2b 100644 --- a/specs/queens/v3-api-validation.rst +++ b/specs/queens/v3-api-validation.rst @@ -171,7 +171,7 @@ each API method in ad-hoc. These changes would make the API method code dirty and we needed to create multiple patches due to incomplete validation. If using JSON Schema definitions instead, acceptable request formats are clear -and we don’t need to do ad-hoc works in the future. +and we don't need to do ad-hoc works in the future. Pecan Framework: `Pecan `_