Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Merging Schedules and Rotations #4084

Open
mastercactapus opened this issue Sep 25, 2024 · 0 comments
Open

proposal: Merging Schedules and Rotations #4084

mastercactapus opened this issue Sep 25, 2024 · 0 comments
Labels
enhancement New feature or request proposal

Comments

@mastercactapus
Copy link
Member

Some initial thoughts on deprecating Rotations in favor of making Schedules "smarter".

RFC: Merging Schedules and Rotations in GoAlert

Overview

GoAlert currently manages on-call responsibilities through two separate systems: Schedules and Rotations. Schedules consist of rules (assignments) such as day-of-week filters and optional time windows, which can target either a user or a rotation. Rotations are simple lists of users that rotate based on time intervals.

Current Issues

  1. Always-active rotations: No way to restrict rotations to specific days or hours, requiring manual management.
  2. User confusion: Schedules and rotations can both be assigned to escalation policy steps, and users sometimes get confused about which to use, especially since only schedules have temporary overrides.
  3. Complex rotation code: Rotations rely on database triggers, which makes them hard to maintain and prone to deadlocks. Joining across multiple tables adds complexity when calculating schedules.
  4. Limited future on-call data: Rotations don’t expose future on-call information, which limits integration with external systems that need this data.

Proposed Solution

I propose consolidating rotations into schedules, enhancing schedule functionality to cover all use cases of rotations. The benefits of this solution include:

  1. Deprecating rotations while maintaining compatibility for existing systems, ensuring gradual migration.
  2. Simplifying scheduling logic by storing all configuration in a single JSONB field in schedule_data, removing the need for table joins and database triggers.
  3. Improving future on-call data visibility by consolidating all scheduling logic under schedules.

Long-Term Compatibility Plan

To minimize disruption, rotations will remain in the codebase for a period of time:

  1. Opt-in configuration: Introduce a configuration option to disable new rotations creation. Initially, this will be opt-in, allowing early adopters to transition to schedules.
  2. Opt-out configuration: In a future release, the creation of new rotations will be disabled by default, with the option to opt back in.
  3. Complete removal: Eventually, rotations will be removed entirely, and a newer version of GoAlert will refuse to start or migrate if rotations are detected.
  4. Auto convert/migrate: Include an admin option for bulk migration of existing rotations to schedules when the auto-convert functionality is built.

Migration Strategy

  1. Deprecate Rotations:

    • Add a confirmation before assigning a rotation to an escalation policy.
    • Provide a "Convert to Schedule" link to migrate rotations into schedules.
  2. Enhance Schedules:

    • Allow assigning multiple users to a schedule at once.
    • Add rotation logic into schedules (active shifts, pauses, flexible intervals).
  3. Gradual Feature Rollout:

    • Introduce opt-in config to disable creating new rotations.
    • Later, change this to opt-out so rotations are disabled by default.
    • Eventually, rotations will be removed entirely.
  4. Bulk Migration Tool:

    • Develop an admin tool to bulk migrate existing rotations into schedules.

Database Considerations

  • Expand the existing schedule_data table (JSONB column) to support multi-user assignments and new rotation logic.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request proposal
Projects
None yet
Development

No branches or pull requests

1 participant