reload, restart - initial and final cycle point changes

[arjclark]

Result of an email conversation between myself, @hjoliver and @dpmatthews.

It is currently possible to do odd (read: bad) things to the initial and final cycle times for a suite as a result of a reload:

• moving the initial cycle time behind the original initial cycle time
• moving the initial cycle time beyond the current cycle
• moving the final cycle time behind the initial cycle time
• moving the final cycle time behind the current cycle time

We should reject changes like these on reloading.

I can't see any reason to allow a change to the initial cycle time once a suite has started running so that should be rejected.

The extent to which changes to final cycle time are restricted may be open to discussion I guess. It is at least clear that moving final cycle time behind initial cycle time should be rejected and suites with that in probably shouldn't validate at all.

[arjclark]

@benfitzpatrick - might be relevant to the iso8601 changes

[hjoliver]

On current master:

• moving the initial cycle time behind the original initial cycle time

accepted (this is ok?)

• moving the initial cycle time beyond the current cycle

accepted (this doesn't make sense?)

• moving the final cycle time behind the initial cycle time

rejected (the reload is aborted)

• moving the final cycle time behind the current cycle time

accepted (suite goes into stopping mode - this is ok?)

[arjclark]

Hi Hilary,

given that suites now have cycling defined relative to initial and final cycle points I think all the above should be being rejected.

So:

• moving the initial cycle time behind the original initial cycle time

Should be rejected as things are defined relative to the initial cycle point e.g. every 6 hours starting from the ICT - graphing could quickly be messed up as a result of going from something like 20100101T12 to 20100101T04.

• moving the initial cycle time beyond the current cycle

Should be outright rejected as makes no sense - suite is already running at that point.

• moving the final cycle time behind the initial cycle time

rejected (the reload is aborted)

Agreed, should be rejected.

• moving the final cycle time behind the current cycle time

accepted (suite goes into stopping mode - this is ok?)

Problematic as you can define things to run in the last N cycles e.g. run a particular major archiving and housekeeping task in the last cycle, if its already in the graph it'll really mess with things.

I think, in conclusion, any change to the initial cycle point once a suite is running should be rejected. Changes to the final cycle time are potentially quite dangerous so should probably also be rejected.

[hjoliver]

[meeting] we agreed:

• need to support changed final point, although it may be difficult
• at the least, document and warn of the risks
• this becomes less of an issue if we can spawn tasks on demand...

Start by checking what happens on current master in various cases.

[hjoliver]

Consolidated with #591.

[sadielbartholomew]

@hjoliver can I take on this issue, or have you been / are you working on some facet of this?

[hjoliver]

@sadielbartholomew - no I haven't, please do!

[sadielbartholomew]

Thanks :)