What's the difference between "uplink setup" and "gateway setup"?

They seem to ask the same questions ** and generate the same kind of config file.

Except that apparently the gateway protests if the config file exists already, while uplink does it.

Is the intention that I could have entirely different settings for uplink and gateway? (I’m guessing here.) If so, wouldn’t it make more sense to have them use the same config file, but if the user wants different settings, have them switch with --config-dir?

Use case:

  • some app uses the gateway to upload some data
  • I want to check from the command-line that the data is indeed there … if I have a different config file and don’t know it, that would be interesting :slight_smile:

** uplink also asks for an “access name” which I don’t know what that is, and on which I can’t find any info in the documentation.

We’ve actually gone back and forth on this a few times - it used to be the case that the gateway and uplink were the same binary (uplink gateway started the gateway). Then they were different binaries but shared a config file. Then they used different config files (current state). You’re right that the uplink and gateway currently can/do use completely different configuration and settings. Perhaps it’s time to re-evaluate how we got here.

The uplink setup is newer and more indicative of where we’re headed. We recently made it so uplink setup can run more than once (gateway setup still works the old way), and we are working on adding documentation for our access control functionality (e.g. the “access name” features are undocumented but allow you to configure multiple different api keys/satellites for use with a single uplink config, more documentation coming soon)

3 Likes

Another idea: named profiles, with a default of “default” or such, which are subdirectories relative to config-dir that contain the configuration. So there can be as many as the user wants.

(And the gateway systemd.service can be storj-gateway@<name>.service, so one can easily run several in parallel if wanted – just translates into invocation of gateway --profile <name> or such.)

All executables use the same config file, but if it has been setup with uplink, and the gateway is run, gateway setup “augments” the configuration. Of course you could also generate all values needed for the gateway even if the user never uses them; would be even simpler for the user.

This is a potentially very confusing issue for users who use both the gateway (via some software) and the uplink from the command-line, so I second the “perhaps time to re-evaluate” :slight_smile: