Skip to content

Commit a7e0116

Browse files
Add ADR for more background to the fix.
Signed-off-by: Gavin Didrichsen <[email protected]>
1 parent fc5889d commit a7e0116

File tree

1 file changed

+54
-0
lines changed

1 file changed

+54
-0
lines changed
Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
# 1. Ubuntu 24 Collection Selection for puppet_agent::install Task
2+
3+
Date: 2025-04-23
4+
5+
## Status
6+
7+
Proposed
8+
9+
## Context
10+
11+
When running Bolt apply with Ubuntu 24 (codename: noble), installations were failing because the puppet_agent::install task defaulted to using the generic 'puppet' collection, resulting in the installation of `puppet-release-noble.deb` instead of the version-specific `puppet8-release-noble.deb`.
12+
13+
This issue specifically affected Ubuntu 24, while other operating systems worked correctly. The underlying cause was that the generic 'puppet' repository didn't properly support Ubuntu 24, whereas the version-specific repositories (like 'puppet8') did have proper packages available.
14+
15+
The puppet_agent::install task (implemented in install_shell.sh) provides a mechanism for installing the Puppet agent across various platforms. It accepts parameters including 'collection', which determines which package collection to use. If no collection is specified, it was defaulting to the generic 'puppet' collection.
16+
17+
A temporary fix was implemented in Bolt's apply_prep.rb function, which added logic to determine the Puppet version and set the collection parameter accordingly. While this fix worked, it violated architectural separation of concerns by placing target-specific logic in the higher-level orchestration function.
18+
19+
## Decision
20+
21+
Move the Puppet version detection and collection selection logic from Bolt's apply_prep function to the puppet_agent::install task's install_shell.sh script, which is the architecturally appropriate location for this functionality.
22+
23+
The implementation enhances the collection selection logic to:
24+
25+
1. First check if a collection was explicitly specified
26+
- If so, use that collection as before
27+
- This maintains backward compatibility and user control
28+
29+
2. If no collection is specified, intelligently determine the appropriate collection:
30+
- First try to detect Puppet version from `/opt/puppetlabs/puppet/VERSION`
31+
- If that fails, try using the `puppet --version` command
32+
- Use the major version to set the collection to `puppet{major_version}` (e.g., `puppet8`)
33+
- Only fall back to the generic `puppet` collection as a last resort
34+
35+
This ensures that for Ubuntu 24, the task will use puppet8-release-noble.deb (assuming Puppet 8) instead of puppet-release-noble.deb.
36+
37+
Rationale:
38+
39+
- The task script is the appropriate location for OS-specific installation logic, maintaining separation of concerns.
40+
- The task already handles platform-specific behavior, making it the natural location for this enhancement.
41+
42+
## Consequences
43+
44+
Positive:
45+
46+
- Ubuntu 24 installations now work correctly out of the box.
47+
- The solution keeps high-level consumers, like bolt, agnostic to implementation details.
48+
- All platforms will now prefer version-specific collections by default, which is generally more reliable.
49+
50+
Negative:
51+
52+
- The install_shell.sh script becomes slightly more complex with additional logic.
53+
- The solution relies on either /opt/puppetlabs/puppet/VERSION existing or the puppet command being available, though it falls back gracefully if neither is available.
54+
- If a very different version of Puppet is running Bolt compared to what should be installed on the target, this approach might select a non-optimal collection. However, this is mitigated by the ability to explicitly specify a collection when needed.

0 commit comments

Comments
 (0)