Origin to/from Kube conversions for SAR
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 8.7k
- Forks
- 4.8k
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 53
Description
For example, origin SAR scopes can be translated to kube SAR extras.
Full round trip conversion may not be possible.
I (Mo) do not think they are fully convertible. Our SAR stuff defaults the namespace and user to the current if not given, kube requires it. Kube SAR also has
NonResourceAttributesandSubresourcewhich we do not seem to have. I am also not sure if kube'sExtraand ourScopescan be round tripped without losing data.
I planned on simply removing it but I was not sure if the origin SAR stuff even handled
NonResourceAttributes. While bothResourceAttributesandNonResourceAttributescannot be specified together, the origin stuff does have a.Pathso I feel like that should be used at some point.
xref: #13128
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 tracing the existing Origin and Kubernetes SAR representations and the discussion in #13128. Determine how scopes map to Extra, whether namespace and user defaults are preserved, and how Path, ResourceAttributes, NonResourceAttributes, and Subresource should behave. Done means the conversion rules and unsupported round-trip cases are agreed and covered by implementation tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- authorization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100