v1.24.0

• [CHANGE] #718 Update Kubernetes dependencies to 0.31.0 and controller-runtime to 0.19.x, remove controller-config and instead return command line options as the only way to modify controller-runtime options. cass-operator specific configuration will still remain in the OperatorConfig CRD. Removes kube-auth from the /metrics endpoint from our generated configs and instead adds network-policy generation as one optional module for Kustomize.
• [CHANGE] #527 Migrate the Kustomize configuration to Kustomize 5 only. Support for using Kustomize 4.x to generate config is no longer supported.
• [CHANGE] #763 If gossip information has ENDPOINT_IP, use it as the IP for the replacement job instead of NATIVE_ADDRESS_AND_PORT
• [CHANGE] #757 Change starting sequence of pods to match StatefulSet controller's behavior. First start the last pod and move towards 0.
• [CHANGE] #780 Make readOnlyRootFilesystem the default for DSE 6.8/6.9, OSS Cassandra 4.1 and newer and HCD. Modify securityContext settings of all containers in this case.
• [FEATURE] #583 If there are pods in failed state (CrashLoopBackOff, ImagePullBackOff or ErrImagePull), restartCount of a container/initContainer is more than zero with termination code >0 or we have a SchedulingFailed event, allow StatefulSet updates even if previous ones haven't been rolled yet. ForceUpgradeRacks will no longer remove itself from the CassandraDatacenter to prevent self modifying Spec.
• [FEATURE] #747 Add ScheduledTask to provide a cronjob like functionality to automatically create a CassandraTask on certain intervals.
• [ENHANCEMENT] #729 Modify NewMgmtClient to support additional transport option for the http.Client
• [ENHANCEMENT] #737 Before issuing PVC deletion when deleting a datacenter, verify the PVCs that match the labels are not actually used by any pods.
• [BUGFIX] #744 If StatefulSet was manually modified outside CassandraDatacenter, do not start such pods as they would need to be decommissioned instantly and could have IP conflict issues when doing so.
• [BUGFIX] #696 If the first pod in the rack was not available to be started (such as in Pending state), the startOneNode would keep waiting for it indefinitely.