Add support for 3.0.x repo

[Arakmar]

Support for 3.0.x added for apt and yum repo
The default has been kept to 2.7.x for now

[bastelfreak]

@Arakmar thanks for the PR! Can you add some tests for it that use the new repo?

[bastelfreak]

@Arakmar ping :)

[Arakmar]

I added one acceptance test about the migration to 3.x.
It triggered some timing problems in case of upgrades (which wasn't tested before), no problem on first run. To fix that, I adjusted the admin socket check to be more reliable.

Also, there are no 3.x packages for Debian 11 and Redhat 8 in the proxysql repo.
I'm not really sure where github actions are getting the test matrix, from operatingsystem_support ?

[bwitt]

Also, there are no 3.x packages for Debian 11 and Redhat 8 in the proxysql repo.
I'm not really sure where github actions are getting the test matrix, from operatingsystem_support ?

@Arakmar it's from metadata.json. See https://github.com/voxpupuli/puppet_metadata for more info.

[vmpr]

We're in exactly this situation right now: on Debian 13 (trixie), upstream only publishes ProxySQL 3.0.x packages — proxysql-2.7.x/trixie/ was never built (HTTP 404), while proxysql-3.0.x/trixie/ exists (currently up to 3.0.10; cf. sysown/proxysql#5179, where trixie support was tied to the 3.0 line). So for trixie users this PR is the only way to keep using the module with a managed repo.

Since the branch meanwhile conflicts with master (the rubocop autofix from modulesync touched spec/classes/proxysql_spec.rb), we rebased the two commits onto current master — the only conflict was trailing-comma style in that spec file, everything else applied cleanly: https://github.com/vmpr/puppet-proxysql/tree/add-3.0.x-repo-rebased
@Arakmar feel free to reset/cherry-pick your branch onto it to refresh the PR.

We're deploying this branch to Debian 13 hosts with ProxySQL 3.0.10 in the next days and can report results here if that helps.

On the CI-matrix question above: 3.x packages exist upstream for Debian 12/13 and Ubuntu 22.04/24.04, but not for Debian 11 / EL8 — so the 3.0 acceptance test would need to skip those as long as they stay in metadata.json.

Is there anything else we can do to help get this over the line?

[vmpr]

Test report — this PR rebased onto current master, ProxySQL 3.0.10 on Debian 13 (trixie), OpenVox 8

As promised: we ran this branch end-to-end on a Debian 13 (trixie) node (OpenVox 8 agent + server), module git-pinned to this PR rebased onto current master (vmpr/puppet-proxysql@add-3.0.x-repo-rebased, manifests identical to fb54e79).

Hiera config used: manage_repo: true, version: '3.0.10', package_ensure: 'installed', Sensitive admin/monitor passwords, loopback listeners, servers/users via override_config_settings.

Results:

• First run: full convergence in a single run, no errors (~19 s). $repo30 renders the apt source for the proxysql-3.0.x/trixie flat repo correctly, the keyring-style key => {name, source} works with puppetlabs-apt 11.3.2, package 3.0.10 installs, config renders, systemd drop-in + service start clean, both wait_for_admin_socket_availability_* execs and reload-config succeed (client = mariadb-client 11.8's mysql).
• Second run: fully idempotent, 0 changes.
• Admin interface (6032) and application traffic through the proxy verified working; monitor pings against the backend OK.

One note worth a README line (or a future fallback bump): the $version default pick($short_proxysql_version_fact,'2.7.1') means a fresh node (no proxysql binary yet → fact absent) selects $repo27 on the first run — and proxysql-2.7.x/trixie/ does not exist upstream (HTTP 404). So with manage_repo: true on trixie an explicit version (e.g. '3.0.10') is required for the first run.

Hope this helps getting the PR over the line — happy to re-test on demand.