-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
suspected 3.9.2-1 scheduled snapshot UI regression #1857
Comments
Update from Maddan in the referenced forum thread. Awaiting clarification of Maddan's current config behaviour. Post confirmation I will edit or close and re-create this issue. |
I can confirm that I am seeing the behaviour exactly as described and it is thus only a cosmetic issue now. New schedules do indeed function but the GUI doesn't know the share name. |
@ScarabMonkey Cheers, most helpful, thanks for chipping in on this one. We do however now have a report from forum member zoombiel in the following forum thread of a suspected failure of the migration code for prior made, ie 3.9.1 stable, scheduled snapshots:
more details are pending re this particular int.isdigit issue. Pasting here for context. Please update the following forum thread with this issues resolution: |
Forum member zoombiel in my latter referenced forum thread has confirmed that their freshly created scheduled snapshot tasks are functioning as expected, bar the known "undefined" UI bug component in the scheduled tasks overview part of the UI. |
return realtime info in task defition via properties. Fixes #1857
Thanks to forum members ScarabMonkey and Maddan in the following thread for highlighting this issue. It appears that we have a regression introduced by stable hotfix pr: #1855 which was intended to aid migration from scheduled task meta created from old share api. From Maddan's account this appears not to have worked as intended (in the field) and has also blocked / broken the prior confirmed, by ScarabMonkey, function of creating a fresh schedule. Ie no migration and broken freshly created scheduled snapshots. A quick fix for this issue (once confirmed / clarified by devs) would be to revert hot fix #1855 and return at least the function of a freshly created scheduled snapshot as then users have at least a work around (recreation of scheduled snapshot tasks), and fresh installs function as intended. Currently scheduled snapshots in 3.9.2-1 are suspected broken via migration or fresh creation (dev confirmation required).
@schakrava I suggest we revert #1855 in stable and publish release notes for the stable channel indicating the need to recreate scheduled tasks. Then as we approach the pool/share renaming capability we improve on the redundant storage of share name within meta for both scrub and snapshot scheduled tasks which we both agree is sub-optimal (my partial fix to at least return function to freshly created scheduled tasks). Alternatively a 'proper fix' is required that may not be timely enough, depending on resources, that includes the migration capability which is obviously preferred.
Please see the following forum thread for context:
https://forum.rockstor.com/t/issue-schedules-broken-after-update-to-3-9-2-0/3999
As of 3.9.2-0 (stable) freshly created scheduled tasks of snapshot or scrub have been confirmed as functioning and displaying as intended with the unfortunate but necessary caveat that we have, currently harmless, redundant meta date of share_name in the scheduled task info. I suggest that this be addressed in the next development release by properly retrieving share name from shareid for the UI components: a task I purposefully postponed and noted in the related fixes for broken scheduled scrubs and task; respective reviewed prs are:
"fix scheduled scrub regression re pool api changes. Fixes #1759" #1760
"fix snapshot scheduled task regression re share api change #1809" #1812
with the latter noting the following:
"N.B. as with the pool api scheduled scrub task fix, it will be necessary for users to delete and re-create all their existing scheduled snapshot tasks (post this pr) in order that their prior function (pre share api change) be restored."
Please note that Maddan's report has yet to be confirmed as it may be that we only have a UI regression here. Creating issue to address either way.
The text was updated successfully, but these errors were encountered: