Timeperiod-Ranges and Director-Import

Hi Everyone,

I´m currently working on implementing holidays dynamicly via an external api into the Icinga-Director to use them as timeperiod-objects for excludes and special notification definition. The import itself is working as intended, but I can´t get the import of the ranges working. I´ve already played around with the director-ui and even the code itself and it doesn´t seem to work. If I set “Time Ranges” in the destination filed of the sync rule I can only set one parameter as source column. When it is loaded it gets casted to an array which leads to ranges like “ARRAY_INDEX => SOURCE_COLUMN” i.e “0 => 00:00-24:00” which is not correct. Is there a way to correctly assign the key and value for the range-object via the sync rule? Maybe if I use custom expressions and a special notation or something like that?

Thanks in advance,
DrDth

Can you provide some details on this? I’m not familiar with the code :slight_smile:

Cheers,
Michael

Hi Michael,

thanks for the quick response.
In short, here is the code which loads the variable for the creation of the time-range object:

protected function setRanges($ranges)
    {
        $this->ranges()->set((array) $ranges);

        return $this;
    }

So, if I configure my time-range in the sync-rule like this:

It gets saved in the db-field just as a string (if I understand correctly).
Here is the Output of the method above with some debugging:

var_dump of $ranges in the method:

string(10) "2019-11-20"

var_dump of ((array) $ranges) which gets set as the range-object:

array(1) 
{ 
[0] => string(10) "2019-11-20"
}

If I synchronize this rule, the generated time-range-objects look like this:

which is the array casted from the $ranges-String and which is not correct.

Maybe I am missing a method of defining both, the key and the value for the time-range-object? Is there one? Or is it simply not implemented in the moment?

bfn
DrDth

Hi,

breaking it down in Icinga 2 DSL, the ranges attribute is a dictionary/hash which holds key value pairs.

So, the source field becoming `${date} from your import needs to provide such, e.g.

{
  "monday" = "07:00-17:00
  "2020-01-19" = "03:13-03:15"
}

The question is now, how does your import source look like?

Cheers,
Michael

Hi,

at the moment my import source is a json file from the fileshipper module. It provides 3 values for each holiday:

name, which is the name of the holiday,
date, which is the actual date of the holiday
and time which is the time-range of the holiday (0:00-24:00 for every holiday)

Here is an example of the json-file:

[
    {"name":"Karfreitag","date":"2019-04-19","time":"00:00-24:00"},
    {"name":"Ostermontag","date":"2019-04-22","time":"00:00-24:00"} ...
]

I use the columns just like that in the snyc-rule. And I played around with it quite a bit e.g using the custom expression ${date} = ${time} as source-column for the ranges object or just one of the two values and so on. Nothing seems to work at the moment.

Cheers,
DrDth

Hi,

that won’t work well since this just creates key-value pairs not connected to each other. The last one is then assigned to the ranges attribute, and as such, it fails with validation then.

I haven’t tried it, but listening to @mfrosch 's explanations, I would consider building a hash set in your import source already, similar to an SQL query result. Imho the value assigned to ranges needs to look like this from your given example:

[
  "tp_ranges": {

     {"2019-04-19": "00:00-24:00"},
     {"2019-04-22": "00:00-24:00"} ...
 }
]

The thing I am not sure is if you would be able to manipulate structures from fileshipper’s json data from your sample to the expected one. Or let’s say, this is the one I’d assume from the code and errors and knowing the Icinga 2 DSL - did you try such a structure already?

Cheers,
Michael