Open MagicRB opened 2 years ago
The coffer server may itself have multiple other backends - how would that work?
The way I see it, it should work like this:
Say you have a config.toml:
main_backend = "bk1"
[[backend]]
type = "vault-kv"
name = "bk1"
address = "localhost:8200"
mount = "secret"
token = "<vault token>"
[[backend]]
type = "coffer-server"
address = "<some address>"
token = "<some credentials or whatever>"
coffer-server
config does not have a name<some address>
which backends it supports. Let's say the server supports backends bk2
and bk3
.bk1
,bk2
and bk3
.coffer view bk1#/
, coffer view bk2#/
or coffer view bk3#/
. Internally, the coffer CLI will route requests accordingly.What do you think?
BTW, this issue is blocked by #37
Actually, what I proposed above may lead to ambiguity, e.g., when config.toml
contains config for two different coffer-server
s, and both have a backend with the same name.
This means that a coffer-server
config really does need a name, and that the user should specify which coffer-server
and which of its backends they want to use, e.g.:
[[backend]]
type = "coffer-server"
name = "cs1"
...
[[backend]]
type = "coffer-server"
name = "cs2"
...
$ coffer view cs1/bk1#some/path
$ coffer view cs2/bk1#some/path
Yeah, i was thinking
[[backend]]
type = "coffer-server"
name = "cs1"
remote-name = "vault"
What were missing is authentication, that's a pretty big part
remote-name = "vault"
That would imply the user would "have to" re-declare each and every backend, right? If the server has 3 configured backends, the user would have to declare 3 [[backend]]
s on their local config file, right?
I think the auto-discovery I proposed would be a lot easier to configure. On the other hand, it would also make it slightly harder to use commands (e.g. coffer create cs1/bk1#path
instead of coffer create cs1#path
).
I guess both approaches have both pros and cons, I'm okay with either approach.
@DK318 and @Heimdell: what do you think?
I guess both approaches have both pros and cons, I'm okay with either approach.
What i was thinking is that first we'd do approach one and then implicitly auto generate the remote backends and merge them implicitly with the users config file
So the auto import would be a continuation of this
Let's postpone this issue until we have a fully ready MVP.
Clarification and motivation
A special backend which exposes a HTTP coffer instances backend as a local backend. The use case is having a remote coffer instance which accesses some internal service, for example vault and using that from the CLI. It would essentially be equivalent to the current web frontend but in the terminal.
Acceptance criteria
New functional remote backend and associated tests.