Stop deployment task stucked and wasn't transmitted to astute

[Andrey Sledzinskiy]

Stop deployment task stucked and wasn't transmitted to astute

Steps:
1. Create next cluster - Ubuntu, HA, Neutron Vlan, default storage, 1 controller, 1 compute
2. Start deployment
3. Run stop button during provisioning

Expected - provisioning stops and nodes go to bootstrap
Actual - nodes were provisioned and stop task got stucked

{

    "build_id": "2015-08-17_17-24-26",
    "build_number": "185",
    "release_versions":

{

    "2015.1.0-7.0":

{

    "VERSION":

{

    "build_id": "2015-08-17_17-24-26",
    "build_number": "185",
    "api": "1.0",
    "fuel-library_sha": "0062e69db17f8a63f85996039bdefa87aea498e1",
    "nailgun_sha": "4710801a2f4a6d61d652f8f1e64215d9dde37d2e",
    "feature_groups":

            [
                "mirantis"
            ],
            "fuel-nailgun-agent_sha": "e01693992d7a0304d926b922b43f3b747c35964c",
            "openstack_version": "2015.1.0-7.0",
            "fuel-agent_sha": "57145b1d8804389304cd04322ba0fb3dc9d30327",
            "production": "docker",
            "python-fuelclient_sha": "4c74a60aa60c06c136d9197c7d09fa4f8c8e2863",
            "astute_sha": "e24ca066bf6160bc1e419aaa5d486cad1aaa937d",
            "fuel-ostf_sha": "17786b86b78e5b66d2b1c15500186648df10c63d",
            "release": "7.0",
            "fuelmain_sha": "c0e6a17f014d86c8075ee896055a61fbe27e52b0"
        }
    }

},
"auth_required": true,
"api": "1.0",
"fuel-library_sha": "0062e69db17f8a63f85996039bdefa87aea498e1",
"nailgun_sha": "4710801a2f4a6d61d652f8f1e64215d9dde37d2e",
"feature_groups":

    [
        "mirantis"
    ],
    "fuel-nailgun-agent_sha": "e01693992d7a0304d926b922b43f3b747c35964c",
    "openstack_version": "2015.1.0-7.0",
    "fuel-agent_sha": "57145b1d8804389304cd04322ba0fb3dc9d30327",
    "production": "docker",
    "python-fuelclient_sha": "4c74a60aa60c06c136d9197c7d09fa4f8c8e2863",
    "astute_sha": "e24ca066bf6160bc1e419aaa5d486cad1aaa937d",
    "fuel-ostf_sha": "17786b86b78e5b66d2b1c15500186648df10c63d",
    "release": "7.0",
    "fuelmain_sha": "c0e6a17f014d86c8075ee896055a61fbe27e52b0"

}

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/215064

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/215064
Committed: https://git.openstack.org/cgit/stackforge/fuel-astute/commit/?id=6b9e268661b11f981083bac41033223888a6dfcd
Submitter: Jenkins
Branch: master

commit 6b9e268661b11f981083bac41033223888a6dfcd
Author: Evgeniy L <email address hidden>
Date: Thu Aug 20 13:32:39 2015 +0300

    Generate unique names for service queue

    RabbitMQ supports such feature as temporary
    queues with autogenerated names, it means that when you
    define a queue, you leave the name empty, so RabbitMQ generates
    a unique name with "amq.gen-" prefix, after fixing a bug [1]
    with heartbeats, we got working reconnects in case of connectivity
    issues. When reconnect happens, for queues with autogenerated
    names RabbitMQ behaves strangely, it does not delete previous queues
    but creates new one, so for a single worker there is old/not
    used queue and the new one. When new message comes to exchange
    it has 50% chance to get into working queue. If there more
    reconnects happen, more dead queues are created and we have
    less chance to get message in working queue.

    In order to prevent that, each worker should have unique
    name for its service queue, which it will use during worker's
    life time. When reconnect happens, it will try to connect to
    the same queue which was used before.

    RabbitMQ version: 3.3.5
    [1] https://bugs.launchpad.net/fuel/+bug/1483182

    Change-Id: I6a92319af986ee2f76d07ce86d14a6875b836412
    Closes-bug: #1485895

[Liubov Efremova (lefremova)]

Verified on: fuel-7.0-257-2015-08-30_17-23-00.iso

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/234665
Committed: https://git.openstack.org/cgit/openstack/fuel-astute/commit/?id=b60624ee2c5f1d6d805619b6c27965a973508da1
Submitter: Jenkins
Branch: master

commit b60624ee2c5f1d6d805619b6c27965a973508da1
Author: Vladimir Sharshov (warpc) <email address hidden>
Date: Mon Oct 12 19:25:00 2015 +0300

    Move from amqp-gem to bunny

    Differents:

    - separate independent chanel for outgoing report;
    - solid way to redeclare already existed queues;
    - auto recovery mode in case of network problem by default;
    - more solid, modern and simple library for AMQP.

    Also:

    - implement asynchronous logger for event callbacks.

    Short words from both gems authors:

    amqp gem brings in a fair share of EventMachine complexity which
    cannot be fully eliminated. Event loop blocking, writes that
    happen at the end of loop tick, uncaught exceptions in event
    loop silently killing it: it's not worth the pain unless
    you've already deeply invested in EventMachine and
    understand how it works.

    Closes-Bug: #1498847
    Closes-Bug: #1487397
    Closes-Bug: #1461562
    Related-Bug: #1485895
    Related-Bug: #1483182

    Change-Id: I52d005498ccb978ada158bfa64b1c7de1a24e9b0