Thanks Frank and Christopher.
Sounds like we have a good path to consolidate around!
On Sat, Oct 3, 2020 at 11:12 AM Joshua McKenzie
wrote:
> how to best merge Casskop's features in Cass-operator.
>
> What if we create issues on the gh repo here
> https://github.com/datastax/cass-operator/issues, create a milestone out
> of
> that, and have engineers rally on it to get things merged? We have a few
> engineers focused on k8s ecosystem for Cassandra from the DataStax side
> who'd be happy to collaborate with you folks to get these things in.
>
>
> On Fri, Oct 02, 2020 at 11:34 AM, wrote:
>
> > An update on Orange's point of view following the recent emails:
> >
> > If we were a newly interested party in running C* in K8s, we would use
> > Cass-operator as it comes from Datastax.
> >
> > The logic would then be that the community embraces it and thanks
> Datastax
> > for offering it!
> >
> > So, on Orange side, we propose to discuss with Datastax how to best merge
> > Casskop's features in Cass-operator. These features are:
> > - nodes labelling to map any internal architecture (including network
> > specific labels to muti-dc setup)
> > - volumes & sidecars management (possibly linked to PodTemplateSpec)
> > - backup & restore (we ruled out velero and can share why we went with
> > Instaclustr but Medusa could work too)
> > - kubectl plugin integration (quite useful on the ops side without an
> > admin UI)
> > - multiCassKop evolution to drive multiple cass-operators instead of
> > multiple casskops (this could remain Orange internal if too specific)
> >
> > We could decide at the end of these discussions the best way forward.
> > Orange could make PRs on cass-operator, but only if we agree we want the
> > functionalities :)
> >
> > If we can sort it out we could end up with a pretty neat operator.
> >
> > We share a common architecture (operator-sdk), start to know each other
> > with all these meetings so it should be possible if we want to!
> >
> > Would that be ok for the community and Datastax?
> >
> > On 2 Oct 2020, at 14:52, Joshua McKenzie wrote:
> >
> > What are next steps here?
> >
> > Maybe we collectively put a table together w/the 2 operators and a list
> of
> > features to compare and contrast? Enumerate the frameworks / dependencies
> > they have to help form a point of view about the strengths and weaknesses
> > of each option?
> >
> > On Tue, Sep 29, 2020 at 10:22 PM, Christopher Bradford > com
> >
> > wrote:
> >
> > Hello Dev list,
> >
> > I'm Chris Bradford a Product Manager at DataStax working with the
> > cass-operator team. For background, we started down the path of
> developing
> > an operator internally to power our C*aaS platform, Astra. Care was taken
> > from day 1 to keep anything specific to this product at a layer above
> > cass-operator so it could solely focus on the task of operating Cassandra
> > clusters. With that being said, every single cluster on Astra is
> > provisioned and operated by cass-operator. The value of an advanced
> > operator to Cassandra users is tremendous so we decided to open source
> the
> > project (and associated components) with the goal of building a
> community.
> > It absolutely makes sense to offer this project and codebase up for
> > donation as a standard / baseline for running C* on Kubernetes.
> >
> > Below you will find a collection of cass-operator features,
> > differentiators, and roadmap / inflight initiatives. Table-stakes
> Must-have
> > functionality for a C* operator
> >
> > -
> >
> > Datacenter provisioning
> > -
> >
> > Schedule all pods
> > -
> >
> > Bootstrap nodes in the appropriate order
> > -
> >
> > Seeds
> > -
> >
> > Across racks
> > -
> >
> > etc.
> > -
> >
> > Uniform configuration
> > -
> >
> > Scale-up
> > -
> >
> > Add new nodes in a balanced manner across rack
> > -
> >
> > Scale-down
> > -
> >
> > Remove nodes one at a time across racks
> > -
> >
> > Node recovery
> > -
> >
> > Restart process
> > -
> >
> > Reschedule instance (IE replace node)
> > - Replace instance
> > -
> >
> > Specific workflows for seed node replacements
> > -
> >
> > Multi-DC / Multi-Rack
> > -
> >
> > Multi-Region / Multi-K8s Cluster
> > -
> >
> > Note this requires support at a networking layer for pod to pod IP
> > connectivity. This may be accomplished within the cluster with CNIs like
> > Cilium or externally via traditional networking tools.
> >
> > Differentiators
> >
> > -
> >
> > OSS Ecosystem / Components
> > -
> >
> > Cass Config Builder - OSS project extracted from DataStax OpsCenter Life
> > Cycle Manager to provide automated configuration file rendering
> > -
> >
> > Cass Config Definitions - definitions files for cass-config-builder,
> > defines all configuration files, their parameters, and templates
> > -
> >
> > Management API for Apache Cassandra (MAAC)
> > -
> >
> > Metrics Collector for Apache Cassandra (MCAC)
> > -
> >
> > Reference Prometheus Operator CRDs
> > -
> >
> > ServiceMonitor
> > -
> >
> > Instance
> >
