add doc about operator no-delete policy

[gazarenkov]

Description

add doc about operator no-delete policy

Which issue(s) does this PR fix or relate to

https://redhat.atlassian.net/browse/RHIDP-13670

PR acceptance criteria

• Documentation

How to test changes / Special notes to the reviewer

Building Container Images for Testing

Need to test container images from this PR?

For Maintainers: To trigger a test image build, review the code and comment /build-images.
This always builds the HEAD of the PR branch.

For Contributors: Ask a maintainer to run /build-images.

Images will be built and pushed to Quay with links posted in comments.

[rhdh-qodo-merge]

PR Summary by Qodo

Document operator resource no-delete policy

📝 Documentation 🕐 Less than 5 minutes

AI Description

• Document that the operator does not delete orphaned resources after Backstage CR changes.
• Explain the data-loss rationale and user responsibility for manual cleanup.
• Add an oc get example to find operator-managed resources by labels.

High-Level Assessment

The PR’s approach (documenting the no-delete behavior with rationale plus a concrete discovery command) is the most effective and lowest-risk way to set expectations and prevent accidental data loss; no alternative implementation approach is needed for a documentation-only change.

Files changed (1) +19 / -1

Documentation (1) +19 / -1

admin.mdAdd Resource Deletion Policy section (no automatic cleanup) +19/-1

Add Resource Deletion Policy section (no automatic cleanup)

• Adds a new "Resource Deletion Policy" section explaining that the operator intentionally does not delete orphaned resources when the Backstage CR configuration changes. Includes rationale focused on preventing data loss and provides an 'oc get' command to locate operator-created resources via labels for manual cleanup.

docs/admin.md

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

Context used

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

✅ Compliance rules (platform): 18 rules

✅ Cross-repo context

  Not relevant to this PR: redhat-developer/rhdh

  Not relevant to this PR: redhat-developer/rhdh-plugins

1. Cleanup misses ConfigMaps ✓ Resolved 🐞 Bug ≡ Correctness

Description

The new resource-discovery command (oc get all,pvc,secret ...) does not list ConfigMaps (not
included in all) and also won’t show ServiceMonitors created when monitoring is enabled, so users
may miss operator-created labeled resources during manual cleanup.

Code

docs/admin.md[R167-169]

+```bash
+oc get all,pvc,secret -l app.kubernetes.io/name=backstage,app.kubernetes.io/instance=<cr-name> -n <namespace>
+```

Relevance

●●● Strong

Team previously accepted monitoring doc fixes (ServiceMonitor naming/notes), suggesting they value
accurate resource-discovery commands.

PR-#1819
PR-#1499

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The doc command currently queries only all,pvc,secret, but the operator creates ConfigMaps and
ServiceMonitors that carry the same app.kubernetes.io/* labels, so those resources won’t be
returned by the documented query.

docs/admin.md[157-172]
pkg/utils/utils.go[37-50]
pkg/model/runtime.go[211-216]
pkg/model/configmapfiles.go[56-93]
internal/controller/monitor.go[18-44]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`docs/admin.md` instructs users to identify operator-created resources via `oc get all,pvc,secret ...`, but this omits important operator-managed resource types (notably ConfigMaps, and ServiceMonitors when monitoring is enabled). This makes the documented cleanup workflow incomplete.

### Issue Context
The operator applies `app.kubernetes.io/name=backstage` and `app.kubernetes.io/instance=<cr-name>` labels broadly to runtime objects, and it does create ConfigMaps and can create ServiceMonitors.

### Fix Focus Areas
- docs/admin.md[165-172]

### Suggested change
Update the example to include ConfigMaps, and either:
1) include a separate `oc get servicemonitors ...` line (so clusters without the CRD don’t error), or
2) add a short note that monitoring CRs (ServiceMonitor) must be queried explicitly when monitoring is enabled.

For example:
```bash
oc get all,cm,pvc,secret -l app.kubernetes.io/name=backstage,app.kubernetes.io/instance=<cr-name> -n <namespace>
# If monitoring is enabled and the CRD exists:
oc get servicemonitors -l app.kubernetes.io/name=backstage,app.kubernetes.io/instance=<cr-name> -n <namespace>
```

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Missing EOF newline 🐞 Bug ⚙ Maintainability

Description

docs/admin.md still has no trailing newline at end-of-file (git reports this in the diff), which is
a minor repo-hygiene issue and can create noisy diffs or fail strict formatting checks.

Code

docs/admin.md[173]

+Review carefully before deleting, especially PersistentVolumeClaims which contain data.

Relevance

●● Moderate

No historical evidence found that missing EOF newline in docs is consistently enforced or fixed.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The last line shown is the file’s end, and the PR diff indicates the file still lacks a trailing
newline at EOF.

docs/admin.md[171-173]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`docs/admin.md` ends without a trailing newline.

### Issue Context
The PR edits the end of this file; adding a final newline removes the `No newline at end of file` condition.

### Fix Focus Areas
- docs/admin.md[173-173]

### Suggested change
Ensure there is a newline after the last line (add a final blank line at EOF).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud