Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
In what area(s)?
Describe the feature
According to the second paragraph of Meta Requests in Knative Runtime Contract, we should apply default
We do have something here. Some areas where this doesn't match well with the description:
I think we could go either way on whether to update the contract, or to update the implementation for each of these things. I do however want to make them consistent.
This change makes numerous cleanups to the runtime contract in an attempt to improve the readability of the document and make the document more useful for the intended auidence. * Moves developer facing statements to a new `runtime-user-guide`. Focuses `runtime-contract` on operator/platform-provider. * Add links to Conformance tests that test Runtime Contract statements. * Corrects, updates, or removes statements to more accurately represent today's Knative runtime. * Updates to informative or removes most untestable statements * Copies in important OCI runtime requirements we previously referenced * Removes reference to OCI specification that didn't bring new requirements. Ref: knative#2539, knative#2973, knative#4014, knative#4027
After discussion in the API working group meeting, this is my understanding of where we landed. Please correct if I missed something or misunderstood.
On the contract/specification side:
On the implementation side:
I've run into some questions about how to translate a RevisionSpec's probes over into something we'd want to execute from the queue-proxy against the user-container.
At present, our hardcoded readinessProbe will make a GET request to the queue-proxy, which then fires TCP probes at the user-container at 50 ms intervals. This gives us the chance to pick up the user-container as soon as possible. This 50ms could be the "platform-specific"
@dgerd pointed out that
Sidenote: there is a comment where we build the default probe in the queue-proxy that suggests we want to get the PreStop going as soon as possible. Given that the
* prepare queue healthHandler for optional aggressive retries #4014 Co-authored-by: Shash Reddy <firstname.lastname@example.org> * add documentation for IsHTTPProbeReady Co-authored-by: Shash Reddy <email@example.com> * Address comments * add kubelet header to http probe, add status code to failed probe error * use kubelet user-agent in http probe Co-authored-by: Shash Reddy <firstname.lastname@example.org>
* Prep for queue health handler for aggressive retries #4014 This PR builds the adapter which converts a user-defined probe to a probe that will be executed by queue proxy against user container. Co-authored-by: Shash Reddy <email@example.com> * Address golang linter comments * fix comment Co-authored-by: Shash Reddy <firstname.lastname@example.org> * return probe encoding error * factor out queue probe retry logic, clean up Co-authored-by: Shash Reddy <email@example.com>