trustd arguments: should we go back to subcommands?

[jcrossley3]

Somehow I've found myself in the midst of trying to address #135, #171 and #173 simultaneously. I'm attempting to do it -- poorly so far -- in #174. Consider this discussion a cry for help.

Here are the assumptions I was making:

• We'd like a friendly CLI for "PM mode" that transparently initializes a database and runs a REST API against it.
• We'd like trustd to have no subcommands, i.e. there's never a reason for it to do significantly different things when you run it. It's a self-contained, data-driven REST API.

Apparently, I was mistaken about the 2nd one, but I'll let Bob explain that below. 😄

My problems arose initially because the managed data wasn't being preserved across restarts of "PM mode". This was difficult to diagnose because the app was failing silently even though it was attempting to log error messages. This was because the env_logger wasn't initialized and our convention is to do that once-and-only-once in Infrastructure::run which we currently only do in the REST server, hence #135.

I don't like that trustd's args consist mostly of all of the server's args. This seems to be a cry for a subcommand, imo.

Further, trustd is doing a lot more work -- currently initializing a managed database -- than our old trust command, which was really just a delegator of subcommands that each then assumed the responsibility of Infrastructureing.

So I think an argument can be made already for trustd to have 2 subcommands:

• trustd api
• trustd db

This is the path of least resistance: we keep Infrastructure in the server only and close #135. We simplify trustd by moving all the db stuff out into a separate module (which should probably be done, regardless).

To be clear, I'm not arguing for subcommands. I'd like for trustd to be a single, self-contained, data-driven app that provides a REST API. To do that right, I don't think it was enough to replicate only the fields of the server's Run struct to Trustd. Most of the logic that used those fields should be moved as well. And that's the path of most resistance.

I'm happy to follow that resistant path but not if the "no subcommands" mantra is wrong.

So, should we make trustd dumb, like the old trust?

[bobmcwhirter]

The two ideas I'm trying to keep in my brain simultaneous, without regard to how it's implemented are:

1. The default trustd with no arguments (PM Mode) should run everything (including serving the UI some day). This includes the REST API, the data-driven importer loops, serving the UI, and whatever else we can dream up as things progress.
2. It should also be possible, in the case of production scalability, for each unit (module?) to be executed separately, sharing the same underlying database, but distributing the CPU load across multiple pods. Currently only thinking "run the importer" and not "run 3 instances of the importer to scale it specifically".

[carlosthe19916]

Based on the assumption that the "old" trust is referring to the trustification repository:

• How I saw it working: A single binary with multiple commands; each command starting a different app/service.
• The problem I saw in it: It is a big binary that includes "everything". Even for starting the UI (in the trustification repo) we need to use the single binary that includes "everything" when in fact the UI only needed part of the whole binary (unnecessary crates/modules included into the binary whose purpose is just to run the UI).

Multiple Commands (single binary) vs multiple binaries (single command)

• Multiple commands (single binary): This is what I saw in the trustification repository and as I mentioned above, in my opinion it creates a big binary when in fact, perhaps the component/part a user is interested is just a small set of it. I don't know if multiple commands add complexity to the code or not, that I'll leave it to your own opinion
• Multiple binaries (single command): this is what in my opinion we should do. If we plan to have multiple "commands" then why are we wrapping them in a single binary? couldn't we just create 2 different binaries for each one, each binary can include multiple internal crates/modules. e.g.
  • trustd api becomes trustd-api (a single binary). And this binary contains crate/module A,B,C
  • trustd db becomes trustd-db (a single but different binary compared to the previous one). And this binary contains crate/module C/D

I am more in favor of Multiple binaries (single command). Not sure how complex that might be in Rust, but coming from a Java world it was as easy as defining maven modules and defining module dependencies between them, then multiple executables can be created out of a single project

I agree with @bobmcwhirter in regards of being able to serve the PM mode with a single command but that is just for demo purposes; for production environments we will need to execute each part of the app separately.

Binary Arguments

just a comment, not really an answer to the discussion's question: Trustify is a command line app that requires arguments to be passed to be initialization. While I don't see anything wrong there I just wanted to share that the more complex the app is the more arguments we will need to pass therefore the app should not rely a lot on arguments but more on "environment variables" or configuration files. Otherwise the arguments are too long that becomes a nightmare.

[carlosthe19916]

I'd like to also add that having a single command to rule everything would be ideal. It is valid to have dreams about "ideal things" :)

[jcrossley3]

FWIW, I'm fine with multiple binaries. That's easy. And we can just remove trustd entirely.

PM mode might be most easily encapsulated within a shell script, e.g.

./trustify-db create
./trustify-api &
./trustify-ingest &
./trustify-ui &

But I think more than a few quickly becomes unwieldy in docs and looks unprofessional, imo.

[ctron]

shell script

Powershell, Mac OS shell (bash 3), bash 4 (5?) …

I think having multiple sub-commands makes sense. I also think having a default subcomment (pm mode) makes sense too. Going for multiple binaries will make the build more complex, and container creation too. It will lead to bigger to containers, or lead to more containers. Both is not ideal.

So I think we should bring back sub-commands, and have a default "run it all for PM" sub-command as a default.

[jcrossley3]

So I think we should bring back sub-commands, and have a default "run it all for PM" sub-command as a default.

wfm