[jira] [Resolved] (YUNIKORN-1627) Admission controller triggers infinite recreation of ReplicaSet objects

["Craig Condit (Jira)" <ji...@apache.org>]

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

Craig Condit resolved YUNIKORN-1627.
------------------------------------
    Fix Version/s: 1.3.0
       Resolution: Fixed

Merged to master.

> Admission controller triggers infinite recreation of ReplicaSet objects
> -----------------------------------------------------------------------
>
>                 Key: YUNIKORN-1627
>                 URL: https://issues.apache.org/jira/browse/YUNIKORN-1627
>             Project: Apache YuniKorn
>          Issue Type: Bug
>          Components: shim - kubernetes
>    Affects Versions: 1.2.0
>            Reporter: Craig Condit
>            Assignee: Peter Bacsko
>            Priority: Critical
>              Labels: pull-request-available
>             Fix For: 1.3.0
>
>
> YUNIKORN-1338 added support in the admission controller for mutating workload objects other than Pods for the purposes of user tracking (and eventual enforcement). This functionality works as designed.
> However, in the case where a ReplicaSet is managed by a Deployment, the changes to the ReplicaSet pod template trigger the associated Deployment to recreate the ReplicaSet without the changes, which the admission controller then updates, triggering another ReplicaSet, etc. ad infinitum. 
> The workaround for now is to set the following in the {{yunikorn-configs}} ConfigMap, which disables the functionality:
> {code:java}
> admissionController.accessControl.bypassAuth: "true"{code}
> The real fix needs to take into account any {{ownerReference}} in a workload which points to another workload type that we manage. This definitely includes ReplicaSet -> Deployment, but could include other workload relationships (more investigation needed on this).
> For ReplicaSets, if the ownerReference is set to a Deployment, it should be sufficient to check for that and assume that the Deployment itself has passed in the appropriate user information due to the admission controller having mutated the Deployment.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: dev-help@yunikorn.apache.org