Core types/providers are not synced when using bundled-ruby for apply #3310
Labels
Bug
Bug reports and fixes.
Comments
donoghuc
added a commit
to donoghuc/bolt
that referenced
this issue
May 10, 2024
Previously when puppet 5 agents were around we stopped syncing core types and providers because they were conflicting with builtin types. We assumed that we could just use these on agents. For the most part this works, but for the local transport when using bundled-ruby this is not the case. This commit updates apply to sync builtin types and providers. This will result in slightly larget pluginsync tar archives and opens up potential issues for puppet agent incompatabilities between the core types shipped with bolt vs what may be on the agent bolt is targetting. However this risk should be quite small compared with the complexity of trying to handle bundled-ruby case differently for apply.
donoghuc
added a commit
to donoghuc/bolt
that referenced
this issue
May 10, 2024
Previously when puppet 5 agents were around we stopped syncing core types and providers because they were conflicting with builtin types. We assumed that we could just use these on agents. For the most part this works, but for the local transport when using bundled-ruby this is not the case. This commit updates apply to sync builtin types and providers. This will result in slightly larget pluginsync tar archives and opens up potential issues for puppet agent incompatabilities between the core types shipped with bolt vs what may be on the agent bolt is targetting. However this risk should be quite small compared with the complexity of trying to handle bundled-ruby case differently for apply. !bug * **Pluginsync builtin bolt content** [#puppetlabsGH-3310](puppetlabsGH-3310) Previously we were not pluginsyncing builtin content to avoid conflicting with puppet 5 builtin types. This was breaking assumptions for bundled-ruby config and should no longer be an issue with modern agents.
donoghuc
added a commit
to donoghuc/bolt
that referenced
this issue
May 17, 2024
Previously when puppet 5 agents were around we stopped syncing core types and providers because they were conflicting with builtin types. We assumed that we could just use these on agents. For the most part this works, but for the local transport when using bundled-ruby this is not the case. This commit updates apply to sync builtin types and providers. This will result in slightly larget pluginsync tar archives and opens up potential issues for puppet agent incompatabilities between the core types shipped with bolt vs what may be on the agent bolt is targetting. However this risk should be quite small compared with the complexity of trying to handle bundled-ruby case differently for apply. !bug * **Pluginsync builtin bolt content** [#puppetlabsGH-3310](puppetlabsGH-3310) Previously we were not pluginsyncing builtin content to avoid conflicting with puppet 5 builtin types. This was breaking assumptions for bundled-ruby config and should no longer be an issue with modern agents.
donoghuc
added a commit
to donoghuc/bolt
that referenced
this issue
May 17, 2024
This commit shows an alternate approach for handling bundled-ruby: true on local transport for core types and providers. Instead of always syncing those plugins (almost always not-necessary) we simply pass through the buitin content location to the apply_catalog task. If it is detected on the target, builtin content is added to the loadpath. This allows us to avoid pluginsyncing when its not always necessary and handing the case of local transport.
donoghuc
added a commit
to donoghuc/bolt
that referenced
this issue
May 17, 2024
This reverts commit d326ffc.
donoghuc
added a commit
to donoghuc/bolt
that referenced
this issue
May 17, 2024
… local transport When using the local transport defaulting to `bundled-ruby: true` it is assumed an agent is on the target. Generally when a `puppet-agent` feature is applied to a target this is assumed to be the case. This provides the core types and providers when an catalog is applied. We explicitly do not want to pluginsync all the core types and providers when we do not have to. This commit updates the apply_catalog task to take advantage of the fact that bolt packages have the core types in them. This works by sending as a task parameter the install location of bundled module content in bolt packages. After unpacking the plugins sent to the apply_catalog task, if the task finds any modules shipped with bolt, it will add those to the `LOAD_PATH`. This allows us to continue to avoid excessive pluginsync and also support the bundled-ruby config over the local transport. !bug * **Ensure core types are available for apply over local transport** [#puppetlabsGH-3310](puppetlabsGH-3310) Previously when using `bundled-ruby: true` config on the local transport core types were not available during catalog application. This commit makes the core types available by loading the bundled bolt module content shipped with bolt packages if it is present on the target.
mcdonaldseanp
added a commit
that referenced
this issue
May 20, 2024
(GH-3310) Ensure plugin code for core types is available on local transport
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the Bug
When using bundled-ruby on the local transport core types are not pluginsynced. It looks like there used to be an issue with puppet 5. Given that is very long EOL we should be able to just pluginsync bolt's version of core types/providers. If that is a bad idea then for at least the local transport we should.
bolt/lib/bolt/pal.rb
Lines 227 to 230 in f52313e
Expected Behavior
When I run apply using the local transport I can use core types/providers.
The text was updated successfully, but these errors were encountered: