Add setting to manage policy templates behavior in Kibana by mrodm · Pull Request #825 · elastic/package-spec

mrodm · 2024-10-24T10:46:27Z

What does this PR do?

Adds a new setting policy_templates_behavior to manage how the policy templates / tiles are shown to the user in Kibana.

Values that admit this new field:

combined_policy
individual_policies
all

Why is it important?

There are some integrations that do not require to show a tile for the integration itself, or vice-versa, there could be integrations that it is not desired to show each of the policy templates (child policy templates) defined as tiles, just the one referring to the integration itself (parent tile)

Checklist

I have added test packages to test/packages that prove my change is effective.
I have added an entry in spec/changelog.yml.

Related issues

Closes [Change Proposal] Add flag to hide "parent tile" in integrations UI for integrations with multiple policy templates #802

mrodm · 2024-10-24T14:58:30Z

spec/integration/manifest.spec.yml

Added this new setting just for integrations.

Tried to look into kibana's code here: https://github.com/elastic/kibana/blob/e5b0b8108b392dae070b87175cf2d43522576c4d/x-pack/plugins/fleet/public/applications/integrations/sections/epm/screens/home/hooks/use_available_packages.tsx#L82

IIUC Kibana just shows different tiles in case of integrations packages. Input packages would just show one tile. Is my understanding correct?

Or, should it be added also for input packages ?

@jen-huang @kpollich

I wonder why we support multiple policy templates in input packages 🤔 What could be a use case? I think we don't have any input package with more than one. Maybe we should change the spec to be more explicit about this.

Some previous discussion about this here: https://github.com/elastic/package-spec/pull/325/files#r860573848

At least, currently all input packages defined in the integrations repository have just one policy template.

Forcing input packages to have just one policy template could be done by adding maxItems setting (it could be done in this PR or in a separate PR):

--- spec/input/manifest.spec.yml +++ spec/input/manifest.spec.yml @@ -38,6 +38,7 @@ spec: policy_templates: description: List of policy templates offered by this package. type: array + maxItems: 1 items: type: object additionalProperties: false

What could be a use case?

I was thinking for instance in the "Custom logs" input package, would that make sense to add a new policy template there to read logs from another source? or would it be better to create a new input package?

IIUC Kibana just shows different tiles in case of integrations packages. Input packages would just show one tile. Is my understanding correct?

Kibana does not enforce the distinction between integration and input type packages when it comes to displaying the tiles, it only reads the number of policy_templates

I was thinking for instance in the "Custom logs" input package, would that make sense to add a new policy template there to read logs from another source? or would it be better to create a new input package?

Yes, in this case it would be better to create another input package.

Maybe a use case could be to have an input that collects from the same source, but with a different method. But in this case maybe it would be better to do #744.

I would be more leaned towards limiting input packages to a single policy.

As it is not clear whether or not input packages should have a limitation in the number of policy templates, I would suggest not doing that for now.

mrodm · 2024-10-24T14:59:30Z

spec/integration/manifest.spec.yml

+    # requires a conditional JSON schema to update the value depending
+    # on the policy_templates length
+    policy_templates_behavior:
+      description: >
+        Behavior to manage the policy templates (policy_templates field) defined that must be available in Kibana as tiles.
+        This is just applicable for those packages that define more than one policy template. By default for these packages, Kibana
+        shows all the policy templates defined in the manifest separately plus another one referring to the
+        whole integration (that contains all the policy templates definitions) available to the user.
+
+        If the `integration_package_only` option is selected, then just one policy template for the whole integration containing all policy
+        templates will be available in Kibana. If the `policy_templates_only` option is selected, then just the policy templates defined
+        in the manifest will be available in Kibana without the specific policy template for the whole integration. If the `default` option
+        is selected, then Kibana keeps the same behavior described above.
+      type: string


Not sure about the wording or even the naming for the options here.
WDYT ? Any other suggestions?

Proposed rewording in the comment above.

jsoriano

Codewise LGTM, added some suggestions about wording and the possible values for the setting.

jsoriano · 2024-10-24T18:12:08Z

spec/integration/manifest.spec.yml

+        Behavior to manage the policy templates (policy_templates field) defined that must be available in Kibana as tiles.
+        This is just applicable for those packages that define more than one policy template. By default for these packages, Kibana
+        shows all the policy templates defined in the manifest separately plus another one referring to the
+        whole integration (that contains all the policy templates definitions) available to the user.
+
+        If the `integration_package_only` option is selected, then just one policy template for the whole integration containing all policy
+        templates will be available in Kibana. If the `policy_templates_only` option is selected, then just the policy templates defined
+        in the manifest will be available in Kibana without the specific policy template for the whole integration. If the `default` option
+        is selected, then Kibana keeps the same behavior described above.


Simplified wording, removing references to the visual representation. Also proposing these three values:

combined_policy: to indicate that there is a single policy template that combines them all.

individual_policies: to indicate that policies are available individually, without a combined policy.

