Creating AtlasDeployment with advancedDeploymentSpec fails with diskGB

[sunchill06]

What did you do to encounter the bug?
Steps to reproduce the behavior:

❯ cat <<EOF | kubectl apply -f -
apiVersion: atlas.mongodb.com/v1
kind: AtlasDeployment
metadata:
  name: new-cluster-1
spec:
  projectRef:
    name: test-project
  advancedDeploymentSpec:
      backupEnabled: true
      diskSizeGB: 80
      mongoDBMajorVersion: "4.4"
      pitEnabled: false
      replicationSpecs:
      - numShards: 3
        regionConfigs:
        - electableSpecs:
            instanceSize: M40
            nodeCount: 3
          autoScaling:
            compute:
              enabled: true
              maxInstanceSize: M60
              minInstanceSize: M40
              scaleDownEnabled: true
            diskGB:
              enabled: true
          providerName: GCP
          regionName: WESTERN_EUROPE
EOF
error: error validating "STDIN": error validating data: ValidationError(AtlasDeployment.spec.advancedDeploymentSpec.replicationSpecs[0].regionConfigs[0].autoScaling): unknown field "diskGB" in com.mongodb.atlas.v1.AtlasDeployment.spec.advancedDeploymentSpec.replicationSpecs.regionConfigs.autoScaling; if you choose to ignore these errors, turn validation off with --validate=false

❯ helm ls
NAME                  	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART                       	APP VERSION
mongodb-atlas-operator	mongodb  	22      	2022-07-04 12:08:47.672815367 +0000 UTC	deployed	mongodb-atlas-operator-1.1.0	1.1.0 

However in the atlas documentation I can see

What did you expect?
I was expecting the spec to run just fine. Following works fine though.

❯ cat <<EOF | kubectl apply -f -
apiVersion: atlas.mongodb.com/v1
kind: AtlasDeployment
metadata:
  name: new-cluster-1
spec:
  projectRef:
    name: test-project
  advancedDeploymentSpec:
      backupEnabled: true
      diskSizeGB: 80
      mongoDBMajorVersion: "4.4"
      pitEnabled: false
      replicationSpecs:
      - numShards: 3
        regionConfigs:
        - electableSpecs:
            instanceSize: M40
            nodeCount: 3
          autoScaling:
            compute:
              enabled: true
              maxInstanceSize: M60
              minInstanceSize: M40
              scaleDownEnabled: true
            diskGBEnabled: true
          providerName: GCP
          regionName: WESTERN_EUROPE
EOF
atlasdeployment.atlas.mongodb.com/new-cluster-1 created

What happened instead?
Error as mentioned earlier.

Screenshots
If applicable, add screenshots to help explain your problem.

Operator Information

• Operator Version - v1.1.0

Kubernetes Cluster Information

• Distribution
• Version
• Image Registry location (quay, or an internal registry)

Additional context
Add any other context about the problem here.

If possible, please include:

• kubectl describe output
• yaml definitions for your objects
• log files for the operator and database pods

[sunchill06]

Following works fine though. Expect the Operator's advance cluster option also sends the request to v1.5 of the Atlas API?

curl --user "${PUBLIC_KEY}:${PRIVATE_KEY}" --digest \
     --header "Content-Type: application/json" \
     --include \
     --request POST "https://cloud.mongodb.com/api/atlas/v1.5/groups/{GROUP}/clusters?pretty=true" \
     --data '{
         "clusterType": "REPLICASET",
         "name": "tenantCluster",
         "replicationSpecs": [
           {
             "regionConfigs": [
               {
                 "electableSpecs": {
                   "instanceSize": "M5"
                 },
                 "autoScaling": {
                    "diskGB": {
                       "enabled": true
                    },
                    "compute": {
                       "enabled": false,
                       "scaleDownEnabled": false
                    }
                 },
                 "providerName": "TENANT",
                 "backingProviderName" : "AWS",
                 "regionName": "US_EAST_1"
               }
             ]
           }
         ]
       }'

[fabritsius]

Thank you @sunchill06 🙏

This does seem like a bug and we are already working on the fix.

[Sugar-pack]

Hi @sunchill06, this bug has been fixed.
And this fix will be included in the next release. Thank you.