[EPIC] CLI interface

[rixvet]

Repetitive work done via GUI should also be possible via CLI command interface to allow automation. It's currently requires programming against the user API, a CLI command wrapper would be a nice addition.

[rixvet]

Would also be nice if the CLI interface would be available at the agent, allowing the some functions of the agent (e.g. disable/enable agent) to be executed (with the API key used by the agent software). This is for example quite useful for sysadmins.

[linuxkd]

We've built an internal Python CLI (currently named krackctl, would obviously rename to something like hashtopolis-cli for upstream) that wraps the v2 REST API and covers most of the operator-side functionality this epic describes — happy to upstream it if there's interest.

What's working today (against a production deployment):

Subcommands for supertask, wrapper, hashlist, pretask, file, task, chunks, chunk, agent/agents, hash, hashtype, config, plus a rolled-up health snapshot. CRUD on most resources — e.g., ... wrapper archive 8802, ... supertask add-pretask 66 22049, ... agent patch 11 cmdPars "...". Bearer-token auth with a short-lived local cache. --json flag on every subcommand for jq pipelines. Single-file script, no runtime deps beyond stdlib.

Out of scope for what we have:

The agent-side CLI @rixvet mentioned (enable/disable an agent from its own host using the agent's API key) — that's a feature of the Python agent codebase, not the operator-side CLI. Would be a separate effort.

Before we invest in cleanup for upstream, would the maintainers be interested in a PR along these lines? And if so, any strong preferences on naming, repo location (standalone hashtopolis/cli vs under hashtopolis/server), or scope boundaries we should match before opening one?

[ObsidianOracle]

Hey @linuxkd thank you very much for reaching out. We haven´t had time yet to answer your question properly: We are about to release 1.0 soon, so all of our ressources are invested into that release. We will come back to you soon once we discussed your approach internally and discussed the technical requirements! We keep you posted!

[linuxkd]

Hey @linuxkd thank you very much for reaching out. We haven´t had time yet to answer your question properly: We are about to release 1.0 soon, so all of our ressources are invested into that release. We will come back to you soon once we discussed your approach internally and discussed the technical requirements! We keep you posted!

Sounds good, thank you for following up!

Also, I have been working on another major feature that has been bothering me for some time, i'll post it here as an issue (feature request) along with a PR. It's pretty significant though, so it will be something that might warrant some discussion. I have most of it already done, but i'm still validating it on our live cluster to ensure it works exactly as expected. It is targeted against the rainbow branch already as I assumed you guys were trying to get to GA on it and efforts going forward probably belonged on that branch.