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

[Fleet] Make default integration install explicit #121628

Merged
merged 119 commits into from
Feb 1, 2022

Conversation

juliaElastic
Copy link
Contributor

@juliaElastic juliaElastic commented Dec 20, 2021

Summary

Making default integration install explicit
Fixes #108456

Manual test cases:

Initial kibana startup:

  1. Navigate to Fleet, verify that /setup has finished (should happen quickly)
  2. verify that no default policies or integrations exist (except for cloud fleet server policy, see below)

Add integration flow:

  1. go to Integrations / Apache / Add integration
  2. verify that UI offers to create a new policy
  3. when submitting, verify that agent policy is being created with system integration, and elastic agent integration is installed as well (first time takes long, about 2 mins)
  4. try again to add integration, should see now the tabbed view New hosts / Existing hosts
  5. test both paths: create new policy and use existing policy

Fleet Server policy flow on-prem:

  1. Go to Fleet tab
  2. verify that in fleet server instructions there is a create button to add fleet server policy
  3. click create button
  4. verify that fleet server policy is created, UI should show a dropdown instead of create button now
  5. verify that fleet server policy has a fleet server integration
  6. verify policy has system integration if system monitoring checkbox was left checked as default
  7. elastic agent integration should be installed as well if monitoring was enabled on the policy
  8. generated fleet server command should include the newly created policy id

Add agent flow (supposing Fleet Server is installed):

  1. go to Fleet / Agents / Add agent
  2. on both Enroll in Fleet / Run standalone tab, see option to create Agent policy (when no policy exists, except fleet server policy)
  3. click on Create button, verify that default policy is created with system integration, and elastic agent integration is installed
  4. verify that generated enroll command (or policy config yml) includes newly created policy id
  5. verify that now agent policy dropdown shows up with pre-selected agent policy
  6. create one more agent policy, and verify that dropdown has no selection by default

