(PE-19049) add meep classification feature flag #48
Conversation
This file contains 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
|
Can one of the admins verify this patch? |
|
Refer to this link for build results (access rights to CI server needed): |
This had been added to allow upgrade testing in flanders with meep for classification prior to our having completed an upgrade workflow in the installer. Now that meep is being worked on in the pe-modules-next package behind a feature-flag, this gate is counter-productive, particularly for Flanders upgrade testing because it masks the common case of upgrading without specifying a pe.conf.
Major PE modules development work is being done in a separate pe-modules-next package. The installer shim decides which pe-modules package to install based on a pe.conf flag. This patch allows Jenkins CI to trigger this by picking up ENV['PE_MODULES_NEXT'] and ensure that the flag is set in the opts[:answers] which will then be transferred to pe.conf by beaker-answers, and then picked up by the installer shim during installation.
...if we are installing with the pe_modules_next flag. The pe-modules-next is meep classification at the moment and needs a 2.0 pe.conf generated.
jpartlow
force-pushed
the
issue/flanders/pe-19049-add-meep-classification-feature-flag
branch
from
456c3ac to
a23d762
Compare
|
Refer to this link for build results (access rights to CI server needed): |
to make it easier to test. Flags can be set in the :answers Hash or picked up from environment variables. In the later case, we need to be able to preserver them in the :answers hash, if not already present, so that BeakerAnswers ensures that they are set in the generated pe.conf file.
The version variable is not used in the fetch_pe_on_windows method (and hopefully wasn't producing a useful side effect...) The removed snapshot and box keys in HOST_DEFAULTS were being overwritten by later keys in the same hash definition and were producing warnings...
…ation so we can adjust tests and setup steps that need to work either with old pe node groups, or with meep. Ultimately the test is just based on version boundary. But while we are validating meep classification, we need to be able to toggle around a temporary feature flag: the pe_infrastructure::use_meep_for_classification parameter. The function checks to see if this has been passed into beaker via the hosts file answers hash. These are answers which beaker-answers would include in the pe.conf it generates. It can also be set from an ENV['PE_USE_MEEP_FOR_CLASSIFICATION'] variable. This will make it easier to setup temporary ci jobs. The answer file setting will take precedence over the environment variable.
The individual specs were already requiring beaker. This change just centralizes that into the spec_helper, and removes the beaker_test_helper now that we are using Beaker 3.
platform configuration of the master node. Expect to use the beaker-pe-large-environments::classification#get_dispatcher() method, which will only be present during a pe_acceptance_tests run, when beaker-pe-large-environments is part of the gem bundle.
The mock hosts being generated for tests where failing when :exec was called, despite the allow() in the helpers.rb make_host() function. Using a Beaker::Host resolved this.
We began managing the puppet service in 2017.1.0 and need to ensure it is stopped and disabled after installation, otherwise each subsequent puppet agent run will restart the agent service, causing potential havoc in smoke tests or other setup steps.
...using the update_pe_conf function. Since a null isn't meaningful for a hocon lookup parameter in pe.conf (or at least, I can't think of why it would be, at the moment), a nil can be used to remove a parameter that we want to clean up from the file. It's possible I am overlooking something tricky about nil, undef in hiera/lookup...it might be applicable to a nodes.conf file where we wanted to clear a parameter on a specific node that had been set in pe.conf, but this function only applies to pe.conf, so I think this is acceptable for now.
This is necessary if we need to adjust parameters for a specific node rather than for all infrastructure via pe.conf.
jpartlow
force-pushed
the
issue/flanders/pe-19049-add-meep-classification-feature-flag
branch
from
a23d762 to
ea8fb4b
Compare
|
Refer to this link for build results (access rights to CI server needed): |
|
Replaced by #59 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is part of a cluster of PRs to update Beaker plugins and the pe_acceptance_test suite for meep with classification.
(PE-19049,PE-18718,PE-18799) Provide a test method for meep classific… …
…ation
so we can adjust tests and setup steps that need to work either with old
pe node groups, or with meep.
Ultimately the test is just based on version boundary. But while we are
validating meep classification, we need to be able to toggle around a
temporary feature flag: the pe_infrastructure::use_meep_for_classification
parameter.
The function checks to see if this has been passed into
beaker via the hosts file answers hash. These are answers which
beaker-answers would include in the pe.conf it generates.
It can also be set from an ENV['PE_USE_MEEP_FOR_CLASSIFICATION']
variable. This will make it easier to setup temporary ci jobs.
The answer file setting will take precedence over the environment
variable.
(PE-19049) Modify how we obtain console dispatcher for frictionless …
platform configuration of the master node. Expect to use the
beaker-pe-large-environments::classification#get_dispatcher()
method, which will only be present during a pe_acceptance_tests run,
when beaker-pe-large-environments is part of the gem bundle.
(PE-19049,PE-11353) Ensure puppet service is stopped in 2017.1+ builds …
We began managing the puppet service in 2017.1.0 and need to ensure it
is stopped and disabled after installation, otherwise each subsequent
puppet agent run will restart the agent service, causing potential havoc
in smoke tests or other setup steps.