Consider using a ReplicaSet in lieu of Deployment for Revision

[vaikas]

When a Revision is created, we create a Deployment. Consider using a ReplicaSet which can scale to 0 instead of using a Deployment.

[josephburnett]

The deployment will come in handy when rolling out security updates to the underlying runtime. We can rebuild the container on the latest runtime and use deployment's surge, max unavailable parameters to slowly replace the container in a revision. I don't think we would want a new revision for that operation.

[mattmoor]

I agree with @josephburnett, closing for now. @vaikas-google feel free to re-open if you want to discuss further.

[grantr]

#497 is easier to implement using a Deployment: set progressDeadlineSeconds and wait for a status update. With a ReplicaSet we have to re-implement progress checking and deadline logic in the revision controller.

[mattmoor]

I think there are a wide variety of other Operator use cases where servicing the underlying image may be made easier by a Deployment than a ReplicaSet.

The one that's been tipping the scales for me has been rebasing images, which is a core scenario for buildpack-style builds. I could see a world where:

1. Revision holds the tag of the image the user wants deployed,
2. Deployment holds the digest of the image at the point where the Revision stamped it out,
3. [external] A servicing event prompts a rebase the tagged image, producing a new digest with the same tag,
4. [external] The digests are swapped in the Deployment triggering a rolling update.

There are other more pedestrian scenarios I could imagine as well: e.g. we service our Revision controller, and the set of sidecars that should be in each pod changes, leading to a Deployment update, which performs a rolling update of the Pods.