Allow grouping of servers by stage/environment

[gervaisb]

It is common to have many servers for the same stage (dev, test, acc, ..), the variable substitutions into the server object can help but the substitution can also be problematic when there is some restriction on what can be substituted.
A solution is to create different servers however, there is nothing to group them and to restrict the usage of servers from different stages.
I can be interesting to have a group attribute in server:

Configuration:

• dev-master-1:1234
• dev-master-2:1234
• dev-slave-1:4321
• dev-slave-2:4321
• test-master-1:1234
• test-master-2:1234
• test-slave-1:4321
• test-slave-2:4321

Current:

servers:
  - url: dev-master-{node}:1234
    variables:
      node:
        enum:
          - '1'
          - '2'
  - url: dev-slave-{node}:4321
    variables:
      node:
        enum:
          - '1'
          - '2'
  - url: test-master-{node}:1234
    variables:
      node:
        enum:
          - '1'
          - '2'
  - url: test-slave-{node}:4321
    variables:
      node:
        enum:
          - '1'
          - '2'

Proposal:

servers:
  - url: dev-master-{node}:1234
    group: dev
    variables:
      node:
        enum:
          - '1'
          - '2'
  - url: dev-slave-{node}:4321
    group: dev
    variables:
      node:
        enum:
          - '1'
          - '2'
  - url: test-master-{node}:1234
    group: test
    variables:
      node:
        enum:
          - '1'
          - '2'
  - url: test-slave-{node}:4321
    group: test
    variables:
      node:
        enum:
          - '1'
          - '2'

[fmvilas]

That's a great suggestion. Thanks for sharing! I'm not going to add anything to the spec in the short term but I'll take into account for future features.

Anyone interested in this feature, please upvote it so that I know if this is something urgent or not.

[lwielek]

@fmvilas
@gervaisb

Slightly different, but similar issue.
An application publishes/subscribes to 2 separate message brokers (clusters).
Some topics exist only on the first message broker, while others exist on the other.

Besides the server.group field, it would be nice to have e.g. topic.serverGroup field, that would identify the message broker, which actually maintains the topic.

[fmvilas]

@lwielek that's an interesting approach to consider too. Would you mind creating a proposal?

[lwielek]

@fmvilas
Proposal

servers:
  - url: api.streetlights.smartylighting.com:1234
    scheme: mqtt
    description: API broker
    group: api
  - url: audit.streetlights.smartylighting.com:1234
    scheme: mqtt
    description: Audit broker
    group: audit
  
topics:
  event.{streetlightId}.lighting.measured:
    serverGroup: api
    publish:
      $ref: '#/components/messages/lightMeasured'
  event.lighting.audit:
    serverGroup: audit
    publish:
      $ref: '#/components/messages/auditMessage'

[fmvilas]

Sorry, I meant creating a separate issue as the problem is different. As part of the proposal, I'd like to understand:

• What's your use case?
• Why it can't be done right now? or, how it would improve the current way of doing it?
• Areas of the spec that might get affected.
• Other considerations.

Thanks!

[lwielek]

@fmvilas Created #244

[fmvilas]

Thanks, @lwielek! Great job describing the feature.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 30 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[smoya]

This was solved by #654