Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-15353

Investigate deploying IDM as a deployment in forgeops instead of a statefulset


    • Type: Story
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Devops
    • Labels:
    • Target Version/s:
    • Story Points:
    • Sprint:
      2020.12 - IDM


      Currently deploying IDM as a stateful set causes upgrade to incur some downtime. It is desirable though to have no downtime when upgrading the IDM pods in forgeops. See FRAAS-3964.

      These are the reasons one would use a stateful set vs a deployment in Kubernetes. See https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#using-statefulsets

      Stable, unique network identifiers.
      Stable, persistent storage.
      Ordered, graceful deployment and scaling.
      Ordered, automated rolling updates.

      These reasons should not apply to IDM.

      1. IDM pods dont talk to eachother
      2. IDM doesn't use persistent volumes
      3. IDM should not care if idm x comes up before idm y
      4. IDM should not care if idm x gets a pod update before idm y

      Warren Strange Said at some point using a deployment vs a stateful set was tried and some issues were discovered around the scheduler. IDM should strive for IDM pods to be cattle and not pets, so IDM should investigate deploying itself as a deployment and not a stateful set. See the slack discussion: https://forgerock.slack.com/archives/C9ECR7XED/p1594174858495700.


      Acceptance Criteria

      • File jiras to fix issues blocking deploying IDM as a deployment, or make an official call that IDM MUST be a stateful set.


          Issue Links



              • Assignee:
                travis.haagen Travis Haagen
                jason Jason Lemay
              • Votes:
                0 Vote for this issue
                7 Start watching this issue


                • Created: