feat: add tags field to Server Object
Description
This PR adds support for defining Tags at Server Object. They can be used for providing metadata, including the environment such as production, development, etc.
Related issue(s) Fixes https://github.com/asyncapi/spec/issues/654
I would be good to extend some of the official examples, like streetlights for kafka with this feature, as this use case is most common, that Kafka has multiple production servers.
I don't fully get what you mean by Kafka has multiple production servers. Would you mind sharing an example or clarifying it? 🙏
Could make sense to also add example
descriptioninTagsobject.
Good suggestion! I've pushed a new commit with the requested change.
separate question: I think we need to mention at least in this PR that we are aware there is a feature that allows you too specify that some channel is available only on a given server (
CHANNEL_NAME.servers).I somehow feel that people will immediately assume, they can refer not only to a server by server name but the tag too 😄
TBH I don't see the relation between CHANNEL_NAME.servers and the tags. Those are not selectors nor similar.
I don't fully get what you mean by Kafka has multiple production servers. Would you mind sharing an example or clarifying it? 🙏
so with Kafka you can have a cluster of brokers. Related discussion https://github.com/asyncapi/spec/issues/465
I'm pretty sure people will use tag to address above.
TBH I don't see the relation between CHANNEL_NAME.servers and the tags. Those are not selectors nor similar.
Am I really the only one (with Kafka cluster use case in mind) that thinks that people will like to do CHANNEL_NAME.servers=['env:production'] 😄
Am I really the only one (with Kafka cluster use case in mind) that thinks that people will like to do CHANNEL_NAME.servers=['env:production'] 😄
This is a really good point 🤔 Maybe something to consider for 3.0.0?
@fmvilas @dalelane @derberg a last review so we can include this into 2.5 finally?
is this PR resolving #654? I think yes, so please update description
do we agree that this PR also solves #465? 👀 @dalelane that wanted to champion the other proposal
@smoya 👇🏼 was not yet addressed
I would be good to extend some of the official examples, like streetlights for kafka with this feature, as this use case is most common, that Kafka has multiple production servers
and regarding 👇🏼
TBH I don't see the relation between CHANNEL_NAME.servers and the tags. Those are not selectors nor similar.
I think we have an agreement that for 3.0 we want to go $ref-everywhere direction, including CHANNEL_NAME.servers, so I guess we can just leave it as it is without any concerns.
@smoya 👇🏼 was not yet addressed
@derberg I updated the socialmedia, streetlights-kafka and streetlights-mqtt examples. Can you take a look to those? 🙏
Kudos, SonarCloud Quality Gate passed! 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
0.0% Duplication
@dalelane can you have a final look please, ref -> https://github.com/asyncapi/spec/pull/809#issuecomment-1252499990
@dalelane thanks, does it also solve https://github.com/asyncapi/spec/issues/465 from your perspective?
@dalelane thanks, does it also solve #465 from your perspective?
yeah I think so - I'll add a comment there, too
@smoya can you update the description accordingly so the other issue is also resolved after merge, by default?
and then merge 💪🏼
@magicmatatjahu something we might want to support in react component out of the box after release 😉
@smoya can you update the description accordingly so the other issue is also resolved after merge, by default?
and then merge 💪🏼
Done at the same time you posted this comment ⚡ 🏃
@derberg I will remember :)
Looks all good here and ready for 2.5.0, going for a merge. Thanks @smoya!

/rtm
:tada: This PR is included in version 2.5.0-next-spec.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
