CLI UX scratchpad #21

New Issue

decentral1se · 2020-10-22T19:50:04Z

decentral1se commented

2020-10-22 19:50:04 +00:00

I am thinking of what can be a small understandable public interface for abra for the alpha-early-adopters-launch. Just to get us started. This doesn't mean we remove functionality, we just only show certain things as public while we're figuring the rest out.

First stab (some of this functionality doesnt exist yet):

Commands:
  backup      backup an application
  deploy      deploy an application
  delete      delete an installed application
  logs        show logs from a deployed app
  upgrade     upgrade an application
  status      check status of an application
  server      manage server instances

I am thinking of the very alpha-testing usage mode here. You can deploy an app, tail the logs to check it is up. Back the thing up. Upgrade it. Check status of it. Then delete it. You use the server command to manage multiple servers.

Thoughts?

Following https://git.autonomic.zone/autonomic-cooperative/abra/pulls/20 I am thinking of what can be a small understandable public interface for abra for the alpha-early-adopters-launch. Just to get us started. This doesn't mean we remove functionality, we just only show certain things as public while we're figuring the rest out. First stab (some of this functionality doesnt exist yet): ``` Commands: backup backup an application deploy deploy an application delete delete an installed application logs show logs from a deployed app upgrade upgrade an application status check status of an application server manage server instances ``` I am thinking of the very alpha-testing usage mode here. You can deploy an app, tail the logs to check it is up. Back the thing up. Upgrade it. Check status of it. Then delete it. You use the server command to manage multiple servers. Thoughts?

❤️ 1

3wordchant commented

2020-10-23 02:36:01 +00:00

Current commands:

Commands:
  context     manage remote swarm contexts
    create
    init      init swarm and create proxy network
    use       switch to context
  cp          copy files to a container
  deploy      let 'em rip
  logs        tail logs from a deployed service
  multilogs   tail logs from a whole stackk
  run         run a command in the specified service's container
  secret      manage secrets
    generate
    insert
  stack       alias to `docker stack`
  upgrade     upgrade to the latest version
  volume      alias to `docker volume`

Proposed commands:

Commands:
  deploy      deploy an application
  delete      delete an installed application
  logs        show logs from a deployed app
  server      manage server instances
    add
    init
  utils APP   low-level toolbelt
    cp        copy files to a container
    run       run a command in the specified service's container
    stack     alias to `docker stack`
    volume    alias to `docker volume

(down to add backup -- and a restore? -- / upgrade / status when we work out how)

Current commands: ``` Commands: context manage remote swarm contexts create init init swarm and create proxy network use switch to context cp copy files to a container deploy let 'em rip logs tail logs from a deployed service multilogs tail logs from a whole stackk run run a command in the specified service's container secret manage secrets generate insert stack alias to `docker stack` upgrade upgrade to the latest version volume alias to `docker volume` ``` Proposed commands: ``` Commands: deploy deploy an application delete delete an installed application logs show logs from a deployed app server manage server instances add init utils APP low-level toolbelt cp copy files to a container run run a command in the specified service's container stack alias to `docker stack` volume alias to `docker volume ``` (down to add `backup` -- and a `restore`? -- / `upgrade` / `status` when we work out how)

3wordchant commented

2020-10-23 03:16:35 +00:00

I made a start, renaming context to server. 16a0988

I made a start, renaming `context` to `server`. 16a0988

🎉 1

decentral1se commented

2020-10-23 14:20:32 +00:00

Some thoughts:

What does abra server init do?
Do we also need a abra server use ... to pick one too?
I would avoid utils as a pretty ambiguous header, just high-level that stuff under it?
I would hide aliases from the public listing for now, muddies the waters in relation to what is docker doing and what is the CLI doing.

Some thoughts: - What does `abra server init` do? - Do we also need a `abra server use ...` to pick one too? - I would avoid `utils` as a pretty ambiguous header, just high-level that stuff under it? - I would hide aliases from the public listing for now, muddies the waters in relation to what is docker doing and what is the CLI doing.

3wordchant commented

2020-10-23 16:28:30 +00:00

What does abra server init do?

