Replace non-ascii symbols in docs

In order to successfully run sphinxcontrib-spelling on Ceilometer docs we need
to replace all non-ascii symbols with the analogous ones from ascii.

Without this fix sphinxcontrib-spelling will fail with:
"UnicodeEncodeError: 'ascii' codec can't encode character u'\u2019'
in position 8: ordinal not in range(128)"

Change-Id: I37891b9471571c3509aece3949d9593738f99849

doc/source/architecture.rst

@@ -30,7 +30,7 @@ community started to realize that a secondary goal could be added to
 Ceilometer: become a standard way to collect metric, regardless of the
 purpose of the collection.  For example, Ceilometer can now publish information for
 monitoring, debugging and graphing tools in addition or in parallel to the
-metering backend. We labelled this effort as “multi-publisher“.
+metering backend. We labelled this effort as "multi-publisher".
 
 .. _increasing number of metrics: http://docs.openstack.org/developer/ceilometer/measurements.html
 
@@ -39,7 +39,7 @@ life, it soon became clear that the OpenStack project needed a tool to watch for
 variations in key values in order to trigger various reactions.
 As Ceilometer already had the tooling to collect vast quantities of data, it
 seemed logical to add this as an extension of the Ceilometer project, which we
-tagged as “alarming“.
+tagged as "alarming".
 
 Metering
 --------
@@ -49,7 +49,7 @@ the telco industry, the steps are:
 
 1. :term:`Metering` is the process of collecting information about what,
    who, when and how much regarding anything that can be billed. The result of
-   this is a collection of “tickets” (a.k.a. samples) which are ready to be
+   this is a collection of "tickets" (a.k.a. samples) which are ready to be
    processed in anyway you want.
 2. :term:`Rating` is the process of analysing a series of tickets,
    according to business rules defined by marketing, in order to transform
@@ -57,10 +57,10 @@ the telco industry, the steps are:
 3. :term:`Billing` is the process to assemble bill line items into a
    single per customer bill, emitting the bill to start the payment collection.
 
-Ceilometer’s initial goal was, and still is, strictly limited to step
+Ceilometer's initial goal was, and still is, strictly limited to step
 one. This is a choice made from the beginning not to go into rating or billing,
 as the variety of possibilities seemed too huge for the project to ever deliver
-a solution that would fit everyone’s needs, from private to public clouds. This
+a solution that would fit everyone's needs, from private to public clouds. This
 means that if you are looking at this project to solve your billing needs, this
 is the right way to go, but certainly not the end of the road for you. Once
 Ceilometer is in place on your OpenStack deployment, you will still have
@@ -79,7 +79,7 @@ but this is fully left up to the implementor.
 
 .. note::
 
-   We do not guarantee that we won’t change the DB schema, so it is
+   We do not guarantee that we won't change the DB schema, so it is
    highly recommended to access the database through the API and not use
    direct queries.
 
@@ -131,12 +131,12 @@ How to access collected data?
 Once collected, the data is stored in a database generally, or in a simple
 file if you do not care about API access and want to do the rest of the
 processing elsewhere. There can be multiple types of
-databases through the use of different database plugins (see the section 
+databases through the use of different database plugins (see the section
 :ref:`which-db`). Moreover, the schema and dictionary of
 this database can also evolve over time. For both reasons, we offer a REST API
 that should be the only way for you to access the collected data rather than
 accessing the underlying database directly. It is possible that the way
-you’d like to access your data is not yet supported by the API. If you think
+you'd like to access your data is not yet supported by the API. If you think
 this is the case, please contact us with your feedback as this will certainly
 lead us to improve the API.
 
@@ -161,7 +161,7 @@ layer, and use the same tools for metering your entire cloud.
 
 Moreover, end users can also :ref:`send their own application centric data <user-defined-data>` into the
 database through the REST API for a various set of use cases (see the section
-“Alarming” later in this article).
+"Alarming" later in this article).
 
 .. _send their own application centric data: ./webapi/v2.html#user-defined-data
 
@@ -216,7 +216,7 @@ version, allows you to set alarms based on threshold evaluation for a collection
 of samples. An alarm can be set on a single meter, or on a combination. For
 example, you may want to trigger an alarm when the memory consumption
 reaches 70% on a given instance if the instance has been up for more than
-10 min. To setup an alarm, you will call :ref:`Ceilometer’s API server <alarms-api>` specifying
+10 min. To setup an alarm, you will call :ref:`Ceilometer's API server <alarms-api>` specifying
 the alarm conditions and an action to take.
 
 Of course, if you are not administrator of the cloud itself, you can only
@@ -235,7 +235,7 @@ There can be multiple form of actions, but two have been implemented so far:
 
 For more details on this, I recommend you to read the blog post by
 Mehdi Abaakouk `Autoscaling with Heat and Ceilometer`_. Particular attention
-should be given to the section “Some notes about deploying alarming” as the
+should be given to the section "Some notes about deploying alarming" as the
 database setup (using a separate database from the one used for metering)
 will be critical in all cases of production deployment.
 
@@ -257,7 +257,7 @@ Since the beginning of the project, a plugin model has been put in place
 to allow for various types of database backends to be used. However, not
 all implementations are equal and, at the time of writing, MongoDB
 is the recommended backend of choice because it is the most tested. Have a look
-at the “choosing a database backend” section of the documentation for more
+at the "choosing a database backend" section of the documentation for more
 details. In short, ensure a dedicated database is used when deploying
 Ceilometer as the volume of data generated can be extensive in a production
 environment and will generally use a lot of I/O.

doc/source/events.rst

@@ -63,7 +63,7 @@ Events from Notifications
 Events are primarily created via the notifications system in OpenStack.
 OpenStack systems, such as Nova, Glance, Neutron, etc. will emit
 notifications in a JSON format to message queue when some notable action is
-taken by that system. Ceilometer will consume such notifications from the
+taken by that system. Ceilometer will consume such notifications from the
 message queue, and process them.
 
 The general philosophy of notifications in OpenStack is to emit any and all
@@ -94,7 +94,7 @@ to Traits, and optional plugins for doing any programmatic translations
 
 The mapping of notifications to events is defined per event_type, which
 can be wildcarded. Traits are added to events if the corresponding fields
-in the notification exist and are non-null. (As a special case, an empty
+in the notification exist and are non-null. (As a special case, an empty
 string is considered null for non-text traits. This is due to some openstack
 projects (mostly Nova) using empty string for null dates.)
 

doc/source/measurements.rst

@@ -96,7 +96,7 @@ network.outgoing.packets.rate  Gauge       packet/s  iface ID  pollster      Ave
 
 At present, most of the Nova meters will only work with libvirt front-end
 hypervisors while test coverage was mostly done based on KVM. Contributors
-are welcome to implement other virtualization backends’ meters or complete
+are welcome to implement other virtualization backends' meters or complete
 the existing ones.
 
 Network (Neutron)