Issue: Schedules broken after update to 3.9.2-0

1

Our existing schedules are failing after the update to 3.9.2 - is anyone else having this issue?

It seems to be a change in some variable names which aren’t updated for existing entries…

2

I believe it is “normal”, as per 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.”

Hope this helps,

1 Like
3

Hmm, I’m on ‘stable’ and wouldn’t expect this kind of thing to happen as part of an automatic upgrade on that channel - seeing as there is no method for this type of change to be disseminated to ‘stable’ users before they receive the automatic update!
An API change in a minor update doesn’t sound like good practice either ;(

4

I’m on stable as well (still 3.9.1-0, though) and am facing the same issue with my scheduled scrubs. I believe this began after my last update to stable 3.9.1, so that would be part of the last major update.
Wait for confirmation by @phillxnet, however, as he will most likely be able to explain the ins and outs of it.

5

@ScarabMonkey and @Flox

As @Flox points out there were large but necessary API changes towards the end of 3.9.1’s development cycle (3.9.0-13 pool api and 3.9.0-15 for disk api) which unfortunately lead to a breakage in creating new scheduled scrubs (in the consequent 3.9.1 stable release) and then during further necessary changes in the share api in 3.9.2’s development cycle (just finished) we had a similar regression in scheduled snapshots.

The scheduled scrub issue caused by the pool api change (towards end of 3.9.1 dev cycle):
https://github.com/rockstor/rockstor-core/issues/1759
and it’s fix in 3.9.2 dev cycle:
https://github.com/rockstor/rockstor-core/pull/1760

And on the Snapshot side we have:
The scheduled snapshot issue caused by the share api change (during 3.9.2 dev cycle):
https://github.com/rockstor/rockstor-core/issues/1809
and it’s fix in the same 3.9.2 dev cycle:
https://github.com/rockstor/rockstor-core/pull/1812

Hopefully the main issue here is that we have 3.9.2 stable out but a fair bit prior to the usual announcement / stable subscriber-mailshot that might otherwise contain such advisory requirements. A rather unforeseen ‘real life’ delay on that one unfortunately: but should be published shortly.

I have updated @ScarabMonkey linked issue with a few more details as I currently believe it to be a duplicate of the above linked snapshot issue/pr.

Linking to the associated scheduled scrub thread where @kbogert diagnosed the api change as the culprit:

We have confirmation in that thread, also by @kbogert, that the released fix was as intended post scheduled scrub task re-creation.

Hope that helps and clears up the rather confusing schedule scrub / snapshot issues.

6

@ScarabMonkey Thanks for reporting this issue and providing constructive feedback both here and on the github issue. And thank you @phillxnet for explaining our reasons for why we made these changes. There have clearly been some learnings from this for us, I’ll just summarize them here

We need to push hot-fixes and more frequent updates to paying subscribers to address regressions and critical bugs sooner than later. We will be doing that going forward. For example, you’ll notice a 3.9.2-1 update that fixes the issue you(@ScarabMonkey) have reported. Perhaps too late for you, but may be useful for others.

I also don’t think we should be storing share_name in meta as it’s redundant. We can get it from share id, which doesn’t change ever, but the name might. Better to decouple as much as possible. @phillxnet do take a look at my pr-1855. I think we should put temporary backwards-compatibility code like I did in that change. That way we migrate affected state on user’s behalf when we make breaking changes .

7

@suman

Agreed as per my pull request comment #1812:

“The approach taken in both this pr and the referenced pool scrub api fix is not ideal but is consistent with existing code and should only result in cosmetic issues upon pool/share name change features being introduced at a later date, with an available work around of re-creating the scheduled task.”

My aim was to re-establish expected behaviour with minimal code change in as timely manner as I could manage at the time while maintaining as much of the currently tested code as possible.

Re your pr, this does provide a work around for an element of the original issue but does not address the requirement to retrieve the share name for display purposes that drove me to the work around of share_name in meta, ie the other 5 files that were altered in the sighted pr that use the meta share_name:
#1812

But yes I agree that the share_name meta element was “not ideal”. Oh well, successive approximation and all and thanks for the pointers. We will need to re-hash how we retrieve the share name in that UI code going forward though.

Also agreed. The disk, pool, and share api changes were bound to have some casualties but at least they are done now (bar the suspected replication regression) and we can move forward with the renaming capability those changes affort, which will be nice. As will be the hot-fix addition.

Cheers.

8

I’m still having the scheduled snapshot issues in 3.9.2-1, Scrubs seems to be working ok.

9

@Maddan A very belated welcome to the Rockstor community.

Thanks for the feedback on this one. Could you confirm if a freshly created scheduled snapshot still works for you as that would help to diagnose where the issue lies? And hopefully provide a work around in the mean time. We have confirmation of this functionality as of 3.9.2-0 from @ScarabMonkey in their now closed issue #1851:
“I can confirm that a newly created schedule is functioning correctly.”

Cheers.

10

Thanks @phillxnet

I’ve been around a while.

A freshly created scheduled scrub appears to work but a freshly created scheduled snapshot doesn’t.

It shows up in the GUI schedule page as snapshot(undefined) rather than snapshot(share)

11

@Maddan Yes a very belated welcome message, but I like to be fair.

Thanks for the update. Could it be that your snapshots report is the issue here, ie only UI fails (as expected with the latest migration ‘hot fix’ but the snapshots are never-the-less still made. Please view your snapshots page and let us know how it is working on your system. I’ve created an issue to track this regression and linked back to this thread so that we can get this pinned down:

12

Thanks Philip, I think you’re correct here.

It does appear to be creating the snapshot correctly (as far as my non-technical capacity can tell) and the issue is in the UI.

Sorry if I missed something earlier. A sysadmin or dev I am not.

13

@Maddan Thanks for your patience and assistance on this one.

Super.

So to clarify:

  • existing scheduled snapshots created prior to 3.9.2-0 are continuing to function but with the “(undefined)” UI bug.
  • freshly created scheduled snapshots, post 3.9.2-1, are also functioning as expected but share the “(undefined)” UI bug.

Apologies for resourcing you this way only I personally have rather limited time currently to tend to this part of Rockstor but would like to do what I can, with your assistance, to pin it down so that I might refine the issue accordingly to help speed up it’s resolution.

Thanks.

14

Thankyou for the help. Sorry for my lack of technical knowledge making the process harder.

I deleted the existing snapshot schedules as I think I mis-understood the issue.

Correct with freshly created snapshot schedules. They appear to be working correctly aside from the UI bug.