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 · 5 comments

Comments

Projects
None yet
3 participants
@jeffhollan
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented May 10, 2019

Relates to #51

@yaron2

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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.

@jeffhollan jeffhollan added this to To do in KEDA Release via automation May 22, 2019

@jeffhollan jeffhollan removed this from To do in KEDA Release May 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.