5.0 Release Notes

This is the first stable release of Hazelcast Platform Operator.

New features

  • Custom resource for Hazelcast cluster that can be used for OS and EE cluster creations.

  • Custom resource for Management Center

  • Expose Hazelcast cluster to external clients (Smart and Unisocket). See Connecting to Hazelcast from Outside Kubernetes

  • Initial Openshift support

  • Empty spec support for both custom resources:

    apiVersion: hazelcast.com/v1alpha1
    kind: Hazelcast
    metadata:
        name: hazelcast
    apiVersion: hazelcast.com/v1alpha1
    kind: ManagementCenter
    metadata:
        name: managementcenter
  • Proper status subresources for Hazelcast and Management Center custom resources:

    kubectl get hazelcast
    
    NAME        STATUS    MEMBERS
    hazelcast   Failed    0/3
    
    kubectl get hazelcast -o yaml
    
    ...
    Status:
    Hazelcast Cluster Status:
        Ready Members:  0/3
    Message:          multiple (1) errors: pod hazelcast-0 in namespace default failed for : ErrImagePull
    Phase:            Failed

Enhancements

  • Made clusterName configurable for Hazelcast custom resource

  • Added liveness/readiness probes, terminationGracePeriod and securityContext to both CRs' Statefulset.

  • Provided local run with Hazelcast Go client for development purposes.

  • Fail fast mechanisms for exposeExternally and licenseKeySecret specifications with meaningful user-facing log message

  • Created constants for all k8s resources that created by the CRs.

  • Created end-to-end and integration test suites via utilizing EnvTest for Hazelcast and Management Center controllers. End-to-end tests are running against GKE and OCP.

  • Prepared workflows to release the operator to DockerHub, RHEL registry and RedHat Marketplace.

  • Configured names of ClusterRole and ClusterRoleBinding dynamically to prevent conflict at multi-namespace deployment.

Fixes

  • Prevented panic on shutting down the client when the connection to the cluster was not established. #60

  • Problem where the controller assumes failed status for pending pods. #74