containers not started during deploy if are stopped

Bug #1714015 reported by Eduardo Gonzalez
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kolla-ansible
Fix Released
High
Eduardo Gonzalez

Bug Description

During some tests, I stopped containers with kolla-ansible stop.

Then, executed kolla-ansible deploy to start all containers. This is not the case,
containers are only started if:

- container does not exists
- check_container_differs is true, which imply removing and create new container
- config_strategy == 'COPY_ALWAYS'

    def recreate_or_restart_container(self):
        self.changed = True
        container = self.check_container()
        # get config_strategy from env
        environment = self.params.get('environment')
        config_strategy = environment.get('KOLLA_CONFIG_STRATEGY')

        if not container:
            self.start_container()
            return
        # If config_strategy is COPY_ONCE or container's parameters are
        # changed, try to start a new one.
        if config_strategy == 'COPY_ONCE' or self.check_container_differs():
            self.stop_container()
            self.remove_container()
            self.start_container()
        elif config_strategy == 'COPY_ALWAYS':
            self.restart_container()

Check_container_differs not evaluate correctly as is not noticing the container is not running.

TASK [haproxy : Check haproxy containers] ******************************************************************************************************
ok: [192.168.100.244] => (item={'key': u'haproxy', 'value': {u'group': u'haproxy', u'image': u'192.168.100.1:4000/lokolla/centos-source-haproxy:5.0.0', u'enabled': True, u'volumes': [u'/etc/kolla//haproxy/:/var/lib/kolla/config_files/:ro', u'/etc/localtime:/etc/localtime:ro', u'haproxy_socket:/var/lib/kolla/haproxy/'], u'container_name': u'haproxy', u'privileged': True}})

PLAY [Apply role kibana] ***********************************************************************************************************************

Changed in kolla-ansible:
importance: Undecided → High
Changed in kolla-ansible:
assignee: nobody → Eduardo Gonzalez (egonzalez90)
status: New → In Progress
Revision history for this message
sean mooney (sean-k-mooney) wrote :

at least form me i hit this issue when using COPY_ALWAYS
i was able to force start eh containers by changing to COPY_ONCE then running deploy

ill then use reconfigure later to go back to COPY_ALWAYS.

can we add a dedicated kolla-ansible start/restart which will start or restart all containers in
there order they would be started in a normal deploy.

Revision history for this message
sean mooney (sean-k-mooney) wrote :

ok that did not work but ill get back to this on monday...

Revision history for this message
Eduardo Gonzalez (egonzalez90) wrote :
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to kolla-ansible (master)

Reviewed: https://review.openstack.org/499205
Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=448a10df6cbd53bc93d7b767787ef925169bc3d4
Submitter: Zuul
Branch: master

commit 448a10df6cbd53bc93d7b767787ef925169bc3d4
Author: Eduardo Gonzalez <email address hidden>
Date: Wed Aug 30 17:38:36 2017 +0200

    Add container state check in kolla_docker

    Missing container status check in recreate_or_restart_container,
    this causes if the container is not running (kolla-ansible stop),
    to not be started with deploy/reconfigure/upgrade if any other param
    changes.

    Change-Id: I5cff5f367e963ba8b1807ec46469da817e40e468
    Closes-Bug: #1714015

Changed in kolla-ansible:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/kolla-ansible 6.0.0.0rc1

This issue was fixed in the openstack/kolla-ansible 6.0.0.0rc1 release candidate.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.