Shared config across NATS clusters

[3goats]

So I just spun up a 3 node NATS cluster and created some users on node a. in its config file. Will/does this then propagate to nodes b & c or is there something I've missed. Can't seem to find anything on this in the docs.

[derekcollison]

If the users and account information is in the server config (called config mode vs operator mode) you will need that information in all servers.

Operator mode alleviates that need.

[3goats]

Thanks for the reply @derekcollison. So from this I assume the account/user info would then be stored in a key/value store ?

[ripienaar]

Not in a KV, no, but in an account server, you can have accounts without JetStream (required for KV)

[3goats]

Thanks - wow another concept to learn. Other than the docs is there a good place to start to learn more about the NATS terminology and concepts ?

[ripienaar]

Mainly the documentation, you can start really simple and gradually explore. Do not try to start with building the most complex system possible.

[3goats]

Yeah, reading about the Account Server now. The docs say:

While the nats servers can be still configured to use a standalone NATS Account Server, this functionality is now deprecated and it is recommended that the servers should now be configured to use the built-in full NATS based resolver instead

So is it better to use the built-in full NATS based resolver for learning or the NATS Account Server ?

[ripienaar]

Use the recommended option.

However I would start even simpler with simply putting usernames and passwords in a file. Avoiding the account server al together. Once you understand what it does then explore the other options available for configuring accounts and credentials.

[3goats]

Thanks again. So I have a three node cluster. I assume then for now I should use the same file for all three node ?

[ripienaar]

You can use the same file yes

[derekcollison]

FYI we are looking at introducing a new resolver option that does use a JetStream KV..

[3goats]

Ok thanks that's good to know.

[3goats]

@derekcollison any idea of timescales for the new resolver ?

[derekcollison]

Sometime this quarter I would imagine.. It's a high priority for me. But we have a lot of high priority items ;)

[derekcollison]

How critical is it for you?

[3goats]

Well we're in the process of building out a reference architecture using NATS. The plan will be to have many distributed entities calling into NATS that will need accounts. The ability to have these replicated across the cluster will be an important requirement since we're building a sort of a highly distributed service mesh.

[ripienaar]

That sounds like the problem the current built-in account resolver already fixes.

[3goats]

Arh OK - maybe I’m misunderstanding something.

…

Sent from my iPhone

On 4 Jul 2022, at 20:57, R.I.Pienaar ***@***.***> wrote:  That sounds like the problem the current built-in account resolver already fixes. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[derekcollison]

The current resolvers that do full cache can solve this problem today.

I believe there is an issue however that we want to resolve that when an account is deleted the system does not provide negative answers in all cases. /cc @matthiashanel

[3goats]

OK thanks for the heads up. I'll look to do some testing with the existing resolvers.

[3goats]

So to be clear - what problem does the proposed new feature solve ?

[derekcollison]

Will allow negative results for accounts that were deleted, etc. Less machinery, can just use the JetStream which is already baked in.

[3goats]

Thanks

…

Sent from my iPhone

On 5 Jul 2022, at 03:55, Derek Collison ***@***.***> wrote:  Will allow negative results for accounts that were deleted, etc. Less machinery, can just use the JetStream which is already baked in. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.