Bug 1532540 - Deployment fails when Timezone parameter is set
Summary: Deployment fails when Timezone parameter is set
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo
Version: 12.0 (Pike)
Hardware: Unspecified
OS: Unspecified
Target Milestone: beta
: 13.0 (Queens)
Assignee: Janki
QA Contact: Itzik Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2018-01-09 09:44 UTC by David Juran
Modified: 2018-10-18 07:19 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-06-27 13:41:30 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:2086 None None None 2018-06-27 13:42:00 UTC

Description David Juran 2018-01-09 09:44:45 UTC
Description of problem:

We noticed that if the 'TimeZone' parameter is set in the deployment environments, the deployment fails. In our case, while trying out OpenDaylight

We had an environment file with 

  TimeZone: 'EUROPE/Paris

During the deployment, the overcloud.AllNodesDeploySteps.NetworkerDeployment_Step1.0 fails with the following error:

    fatal: [localhost]: FAILED! => {
        "(outputs.stderr|default('')).split('\n')|union(outputs.stdout_lines|default([]))": [
            "Error running ['docker', 'run', '--name', 'opendaylight_api', '--label', 'config_id=tripleo_step1', '--label', 'container_name=opendaylight_api', '--label', 'managed_by=paunch', '--label', 'config_data={\"start_order\": 0, \"image\": \"\", \"environment\": [\"KOLLA_CONFIG_STRATEGY=COPY_ALWAYS\", \"TRIPLEO_CONFIG_HASH=492379262c6e740c9695ee5dda2be8f6\"], \"user\": \"odl\", \"volumes\": [\"/etc/hosts:/etc/hosts:ro\", \"/etc/localtime:/etc/localtime:ro\", \"/etc/puppet:/etc/puppet:ro\", \"/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro\", \"/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro\", \"/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro\", \"/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro\", \"/dev/log:/dev/log\", \"/etc/ssh/ssh_known_hosts:/etc/ssh/ssh_known_hosts:ro\", \"/var/lib/kolla/config_files/opendaylight_api.json:/var/lib/kolla/config_files/config.json:ro\", \"/var/lib/config-data/puppet-generated/opendaylight/:/var/lib/kolla/config_files/src:ro\", \"/var/log/containers/opendaylight:/opt/opendaylight/data/log\", \"/var/lib/opendaylight/journal:/opt/opendaylight/journal\", \"/var/lib/opendaylight/snapshots:/opt/opendaylight/snapshots\"], \"net\": \"host\", \"detach\": true, \"privileged\": false, \"restart\": \"always\"}', '--detach=true', '--env=KOLLA_CONFIG_STRATEGY=COPY_ALWAYS', '--env=TRIPLEO_CONFIG_HASH=492379262c6e740c9695ee5dda2be8f6', '--net=host', '--privileged=false', '--restart=always', '--user=odl', '--volume=/etc/hosts:/etc/hosts:ro', '--volume=/etc/localtime:/etc/localtime:ro', '--volume=/etc/puppet:/etc/puppet:ro', '--volume=/etc/pki/ca-trust/extracted:/etc/pki/ca-trust/extracted:ro', '--volume=/etc/pki/tls/certs/ca-bundle.crt:/etc/pki/tls/certs/ca-bundle.crt:ro', '--volume=/etc/pki/tls/certs/ca-bundle.trust.crt:/etc/pki/tls/certs/ca-bundle.trust.crt:ro', '--volume=/etc/pki/tls/cert.pem:/etc/pki/tls/cert.pem:ro', '--volume=/dev/log:/dev/log', '--volume=/etc/ssh/ssh_known_hosts:/etc/ssh/ssh_known_hosts:ro', '--volume=/var/lib/kolla/config_files/opendaylight_api.json:/var/lib/kolla/config_files/config.json:ro', '--volume=/var/lib/config-data/puppet-generated/opendaylight/:/var/lib/kolla/config_files/src:ro', '--volume=/var/log/containers/opendaylight:/opt/opendaylight/data/log', '--volume=/var/lib/opendaylight/journal:/opt/opendaylight/journal', '--volume=/var/lib/opendaylight/snapshots:/opt/opendaylight/snapshots', '']. [125]", 
            "stdout: c2127c57bb56951cb62e8e2439145d7ddc4fb6679167144ab616208cf1eef042", 
            "stderr: /usr/bin/docker-current: Error response from daemon: mkdir /etc/localtime: file exists."
        "failed_when_result": true

Version-Release number of selected component (if applicable):

Additional info:

This could be related to https://bugs.launchpad.net/tripleo/+bug/1710129

Comment 1 Sid Ahmed Sadouni 2018-01-09 15:47:48 UTC
This seems specially linked to the opendaylight container. 
We are using the latest version at this time, ie : 12.0-20180104.2.

In another deployment without opendaylight, and with the TimeZone parameter, there is no issue.

Comment 2 Alex Schultz 2018-01-09 20:12:31 UTC
Sounds like the Opendaylight container is improperly attempting to configure the timezone in the container which is mapped from the host.

Comment 6 Nir Yechiel 2018-03-27 09:22:10 UTC
@Janki, can you please take a look at this one?

Comment 7 Janki 2018-03-28 07:23:18 UTC
Yes. Looking into it.

Comment 8 Janki 2018-03-28 14:33:49 UTC
Hi David

I could not reproduce the issue. I tried redeploying overcloud specifying the timezone as follows:

$ cat my_timezone.yaml 
  TimeZone: 'Europe/Paris'

$ cat overcloud_deploy.sh
timeout 100m openstack overcloud deploy \
--environment-file /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml \
-e /home/stack/my_timezone.yaml \

The HA deployment went fine. Timezone was set to be Paris (CET-1CEST,M3.5.0,M10.5.0/3 [1].) in /etc/localtime both on controller nodes and inside ODL container.

Please note the capital letters in "EUROPE" in your description. Can you please try again with small letters? I guess that could be the issue.


[1]. https://remotemonitoringsystems.ca/time-zone-abbreviations.php

Comment 9 Janki 2018-03-28 16:06:46 UTC
And I used OSP13 container images.

I see you are using OSP12 images.

Comment 10 David Juran 2018-04-10 15:52:57 UTC
I currently don't have access to a test environment but I indeed encountered this with OSP12

Comment 11 Janki 2018-04-12 02:34:44 UTC
Assuming this works with OSP13, I am moving this ti ON_QA so that QA and test and verify again. Is that fine Nir?

Comment 12 Nir Yechiel 2018-04-12 06:21:08 UTC
(In reply to Janki from comment #11)
> Assuming this works with OSP13, I am moving this ti ON_QA so that QA and
> test and verify again. Is that fine Nir?

Sure, @Itzik perhaps you or Tomas can try this with RHOSP 13?


Comment 13 Itzik Brown 2018-04-12 15:20:51 UTC
Checked with:

Comment 15 errata-xmlrpc 2018-06-27 13:41:30 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.


Note You need to log in before you can comment on or make changes to this bug.