yangwwei commented on issue #81: [YUNIKORN-28] Support validating yunikorn-configs before admitting it URL: https://github.com/apache/incubator-yunikorn-k8shim/pull/81#issuecomment-598396970 > This will mean that we cannot change the core config code without updating the shim. When we introduce a new shim which adds some config to the core and we want to deploy the scheduler without the k8shim we cannot. This I disagree. Configs are core side things, even there are 2 shims. the configs should be consistent in core. If we diverse different configs for different shims, that will diverse the core codebase as well. that's something we don't want to run into. Core should be generic. Note, this approach shim doesn't use the configs directly, it only validates it using configs pkg for the core. > I am also wondering where the config volume is if you have no scheduler deployed. This is not a valid case. We certainly don't want the admission-controller running without the scheduler. > Using a service discovery to find the rest interface is a better solution and allows us to really keep any knowledge that does not belong in the admission controller out of it. That's something we can do, but apparently it introduces more complexity. Do you think we should invest resources for this? The admission-controller is an optional deployment, if we need some changes in scheduler's deployment for service discovery, that is not always necessary. > You also need to keep in mind that even if the validate passes the scheduler can still reject the configuration. The config can be valid but the running config might prevent it from being applied, i.e. a leaf queue with running apps cannot be changed into a parent queue, or a placement rule defined in the config might not exist in the code itself. Here is to place a safe-guard that includes all necessary static checks. IIRC, we do refresh the configs once the load is successful. This is consistent. But if it fails sometime later, that's another thing we need to think about.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
