Alternative to this provider

[ahirner]

Since this provider will retire, I wonder if someone can suggest another way to configure jetstreams in a declarative manner.

[ripienaar]

Just fyi: the reason for retiring is that the server has some (and soon more) dynamic behaviours where configuring you put in is not what’s applied or what you get when asking the configuration back

this is inherently incompatible with desired state management. Personally I would love this repo to continue but it seems untenable given above.

[marshauf]

Where can we read up on these dynamic behaviors already implemented and planed?
Are we just talking about Jetstream configuration or even nats-server configuration?

[ahirner]

I guess this amounts to using and potentially improving the k8s operator.
Do you think jetstream behavior can evolve back to terraform-like semantics eventually?

[ripienaar]

K8s operator is facing similar issues since it is also desired state based.

Customer feedback might change things.

[marshauf]

If any desired state based config tool is facing similar issues, isn't the nats-cli and the Synadia Control Plane facing the same issues? At least nats-cli
How will configuring Jetstream work, in the future?

[ripienaar]

CLI and CP are both one-shot, they do not come back and actively manage the stream based on a old config. They operate on what is there so the problem is avoided.

For reference the problem are these:

    "consumer_limits": {
      "description": "Limits of certain values that consumers can set, defaults for those who don't set these settings",
      "type": "object",
      "properties": {
        "inactive_threshold": {
          "description": "Maximum value for inactive_threshold for consumers of this stream. Acts as a default when consumers do not set this value.",
          "$comment": "nanoseconds depicting a duration in time, signed 64 bit integer",
          "type": "integer",
          "maximum": 9223372036854775807,
          "minimum": -9223372036854775807
        },
        "max_ack_pending": {
          "description": "Maximum value for max_ack_pending for consumers of this stream. Acts as a default when consumers do not set this value.",
          "$comment": "integer with a dynamic bit size depending on the platform the cluster runs on, can be up to 64bit",
          "type": "integer",
          "maximum": 9223372036854775807,
          "minimum": -9223372036854775807
        }
      }
    }

If you dont set these values in TF the server will override them. This is kind of managable as we can detect this on the stream and demand its set (tf provider and k8s resources do this)

In future account level settings though will override stream and consumer settings. That's a dead end for this kind of system.

[ahirner]

But is it a dead for configuring properties that are not inherited? (AFAIU, in this case only allow configuration on the account level)

[ripienaar]

Of course we can forever remove features here as the server changes what is inherited etc.

I’d rather not build a crippled solution though

so you got a early deprecation notice - this is fine for the entire 2.10 series (months more) and we might review how things work based on customer feedback.

[bruth]

A quick update.. this particular improvement: nats-io/nats-server#4959 is coming for 2.11. This will lay a better foundation for revisiting declarative tooling including Terraform and the NACK k8s operator.

[Tim-Blyth-SiteHost]

Hi there, any update on the timeline for the new Terraform Provider?

The issue linked was merged Aug 27th but the latest pre-release is v2.10.23-RC.10, not v2.11 yet.

[ripienaar]

The provider now requires nats server 2.11. Until that’s released this is on hold as no one will yet be running that version of nats server.

[Tim-Blyth-SiteHost]

I suppose my question then is the ETA of nats server 2.11, but I imagine that discussion is more productive in https://github.com/nats-io/nats-server/ rather than here: thanks for the response.

[ripienaar]

We do not have a ETA for that