Revision should manage activation

[mattmoor]

In my opinion, the fact that today Route manages the deactivation of Revisions feels like a layering violation.

In more detail, activation is widely viewed as a feature of Revisions, but today the semantic boundary is that the Revision surfaces inactivity via Active: False, Route(s) referring to inactive Revisions then wire in the activator, and after a grace period the Revision (really KPA) scales the Revision to zero.

However, this means that when inactivate the Revision is Ready: False, which is often a source of confusion, and presents another interesting race (during initial deployment) where the Revision must pass a readinessProbe before it is scaled to zero or the Configuration may never witness its readiness.

I believe that Revision (possibly through the KPA) should manage its own activation.

cc @vaikas-google @evankanderson @tcnghia @grantr @dprotaso for thoughts.

[mattmoor]

I suspect that we want the networking abstractions to land first.

[mattmoor]

cc @tcnghia

[lichuqiang]

There is no doubt about the issue itself. But we might want to see #1583 land first?

[imikushin]

I believe this can be achieved this way:

• Add another k8s-service for each revision, named something like hello-world-01-internal (where hello-world-01 is the revision name) and targeting the revision pods (when/if they exist!) via a label selector
• the activator will proxy to hello-world-01-internal k8s-service instead of hello-world-01 k8s-service
• hello-world-01 k8s-service will become the facade for the revision:
  • when the revision is Active, i.e. has ready pods, hello-world-01 will target the revision pods (via a label selector)
  • when the revision is Inactive, i.e. has no pods, hello-world-01 will target the activator (by changing the service type to ExternalName and pointing to the activator k8s-service)

In this design, it's the job of the revision controller to update the revision facade k8s-service. Route becomes completely activation-agnostic. In fact, it becomes even revision agnostic, because all it cares about is just a k8s-service to hit.

[mattmoor]

This won't provide the activator with enough context to activate the revision. The way we provide this context today is decorating the request with an extra header.

[imikushin]

What component does add the header now?

[mattmoor]

When we change ClusterIngress (backed by Istio) to point at the Activator service, we include rewrite logic to decorate the request with the extra header.

[cppforlife]

i was asking about using host header instead of headers recently in slack. planning to bring this up in upcoming networking call for discussion.

…

Sent from my iPhone

On Oct 29, 2018, at 6:17 PM, Matt Moore ***@***.***> wrote: When we change ClusterIngress (backed by Istio) to point at the Activator service, we include rewrite logic to decorate the request with the extra header. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[imikushin]

/assign

[imikushin]

@cppforlife I've got the same question! Why not use Host header?