[Fleet] Integration policy upgrades are not space aware

[kpollich]

If integration policies for a given integration exist in two spaces, Fleet will not apply an upgrade to both spaces, only the space in which the upgrade request was made. This results in "orphaned" integration policies that cannot be upgraded to the latest version of an integration

To reproduce

From: elastic/integrations#3434

Using the Palo Alto Networks Logs integration as an example.

If I have 2 x integration instances, both on v1.6.0 and v2.1.0 has just been released.

The first integration is in space ID "space1" and the second integration is in space ID "space2"

If I use the upgrade function in Kibana/Fleet webUI, it will upgrade the first instance of a deployed integration to v2.1.0, in "space1"

But it will leave the integration in "space2" on v1.6.0 and it will not upgrade it.

At this point there are no options in the webUI to manually upgrade the v1.6.0 integration that has been left hanging, regardless of whether I attempt this from the "default" space, or "space1" or "space2".

There is no documentation available on how to correct this, and no obvious API endpoint to trigger upgrade of the integration.

The only option seems to be to delete the v1.6.0 integration and recreate it.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[kpollich]

I'm actually having some trouble reproducing this one e.g.

Screen.Recording.2023-12-08.at.11.12.02.AM.mov

What I tried

1. Install Nginx 1.16.0 in any space
2. Create an Nginx integration policy in Second space
3. Create an Nginx integration policy in Default space
4. Navigate to integration settings and select Update + Upgrade integration policies
5. Observe integration policies are upgraded to latest version, regardless of their space (might need a page refresh as the bulk update can take a few seconds)

[mbudge]

Hi

This is affecting our deployment.

This is the latest Azure Logs integration with an upgrade option.

Contact support and use ticket #01547752 if you want to collect diagnostics from our deployment.

Thanks

[criamico]

I tried to reproduce it on current main and couldn't reproduce it. I also tried with 8.12.0 production and there doesn't happen as well:

Screen.Recording.2024-04-09.at.12.31.21.mov

@amolnater-qasource could you help with this? It would be good to know if you could reproduce it.

[amolnater-qasource]

Hi @criamico

We have attempted to reproduce this issue on 8.11.0 production and 8.13.0-SNAPSHOT, however, we are not able to reproduce this issue at our end.

Steps Followed:

1. Created space1 and installed Apache-1.4.1 version on it.
2. Created space2 and installed Apache-1.5.0 version on it.
3. Created space3 and installed Apache-1.5.0 version on it.
4. Upgraded the integration and Integration policies.
5. Observe all integrations upgraded successfully.

Screen Recording:
8.11.0:

Apache.HTTP.Server.-.Integrations.-.Elastic.-.Google.Chrome.2024-04-09.19-43-20.mp4

8.14.0-SNAPSHOT:

Apache.HTTP.Server.-.Integrations.-.Elastic.-.Google.Chrome.2024-04-10.13-45-03.mp4

Please let us know if we are missing anything here.
Thanks!

[criamico]

Thank you very much @amolnater-qasource!

This issue stems from elastic/integrations#3434, which was opened more than a year ago and the system where this was happening was on 8.2.0 (see this comment).

Based on the fact that none of us could reproduce it in systems > 8.12.x, this issue was already resolved in recent releases. I'll close it as not reproducible.