Are the metadata records for microservices meant to be immutable?

[Zambito1]

They seem to be treated as immutable in the NATS clients that I have tried, but there is no mention of that in the API specification from what I can find: https://github.com/nats-io/nats-architecture-and-design/blob/main/adr/ADR-32.md

[Jarema]

Hey!
We didn't explicity mark them as immutable, but also did not receive any requests to make them mutable.
Can you please share what is your use case to have them mutable so we can better understand it?

[Zambito1]

We have services that interface with hardware systems, and we want to be able to use the metadata for information about the hardware system that it interfaces with. This information could change within the lifecycle of the service - for example, if the hardware is active or inactive, and a related job ID if the hardware is active.

We actually started building out a custom solution using a KV store, but the info in the KV is essentially just what we would put in the service metadata if the metadata was mutable. It would be nice to avoid the extra KV if we can.

[ripienaar]

To me the information in the meta should describe the service not additional information about where the service is hosted on, those does indeed sound like its better stored in an asset registry or something. Could also be exposed by a particular endpoint that could be used to perform discovery at a higher level

map[string]string seems quite limited for what you're trying to do when you'd probably quickly run into wanting nested hashes or something.

[Zambito1]

To be clear, we are not using the metadata for information about where the service is hosted. When I say "hardware" I am not talking about computers, I am talking about devices that physically manipulate things. I realize that was a little ambiguous.

The problem with making a custom endpoint is that we are effectively reinventing $SRV.INFO for the sole purpose of circumventing the fact that clients handle responses to that endpoint with an immutable structure. We would effectively have $SRV.INFO and CUSTOM.INFO where the former is immutable data managed by the NATS client library, and the latter is mutable data managed by us.

Sure, we would be limited to the record type if we use the metadata field. I looked at the information we are storing in our current custom solution, and it is only string->bool, string->string, and string->enum, each of which fit nicely in string->string. While we have more complex messages, I don't think we would have more complex messages for service information. Anything else would likely make more sense as a data stream (core NATS or Jetstream) rather than service info, regardless of mutability.

[ripienaar]

fair enough, anyway I dont think this should be immutable so we can certainly fix that