Compose: Making extension fields valid anywhere in `docker-compose.yaml`

[wesrice]

I've run into a scenario where I think it would be ideal to be able to add x-* extension fields to service definitions in my docker-compose.yaml file, like so:

version: "3.4"

services:
  foo:
    build: ...
    ports: 
      - ...
    x-meta:
      my_var_1: ...
      my_var_2: ...
  bar:
    build: ...
    ports: 
      - ...
    x-meta:
      my_var_1: ...
      my_var_2: ...

I realize that I can "lift" my x-meta info to a valid state, like so:

version: "3.4"

x-meta:
  services:
    foo:
      my_var_1: ...
      my_var_2: ...
    bar:
      my_var_1: ...
      my_var_2: ...

services:
  foo:
    build: ...
    ports: 
      - ...
  bar:
    build: ...
    ports: 
      - ...

However, I'm not a fan of this method because my x-meta structure has to shadow the services definitions object. In complex environments with many service definitions, the effort to maintain parity amongst the two constructs grows. I don't want to overstate this additional effort as a task that is super complex or anything, but frankly it is just a bit inconvenient.

Any thoughts on the possibility of making extension fields valid anywhere within docker-compose.yaml?

[shin-]

I guess I'm curious as to why this would be necessary to begin with, since it makes no practical difference. Can you explain what you're trying to achieve?

[wesrice]

Sure. In my particular situation, I'm parsing a docker-compose.yaml to generate service-specific configuration files for Google App Engine. Google App Engine does not support Docker Compose, but shares familiar concepts with the Compose file, such as defining port bindings or environment variables.

Having a parser reconcile the Compose file service definitions object with an extended field object that contains Google App Engine specific data is trivial. However, from a project management standpoint, I'd like for all configuration of a service, whether Docker or Google App Engine configuration, to reside in the same location.

Is my approach to this scenario ideal? Debatable. Am I leaning on the Compose file more that I should be to solve a larger problem? Probably.

My larger point is that custom meta can be added to the root of the Compose file via extensible fields as a means to aid the development process. Shouldn't it be reasonable for meta to be attached to more objects other than the root for the same purpose?

Fwiw, I think the Open Api Specification is a good example of a spec that allows for extension in this manner. The documentation for each object in the schema section details if the object is extendable via specification extensions or not.

[stale[bot]]

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.

[stale[bot]]

This issue has been automatically closed because it had not recent activity during the stale period.