don’t implement your scheduler in a pure queue design
HP Cloud Service Automation (3.1) allows you to schedule requests in the future. It also allows you schedule end dates for subscriptions.
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.
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!
March 4, 2013
В· antipaucity В· No Comments
Tags: cloud, cron, csa, data-structures, development, fail, fifo, hp, hpcsa, iterative, queue, scheduling В· Posted in: commentary, complaint, ideas, insights, rant, technical, work