epi-project / brane

Programmable Orchestration of Applications and Networking
Apache License 2.0
9 stars 7 forks source link

Restructure brane-cli interface. #80

Closed DanielVoogsgerd closed 2 months ago

DanielVoogsgerd commented 3 months ago

This is just a thought that occured, let me know what you think. The brane command has quite a bit of subcommands. I think we should structure them a bit more clearly.

The current interface can work on both packages and workflows. However it specifies only the action we want to take. I think it might be more clear if we structure it: brane workflow, brane package, maybe for registry actions something like brane registry. All of them followed by the action we want to take.

Again just a thought that occured that I wanted to jot down. Let me know what you think, it is not high on the priority list anyway.

Lut99 commented 3 months ago

Good idea! It just to be a bit nicer when there where less, but ever since brane data, it has become much more arbitrary how things are structured. +1 for a refactor :)

DanielVoogsgerd commented 3 months ago

Okay so:

build -> package build
certs
check -> workflow check
data
import -> package build
inspect -> package inspect
instance
list -> package list
load -> package load
pull -> package pull
push -> package push
remove -> package remove
repl -> workflow repl
run -> workflow run
test -> package test
search -> package search
unpublish -> package unpublish
upgrade -> package upgrade
verify -> (Move to branectl? Seems like the better place)
version
help

This way we end up with:

certs
data
instance
package
(verify)
version
workflow
help

Furthermore I'd like to add a health subcommand that has subcommands to probe the nodes for their health/status.

@Lut99 What do you think?

Lut99 commented 2 months ago

Yeah, looks good to me!

verify -> (Move to branectl? Seems like the better place)

I think both can have one xD They both just focus on their own content. brane is the tool that scientists and software engineers download, so it makes sense IMO if they can check their own configs with this file (read: container.yml, data.yml, etc).

Furthermore I'd like to add a health subcommand that has subcommands to probe the nodes for their health/status.

This one I'd consider moving to branectl instead :) Since scientists are not in charge of managing nodes, more than some pinging and perhaps (if that ever gets implemented) if they can login might not be necessary. And I think version already covers that.

Unless you have other ideas what you want to do with health here? I'm also fine with making health and alias for version. Or a slightly dumbed-down version of it.