kubectl example subcommand — PR #134529 ready for review

[Sean O'Gorman]

Hi All,

I'm Sean O'Gorman, contributing to sig-cli. I've opened PR #134529 1 implementing a kubectl example subcommand (KEP-4146 2) and would appreciate your review when you have a moment.

Quick context: kubectl example deployment generates a clean, immediately-applicable YAML manifest — no more copying from docs and stripping comments. It currently covers 13 resource types including Gateway API, with struct-based generation (no templates) so the output always matches the cluster's API version.

The PR has been open a while and still needs /ok-to-test from an org member before CI can run. If you could take a look, that would be hugely appreciated. I had one comment around driving in #sig-cli with a sponsor, but didn't get time until now to push this. I did incorporate that with these changes:
 Key design decisions:
 - Struct-based generation using typed Go structs, not templates
 - Covers 13 resource types: Pod, Deployment, Service, ConfigMap, Secret, PVC, Job, CronJob, Ingress, NetworkPolicy, CRD, Gateway, HTTPRoute
 - Demonstrates the Ingress→Gateway API traffic paradigm shift with comparable examples
 - Flags for customization (--name, --image, --replicas, --namespace, --port)
 - Clean YAML output with zero-value field stripping

Pushing this as an eager Irish dude on St. Patrick's day, hoping for a bit of luck giving how crazy busy your schedules are.

Happy to address any feedback and would to present this the enhancement as soon as possible.

1 https://github.com/kubernetes/kubernetes/pull/134529
2 https://github.com/kubernetes/enhancements/pull/5576

Thanks,

Sean O'Gorman

Lead DevOps Engineer

sean.o...@deptagency.com

+353851028787

DEPT®

www.deptagency.com

Dept Design & Technology Registered office name: Thomas Burgh House, Newmarket, Dublin 8

Registered office: Newmarket Church, Dublin 8, Co. Dublin, IE

[Maciej Szulik]

Hey Sean,

Appreciate your contribution. We've been discussing this topic several times in the past.

The two scenarios/approaches we've considered in the past were:

1. Walk through available openapi schema and expose flags for each 

field one can set on a resource. 

2. Extended the openapi schema with a field where resource authors could

embed the "template" of a resource. Which we would use for kubectl create.

Both of the above have their own pros and cons, but I'm happy to see interest

in moving this topic forward. Have a look through our agenda, if you're curious

those past discussions, and as I mentioned on slack drop this topic for one of 

our next meetings. I'd love to learn what your proposal looks like :-)

Maciej

--
You received this message because you are subscribed to the Google Groups "sig-cli" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-cli+u...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-cli/CAANDYXzdMd6u3jr4hs0i%3DLMctWPDfO44hSh%3DaqR8U2jc6ZoSsA%40mail.gmail.com.

[Sean O'Gorman]

Hi Maciej,

Thanks for the warm response and the context. I've dug through the sig-cli history and found both approaches you mentioned:
1. KEP-2380 (Data-Driven Commands) — Phillip's proposal to walk OpenAPI schema and expose CLI flags per field, with the cnctl PoC from 2018.
2. kubectl-generate — Eddie's PoC reading example fields from an extended OpenAPI schema.
Both identified a real gap — users need a fast way to get a correct, working manifest. Could you comment on whether they stalled because they required upstream OpenAPI changes, I know that's the industry standard but was that ultimately too difficult to implement? 

My proposal inverts that: ship value first with typed Go struct builders (13 resource types, works offline, no API changes), and provide a clean interface that OpenAPI-based generators can plug into later without changing the command surface.

I'd like to present this at an upcoming sig-cli meeting, whenever is appropriate after code freeze.

Ultimately, I do get this has been attempted this before and you want whatever does get implemented, needs to be rock solid and future proof, to ensure success long term so I will definitely defer to wisdom of production you have obviously acquired! 
 
Could I add this to the agenda for the next available meeting? I'll include a one-paragraph summary and links to the KEP and implementation PR so attendees can pre-read, it's been updated after your kind response.

Cheers,
Sean

KEP PR: https://github.com/kubernetes/enhancements/pull/5576

Implementation PR: https://github.com/kubernetes/kubernetes/pull/134529