don’t implement your scheduler in a pure queue design
Recently came across a seriously funky issue with one of HP’s products (don’t laugh – I know there’s loads of funkiness in HP tools).
HP Cloud Service Automation (3.1) allows you to schedule requests in the future. It also allows you schedule end dates for subscriptions.
That’s neat.
Here’s the problem: if you delete a Service Offering (which allows something to be requested in the CSA catalog) while an active subscription is using it – any active subscriptions get delinked, and become unmanageable with the tool.
Now the dopey scheduler comes into play.
CSA’s scheduler works by putting all future items into a FIFO queue. What this ends up meaning is that if you have an item that fails (because, for example, you’re now past a scheduled end date, but the subscription is unlinked from an offering, so it can’t unprovision it), all other pending items fail, too. Even ones that should happen “immediately” – because “immediately” is still added to the scheduling queue… behind the erroring item(s). And since those items have errored, nothing can move forward.
This is stupid. (And yes – RFEs have already been filed over these problems in the product.)
Instead, have the scheduler put all items into a table – at the appointed time, iterate through the table and run everything you can – if it won’t run, flag it as an error, and move on.
This is how cron works. Why would you not use a commonly-accepted, reliable way of doing things? Oh yeah – you’re HP.
If you’re planning to write something for your product/software/tool – see if anyone else has done it before, and then try to mimic methods that work… please!
