yunikorn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] [incubator-yunikorn-k8shim] yangwwei commented on issue #81: [YUNIKORN-28] Support validating yunikorn-configs before admitting it
Date Thu, 12 Mar 2020 20:14:47 GMT
yangwwei commented on issue #81: [YUNIKORN-28] Support validating yunikorn-configs before admitting
   > 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
   > 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:

With regards,
Apache Git Services

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message