Export crossplane beta trace libraries

[stevendborrelli]

What problem are you facing?

When building CLI tooling around Crossplane, it would be useful to be able to import the libraries used in crossplane beta trace at https://github.com/crossplane/crossplane/tree/master/cmd/crank/beta/trace/internal.

They are currently marked as internal.

Use cases:

• Fetching and mapping resources in to k8s references
• Fetching the resource tree

How could Crossplane help solve your problem?

[negz]

Bit of a tangent, but I'd prefer to reorganize cmd/ to mostly contain only actual CLI entry points, with any supporting libraries moving out of cmd/ and under internal/, or if we agree to make them public, /.

More concretely, I'd like to move e.g. cmd/crank/beta/trace/internal -> internal/crank/trace.

[negz]

More on-topic:

• Any time we make a package public we're committing to maintaining it as a library (caring about breaking changes etc).
• If we do want to take on that commitment, does it make sense for the code to still live in c/c (which is mostly not a library)?

Would we want something like https://github.com/crossplane/cli-runtime for example?

[stevendborrelli]

A separate library would be good, it may not even need to be CLI specific.

Currently I’m writing a CLI that migrates claims from one namespace to another.

Another project I am thinking of is a crossplane pause/unpause CLI that could recurse through a claim during maintenance or migration to another control plane.

[gotwarlost]

We have 2 use-cases for needing the trace library

• A custom trace tool that works differently from the standard one as described in Improve the trace command for performance  #5707 (comment)

• Our acceptance tests (written as go test tests) create a bunch of resources and wait for all of them to be synced/ ready and not have last async operation failures before we can declare victory. To be honest, this use-case could have been handled by running crossplane beta trace --json and loading resources from there but since we'd already copied the libraries, we simply ended up using them. Note that even in that case we would still have to copy the resource tree model objects in order to deserialize the JSON.