Current Behavior
A Service in Release Mode currently takes revision name(s) as input to the Spec to determine where to route traffic. However, since the service is responsible for creating the configuration there is a bootstrapping problem. A revision name is not known until the service creates it, but a revision name is required to create a Service in this mode.
To get around this restriction there are two patterns that are used in 0.2:
- Create the Service in "runLatest", observe the revision name, and then update to "release"
- Know that the first revision name is "${SERVICE_NAME}-00001", and pass that as input
Neither patterns are desirable. The first pattern has the disadvantage of requiring a create and update to achieve the desired state, and requires increased knowledge of Knative move through the required steps.
The pattern of putting non-existent revisions in the list creates a race condition between the update of the route and the creation of the revision which is not handled by the Service. This can lead to unexpected failures. In addition, the second pattern requires the user to know the naming convention, and may result in hardcoding a convention that is not currently covered by the runtime spec.
Proposal
This proposal was discussed at the 2018/12/05 API Work Group meeting.
I propose the introduction of sentinel values in the "revisions" list to allow a user to reference the latest created Revision without knowing the name. Future variables could be added to extend the functionality, but a single sentinel value (i.e. "@latestRevision" ) would be all that is currently required. Sentinel values can be denoted by a prefix sigil that is outside of the Kubernetes naming convention. This allows for the namespace of sentinel values to not conflict with valid revision names.
Other considered options can be seen in the document linked below.
The biggest advantages of this approach over others is that:
- The action of the user is very explicit
- It brings up the service into a "Ready" state
- It is extensible and usable outside of Service creation.
Additional Info
Original Proposal Document (Shared with knative-users@ and knative-dev@)
Current Behavior
A Service in Release Mode currently takes revision name(s) as input to the Spec to determine where to route traffic. However, since the service is responsible for creating the configuration there is a bootstrapping problem. A revision name is not known until the service creates it, but a revision name is required to create a Service in this mode.
To get around this restriction there are two patterns that are used in 0.2:
Neither patterns are desirable. The first pattern has the disadvantage of requiring a create and update to achieve the desired state, and requires increased knowledge of Knative move through the required steps.
The pattern of putting non-existent revisions in the list creates a race condition between the update of the route and the creation of the revision which is not handled by the Service. This can lead to unexpected failures. In addition, the second pattern requires the user to know the naming convention, and may result in hardcoding a convention that is not currently covered by the runtime spec.
Proposal
This proposal was discussed at the 2018/12/05 API Work Group meeting.
I propose the introduction of sentinel values in the "revisions" list to allow a user to reference the latest created Revision without knowing the name. Future variables could be added to extend the functionality, but a single sentinel value (i.e. "@latestRevision" ) would be all that is currently required. Sentinel values can be denoted by a prefix sigil that is outside of the Kubernetes naming convention. This allows for the namespace of sentinel values to not conflict with valid revision names.
Other considered options can be seen in the document linked below.
The biggest advantages of this approach over others is that:
Additional Info
Original Proposal Document (Shared with knative-users@ and knative-dev@)