Serving: kbuffer rename breaks updating

[mattmoor]

/assign @tcnghia @josephburnett

I just pulled in the kbuffer change, and it left around the activator deployment. This needs work, but what worries me more is that every Revision's Deployment (which we don't reconcile) is pushing traffic to the wrong service name.

We need to rollback this change, unless our confidence is 100% that we'll land the kbuffer change before 0.3.

[josephburnett]

cc: @vvraskin

[josephburnett]

How should we proceed?

We could this:

1. change the pod and service labels back to "activator" but leave the rest of the rename.
2. open an issue to rename the labels to "kbuffer" and reconcile deployments.
3. cleanup the activator deployment. cc @jonjohnsonjr who has been working on upgrade testing. Any idea how we could do this?

[josephburnett]

Chatting with @akyyy I think that we should just rollback the rename. I'll put out some pull requests.

[vvraskin]

Just had a private chat with Joe, we could revert it if its urgent. However, if the timing is ok, I could take a look or consult with @jonjohnsonjr on the solution.
To be honest I'm still laking knowledge in the field of isio - so cannot propose a proper solution right now.

[josephburnett]

The solution touches on a number of things. Istio routing, deployment reconciling, cleaning up system resources ("activator" deployment). We do need to figure that stuff out. But maybe not yet. I think that I just jumped the gun here on the rename.

Besides, @tcnghia is working on replacing / moving the activator with an Envoy filter. So we might skip the rename if that works out.