Add support for ietf-schedule basic recurrence

[saba8814]

Description

Why

Infix did not have scheduling system, thus this PR adds support for ietf-schedule(RFC9922) standard yang that is wired into the system using crontab. Additionally this PR adds 2 predefined actions that are check-update and reboot.

What to Expect

Scheduler (infix-schedule) — a new YANG module augmenting ietf-system with a schedules list. Each schedule has a recurrence rule and a predefined action. A regression test testing scheduling of reboot predefined-action. Example configuration:

{
  "ietf-system": {
    "system": {
      "infix-schedule:schedules": {
        "schedule": [
          {
            "name": "reboot-test",
            "enabled": true,
            "predefined-action": "infix-schedule:reboot",
            "recurrence": {
              "frequency": "infix-schedule:minutely",
              "interval": 1
            }
          }
        ]
      }
    }
  }
}

Firmware update check — when check-update fires, /usr/sbin/infix-check-update queries the GitHub releases API, compares the latest tag against the running version, and writes a notification to /run/infix-update. The login banner picks this up and displays it to the admin.

Limitations

• Secondly and Yearly recurrence are not supported, since we can not express them in cron
• bymonthday only supports positive integer values 1-31 (ietf-schedule ranges are -31..-1 and 1-31)
• Two predefined-actions defined and implemented, custom command ommitted for now
• Check update script expects github api style

Future work

• Add support for full-fledged unattended upgrades as discussed in Add support for unattended upgrades #1301

Checklist

Tick relevant boxes, this PR is-a or has-a:

• Bugfix
  • Regression tests
  • ChangeLog updates (for next release)
• Feature
  • YANG model change => revision updated?
  • Regression tests added?
  • ChangeLog updates (for next release)
  • Documentation added?
• Test changes
  • Checked in changed Readme.adoc (make test-spec)
  • Added new test to group Readme.adoc and yaml file
• Code style update (formatting, renaming)
• Refactoring (please detail in commit messages)
• Build related changes
• Documentation content changes
  • ChangeLog updated (for major changes)
• Other (please describe):

[mattiaswal]

Also add the the "magic" key word fix #issue number in the PR description, this closes the open issue automatically when merged.

[saba8814]

Also add the the "magic" key word fix #issue number in the PR description, this closes the open issue automatically when merged.

Thing is #1301 is formulated in way that it is support for full unattended upgrade, and this PR adds scheduling stuff and just a check for update availiability thus I ommited it from git message, since full implementation of unnattended-upgrade will be handled in a separete merge request.

[troglobit]

Still haven't had the time to fully look at this, but a few general pointers that are useful:

