support storage directories up to 1 year old #1507
Conversation
reidpr
requested review from
mphinney1100 and
j-ogas
and removed request for
mphinney1100
|
@reidpr Sorry for the delayed reply. I think for Gentoo the situation is easy, as I will always try to keep only approximately the last 2-3 releases in-tree, and Gentoo users are regularly updating due to it's rolling nature (for example, there are always two versions of KDE packages in-tree, a stable one and the next one for testing). For other distributions, I wonder if this is something they may want to handle in the upgrade path: If the packager knows that the Charliecloud version packaged in the old stable and the current stable version of the distribution are too far apart to support upgrading the storage format, maybe the packaging code can already clear the storage directories or advice the user during the system upgrade with a message to do so. |
|
I suppose that supporting an outdated storage directory format means the ability to upgrade to the most recent version. As you write, @reidpr, I guess that in many (or even all) cases users should be able to rebuild the contents of the storage directory without too much effort. Thus we are talking about a convenience feature here. And the documentation even mentions that "sometimes upgrade is not possible". On the other hand convenience is also a nice feature. ;-) Therefore one has to strike a balance between the technical burden to maintain the required compatibility code and the user convenience it brings about. I do not feel in a position to make any judgement concerning this point. In order to offer a convenient upgrade path for users upgrading from one stable Debian release to the next one (anything else is not officially supported), a support period of three years would be fine. The time between the start of freezes for subsequent releases is typically two years. To be on the safe side we should add the typical time between Charliecloud releases plus the delay caused by packaging the release for Debian and some extra safety margin to account for fluctuations, such that we end up with something like three years. If you think the price for a three year support period is too high, that would also be fine in my opinion as long as Charliecloud issues a clear error/warning message instructing the user how to proceed. |
Co-authored-by: Jordan Ogas <jogas@lanl.gov>
Makes sense. However I’m skeptical because (1) storage version bumps really are rather erratic, e.g. we had something like 3–4 releases for storage v2 and then only one release for storage v4 and (2) I don’t want to expose the storage version to users. We could instead say something like “m major versions”, which is easier to count but also less predictable, and I keep wanting to increase the release cadence, so maybe that will actually happen sometime. |
Previously, we did not commit to any particular duration for support of old storage directories. The disadvantage is that we're growing an increasing amount of compatibility code and testing. This documents a 1-year support period.
One potential problem is distribution-packaged versions. Currently these tend to lag rather a lot (e.g. Debian stable has 0.21, which is about two years old and has storage version 1). I’m not too worried about that since everything in storage can be rebuilt, but I would like to gather comment on it. If we did want to support e.g. Debian stable-to-stable upgrades, we’re looking at 3 years or more of support.
If this passes review, I’ll also create child bugs to retire storage versions 1–4, and update the release instructions to create new such bugs upon release of each relevant version.