yangwwei commented 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. ---------------------------------------------------------------- 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]
