Fusion command line interface about horizon

[marshall007]

Similar to the other CLI tools already mentioned, see jitsu for further inspiration. They let you do literally everything from the command line, including account creation. You never even have to open up a web browser to get an app deployed and running, which is pretty cool.

I think it makes sense for the app directory to be designated by the presence of a .fusionconf file (or similar). The config file should probably contain things like scaling and db settings so they can exist somewhere as part of the source. fusion deploy should take such settings into account so you don't have to run multiple commands. Likewise, commands like fusion scale should configure the remote machine but also persist the new settings to the config file for you.

[dalanmiller]

After talking with @mglukhovsky, we will want to include ssh functionality into the tool similar to what you can do with docker-machine ssh server_name. You can also run one off commands this way just like you can with normal ssh such as ssh root@server ls -alh /root and docker-machine ssh server ls -alh /root which we should allow.

fusion ssh app [--app app_name]

Allows you to ssh into the actual Docker container running a Fusion app.

fusion ssh server_cluster_node

Allows you to ssh into a node of the Fusion cluster running Fusion apps. (See https://cloud.google.com/container-engine/docs/clusters/)

[coffeemug]

/cc @mlucy @encryptio since they're working on (some of) this stuff right now.

[mlucy]

I agree that fusion verb object is a good way to structure the command. I'm not 100% sure what the subcommands should be, the ones here mostly look good.

One thing I'm not sure of is that I'm not sure you should invoke this through fusion rather than a separate fusion-ops command. It seems a little weird to mix the command that runs the server with the deployment tool. I definitely think fusion-ops should be its own binary, but if we really like fusion ssh etc. we can just make fusion shell out to it.

I'd like to propose that we avoid settling the specific invocations until we're a little further along and have a better idea of what's going to be in v1.

[encryptio]

All of the user-facing API seems good. It makes a few assumptions on what Ops will do that are different than what I expected, but that's a discussion for outside of this issue.

Me and @mlucy were planning on writing the Ops client (which would implement all the subcommands except server listed above) in Go so that they can share data structures and verification routines with the Ops server (which is company internal only.)

With that in mind, my preferred way to implement this would be something like:

(option 1)

• The fusion binary remains in JS, as it is now.
• When called with a subcommand that is supposed to be handled by the ops client (static list of subcommands), it calls out to the fusion-ops-client binary with the exact arguments it was called with, no argument parsing (or errors out and shows hints if the fusion-ops-client executable does not exist)
• The fusion-ops-client can then do whatever and both it and the fusion executable can be modified independently.

The only cross-cutting concern would be when adding new subcommands that the fusion-ops-client wants to handle; they'd need to be added to both projects together. It shouldn't be hard to coordinate releases if needed for that (and often, coordinated releases won't be needed.)

(option 2)
git shows us an alternative design; rename the fusion JS server to fusion-server and add a new top level program that only does multiplexing. Very cleanly separated concerns, but slightly harder to get going, and the benefits are minimal in our case over the above option.

(option 3)
You could of course have the ops client be the fusion binary and only call out to fusion-server for serving, but that seems like a dependency in the wrong direction; an unnecessary complication for first time users.

(option 4)
We implement the fusion ops client in JS and put it in this repo. (bleh)

[marshall007]

I think I prefer option (3), renaming the server to fusion-server and the ops client fusion. In addition to being very cleanly separated as @encryptio mentioned, it's just more obvious what you're calling. I don't think this creates any barriers to getting started. Your options are:

1. Install fusion CLI tools which upon running fusion server will automatically install/update the JS server if necessary.
2. Install fusion-server and execute it directly.

In either case, this is a one-step process for the user. Additionally, I think there are several advantages to this approach:

1. It makes a lot more sense for the CLI to handle a missing/outdated fusion-server dependency than the other way around.
2. There are use-cases for running fusion independently of fusion-server (CI, health checks, etc) and vice-versa (fusion-server contributors, self-host).
3. Having a fusion --server-binary flag is useful in a number of scenarios and option (3) is the only one that doesn't require an additional fusion-server installation.
4. There wouldn't really be any cases in which coordinated releases would be necessary.

---

Option (1) is reminiscent of how the rethinkdb binary works and I've found this to be unintuitive. I don't usually expect the server binary to shell out to other scripts. Also, in the case of rethinkdb, it prevents releases to admin scripts independent of server releases and has resulted in some duplicate argument parsing logic.

---

Option (4) could actually be done without having to put the ops CLI stuff in this repo and (assuming writing the ops client as an npm package isn't a big deal) that might actually be pretty nice! Done this way, you get most advantages of (3), but with a single npm install -g fusion.

{
  "name": "fusion",
  "bin": {
    "fusion": "./node_modules/.bin/fusion",
    "fusion-server": "./main.js"
  }
}

{
  "name": "fusion-cli",
  "bin": {
    "fusion": "./main.js"
  }
}

Note: with this package.json setup, npm i -g fusion installs and symlinks both the fusion and fusion-server binaries for you. If you just want the ops CLI tools, you can still just do npm i -g fusion-cli.

[deontologician]

The horizon cli tool has been split out into its own package. It's in the cli/ directory on next

[deontologician]

@mlucy @encryptio Do you guys have an api we can send commands to to upload an app etc? Or an executable we can distribute with the cli tool?

[encryptio]

We were intending to wrap up the client as an executable for distribution for a few reasons; the two major ones are so that we can share serialization and validation logic, and the other is because there's a bit of tricky logic to invoke ssh/rsync properly (which, of course, cannot be done through the HTTP API)

The client program isn't ready at the moment, but that's the plan.

[deontologician]

So, this issue is hard to classify as "Subsequent" or "Initial release" since it's very broad. Some of this has already been implemented, other stuff needs to be implemented for v1, and other stuff doesn't need to be implemented until later.

@coffeemug any chance you could break this out into sub-issues with priorities?

[coffeemug]

Yes, I'll see what I can do.

[deontologician]

@encryptio this seems to mostly be related to horizon-cloud commands. I assume you guys already have issues for things like horizon status horizon scale etc, or have another direction you want to take

I am going to close for now