-
Notifications
You must be signed in to change notification settings - Fork 148
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
Changes to binary distribution #6542
base: main
Are you sure you want to change the base?
Conversation
You will need to add integration tests to make sure upgrades respect the flavor or lack of one. For the existing upgrade tests you could probably add a check to ensure every component exists in both versions easily. For flavors you'll need new tests for those case most likely. |
unpackRes, err := u.unpack(version, archivePath, paths.Data()) | ||
// default to extended flavor to avoid breaking behavior | ||
|
||
// no default flavor, keep everything in case flavor is not |
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.
keep everything in case flavor is not
Is not what?
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.
right :-)
internal/pkg/agent/install/.flavors
Outdated
@@ -0,0 +1,13 @@ | |||
basic: |
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.
What value are we getting out of making this a file and having to deal with opening+parsing it vs just embedded this list into the agent as code?
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.
upgrade scenario.
if you want to change content of flavor in between version you need somehow know what should be present in a new version. upgrade code is executed from stale version not the new one so embedded content would reflect state of things of version-1. if you add a new component or change layout of existing one in a new version it would be stripped and break
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.
OK, so if we add a new binary in the future we to communicate to the old agent what it needs to extract?
This feels very similar to what the manifest does with metadata to let us pull determine the extraction path.
metadata, err := getPackageMetadataFromZipReader(r, fileNamePrefix) |
Can we make the definition of the flavors part of the manifest file and then pull the list out before extracting the rest of the zip/tar? That would make this work in an already proven way and make the flavours a property of a specific agent version which is easy to reason about.
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 should be ok to merge if you're ok with mixing concerns. the only difference is that manifest is in versioned home after installation, but it should not matter in this case.
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.
Keeping it in versioned home is a benefit IMO so that it is a property of an individual agent version. I'd rather not introduce something new for this if we can handle this with an existing mechanism.
CC @pchila for opinions on use of the manifest file for defining the flavors per agent version since he implemented it originally.
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.
updated to use manifest in a meanwhile,
if @pchila objects i can revert. but i agree this is cleaner and removes one traversal through archive before unpacking during upgrade
Spec file updated for agentbeat here: elastic/beats#42348 |
Fixing windows |
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
Quality Gate passedIssues Measures |
} | ||
|
||
// SpecsForFlavor returns spec files associated with specific flavor | ||
func SpecsForFlavor(flavor FlavorDefinition) ([]string, error) { |
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.
This function always returns nil
as error, is the error needed?
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.
leftover from previous design, thanks for pointing it out
|
||
// fix versionedHome | ||
versionedHome = strings.ReplaceAll(versionedHome, "\\", "/") | ||
log.Errorf("using %q", versionedHome) |
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 this needed? It's not an error, right?
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 not an error, this is because zip on windows are using unix paths 🤦
Co-authored-by: Andrzej Stencel <[email protected]>
…agent into feat/binary-distr
What does this PR do?
This PR changes logic of installation and ugprades in following manner.
Default
install
installs only:additional flag is added that includes components above and:
Upon installation user choice is backed into
.flavor
file.Part of elastic agent package is
.flavors
file defining flavor for this particular version.Upon upgrade or install
.flavors
is read and only components specified in desired flavor (using flag withinstall
or content of.flavor
in case ofupgrade
) are copied.In case of any issues with parsing any of the above files we fall back to previous way and copy everything.
Each components needs to define files in addition to binary, spec and config in a form
in their spec file.
During upgrade target version spec file is parsed. not the current installation.
Why is it important?
Reducing space on disk by omitting not needed components.
Checklist
./changelog/fragments
using the changelog toolHow to test this PR locally
Scenario 1 and 2 (installation)
Build package and install without and with flag
--install-server
check components present
Scenario 3 - upgrade to future version
Prepare same agent but with different commit hash (do small change and commit locally)
Run
upgrade 9.0.0-SNAPSHOT --source-uri="file://....zip" --skip-verify
and check only desired components are presentScenario 4 - upgrade from stale version
Upgrade from previous version to this one and check ALL components are present