Salt 3008 migration

[jpmckinney]

Migration repo: https://github.com/saltstack/great-module-migration
Purge Git issue: saltstack/salt#65970

Blocked until 3008 release

modules

• I don't think any modules removed in PR 65971 affect us.

states

From 65971:

• alias (core)
• alternatives (core)
• debconf (core)
• mysql_database (wordpress)
• mysql_grants (wordpress)
• mysql_user (wordpress)
• gem (redmine)
• rvm (redmine)
• svn (redmine)
• webutil (htpasswd)

Looks like postgres is saved for now.

The Redmine server will not last long term, so we can abandon it instead of upgrading, if needed.

[RobHooper]

Ubuntu 26.04 has added support for the new DEB822 apt repository format, this modern format is preferred and the following warning can be seen:

N: Some sources can be modernized. Run 'apt modernize-sources' to do so.

Support for the DEB822 format has been added in Salt 3008 (saltstack/salt#67956)

The one apt source that will need additional attention is Percona which is configured via their custom command rather than directly in salt.

[RobHooper]

Checking through our code, this is the current state support:

Nothing to do:

• alias – Was not removed
• debconf – Was not removed

Partial removal:

• alternatives – Present as a module but not a state
• webutil (htpasswd) - Present as a module but not a state

Apache was removed ahead of scheduled.
Moved to saltext-apache

• apache_module
• apache_conf
• apache_site

Moved to saltext-mysql

• mysql_database (wordpress)
• mysql_grants (wordpress)
• mysql_user (wordpress)

No longer in use:

• gem (redmine)
• rvm (redmine)
• svn (redmine)

[RobHooper]

For 'alternatives' I have drafted the following replacement solution.

 editor:
   cmd.run:
    - name: update-alternatives --set editor {{ editor }}
    - unless: test "$(readlink /etc/alternatives/editor)" = "{{ editor }}"
     - require:
       - pkg: vim

Alternatives and webutil are both still present in salt but only as modules. I am inclined to fully replace these states in our code as, from my reading, it is not clear what the Salt maintainers intended and are planning.

We can replace the Apache states easily as the files and modules are all managed via symlinks.

MySQL is more involved to manage, if we want to retain full control over the MySQL integration I suggest we write a custom script to manage databases, users and grants. The Salt docs detail how to make stateful scripts
https://docs.saltproject.io/en/latest/ref/states/all/salt.states.cmd.html#using-the-stateful-argument

We have the option of installing and using the salt extensions, the concern is that they rely on the community to maintain, that said Apache and MySQL I would expect to be popular and well supported.

@jpmckinney do you have a preference on Apache and MySQL between managing them with more custom salt workarounds or using the salt extensions?

[jpmckinney]

I figure let's use the extensions unless we discover a reason not to.

For alternatives and debconf, the states no longer work? Just want to double-check they aren't working despite not advertising states.