Crossplane: Workflow Tooling: crossctl

[hasheddan]

Description

I find myself using a lot of the same kubectl commands when creating classes, claims, etc. on Crossplane, and have begun to write bash scripts to automate some of the process. I believe that a CLI / kubectl plugin (crossctl)would be useful for more efficient development workflow as well as a nice user experience for new Crossplane administrators. Some features that it may implement include:

• Class / claim creation walk-through.

crossctl create bucket class
> which provisioner would you like to use?
s3bucket.aws.crossplane.io/v1alpha1 <--
bucket.storage.gcp.crossplane.io/v1alpha1
bucket.account.storage.azure.crossplane.io/v1alpha1

> enter a name for your bucket class (leave blank for dynamically generated): ...

> enter a namespace for your bucket class (leave blank for crossplane-system): ...

...
...

• Viewing logs. Automatically identify running Crossplane pod and print logs.

crossctl logs

crossctl -e [extension-name] logs



md5-49906a5e031a1ec9758fda741e5fa168



crossctl provider add aws
> enter you aws access key: ...

> enter your aws secret key: ...

Value Proposition

• Improves developer efficiency when testing new features
• Easy introduction to working with Crossplane
• Nice demo tool for non-Kubernetes users
• Opportunity for new contributors to get their feet wet in the community with a low barrier to entry project (i.e. requires less understanding of Kubernetes internals)

Open Questions

• What features should be included?
• Where should the project live?
• kubectl plugin or separate tool?

[displague]

I like this approach.

I've been adding little helper shell scripts that call the cloud provider's CLI tool to fit my needs, generally around setting up the initial credentials and IAMs. This takes that a necessary step further for usability.

My thinking has been stuck around embedding a web UI with the deployment to serve as the means to interact with external service providers.

crossctl and a web UI approach may be compatible.

I think that either UI would do well to integrate with the Cloud providers' OAuth2-style mechanisms for acquiring tokens and interacting with the existing account resources (both managed (buckets), and prerequisite (IAMs, VPCs, etc)).

[suskin]

@hasheddan cool! I was also wishing I had a crossctl configure type thing when I was setting up providers, so this seems like it could be beneficial.

Just to make sure someone argues the other side, do you have some of the examples of the commands you've been running? I'm wondering whether some of the use-cases could be satisfied by something lighter-weight, like aliases in a user's shell session.

[hasheddan]

I think it is definitely possible that something lighter weight could do the trick. However, kubectl does make it very easy to implement plugins.

Most of what I have been doing is related to getting logs from the crossplane pods or provisioning multiple resource sequentially. Therefore, it isn't really new functionality, just shortening / combining of commands which could be achieved through aliases. However, it might be nice just to have it standardized in a stand-alone CLI or kubectl plugin. I imagine that there will be more and more custom functionality desired as the project evolves, specifically around pulling and installing stacks and things of that nature.

[suskin]

Ahhh, excellent; that's exactly what I was hoping they used as their discovery mechanism!

For convenience aliases like you're describing, a reason to resist making an Actual Tool for as long as possible would be that a tool needs to be more aggressively maintained than aliases. Also, it does seem potentially contrary to the do one thing and do it well guideline of unix programming (which is a guideline that helps to encourage composability of tools). Which we don't necessarily need to follow, but which is another reason to resist making an Actual Tool.

Anyway, it seems as though in the long run, the particular aliases or macros that you're talking about could be a specific configuration of an alias or macro tool. What would you think of a more general alias type thing, similar to git aliases?

All that said, I suspect that there are some use-cases that are clearly a good fit for a plugin, some that are clearly a good fit for an alias, and a bunch that are in a gray area in between.

[suskin]

I've just found a sigs project for managing kubectl plugins. I expect this will be useful in the future : )

[jbw976]

There's some overlap here with the goal of #560 to help make the initial experience for a new Crossplane user to be easier.

@suskin I just listened to the Kubernetes podcast released yesterday about kubectl plugins and the krew plugin manager, it does sound like the story there has improved a lot recently.

[hasheddan]

crossctl is a thing!