yangwwei edited a comment on pull request #207: URL: https://github.com/apache/incubator-yunikorn-core/pull/207#issuecomment-706408396
hi @wilfred-s the workflow you suggested > GET config make change (keep delta) PUT changed config PUT: OK update checksum, persist config PUT: fail, show message and either go directly back to 1 and let user redo it from scratch or GET config, apply delta Show changed config (delta applied) go back to 2. This is exactly why I thought it is too complex... imagine we are building a service to manage the queue structure where user can modify, track versioning, rollback to a previous version, etc. This service has to maintain the configs, e.g in its DB. Which one will be the source of truth, the configs in DB, or the configs in YK? Looks like you are suggesting using the YK side configs as the source of truth. Then how can the service deal with its own data, or it will be a stateless service? How can they implement version control, and rollback features, etc? All things we want to do is to avoid a harmful update (I agree this is important). But I think such logic could be complex and it should be built outside of YK. But I guess even we get this merged. As long as the client maintains the configs carefully.. we should be fine. Just do not want to get to the point, where the client thinks it is correct, but YK thinks it is not. This is how the whole source-of-truth topic comes from. In most cases, we should be fine, but when we run into such a situation, we know which one to trust and abandon the other one. ---------------------------------------------------------------- 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]