1. Personally I prefer to use "Add support for" instead of "feat:", it feels more human and invites to a discussion
2. Each PR should have a description which introduces the reviewer to the topic, nothing too in-depth, just a summary of the why:s and what:s to expect. Screenshots is a favorite! This is also a good place to bring up limitations (for example: "most of the advanced features are deviated to allow for a simple good-enough first release", future work, etc.

I hope to have some time tomorrow for a detailed look at the changes 😃

[saba8814]

Still haven't had the time to fully look at this, but a few general pointers that are useful:

1. Personally I prefer to use "Add support for" instead of "feat:", it feels more human and invites to a discussion
2. Each PR should have a description which introduces the reviewer to the topic, nothing too in-depth, just a summary of the why:s and what:s to expect. Screenshots is a favorite! This is also a good place to bring up limitations (for example: "most of the advanced features are deviated to allow for a simple good-enough first release", future work, etc.

I hope to have some time tomorrow for a detailed look at the changes 😃

Thank you, I've added description now, hope it is not too long.

[mattiaswal]

Shouldn't this setting be inside the schudler instead? What do you say @wkz @troglobit

[troglobit]

Quite possibly, please remind me again of this tomorrow.

Sorry for being so late on the ball!

[saba8814]

I've cleaned up other comments, I will wait on this one until I hear your point of view. I believe it shall be under software yang since we might have "action" in future to manually check for update. FYI: @troglobit @mattiaswal

[troglobit]

I think this is OK, but I have another point to make that will tie actions like this back to the scheduler better.

[troglobit]

This is shaping up! I have two architectural points to bring up: the intended pattern in the RFC is to pick the grouping that matches our capability and prune, then bring the schedule to the task rather than the task to a central scheduler.

We have sort of done this, but I think we can do better! 😃

1. Use icalendar-recurrence, prune with deviations

Right now we uses schedule:recurrence-basic and hand-declare byhour, byminute, byday, etc. on top. But those nodes already exist in the RFC's icalendar-recurrence grouping, with semantics pinned to RFC 5545. Declaring them locally means a generic RFC 9922 client sees infix-schedule:byhour instead of ietf-chedule:byhour, we pay for the standard without getting the interop. So, take the top grouping and deviate away what cron can't do:

container recurrence {
  if-feature "schedule:icalendar-recurrence";
  uses schedule:icalendar-recurrence {
    refine frequency {
      mandatory true;   // RFC 9922 §3.3.3 SHOULD; also stops an empty
                        // recurrence from compiling to '* * * * *' (!)
      must "not(derived-from-or-self(., 'schedule:secondly'))";
    }
    refine interval { default 1; }
  }
}

deviation ".../recurrence/recurrence-first"     { deviate not-supported; }
deviation ".../recurrence/until"                { deviate not-supported; }
deviation ".../recurrence/count"                { deviate not-supported; }
deviation ".../recurrence/period"               { deviate not-supported; }
deviation ".../recurrence/bysecond"             { deviate not-supported; }
deviation ".../recurrence/byday/direction"      { deviate not-supported; }
// ... byyearday, byyearweek, bysetpos, workweek-start, exception-dates,
//     time-zone-identifier — same treatment
deviation ".../recurrence/bymonthday" {
  deviate replace { type int32 { range "1..31"; } }
}

What survives is exactly the surface you built — same feature set, standard spelling. Bonuses: the supported-frequency identities and both existing deviations go away (clients configure plain ietf-schedule:daily, the must rejects what we can't do), deviations are advertised in the YANG library so controllers can discover our limits, and when we someday outgrow crond we lift deviations instead of renaming nodes.

2. Drop choice action — schedules become named time-specs, actions reference them

The predefined-action identityref bothers me: the schedule holds the trigger, but check-update's actual config lives in /system/software/ check-update, and nothing in the schema connects them — just a naming convention and a strstr() in schedule.c. Two enabled leaves with undefined interaction, and every new action needs an identity here plus a branch in action_to_cmd(). The scheduler ends up knowing about everything.

This is the old Cisco time-range pattern: make the schedules list a library of pure time definitions (no actions at all), and let each feature own its trigger via a YANG leafref:

/* infix-schedule: just time-specs */
typedef schedule-ref {
  type leafref {
    path "/sys:system/schedules/schedule/name";
  }
}

/* infix-system-software: the feature owns its complete self */
container check-update {
  leaf enabled    { type boolean; default false; }
  leaf update-url { type string; ... }
  leaf schedule   { type ifsched:schedule-ref; }
}

/* scheduled reboot becomes its own small feature */
container scheduled-reboot {
  leaf schedule { type ifsched:schedule-ref; }
}

This gets us validated references (can't delete a schedule still in use, nice when the action is reboot), clean enabled semantics (feature's enabled = whether, schedule's enabled = kill-switch for everything referencing it), sharing (reboot and check-update both pointing at sunday-night is one recurrence to audit), and new schedulable features never touch infix-schedule again. schedule.c shrinks to "schedule name → cron fields"; each feature's callback knows its own command, so action_to_cmd() and the identities go away too. This also sets us up nicely for #1301, where unattended upgrades will grow real policy config around this trigger.

One backend caveat to handle either way: with both day-of-month and
day-of-week set, cron fires on either, while RFC 5545 says intersection, so bymonthday 13 + byday friday means Friday the 13th in the model but "every 13th and every Friday" in the crontab. Simplest fix: must "not(bymonthday and byday)" until someone needs the combination.

I know this is a rework rather than a touch-up, but the cron translation layer you've built carries over almost unchanged, it's only the YANG surface that changes, but this is very important and the leafref addition means it will be possible to validate the config against the YANG model offline!