sub_server_init() {
	load_context

	docker swarm init || true
	docker network create --driver=overlay proxy --scope swarm || true
}

Basically makes sure swarm mode is enabled and the proxy network exists.

Do we also need a abra server use ... to pick one too?

Unsure.

I was hoping to maybe avoid the "run a command, then all subsequent docker commands you run, including the command to find out which server you're targeting, run on the remote server" Docker model, by storing app configs in the right server folder as you suggested, but if we diverge it might confuse people who are used to it.

docker context use has a pretty simple user interface so it doesn't seem suuuuuper necessary to have our own.

Short-term I'm happy to keep it in tho.

I would avoid utils as a pretty ambiguous header, just high-level that stuff under it?
I would hide aliases from the public listing for now, muddies the waters in relation to what is docker doing and what is the CLI doing.

Ah right I think I missed you were suggesting keeping other stuff but not listing it in basic usage instructions. Maybe --help-all to list everything?

> What does `abra server init` do? ``` sub_server_init() { load_context docker swarm init || true docker network create --driver=overlay proxy --scope swarm || true } ``` Basically makes sure swarm mode is enabled and the `proxy` network exists. > Do we also need a `abra server use ...` to pick one too? Unsure. I was hoping to maybe avoid the "run a command, then all subsequent docker commands you run, including the command to find out which server you're targeting, run on the remote server" Docker model, by storing app configs in the right server folder as you suggested, but if we diverge it might confuse people who are used to it. `docker context use` has a pretty simple user interface so it doesn't seem suuuuuper necessary to have our own. Short-term I'm happy to keep it in tho. > I would avoid `utils` as a pretty ambiguous header, just high-level that stuff under it? > I would hide aliases from the public listing for now, muddies the waters in relation to what is docker doing and what is the CLI doing. Ah right I think I missed you were suggesting keeping other stuff but not listing it in basic usage instructions. Maybe `--help-all` to list everything?

❤️ 1

decentral1se commented

2020-10-24 14:03:30 +00:00

I was hoping to maybe avoid the “run a command, then all subsequent docker commands you run, including the command to find out which server you’re targeting, run on the remote server” Docker model, by storing app configs in the right server folder as you suggested, but if we diverge it might confuse people who are used to it.

Ahhhh gotcha, yes, perfect!

I would avoid utils as a pretty ambiguous header, just high-level that stuff under it?
I would hide aliases from the public listing for now, muddies the waters in relation to what is docker doing and what is the CLI doing.

Ah right I think I missed you were suggesting keeping other stuff but not listing it in basic usage instructions. Maybe --help-all to list everything?

👍

> I was hoping to maybe avoid the “run a command, then all subsequent docker commands you run, including the command to find out which server you’re targeting, run on the remote server” Docker model, by storing app configs in the right server folder as you suggested, but if we diverge it might confuse people who are used to it. Ahhhh gotcha, yes, perfect! >> I would avoid utils as a pretty ambiguous header, just high-level that stuff under it? >> I would hide aliases from the public listing for now, muddies the waters in relation to what is docker doing and what is the CLI doing. > > Ah right I think I missed you were suggesting keeping other stuff but not listing it in basic usage instructions. Maybe --help-all to list everything? 👍

decentral1se commented

2020-10-26 09:14:28 +00:00

OK, I've been following the git example (i know, i know, but hear me out) and actually git --help is really quite instructive. As long as we don't end up calling any of our subcommands reflog or whatever haha.

See #18 (comment).

OK, I've been following the `git` example (i know, i know, but hear me out) and actually `git --help` is really quite instructive. As long as we don't end up calling any of our subcommands `reflog` or whatever haha. See https://git.autonomic.zone/coop-cloud/abra/issues/18#issuecomment-1663.

decentral1se commented

2020-10-26 17:16:00 +00:00

OK, gonna close this off, think we're on a good track now.

decentral1se closed this issue

2020-10-26 17:16:00 +00:00

3wordchant referenced this issue from a commit

2020-10-27 16:00:18 +00:00

.abra dir, `abra new` Closes #24 Ref #21

This repo is archived. You cannot comment on issues.