all: the default value, where both the combined policy and the individual policies are available.

Suggested change

Behavior to manage the policy templates (policy_templates field) defined that must be available in Kibana as tiles.

This is just applicable for those packages that define more than one policy template. By default for these packages, Kibana

shows all the policy templates defined in the manifest separately plus another one referring to the

whole integration (that contains all the policy templates definitions) available to the user.

If the `integration_package_only` option is selected, then just one policy template for the whole integration containing all policy

templates will be available in Kibana. If the `policy_templates_only` option is selected, then just the policy templates defined

in the manifest will be available in Kibana without the specific policy template for the whole integration. If the `default` option

is selected, then Kibana keeps the same behavior described above.

Expected behavior when there are more than one policy template defined.

When set to `combined_policy`, a single policy template is available, that

combines all the defined templates. When set to `individual_policies`, all

policies are individually available, but there is no combined policy.

The default value is `all`, where the combined policy template is available

along with the individual policies.

I like this proposal that does not mention any reference to tiles in Kibana.
And it also looks easier to understand what each option is aimed for.

Thanks!

I'll do the required changes.

Added in b2ff189

jsoriano · 2024-10-24T18:12:32Z

spec/integration/manifest.spec.yml

+    # requires a conditional JSON schema to update the value depending
+    # on the policy_templates length
+    policy_templates_behavior:
+      description: >
+        Behavior to manage the policy templates (policy_templates field) defined that must be available in Kibana as tiles.
+        This is just applicable for those packages that define more than one policy template. By default for these packages, Kibana
+        shows all the policy templates defined in the manifest separately plus another one referring to the
+        whole integration (that contains all the policy templates definitions) available to the user.
+
+        If the `integration_package_only` option is selected, then just one policy template for the whole integration containing all policy
+        templates will be available in Kibana. If the `policy_templates_only` option is selected, then just the policy templates defined
+        in the manifest will be available in Kibana without the specific policy template for the whole integration. If the `default` option
+        is selected, then Kibana keeps the same behavior described above.
+      type: string


Proposed rewording in the comment above.

spec/integration/manifest.spec.yml

jsoriano · 2024-10-24T18:14:11Z

spec/integration/manifest.spec.yml

+              - integration_package_only
+              - policy_templates_only
+              - default


Options proposed above.

Suggested change

- integration_package_only

- policy_templates_only

- default

- combined_policy

- individual_policies

- all

jsoriano · 2024-10-24T18:23:58Z

spec/integration/manifest.spec.yml

I wonder why we support multiple policy templates in input packages 🤔 What could be a use case? I think we don't have any input package with more than one. Maybe we should change the spec to be more explicit about this.

Some previous discussion about this here: https://github.com/elastic/package-spec/pull/325/files#r860573848

elasticmachine · 2024-10-25T11:05:24Z

💚 Build Succeeded

Buildkite Build
Commit: b2ff189

History

💚 Build #876 succeeded 8a1f8e9
💚 Build #875 succeeded 0b8c6e2
💔 Build #874 failed c4a5290
💚 Build #873 succeeded dca0eef
💚 Build #872 succeeded f84211b
💚 Build #871 succeeded c0d1165

cc @mrodm

Add setting to manage policy templates behaviour in Kibana

d902507

mrodm self-assigned this Oct 24, 2024

mrodm added 2 commits October 24, 2024 13:00

Add changelog entry

c0d1165

Update description changelog entry

dca0eef

mrodm force-pushed the add_policy_tiles_behaviour branch from f84211b to dca0eef Compare October 24, 2024 11:33

Update description and naming

0b8c6e2

mrodm force-pushed the add_policy_tiles_behaviour branch from c4a5290 to 0b8c6e2 Compare October 24, 2024 13:42

mrodm added 2 commits October 24, 2024 15:45

Add test package

3dc83de

Fix typo

8a1f8e9

mrodm commented Oct 24, 2024

View reviewed changes

mrodm marked this pull request as ready for review October 24, 2024 15:07

mrodm requested a review from a team as a code owner October 24, 2024 15:07

jsoriano reviewed Oct 24, 2024

View reviewed changes

Update description and values for policy_templates_behavior

b2ff189

jsoriano approved these changes Oct 27, 2024

View reviewed changes

mrodm mentioned this pull request Oct 28, 2024

Expose policy_template_behavior in search and package endpoints elastic/package-registry#1243

Closed

mrodm changed the title ~~Add setting to manage policy templates behaviour in Kibana~~ Add setting to manage policy templates behavior in Kibana Oct 28, 2024

mrodm merged commit cc52823 into elastic:main Oct 28, 2024

mrodm deleted the add_policy_tiles_behaviour branch October 28, 2024 14:50

Conversation

mrodm commented Oct 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Why is it important?

Checklist

Related issues

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mrodm Oct 24, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsoriano left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Oct 25, 2024

💚 Build Succeeded

History

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mrodm commented Oct 24, 2024 •

edited

Loading

mrodm Oct 24, 2024 •

edited

Loading