This has probably something to do with containers but I don't understand where this comes from, who needs that, who's going to consume it and how. Furthermore there is no corresponding specification update.

If these are [Docker] container labels, a more flexible system might be having a labels section and with all of them there, kinda like buildopts.rpms.macros (free form) or xmd (structured).

Hello, this can be used to generate a Dockerfile out from a module to build a container image containing that module. I will try to provide any remaining information or implement something more general.

@ttomecek ^

Looks like we'll have another architectural discussion about install profiles...

So the question here is if we want to have one artifact type per module, or multiple. The direction we were heading was to have just one. Hence there would be just a single install profile targeted at containers. So the container metadata could live elsewhere, not in profiles (xmd likely?).

This PR is worth discussing before merging/working further on.

Hello, here is a very primitive proof of concept: https://pagure.io/module2Dockerfile

Your PoC clearly shows that this is not complete, since you need to manually specify all RUN and COPY instructions.

I would love to have a face-to-face design discussion about this so all of us can clearly agree on how to approach this problem.

Your PoC clearly shows that this is not complete, since you need to manually specify all RUN and COPY instructions.
I would love to have a face-to-face design discussion about this so all of us can clearly agree on how to approach this problem.

I am all for it! Thank you!

OK - @ttomecek, @clime. Should we close this and re-open it after you two get a chance to discuss?

+1

Ok with me.

We talked about it with @ttomecek and @psabata and a possible alternative suggestion was to make a new section probably specific for containers that would also contain container labels.

I would like to support this PR's solution though. All three items (ports, env, command) are in direct relation with the rpms being installed for a given profile. Also, they are generic across artifact types (hope that I am using the right word here) that you can encapsulate the module with (VM image, container image, host machine, ...).

They also are optional so that if they do not fit into some profile (e.g. you can have mplayer profile listening on certain ports for video streams, then streaming mplayer profile, and then completely passive mplayer profile with no ports open for just casual video watching) or even module (e.g. Perl or Php module probably will have no ports open whereas nginx will), they do not need to be specified.

I am convinced this is a good solution because whatever that other section was, it would need to be in relation with profiles and that's because there it is specified what rpms are installed, which is potentially decisive for open-ports defintion (httpd without mod_ssl won't have 443 open even though this is probably no longer valid use-case) and also environment and command might be different for different rpms installed (e.g. you can have minimal uwsgi profile with no plugins in and then more robust profile with GeoIP plugin installed, which means two additional options for uwsgi --geoip-country, --geoip-city might be used).

There might be better examples for sure but I would like to ask for reconsidering or reopening this PR. I can probably provide better reasoning too if needed.

@psabata also asked for consumers. We would like to generate Dockerfiles for modules built in COPR but I think there might be more use-cases.