There's basically 1 java driver in the C* ecosystem. We have 3? 4? or more operators in the ecosystem. Has one of them hit a clear supermajority of adoption that makes it the de facto default and makes sense to pull it into the project?
We as a project community were pretty slow to move on building a PoV around kubernetes so we find ourselves in a situation with a bunch of contenders for inclusion in the project. It's not clear to me what heuristics we'd use to gauge which one would be the best fit for inclusion outside letting community adoption speak. --- Josh McKenzie Sent via Superhuman <https://sprh.mn/?vip=jmcken...@apache.org> On Thu, Sep 10, 2020 at 10:58 AM, <franck.de...@orange.com> wrote: > Hi, > > Thanks John for your efforts in setting up the repo and in the SIG > meetings in general :) > > As the team already in charge for CasKop, we did not participate in the > code in your repo for different reasons: > - we never said we would. We discussed the CRD in the SIG meetings and our > objective was to check whether CassKop’s choice were good or not, and they > were good most of the times. > - we were finishing V1 of CassKop with backup and restore functionalities. > This is almost done, we are merging it as I am writing this. > - we want to offer CassKop to the community when V1 is released as working > code if it wants it. I mentioned this a few times in the videos so this is > no news. > > An operator is a big work, don’t underestimate it! > > We believe not starting from scratch is better but this is only our > opinion. Should I go formal on this offer and have a dedicated thread as > was done for the drivers? > > Sincerely hope this helps > Franck > Product Owner of CassKop @ Orange > https://github.com/Orange-OpenSource/casskop > (Yes we’ll fix the vulnerability once the big merge is done :) ) > > On 10 Sep 2020, at 05:10, John Sanda <john.sa...@gmail.com> wrote: > > Hey everyone, > > A while back I started https://github.com/jsanda/cassandra-operator in an > effort to move things forward. One of my primary goals was to get some > people contributing. That did not happen, which is understandable. I am > going to throw out some questions and would love to get feedback, > particularly from people who have been participating in the SIG and/or are > involved with relevant projects. > > * Should we continue down the path of trying to build a common operator > project? If yes, how should we proceed? > > * Should we broaden the focus to using and running Cassandra in Kubernetes > in general? CEP 2 Kubernetes Operator > <https://cwiki.apache.org/confluence/display/CASSANDRA/ > CEP-2+Kubernetes+Operator> says > that its motivation is to make it easy to run Cassandra on Kubernetes. > Having an operator is definitely a big part of that, but it is not the only > part. There are important areas like application development, data > migration, multi-region / multi-cloud clusters, and tooling integration to > name a few. I think that the community benefits from collaboration > regardless of whether or not there is a common operator. That is not to > suggest that a common operator would not be good. I do not necessarily see > it as a zero sum game where it has to be a common operator or nothing. > > Thanks > > - John > > _________________________________________________________________________________________________________________________ > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message par > erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. If you have received this email in > error, please notify the sender and delete this message and its > attachments. As emails may be altered, Orange is not liable for messages > that have been modified, changed or falsified. Thank you. >
