Re: [atomic-devel] The atomic command and setting hostname for containers

[Daniel J Walsh <dwalsh redhat com>]

On 02/17/2016 10:25 AM, Jan Pazdziora wrote:
> Hello,
>
> with the atomic command, we can run
>
> 	atomic install ...
>
> to configure a service in/via a container and
>
> 	atomic run ...
>
> to start it.
>
> If the software in the container would like to have a particual fixed
> hostname set, specified by the user/admin, the LABEL INSTALL and/or RUN
> have to specify
>
> 	docker run --cap-add=SYS_ADMIN
>
> for hostname command in the container to be able to change the
> hostname, which is an overkill especially give the fact that docker
> itself gives us a way to specify the hostname.
>
> It'd be nice if the atomic command could support -h option, and make
> that value available for use in the INSTALL / RUN / UNINSTALL LABELs.
> I envision something like
>
> 	docker install -h ipa.example.com freeipa-server --realm EXAMPLE.COM ...
>
> and
>
> 	docker run freeipa-server
>
> and be able to use
>
> 	LABEL INSTALL 'docker run -h ${OPT_HOSTNAME} ... ${IMAGE} ...'
>
> and
>
> 	LABEL RUN 'docker run -h ${OPT_HOSTNAME} ... ${IMAGE} ...'
>
> and have that OPT_HOSTNAME expand to
>
> 	-h ipa.example.com
>
> Of course, if we wanted for admin to only specify the hostname once
> during atomic install, the value would have to survive somewhere for
> subsequent atomic run events. I'm not sure how to do that though,
> to fit the rather state-less nature of atomic (utility).
>
> One possibility is to specify for example
>
> 	the value of -h option of atomic install is stored in
> 	/etc/${NAME}.hostname file and that file is consulted for
> 	all atomic operations (that touch containers) and its content
> 	made available in OPT_HOSTNAME
>
> But this really gets us into the business of defining "storage" for
> container configuration. Another possibility would be for the INSTALL
> container to handle it. For example, in the install.sh, the current
> value of $(hostname) could be stored to whatever /host/... location
> the container would like, and then we could come up with new LABEL
> RUN_HOSTNAME_LOCATION that atomic would evaluate and use for
> OPT_HOSTNAME.
>
> So the Dockerfile bits would be
>
> 	LABEL INSTALL 'docker run -h ${OPT_HOSTNAME} -h /:/host ${IMAGE} ...'
> 				# Just use the -h option of atomic here
> 	LABEL RUN_HOSTNAME_LOCATION '/etc/${NAME}/hostname'
> 	LABEL RUN 'docker run -h ${OPT_HOSTNAME} ... ${IMAGE} ...'
> 				# Get content of /etc/${NAME}/hostname
> 				# and if not empty, replace OPT_HOSTNAME
> 				# with it
>
> and install.sh would do
>
> 	hostname > /host/etc/${NAME}/hostname
>
> Is the idea of having hostname handling support in atomic command
> acceptable?
>
> Is introducing new LABEL like RUN_HOSTNAME_LOCATION which would be
> consulted for location of the hostname value acceptable?
>
> I've checked that
>
> 	docker run -h '' ...
>
> sets the hostname to the container id so if the ${OPT_HOSTNAME}
> replacement correctly puts in empty string parameter, things should
> work.
>
> I can prepare patch but I wanted to get some preliminary feedback
> about the idea and direction.
>
> Thank you,
>
atomic install can create a container, which includes the hostname you
want to set, then atomic run will just start the container
Or atomic install could create a k8s json file or systemd unit file with
the name saved.

One thing you could do now, is force the hostname as an environment
variable or require the user to specify the hostname in the install

# atomic run foobar
error:  You must specify hostname

# atomic run foobar ipa.example.com


Or you could pass the hostname as an environment variable.

HOSTNAME=ipa.example.com atomic run foobar

Adding yet another label does not seem to be a great idea.