Save and Restore config back-up files

[phillxnet]

As a partial solution to rockstor/rockstor-core#2639 we could/should:

1. Have incomming outgoing package scriptlet (removed or upgraded) copy it's ´/opt/rockstor/static/config-backups´ contents to top-level ´/opt/rockstor/config-backups´ directory.
2. Have incoming package scriptlet (installed or upgrading) copy what-ever it finds in the ´/opt/rockstor/config-backups´ directory to the working location accessible via Web-UI: and in doing so re-establish what the existing db expects to find there.

A bonus of this process is that on every package managed upgrade we make a copy of our config backup files.

This proposed ´/opt/rockstor/config-backups´ directory would not be deleted in any package clean-up process. And so would serve as a repository for such files, while still maintaining our isolation form the OS at large and keeping within our parent directory.

[Hooverdan96]

That's an interesting idea.
What would you think about making the /opt/rockstor/config-backups the new permanent location (changing it in the settings for django), but still have the scriptlet move everything it finds from the "old" location to this new one. That way, we would enable the transition out of the static tree path without user intervention. And, eventually, in some future version deprecate that copying over there.
Finally, that would/could leave the door also open for future functionality of customer defined backup locations via the WebUI (as @FroggyFlox was open to)?

I am operating under the assumption that your suggestion is around the thought of stability, meaning, no changes to the config backup functionality while still enabling a non-destructive update?

[phillxnet]

@Hooverdan96 Re:

That way, we would enable the transition out of the static tree path without user intervention.

Yes me and @FroggyFlox did entertain this idea actually, but I'm unsure if we have a requirement, or will incure more complexity, if we move outside of static for the working directory, given it's what the Django stuff can normally reach. Hence this as a quick fix that also adds redundancy. And only entails rpm scriptlet changes so we can likely get this in place for the next release. Then in the future, when we have more of our updates in place, we can re-visit and enhance further re custom settings and non build-time but run-time directory setting.

I think we are of similar minds on this one all around really. I just wanted to get in the simplest 'fix' for now and as you say it may server as a transition for the future. But changing this will entail no core changes and no db migration issues etc.

meaning, no changes to the config backup functionality while still enabling a non-destructive update?

Exactly - it's not good what we have, and a couple of lines in outgoing and incoming rpm scriptlets and we have a fix as we wrestle our dependencies etc. Then we get our selves some time/distance to fathom our 'other' options and enhancements. Sort of a bit-by-bit with minimal fix at first. Just not entirely sure of our options re access outside of the static. But we know it works there and we have had years of using the current location. Only my new Poetry based install method took a brute force approach to re-establishing static - which I stand by - but I entirely missed this ramification. So it's great that it's come to light. Hence quick fix with minimal intervention all around. At least initially.

Also I like the idea of taking copies on each package operation so it might be good to keep that facility, if that is the way we end up going.

Incidentally there has been side chat on providing an easy Appman config backup upload/stash capability - but again - for another time, issue, and repo I think :).

[Hooverdan96]

yep, we're aligned. Go for it. One more question:

1. Copy from the Rockstor config-backups folder to the /opt/rockstor/config-backups folder
2. perform the RPM update
3. Copy back to the original folder
4. Question: Clean up of the /opt/rockstor/config-backups folder or leave entries there, and just overwrite all during next update?

Well, you must have something in mind, I can just look at your pull request, once you get to it.

[phillxnet]

@Hooverdan96 I'll present what I think may fix our current failure and we can review from there. Likely there will be holes but hopefully smaller than we obviously have currently :). But give this mechanism will live entirely in rpm scriptlets it want's to be as basic as possible was my thinking.

[phillxnet]

To account for upgrades from our current Stable release, assuming no backports, to the stable that will ultimately be spun off form our current testing branch, we need the majority, if not all, of the fix here to be in scriptlets of the incoming package.

[phillxnet]

Closing as:
Fixed by #45