[FEATURE] Add shared configs between components / capability

[jamesstocktonj1]

Affected project(s)

• documentation
• examples
• wasmCloud host
• wasmCloud CLI (wash)
• wasmCloud dashboard UI (washboard)
• capability providers
• provider bindgen
• control interface client
• other / not sure

Is your feature request related to a problem? Please describe.

I would like the ability to be able to share configurations between many components and/or capabilities. This can be useful for a range of situations such as having vaguely related services which need to be configured with the same parameters. One such example could be when you have an event producer and an event consumer that need to be configured to communicate on the same topic.

Describe the solution you'd like

One solution could be a new config type as seen in this example config:

spec:
  components:
    - name: my-global-config
      type: config
      properties:
        topic: my-topic

    - name: producer
      type: component
      properties:
        image: ghcr.io/username/my-producer:0.1.0
        config:
          - name: my-global-config

    - name: consumer
      type: component
      properties:
        image: ghcr.io/username/my-consumer:0.1.0
        config:
          - name: my-global-config

By adding - name: my-global-config to the component config this allows both of the components to be configured with the value topic: my-topic.

Describe alternatives you've considered

With this solution we could also allow a kind of "overriding" of config values such as the following:

spec:
  components:
    - name: my-global-config
      type: config
      properties:
        foo: bar

    - name: component-a
      type: component
      properties:
        image: ghcr.io/username/my-component-a:0.1.0
        config:
          - name: my-global-config
      # resultant config:
      #   - foo: bar

    - name: component-b
      type: component
      properties:
        image: ghcr.io/username/my-component-b:0.1.0
        config:
          - name: my-global-config
            properties:
              foo: bat
      # resultant config:
      #   - foo: bat

This could be a possible solution to avoid overwriting the my-global-config on deployment. But this may make things complicated when it comes to subscribing to config changes.

Additional context

No response

[thomastaylor312]

Thanks for the issue @jamesstocktonj1! So @brooksmtownsend and I had some conversations in person about this before. So you currently can use existing configuration items in a wadm manifest and share those between manifests using exactly what you have above (just specifying the name). However, that means the config has to be created out of band (and before) the wadm manifest is deployed. So you can work around this right now, but it isn't ideal.

The real solution feels like it would be similar to #277 except for config objects. I think a new type: config like you proposed above would be a good way to do it. So my one question is do you expect to use a config across many manifests or just within a single manifest like you have demonstrated above?

Also, going to move this to the wadm repo since it is wadm releated

[jamesstocktonj1]

Hi Thomas, thanks for moving to the right repo. I hadn't seen that proposal of sharing manifests and I don't see why a type: config should behave any differently. That being said could I propose a different solution...

Perhaps a scope value could be assigned to the config to make it crystal clear where it should be visible:

- name: my-global-config
    type: config
    scope: global
    properties:
      foo: bar

- name: my-local-config
    type: config
    properties:
      foo: bar
# my-local-config defaults to local

I know that #277 is currently in progress but thought I'd propose this just to stir things up.

[thomastaylor312]

I'll have to think about that some more. I definitely think a top level config type could be worth it and would automatically be "global." We could keep other config under the link as well and that would be a "local" scope

[brooksmtownsend]

I really like the idea of having configuration be "global" in the manifest sense, e.g. you can define the configuration in the manifest and then refer to it from multiple components/providers/links from within that same manifest 😄 I think it could get a little difficult and fall under the scope of #277 if we wanted to share the configuration between manifests, but I see that being a v2 of this same feature 😄

As for right now, a new type: config should slot in pretty well and is ready for work now! We already have a ConfigScaler, so the bigger piece of implementation will just be ensuring that a "global" config is noted in the "required_config" scalers lists for the components/links/providers