Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local transport defaults are not applied when using apply_prep #3309

Closed
donoghuc opened this issue May 8, 2024 · 0 comments
Closed

Local transport defaults are not applied when using apply_prep #3309

donoghuc opened this issue May 8, 2024 · 0 comments
Labels
Bug Bug reports and fixes.

Comments

@donoghuc
Copy link
Member

donoghuc commented May 8, 2024

Describe the Bug

When using the local transport for a target the default behavior is described as using the ruby env shipped with bolt and the puppet-agent feature is set. This only happend on with_connection. When the first action a plan does on a target is apply_prep the targets who need puppet_agents is decided before any actions are run on that target

private def install_agents(targets, options)

Therefore these two plans have different results on the local transport:

plan foo(TargetSpec $targets){
  run_command(whoami, $targets)
  apply_prep($targets)
}
plan foo(TargetSpec $targets){
  apply_prep($targets)
}

The first plan correctly assigns the puppet-agent feature to the resolved$targets, then apply prep does not attempt to install an agent. The second plan attempts to install an agent on the target.

Expected Behavior

Defaults should be assigned when targets are resolved so that the expected state is available whenever the target is referenced.

@donoghuc donoghuc added the Bug Bug reports and fixes. label May 8, 2024
donoghuc added a commit to donoghuc/bolt that referenced this issue May 9, 2024
…t init

Previously defaults were not applied until an action was actually requested on a target. This made inventory resolution confusing and non-determanistic behavior with apply_prep. This commit moves application of defaults for a target to the init method for creating a target object.

!bug

* **Apply bundled-ruby defaults at target creation** ([puppetlabs#3309](3309))

  Ensure defaults associated with `bundled-ruby` transport config are
  applied at target initialization.
donoghuc added a commit to donoghuc/bolt that referenced this issue May 10, 2024
…t init

Previously defaults were not applied until an action was actually requested on a target. This made inventory resolution confusing and non-determanistic behavior with apply_prep. This commit moves application of defaults for a target to the init method for creating a target object.

!bug

* **Apply bundled-ruby defaults at target creation** ([puppetlabs#3309](3309))

  Ensure defaults associated with `bundled-ruby` transport config are
  applied at target initialization.
donoghuc added a commit to donoghuc/bolt that referenced this issue May 10, 2024
…t init

Previously defaults were not applied until an action was actually requested on a target. This made inventory resolution confusing and non-determanistic behavior with apply_prep. This commit moves application of defaults for a target to the init method for creating a target object.

!bug

* **Apply bundled-ruby defaults at target creation** ([puppetlabs#3309](3309))

  Ensure defaults associated with `bundled-ruby` transport config are
  applied at target initialization.
donoghuc added a commit that referenced this issue May 13, 2024
(GH-3309) Ensure bundled-ruby defaults are applied at target init
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Bug reports and fixes.
Projects
None yet
Development

No branches or pull requests

1 participant