Migrate Parameters to Custom Resource Definitions

On this page

Affected Configurations

Migration Procedure

Beginning with Atlas Kubernetes Operator version 2.6, various resource configurations that previously took the form of parameters have transitioned to CRDs of their own. Support for the parameter-based parent resource configuration is deprecated. Existing parameter-based parent resource configurations will continue to work, but support for these configurations will be removed in a future release.

To continue managing these resources through Atlas Kubernetes Operator in the future, migrate to the appropriate CRD.

Affected Configurations

The following configurations are affected:

Parameter	CRD
`spec.customRoles`	`AtlasCustomRole` Custom Resource
`spec.privateEndpoints`	`AtlasPrivateEndpoint` Custom Resource

Migration Procedure

To migrate from parameter-level resource management to CRD management:

Disable project reconciliation and edit subresource references.

Add the mongodb.com/atlas-reconciliation-policy: "skip" annotation to the parent resource's metadata. This prevents Atlas Kubernetes Operator from attempting to reconcile the parent resource and its subresources.
To prevent conflicts with the new CRD you create, you must delete the parameters corresponding to the resource you want to migrate from the parent resource.

Consider the following example of an atlasProject with a customRoles configuration:

apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  name: my-project
spec:
  name: Test project
  connectionSecretRef:
    name: my-atlas-key
  customRoles:
    role:
      name: my-role
      actions:
        - name: getShardMap
          resources:
            cluster: true
        - name: shardingState
          resources:
            cluster: true
        - name: connPoolStats
          resources:
            cluster: true
        - name: getLog
          resources:
            cluster: true
        inheritedRoles:
          - name: operator-role-1
            role: backup
   projectIpAccessList:
     - cidrBlock: "203.0.113.0/24"
       comment: "CIDR block for Application Server B - D"

Ensure that you have added the annotations block in lines 5 and 6 and remove the customRoles block shown in the previous example.

apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  name: my-project
annotations:
  mongodb.com/atlas-reconciliation-policy: "skip"
spec:
  name: Test project
  connectionSecretRef:
    name: my-atlas-key
  projectIpAccessList:
    - cidrBlock: "203.0.113.0/24"
      comment: "CIDR block for Application Server B - D"

Warning

If you do not apply this annotation, Atlas Kubernetes Operator will continue to attempt reconciliation as you modify your other resources. For users with New Default: Deletion Protection in Atlas Kubernetes Operator 2.0 disabled, this can result in Atlas Kubernetes Operator removing the Atlas project when you remove the atlasProject resource, or entering a blocked state attempting to remove a project with active subresources such as database users or deployments.

Delete the parameters from the parent CRD.

To prevent conflicts with the new CRD you create, you must first delete the parameters corresponding to the resource you want to migrate from the parent resource. For example, remove the customRoles parameter from the atlasProject CRD shown previously:

apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
 name: my-project
 annotations:
   mongodb.com/atlas-reconciliation-policy: "skip"
spec:
  name: Test project
  connectionSecretRef:
    name: my-atlas-key
  projectIpAccessList:
    - cidrBlock: "203.0.113.0/24"
  comment: "CIDR block for Application Server B - D"

Create the new CRD.

Create a CRD of the appropriate kind for the parameter you want to migrate, according to its syntax. For example, to migrate the customRoles parameter of the atlasProject CRD shown previously, create a AtlasCustomRole Custom Resource.

apiVersion: atlas.mongodb.com/v1
kind: AtlasCustomRole
metadata:
  name: shard-operator-role
  namespace: mongodb-atlas-system
labels:
  mongodb.com/atlas-reconciliation-policy: keep
spec:
  projectRef:
    name: my-project
    namespace: my-operator-namespace
role:
  name: my-role
  actions:
    - name: getShardMap
      resources:
        cluster: true
    - name: shardingState
      resources:
        cluster: true
    - name: connPoolStats
      resources:
        cluster: true
    - name: getLog
      resources:
        cluster: true
  inheritedRoles:
    - name: operator-role-1
      role: backup

Wait for Atlas Kubernetes Operator to sync the new resource status.

Remove the `atlas-reconciliation-policy: "skip"` annotation.

Additionally, you can now configure this resource as an Independent CRD.

Back

Independent Custom Resource Definitions

Compatibility