Serving: Downward API Release 0.7

[vtereso]

KService Pod Templating

As mentioned here, "We cannot inline PodSpec until 0.7". However right below this, the RevisionSpec uses this PodSpec definition. Is this meant to say that the PodSpec will be replaced or "inlined" with corev1.PodSpec in 0.7? Otherwise, will there be support for the Downward API like the following:

- name: INSTALLED_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace

within the container definition on the KService.

/area API

/area autoscale
/area build
/area monitoring
/area networking
/area test-and-release

Ask your question here:

[vtereso]

@mattmoor Can you explain this comment?

[dgerd]

The comment in the code refers to constraints in json serialization. The PodSpec is re-defined so that omitempty can be added to the json parsing logic on line 103. Adding omitempty allows clients to interact with multiple versions of knative without breaking. This comment is not related to the downward API.

That said we are beginning to take a closer look at the downward API and the best way to offer it in Knative without breaking the serverless abstraction. Many of the fields offered are definitely useful for many applications (such as namespace); however, some of them (such as pod name) start to create a leaky abstraction and may result in reliance on implementation details.

[vtereso]

Ok, my misunderstanding as to the intent of inline, but that makes perfect sense. Your explanation of using the Knative specific Podspec seems to use circular logic (at least from my perspective) where it must allow omitempty to support old versions, but why was it ever replaced to begin with? Having a PodSpec without containers doesn't seem useful, but I'm sure there are reasons I guess. To close, is there a Knative approach to achieving the namespace (since the Downward API is no go)? For my use case, the Kubernetes library is not imported and was hoping it didn't have to be a static value in the service definition.

[dgerd]

Ok, my misunderstanding as to the intent of inline, but that makes perfect sense. Your explanation of using the Knative specific Podspec seems to use circular logic (at least from my perspective) where it must allow omitempty to support old versions, but why was it ever replaced to begin with?

The long story short is that from 0.5 to 0.6 we added our v1beta1 API alongside our existing v1alpha1 API. v1alpha1 supports Container and v1beta1 supports PodSpec. This means that you must specify one of Container OR PodSpec. As PodSpec is a OneOf type field it must be optional. As older clients do not understand the v1beta1 PodSpec it should be serialized as missing instead of null hence the need for omitempty.

To close, is there a Knative approach to achieving the namespace (since the Downward API is no go)? For my use case, the Kubernetes library is not imported and was hoping it didn't have to be a static value in the service definition.

We do not have an easy way to get the namespace in 0.6. I created an issue that provides more details and tracks the Downward API: https://github.com/knative/serving/issues/4190. It would be helpful if you wanted to add your use-case there.

[vtereso]

Will do. Thanks for the replies.