spec icon indicating copy to clipboard operation
spec copied to clipboard

feat: add tags field to Server Object

Open smoya opened this issue 3 years ago • 9 comments

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

smoya avatar Jun 17 '22 15:06 smoya

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

sonarqubecloud[bot] avatar Jul 20 '22 15:07 sonarqubecloud[bot]

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 description in Tags object.

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.

smoya avatar Jul 20 '22 15:07 smoya

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'] 😄

derberg avatar Jul 25 '22 16:07 derberg

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 avatar Jul 25 '22 17:07 fmvilas

@fmvilas @dalelane @derberg a last review so we can include this into 2.5 finally?

smoya avatar Sep 20 '22 14:09 smoya

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.

derberg avatar Sep 20 '22 15:09 derberg

@smoya 👇🏼 was not yet addressed

@derberg I updated the socialmedia, streetlights-kafka and streetlights-mqtt examples. Can you take a look to those? 🙏

smoya avatar Sep 21 '22 14:09 smoya

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

sonarqubecloud[bot] avatar Sep 21 '22 14:09 sonarqubecloud[bot]

@dalelane can you have a final look please, ref -> https://github.com/asyncapi/spec/pull/809#issuecomment-1252499990

derberg avatar Sep 21 '22 14:09 derberg

@dalelane thanks, does it also solve https://github.com/asyncapi/spec/issues/465 from your perspective?

derberg avatar Sep 22 '22 08:09 derberg

@dalelane thanks, does it also solve #465 from your perspective?

yeah I think so - I'll add a comment there, too

dalelane avatar Sep 22 '22 08:09 dalelane

@smoya can you update the description accordingly so the other issue is also resolved after merge, by default?

and then merge 💪🏼

derberg avatar Sep 22 '22 08:09 derberg

@magicmatatjahu something we might want to support in react component out of the box after release 😉

derberg avatar Sep 22 '22 08:09 derberg

@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 ⚡ 🏃

smoya avatar Sep 22 '22 08:09 smoya

@derberg I will remember :)

magicmatatjahu avatar Sep 22 '22 08:09 magicmatatjahu

Looks all good here and ready for 2.5.0, going for a merge. Thanks @smoya!

char0n avatar Sep 22 '22 08:09 char0n

derberg avatar Sep 22 '22 08:09 derberg

/rtm

char0n avatar Sep 22 '22 08:09 char0n

: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:

asyncapi-bot avatar Sep 22 '22 08:09 asyncapi-bot