schema: Change as needed for the new rotations #193
Conversation
nilmerg
force-pushed
the
schema-for-rotation-configuration
branch
5 times, most recently
from
4ba93ab to
5f7d8ff
Compare
not final yet, just a first attempt prior any usage
nilmerg
force-pushed
the
schema-for-rotation-configuration
branch
from
5f7d8ff to
ff76b83
Compare
Is there an issue in the web project that explains how those are supposed to work that you can reference here? How is all of this supposed to be interpreted? What needs more explanation: Footnotes
|
|
Updated the description. The changes in Web are already in a state, that they are fully functional with these changes applied. |
Is Is it correct as a very high-level summary that with this, a new schedule is now a list of what previously was a schedule (and is now called rotation)? So to resolve the schedule to recipients at a specific time, evaluate each rotation like an old schedule was evaluated. Do this for each rotation in the order given by |
Yes. Think of a
I'd rephrase
with
|
|
As just discussed with @nilmerg: this change makes the |
nilmerg
force-pushed
the
schema-for-rotation-configuration
branch
from
b212483 to
0cbee4d
Compare
| CREATE TABLE schedule_member ( | ||
| schedule_id bigint NOT NULL REFERENCES schedule(id), | ||
| timeperiod_id bigint NOT NULL REFERENCES timeperiod(id), | ||
| CREATE TABLE rotation_member ( |
There was a problem hiding this comment.
Table rotation_member must be created before timeperiod_entry.
Same in upgrade file.
schema/pgsql/schema.sql
Outdated
| -- Set in case the first_handoff was in the past during creation of the rotation. | ||
| -- It is essentially the creation time of the rotation. | ||
| -- Used by Web to avoid showing shifts that never happened | ||
| actual_handoff bigint, |
There was a problem hiding this comment.
It is essentially the creation time of the rotation.
Even if first_handoff is set to be in the future when creating the rotation?
There was a problem hiding this comment.
No, in that case it's NULL
There was a problem hiding this comment.
Can you always set it? That would actually make it useful as it would allow to easily determine the currently active version of the rotation (the one with the largest value of actual_handoff, that is at or before the current time).
There was a problem hiding this comment.
first_handoff should suffice for this job, shouldn't it?
There was a problem hiding this comment.
Only if the switchover to the newer version happens at a fixed time like 00:00 UTC. Otherwise, it misses timezone and/or time of day information.
This is a fundamental and incompatible change to how schedules are defined. Now, a schedule consists of a list of rotations that's ordered by priority. Each rotation contains multiple members where each is either a contact or a contact group. Each member is linked to some timeperiod entries which defines when this member is active in the rotation. This commit already includes code for a feature that was planned but is possible using the web interface at the moment: multiple versions of the same rotation where the handoff time defines when a given version becomes active. With this change, for the time being, the TimePeriod type itself fulfills no real purpose and the timeperiod entries are directly loaded as part of the schedule, bypassing the timeperiod loading code. However, there still is the plan to add standalone timeperiods in the future, thus the timeperiod code is kept. More context for these changes: - Icinga/icinga-notifications-web#177 - #193
This is a fundamental and incompatible change to how schedules are defined. Now, a schedule consists of a list of rotations that's ordered by priority. Each rotation contains multiple members where each is either a contact or a contact group. Each member is linked to some timeperiod entries which defines when this member is active in the rotation. This commit already includes code for a feature that was planned but is possible using the web interface at the moment: multiple versions of the same rotation where the handoff time defines when a given version becomes active. With this change, for the time being, the TimePeriod type itself fulfills no real purpose and the timeperiod entries are directly loaded as part of the schedule, bypassing the timeperiod loading code. However, there still is the plan to add standalone timeperiods in the future, thus the timeperiod code is kept. More context for these changes: - Icinga/icinga-notifications-web#177 - #193
This is a fundamental and incompatible change to how schedules are defined. Now, a schedule consists of a list of rotations that's ordered by priority. Each rotation contains multiple members where each is either a contact or a contact group. Each member is linked to some timeperiod entries which defines when this member is active in the rotation. This commit already includes code for a feature that was planned but is possible using the web interface at the moment: multiple versions of the same rotation where the handoff time defines when a given version becomes active. With this change, for the time being, the TimePeriod type itself fulfills no real purpose and the timeperiod entries are directly loaded as part of the schedule, bypassing the timeperiod loading code. However, there still is the plan to add standalone timeperiods in the future, thus the timeperiod code is kept. More context for these changes: - Icinga/icinga-notifications-web#177 - #193
This is a fundamental and incompatible change to how schedules are defined. Now, a schedule consists of a list of rotations that's ordered by priority. Each rotation contains multiple members where each is either a contact or a contact group. Each member is linked to some timeperiod entries which defines when this member is active in the rotation. This commit already includes code for a feature that was planned but is possible using the web interface at the moment: multiple versions of the same rotation where the handoff time defines when a given version becomes active. With this change, for the time being, the TimePeriod type itself fulfills no real purpose and the timeperiod entries are directly loaded as part of the schedule, bypassing the timeperiod loading code. However, there still is the plan to add standalone timeperiods in the future, thus the timeperiod code is kept. More context for these changes: - Icinga/icinga-notifications-web#177 - #193
This is a fundamental and incompatible change to how schedules are defined. Now, a schedule consists of a list of rotations that's ordered by priority. Each rotation contains multiple members where each is either a contact or a contact group. Each member is linked to some timeperiod entries which defines when this member is active in the rotation. This commit already includes code for a feature that was planned but is possible using the web interface at the moment: multiple versions of the same rotation where the handoff time defines when a given version becomes active. With this change, for the time being, the TimePeriod type itself fulfills no real purpose and the timeperiod entries are directly loaded as part of the schedule, bypassing the timeperiod loading code. However, there still is the plan to add standalone timeperiods in the future, thus the timeperiod code is kept. More context for these changes: - Icinga/icinga-notifications-web#177 - #193
rotation
Holds the configuration of a specific rotation.
priority: As the comment states, the lower the more important. Meaning: The shifts described by a rotation with a higher priority (i.e. lower integer) overrides others with a lower one:
weekends: 2
anytime: 1
dayshift: 0
mode: The configuration type. It describes the pattern the timeperiod entries, associated to each member, have.
rotation_member
Maps a member of a rotation to a specific contact or contactgroup.
position: Defines the order the member placed at inside the rotation.
Though, this is probably not of interest to the daemon. As timeperiod_entry also describes it.
timeperiod_entry
Every member of a rotation has at least one entry associated with it inside the timeperiod of a rotation.
The order of a rotation's members is incorporated in the definition of their entries here.
The daemon just has to interpret them, based on the priority of their rotation, to know who's on duty. Look at the first screenshot again, as the Result is what the intended effect should be.