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
