Update docs to reflect migration path for 0.3

Author: AMecea

docs/integrate-operator.md

@@ -25,9 +25,8 @@ The MySQL operator provides 3 services to access the nodes:
  * `<cluster_name>-mysql` is the service that routes traffic to all the _healthy_ nodes from the
    cluster. You should use this endpoint for reads.
 
- * `<cluster_name>-mysql-nodes` is the service used internally to access nodes. You can use this
-   service to access a specific node (e.g.
-   `<cluster_name>-mysql-0.<cluster-name>-mysql-nodes.default`)
+ * `mysql` is the service used internally to access all nodes within a namespace. You can use this
+   service to access a specific node (e.g. `<cluster_name>-mysql-0.mysql.<namespace>`)
 
 We use helm to deploy our application into Kubernetes, so we updated our charts to use the MySQL
 operator to provide one cluster per application.

docs/operator-upgrades.md

@@ -13,7 +13,7 @@ aliases: []
 toc: true
 ---
 
-In this section ayou can find the migration path when upgrading to a newer version of the MySQL operator.
+In this section you can find the migration path when upgrading to a newer version of the MySQL operator.
 
 ## v0.2.x upgrade
 
@@ -30,3 +30,16 @@ This upgrade requires a Kubernetes cluster upgrade because the `v0.2.x` works on
 6. Now you can upgrade your nodes, as well.
 7. Enjoy!
 
+
+## v0.3.x upgrade
+
+This version works on Kubernetes grater or equal with `1.11`. The upgrade should be done on staging
+first because it's with downtime. It requires the deletion of the statefulset and recreation of it.
+The reason behind is that we changed the headless service name (which is an invariant statefulset
+field) to make it smaller that will prevent you from hitting this
+[bug](https://github.com/presslabs/mysql-operator/issues/170).
+
+
+The operator should do all the work for you but you have to make sure that you have the latest
+`0.2.x` version of the operator.
+