Bug 1117850 (RHEVM_engine_in_docker_image)

A simple experiment: https://github.com/fabiand/dockerfiles/tree/master/engine

An issue is currently to run engine-setup during the container build:

Step 13 : RUN engine-setup --offline --config-append=/root/complete-answers
 ---> Running in 1812a6d1d295
[ INFO  ] Stage: Initializing
[ INFO  ] Stage: Environment setup
          Configuration files: ['/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf', '/etc/ovirt-engine-setup.conf.d/10-packaging.conf', '/root/complete-answers']
          Log file: /var/log/ovirt-engine/setup/ovirt-engine-setup-20150423143348-00fj3h.log
          Version: otopi-1.3.1 (otopi-1.3.1-1.el7)
[ INFO  ] Stage: Environment packages setup
[ INFO  ] Stage: Programs detection
[ INFO  ] Stage: Environment setup
[ ERROR ] Failed to execute stage 'Environment setup': Command 'initctl' is required but missing
[ INFO  ] Stage: Clean up
          Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20150423143348-00fj3h.log
[ INFO  ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20150423143353-setup.conf'
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ ERROR ] Execution of setup failed
INFO[0025] The command [/bin/sh -c engine-setup --offline --config-append=/root/complete-answers] returned a non-zero code: 1

From today on this can be tested:

With the atomic command the usage is quite easy:

atomic install fabiand/ovirt-engine-3.5
# or
ADMINPW=foo atomic install fabiand/ovirt-engine-3.5

With docker it’s a few more lines:

export IMAGE=docker.io/fabiand/ovirt-engine-3.5
export NAME=ovirt-engine-3.5

# Use a transient (--rm) container to create the real the container
docker run --rm -v /:/host \
  -e FQDN=$(hostname) \
  -e ADMINPASSWORD=${ADMINPW:-ovirt} \
  -e NAME=$NAME \
  -e IMAGE=$IMAGE \
  $IMAGE container/atomic-install.sh

The upstream repository is here:
https://gerrit.ovirt.org/gitweb?p=ovirt-container-engine.git

I tested this on a RHEL 7.1 host. The container itself is CentOS 7.

Because of a host side (docker 1.5 works, 1.6 doesn't) change this line fails:

https://gerrit.ovirt.org/gitweb?p=ovirt-container-engine.git;a=blob;f=Dockerfile;h=4fa88b5a59564c84bf39c7ee731600cd66fd2ad8;hb=HEAD#l35

This is a good example of how a missing isolation can also break containers.

basic sanity testing on this bug:
1. RHAH 7.1.3 released version and docker-1.6.2-14.el7.x86_64
2. atomic install fabiand/ovirt-engine-3.5
3. RHEVM setup automatically successful(complete-answers,oVirt Engine Version: 3.5.2.1-1.el7.centos)
4. Add RHEV Hypervisor - 7.1 - 20150609.0.el7ev into it successful.

currently:
1. we set ports to 443 and 80, how the end-user run more then one docker image for rhevm in the same host?
2. How the end-user set the rhevm setup interactively rather than we set the complete-answers file.
3. how the end-user upgrade the rhevm on docker images? 

Thanks
Ying

For this bug, here we need to define and clear the test scope:
1. which Host we will support officially.
2. which docker version we will support officially.
3. which OS we will support for container itself?(here it is based on which OS rhevm official support)

> 3. how the end-user upgrade the rhevm on docker images? 

Here we can yum update rhevm via repo. Then run engine-setup.
But here I found error:
---
[ INFO  ] Stage: Environment setup
[ ERROR ] Failed to execute stage 'Environment setup': Command 'initctl' is required but missing
[ INFO  ] Stage: Clean up
---

It looks like the engine-setup is looking for initctl. but no /usr/bin/initctl in docker image which image ID: 1dfb55553d7e

Yaniv - I'm trying to understand the use case.
The issue of HE, upgrades, backup-restore, persistent storage - need a lot more details.

(In reply to Yaniv Kaul from comment #9)
> Yaniv - I'm trying to understand the use case.
> The issue of HE, upgrades, backup-restore, persistent storage - need a lot
> more details.

I would ask Itamar about this. It's about ease of installation and testing in a container vs rpms.

Per my discussion with Doron today, I'm putting this RFE on him. 
While I assume we won't be having it for 4.0, we certainly want to detail design it and start implementing some of the required subtasks to achieve this, including upgrade and all.