On Fri, 16 Aug 2002, David Nolan wrote:
> In particular, for my needs I need multiple oncall schedules, for multiple
> groups (for internal organization purposes), all specified in the same
> config files.
schedule::oncall can manage multiple schedules by creating separate
objects for each of them. for example:
my $s1 = ne Schedule::Oncall;
my $s2 = ne Schedule::Oncall;
$s1->load ("file" => "sched1");
$s2->load ("file" => "sched1");
at this moment the code doesn't support having separate schedules in the
same file, but the "load" routine could be modified to accept an argument
which instructs it to pay attention to schedules in a file separated by
blocks. you tell it the block you care about, and it loads that. another
example:
beginsched SCHED1
...
endsched SCHED1
beginsched SCHED2
...
endsched SCHED2
however, i'm not sure of the real value of keeping them all in a
single file.
> I also want:
> Automated generation of the schedules, I don't want to have to write a
> one-off perl script to populate the oncall schedule.
ahh, yes, but over here people wanted some input as to what times they
were scheduled, so we manually created the schedules as appropriate.
maybe a new method could be added to schedule::oncall to automatically
produce a rotation based on the "people" stuff it loads up.
> Different schedule intervals for different groups. i.e. group X rotates
> responsibility weekly, group Y does it daily, group Z does it hourly...
...which can be done by loading each "group" as its own instance with
its own rotation using sched-report.
> And multiple responsibility listings for each group (i.e. a primary oncall
> person, and a fallback/secondary for escalation purposes)
yes, this would be a nice feature.
> And then I read in all the files from an Overrides directory, which look
> like:
schedule::oncall handles overrides by simply overlaying multiple
schedules. you call $s1->load ("file" => "schedule1") then
$s1->load ("file" => "override");
> My primary purpose in writing this had been to do some automated rotation
> of pager aliases for Qpage.
sounds like a good application.
> If we could incorporate some of the added oncall functionality into your
> module, I'd be happy to write the qpage.cf updater and web interface to use
> your module, and they could be distributed in your tools collection.
sounds doable.