Automatic merge from submit-queue
Use existing uid if one is found
Without this if we create some ingresses we will get eg: a forwarding rule like "foo-uid". Now if we restart
the ingress controller, and while it's down delete the configmap where it stores its uid, it will come back, see an existing ingress, but wrongly record the uid as "empty string". This will cause the ingress to ignore the old forwarding rule, backends etc.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.kubernetes.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.kubernetes.io/reviews/kubernetes/contrib/1363)
<!-- Reviewable:end -->
Automatic merge from submit-queue
Don't clobber backends.
If a parallel ingress controller updates the backend service with another instance group, don't clobber it, just make sure the instance group you put in is there.
Automatic merge from submit-queue
Correctly handle ingress.class in GCE controller
This bug would only get activated when a user has both `ingess.class=gce` and `ingress.class=nginx` ingresses active in the same GCE/GKE cluster, and would manifest as a set of cloud resources created wastefully for the `ingress.class=nginx` ingress as well.
We were previously only ignoring ingress.class (documented here: https://github.com/kubernetes/contrib/blob/master/ingress/controllers/gce/BETA_LIMITATIONS.md#disabling-glbc) when the ingress was created/deleted/modified. There's a chance another ingress with the correct class results in us entering the `sync` routine and listing all ingresses. The listing routine was not smart enough to ignore `ingress.class=nginx`, so we ended up creating resources for the nginx ingress anyway.
The second commit fixes some of the nginx examples to include a `readiness` probe that is == liveness probe.
Minhan or Girish, whichever one has spare cycles first.
