[ 
https://issues.apache.org/jira/browse/YUNIKORN-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Craig Condit updated YUNIKORN-2369:
-----------------------------------
    Description: 
YUNIKORN-1273 added support to create unique application IDs instead of 
grouping pods within a given namespace into a single application. However, 
using this feature in combination with the YuniKorn admission controller 
results in a failure to accept pods, as the pod UID (used in the generated 
identifier) has not yet been created when admission controllers run.

For example, given a pod UID of *deadbeefcafe* running in namespace {*}test{*}, 
the expected application ID is {*}test-deadbeefcafe{*}. However, since the pod 
UID is not present when the admission controller runs, this evaluates to 
`test-` and results in the pod being rejected by Kubernetes since labels must 
contain only alphanumeric characters and "-", and must start end end with 
alphanumeric characters.

One way to solve this would be to set the applicationId label in the admission 
controller to something like *test-uniqueautogen* and then have the scheduler 
interpret the presence of the *-uniqueautogen* suffix as a request to use the 
pod UID as part of the name (since it will be available to the scheduler). This 
satisfies the original design of YUNIKORN-1273, which was to make the 
identifiers predictable (since they contain the pod UID), unique (as they still 
are UUIDs) and consistent between restarts of the scheduler. A drawback to this 
approach is that the applicationId label will not reflect the real 
applicationId used.

  was:
YUNIKORN-1273 added support to create unique application IDs instead of 
grouping pods within a given namespace into a single application. However, 
using this feature in combination with the YuniKorn admission controller 
results in a failure to accept pods, as the pod UID (used in the generated 
identifier) has not yet been created when admission controllers run.

For example, given a pod UID of *deadbeefcafe* running in namespace {*}test{*}, 
the expected application ID is {*}test-deadbeefcafe{*}. However, since the pod 
UID is not present when the admission controller runs, this evaluates to 
`test-` and results in the pod being rejected by Kubernetes since labels must 
contain only alphanumeric characters and "-", and must start end end with 
alphanumeric characters.

One way to solve this would be to set the applicationId label in the admission 
controller to something like *test-uniqueautogen* and then have the scheduler 
interpret the presence of the *-uniqueautogen* suffix as a request to use the 
pod UID as part of the name (since it will be available to the scheduler). This 
satisfies the original design of YUNIKORN-1273, which was to make the 
identifiers predictable (since they contain the pod UID), unique (as they still 
are UIDs) and consistent between restarts of the scheduler. A drawback to this 
approach is that the applicationId label will not reflect the real 
applicationId used.


> Using unique generated Application IDs breaks scheduling
> --------------------------------------------------------
>
>                 Key: YUNIKORN-2369
>                 URL: https://issues.apache.org/jira/browse/YUNIKORN-2369
>             Project: Apache YuniKorn
>          Issue Type: Bug
>          Components: shim - kubernetes
>            Reporter: Craig Condit
>            Assignee: Craig Condit
>            Priority: Critical
>
> YUNIKORN-1273 added support to create unique application IDs instead of 
> grouping pods within a given namespace into a single application. However, 
> using this feature in combination with the YuniKorn admission controller 
> results in a failure to accept pods, as the pod UID (used in the generated 
> identifier) has not yet been created when admission controllers run.
> For example, given a pod UID of *deadbeefcafe* running in namespace 
> {*}test{*}, the expected application ID is {*}test-deadbeefcafe{*}. However, 
> since the pod UID is not present when the admission controller runs, this 
> evaluates to `test-` and results in the pod being rejected by Kubernetes 
> since labels must contain only alphanumeric characters and "-", and must 
> start end end with alphanumeric characters.
> One way to solve this would be to set the applicationId label in the 
> admission controller to something like *test-uniqueautogen* and then have the 
> scheduler interpret the presence of the *-uniqueautogen* suffix as a request 
> to use the pod UID as part of the name (since it will be available to the 
> scheduler). This satisfies the original design of YUNIKORN-1273, which was to 
> make the identifiers predictable (since they contain the pod UID), unique (as 
> they still are UUIDs) and consistent between restarts of the scheduler. A 
> drawback to this approach is that the applicationId label will not reflect 
> the real applicationId used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to