Salt minion provisioning: cleanup after provisioned

[davidkarlsen]

It would be nice to call saltutil.clear_cache after finishing provisioning - this would clear out the salt minion cache in /var/cache/salt/minion .

Now I have to add this in my Vagrantfile:
config.vm.provision :shell, :inline => "salt-call saltutil.clear_cache"

[obestwalter]

Forcibly removes all caches on a minion.
New in version 2014.7.0.
WARNING: The safest way to clear a minion cache is by first stopping the minion and then deleting the cache files before restarting it.

link

@davidkarlsen I am not quite sure, why I would want this by default. I am not using it in my setups and it doesn't sound like something that should be always done. Could you explain, why you think this is necessary as a default?

[davidkarlsen]

Because I use salt masterless to build a box and repackage it for distribution. And I want to remove as much residual config as possible (caches in var etc), before I zero and repackage the image.

[obestwalter]

I understand. So this should be introduced as a configurable option that is deactivated by default. Do you agree?

[davidkarlsen]

That sounds reasonable

[obestwalter]

Well, I am a reasonable man. I will try to get another change in that touches the part of the code that will be involved in this change here (at least I think so - I did not dive into the sources yet). So if I get #5849 done I might be able to add this as well.

I wonder if we should do this a bit more generic right away to make it possible to issue an arbitrary call (or script) after provisioning to make this usable for other scenarios as well. I don't know if something like this would be useful though ...

@mitchellh Is there any kind of generic post provisioning step/hook that could be used for use cases like this?

[obestwalter]

On the other hand: the way you're doing it at the moment is somehow a post provisioning step by using the shell provisioner - so this is actually doing the job just fine. Maybe this enhancement is not really necessary for something specialized like you are doing?

[obestwalter]

@davidkarlsen What did you think about my last suggestion? I think we could close this as wontfix - do you agree?

[chrisroberts]

Related: #3849

[chrisroberts]

Hi there,

We would really like this, but this issue has been open for over a year with no one working on it, Leaving it open is unfortunately making our issue count look higher than it is. I’m going to close this and if someone wants to work on it I’d still be open to a PR!

Cheers!