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