Hi Deepak, During the last SIG meetings, both repair and backup/restore were discussed in the context of lifecycle management. The Instaclustr operator already has backup/restore capabilities which are documented here <http://Instaclustr operator> (in full disclosure, I have never used the operator, just aware of the feature). Medusa <https://github.com/thelastpickle/cassandra-medusa> is another possibility. There have been a couple discussions in tickets in the medusa repo. Just wanted to point out that it is definitely on the radar.
On Thu, Apr 30, 2020 at 12:41 PM Deepak Vohra <dvohr...@yahoo.com.invalid> wrote: > Updated CEP-2: > Without involving advanced automation that could involve resources > specific to Cloud Service provider, the following could be added. > - Automatic backup and restore operations- Role-based access control > (RBAC) Automated Security Management- Automated Monitoring Through > Prometheus > thanks,Deepak > On Monday, April 27, 2020, 04:33:45 p.m. UTC, Stefan Miklosovic < > stefan.mikloso...@instaclustr.com> wrote: > > Hi Deepak, > > while we would be delighted to take Instaclustr's operator as a > baseline, this is not so simple ... > > I think we should gather all functional requirements first, improve > and complete the actual CEP and based on these facts we should distil > the best solution, whatever it would be. > > In general, I do not want this whole operator effort to be about "ours > or theirs" and "who wins", it should be done _together_. My take on > this as of now is that let's forget about all operators and let's > pretend we just want to build a new one. Based on what operator we > want to have, after that we will look around and make some comparison > to see what is already available among all operators out there. Based > on that, we could cherry-pick features and approaches from each or > introduce some completely different and only after that we would start > to think about the implementation. I think we are just at the very > beginning and I do not think that mentioning whatever operator at this > moment is a good idea (but I am glad you are interested!). > > How does this sound to you? Do you think that you could be helpful > with going through the CEP Patrick has compiled while adding more > details and features you would like to see? That would be of > tremendous help and we would know more in detail what we actually want > and we can discuss it in more detail afterwards. > > Regards and thanks a lot in advance > > On Mon, 27 Apr 2020 at 17:16, Deepak Vohra <dvohr...@yahoo.com.invalid> > wrote: > > > > An operator for Apache Cassandra in alpha is provided by Instaclustr > that supports StatefulSet, scaling and monitoring. Could it be used as the > base operator to build on? OperatorHub.io | The registry for Kubernetes > Operators > > > > | > > | > > | | > > OperatorHub.io | The registry for Kubernetes Operators > > > > The registry for Kubernetes Operators > > | > > > > | > > > > | > > > > > > > > > > > > On Monday, April 27, 2020, 05:49:37 a.m. UTC, Patrick McFadin < > pmcfa...@gmail.com> wrote: > > > > *Hi everyone,Over the past two weeks, we have had 4 public meetings > with a > > lot of great discussions. You can find the recordings and notes here: > > > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG > > < > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG > >There > > were some important next steps after this week. First is some > housekeeping. > > Having two meetings allowed for better time zone spread, but the > > discussions were disconnected and tended to be somewhat redundant. It was > > suggested to move to a single meeting that can span the most timezones. I > > took that feedback and have rebuilt the SIG meeting schedules in the same > > type of rotation being used for the Contributor Meetings. We’ll see how > > that goes for everyone effected. I’ve also switched away from Zoom to > Jitsi > > (jitsi.org <http://jitsi.org>). Switching to a more open video > conferencing > > software seemed like a natural move and the feature list is comparable to > > Zoom.All the meeting details and schedule are posted here: > > > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG > > < > https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG > >This > > includes a calendar file and shared calendar link. Next important thing > is > > the beginning of the CEP for the Kubernetes Operator. Ben Bromhead and I > > took a first pass at a skeleton for CEP-2 > > < > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-2+Kubernetes+Operator > > > > with all the basics. At this point, we need everyone participating in the > > project to take some time and help build out some of the critical > details. > > Because everyone loves Confluence so much, I have created a Google doc we > > can use as a working area before moving over to a more formal Cassandra > > Wiki. > > > https://docs.google.com/document/d/18Ow4R3tB9GIvdcFO7WmUvjb0a-sT6h0zSCEnfHsPz58/edit?usp=sharing > > < > https://docs.google.com/document/d/18Ow4R3tB9GIvdcFO7WmUvjb0a-sT6h0zSCEnfHsPz58/edit?usp=sharing > >Everyone > > has edit rights. Please use the comment functionality if you have > questions > > about a particular section.The main portion that really needs the most > > thoughtful work is Operator Capability Level > > < > https://github.com/operator-framework/operator-sdk/blob/master/doc/operator-capabilities.md > >. > > What does each level mean in Cassandra terms. There was already some good > > debate about configuration and common tasks like repair. Let’s get that > > captured in the doc if we can. If you are one of the groups that already > > have an operator, your experience here is invaluable. Please take some > time > > of you can. Thanks and looking forward to the collaboration. Patrick* > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > -- - John
