apply_prep installs openvox-agent via puppet-openvox_bootstrap

[jessereynolds]

Replace puppetlabs-puppet_agent with puppet-openvox_bootstrap for automatic installation of openvox-agent rather than puppet-agent packages. (Nb, this doesn’t yet support Windows).

[donoghuc]

I dont think you want another feature (feature in the senese of an attrribute on a target). I think from bolt's perspective the puppet-agent feature just means there is a "puppet librar\y" (meaning a ruby interpreter a puppet executable and a puppet gem w/ its deps) available on a target.

IMO what should be done here is to simply replace the puppet_agent module in the Puppetfile and point to that in the default puppet_library hook. Note you will want the openvox_bootstrap module to indicate what task to run with a bolt_plugin.json file. https://github.com/puppetlabs/puppetlabs-puppet_agent/blob/main/bolt_plugin.json

[jpartlow]

I opened voxpupuli/puppet-openvox_bootstrap#34 for this.

What Cas is saying makes sense to me. Plus if we rename puppet-agent as the feature, we break existing plans that are testing for that feature.

[jpartlow]

I think I also have an incompatibility in openvox_bootstrap. It has a package parameter, because it can install any openvox package. That has a default of openvox-agent, but the type is String[1], rather than Optional[String], and I think that's breaking the specs here?

I think patching that to be Optional[String] is probably ok, although it feels a little loose to me.

[donoghuc]

I dont think you necessarily need to change the task spec. Bolt should just have a sane default parameter that is required here

openbolt/lib/bolt/plugin.rb

Line 133 in b9bff5a

DEFAULT_PLUGIN_HOOKS = { 'puppet_library' => { 'plugin' => 'puppet_agent', 'stop_service' => true } }.freeze

[jpartlow]

I dont think you necessarily need to change the task spec. Bolt should just have a sane default parameter that is required here

openbolt/lib/bolt/plugin.rb

Line 133 in b9bff5a

DEFAULT_PLUGIN_HOOKS = { 'puppet_library' => { 'plugin' => 'puppet_agent', 'stop_service' => true } }.freeze

Ah ok, so this pr needs something like:

 DEFAULT_PLUGIN_HOOKS = { 'puppet_library' => { 'plugin' => 'openvox_bootstrap', 'package' => 'openvox-agent', 'stop_service' => true } }.freeze

And then I need to implement stop_service in the openvox_bootstrap::install task. I thought the packages installed with the service stopped? Or perhaps that's not the case on Windows? It should be easy enough to add.

Does the bolt_plugin.json in the openvox_bootstrap module need any parameter defaults? It looks like that just names the task associated with puppet_library. Although, I'm also not quite sure what bolt_plugin.json does given the above default in the lib/bolt/plugin.rb :)

[donoghuc]

My reccolection of all the exact details is a but hazy... But yeah, that all seems about right!

Does the bolt_plugin.json in the openvox_bootstrap module need any parameter defaults? It looks like that just names the task associated with puppet_library. Although, I'm also not quite sure what bolt_plugin.json does given the above default in the lib/bolt/plugin.rb :)

No defaults in the bolt_plugin.json. All that does is let bolt know that this module has a puppet_library implementation and points it to that task. Anything about task parameter defaults, requirements, or implentations etc belongs in the task metadata that points to.

[jpartlow]

@jessereynolds there's a pr up at voxpupuli/puppet-openvox_bootstrap#35 to help with this.

If you add a temporary commit pinning openvox_bootstrap in the Puppetfile to that jpartlow:gh-35-add-stop-service-to-install branch we can see what happens to the tests here.

[jessereynolds]

@jessereynolds there's a pr up at voxpupuli/puppet-openvox_bootstrap#35 to help with this.

If you add a temporary commit pinning openvox_bootstrap in the Puppetfile to that jpartlow:gh-35-add-stop-service-to-install branch we can see what happens to the tests here.

Great, thanks @jpartlow ! I’ll add that and see what it looks like. From this earlier test failure https://github.com/OpenVoxProject/openbolt/actions/runs/16810148208/job/47613105677?pr=49#step:8:347 it looks like either the install task will need to have a default for the ‘package’ param, or bolt will need to supply it. (correction, I see you’ve addressed that in jpartlow/puppet-openvox_bootstrap@6c07d34 )

I’ll also be re-doing this PR without the addition of the ‘openvox-agent’ as a synonym for ‘puppet-agent'

[jessereynolds]

For interest I created a new branch that has this branch rebased on #48 to see if some tests might fare better. PR in my fork here: jessereynolds#10 … but now I’m wishing we had better data visualisation / quantification for the all the rspec examples (eg maybe something like https://github.com/SonicGarden/rspec-report-action or https://github.com/ctrf-io/github-test-reporter ) to help understand which examples are fixed, and which are newly broken, compared to this PR.

[jpartlow]

For the Apply Tests on linux, the issue is that the openvox_bootstrap::check returns a :test_version value rather than a :version value, which could be fixed either place.

The Apply Tests on windows won't work until openbox_bootstrap gets windows support.

For the BoltSpec Tests, openbox_bootstrap::check isn't fulfilling the role the spec is expecting. It's expecting to be able to run it successfully regardless of whether openvox is installed on that node as a test of whether openvox is installed on that node. I wrote check to take some of the redundancy out of version testing for openbox_bootstrap tests. This could be sorted out either place.

The Linux Integration specs are having container/sudo issues for me locally, not certain if its the same problem as in gha, which has steps related to sudo; my brain isn't working well enough this week to sort it out.

The other two window spec clusters are, um, windowy.

[austb]

We should be able to remove this pin to Josh's fork now that the PR has been merged.

Might need a release to remove the git: ref entirely though