You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, last year we introduced a field, policy_templates.[0].multiple: boolean, that lets Kibana know whether a package can be configured for an agent policy more than once or not: elastic/package-registry#350
This flag is currently in effect for endpoint (that is, Endpoint package can only be added once to an agent policy) and, AFAIK, no others. Now that packages can have multiple policy_templates (#137), I'd like to discuss whether this flag still makes sense at the policy template level, or if we should consider moving it to the package level.
My preference is to move it to the package level, semantically that makes more sense to me with the original intention of this field, but I realize that this might change now with packages exporting multiple integrations. Do we foresee a use case where we will want to apply this restriction at the policy template/integration level?
The text was updated successfully, but these errors were encountered:
Makes sense on the package level. If we later need it per integration, we can introduce it there too. At the moment my assumption is, if it is set on the package level, it applies to all templates.
Hi, last year we introduced a field,
policy_templates.[0].multiple: boolean
, that lets Kibana know whether a package can be configured for an agent policy more than once or not: elastic/package-registry#350This flag is currently in effect for
endpoint
(that is, Endpoint package can only be added once to an agent policy) and, AFAIK, no others. Now that packages can have multiplepolicy_templates
(#137), I'd like to discuss whether this flag still makes sense at the policy template level, or if we should consider moving it to the package level.My preference is to move it to the package level, semantically that makes more sense to me with the original intention of this field, but I realize that this might change now with packages exporting multiple integrations. Do we foresee a use case where we will want to apply this restriction at the policy template/integration level?
The text was updated successfully, but these errors were encountered: