[Feature Request] Support CF metadata

[corporateuser]

Description

It would be helpful to have ability to specify labels and annotations right in mta/mtad files.

Additional information

It would be nice to have something like:

ID: "my-mta"
_schema-version: 3.3.0
version: 1.0.0

modules:
  #A cf app which will be bound to the service
- name: my-app
  type: application
  path: "appBits.zip"
  requires:
    - name: my-service
  parameters:
    instances: 1
    labels:
     environment: staging
     type: core-modules
    annotations:
      last-change:
        author: John Doe
        date: 12-12-12
        commitId: abc4567

[boyan-velinov]

Hello,

Thanks for providing feedback!

multiapps-controller does not provide support to users to modify CF metadata. However, it uses it to store MTA related data.

I would like to understand more about your use case:

• Do you use MTA deployment provided by SAP BTP?
• Do you bring up multiapps-controller on your own?
• What is the end-to-end scenario?
• Is it an option to use CF app env instead?

Best Regards,
Boyan

[corporateuser]

Hello,
I see it as well that metadata is hidden from us in mta/mtad, but in CF manifest it is available.

1. We use SAP BTP
2. We use SAP BTP
3. For now we store in CF space's tag the latest hash, which later we're using to calculate difference between different spaces
4. Possible, but looks not so right

[corporateuser]

Another scenario which came to my mind:
For security validation we need to implement rate limiting. For different type of applications rate limiting should be one of 2 types: jwt-based or host-based. Currently we mark our applications with one of 2 types in our script, and store this configuration there.
It would be a nicer solution to make this a label instead and store this in mta[d] file itself where all the configuration is stored. Then we could simply select all the applications with specific rate limiting type with 1 command or api query.
It is possible to store in env variables as well, but this has its own downsides, like polluting env variables, additional calls.

[boyan-velinov]

The current possible way is to do it with env variables. Support of CF metadata is not in the mid-term roadmap of the service