-
Notifications
You must be signed in to change notification settings - Fork 108
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
Add Fleet package policies and epm support #454
Conversation
taylor-swanson
commented
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
- 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
1309198
to
df2cf33
Compare
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.
Couple of usability questions on the package resource.
return *hash | ||
} | ||
|
||
func ResourcePackage() *schema.Resource { |
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 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?
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.
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.
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.
Wdyt about timing here? I'm inclined to merge this and have the data sources in a follow up?
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.
I would agree as well. I can write a follow up issue for the package data source. (issue here: #468)
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.
LGTM 🚀
@taylor-swanson @tobio , we should definitely have a package data resource as well |
hey @taylor-swanson , i'm looking into the UX of the new resources, I might want us to change their name / terminology a bit. |
@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.
|
I agree @taylor-swanson that it's not best to wait here. the fact that the UI & API use different terminologies is a separate issue (mainly for the fleet team) |
@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 ( |
i'm no fleet PM , so I don't have full context over these unfortunately. Maybe @nimarezainia can comment. our UI is really big on using the term "integration" in that space. |
Link to refactoring issue: #475 |
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. |