Proposal: CLI for MavenWorks config server

[quigleyj-mavenomics]

Config Server CLI runner

What

This proposal is for a console runner that accomplishes the following:

• Starts the Config Server
• Manages the settings of same (eg, hostname, port, etc)
• Manages objects in the config (eg, users, dashboards)
• Serves the Standalone to go with the Config Server
• [stretch goal] Include a method of adding and removing extensions

These goals will significantly alleviate deployment concerns and offer a pathway to utilize the increasingly robust Config Server that adds functionality to the MavenWorks Standalone client.

Why

Right now, the Config Server must be run from a source checkout. This is inconvenient for a number of reasons:

• Users have to have Git
• Users have to know how to work the build chain
• Users have to know how to resolve environment setup issues
• Users have to know the semi-magical environment variables to configure the server
• Users have to have internet access
• etc... I could go on

It's obvious that we need some easier way of running a config server and deploying it with the front end. One possible approach is a CLI runner, much like how JupyterLab integrates with the jupyter CLI tool to start/manage JupyterLab.

This CLI tool should make it easy to start and manage a ConfigServer. ConfigServers have some settings that should be conveniently exposed via this CLI runner (such as hostname/port, login auth, DB location, etc).

We've also yet to address how plugin management will work. At the risk of bikeshedding what I have no doubt will become the most complicated part of this project, I think there's something spikable that we can do here.

Plan

• [x] Setup a CLI script that works from a local checkout
• [x] Separate ConfigServer core from ConfigServer bootstrap/init
  • Make sure not to break deployments!
  • I'm hoping that we can simply have a different entrypoint...
    • That way the ConfigServer package can still be run directly
• [ ] Change how ConfigServer settings are managed
  • Stop leaning so heavily on environment variables
    • (but leave them in as a useful escape hatch)
  • Things like SQL Db settings need to be saved for object management
  • Allow for a settings file in some place like $XDG_CONFIG_HOME/mavenomics/config.json
• [x] Create a new NPM package with the CLI package
  • Something that it can recognize as a CLI utility and expose

User spec

Assume that the name of the CLI runner is something like mavenworks

• maven would be nice but we can't use that for obvious reasons

Basic commands:

• mavenworks serve (alias mavenworks)
  • Start the server
  • Args: --hostname <url=localhost> -p,--port <number=3000> --ip <addr=localhost>
• mavenworks config (alias mavenworks cfg)
  • Manage config objects in the DB
  • Subcommands
    • add <type> <...args>- Add an object to the config
    • remove <...args> (alias rm)- Remove an object from the config
    • list <...args> (alias ls) List objects in the config
• mavenworks settings
  • Manage settings and save them in a location that serve can read
  • Subcommands
    • set <key> <value>- Set the setting key to value
    • get <key>- Print the value of setting key
• mavenworks debug
  • Print a bunch of paths, versions, and meta info about the environment

[YairMarcowMavenomics]

Next steps: describe and plan out how to do implement the necessary settings management for the standalone client to have to access to