Add ability to parameterize the FROM

[vbusch]

It would be nice to be able to substitute values for the FROM image. This would enable us to build community images as well, without having a separate file Dockerfile (or using sed).

Could we make the FROM image be configurable?

[jmtd]

I think this is probably a good idea, although there will be a point where to use a different base image you will need to write a new template altogether. For example to base on a non redhat-like image we would need to have a template that used things other than yum, rpm etc. (or even to use dnf for newer redhat-likes, such as modern fedora). So it's a matter for discussion where we draw the line on flexibility with the existing template versus providing (or requiring the writing of) separate templates.

[vbusch]

Docker 1.17, does support this. But I don't know how long it will be before we move up to that version.

[jmtd]

I'm possibly misunderstanding this issue now, but I just looked at dogen/templates/template.jinja and the FROM line is paramaterized, based on the from: and version: keys in the image.yaml.

[vbusch]

In the image.yaml file, I would like to be able to do something equivalent to
FROM: $(IMAGE)
And then when building, pass in either centos:7 or rhel7/rhel

[rwngwn]

I think that making FROM instruction configurable is not enough - you'll probably need to look more deep on next steps - i.e different repository names for yum (SCL for example), similar issue can be with MAINTAINER instruction, also LABELS seems suspicious for me.
Are you sure that images will be really different in FROM instruction?
Even if so I would prefer to write is as a dogen plugin which will not be part of mainline and let image owners maintain it.

[goldmann]

I'm not entirely sure if adding such feature is a good idea. From image POV change of the base image is something that changes the resulting image producing a completely new stack. Additionally - there is a good point about expectations of the scripts. It's highly unlikely to have same scripts / package sets, etc working in both; standard and overridden base image.

I'm voting here for dropping this feature request, I don't see the value. Additionally - image descriptor is not a template. For your use case you can use a custom template with the --template parameter instead.

[jmtd]

Even if so I would prefer to write is as a dogen plugin which will not be part of mainline and let image owners maintain it.

I did wonder about a plugin that let you replace any of the input YAML on the command line, e.g. --rewrite-input /path/in/yaml=newvalue

[rwngwn]

that plugin means, that we can have different image from same image.yaml + template - i.e. you need to commit your run script too, to have reproducible builds. I dont like idea of having such plugin - if you need such behavior you can provide different jinja template via --template and achieve same behavior.

[rcernich]

I think what's key is that it be able to support "like" features and functionality, e.g. having a single yaml for both a redhat/ubuntu or yum/scl is not a reasonable use case, as the integration will most likely be specific to those and thus, not common (as stated above). The simple use case is to support "like" distros, artifacts, integration scripts, e.g. rhel/centos, release/developer builds of artifacts, etc. A simple use case: as a developer, I want to make some changes to a jar and test that out in k8s. The developer shouldn't have to do too much work to make that happen, e.g. -Dmyartifact.url=file:///... -Dmyartifact.skipMd5=true.