[adr-32] add meta field to service api

[telemac]

I added an optional meta field to the service definition, this allows to specify some optional meta data to a service instance, like for instance, the Mac address of the machine running the service.

The format is a map in the form {"label": value} where value can be any json type.

I suppose that the typescript definition would be (but I'm not totally sure of that) :

meta?: Record<string, any>

[aricart]

You should be able to calculate such type of information and report it via the custom stats handler. Is this not sufficient?

[telemac]

Hi @aricart, I write services on edge devices, and for each instance of the service I have to know a few informations, architecture, Mac address, to characterize the service. I know those datas at service start, and it is not STAT data, so the stat callback is not the most logical and immediate place to store those service metadata. If I can only retrieve my service meta datas in the STATS endpoint, I probably use this endpoint every time, even if I am not interested in the stats of the service.

In my way of thinking I probably use the stats callback to return datas related to stats, and that are changing along the time, because it is a callback. It seems more natural to me to have the non changing service specific datas set at the service creation in a map, because it won't change, it is known at service startup and a map is a bit easier and natural for this kind of usage, I think. Regardless, I like the micro package very much.

[aricart]

Wondering if the connections info has most of the information you need...

[aricart]

Really what you want is an opaque blob that you can type and have accessible and then perhaps your service handlers can query...

[telemac]

An opaque blob is effectively what I'd like to use, I imagine I'm not the only one that could have that kind of need, it seems to me that every other solution works, but is less easy, immediate and elegant for a common need. I standardized way to attach metas to a service instance feels to me a quite useful feature. As it is optional, it won't be in the way of those that don't have the use, and server well those that have a use for attaching data to a service. The fact that it is defined in the spec can also allow the future interface tools to standardize the access and GUI to that kind of data.

[ripienaar]

Ideally the discovery pings include a way to query such metadata - even if unspecified could be up to service implementers to use something like https://github.com/antonmedv/expr to apply the query to their runtime metadata, this way you can target service instances that match some run time state.

[telemac]

In a (very ?) large deployment, I can see the interest to filter on the service metadatas, certainly.

[ripienaar]

It's not about scope in size its about complexity or the desire to do certain actions only in subsets of service instances

[telemac]

I agree, but what is a nice option, but not a necessity, with a few hundred clients, is certainly more essential with a few millions.

(and I apologize for my less than optimal English, I do my best but it is not always enough...)

[ripienaar]

Yeah the way I described it its essentially enirely opt-in, you only implement it if you need it and then get to pick the matching method

[telemac]

sounds ideal to me.

[bruth]

@telemac added in #205. Client updates will follow