Giters

knative / client-contrib

Community contributed `kn` plugins.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

"kn-admin" use case collection [discussion]

rhuss opened this issue · comments

commented

As we have kn admin as our first 'official' kn plugin, it's time to collect features which people would like to see as part of a "kn admin" which is all about to configure a Kubernetes based Knative installation (in contrast to non-Kubernetes based implementations like Cloud Run).

This plugin is special as the persona it is adresses is not necessarily the end-user of Knative (like a developer) but an admin setting up Knative. Of course, if used in a standalone development environment (like minikube) that functionality might be helpful for everyone.

As soon we have kind of an initial set which we would like to have configured, we can revisit the command structure for this plugin.

Currently the following initial features / commands are available:

  • kn admin domain set - to set Knative route domain
  • kn admin registry add - add registry with credentials to enable Service deployment from it

What other use case can you imagine and which would make sense to add it to this plugin ? Please forward this issue to anybody who is interested in having features added for such a plugin.

// cc: @mattmoor @vaikas @evankanderson (TOC) @zhanggbj (kn-admin maintainer)

commented

I like the idea a lot! Can we have this run in two "modes", where one mode is mutating configmaps directly and the other mutates the KnativeServing CR if you're running in an environment that's installed by an operator?

You could even try to guess which one to use based on the availability of a KnativeServing CR in the cluster but of course that should be overridable via flags.

commented

Can we have this run in two "modes", where one mode is mutating configmaps directly and the other mutates the KnativeServing CR if you're running in an environment that's installed by an operator?

Definitely. And as you say, it also can auto-detect the installation mode but allow it to be overwritten via an option.

commented

One of the first things that comes to mind would be all autoscaling options as described in https://knative.dev/docs/serving/configuring-autoscaling/ . And of course it would be cool if kn admin would be able to detect the serving version installed so that it could act differently depending on the Knative serving version running on the clustee.

commented

@rhuss @markusthoemmes
Thanks for opening this! I have a proposal doc for the kn admin with 12 user stories, including domain & registry (which are merged) and auto-scaling as you mentioned.

I think working with operator mode is also a good idea and we can have more discussion in the proposal doc.

kn_admin_design (1)

CC @duglin @maximilien