StackStorm / st2

StackStorm (aka "IFTTT for Ops") is event-driven automation for auto-remediation, incident responses, troubleshooting, deployments, and more for DevOps and SREs. Includes rules engine, workflow, 160 integration packs with 6000+ actions (see https://exchange.stackstorm.org) and ChatOps. Installer at https://docs.stackstorm.com/install/index.html
https://stackstorm.com/
Apache License 2.0
6.05k stars 745 forks source link

`st2 pack install` will ignore failures when installing multiple packs #4620

Open LindsayHill opened 5 years ago

LindsayHill commented 5 years ago
SUMMARY

If I attempt to install multiple packs using st2 pack install, and one of those packs is non-existent, it will silently ignore the failure.

ISSUE TYPE
STACKSTORM VERSION

st2 3.0dev (d86747c), on Python 2.7.12

OS / ENVIRONMENT / INSTALL METHOD

one-line install.

STEPS TO REPRODUCE
extreme@ubuntu:~$ st2 pack install foobar acos

For the "foobar, acos" packs, the following content will be registered:

rules     |  0
sensors   |  0
aliases   |  0
actions   |  19
triggers  |  0

Installation may take a while for packs with many items.

    [ succeeded ] download pack
    [ succeeded ] make a prerun
    [ succeeded ] install pack dependencies
    [ succeeded ] register pack

+-------------+-----------------------------------------------+
| Property    | Value                                         |
+-------------+-----------------------------------------------+
| name        | acos                                          |
| description | Manage ACOS-based appliances of A10 Networks. |
| version     | 0.2.5                                         |
| author      | Hiroyasu OHYAMA                               |
+-------------+-----------------------------------------------+
extreme@ubuntu:~$
EXPECTED RESULTS

I expected some error message about "pack foobar not found", similar to if I had just tried st2 pack install foobar

ACTUAL RESULTS

Install completes 'successfully', since one pack install works.

amanda11 commented 4 years ago

Did a bit of investigation.

  1. If I install one pack that doesn't exist (local or remote) then we get a failure
  2. If I install two packs and one doesn't exist, then: a. if it is a download fail on a local pack - we error at the download stage b. if it is a download fail as we can't find the repo_url (e.g. remote non-exist) - then we silently ignore it

st2common/st2common/util/pack_management.py's download_pack will: a) throw an exception if we can't find pack in local repo (https://github.com/StackStorm/st2/blob/master/st2common/st2common/util/pack_management.py#L144-L146) b) return a tuple indicating failed to find and remote (https://github.com/StackStorm/st2/blob/master/st2common/st2common/util/pack_management.py#L109-L112) c) return a tuple indicated ok if successful (https://github.com/StackStorm/st2/blob/master/st2common/st2common/util/pack_management.py#L174)

Then in contrib/packs/actions/pack_mgmt/download.py we: a) raise an error if when we go through the tuple we don't find at least one success.(https://github.com/StackStorm/st2/blob/master/contrib/packs/actions/pack_mgmt/download.py#L100-L112 b) if at least one succeeded then the sanitized_result does NOT include the True/False for that pack to indicate if it were successful or not. Therefore we'd need to change the API result to include the true/false if we want to download all remotes that we can but still indicate what failed.

So I'm just wondering if the expected results for this situation if one pack succeeds, and one fails should be either:

  1. always fail at download regardless of whether its local or remote url OR
  2. only fail at download if its remote, and then report in the result which ones succeeded or failed.

I would have thought it might be better to be consistent and fail at the download if one of the packs referenced doesn't exist, but do not know if there is a historical reason or other consequences why download fail of a remote is different to not finding a local directory.

winem commented 3 years ago

I just verified that this issue still persists on st2 3.5.0

There is a slight difference in the output depending on the position of the non-existing pack.

  1. non-existing pack as the last argument:

    
    root@st2-launchdev-u20:~# st2 pack install netbox foorbar
    
    [ succeeded ] init_task
    [ succeeded ] download_pack
    [ succeeded ] make_a_prerun
    [ succeeded ] get_pack_dependencies
    [ succeeded ] check_dependency_and_conflict_list
    [ succeeded ] install_pack_requirements
    [ succeeded ] get_pack_warnings
    [ succeeded ] register_pack

+-------------+--------------------------------+ | Property | Value | +-------------+--------------------------------+ | ref | netbox | | name | netbox | | description | NetBox DCIM | | version | 2.0.0 | | author | John Anderson, Jefferson White | +-------------+--------------------------------+


2. if there is any existing pack after the non-existing one: 

root@st2-launchdev-u20:~# st2 pack install git foorbar netbox

For the "git, foorbar, netbox" packs, the following content will be registered:

actions | 301 rules | 1 sensors | 2 aliases | 0 triggers | 0

Installation may take a while for packs with many items.

[ succeeded ] init_task
[ succeeded ] download_pack
[ succeeded ] make_a_prerun
[ succeeded ] get_pack_dependencies
[ succeeded ] check_dependency_and_conflict_list
[ succeeded ] install_pack_requirements
[ succeeded ] get_pack_warnings
[  running  ] register_pack
[ succeeded ] register_pack

+--------+--------+-------------+---------+--------------------------------+ | ref | name | description | version | author | +--------+--------+-------------+---------+--------------------------------+ | git | git | Git SCM | 1.0.0 | StackStorm, Inc. | | netbox | netbox | NetBox DCIM | 2.0.0 | John Anderson, Jefferson White | +--------+--------+-------------+---------+--------------------------------+



So the number of actions, rules, ... to be registered is only shown if the non-existing pack is not the last one in the list.