Expose mig-server-extconfs on development deployments, too.

[jonasbardino]

We also want to be able to override MiGserver.conf values in development. This addition simply mimics the production env with files in persistent root.

[albu-diku]

I understand what this is trying to achieve and support the goal, but question the means. I can’t help feeling this is adding a mechanism that we should not really need: specifically, it feels like a by product of baking too much into the containers.

If one views/arranges containers as just run what they are told, then in development we ought to provide them a development configuration. That is, if you want development containers I’d have expected we just provide them with a development configuration wholesale rather than overriding what happens to be within them.

The complicating factor is the build seals confirmation in, hence we now add a way of override that. I wonder if we could move in the direction of specifying a configuration entirely outside instead?

[albu-diku]

Idea: as part of a site build we must already have the config generated at some stage. If we rearrange the existing build to produce two layers of containers: those with just the built code, and directly derived from them those than include the configuration. The latter are the ones that continue to be started by make up, but the other set would still be there as well as would a directory containing the site configuration that was baked in. Add another make target that allows starting the former and squeezes in the on-disk configuration - which can be customised however is needed.

[albu-diku]

Note, looking again it seems like the facility is already in there. My commentary thus represents the longer term that’s I believe has consensus at least in broad strokes. If you can confirm this is merely explaining existing things then happy to approve - no reason I can see that development builds can’t benefit.

[jonasbardino]

This PR really just extends the existing mechanism for overriding MiGserver.conf options inside containers to also be available in the development flavor. Not sure why that was left out when we added it to the production flavor in PR #106.

The underlying functionality is described in ucphhpc/migrid-sync#244 and it is useful in a number of cases where we simply don't expose all configuration options in generateconfs and the docker .env . It is already used in practice to inject e.g. a number of SITE variables not otherwise exposed and the complete unwieldy Cloud configuration where enabled.

It is not meant to address the need for docker stack restructuring and simplification, and we definitely still aim for that. However, it's a lot easier said than done.