Re: 4-26-2020 update on Kubernetes Operator

[John Sanda <jo...@gmail.com>]

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 <dv...@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.miklosovic@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 <dv...@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 <
> pmcfadin@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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>



-- 

- John