On Fri, Sep 7, 2018 at 5:03 PM Jonathan Haddad <j...@jonhaddad.com> wrote: > > We haven’t even defined any requirements for an admin tool. It’s hard to > make a case for anything without agreement on what we’re trying to build. > We were/are trying to sketch out scope/requirements in the #14395 and #14346 tickets as well as their associated design documents. I think the general proposed direction is a distributed 1:1 management sidecar process similar in architecture to Netflix's Priam except explicitly built to be general and pluggable by anyone rather than tightly coupled to AWS.
Dinesh, Vinay and I were aiming for low amounts of scope at first and take things in an iterative approach with just enough upfront design but not so much we are unable to make any progress at all. For example maybe something like: 1. Get a super simple and non controversial sidecar process that ships with Cassandra and exposes a lightweight HTTP interface to e.g. some basic JMX endpoints 2a. Add a pluggable execution engine for cron/oneshot/scheduled jobs with the basic interfaces and state store and such 2b. Start scoping and implementing the full HTTP interface, e.g. backup status, cluster health status, etc ... 3a. Start integrating implementations of the jobs from 2a such as snapshot, backup, cluster restart, daemon + sstable upgrade, repair, etc 3b. Start integrating UI components that pair with the HTTP interface from 2b 4. ?? Perhaps start unlocking next generation operations like moving "background" activities like compaction, streaming, repair etc into one or more sidecar contained processes to ensure the main daemon only handles read+write requests There are going to be a lot of questions to answer, and I think trying to answer them all up front will mean that we get nowhere or make unfortunate compromises that cripple the project from the start. If people think we need to do more design and discussion than we have been doing then we can spend more time on the design, but personally I'd rather start iterating on code and prove value incrementally. If it doesn't work out we won't release it GA to the community ... -Joey --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