Cloud (depends on change in cloud stackpack)

  1. Verify that Elastic Cloud agent policy is created by default with fleet server integration
  2. non fleet server flows are the same as on prem (no default policy, system, elastic agent integration initially)

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@@ -1382,7 +1384,9 @@ export async function incrementPackageName(
? packagePolicyData.items
.filter((ds) => Boolean(ds.name.match(pkgPoliciesNamePattern)))
.map((ds) => parseInt(ds.name.match(pkgPoliciesNamePattern)![1], 10))
.sort()
.sort((a: number, b: number) => {
return a - b;
Copy link
Contributor Author

@juliaElastic juliaElastic Dec 20, 2021

Choose a reason for hiding this comment

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

this fixes a bug, default sorting doesn't work correctly on numbers, e.g. "1, 10, 9" - this was giving an error when reaching system-10 name in integrations, and the logic returned system-10 again as incremented name
EDIT: changed this to find max number, no need to sort.

try {
if (withSysMonitoring) {
Copy link
Contributor Author

@juliaElastic juliaElastic Dec 20, 2021

Choose a reason for hiding this comment

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

potential problem:
installing these packages might take long (about 2 mins) which causes network timeout. this results in an error, and fails next agent policy creation request. Could this be improved by bundled default packages?

EDIT: during latest testing, the install took much less time (25s), will keep an eye on this

Copy link
Contributor

Choose a reason for hiding this comment

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

Bundled default packages aren't going to make much of a difference here based on my investigations in #110500. We'll likely need elastic/elasticsearch#77505 to fix this.

@juliaElastic juliaElastic self-assigned this Dec 20, 2021
defaultMessage="Collecting monitoring logs and metrics will also create an {agent} integration. Monitoring data will be written to the default namespace specified above."
values={{
agent: (
<AgentPolicyPackageBadge pkgName={'elastic_agent'} pkgTitle={'Elastic Agent'} />
Copy link
Contributor Author

Choose a reason for hiding this comment

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

currently displaying a generic badge. in order to display the package's real badge, I would need to know the latest version number, which seems overkill

@juliaElastic juliaElastic changed the title [Fleet] Draft before I go on holiday [Fleet] Make default integration install explicit Dec 29, 2021
@juliaElastic juliaElastic marked this pull request as ready for review December 29, 2021 15:47
@juliaElastic juliaElastic requested a review from a team as a code owner December 29, 2021 15:47
@juliaElastic juliaElastic added release_note:enhancement v8.1.0 Team:Fleet Team label for Observability Data Collection Fleet team labels Dec 29, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/fleet (Team:Fleet)

@@ -546,6 +545,7 @@ export async function createInstallation(options: {
? true
: undefined;

// TODO cleanup removable flag and isUnremovablePackage function
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@mostlyjason what about the endpoint package, can it be removable as well?

Copy link
Contributor

@mostlyjason mostlyjason Jan 4, 2022

Choose a reason for hiding this comment

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

I don't see why not. Adding @kevinlog for confirmation. For context, we are trying to remove the concept of unremovable packages since they will no longer be installed by default. This would also allow users to reinstall the package if there is a problem. Can you think of any reason users shouldn't be able to remove endpoint, provided they removed all integration policies first?

Copy link
Contributor

Choose a reason for hiding this comment

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

@mostlyjason @juliaElastic I think it's OK to make the endpoint package removable especially for reasons you stated such as allowing users to uninstall and reinstall if there is a problem.

If the user removed all integration policies first then all of their Endpoints would be uninstalled. I would just like to test what would happen with their data if they uninstalled the package. This would imply that we remove mappings, etc. If we're going to make the Endpoint package removable, I'd like to open up a separate ticket/PR if possible where we can test a few different scenarios before merging/releasing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@kevinlog thanks for your response, are you comfortable with testing this soon as we are planning to merge this feature for 8.1? If not, should we keep endpoint package unremovable for now?
cc @joshdover

Copy link
Contributor

Choose a reason for hiding this comment

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

When we uninstall packages, I don't believe any existing data should be affected, though the next rollover of the data stream would cause the write index to pickup the generic mappings for logs-*-* and metrics-*-* rather than the endpoint-specific ones. This would only affect new data that is ingested which shouldn't be happening once a package is uninstalled anyways.

// NOTE: we ignore failures in attempting to create package policy, since agent policy might have been created
// successfully
withSysMonitoring
// TODO case when both isDefaultFleetServer and withSysMonitoring is true
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@joshdover is it a valid use case to add system monitoring to default fleet server policy? currently default fleet server policy only includes fleet server integration

Copy link
Contributor

Choose a reason for hiding this comment

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

I think that is probably a valid use case for preconfiguration / kibana.yml, but isn't possible via the UI today.

Is there a major hurdle in supporting this case?

Copy link
Contributor

Choose a reason for hiding this comment

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

I thought we are removing the default fleet server policy? I didn't read the code, so am I missing context behind this question?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After reading the comments here and in design doc, it seems that we can completely get rid of the flag to mark a policy default (is_default and is_default_fleet_server flags in code). I wasn't aware of this before, probably because on the designs the policies were still called "Default policy" and "Default Fleet Server policy".

@joshdover I think we can support system integration with fleet server policy, I didn't want to start implementing it until confirmed.

Copy link
Contributor

Choose a reason for hiding this comment

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

Makes sense to me. If we're going to drop the concept of default completely, we should remove that field from our Saved Object mappings and add a Saved Object migration that deletes this field.

@juliaElastic
Copy link
Contributor Author

@elasticmachine merge upstream

Copy link
Member

@nchaulet nchaulet left a comment

Choose a reason for hiding this comment

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

One last comment otherwise 🚀

@juliaElastic
Copy link
Contributor Author

@elasticmachine merge upstream

@juliaElastic
Copy link
Contributor Author

@elasticmachine merge upstream

@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
fleet 557 565 +8

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
fleet 1169 1142 -27

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
fleet 648.4KB 659.6KB +11.2KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id before after diff
fleet 112.8KB 109.2KB -3.6KB
Unknown metric groups

API count

id before after diff
fleet 1285 1258 -27

ESLint disabled line counts

id before after diff
fleet 40 41 +1

Total ESLint disabled count

id before after diff
fleet 48 49 +1

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @juliaElastic

@juliaElastic juliaElastic merged commit b4b3285 into elastic:main Feb 1, 2022
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Feb 1, 2022
@juliaElastic juliaElastic deleted the feat-remove-default-pkgs branch February 1, 2022 11:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:enhancement Team:Fleet Team label for Observability Data Collection Fleet team v8.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Fleet] Remove default integrations