Is there a reason, why there is no ressource to add User ?

[fasibio]

What motivated this proposal?

Want to add new User. to split permission f.E. new users

What is the proposed change?

Make it possible to Add new User, so each serivce with connection to nats can create his own user by deployment and use them by deployed service.

Who benefits from this change?

User is a "ressoure" as well. so it make sense this is manageable

What alternatives have you evaluated?

No response

[ripienaar]

Never had a request for this tbh, with the user store being just files on your local disk it’s kind of weird.

We are working on a library that supports pluggable stores like maybe jetstream KV and that could be used for something like this but it’s some way off.

[fasibio]

Oh i am not sure if with missunderstand each other, so i will try to explain with other words. At the moment i use nsc add user -a $NATS_ACCOUNT_NAME -n $NATS_USER_NAME and its hard to handle this value by service creation. So the idea was to handle this over TF.

resource "jetstream_user" "SERVICE_A" {
  name = "service A "
  account= "FOO"
 allow-pub =  ["A.*", "B.>"]
allow-sub = [...]
... 
}

But I understand what you mean. This Ressource will only be handled locally... I am also not sure... but its hard to handle this dezentral at the moment..

[ripienaar]

Yes, I know that's what you want to achieve. I am saying nsc only really just store the "database" in your local machine, thats not really what TF is for.

Eventually we could support other data stored for nsc, like a stream or kv, and then having a TF provider make sense.

Further nsc has no API for anything else to build on. We are currently building that API to enable this kind of thing (though nats CLI will be first target)

[fasibio]

Yes, I know that's what you want to achieve. I am saying nsc only really just store the "database" in your local machine, thats not really what TF is for. => I am not 100% agree here.

I understand you point but ressources like f.E.:

random_password also store this data only locally.

[ripienaar]

Just because they do a bad thing doesnt mean we should :)

But no, the way the terraform random resource works is by using unique seeds to generate preditcable outputs and then to store it in the state. Same as any other TF resource. For state resiliance it can go in remote stores like S3 or whatever. The fact that it starts as single use local storage is nice to start with but not how you use terraform in production.

In constrast with nsc a local disk store is the only possible supported store right now and there are no other options, this is not in line with how TF is used or what its for.

Once we have network stores for the nsc database we can revist, for now I am afraid its not something we'll work on.

[ripienaar]

Closing in favour of https://github.com/nats-io/terraform-provider-jetstream/issues/129