-
Notifications
You must be signed in to change notification settings - Fork 16
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
Agent MSI support #212
Agent MSI support #212
Conversation
@amitkanfer is it possible to have the MSI set the --base-path option for the agent install command? (as @cmacknz mentions here)? Setting the path was a big requirement from enterprises and I can't see any reason why it wouldn't also be a requirement for the same set of users who would want to utilize the MSI (aside from Defend users of course). it would be great not to have diverging product behaviors if possible. (of course I am saying this not knowing what the amount of effort involved exactly is) |
i'll look into that @nimarezainia . My concern is more around the uninstall flow. Not sure how the new base path will be available to the "add/remove features" and the other native Windows applications. Probably a solved problem, but i just need to understand them. |
I also need to check and implement upgrade flows. editing the description |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When this gets merged, at what point is it included in the stack release process? Does it show up in the snapshots for the next minor and would be released what that version is released? Or is there more work to do to have this actually show up in the downloads page for agent?
Following from having a way to build this, we need a way to test it. Likely we can do this as an agent integration test, but since this isn't actually packaged from the agent repository we'd only want the test to run every time there is a new snapshot (or once per day or something).
@@ -68,6 +68,12 @@ static bool FromFilenameOrUrl(string fileName, string url, out ArtifactPackage a | |||
Architecture = rxGroups["arch"].Value.ToLower(); | |||
IsSnapshot = !rxGroups["snapshot"].Value.IsEmpty(); | |||
|
|||
// HACK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a better way to do this, or will this live on forever :)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's a very good question :)
Co-authored-by: Craig MacKenzie <[email protected]>
There will be a follow up PR to make the necessary changes in the pipelines. @dliappis is will be reviewing the work. We should be able to first merge this PR, make sure there's no impact on existing (beats) MSIs, and then trigger the agent MSI flow. At the moment, i'm focused on testing the install / upgrade / uninstall flows. Once they work 100% i'll cleanup the PR and go through the review cycle |
Will try following https://stackoverflow.com/a/17790056 to show error messages to the end user. Note that this is valid only when running the installer w/o MDMs |
process.StartInfo.CreateNoWindow = true; | ||
session.Log("Running command: " + process.StartInfo.FileName + " " + process.StartInfo.Arguments); | ||
process.Start(); | ||
session.Log(process.StandardOutput.ReadToEnd()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also log process.standarderror?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's trickier to do both and didn't succeed on the first try... so yes, we should, will work on it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for now i just switched to stderr instead of stdout
System.Diagnostics.Process process = new System.Diagnostics.Process(); | ||
process.StartInfo.WorkingDirectory = install_folder; | ||
process.StartInfo.FileName = Path.Combine(install_folder, "elastic-agent.exe"); | ||
process.StartInfo.Arguments = "install -f " + install_args; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we consider always adding --delay-enroll so that installation success doesn't depend on fleet service reachability + valid API token?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one of the tasks was to make sure the service was up and running right after the installation flow... Don't you think the admin would want to know if the token is wrong when rolling out agent installations?
As the release manager can't trigger the workflow introduced in 566b9e4 , we maintain the old way of building snapshot/staging beats artifacts by keeping the trigger pipeline only for that branch. Note: this means that this PR **MUST NOT** be backported to the elastic-stack-installers 7.17 branch. Details: https://elasticco.atlassian.net/browse/REL-1004?focusedCommentId=107973
Add Install, Upgrade, and Uninstall MSI tests using Pester w/ Powershell Core
…uild on test failure for now.
* first draft * 6 * 6 * Preventing agent upgrade via MSI * Update src/installer/BeatPackageCompiler/BeatPackageCompiler.cs Co-authored-by: Craig MacKenzie <[email protected]> * Update README.md * Update README.md * Fixing uninstall flow and install cleanup flow * rolling back if agent install command fails * redirecting stdout to MSI log * Failing the uninstall flow in case agent uninstall command fails * Don't attempt calling agent install if the file doesn't exist * adding BK logic (#219) * Update build.ps1 * Clean up path length Instead of re-cloning to a checkout with a shorter path, we rename the existing BK checkout. * Fix 798ff24 * Typo * Build from MANIFEST_URL and don't sign This commit implements the refactoring to allow a short term integration with the unified release. It's meant to be triggered by getting passed a $MANIFEST_URL and $DRA_WORKFLOW env var. * Update README.md Co-authored-by: Craig MacKenzie <[email protected]> * Update README.md Co-authored-by: Craig MacKenzie <[email protected]> * Update README.md Co-authored-by: Craig MacKenzie <[email protected]> * Update README.md Co-authored-by: Craig MacKenzie <[email protected]> * Redirecting stderr and removing PATH manipulation for Agent MSI * Remove cron schedule As discussed in https://elasticco.atlassian.net/browse/REL-1004?focusedCommentId=107598 * Trigger 7.17 beats DRA using schedule As the release manager can't trigger the workflow introduced in 566b9e4 , we maintain the old way of building snapshot/staging beats artifacts by keeping the trigger pipeline only for that branch. Note: this means that this PR **MUST NOT** be backported to the elastic-stack-installers 7.17 branch. Details: https://elasticco.atlassian.net/browse/REL-1004?focusedCommentId=107973 * Making sure Agent MSI runs as an administrator * Add MSI tests for Agent Pipeline (#220) Add Install, Upgrade, and Uninstall MSI tests using Pester w/ Powershell Core * Enabling agent tests * Disable "Default" test case as it doesn't exist anymore. Don't fail build on test failure for now. * Default mode clean-up * Update build.ps1 --------- Co-authored-by: Craig MacKenzie <[email protected]> Co-authored-by: Dimitrios Liappis <[email protected]> Co-authored-by: William Easton <[email protected]> Co-authored-by: William Easton <[email protected]>
This commit fixes a bug introduced in PR elastic#212 which missed the switch from WORKFLOW -> DRA_WORKFLOW from the publish step, resulting in failures[^1]. [^1]: https://buildkite.com/elastic/elastic-stack-installers/builds/3641#018d5b0b-5ae5-404c-b79f-211468f45413/51-52
This commit fixes a bug introduced in PR #212 which missed the switch from WORKFLOW -> DRA_WORKFLOW from the publish step, resulting in failures[^1]. [^1]: https://buildkite.com/elastic/elastic-stack-installers/builds/3641#018d5b0b-5ae5-404c-b79f-211468f45413/51-52
This commit fixes a bug introduced in PR #212 which missed the switch from WORKFLOW -> DRA_WORKFLOW from the publish step, resulting in failures[^1]. [^1]: https://buildkite.com/elastic/elastic-stack-installers/builds/3641#018d5b0b-5ae5-404c-b79f-211468f45413/51-52
This commit fixes the downloaded artifacts path to the expected path by the release manager image (`bin/out`). The original path was changed in #212 and the previous step because path lengths exceeded a limit imposed by the msi builder.
This commit fixes the downloaded artifacts path to the expected path by the release manager image (bin/out). The original path was changed in #212 and the previous step because path lengths exceeded a limit imposed by the msi builder.
This commit fixes the downloaded artifacts path to the expected path by the release manager image (bin/out). The original path was changed in #212 and the previous step because path lengths exceeded a limit imposed by the msi builder.
This reverts commit ffffea6.
This commit fixes the downloaded artifacts path to the expected path by the release manager image (bin/out). The original path was changed in #212 and the previous step because path lengths exceeded a limit imposed by the msi builder.
PR #212 made some changes on `main` that require the presence of `MANIFEST_URL`. However, the pipeline is still configured to run the same script when a PR (from an upstream branch) is raised and it currently fails. This commit skips tests when triggered from another pipeline (unified release), and allows running tests when triggered by PR creation by picking up a suitable `MANIFEST_URL`.
PR #212 made some changes on `main` that require the presence of `MANIFEST_URL`. However, the pipeline is still configured to run the same script when a PR (from an upstream branch) is raised and it currently fails. This commit skips tests when triggered from another pipeline (unified release), and allows running tests when triggered by PR creation by picking up a suitable `MANIFEST_URL`. DRA publishing is skipped unless we are triggered from the unified release. Closes elastic/ingest-dev#2895
When will this be GA with supporting documentation? Says it's beta. |
@mbudge we are looking at 8.14 for GA and docs will be ready then. |
@amitkanfer , @nimarezainia I've opened the issue above for the docs. Amit, I'd really appreciate if you, or anyone, can provide the install steps and any other details users will need. Also, are there any UI changes planned? Thanks! |
agent install
from the target folder)agent install
and fail execution if code is different than 0agent install
is executed successfullyTo test, run from a command prompt with administrator permissions:
Another option, with logs collection:
Few notes:
INSTALLARGS
are not provided, the MSI will copy the files to a temp folder and finish.INSTALLARGS
are provided, the MSI will copy the files to a temp folder and then run theelastic-agent install
command with the provided args. If the install flow is successful, the temp folder is deleted.INSTALLARGS
are provided but theelastic-agent install
command fails - the top folder is NOT deleted to allow further troubleshooting.elatic-agent uninstall
on a "best effort" basis and will always finish successfully (if not, a 3rd party tool will be needed to remove the windows service)elastic-agent install
command fails (for any reason), the MSI will rollback all changes.