You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cassandra.apache.org by Patrick McFadin <pm...@gmail.com> on 2020/04/27 05:49:11 UTC

4-26-2020 update on Kubernetes Operator

*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*

Re: 4-26-2020 update on Kubernetes Operator

Posted by Eric Evans <ee...@wikimedia.org>.

On Mon, Apr 27, 2020 at 2:30 AM Dinesh Joshi <dj...@apache.org> wrote:

> Hi Patrick,
>
> Thanks for driving the meetings. It would be good to have the on going
> discussions on the dev list for people in time zones that cannot attend the
> meetings in real time.
>

+1

I would never (try to) tell anyone that they cannot teleconference with
like-minded peers, but it feels worth mentioning that this format will
never be totally inclusive.



> > On Apr 26, 2020, at 10:49 PM, Patrick McFadin <pm...@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
>
>

-- 
Eric Evans (he/him)
Senior Software Engineer, Core Platform
Wikimedia Foundation
eevans@wikimedia.org

Re: 4-26-2020 update on Kubernetes Operator

Posted by Dinesh Joshi <dj...@apache.org>.

Hi Patrick,

Thanks for driving the meetings. It would be good to have the on going discussions on the dev list for people in time zones that cannot attend the meetings in real time.

Dinesh

> On Apr 26, 2020, at 10:49 PM, Patrick McFadin <pm...@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

Re: 4-26-2020 update on Kubernetes Operator

Posted by Stefan Miklosovic <st...@instaclustr.com>.

Hi Deepak,

thanks for your contribution.

When it comes to cloud services / different providers, that is
something we could tackle with some (simple) "test suite" against all
main clouds, yes. However, from my experience this is not too
critical. It does not differ a lot if you run  your cluster on AWS,
GCP or Azure (mentioning the most used cloud providers). Unless you do
something very specific there are no differences. Some differences are
about how persistent volumes are attached, what permissions have to be
there and what storage classes to use etc, yes, this is "cloud
specific" and relatively easy to handle, however, apart from this, I
would say that there were not any big issues. It was even reported to
me that it run on IBM cloud without any effort on our side so ...
After all, it is Kubernetes which is an abstraction to run services on
so they should be transparently movable from one cloud to another
without anybody noticing a thing.

Testing should be more focused on respective Kubernetes versions.
Operator SDK is using the Kubernetes API of some version. Obviously,
as SDK is being developed, so is the Kubernetes API version it is
pinned-down to updated. From my experience if  you do not use anything
specific and fairly low-level, you can run pretty much the latest
version of Operator SDK against quite old Kubernetes clusters but
there is not any guarantee that things will not start to fail appart
more recent SDK you use.

If we want to do federation between these clouds, that is something I
do not have any experience with whatsoever.

On Tue, 28 Apr 2020 at 04:44, Deepak Vohra <dv...@yahoo.com.invalid> wrote:
>
>  I have added a potential Goal to CEP-2:Deploying and managing Kubernetes resources depends a lot on the Cloud Service provider used. Is it a goal to target  integration with any/all/some Cloud Service providers???
>
>     On Monday, April 27, 2020, 04:33:45 p.m. UTC, Stefan Miklosovic <st...@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 <pm...@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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org

Re: 4-26-2020 update on Kubernetes Operator

Posted by Deepak Vohra <dv...@yahoo.com.INVALID>.

 I have added a potential Goal to CEP-2:Deploying and managing Kubernetes resources depends a lot on the Cloud Service provider used. Is it a goal to target  integration with any/all/some Cloud Service providers???

    On Monday, April 27, 2020, 04:33:45 p.m. UTC, Stefan Miklosovic <st...@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 <pm...@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

Re: 4-26-2020 update on Kubernetes Operator

Posted by 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

Re: 4-26-2020 update on Kubernetes Operator

Posted by Deepak Vohra <dv...@yahoo.com.INVALID>.

 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 <st...@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 <pm...@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

Re: 4-26-2020 update on Kubernetes Operator

Posted by Stefan Miklosovic <st...@instaclustr.com>.

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 <pm...@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

Re: 4-26-2020 update on Kubernetes Operator

Posted by Deepak Vohra <dv...@yahoo.com.INVALID>.

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

The registry for Kubernetes Operators
|

On Monday, April 27, 2020, 05:49:37 a.m. UTC, Patrick McFadin <pm...@gmail.com> wrote: