ironcore-dev / ironcore-dev/sonic-operator
Define the Switch Deletion Lifecycle
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 4
- Forks
- 155
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 8
Description
Summary
Define the expected behavior when a Switch resource is deleted.
Currently, the resource primarily provides the switch-specific information used by the operator to generate its ZTP script. It is unclear whether deleting the resource should also affect the physical switch.
Basic example
Possible behaviors include:
- Delete only the Kubernetes resource, without changing the physical switch.
- Reset or decommission the physical switch.
- Perform limited cleanup of configuration managed by the operator.
Motivation
The deletion behavior should be defined before implementing cleanup or reset logic. The appropriate workflow may also depend on how Switch resources are created and managed by external systems.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the Switch resource definition and the operator workflow that generates its ZTP script. Determine how Switch resources are created and managed by external systems, then document an agreed deletion contract covering the Kubernetes resource and any physical-switch cleanup; done means the expected lifecycle is explicit before implementation begins.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100