Gh 101 openvox acceptance gha main#120
Merged
jpartlow merged 15 commits intoOpenVoxProject:mainfrom Jun 19, 2025
Merged
Conversation
Contributor
Author
|
Waiting for https://github.com/jpartlow/puppet/actions/runs/15642839849/job/44074051996 to finish grinding through. Ignore the Debian 13 failure. We don't have openvox-server debian 13 packages yet, and I've commented out that plaform in 5cf7c0e. |
Contributor
Author
|
Ok, there are definitely some test failures I need to look into from that Beaker run. Once that run completes I'll grab the log set and sift through them. |
Contributor
Author
|
Ok, have a passing run now with the additional changes: https://github.com/jpartlow/puppet/actions/runs/15741979892/job/44369321462 Rebasing. |
jpartlow
force-pushed
the
gh-101-openvox-acceptance-gha-main
branch
from
226e3ef to
389cf39
Compare
bastelfreak
reviewed
Jun 18, 2025
jpartlow
force-pushed
the
gh-101-openvox-acceptance-gha-main
branch
from
389cf39 to
c00c3ee
Compare
…r acceptance The step bundled up log tarballs which Jira was configured to extract and preserver for inspection. We might want to do something else here now, but for the time being I'm just unhooking it as we don't have anywhere to store them.
The acceptance pipeline was previously tied to use of beaker-puppet rake tasks which would magically include a set of setup presuite steps from that gem in order to install and prep ahead of running the tests/. The beaker-puppet gem is tied to Perforce internals for obtaining packages to test against. We're using Bolt in a prior step to install agent/server packages as needed prior to running Beaker. But we do need some of the setup steps to kick start certs/puppetserver on the primary. I'm extracting those steps from beaker-puppet into a local pre-suite directory for our beaker runs.
There are a few spots in the suite where an attempt is made to 'service foo action' something directly, usually because we're testing status code or attempting to reload. EL9 and others no longer have service, so I've added a little service() helper to lib/helper.rb to pick systemctl or fallback to service or squawk. Where it appeared that puppet-resource would suffice, I switched to using that. One place that needs to keep a direct call to the service subsystem is language/exported_resources.rb test per Eric's comment. Another notable exception is the resource/service/init_on_systemd.rb test, which still makes explicit calls to the 'service' binary because that's explicitly what the test is testing, and it's confined to platforms where the service binary will be present. However a little deeper in the rabbit hole lurks beaker-puppet which provides the with_puppet_running_on() method used throughout the suite, which calls a bounce_service method also in BeakerPuppet::Helpers::PuppetHelpers. And that method *also* attempts to use the sysv service executable... Right now I'm overriding this locally in lib/helpers.rb to sidestep the issue, but we may want to bite the bullet, fork beaker-puppet and either depend on the forked repo directly or generate a different gem.
…re-suite This pre-suite step runs Beaker's configure_type_defaults_on() to get the .ssh/environment setup. Normally beaker-puppet would do this, but it's not capable of installing openvox packages, so the kvm_automation_tooling::standup_cluster plan is handling package installation instead. The configure_type_defaults_on() step is important because Beaker's use of ssh as root relies on the .ssh/environment file supplying PATH to the puppet binaries.
…of beaker.hostname When running the acceptance suite, each agent node was getting its puppet.conf server set to the Beaker master node's hostname value as set in the hosts.yaml. The values in hosts.yaml are somewhat arbitrary, and the puppetserver cert is being configured with dns_alt_names matching fqdn. This patch changes the agent server setting to also be fqdn so they match. (determined in this test by `facter fqdn`)
…sent The i18n tests were failing on almalinux and debian because of locale pre-requisites. Almalinux 8/9 does not have the glibc-all-langpacks installed, unlike rocky, and only has the en_* locales by default. Debian has only the base C.UTF-8 installed by default. I'm taking the blunt approach here and ensuring in the pre-suite that on almalinux glibc-all-langpacks is installed, and on debian locales-all is installed. The tweak to the reset_master_system_locale() helper, was my original fix for the failures on debian, to ensure that we locale-gen en_US before attempting to switch to it (since it's not there by default). On Debian, the enable_local_language() method should have been able to locale-gen desired locales after editing /etc/locale.gen, but this was failing for the first calls to localectl set-locale LANG=en_US.utf8 in the enable_option_disable_i18n.rb test, althought not when done for ja_JP, and not when run for en_US in other tests. I have no idea what was going on there.
This test was failing because it was expecting a certain key ordering of the $server_facts hash (that serverversion would be the first element), and the addition of serverimplementation disrupted that. Rather than trying to match on the printed order of the $server_facts, changed to validate that we have a non-empty $server_facts hash.
The ssl/autosign_command test was assuming a primary with a system ruby for one of it's autosign scripts. Switched it to use the agent's ruby which we know will always be present.
The Beaker agent() method is a dubious creature. It is generated, I believe, by Beaker's Beaker::DSL::Roles.add_role_def() which TestCase uses to generate helper methods from host role values to either an array of matching host objects, or the singular host object if there is only one. This later behavior makes these helpers dangerous since it changes depending on whether Beaker is executed with say [agent1, agent2] hosts or just agent1 hosts. These two tests could pass if a single host was given, but would fail when agent returned an array. For the first case, confine works better than skip test since it constrains the hosts array for the test case. For the second case, the code is operating within an agents.each |host| block, and it was probably a revision somewhere in its past that left some methods stranded using agent() instead of host. It just happened to work as expected in the single node case since agent() would return the same value as host.
Uses the nested_vms action to prepare a cluster of one primary node, then installs openvox-agent and openvox-server, and preps and executes the acceptance/ suite with Beaker.
and add Debian 13 as a test platform, since we are on the main branch, but left it commented out at present since we don't have openvox-server packages built for Debian 13 yet.
…ry use The system package defaults to 2G. Tuning it to half available system memory to take advantage of more memory if available. Since there's no puppetdb in this suite, there's no contention and Java can use half for heap while still reserving half for off-heap and system usage. It could be tuned higher depending on actual memory, but we don't need complex heuristics here and won't be loading the puppetserver anyway. This is just an attempt to give the server a little more breathing space to see if it speeds up the tests at all.
The i18n tests are in an odd state. 3b82c0f added a skip_test to acceptance/tests/i18n/modules/puppet_agent.rb because the eputname-i18ndemo module used by the test has an init class with a call to the old, deprecated stdlib validate_absolute_path() function that would error out the test. However, puppet_agent_cached_ctalog, puppet_apply, puppet_apply_module_lang and puppet_apply_unsupported_lang are all in the same boat. It's possible the test suite was configured to run with strict disabled? Or the i18n/ tests were simply not being run, since there is currently no language localization being done. For now, I'm adding the skip_test to the other affected tests, and they can be removed or the module can be updated in a future audit of the suite.
…eptance workflow Seeing occasional ooms and instances of puppetserver not coming up quickly enough in a reload to handle requests from the following puppet agent call in the test suite. Increasing the memory for the vm to 8GB, coupled with the added acceptance/pre-suite/010_set_puppetserver_memory_defaults.rb pre-suite step will give puppetserver about a 4GB heap with another 4GB available for off-heap and regular system usage. This reduced reload issues in manual testing at least.
…ing test suite Adds a pre-suite step to set droponsde enabled: false in puppetserver.conf when running the pre-suite with puppetserver. The test runs for main, particularly on Debian, have been taking twice as long (2h instead of 1h) due to a 30s delay on each 'systemctl reload puppetserver' call. Disabling dropsonde resolved this for the test suite. OpenVoxProject/openvox-server#24 We want telemetry off anyway when running the test suite, since even when we get it working, we don't want false usage stats from test runs.
jpartlow
force-pushed
the
gh-101-openvox-acceptance-gha-main
branch
from
c00c3ee to
a4423ab
Compare
bastelfreak
approved these changes
Jun 19, 2025
nmburgan
pushed a commit
that referenced
this pull request
Sep 5, 2025
Correct provides statement for Debian packaging
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.