Updating stackstorm packs does not work about stackstorm-k8s HOT 11 CLOSED

If you just updated st2packs Docker image and re-uploaded it to remote registry under the same tag and expect that Helm will detect the change, - it's not enough.
You need to version your Docker image and change tag/reference in Helm values. Eg. v1.0.0, v1.1.0, or whatever Docker versioning/tagging scheme you'd prefer. Do helm upgrade after that.

This way Helm can understand that st2packs image has changed and trigger downloading new image, replacing old.

from stackstorm-k8s.

Armab is 100% correct, but I'm going to expand on what he said a bit for clarity because I hit this exact same documentation bug a while back, and I think it's worth expanding on.

The problem exists here: https://github.com/StackStorm/st2packs-dockerfiles/blob/master/README.md

The documented docker commands reference using 'latest' as the correct way to tag the image on build, but because of the way helm works, this would actually cause the behavior you are experiencing with the helm upgrade command. Indeed, the Helm documentation will also tell you that using 'latest' as a tag for any docker image within a helm file goes against best practices, since helm files are meant to be versioned.

It would be more useful to say the build command you want to use with the st2-packs image is this:

docker build --build-arg PACKS="<pack names>" -t ${DOCKER_REGISTRY}/st2packs:v0.0.1 st2packs-image

And likewise, when you make any changes to those packs, it should be:

docker build --build-arg PACKS="<pack names>" -t ${DOCKER_REGISTRY}/st2packs:v0.0.2 st2packs-image

Etc and so forth.

You would then, in your helm chart, reference the specific version of docker image you want to pull from the registry. Helm will see that the tag being referenced has changed, and THAT will tell it to make the necessary changes. It ALSO has the simply wonderful side effect of making it capable of reverting those changes if need be.

from stackstorm-k8s.

This is useful 👍

Anyone motivated to submit a README improvement to https://github.com/StackStorm/st2packs-dockerfiles/blob/master/README.md or this chart documentation (https://github.com/StackStorm/stackstorm-ha/) stating a few notes about custom st2packs versioning?

from stackstorm-k8s.

Thanks @Xelinor for improving the documentation, https://github.com/StackStorm/st2packs-dockerfiles#building-the-st2packs-image makes it more clear about st2packs Docker image versioning.

@erenatas Please let us know if that was your issue or not.

from stackstorm-k8s.

@Xelinor @armab , thank you so much for quick responses. I will try and get back to you in a bit. I did not think this would be a problem since that '''register-content''' job starts when I do a '''helm upgrade''' and I can see my modifications in that job's container. I hope this is the solution.

from stackstorm-k8s.

@armab I thought that pullPolicy: Always would do my job but it seems that Helm does not care about that. Thank you so much for your help. I would probably waste a lot of time if you wouldn't help.

from stackstorm-k8s.

@erenatas that would work for re-spinning the entire environment, but helm upgrade is basically doing a slightly more complicated diff comparison. No change in text means no change to the containers.

from stackstorm-k8s.

@armab I was playing with this more yesterday and this morning and there may be an actual bug here too.

ADDING to packs works with versioning, but REMOVING packs or removing actions/rules/etc from them does not. Or, rather, they still show up in the GUI interface, but the actions themselves fail when attempting to be run. There may be a step missing somewhere to clean up mongodb entries maybe? It sorta is behaving like that is the case. Where packs have been removed, the icons are missing but the action list is still there. Attempting to run the action gives:

For instance, if I remove my custom 'nagios_feed_lost' action from my nagios pack:

{
"traceback": " File "/opt/stackstorm/st2/local/lib/python2.7/site-packages/st2actions/container/base.py", line 127, in _do_run
(status, result, context) = runner.run(action_params)
File "/opt/stackstorm/st2/local/lib/python2.7/site-packages/orquesta_runner/orquesta_runner.py", line 89, in run
wf_def = self.get_workflow_definition(self.entry_point)
File "/opt/stackstorm/st2/local/lib/python2.7/site-packages/orquesta_runner/orquesta_runner.py", line 50, in get_workflow_definition
with open(entry_point, 'r') as def_file:
",
"error": "[Errno 2] No such file or directory: u'/opt/stackstorm/packs/nagios/actions/workflows/nagios_feed_lost.yaml'"
}

Likewise, if I connect to one of the actionrunner pods:

root@st2-st2actionrunner-7ccf46664c-bnfl4:/opt/stackstorm/packs/nagios/actions# ll
total 20
drwxrwxr-x 3 root root 4096 Oct 21 19:57 ./
drwxrwxr-x 4 root root 4096 Oct 21 19:57 ../
drwxrwxr-x 2 root root 4096 Oct 21 19:57 pythonactions/
-rwxrwxr-x 1 root root 286 Oct 21 19:26 status_host_metadata.yaml*
-rwxrwxr-x 1 root root 351 Oct 21 19:26 status_service_metadata.yaml*

from stackstorm-k8s.

@Xelinor That's how StackStorm content management works, not related to stackstorm-ha chart implementation.

Because user can create an action via CLI/API, register content/pack install doesn't generate a diff to remove resources which are absent on disk.

from stackstorm-k8s.

Because user can create an action via CLI/API, register content/pack install doesn't generate a diff to remove resources which are absent on disk.

Hmm, fair point. I think that's a reasonable expectation that it should be doing that though. The ST2 CLI has the pack install functions disabled for similar reasons. I'm going to write it up as a feature request.

from stackstorm-k8s.

#93

from stackstorm-k8s.