Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KEDA CLI Commands #173

Open
jeffhollan opened this issue May 10, 2019 · 10 comments
Open

KEDA CLI Commands #173

jeffhollan opened this issue May 10, 2019 · 10 comments

Comments

@jeffhollan
Copy link
Member

@jeffhollan jeffhollan commented May 10, 2019

Related closely to #167 I think, but would be nice for the insights that the dashboard provides through some CLI (maybe the func CLI, not sure if KEDA needs its own).

It's possible that the dashboard won't surface much more than the kubectl would, but just had an ask from some users that it was hard to know after deploying if things were working or not. Ideally an experience a bit more than just kubectl logs existed.

@yaron2
Copy link
Contributor

@yaron2 yaron2 commented May 10, 2019

If I understand correctly, the ask is "how do I monitor KEDA and know if something went wrong with scaling my deployment".

Either cli or ui, currently we have two sources of truth: the controller logs and the status fields of ScaledObjects.

I can assume for the cli a command like keda get all would show the names of scaled objects, the trigger, and the latest status.

We could also parse the logs of the controller but that is not advisable.
Instead, we should make sure every ScaledObject is updated with human readable info regarding its state.

wdyt?

@yaron2
Copy link
Contributor

@yaron2 yaron2 commented May 10, 2019

Relates to #51

@yaron2
Copy link
Contributor

@yaron2 yaron2 commented May 10, 2019

Actually,

This is very similar to how you would get visibility into a service mesh.

In that case, I think the correct way to go would be to expose a Restful API from the controller to get detailed view of all the scaled objects.

The UI will visualize that data.

A KEDA cli would mean Azure Functions/kubeless/openFaaS/other users would need to have two clis in place. One for their framework and one for KEDA.

If we put that functionality in the func cli, we miss out on all non azure function users.

@ahmelsayed
Copy link
Contributor

@ahmelsayed ahmelsayed commented May 10, 2019

What kind of information are you thinking about surfacing from keda directly?

We could have a simple kubectl plugin and get kubectl keda .... style commands? It could wrap kubectl or communicate with that API depending on what data we're interested in showing. Most of the state we have is already stored in the crd for each scaled object.

@yaron2
Copy link
Contributor

@yaron2 yaron2 commented May 10, 2019

Yep a kubectl plugin is a good idea - it would communicate with our API that feeds the dashboard as well as direct user queries for more advanced cases.

@tomkerkhove
Copy link
Member

@tomkerkhove tomkerkhove commented Nov 18, 2019

v1.0 has shipped (🎉) and I'd love to get working on this for v1.x so we can build the dashboard on top of this.

Anybody who agrees? If so, I can spec it a bit out and provide a proposal.

Given everything gets a dedicated repo, I'd say this should be moved to http://github.com/kedacore/cli once we've agreed on it.

@tomkerkhove
Copy link
Member

@tomkerkhove tomkerkhove commented May 4, 2020

Bumping

@arschles
Copy link
Contributor

@arschles arschles commented Mar 22, 2021

As I mentioned in #1661, I think there's another possible use case for a keda CLI or kubectl plugin, and that is to provide users a more convenient way to create ScaledObject / ScaledJobs (I added a use cases section over in #1661 for those interested). So a CLI could potentially do mutation operations as well.

What do folks think? I can work on this

@coderanger
Copy link
Contributor

@coderanger coderanger commented Mar 22, 2021

I don't think this would be a good user experience to encourage. The use of existing tools like Kubectl's generators is highly correlated with new user confusion about how to maintain things over time. They are great for quick demos but terrible for long-term UX :-(

@zroubalik
Copy link
Member

@zroubalik zroubalik commented Mar 22, 2021

I tend to agree with @coderanger.

And there are other aspects, for example from maintenance POV: let' say we implement this kind of CLI, then it should definitely support ScaledObject creation -> thus it should be able to create a Trigger definition, suggest mandatory and optional fields and validate them on the client side. And because the triggers specs are not some CRDs with a well defined structure, but just key value map, you will need to implement the validation checks for all scalers (that's already done in each scaler code) and then track all the changes/additions. It is of course doable (or refactor the existing validation part in the scaler and expose it), but not sure if it is worth the effort. 🤷‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants