Document deleting orphaned Kubernetes objects - #3413
Conversation
|
|
||
| Open your project and select **Live Status** for the environment (and tenant) you want. The table offers a delete action on every orphaned row, and when an application has orphaned objects the page also shows a card counting them. To list only orphaned objects, use the **Sync status** filter and select **Orphaned**. | ||
|
|
||
| :::figure |
There was a problem hiding this comment.
Need a screenshot without names etc.
| | Out of Sync | <i class="fa-solid fa-arrow-up orange"></i> | Object manifest is not the same as what was applied | | ||
| | Unknown | <i class="fa-solid fa-question grey"></i> | We don't have information about the live status of this object | | ||
| | Orphaned | <i class="fa-solid fa-link-slash orange"></i> | Object was deployed in a previous release but is no longer part of the latest deployment process | | ||
| | Deleting | <i class="fa-solid fa-hourglass blue"></i> | Octopus is deleting this orphaned object. Select the status to open the task doing the work | |
There was a problem hiding this comment.
Slightly off - the UI shows "Deleting" but the sync status doesn't actually change over the wire
|
Pull request environment is available at https://stoctodocspr3413.z22.web.core.windows.net. You can view the ephemeral environment status in Octopus Deploy. This environment will be automatically deprovisioned when the pull request is closed, or after 7 days of inactivity. |
tleed5
left a comment
tleed5
left a comment
There was a problem hiding this comment.
Overall looks good, just some small changes to make things clearer
| @@ -85,24 +85,27 @@ Sync Status tracks whether the changes Octopus deployed still matches the resour | |||
| | Out of Sync | <i class="fa-solid fa-arrow-up orange"></i> | Object manifest is not the same as what was applied | | |||
| | Unknown | <i class="fa-solid fa-question grey"></i> | We don't have information about the live status of this object | | |||
| | Orphaned | <i class="fa-solid fa-link-slash orange"></i> | Object was deployed in a previous release but is no longer part of the latest deployment process | | |||
There was a problem hiding this comment.
If we wanted to make this icon's color match the portal you can add style="color: var(--colorIconWarning);" and get rid of the orange class since it doesn't actually exist for fa-link-slash
|
|
||
| ### An object stays orphaned after I re-added the step \{#orphan-persists-after-re-adding-a-step} | ||
|
|
||
| Octopus clears the orphan state when a deployment deploys the object again. Re-adding a step that is disabled does not deploy anything, so the object stays orphaned. Enable the step and deploy, or [delete the orphaned object](/docs/kubernetes/live-object-status/deleting-orphaned-objects) if you no longer want it. |
There was a problem hiding this comment.
Re-adding a step that is disabled does not deploy anything
I think this is a little bit confusing, it kinda conflicts with what is mentioned below
Skipping or disabling a step does not orphan its objects
I think it needs to be explicit about re-adding a step that was removed from the process
| Octopus clears the orphan state when a deployment deploys the object again. Re-adding a step that is disabled does not deploy anything, so the object stays orphaned. Enable the step and deploy, or [delete the orphaned object](/docs/kubernetes/live-object-status/deleting-orphaned-objects) if you no longer want it. | |
| Octopus clears the orphan state when a deployment deploys the object again. Re-adding a step that was removed from the process does not deploy anything, so the object stays orphaned. Enable the step and deploy, or [delete the orphaned object](/docs/kubernetes/live-object-status/deleting-orphaned-objects) if you no longer want it. |
|
|
||
| An object is marked [Orphaned](/docs/kubernetes/live-object-status#orphaned-objects) when a deployment succeeds and no longer produces an object that a previous release deployed. The usual causes are removing the object from a manifest, or removing the step that deployed it from the deployment process. Skipping or disabling a step does not orphan its objects, and a failed deployment never orphans anything. | ||
|
|
||
| If you expected an object to be orphaned and it isn't, check that every Kubernetes monitor in the application is on agent version 2.38.3 or later (v2) / 3.0.1 or later (v3). Orphan tracking is all-or-nothing across the application, so one older agent disables it everywhere and dropped objects are silently removed from the table instead. |
There was a problem hiding this comment.
By application do you mean Octopus Deploy itself or an application instance? Seems a bit weird if one outdated agent that might be in a completely different space could disable orphan tracking for the entire Octopus instance
There was a problem hiding this comment.
monitors deployed to from the P/E/T - so application instance
3 participants
Documents the new orphaned-object deletion feature in Kubernetes Live Object Status (Octopus Server 2026.3).
Deletingsync status, clarifies when an object becomes orphaned, and updates the excluded-steps limitation for newer agentsDeployedResourceAdministerto the four built-in roles that get it🤖 Generated with Claude Code