README.md: Update

- Add Prometheus Rule CRD
- Update development/testing section
- Remove `v0.1.0` migration section

README.md

@@ -42,33 +42,6 @@ Prometheus Operator, it is highly recommended to use the latest version.
 If you have an older version of Kubernetes and the Prometheus Operator running,
 we recommend upgrading Kubernetes first and then the Prometheus Operator.
 
-If you have previously used pre-1.5.0 releases of Kubernetes with the `0.1.0` 
-version of the Prometheus Operator, see the [migration](#migration) section.
-
-## Migration
-
-The `PetSet` was deprecated in the `1.5.0` release of Kubernetes in favor of
-the `StatefulSet`. As the Prometheus Operator used the `PetSet` in version
-`0.1.0`, those need to be migrated as we upgrade our Kubernetes cluster as well
-as the Prometheus Operator.
-
-First the Prometheus Operator needs to be shut down. Once shut down, retrieve 
-the `PetSet`s that were generated by it. You can do so simply by finding all
-`Prometheus` and `Alertmanager` objects created:
-
-```sh
-kubectl get prometheuses --all-namespaces
-kubectl get alertmanagers --all-namespaces
-```
-
-For each `Prometheus` and `Alertmanager` object, a respective `PetSet` with the
-same name was created in the same namespace. Those `PetSet`s need to be
-migrated according to the [official migration documentation](http://kubernetes.io/docs/tasks/manage-stateful-set/upgrade-pet-set-to-stateful-set/).
-
-Once migrated and on Kubernetes version `>=1.5.0`, you can start the
-Prometheus Operator of version `>=0.2.0`, and the `StatefulSet` created
-in the migration will from now on be managed by the Prometheus Operator.
-
 ## CustomResourceDefinitions
 
 The Operator acts on the following [custom resource definitions (CRDs)](https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/):
@@ -80,6 +53,10 @@ The Operator acts on the following [custom resource definitions (CRDs)](https://
   of services should be monitored. The Operator automatically generates Prometheus scrape configuration
   based on the definition.
 
+* **`PrometheusRule`**, which defines a desired Prometheus rule file, which can
+  be loaded by a Prometheus instance containing Prometheus alerting and
+  recording rules.
+
 * **`Alertmanager`**, which defines a desired Alertmanager deployment.
   The Operator ensures at all times that a deployment matching the resource definition is running.
 
@@ -144,10 +121,14 @@ kubectl delete --ignore-not-found customresourcedefinitions \
 
 ### Testing
 
-1. Ensure that you're running tests in the following path: `$GOPATH/src/github.com/coreos/prometheus-operator` as tests expect paths to match.
-  1. If you're working from a fork, just add the forked repo as a remote and pull against your local coreos checkout before running tests.
-1. `make test` executes all *unit tests*.
-2. You can execute the *e2e tests* on a local minikube by compiling the static binary (which is what is used for the container images) with `make crossbuild`.
-  1. build the container image with the docker host from within minikube by running `eval $(minikube docker-env)`.
-  2. You can build the container images using `make image`.
-  3. Finally run the e2e tests using `make e2e-test`.
+> Ensure that you're running tests in the following path:
+> `$GOPATH/src/github.com/coreos/prometheus-operator` as tests expect paths to
+> match. If you're working from a fork, just add the forked repo as a remote and
+> pull against your local coreos checkout before running tests.
+
+1. Running *unit tests*:
+  1. `make test-unit`
+1. Running *end-to-end* tests on local minikube cluster:
+  1. `minikube start --kubernetes-version=v1.10.0 --memory=4096 --extra-config=apiserver.Authorization.Mode=RBAC`
+  2. `eval $(minikube docker-env) && make image` - build Prometheus Operator docker image on minikube's docker
+  3. `make test-e2e`