improve update systems via recurring states

[mcalmer]

What does this PR change?

Implement some improvements to update systems via recurring states.

• provide a standalone salt update state
• improve update stack update state
• check pillar to skip reboot_if_needed if not wanted

GUI diff

No difference.

• DONE

Documentation

• Not needed, but added https://github.com/SUSE/spacewalk/issues/23573

• DONE

Test coverage

• No tests: already covered

• DONE

Links

Issue(s): https://github.com/SUSE/spacewalk/issues/22483
Ports(s): https://github.com/SUSE/spacewalk/pull/23577

• DONE

Changelogs

Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository

If you don't need a changelog check, please mark this checkbox:

• No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

Before you merge

Check How to branch and merge properly!

[rjmateus]

Lgtm. thank you for implementing this one.

[cbbayburt]

How is the mgr_reboot_if_needed pillar set?

[mcalmer]

How is the mgr_reboot_if_needed pillar set?

I think there is no automatic way yet. So by default nothing change compared to what we have now. reboot is always executed if needed.

But a customer can manual set it via /srv/pillar/, gitfs or maybe also via "custom info" (AFAIK we convert them into pillar? - I havn't tried this yet.)

[cbbayburt]

Thanks. LGTM 👍

Related issue just for reference: https://github.com/SUSE/spacewalk/issues/22483

[mcalmer]

When using custom info, it would look like this:

    custom_info:
        ----------
        mgr_reboot_if_needed:
            False

And I think "False" is here a string. I think we can enhance the check to also react on this.

[mcalmer]

I am also looking for some hints if the UI configuration is complete? AFAIK there is somewhere a description which I cannot identify where it comes from.

[cbbayburt]

I am also looking for some hints if the UI configuration is complete? AFAIK there is somewhere a description which I cannot identify where it comes from.

Oh right, descriptions are translated strings in java/StringResource_en_US.xml.

The UI picks it up automatically, looking at the message key internal_state.<state_label>

So you need to add the following:

      <trans-unit id="internal_state.update-salt">
        <source>...</source>
      </trans-unit>

[github-actions]

👋 Hello! Thanks for contributing to our project.
Acceptance tests will take some time (aprox. 1h), please be patient ☕
You can see the progress at the end of this page and at https://github.com/uyuni-project/uyuni/pull/8227/checks
Once tests finish, if they fail, you can check 👀 the cucumber report. See the link at the output of the action.
You can also check the artifacts section, which contains the logs at https://github.com/uyuni-project/uyuni/pull/8227/checks.

If you are unsure the failing tests are related to your code, you can check the "reference jobs". These are jobs that run on a scheduled time with code from master. If they fail for the same reason as your build, it means the tests or the infrastructure are broken. If they do not fail, but yours do, it means it is related to your code.

Reference tests:

• https://github.com/uyuni-project/uyuni/actions/workflows/acceptance_tests_secondary_parallel.yml?query=event%3Aschedule

• https://github.com/uyuni-project/uyuni/actions/workflows/acceptance_tests_secondary.yml?query=event%3Aschedule

KNOWN ISSUES

Sometimes the build can fail when pulling new jar files from download.opensuse.org . This is a known limitation. Given this happens rarely, when it does, all you need to do is rerun the test. Sorry for the inconvenience.

For more tips on troubleshooting, see the troubleshooting guide.

Happy hacking!
⚠️ You should not merge if acceptance tests fail to pass. ⚠️

[mcalmer]

@parlt91 @cbbayburt I added the translation and I have added handling of pillar created via custom_info.
Please check again

[mcalmer]

@admd should this be ported to 4.3 as well? If @parlt91 port the one shot execution for recurring states, this may make sense as well.

[parlt91]

Tested it out and it looks good to me. Just left one comment about the schema upgrade dir above.

[cbbayburt]

@admd should this be ported to 4.3 as well? If @parlt91 port the one shot execution for recurring states, this may make sense as well.

IMO yes. https://github.com/SUSE/spacewalk/issues/22483 is also going to be implemented on top of this.

[admd]

Generally, we plan not to add anything major in 4.3 anymore.

But in this case, this would be a nice change to add in 4.3. It's not that big from code wise so less chance of introducing any regressions.

[rjmateus]

@admd @mcalmer @cbbayburt I was discussion this with MC on the chat. COnsidering that update salt with salt is the a root of problems, and MC (thank you so much) added this state to address the issue, would make sense to keep updating salt on the mgr_keep_system_up2date_updatestack state? [1]
If the user uses this new state before update, we would not have have any problems. However, if salt gets updated, it restarts the agent and forgets about the remaining tasks.

https://github.com/uyuni-project/uyuni/blob/master/susemanager-utils/susemanager-sls/salt/uptodate.sls#L1-L26