|Summary:||OpenDaylight Container fails to start due to volume mounting destroying ODL etc config dir|
|Product:||Red Hat OpenStack||Reporter:||Tim Rozet <trozet>|
|Component:||openstack-tripleo-heat-templates||Assignee:||Tim Rozet <trozet>|
|Status:||CLOSED ERRATA||QA Contact:||Itzik Brown <itbrown>|
|Version:||13.0 (Queens)||CC:||jchhatba, mburns, rhel-osp-director-maint|
|Target Release:||13.0 (Queens)|
|Fixed In Version:||openstack-tripleo-heat-templates-8.0.0-0.20180304031150||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2018-06-27 13:46:53 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Tim Rozet 2018-03-14 21:03:09 UTC
Description of problem: The volume - /var/lib/opendaylight/etc:/opt/opendaylight/etc is mounted into the docker container, which causes the default config files in /opt/opendaylight/etc in the container to be overridden with an empty directory. Although puppet-generated config files are copied by kolla at container runtime, the puppet-generated config files only include a subset of the deafult config files. Hence, the container constantly tries to restart because the ODL karaf process dies on start. Version-Release number of selected component (if applicable): How reproducible: Everytime Steps to Reproduce: 1. Deploy with ODL 2. 3. Actual results: Running command: '/opt/opendaylight/bin/karaf server' + exec /opt/opendaylight/bin/karaf server karaf: JAVA_HOME not set; results may vary null Error occurred shutting down framework: java.lang.NumberFormatException: null java.lang.NumberFormatException: null at java.lang.Integer.parseInt(Integer.java:542) at java.lang.Integer.parseInt(Integer.java:615) at org.apache.karaf.main.ConfigProperties.<init>(ConfigProperties.java:214) at org.apache.karaf.main.Main.updateInstancePidAfterShutdown(Main.java:228) at org.apache.karaf.main.Main.main(Main.java:193) Expected results: Container starts and stays up.
Comment 1 Tim Rozet 2018-03-14 21:10:25 UTC
A workaround for now is to remove the line from the docker/services/opendaylight_api.yaml file: https://github.com/openstack/tripleo-heat-templates/blob/master/docker/services/opendaylight-api.yaml#L141
Comment 3 Tim Rozet 2018-03-14 21:11:52 UTC
Janki, why was this added in: https://review.openstack.org/#/c/489201/31/docker/services/opendaylight-api.yaml ?
Comment 4 Janki 2018-03-15 04:07:44 UTC
It was added to set upgrade flag to false at https://review.openstack.org/#/c/489201/31/docker/services/opendaylight-api.yaml L169. (I am now thinking if that is the correct place). However, the mount should have copied files from container to host and not delete all the files from container. The reason why this is not happening is because etc/ is not created on host. Correct solution here would be to add '/var/lib/opendaylight/etc' under host_prep_tasks.
Comment 5 Janki 2018-03-15 09:20:46 UTC
(In reply to Janki from comment #4) > It was added to set upgrade flag to false at > https://review.openstack.org/#/c/489201/31/docker/services/opendaylight-api. > yaml L169. (I am now thinking if that is the correct place). > > However, the mount should have copied files from container to host and not > delete all the files from container. The reason why this is not happening is > because etc/ is not created on host. Correct solution here would be to add > '/var/lib/opendaylight/etc' under host_prep_tasks. Adding etc/ on host via host_prep_tasks doesnot solve the problem too. Ideally, all files from container should be copied to host and vice versa when a volume is mounted. Need to find why this is not happening. Meanwhile, we can either not mount etc/ and find another way to change the ODL upgrade flag.
Comment 11 Itzik Brown 2018-04-01 05:56:16 UTC
Checked with: puppet-opendaylight-8.1.0-0.20180321182556.45c4db7.el7ost.noarch
Comment 14 errata-xmlrpc 2018-06-27 13:46:53 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:2086