Add xpack core and security to INTEG TEST #77632
Conversation
This change makes it so x-pack-core and x-pack-security are bundled in the INTEG TEST distribution that we use for testClusters in our tests. There are two reasons for this: - In elastic#77231 where we are looking into enabling and auto-configuring security by default for all nodes, we need to call out to ConfigInitialNode to determine whether we should do the auto-configuration or not. - Since we are enabling security by default, we should be looking into enabling security for all for our tests moving forward, or at least make a concsious decision about which ones run without security. This change is a step towards that direction.
|
Pinging @elastic/es-delivery (Team:Delivery) |
|
Pinging @elastic/clients-team (Team:Clients) |
| from(defaultBinFiles) | ||
| include 'x-pack-env', 'x-pack-security-env' |
There was a problem hiding this comment.
Why is this explicit include necessary?
There was a problem hiding this comment.
We will need to call to ConfigInitialNode and to EnrollNodeToCluster from the startup script (either directly or by calling the bash script ) . Either way, we need x-pack-env and x-pack-security-env as we do in all of our security CLI tools. My original change had us copying all bin files but @mark-vieira commented that we don't need all , so I'm just copying the two that we need.
There was a problem hiding this comment.
Hey @rjernst did that answer your question? Any additional concerns/thoughts? Thanks!
There was a problem hiding this comment.
It answered my question, thanks!
|
@mark-vieira @breskeby any thoughts on this ? |
|
@jkakavas Is this backportable to 7.x? The change to check for actually installed modules is important to being able to split up xpack rest tests. |
|
@rjernst Yes, I can't think of any problems. I'll open a backport PR Monday morning |
This change makes it so x-pack-core and x-pack-security are bundled in the INTEG TEST distribution that we use for testClusters in our tests. There are two reasons for this: - In elastic#77231 where we are looking into enabling and auto-configuring security by default for all nodes, we need to call out to ConfigInitialNode to determine whether we should do the auto-configuration or not. - Since we are enabling security by default, we should be looking into enabling security for all for our tests moving forward, or at least make a conscious decision about which ones run without security. This change is a step towards that direction. # Conflicts: # distribution/archives/build.gradle # distribution/packages/build.gradle
This commit no longer explicitly sets the default configuration for FIPS tests. This allows each project's tests to run in FIPS mode with out deviation (other than the FIPS mode). A side product of this change is that any REST test can now enable security if they so choose without needing to use the default distribution. This allows for additional usage of the integ_test distribution which can help with testing modularization. This only possible now that the security plugin is always included with the integ_test distribution via #77632 fixes: #70005 related: #77632
This change makes it so x-pack-core and x-pack-security are bundled
in the INTEG TEST distribution that we use for testClusters in our
tests. There are two reasons for this:
are looking into enabling and auto-configuring security by default
for all nodes, we need to call out to ConfigInitialNode to
determine whether we should do the auto-configuration or not.
into enabling security for all for our tests moving forward, or
at least make a concsious decision about which ones run without
security. This change is a step towards that direction.