Skip to content
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.

[dev.icinga.com #1867] Recurring Downtimes #729

Closed
icinga-migration opened this issue Aug 31, 2011 · 60 comments
Closed

[dev.icinga.com #1867] Recurring Downtimes #729

icinga-migration opened this issue Aug 31, 2011 · 60 comments
Labels
Downtimes enhancement
Milestone
1.13

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/1867

Created by pdeneu on 2011-08-31 11:38:54 +00:00

Assignee: Wolfgang
Status: Resolved (closed on 2015-02-14 21:10:02 +00:00)
Target Version: 1.13
Last Update: 2015-02-14 21:10:02 +00:00 (in Redmine)

new feature request for icinga classic (and icinga-web) is to define recurring timeperiods.
for example to define on every second saturday in month a downtime for specific hosts or services.
recurring downtimes on hostgroups (on all hosts of group) can be a nice feature too.

Attachments

Changesets

2015-02-14 21:04:47 +00:00 by mfriedrich cd0c205

Integrate recurring downtimes scripts

fixes #1867

2015-02-14 21:09:20 +00:00 by mfriedrich 6806d8f

Update Changelog with downtime changes

refs #1867

Relations:
@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-09-12 13:33:34 +00:00

  • Status changed from New to Feedback

i don't understand the feature request. is this a core related configuration item, or just a gui read only feature?

@icinga-migration
Copy link
Author

Updated by mjbrooks on 2011-09-15 18:34:11 +00:00

Core.

The basic idea is that, for example, you know your sever will be down every Sunday and you want to just say, every Sunday there is a downtime for this server (or hostgroup even) instead of having to put them in one by one ahead of time.

I'm thinking this could be quite involved because it might require some serious effort, like a whole new scheduler. I think in the end it would be effort well spent, I'm just saying that it would be more than just a minor tweak even though it may look like it on the surface.

+1 for the idea

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-09-30 22:08:46 +00:00

  • File added downtime-3.2.tar.gz

well he could have provided more accurate information in the first place. not everyone knows about such addons like the cgi to be found on the web.

https://www.monitoringexchange.org/inventory/Utilities/AddOn-Projects/Downtimes/downtime\_sched%253A-recurring-downtime-scheduler

http://feedback.icinga.org/forums/50329-general/suggestions/1120561-add-recurring-downtimes?ref=title

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2011-10-05 19:10:30 +00:00

Somehow I overlooked this issue... and began to create a new perl script similar to Steve Shipways file. That means it will read the icinga.cfg to determine the name of the status file which in turn will be used to read the existing downtimes. Then a file with downtime definitions will be processed. I intend to use something like

define downtime {
   host_name           some_host 
   hostgroups          hg1
   servicegroups       sg1
   service_description some_service
   author              some_author
   comment             backup
   duration            30
   downtime_period     2011-10-02 - 2011-10-10 10:00-12:00
   fixed               0
   propagate           1
}

Planned for now:
"host_name", "hostgroups", and "servicegroups" are mandatory and mutually exclusive.
"service_description" is optional. If not defined a downtime for a host / hostgroup(s) / servicegroup(s) is/are scheduled. If defined it can be a single service or "all" for all services of a single host.
"duration" is optional and must be defined if it is a flexible downtime.
"fixed" is optional and will be "0" if duration is defined/differs from start time-end time.
"propagate" is optional and default to "0". If set the downtime will be propagated to child hosts of the host specified.
"downtime_period" is similar to the definition found in time periods meaning that any of the following should be valid:

   downtime_period     2011-10-01              20:00-02:00
   downtime_period     2011-10-10 - 2011-10-20 10:00-12:00
   downtime_period     day 1 - 3               04:00-12:00
   downtime_period     sunday                  00:00-24:00
   downtime_period     monday - wednesday      20:00-22:00
   downtime_period     monday                  00:00-09:00,17:00-24:00
   downtime_period     1999-01-28              00:00-24:00
   downtime_period     saturday                00:00-24:00
   downtime_period     monday 3                00:00-24:00
   downtime_period     day 2                   00:00-24:00
   downtime_period     february 10             00:00-24:00
   downtime_period     february -1             00:00-24:00
   downtime_period     friday -2               00:00-24:00
   downtime_period     thursday -1 november    00:00-24:00
   downtime_period     2007-01-01 - 2008-02-01 00:00-24:00
   downtime_period     monday 3 - thursday 4   00:00-24:00
   downtime_period     day 1 - 15              00:00-24:00
   downtime_period     day 20 - -1             00:00-24:00
   downtime_period     july 10 - 15            00:00-24:00
   downtime_period     april 10 - may 15       00:00-24:00
   downtime_period     tuesday 1 april - friday 2 may      00:00-24:00
   downtime_period     2007-01-01 - 2008-02-01 / 3         00:00-24:00
   downtime_period     2008-04-01 / 7                      00:00-24:00
   downtime_period     monday 3 - thursday 4 / 2           00:00-24:00
   downtime_period     day 1 - 15 / 5                      00:00-24:00
   downtime_period     july 10 - 15 / 2                    00:00-24:00
   downtime_period     tuesday 1 april - friday 2 may / 6  00:00-24:00

Another script will convert existing definitions created for Steve's script.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2011-11-09 10:13:21 +00:00

  • Assigned to set to Wolfgang

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2011-11-18 00:08:12 +00:00

  • File added downtime.tar
  • Done % changed from 0 to 20

First try including scheduling script, some lines of documentation, and a conversion script.

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-04 21:48:42 +00:00

  • File added downtime.tgz
  • Done % changed from 20 to 30

second version of sched_down.pl script including holidays based on easter and enabling local holidays

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-04 21:56:01 +00:00

Holidays based on easter

   downtime_period     whit_sunday       00:00-24:00

Define local holidays in separate file

   Spring_bank_holiday day_in_week_of_month(5,1,-1)

Use of local holidays (last monday in may)

   downtime_period     Spring_bank_holiday   09:00-17:00

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-07 18:23:53 +00:00

  • File deleted downtime.tar

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-07 18:24:02 +00:00

  • File deleted downtime.tgz

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-07 19:36:54 +00:00

  • File added downtime-003.tgz
  • Assigned to changed from Wolfgang to ricardo

removed some bugs
ready for testing

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-14 23:31:46 +00:00

  • File deleted downtime-003.tgz

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-14 23:33:22 +00:00

  • File added downtime-004.tgz

fixed calculation of duration, added call for crontab in docs

@icinga-migration
Copy link
Author

Updated by m4rcu5 on 2012-03-18 21:56:44 +00:00

  • File added downtime.cfg
  • File added debug.log

I was testing the script of Wolfgang today. It seems that it only adds one service downtime at each run instead of adding all for the upcoming period?

  1: --- Debug enabled so NO commands will be sent to /var/lib/icinga/rw/icinga.cmd! ---
    2: --- Scheduled downtimes ---
    2: 2012.03.19 04:00 - 2012.03.19 06:00 host.fqdn.tld;HTTP IPv4
    2: 2012.03.19 04:00 - 2012.03.19 06:00 host.fqdn.tld;HTTP IPv4 / SSL
    2: 2012.03.19 04:00 - 2012.03.19 06:00 host.fqdn.tld;IMAP4
    2: 2012.03.19 04:00 - 2012.03.19 06:00 host.fqdn.tld;POP3
    2: 2012.03.19 04:00 - 2012.03.19 06:00 host.fqdn.tld;SMTP
    2: 2012.03.19 04:00 - 2012.03.19 06:00 host.fqdn.tld;Zimbra Status
CMD: [1332106260] SCHEDULE_SVC_DOWNTIME;host.fqdn.tld;SMTP;1332126000;1332133200;0;0;900;;Scheduled Backups

Running the script again immediately afterwards adds the next service, i have to repeat it until all of them are added.

The full debug and downtime.cfg are attached.

One other thing i noticed is that attaching the opening bracket to the word "downtime" as is common in the Icinga configs will break the script.

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-19 11:06:57 +00:00

  • File added downtime-005.tgz

Thanks for your feedback. Attached a new version fixing these errors.

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-19 11:07:17 +00:00

  • File deleted downtime-004.tgz

@icinga-migration
Copy link
Author

Updated by m4rcu5 on 2012-03-19 20:16:29 +00:00

Confirmed, works like a charm now. Thanks!
Just one more comment, would it be possible to add multiple services to a definition? When scheduling downtime you often have a couple of checks that need to be suspended as they are affected.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-03-19 22:42:34 +00:00

hm. from the source this looks good. could this be somehow included in the icinga package? if so, please add a license header with copyright. and please remove the mention of xi being a trademark in the docs - name it the "commercial nagios version".

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-20 19:38:04 +00:00

  • File added downtime-006.tgz
  • Done % changed from 30 to 50

Added some perfdata, moved most output to STDERR, fixed docs

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-20 19:38:12 +00:00

  • File deleted downtime-005.tgz

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-03-20 23:09:28 +00:00

fixed docs plus header looks good. any proposals on how to integrate this within upstream package?

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-21 20:13:50 +00:00

  • File added downtime-007.tgz

@m4rcu5: have a try

A comma-separated list of objects per hostgroup/servicegroup/host/service description should be possible.
Doc bugfix.

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-21 20:13:58 +00:00

  • File deleted downtime-006.tgz

@icinga-migration
Copy link
Author

Updated by m4rcu5 on 2012-03-21 20:31:58 +00:00

@wolfgang: Seems to work, thanks!

define downtime{
        host_name               mailserver.fqdn.tld
        service_description     Zimbra Status,IMAP4,POP3,SMTP
        comment                 Scheduled Backups
        duration                15
        downtime_period         monday - sunday 04:00-06:00
        }

Already scheduled: 0, Definitions: 2, newly planned: 6 | Existing=0 defined=2 new=6

To make the brackets more compliant to the rest of the configs, could you make the following change on line 320?:

-if (/define\s+(\S+)\s+{/) {
+if (/define\s+(\S+)\s*{/) {

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-21 20:42:14 +00:00

  • File added downtime-007.tgz

Darn. I missed that occurrence.
Fixed

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-21 20:42:22 +00:00

  • File deleted downtime-007.tgz

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-03-21 20:45:42 +00:00

hm. can you start this over in git in your wnieder branch in icinga-core.git? that would make more sense to me.

place it somewhere in contrib/

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-22 22:08:36 +00:00

  • File deleted downtime-007.tgz

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-03-22 22:11:56 +00:00

Scripts now in git (wnieder/downtimes in icinga-core), docs in r1.7 (icinga-docs and most of it already in this issue).

@icinga-migration
Copy link
Author

Updated by m4rcu5 on 2012-03-24 23:05:24 +00:00

It seems that specifying the duration is not enough anymore to enable flexible downtimes. You now need to specifically set "fixed 0" to enable flexible downtimes.

duration                15
downtime_period         monday - sunday 04:00-06:00

CMD: [1332630240] SCHEDULE_SVC_DOWNTIME;mail01.xxx.com;Zimbra Status;1332640800;1332648000;1;0;900;icingaadmin;Scheduled Backups

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-04-20 06:11:25 +00:00

The scheduling script itself seems to work as expected so I'd include the script (and the documentation) in 1.7. Managing downtimes via GUI is not supported yet but creating a definition file using your favourite editor is sufficient so (nearly) everyone can use the functionality.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-04-20 10:28:35 +00:00

question is about possible "make install blablabla" and possible dependencies therefore (packages...)

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-04-20 10:35:11 +00:00

Dependencies: Perl module "Time::Local"

@icinga-migration
Copy link
Author

Updated by ziesemer on 2012-07-15 08:18:19 +00:00

I don't believe this is working for simply scheduling a servicegroup, as follows:

define downtime {
  servicegroups             my-servicegroup
  service_description       all
  downtime_period           days 1 - 31 23:30-02:30
}

I.E., when run in debug, no "CMD:" lines are output.

However, if I add a hostgroup:

define downtime {
  hostgroups                my-hostgroup
  servicegroups             my-servicegroup
  service_description       all
  downtime_period           days 1 - 31 23:30-02:30
}

Then something happens:

CMD: [1342339920] SCHEDULE_HOSTGROUP_HOST_DOWNTIME;my-hostgroup;1342413000;1342423800;1;0;0;icingaadmin;sched_down.pl 0.08

However, this is no different than if no servicegroups were specified at all:

define downtime {
  hostgroups                my-hostgroup
#  servicegroups             my-servicegroup
  service_description       all
  downtime_period           days 1 - 31 23:30-02:30
}

Yields:

CMD: [1342340100] SCHEDULE_HOSTGROUP_HOST_DOWNTIME;my-hostgroup;1342413000;1342423800;1;0;0;icingaadmin;sched_down.pl 0.08

I need to see a SCHEDULE_SERVICEGROUP_SVC_DOWNTIME here somehow, to duplicate what is a standard operation through the UI.

I can make this work if I comment out the block starting out at line #428 in the script - but I'm not sure why a match isn't being made here:

unless (exists ($sg{"$h"})) {
        info (2, "object $h does not exist");
        next;
}

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-07-15 18:11:15 +00:00

Please test

`- (%hg,%sg) = read_object_file ($oFile,3);

  • my ($ref_hg,$ref_sg) = read_object_file ($oFile,3);
  • %hg = %$ref_hg;
  • %sg = %$ref_sg;`

`- return (%hGroup, %sGroup);

  • return (%hGroup, %sGroup);`

@icinga-migration
Copy link
Author

Updated by ziesemer on 2012-07-15 20:56:30 +00:00

Wolfgang - thanks, that fixed it. (Yeah, I wasn't going to find that too quickly... :-)

@icinga-migration
Copy link
Author

Updated by ziesemer on 2012-07-15 21:10:36 +00:00

Well - not quite. The icinga.log shows:

[1342385818] EXTERNAL COMMAND: SCHEDULE_SERVICEGROUP_SVC_DOWNTIME;;1342413000;1342423800;1;0;0;icingaadmin;...
[1342385818] Error: Could not find servicegroup '' provided in external command!

So the service group name isn't actually being sent over to the command file (nor is it logged as such).

I can partially fix this with:

- $extcmd = "SCHEDULE_SERVICEGROUP_SVC_DOWNTIME;$hg;$data";
+ $extcmd = "SCHEDULE_SERVICEGROUP_SVC_DOWNTIME;$sg;$data";

However, if my configuration contains servicegroups my_servicegroup1,my_servicegroup2, the entire servicegroups string is passed-along (incorrectly) - instead of sending separate commands for each group.

@icinga-migration
Copy link
Author

Updated by ziesemer on 2012-07-16 01:17:55 +00:00

  • File added sched_down.pl-MAZ1.patch

I'm a little out of my territory here, but attached is a possible patch. It includes your above comment #39, and both my notes from comment #41 (fixing the $extcmd string, and supporting multiple service groups).

What isn't working is that when run multiple times, duplicate downtimes are being scheduled into Icinga (and I'm not sure how to fix this - so please don't reserve this for me to fix. :) Actually, is this even possible? This involves sending a SCHEDULE_SERVICEGROUP_SVC_DOWNTIME external command but AFAIK, the engine doesn't keep track of downtimes by host/service-groups, but only by individual hosts/services. So we can't easily query to see if a servicegroup was previously scheduled, correct? Maybe instead of submitting a SCHEDULE_SERVICEGROUP_SVC_DOWNTIME, this script needs to just send the individual SCHEDULE_SVC_DOWNTIME commands for any that don't already exist?

However, overall, I think a comprehensive review is needed to ensure that the script supports what is documented. Are there any existing test cases that I could expand upon?

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-07-16 05:48:57 +00:00

Please pull the current version from git (which should solve the issue running the script multiple time), apply the changes I proposed for service groups and retry. If it still doesn't work then please create a new thread on www.monitoring-portal.org for that.
No, there aren't any test cases yet.

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2012-07-16 11:54:55 +00:00

I shouldn't have answered so early in the morning :-(.
Apply your patch as well (it should be applied to hostgroups, too) and retry.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2012-10-24 17:53:38 +00:00

  • Target Version set to 1.10

think of a different core, this should be doable within #2833 while adding (experimental) support here. though, it might happen that this does not hit the final release.

@icinga-migration
Copy link
Author

Updated by ziesemer on 2012-12-18 21:15:58 +00:00

It's been a while, and I'm finally re-visiting this, but I'm pretty certain this still needs some attention. I'm using the contrib/downtimes/sched_down.pl that was bundled with 1.8.3 - which appears identical to the GIT head at https://git.icinga.org/?p=icinga-core.git;a=blob;f=contrib/downtimes/sched\_down.pl;h=99d5252932c9e5a8a2b3f1d2cf6313201dadc19a;hb=master . Things have changed a bit, but are still not correct.

As-is (without patching), with a downtime config that contains only "servicegroups", "author", "comment", and "downtime_period", I still see "CMD:SCHEDULE_SERVICEGROUP_HOST_DOWNTIME" being logged. This should be a "SCHEDULE_SERVICEGROUP_SVC_DOWNTIME" instead.

Can you please offer some additional guidance as to what needs to happen here to get this working properly? Thanks!

@icinga-migration
Copy link
Author

Updated by fgr on 2012-12-20 13:56:17 +00:00

Hi!

Scheduled downtimes are not correcly recognized, if they're defined for a period of some days, e.g. "downtime_period 2012-12-15 - 2012-12-30 20:00-21:00". They're ignored until the "plan ahead" option catches either the start or the end date - then they're scheduled correctly for the next occurance:

[root@fgrtest downtimes]# date
Thu Dec 20 14:29:28 CET 2012
[root@fgrtest downtimes]# cat /usr/local/icinga/etc/downtime.cfg
define downtime {
    host_name           childhost
    author              some author
    comment             some comment
    downtime_period     2012-12-15 - 2012-12-30 20:00-21:00
    propagate           1
    register            1
}

[root@fgrtest downtimes]# ./sched_down.pl
  1: status_file=/usr/local/icinga/var/status.dat
  1: object_cache_file=/usr/local/icinga/var/objects.cache
  1: command_file=/usr/local/icinga/var/rw/icinga.cmd
  1: planning childhost;;some comment: 2012-12-15 - 2012-12-30 20:00-21:00
  1: Rejected: ==> start is more than 2 days away
  1: --- Debug enabled so NO commands will be sent to /usr/local/icinga/var/rw/icinga.cmd! ---
Already scheduled: 0, Definitions: 1, newly planned: 0 | Existing=0 defined=1 new=0

[root@fgrtest downtimes]# ./sched_down.pl -m5
  1: status_file=/usr/local/icinga/var/status.dat
  1: object_cache_file=/usr/local/icinga/var/objects.cache
  1: command_file=/usr/local/icinga/var/rw/icinga.cmd
  1: planning childhost;;some comment: 2012-12-15 - 2012-12-30 20:00-21:00
  1: Rejected: ==> start is more than 5 days away
  1: --- Debug enabled so NO commands will be sent to /usr/local/icinga/var/rw/icinga.cmd! ---
Already scheduled: 0, Definitions: 1, newly planned: 0 | Existing=0 defined=1 new=0

[root@fgrtest downtimes]# ./sched_down.pl -m6
  1: status_file=/usr/local/icinga/var/status.dat
  1: object_cache_file=/usr/local/icinga/var/objects.cache
  1: command_file=/usr/local/icinga/var/rw/icinga.cmd
  1: planning childhost;;some comment: 2012-12-15 - 2012-12-30 20:00-21:00
  1: possibly on: Thu Dec 20 20:00:00 2012 to Thu Dec 20 21:00:00 2012 for 0 mins
0: CMD:SCHEDULE_AND_PROPAGATE_HOST_DOWNTIME;childhost;1356030000;1356033600;1;0;0;some author;some comment
  1: --- Debug enabled so NO commands will be sent to /usr/local/icinga/var/rw/icinga.cmd! ---
CMD: [1356010140] SCHEDULE_AND_PROPAGATE_HOST_DOWNTIME;childhost;1356030000;1356033600;1;0;0;some author;some comment
Already scheduled: 0, Definitions: 1, newly planned: 0 | Existing=0 defined=1 new=0

[root@fgrtest downtimes]#

@icinga-migration
Copy link
Author

Updated by mjbrooks on 2013-05-04 20:25:19 +00:00

Is this still open Wolfgang?

@icinga-migration
Copy link
Author

Updated by mjbrooks on 2013-05-04 20:33:57 +00:00

Never mind... I just saw it on the roadmap. ;)

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-06-29 15:55:09 +00:00

what's the general status of that? is it something which may be pulled out of contrib/ into a supported location for 1.10 or is it still "under development"?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-07-20 12:21:40 +00:00

  • Project changed from 19 to Core, Classic UI, IDOUtils

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2013-07-20 12:44:42 +00:00

  • Target Version changed from 1.10 to 1.11

@icinga-migration
Copy link
Author

Updated by mjbrooks on 2014-01-13 03:45:03 +00:00

Will this be official in 1.11? Are we on target for this to have all the bugs worked out?

@icinga-migration
Copy link
Author

Updated by ziesemer on 2014-01-13 04:52:44 +00:00

Having looked into this a fair amount previously (as visible in the above comments), I've largely given up on this for 1.x - though please surprise me otherwise!

I think there are a number of design issues - both ones that were touched on here but not completely resolved, and others that I haven't even brought to attention yet - which prevent this from becoming a reality in 1.x, at least not one that is "stable", robust, and one that I would trust in our production environment.

The fact that we have to regularly schedule a job to pre-schedule scheduled downtimes just "seems wrong". I think the best solution would be to have a "1st class" configuration option for scheduled downtimes, just as we can currently schedule notification periods and checks (and exclusions to those periods). However, this would require some significant additions to the current core - which I would agree with the Icinga team that this is work probably best saved for Icinga 2.x. And it seems like some recent progress has been made on this front, as visible at http://feedback.icinga.org/forums/50329-general/suggestions/1120561-add-recurring-downtimes . I just haven't had a chance to review what is being offered here - though I anxiously await an official, "stable" release of Icinga 2 to start considering as an upgrade.

(I am not an Icinga developer - just a user, and the opinions expressed here are only my own $0.02.)

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-03-03 18:54:01 +00:00

  • Target Version changed from 1.11 to 1.12

feature freeze 1.11

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-10-24 23:15:13 +00:00

Is this still a viable option, or what's the status of this?

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2014-10-26 19:13:20 +00:00

  • Status changed from Feedback to Assigned
  • Target Version deleted 1.12

@icinga-migration
Copy link
Author

Updated by Wolfgang on 2014-10-28 17:50:17 +00:00

  • File added sched_down_0.1.14.pl

I fixed several issues during the last months and added support for "workdays".
Special days defined via "-l ..." are not automatically treated as "day off" because whether they are working days or not might depend on national or regional regulations (e.g. carnival monday, twelfth day, ...). Executing something like

./sched_down.pl -e "workday 4 09:00-10:00" -t 20150101 --m 10

" will result in

"Wed Jan  6 09:00:00 2015 to Wed Jan  6 10:00:00 2015 for 0 mins"

. Adding "twelfth_day day_off" to the holiday file will change that to the next day.

@ziesemer
I disagree. Without specifying "service_description all" SCHEDULE_SERVICEGROUP_HOST_DOWNTIME" will be selected, otherwise SCHEDULE_SERVICEGROUP_SVC_DOWNTIME.

@fgr
This should be fixed.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-02-14 20:14:42 +00:00

  • Category set to Downtimes
  • Target Version set to 1.13

I'll add that to tools/downtimes, update the documentation and we'll close this issue. Future bugs should be reported just like normal.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2015-02-14 21:10:02 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 50 to 100

Applied in changeset cd0c205.

@icinga-migration icinga-migration added this to the 1.13 milestone Jan 17, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Downtimes enhancement
Projects
None yet
Milestone
1.13
Development

No branches or pull requests
1 participant
@icinga-migration