Destroying a release does not destroy the corresponding cache directory (ZFS)

[joh-ku]

[MANDATORY] Describe the bug [MANDATORY]
When running bastille destroy RELEASE (ZFS) the corresponding cache directory remains untouched.

[MANDATORY] Bastille and FreeBSD version (paste bastille -v && freebsd-version -kru output)
0.10.20231125
14.1-RELEASE-p3
14.1-RELEASE-p3
14.1-RELEASE-p3

[MANDATORY] How did you install bastille? (port/pkg/git)
pkg

[optional] Steps to reproduce?

1. Run e.g. bastille destroy 14.0-RELEASE (or any release version you may want to destroy)
2. /usr/local/bastille/cache/14.0-RELEASE still exists

[optional] Expected behavior
When a release is destroyed, its corresponding cache directory should be deleted as well.

[foudfou]

This is not well documented but the cache is deleted on force: bastille destroy force 14.0-RELEASE .

[joh-ku]

@foudfou correct, there is a force flag. Thanks for pointing this out!

The question for me is, if an additional flag is required at all and hence, if "destroy" should delete the release and cache directories all together. Pulling the image again is cheap anyway.

[foudfou]

Pulling the image is not so cheap to be honest (minutes) compared to creating a release from the cache (seconds). Plus upstream might not have the locally destroyed release anymore (although subsequent jails could be hard to use).

That said, I would also expect destroying a release to also clean up the cache and have amend the PR accordingly.

[joh-ku]

Well, not as cheap as serving it from the cache, agreed. Thank you for the PR! I think the behavior is clearer now.

[bmac2]

@cedwards what do you think the desired action is here?? Isn't the way itworks not destroying cache the designed way, or should it be changed? Don't want to make changes without your input.

[marschro]

Another thing to keep in mind - ist it true, that the zfs filesystem for that release then still does exist?
If so, then maybe it can be considered to "clean-up" that too?

[michael-o]

Has this one been resolved with the last release?

[bmac2]

I do not believe this one has been addressed yet. No PR in this release addressed this.

@michael-o

[michael-o]

I do not believe this one has been addressed yet. No PR in this release addressed this.

@michael-o

Alright, am still questioning why force would be useful unless something is mounted and needs to be taken down. Cache should always go with.

[tschettervictor]

This is documented, but should we just delete everything including the cache?

Or are we good with documentation on it?

I'd opt to require the flag for deleting the cache, as there can be times when one wants to retain release cache if the release goes EOL.

[joh-ku]

I don't think the force option provides significant benefit in this context and in this sense I'd be fine with deleting release and cache together. Anyway, I'm definitely fine with what the majority thinks is best.

[tschettervictor]

@michael-o @bmac2

[bmac2]

I think documenting the behavior and using -f if you want to destroy cache is the way to go. Not everyone wants to destroy the cache and the image is not always cheap to download.

Anyone disagree at this point?

[michael-o]

I think documenting the behavior and using -f if you want to destroy cache is the way to go. Not everyone wants to destroy the cache and the image is not always cheap to download.

Anyone disagree at this point?

I personally think that force applies to unmount and rm only. Everything what can be deleted should be deleted. One could add a flag to retain the cache.

[tschettervictor]

Perhaps a --no-cache flag?

[bmac2]

ok so on a destroy WITHOUT any flags we set it to delete the cache. Anyone against this method?