Problem Statement

Currently, Red Hat Satellite requires administrative action to remove host records, even when a system is decommissioned or re-registered. While subscription-manager unregister removes local state, it does not clean the corresponding host record on the Satellite server.

In modern infrastructures — particularly global enterprises using ephemeral VMs, CI pipelines, or ORGA-based testing — this leads to host clutter, re-registration errors, and unnecessary operational overhead.

Request the ability for a RHEL host to delete its own host record from Satellite securely and automatically, without requiring external API access or human intervention.

User Experience & Workflow

Request the ability for a RHEL host to delete its own host record from Satellite securely and automatically, without requiring external API access or human intervention.

Requirements

Red Hat Satellite does not provide a mechanism for a registered host to delete its own
host record from the Satellite server via subscription-manager or a secure
automated method. This creates a disconnect between host registration and
host lifecycle completion.

Business Impact

Impacts on Global Enterprise Operations:
----------------------------------------

1. Obstructed Automation & Self-Service
---------------------------------------
In dynamic infrastructures using CI/CD, ephemeral VMs, or auto-scaling, hosts
must register and unregister cleanly. Without self-deletion, residual host
records accumulate, preventing re-registration and requiring manual cleanup.

Result:

• Automation pipelines become brittle.
• CI/CD fails when runners or test machines cannot re-register.
• DevOps teams must escalate to Satellite admins.

2. Increased Operational Overhead
---------------------------------
Satellite administrators are forced to regularly clean stale host records via
hammer, web UI, or custom scripts. As host volumes grow across environments
and ORGAs, this overhead scales non-linearly.

Result:

• Loss of administrator time for repetitive cleanup tasks.
• Increased support tickets from teams unable to register or switch ORGA.

3. Inventory and CMDB Pollution
-------------------------------
Residual host records remain in Satellite’s reports, fact data, and connected
CMDBs (e.g., Ansible Tower, ServiceNow). This results in false-positive audit
data, incorrect patch status, and security non-compliance reports.

Result:

• Erosion of trust in Satellite inventory accuracy.
• False compliance alerts and incorrect lifecycle metrics.

4. Inconsistent Lifecycle Governance
------------------------------------
Satellite allows a host to register, attach subscriptions, and push facts,
but not to cleanly remove itself from the system, despite possessing its
authenticated identity.

Result:

• Asymmetry in lifecycle control.
• Organizations must use privileged API tokens or shared credentials for cleanup.
• Elevated risk due to wider-than-necessary API access.

5. Fragile Cross-ORGA or Test Use Cases
---------------------------------------
Switching ORGAs or AKs for test environments or integration scenarios becomes
error-prone. Stale host records block registration unless someone removes them
manually.

Result:

• Breakage in test environments.
• Loss of agility for developers and QA teams.

Examples in Practice:
---------------------

• A GitLab CI runner registers to Satellite in ORGA "test-a", then is redeployed
  and tries to register to "test-b" with a new AK — registration fails due to an
  existing host record.
• A cloud autoscaler creates short-lived VMs that leave hundreds of stale host
  entries in Satellite.
• A patch compliance report includes systems that no longer exist.

Conclusion:
-----------
The inability for a host to autonomously and securely delete its own record
from Satellite severely limits automation, scalability, inventory hygiene, and
modern infrastructure practices. In global enterprises with high infrastructure
churn, this becomes a blocker to operational efficiency and auditability.

A host-initiated, scoped, and authenticated self-deletion feature would solve
this problem without compromising security or RBAC boundaries.