Re: [DISCUSS] Next steps for Kubernetes operator SIG
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 > - > > Reference Grafana Operator CRDs > - > > Instance > - > > Dashboards > - > > Datasource > - > > PodTemplateSpec > - > > Customization of existing pods including support for adding containers, > volumes, etc > - > > Advanced Networking > - > > Node Port > - > > Host Network > - > > Simple security > - > > Management API mTLS support > - > > Automated generation of keystore and truststore for internode and client > to node TLS > - > > Automated superuser account
4.0 GA scope: the opt-in approach (CALL TO ACTION)
As discussed on the contributor call, we collectively agreed to try something new to determine scope for 4.0. Rather than going ticket by ticket or "asking for forgiveness" and having people move things out individually, we've flagged all tickets in the 4.0 scope that are still open with the fixversion '4.0-triage' with the intent to "opt things in". Link: https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20fixversion%20%3D%204.0-triage If there's a ticket you want to keep in the 4.0 release, please edit the ticket and remove the '4.0-triage' fixversion. Let's target having this done by End of Day Friday, October 9th (one week from now). If you don't have access to remove that fixver from a ticket, please reach out to me (jmckenzie), Jordan West, or Jon Meredith on the-asf slack in #cassandra-dev or via DM and we'll help you out. At the end of day on Oct 9th, we'll go through and move every ticket that still has 4.0-triage into 4.0.x and have our scope for 4.0 GA. Sound good? ~Josh
Re: [DISCUSS] Next steps for Kubernetes operator SIG
Hello Franck, This sounds like a great plan. We would love to expand the group of contributors and work towards getting the combined efforts pulled into the Apache Cassandra project proper. The list of items listed here are all wins in our book (and we've even said how much we enjoyed the CassKop labelling interface). Cheers, ~Chris Christopher Bradford On Fri, Oct 2, 2020 at 11:35 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 < > bradfor...@gmail.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 > >> - > >> > >> Reference Grafana Operator CRDs > >> - > >> > >> Instance > >> - > >> > >> Dashboards > >> - > >> > >> Datasource >
Re: Renaming master to trunk on cassandra-builds, cassandra-website, cassandra-dtest
+1 to in-jvm-dtest-api as well. > On Oct 2, 2020, at 6:48 AM, Dinesh Joshi wrote: > > +1 generally. We should do this for the sidecar repo as well. > > Dinesh > >> On Oct 2, 2020, at 2:17 AM, Mick Semb Wever wrote: >> >> Next week I plan to rename master branches on the cassandra-builds, >> cassandra-website and cassandra-dtest repositories to trunk. >> >> This was discussed in >> https://lists.apache.org/thread.html/r54db4cd870d2d665060d5fb50d925843be4b4d54dc64f3d21f04c367%40%3Cdev.cassandra.apache.org%3E >> >> The general preference there was trunk over main, so to match the cassandra >> repository. >> >> I'm tackling these three repositories first as they are the easiest. >> >> There are also the repositories… >> - cassandra-sidecar >> - cassandra-diff >> - cassandra-in-jvm-dtest-api >> - cassandra-harry >> >> If you are involved in one of these repositories and would like me to do it >> as well, please say so. >> >> This is getting tracked under CASSANDRA-16163 >> >> regards, >> Mick > > > - > 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
Re: [DISCUSS] Next steps for Kubernetes operator SIG
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 > 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 >> - >> >> Reference Grafana Operator CRDs >> - >> >> Instance >> - >> >> Dashboards >> - >> >> Datasource >> - >> >> PodTemplateSpec >> - >> >> Customization of existing pods including support for adding containers, >> volumes, etc >> - >> >> Advanced Networking >> - >> >> Node Port >> - >> >> Host Network >> - >> >> Simple security >> - >> >> Management API mTLS support >> - >> >> Automated generation of keystore and truststore for internode and client >> to node TLS >> - >> >> Automated superuser account configuration >> - >> >> The default superuser (cassandra/cassandra) is disabled and never >> available to clients >> - >> >> Cluster administration account may be automatically (or provided) with >> values stored in a k8s secret >> - >> >> Automatic application of NetworkTopologyStrategy with
Re: Renaming master to trunk on cassandra-builds, cassandra-website, cassandra-dtest
+1 generally. We should do this for the sidecar repo as well. Dinesh > On Oct 2, 2020, at 2:17 AM, Mick Semb Wever wrote: > > Next week I plan to rename master branches on the cassandra-builds, > cassandra-website and cassandra-dtest repositories to trunk. > > This was discussed in > https://lists.apache.org/thread.html/r54db4cd870d2d665060d5fb50d925843be4b4d54dc64f3d21f04c367%40%3Cdev.cassandra.apache.org%3E > > The general preference there was trunk over main, so to match the cassandra > repository. > > I'm tackling these three repositories first as they are the easiest. > > There are also the repositories… > - cassandra-sidecar > - cassandra-diff > - cassandra-in-jvm-dtest-api > - cassandra-harry > > If you are involved in one of these repositories and would like me to do it > as well, please say so. > > This is getting tracked under CASSANDRA-16163 > > regards, > Mick - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Next steps for Kubernetes operator SIG
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 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 > - > > Reference Grafana Operator CRDs > - > > Instance > - > > Dashboards > - > > Datasource > - > > PodTemplateSpec > - > > Customization of existing pods including support for adding containers, > volumes, etc > - > > Advanced Networking > - > > Node Port > - > > Host Network > - > > Simple security > - > > Management API mTLS support > - > > Automated generation of keystore and truststore for internode and client > to node TLS > - > > Automated superuser account configuration > - > > The default superuser (cassandra/cassandra) is disabled and never > available to clients > - > > Cluster administration account may be automatically (or provided) with > values stored in a k8s secret > - > > Automatic application of NetworkTopologyStrategy with appropriate RF for > system keyspaces > - > > Validating webhook > - > > Invalid changes are rejected with a helpful message > - > > Rolling cluster updates > - > > Change in binary (C* upgrade) > - > > Change in configuration > - > > Canary deployments - single rack application of changes for validation > before broader deployment > - > > Rolling restart > - > > Platform Integration / Testing / Certification > - > > Red Hat Openshift compatible and certified > - > > Secure, Universal Base Image (UBI) foundation images with security > scanning performed by Red Hat > - > > cass-operator > - > > cass-config-builder > - > > apache-cassandra w/ MCAC and MAAC > - > > Integration with Red Hat certification pipeline / marketplace > - > > Presence in Red Hat Operator Hub built into OpenShift interface > - > > VMware Tanzu Kubernetes Grid Integrated Edition compatible and certified > - > > Security scanning for images performed by VMware > - > > Amazon EKS > - > > Google GKE > - > > Azure AKS > - > > Documentation / Reference Implementations > - > > Cloud storage classes > - > > Ingress solutions > - > > Sample connection validation application with reference implementations of > Java Driver client connection parameters > - > > Cluster-level Stop / Resume - stop all running instances while keeping > persistent storage. Allows for scaling compute down to zero. Bringing the > cluster back up follows expected startup procedures > > Road Map / Inflight > > 1. > > Repair > 1. > > Reaper integration > 2. > > Backups > 1. > > Velero integration > 2. Medusa integration > 3. > > Advanced Networking via
Renaming master to trunk on cassandra-builds, cassandra-website, cassandra-dtest
Next week I plan to rename master branches on the cassandra-builds, cassandra-website and cassandra-dtest repositories to trunk. This was discussed in https://lists.apache.org/thread.html/r54db4cd870d2d665060d5fb50d925843be4b4d54dc64f3d21f04c367%40%3Cdev.cassandra.apache.org%3E The general preference there was trunk over main, so to match the cassandra repository. I'm tackling these three repositories first as they are the easiest. There are also the repositories… - cassandra-sidecar - cassandra-diff - cassandra-in-jvm-dtest-api - cassandra-harry If you are involved in one of these repositories and would like me to do it as well, please say so. This is getting tracked under CASSANDRA-16163 regards, Mick
