Skip to content
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

Open
wants to merge 39 commits into
base: main
Choose a base branch
from

Conversation

michalpristas
Copy link
Contributor

Ready for review but DO NOT MERGE before spec files of dependencies are updated in other repos

What does this PR do?

This PR changes logic of installation and ugprades in following manner.

Default install installs only:

  • agentbeat
  • endpoint-security
  • pf-host-agent

additional flag is added that includes components above and:

  • cloudbeat
  • apm-server
  • fleet-server
  • pf-elastic-symbolizer
  • pf-elastic-collector

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 with install or content of .flavor in case of upgrade) 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

component_files:
 - file1
 - dir1/*

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

  • I have read and understood the pull request guidelines of this project.
  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation TODO: @michalpristas
  • I have made corresponding change to the default configuration files
  • I have added tests that prove my fix is effective or that my feature works
  • I have added an entry in ./changelog/fragments using the changelog tool
  • I have added an integration test or an E2E test

How 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 present

Scenario 4 - upgrade from stale version

Upgrade from previous version to this one and check ALL components are present

@michalpristas michalpristas added enhancement New feature or request backport-skip labels Jan 17, 2025
@michalpristas michalpristas self-assigned this Jan 17, 2025
@michalpristas michalpristas requested a review from a team as a code owner January 17, 2025 16:13
@cmacknz
Copy link
Member

cmacknz commented Jan 17, 2025

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
Copy link
Member

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right :-)

@@ -0,0 +1,13 @@
basic:
Copy link
Member

@cmacknz cmacknz Jan 17, 2025

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?

Copy link
Contributor Author

@michalpristas michalpristas Jan 20, 2025

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

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

@michalpristas michalpristas Jan 22, 2025

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

@michalpristas
Copy link
Contributor Author

Spec file updated for agentbeat here: elastic/beats#42348

@michalpristas
Copy link
Contributor Author

Fixing windows

@swiatekm swiatekm added the Team:Elastic-Agent-Control-Plane Label for the Agent Control Plane team label Jan 21, 2025
@elasticmachine
Copy link
Contributor

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

}

// SpecsForFlavor returns spec files associated with specific flavor
func SpecsForFlavor(flavor FlavorDefinition) ([]string, error) {
Copy link
Contributor

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?

Copy link
Contributor Author

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)
Copy link
Contributor

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?

Copy link
Contributor Author

@michalpristas michalpristas Jan 23, 2025

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 🤦

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-skip enhancement New feature or request Team:Elastic-Agent-Control-Plane Label for the Agent Control Plane team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants