You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What did you do to encounter the bug?
Steps to reproduce the behavior:
Deploy an AtlasDeployment with a serverlessSpec definition.
Wait for the creation of the Atlas Cluster, this will create a Flex cluster.
Check the status of the AtlasDeployment, this has now an error in the DeploymentReady status and it's status False.
What did you expect?
With the deprecation of the serverlessSpec I expected to see a Flex cluster being created, but Atlas should provide backwards compatibility where you can still manage these Flex clusters while using the serverlessSpec definition, as per the docs:
To preserve backwards compatibility of the APIs for a period of time, Atlas will continue to allow for these migrated clusters to be managed through the same APIs, including when using Atlas Kubernetes Operator. The backwards compatibility of APIs will remain in place until January 2026, when the old APIs will be removed and only APIs related to Flex clusters will remain in place.
What happened instead?
The status of the AtlasDeployment of type DeploymentReady has a status of False with the following error reported:
status:
conditions:
- lastTransitionTime: '2025-02-07T09:46:11Z'status: 'False'type: Ready
- lastTransitionTime: '2025-02-07T09:46:11Z'status: 'True'type: ResourceVersionIsValid
- lastTransitionTime: '2025-02-07T09:46:11Z'status: 'True'type: ValidationSucceeded
- lastTransitionTime: '2025-02-07T09:46:11Z'message: >- unable to retrieve list of serverless private endpoints from Atlas: https://cloud.mongodb.com/api/atlas/v2/groups/REDACTED/privateEndpoint/serverless/instance/REDACTED/endpoint GET: HTTP 400 Bad Request (Error code: "NOT_SERVERLESS_TENANT_CLUSTER") Detail: The specified cluster REDACTED in group REDACTED is not a serverless tenant cluster. Reason: Bad Request. Params: [REDACTED REDACTED]reason: ServerlessPrivateEndpointFailedstatus: 'False'type: DeploymentReady
In the meantime, we are investigating why the API shimming is not working as intended for serverless deployment types - but if you do the above, it’s not needed - it’s really only critical once deployments are automigrated to flex and we fully expect to have resolved this by then.
Thanks for the response. Directly creating / managing the Flex cluster using the flexSpec does work as intended. We have created a workaround in our deployment strategy to apply the serverlessSpec variant for existing deployments that need to be auto migrated while our new deployments use the new flexSpec and this solves the problem for us as long as this issue is fixed before auto migration happens. Glad to hear you fully expect that to happen!
What did you do to encounter the bug?
Steps to reproduce the behavior:
AtlasDeployment
with a serverlessSpec definition.AtlasDeployment
, this has now an error in theDeploymentReady
status and it's statusFalse
.What did you expect?
With the deprecation of the serverlessSpec I expected to see a Flex cluster being created, but Atlas should provide backwards compatibility where you can still manage these Flex clusters while using the serverlessSpec definition, as per the docs:
What happened instead?
The status of the
AtlasDeployment
of typeDeploymentReady
has a status ofFalse
with the following error reported:Operator Information
Kubernetes Cluster Information
Additional context
Example
AtlasDeployment
used:kubectl describe output:
The text was updated successfully, but these errors were encountered: