[Bug]: No status on AtlasBackupPolicy and AtlasBackupSchedule CR

[pavansokkenagaraj]

Is there an existing issue for this?

• I have searched the existing issues

AKO Version

v2.10.0

Distribution

Kubernetes

Kubernetes Version

1.33

Current Behavior

No status on AtlasBackupPolicy and AtlasBackupSchedule CR

apiVersion: atlas.mongodb.com/v1
kind: AtlasBackupSchedule
metadata:
  creationTimestamp: "2025-10-22T02:00:30Z"
  generation: 1
  name: prod-backup-schedule
  namespace: minimal-test
  resourceVersion: "310960"
  uid: 4f95754f-93e8-481e-9295-a5c351c06671
spec:
  autoExportEnabled: false
  policy:
    name: prod-backup-policy
    namespace: minimal-test
  restoreWindowDays: 3
  updateSnapshots: true

Custom Resources to reproduce the issue

apiVersion: atlas.mongodb.com/v1
kind: AtlasBackupSchedule
metadata:
  creationTimestamp: "2025-10-22T02:00:30Z"
  generation: 1
  name: prod-backup-schedule
  namespace: minimal-test
  resourceVersion: "310960"
  uid: 4f95754f-93e8-481e-9295-a5c351c06671
spec:
  autoExportEnabled: false
  policy:
    name: prod-backup-policy
    namespace: minimal-test
  restoreWindowDays: 3
  updateSnapshots: true

Steps To Reproduce

1. Install ABS and ABP
2. Observe the status

Logs

Code of Conduct

• I agree to follow this project's Code of Conduct

[josvazg]

Thanks for reporting this issue @pavansokkenagaraj !

Is this report complete?
Could you provide a sample AtlasBackupPolicy for reproduction?
We would also need some sample deployment to reproduce the issue. What this a flex cluster? something else?
Any useful logs you wanted to share?

[pavansokkenagaraj]

@josvazg Sorry, I thought I added the ABP CR.
I was testing on Atlas Pro with M10/M30

The status conditions are empty but have IDs.
I have attached a screenshot

apiVersion: atlas.mongodb.com/v1
kind: AtlasBackupPolicy
metadata:
  creationTimestamp: "2025-10-23T19:32:39Z"
  finalizers:
  - mongodbatlas/finalizer
  generation: 1
  labels:
    crossplane.io/composite: simple-op
  name: simple-op-bp
  namespace: simple-op
  resourceVersion: "1725415"
  uid: b764b0a0-fb22-45a6-8aa3-5cb68519ec3f
spec:
  items:
  - frequencyInterval: 6
    frequencyType: hourly
    retentionUnit: days
    retentionValue: 3
  - frequencyInterval: 1
    frequencyType: daily
    retentionUnit: days
    retentionValue: 7
status:
  backupScheduleIDs:
  - simple-op/simple-op-bs
  conditions: []
  observedGeneration: 1

apiVersion: atlas.mongodb.com/v1
kind: AtlasBackupSchedule
metadata:
  creationTimestamp: "2025-10-23T19:32:40Z"
  finalizers:
  - mongodbatlas/finalizer
  generation: 1
  labels:
    crossplane.io/composite: simple-op
  name: simple-op-bs
  namespace: simple-op
  resourceVersion: "1725413"
  uid: 578a9b55-1fed-4d36-8e2d-3b8505df17aa
spec:
  autoExportEnabled: false
  policy:
    name: simple-op-bp
    namespace: simple-op
  restoreWindowDays: 3
  updateSnapshots: true
status:
  conditions: []
  deploymentID:
  - simple-op
  observedGeneration: 1

screenshot from atlas console:

[josvazg]

Thanks for reporting, I have a reproduction of the issue and we are looking into it!

[josvazg]

We have revised the behavior and it works as intended. We understand it might be confusing, but the issue is that both backup policies and backup schedules are not resources on their own, they are just configuration templates which deployments use to setup their backups. A policy could be used from zero to many schedules and each schedule be used from zero to many deployments, it is not so clear what "READY" would mean is that context.

You already noted the backup schedule status ".deploymentID" gets updated with the ID of the deployment that configured such schedule, that is all that gets updated outside of the deployment itself.

[pavansokkenagaraj]

@josvazg Thanks for the clarification — I understand this is the current design choice.

However, in most Kubernetes operator patterns, custom resources expose a readiness condition to signal their state to external controllers such as Crossplane or ArgoCD.

This consistency is important for interoperability and automation across ecosystems.
The absence of a readiness condition makes it harder to compose these resources declaratively, forcing downstream operators to implement custom readiness logic.

Is it possible to reconsider this behavior or at least providing a minimal readiness signal (e.g., when .status.deploymentID is populated) to align with broader K8s conventions.

Please keep this issue open if you’re open to revisiting this design in future releases.

[josvazg]

Yes you are right @pavansokkenagaraj , the Ready pattern is expected to behave as you described. But with the given design, this is not a simple bugfix but a wider design fix that requires breaking changes to properly address.

Updating the READY status right now would require us first to define what ready means in this context. It is not a simple this resource is ready or not, cause this is not a resource, but rather a relationship of many resources with a single config.

BTW, just FYI. Regarding readiness semantics, the Backup Schedule readiness for a Deployment is contained within that Deployment. If the Deployment goes Ready is because it also managed to setup its Backup Scheduled as per configuration.

[github-actions]

This issue has gone 30 days without any activity and meets the project’s definition of 'stale'. This will be auto-closed if there is no new activity over the next 60 days. If the issue is still relevant and active, you can simply comment with a 'bump' to keep it open. Thanks for keeping our repository healthy!