Pack Install should be Idempotent

[arm4b]

Current st2 pack install always re-downloads and re-installs the pack, no matter what.

If pack is already installed - we shouldn't reinstall it again, unless some special flag or command specified. Re-downloading/re-installing by default takes time and in fact, it's upgrade (if no version is pinned) or maybe reinstall (if version specified).

Example story is configuration management tools, when you apply playbook/cookbook on a set of machines. Apart of deploying st2, it for example can install a bunch of st2 packs (10-20) on the same machine. And it's normal to run playbook on the same machine several times. Re-downloading/Re-installing packs every time takes time and it's a waste of resources and doesn't guarantee successfull execution every time.

See related discussion https://github.com/StackStorm/st2/pull/2982#discussion_r89614083

[Kami]

I personally like it to keep it simple and idempotent (so just download and reinstall the pack).

Logic to determine if pack is already installed completely would be quite complex (would need to some how very that pack is correctly installed - checksum or similar, files are in place, etc. it's also more problematic because "install" consists of multiple steps which we can't easily make as part of a "transaction") and this introduce all kinda of edge cases probably.

If we can make the whole approach very robust, I would be fine with it though.

[arm4b]

I don't think that current pack install is "really" Idempotent, even when pinning the version st2 pack install github=0.0.4.

We assume it is Idempotent in perfect "vacuum" conditions. But in real life any process involving re-running a bunch of logic could produce different results:

• download failed
• upstream code could change (force push)
• virtualenv-related tasks failed
• pip pack dependencies changed and new dep. versions installed
• register pack may re-enable previously disabled components (rules, sensors, etc), there are reported Issues
• machine is out of disk space which caused failed install
• etc

So the better way is not to change the resource, if it's already in desired state.

But the most annoying thing is that re-applying pack install for already installed packs takes time. For 10-20+ packs (real-life deployments) this can take quite a lot.

If apt-get/yum install would work this way, we'd live in a much more painful world.

---

And yeah, I agree that it could be hard to do the right way, preserving the state and so on. So it's not a super important thing and we can live without it, but it's definitely something that could be nice to have in future :+1:

[nmaludy]

+1