are there any plans to offer a kubernetes / openshift operator which will be compatible with the fork? or, if not offered by the fork, is there any operator by a 3rd party which is known to support it?
using ECK does not seem to be an option (both from a license point of view and also from a technical point of view, see: Does elastic eck operators support open distro for Elasticsearch).
using an operator gives much more flexibility compared to manually running it (e.g. with helm charts), esp. when it comes to upgrades & scaling.
do you already have some additional information about this operator?
do you know whether it’ll be based on an existing operator (e.g. i’m aware of the one from zalando: zalando-incubator/es-operator) or if it’ll be something new?
will this be ready for the first release of the fork (or already a beta before that)?
Not sure when it will come out, we haven’t started work on it. It would be a fork of an existing operator. The two candidates I have seen are the one you mentioned from Zalando or from RedHat openshift/elasticsearch-operator (github.com)
Here is a Kubernetes Logging Helm chart that both tackles scaling and upgrading problems. It can run from a minikube setup (without a kafka broker) up to scaled out horizontally and vertically cluster setup. The chart is perfect for learning and experimenting but can be leveraged for any further development if needed.
now that OpenSearch is officially out: do you have a timeline for this (at least a timeline for when you’ll start with it)? can the planning & discussion (e.g. selection/evaluation of base for the new operator) be done in the open so that we know who’s working on this and what considerations are going into it and can contribute feedback?
out of interest: i presume that AWS isn’t manually managing their ES (soon: OS?) instances - is their operator (or whatever they’re using) an option as a basis for opensearch? it would of course require AWS to opensource it first (AFAIK it isn’t under a FOSS license / publicly visible yet?)
I tried to get some internal interest in building something. So far the best one I have seen is this one from Zalando. I could reach out and see if they are willing to collaborate on that, but I think we need a stable release before we can think about that.
if you could do that (i presume you have some contacts there?), that’d be great!
i’m not so sure about that: i would presume that - for now at least - the operations aspects of opensearch will stay as they are (and as they were with elasticsearch) - of course with “elasticsearch” renamed to “opensearch” in all the config options & files. since the renaming is already done i’d presume that an operator which gets adapted to work with opensearch now would still work with opensearch 1.0.0?
and i think adoption rate of opensearch would be higher if there’s an operator - maybe i’m wrong, but i’d presume that nowadays most “professional” setups are run on a k8s cluster and there an operator makes live a lot easier. so companies (i presume few here just run their own k8s cluster on their private NAS just for fun? i know that i don’t ) probably used ECK so far and now won’t be able to move to elasticsearch until a new operator is available since ECK won’t work with opensearch. those using managed services obviously are not affected by this (and those running the manged service have their own operator - where i was maybe hoping that somebody might decide to share theirs here).
@jkowall: do you already have specific plans on how you’ll be running opensearch at logz.io? i presume now with elasticsearch you’re either using ECK or possibly ECE (i don’t know your exact setup?
do we have anyone from redhat here in the forum? since you publicly voiced support for opensearch i presume you’ll integrate it in an upcoming release of openshift? if so, do you already have a plan on how you’ll be operating it there? will you continue to use your existing operator (modified for opensearch) with a pure focus on your logging stack or would you be interested in moving to a generic operator which works for all use-cases? (added advantage: anyone running openshift doesn’t need to deal with deploying / upgrading the operator - it’s already packaged by you and we can just set up the custom resources to get the opensearch clusters up & running )
I had contacts there, but they are outdated now. I need to make a new contact. I will ask them.
Today we run ElasticSearch (soon OpenSearch) on EC2 instances, similarly, we run Kafka on but I think in the future we want to move both OpenSearch and Kafka to K8S. We run most of our other services on K8S already today. I doubt we would migrate to OpenSearch and to K8S at once, as this would be a lot of risk for the size of clusters we are running.
There are folks from RedHat I am in touch with. They are using the RedHat Operator for K8S, but they don’t run large customers on OpenShift. I can email them if you would like @ralph. They are also not sure if they want to use OpenSearch longer term as it’s quite heavy and complex to run, but there is not a good alternative right now. They are investigating things like ClickHouse, but of course you’ll give up Kibana with that approach.
Hey Ralph - Amazon Elasticsearch Service for what it is worth manages Elasticsearch directly on EC2. But I am hoping there will be a lot folks with experience using K8S in production that want to work on operators for OpenSearch and OpenSearch Dashboards. That would be great.
just to point it out here: @jkowall has created a ticket with zalando to check if they’re interested in contributing their operator to OpenSearch:
also worth mentioning is the fact that their operator is currently under the MIT license. i’m not sure if this’d be an issue if it were contributed to the project or if they’d have to re-license it under the Apache 2.0 license to avoid license-mixture under the OpenSearch brand?
Maybe it would make sense to base an official OpenSearch operator on ECK (the official Elasticsearch and Kibana operator made by Elastic) (GitHub - elastic/cloud-on-k8s: Elastic Cloud on Kubernetes). I gave it a spin last weekend just with a trivial test on my local machine and it worked great. It was able to scale up and down one data node at a time while keeping cluster health from going red.
The most recent version of it doesn’t have an open source license. But perhaps an older version of it was published with an open source license that could be forked? Or, its design could be used as inspiration?
Sounds like it was never published with an open source license. But what makes it unusable from a technical perspective? It uses StatefulSets right now. Is that problematic?
I have been recently working on K8s. I can pick this up but will be needing an additional hand from the community as I don’t have in depth understanding about OpenSearch.
I am currently working on creating a Helm Chart for OpenSearch. This is helping me understand it better. Once the PR is merged I can start on the operator.
Are you all looking for a Helm based operator or anything specific? I have just completed creation of basic Helm Charts for OpenSearch and OpenSearch Dashboards. @searchymcsearchface@jkowall
I know the RedHat team was asking about a Helm Chart. Personally, I think the operator would be more useful. I really like the Zalando one. I hope we adopt OpenSearch on k8s in the future.
I have already created basic Helm charts for deploying official docker images of OpenSearch and OpenSearch Dashboards[PR is in review]. I will try going through how Zelando have built it and try doing a POC for OpenSearch to kickstart.
we’re not using helm charts for various reasons and have built our own k8s deployment descriptors for now as a quick-win (sorry, nothing i can easily share since it contains various company-internal things as well for our specific way of rolling things out).
we’d want an operator to have all the nice things which it usually brings you: properly managing rolling upgrades (as pointed out in Redirecting… you e.g. need to set some cluster settings before starting it & at the end), auto-scaling, etc. and it’d just in general make our life a lot easier if we can just create a custom resource and then get a full cluster deployed.
i’m still hoping that Zalando can be convinced to move their license to Apache 2.0 so that either their operator can be forked for OpenSearch or that they might also move to OpenSearch themselves and thus the operator itself is directly moved to support OpenSearch.
building a complete new operator from scratch is a lot more effort than re-using their existing, battle-proven operator. and “just having a look” at what they’re doing is a bit of a gray-zone from a legal point of view (different license, so copying would be re-licensing without their approval and also w/o attribution). but i’m no lawyer and hate all things licenses (well, actually by now all things lawyer-related ), just wanted to point out that there’s also a legal component to the whole thing.
) probably used ECK so far and now won’t be able to move to elasticsearch until a new operator is available since ECK won’t work with opensearch. those using managed services obviously are not affected by this (and those running the manged service have their own operator - where i was maybe hoping that somebody might decide to share theirs here).
), just wanted to point out that there’s also a legal component to the whole thing.