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 <dvohr...@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 > <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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
