Skip to content

Add Fleet package policies and epm support #454

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

Merged
merged 6 commits into from
Nov 2, 2023

Conversation

taylor-swanson
Copy link
Contributor

  • Add Fleet EPM (Elastic Package Manager) support, currently only provides for installing and uninstalling packages.
  • Add Fleet Package Policy support.
  • Add acceptance tests
  • Add documentation

@taylor-swanson taylor-swanson self-assigned this Oct 25, 2023
- Add Fleet EPM (Elastic Package Manager) support, currently only provides
for installing and uninstalling packages.
- Add Fleet Package Policy support.
- Add acceptance tests
- Add documentation
@taylor-swanson taylor-swanson force-pushed the feature/fleet-package-policy branch from 1309198 to df2cf33 Compare October 26, 2023 20:58
@taylor-swanson taylor-swanson marked this pull request as ready for review October 30, 2023 13:14
Copy link
Member

@tobio tobio left a comment

Choose a reason for hiding this comment

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

Couple of usability questions on the package resource.

return *hash
}

func ResourcePackage() *schema.Resource {
Copy link
Member

Choose a reason for hiding this comment

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

It feels like this resource may be difficult to use without a data source to list the available packages. I'm thinking about how I'd use this right now, where I'd be flicking between the Kibana UI and TF code, but what happens when the package in the repo is upgraded to a new version?

Do you have plans to add that data source in a follow up? If not could we?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These are great points. I've been trying to think of usability concerns (and there are a few when dealing with packages and package policies).

We didn't have explicit plans for a package data source, but we can definitely look into doing that. At a quick glance, the "list packages" endpoint for EPM seems to list the latest package versions only (it doesn't give you a full manifest of what's available in the package registry), as far as I can tell. This should be fine, though, since we really only care about the latest package version.

Copy link
Member

Choose a reason for hiding this comment

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

Wdyt about timing here? I'm inclined to merge this and have the data sources in a follow up?

Copy link
Contributor Author

@taylor-swanson taylor-swanson Nov 1, 2023

Choose a reason for hiding this comment

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

I would agree as well. I can write a follow up issue for the package data source. (issue here: #468)

Copy link
Member

@tobio tobio left a comment

Choose a reason for hiding this comment

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

LGTM 🚀

@Kushmaro
Copy link
Contributor

Kushmaro commented Nov 3, 2023

@taylor-swanson @tobio , we should definitely have a package data resource as well

@taylor-swanson
Copy link
Contributor Author

@tobio @Kushmaro, see #469 for the package data source PR.

@taylor-swanson taylor-swanson deleted the feature/fleet-package-policy branch November 3, 2023 13:17
@Kushmaro
Copy link
Contributor

Kushmaro commented Nov 8, 2023

hey @taylor-swanson , i'm looking into the UX of the new resources, I might want us to change their name / terminology a bit.
the Fleet UI doesn't mention or discusses at all "Package policies" rather, "integrations". That is what our users know... our UX / wording should be consistent where we can have them so

@taylor-swanson
Copy link
Contributor Author

@Kushmaro, I chose the name based on the terminology used in the API (which refers to integration policies as package policies). We can certainly update documentation to mention/use the term integrations policies instead.

Do you think we should rename the resource as well? If we want to do that, now would be the time. The longer we wait, the more users this would impact, since it would be a breaking change.

elasticstack_fleet_package_policy -> elasticstack_fleet_integration_policy

@Kushmaro
Copy link
Contributor

Kushmaro commented Nov 9, 2023

I agree @taylor-swanson that it's not best to wait here.
I know the API refers to package policies, but that kind of excludes the actual user experience. when users go to the fleet management UI , they have no concept of "package policies"

the fact that the UI & API use different terminologies is a separate issue (mainly for the fleet team)
but i'd want us to align the Terraform client experience towards what the user will natively understand from the UI / Product.

@taylor-swanson
Copy link
Contributor Author

@Kushmaro, that makes sense. I'll write up an issue to rename the package policy resource and update documentation. Do you have any thoughts about the package resource and data source (elasticstack_fleet_package)? There are a few things that identify them as "packages" (Elastic Package Registry, Elastic Package Manager, etc), but the Kibana UI and the main docs site seems to refer to them as "integrations" at this point. Although, I thought I've heard that not every package is an integration? (I could be wrong about that, though).

@Kushmaro
Copy link
Contributor

Kushmaro commented Nov 9, 2023

i'm no fleet PM , so I don't have full context over these unfortunately. Maybe @nimarezainia can comment.
I do think that for the data resource, we should refer as "fleet_integration"

our UI is really big on using the term "integration" in that space.

@taylor-swanson
Copy link
Contributor Author

Link to refactoring issue: #475

@nimarezainia
Copy link

agree with both @taylor-swanson and @Kushmaro - average user of the platform would be more familiar with the concept of an "integration" rather than packages which are perhaps more developer focuses. Thanks for making all these changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants