feat: Instance deletion API with tenant reported issue should record which tenant deleted the machine

[ajf]

Is this a new feature, an improvement, or a change to existing functionality?

Improvement

How would you describe the priority of this feature request

Medium

Please provide a clear description of problem this feature solves

It'd be useful for debugging, training, or Q&A purposes to record which tenant that deleted an instance with a tenant reported issue with the instance.

Feature Description

As a operations team debugging hardware, and a tenant deletes a instance from the API with a tenant reported issue, I want to see which tenant deleted the instance.

Describe your ideal solution

N/A

Describe any alternatives you have considered

No response

Additional context

No response

Code of Conduct

• I agree to follow NCX Infra Controller's Code of Conduct
• I have searched the open feature requests and have found no duplicates for this feature request

[ajf]

@sunilkumar-nvidia can you take a look at this

[sunilkumar-nvidia]

Proposal: Record tenant attribution on instance delete

Type: Improvement · Priority: Medium · Layer: Cloud (infra-controller-rest)

Problem

When a tenant deletes an instance (especially with a tenant-reported issue), operations teams need to know which org, user, and tenant initiated the delete. Today that information is fragmented (audit logs, machine health JSON on site) and is not easy to discover from the cloud layer.

Solution summary

Enrich the existing cloud delete flow with a standard JSON envelope on every delete. No new DB tables, no ReleaseInstance / proto changes.

Changes

#	Change	Scope
1	Structured API logs	All deletes — log delete_initiated_by (org, user_id, tenant_id, tenant_org, instance_id)
2	Cloud persistence	All deletes — replace the current Terminating status_detail plain-text message with the JSON envelope (table + create-on-delete already exist)
3	Site handoff	Deletes with machineHealthIssue — merge the same envelope into existing Issue.details before DeleteInstanceV2 (respect 1024-char limit)
4	gRPC	No change — same InstanceReleaseRequest; only Issue.details string content changes when an issue is present

JSON envelope (canonical)

{
  "delete_initiated_by": {
    "org": "<request org>",
    "user_id": "<cloud user uuid>",
    "tenant_id": "<instance tenant uuid>",
    "tenant_org": "<instance.Tenant.Org>"
  },
  "tenant_reported": {
    "category": "HARDWARE",
    "summary": "...",
    "details": "..."
  }
}

tenant_reported is included only when the client sends machineHealthIssue.

Where data is stored (cloud)

Store	When	Notes
status_detail.message (Terminating)	All deletes	Primary — queryable via instance status history while instance exists
audit_entry	All deletes	Already has org_name + user_id
Issue.details	Delete with issue	Forwarded to site; surfaces in Forge TenantReportedIssue without Forge changes
instance table	—	No new columns

Implementation

• Touchpoint: DeleteInstanceHandler.Handle in api/pkg/api/handler/instance.go
• Helper: buildDeleteAttribution(org, dbUser, tenant) → JSON envelope
• Tests: delete with/without machineHealthIssue; status detail contains envelope; Issue.details size handling

Out of scope

• DB schema migration / new tables
• Proto or ReleaseInstance RPC changes
• Forge / site-agent code changes
• Long-term history after cloud instance row is removed

Effort / risk

Small — improvement on existing delete + status-detail behavior; document envelope format for parsers and repair workflows.

[sunilkumar-nvidia]

@thossain-nv reviewing the requirements, I’ve shared my initial proposal above. Please take a look. I believe the changes at the API layer should be sufficient. Feel free to pick up this issue if you agree. Otherwise, we should discuss further and create separate sub-issues for the core and API layers.

Thanks!