[Arista NG Firewall] Add Dashboards to Beta Integration

[MakoWish]

Type of change

• Enhancement

What does this PR do?

This PR is to add a set of dashboards to the Arista NG Firewall integration

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have incremented the version in my package's mainfest.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

• Test import into elastic-package

Related issues

• Closes [Arista NG Firewall] Add Dashboards to Beta Integration #6943

Screenshots

Overview:

Admin Login:

Session Stats:

Web Filter:

Intrusion Prevention:

System Stats:

Interface Stats:

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-12-12T00:38:58.586+0000

• Duration: 19 min 45 sec

Test stats 🧪

Test	Results
Failed	0
Passed	31
Skipped	0
Total	31

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[efd6]

We are moving visualisations to Lens. There are a number of non-Lens visualisations here. Can you replace them with Lens equivalents or find an alternative approach?

[MakoWish]

I would love to, but Lens is still seriously lacking and not quite ready IMO. There are a few things I like about Lens, but too many areas it just cannot replace other visualizations.

One of the biggest downfalls is the inability to export from tables. Another big one for us is the inability to link to Saved Searches. The Markdown capability in TSVB's also cannot be replicated any other way.

We have spoken with our CSM's a few times about this, but we haven't seen any traction on getting much changed about Lens yet.

[P1llus]

@MakoWish @efd6 We can speak about this a bit internally, while we can also take a look to see if there are any possibilities we can use from Lens today as well, I believe we have a few options here.

Just to mention though, so it's not misunderstood, the dashboards looks great! And we certainly would like to use them if possible!

The issue is that specifically for dashboards that are embedded to integrations, we have to use Lens for certain reasons, so it is currently restricted to Lens, Vega, Maps and the non-TSVB markdown.

I can see if we can do something with this next week, maybe we can discuss this on slack as well, see if we can find some workarounds here.

But the TLDR is that even though we would like to, we cannot merge new visualizations that add types that I did not mention above anymore.

[drewdaemon]

Hi @MakoWish !

I'm on the team that manages Lens and the other visualization editors. Here are a few responses to your comment.

One of the biggest downfalls is the inability to export from tables.

This feature is available for Lens panels (not just tables) as a context menu action.

Another big one for us is the inability to link to Saved Searches.

We don't have plans to support this in Lens. You should be able to achieve the same result by saving your filters and queries as saved queries from the search bar and applying them to any Lens visualizations you want to.

The Markdown capability in TSVB's also cannot be replicated any other way.

We are aware of this gap. We are currently discussing the specifics, but we plan to provide an alternative 👍

[MakoWish]

One of the biggest downfalls is the inability to export from tables.

This feature is available for Lens panels (not just tables) as a context menu action.

I was not aware of that! I did like the blatantly obvious "Toolbar" on the aggregation-based Data Table. I would have to educate my users on this option, but at least it is possible. Are there any plans to make that a little more obvious?

Another big one for us is the inability to link to Saved Searches.

We don't have plans to support this in Lens. You should be able to achieve the same result by saving your filters and queries as saved queries from the search bar and applying them to any Lens visualizations you want to.

Yeah, that is a huge one for us and one of the biggest reasons we are not using Lens more. We have quite a few dashboards where all visualizations are linked to Saved Searches, because the filtering done on the Saved Search is updated from time-to-time (list of specific servers, services, etc.). Having to update the filters on every single visualization is not feasible. With a Saved Search, there is one change, and all the dashboards and visualizations based on that Saved Search will automatically reflect that change.

Saving filters to the dashboard itself is not a good idea at all, because users frequently want to search for things on their own, or apply their own filters, and when they clear filters or the search bar, they lose the base filtering we need on the dashboard to begin with. We don't want standard users to have the ability to clear those filters at all.

The Markdown capability in TSVB's also cannot be replicated any other way.

We are aware of this gap. We are currently discussing the specifics, but we plan to provide an alternative 👍

That is good to hear!

Another one is the Aggregation based "Gauge" visualization. That one is also not doable with Lens. Any plans to include that?

I also noticed the original Metric in Lens was changed to Legacy Metric, and I don't like the new TP Metric, because there it is not customizable at all. Are there plans to update the new Metric in Lens to allow customizing? Either that, or just don't ever get rid of the "Legacy" one, because it is better IMO.

Final one I can think of for now is the inability to create hyperlinks in Lens. I prefer doing hyperlinks in Data Views, but since we cannot include custom Data Views with Integrations, TSVB is the only remaining option. Are there plans to allow creating hyperlinks in Lens visualizations?

[drewdaemon]

One of the biggest downfalls is the inability to export from tables.

This feature is available for Lens panels (not just tables) as a context menu action.

I was not aware of that! I did like the blatantly obvious "Toolbar" on the aggregation-based Data Table. I would have to educate my users on this option, but at least it is possible. Are there any plans to make that a little more obvious?

I hear you—one downside to transitioning to a new UX is having to learn where things got moved to :D . It is nice that it's so discoverable in TSVB.

But, it seems to me that the context menu is a reasonable place for all of these panel-level actions and we wanted to make it available for all visualization types, not just tables.

So, I'd say that the context menu pattern is the future and we don't have plans to move it. Feel free to raise an issue in the Kibana repo if you feel strongly about this, though.

another big one for us is the inability to link to Saved Searches.

We don't have plans to support this in Lens. You should be able to achieve the same result by saving your filters and queries as saved queries from the search bar and applying them to any Lens visualizations you want to.

Yeah, that is a huge one for us and one of the biggest reasons we are not using Lens more. We have quite a few dashboards where all visualizations are linked to Saved Searches, because the filtering done on the Saved Search is updated from time-to-time (list of specific servers, services, etc.). Having to update the filters on every single visualization is not feasible. With a Saved Search, there is one change, and all the dashboards and visualizations based on that Saved Search will automatically reflect that change.

Saving filters to the dashboard itself is not a good idea at all, because users frequently want to search for things on their own, or apply their own filters, and when they clear filters or the search bar, they lose the base filtering we need on the dashboard to begin with. We don't want standard users to have the ability to clear those filters at all.

Sorry, I seem to have failed to explain properly. We have a newer concept called "saved queries" that covers your use-case for Discover saved searches. Saved queries contain filters and query—everything you see in the search bar interface anywhere in Kibana.

If you have a KQL query in the search bar as well as a set of filters and you want to apply all that to several visualizations, you can do that. Then, whenever the saved query is updated, those updates will be reflected on all visualizations, the same way a saved search would be. Edit: this isn't true :(. elastic/kibana#82692 is the issue to track.

The only difference is that saved searches contain state for the Discover app in particular (the columns that are showing, etc) and can be embedded on dashboards. So, they remain relevant for the Discover app and for embedding the Discover table on dashboards, but saved queries can be seen as a replacement for the cases you have described.

See https://www.elastic.co/guide/en/kibana/master/save-load-delete-query.html for more info.

Another one is the Aggregation based "Gauge" visualization. That one is also not doable with Lens. Any plans to include that?

If you mean the arc gauges, this is the issue to track: elastic/kibana#155131. However, we see the new metric as a pretty clean stand-in for the TSVB arc gauges.

Here's an example from the System integration.

TSVB Gauge

Lens metric

There are also design updates in the works for the current Lens "gauge visualization" which should make it a lot more visually appealing (no timeline on this, though):

I also noticed the original Metric in Lens was changed to Legacy Metric, and I don't like the new TP Metric, because there it is not customizable at all. Are there plans to update the new Metric in Lens to allow customizing? Either that, or just don't ever get rid of the "Legacy" one, because it is better IMO.

Thanks for the feedback. You're not the first to raise these concerns so they're definitely on our radar.

The new metric was particularly designed to work well over a set of different dashboard panels, a case where the legacy metric suffers, partly because we allow for so much user customization. You can read more about our thinking here, though its a little out-of-date since we've already made improvements to the metric size, etc. For a more formal document, see here.

That said, we're listening to the feedback and plotting our path accordingly.

Final one I can think of for now is the inability to create hyperlinks in Lens. I prefer doing hyperlinks in Data Views, but since we cannot include custom Data Views with Integrations, TSVB is the only remaining option. Are there plans to allow creating hyperlinks in Lens visualizations?

I agree, this is a nice TSVB feature. You can accomplish a similar thing using dashboard drilldowns. Also, I don't see any reason why you can't include a custom data view with an integration as long as its scoped to a particular visualization (the docs call these "temporary data views", but that's a misnomer).

Anyway we always appreciate user feedback. Hopefully that addresses some of your most pressing concerns and points you to the right issues to track for progress, etc. Let me know if it makes sense and ping me if I can be of more help on the PR. Thanks for the contribution!

[MakoWish]

I will have to try the Saved Query idea. We do also embed Saved Searches at the bottom of dashboards quite frequently. More often than not, you cannot cleanly visualize all details of an event, so I always find it beneficial to have a Saved Search embedded at the bottom of the dashboard. This allows a user to view more details of an event that may not be illustrated in the visualizations. Will a Saved Query saved to a dashboard also filter an embedded Saved Search on that same dashboard? If so, that could be the answer to this issue.

The Lens Metric does not have quite the same effect as the Aggregation based Gauge or the TSVB Gauge. I just gave a +1 on that issue you linked. I would like to see that added.

Dashboard drilldowns are super clunky and not user friendly. Having a field set as a hyperlink in the Data View makes it clickable anywhere in Kibana. I use URL field types in Data Views quite extensively in our environment. It makes navigating Kibana feel more like an app instead of just a collection of dashboards. This is much cleaner and anybody that has ever used a computer recognizes underlined blue text as something clickable. @P1llus said they don't want to include custom Data Views with Integrations, "mostly because of that current issue with being bloated with dataviews." Not being able to set hyperlinks on visualizations (other than TSVB), and not being able to include Data Views with hyperlinks really restricts this navigability.

[ThomThomson]

@MakoWish In regards to the clunkiness of Dashboard Drilldowns being used as links, the Presentation team is working on a new feature which should help. Dashboard Links. Basically the idea is that you will be able to place a horizontal or vertical list of links anywhere on your Dashboard. Links will be able to navigate between Dashboards, and also to other arbitrary URLs.

[MakoWish]

Will those links be able to pass filters or queries? The use case for this Integration is that I want event.id to be a hyperlink to an "Event Details" sort of dashboard. In order for that to work, I need the link to pass either a filter or query in the URL. Given an event with event.id: 110701497342736 here is a sample hyperlink I am currently using on these dashboards:

../app/dashboards#/view/logs-arista_ngfw-3565dc44-1886-49aa-b8d3-523623e605dc?_a=(filters:!((meta:(alias:!n,disabled:!f,field:event.id,index:'logs-*',key:event.id,negate:!f,params:(query:'110701497342736'),type:phrase),query:(match_phrase:(event.id:'110701497342736')))))

[ThomThomson]

Ah I understand your use case now - I was missing context. Unfortunately, the Links will not fit this use-case as they are meant to be relatively static, and will pass the current state of the Dashboard filters, queries etc to the destination Dashboard.

For dynamic linkages, Drilldowns would indeed be your best bet, and they certainly can add filters to the destination Dashboard based on elements of the document on which the user has clicked.

[MakoWish]

Here is a more detailed look at how I am doing things... since I am currently looking at my IAM set of dashboards for an investigation...

I have a TSVB Markdown vis on the left for navigation, but you can also see the some of my hyperlinks from Data Views. I had to hide system names, IP's, and user names, but I left just enough to see "Events by Reporting Host", "Events by User Name", and "Events by Souce IP" are all hyperlinks configured in the Data Views. With this requirement to use Lens, and the inability to include OOB Data Views, this is not possible.

[MakoWish]

Yeah, like I said, drill downs are clunky and not user friendly at all. I don't like using them at all.

[drewdaemon]

@MakoWish I agree with you on the TSVB table URL feature. I recently ran into a very similar case to the one you described when working on Lens conversions for another integration. I've created an issue for adding this to Lens so we can consider this enhancement as a team.

As far as the data views go, I believe @P1llus is only talking about adding library data views that are stored as their own saved object. I believe that the "temporary data views" are not a problem since they are only scoped to a single visualization and do not get installed to the data view page when the integration is added. @P1llus, feel free to confirm.

A final note on the saved queries. I believe they should cover the saved search case as well, since they can be applied to saved searches as well as visualizations, and all other types of Kibana content. Just look out for this bug which makes it a bit more tedious to update existing saved queries.

[P1llus]

As far as the data views go, I believe @P1llus is only talking about adding library data views that are stored as their own saved object. I believe that the "temporary data views" are not a problem since they are only scoped to a single visualization and do not get installed to the data view page when the integration is added. @P1llus, feel free to confirm.

When you create a data-view, use it in a visualization, export it so it includes a reference to that data-view, does this not get generated when the integration is installed @drewdaemon ?
When a user opens the data-view dropdown later, he will also see the data-views generated by the integration does he not?

[drewdaemon]

@P1llus if I create a data view from Lens, I can decide whether to make that data view available outside of my current visualization. If I select "Use without saving," the data view is only available within this particular visualization (it is saved with the visualization SO).

So, when the integration is installed, you will see it in the data view menu only when you open this particular visualization.

[drewdaemon]

Also, @MakoWish I guess I misinformed you on the saved queries. Visualizations won't update when the saved query is updated. So, that is unfortunately an existing gap between saved queries and how you're currently using saved searches. This is the issue to track for that.

ESQL will also work similarly to saved searches today where you will be able to create a set of visualizations based on an ESQL query and when that query is changed, it will be reflected everywhere.

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[MakoWish]

Okay, so yeah... big gaps in Lens IMHO:

• Ability to link to a Saved Search like Aggregation based visualizations can
• Ability to add hyperlinks in Data Table, Metric, Bar Graph, etc. like in TSVB (even if done with Markdown in TSVB)
• Better Markdown capabilities as can be done in TSVB (alignment, CSS, etc.)
• Arc-style gauge for metrics

As it is now, the hyperlinks issue is the biggest for this particular integration. The ability to link to a "details" sort of dashboard is pretty critical for Arista NG Firewall logs. Each detail of a single activity comes from a different provider (session, session stats, firewall, IPS, HTTP, web filter, etc.), and you really have no idea what actually happened without being able to look at all events surrounding an event.id. You could have a dozen or more events related to one activity, and I feel we are striking out on being able to view that overall picture out-of-the-box.

In my environment, I handle the hyperlinks in an "Arista NG Firewall" Data View (logs-arista_ngfw.*), and it works beautifully. I tried to work around that limitation with some changes to visualizations, but we don't seem to be able to do that here.

[P1llus]

@MakoWish apparently I was unaware that its possible to create a dataview when creating a lens visualization that is only scoped to that visualization and not exported as its own saved object but rather part of the lens one, if thats the case then you can use those.

[MakoWish]

Conflicts resolved. Can someone kick off another /test, please?

[drewdaemon]

/test

[MakoWish]

Jenkins is giving me a 500, and I don't have access to BuildKite. Why is it failing?

[efd6]

[2023-11-22T17:37:15.447Z] 2023/11/22 17:37:15  INFO Skipped errors: found 1 validation error:
[2023-11-22T17:37:15.448Z]    1. conditions.kibana.version must be ^8.10.0 or greater to include saved object tags file: kibana/tags.yml (SVR00005)
[2023-11-22T17:37:15.448Z] Error: checking package failed: linting package failed: found 16 validation errors:
[2023-11-22T17:37:15.448Z]    1. references found in dashboard kibana/dashboard/arista_ngfw-090e6d40-1dc4-11ee-b346-5b9e0073e798.json: arista_ngfw-ffee4a67-2bf6-4c3a-881a-026232d2e8c3 (visualization), arista_ngfw-78edcde0-20ee-11ee-8ab3-fb5b73d7bd73 (search) (SVR00004)
[2023-11-22T17:37:15.448Z]    2. references found in dashboard kibana/dashboard/arista_ngfw-0f3dafe6-c66a-4d1e-a9e9-fa3fb418bfaf.json: arista_ngfw-ffee4a67-2bf6-4c3a-881a-026232d2e8c3 (visualization), arista_ngfw-6cf3b505-142c-436a-9625-97800660e36f (search) (SVR00004)
[2023-11-22T17:37:15.448Z]    3. references found in dashboard kibana/dashboard/arista_ngfw-2b026f60-1cf1-11ee-b346-5b9e0073e798.json: arista_ngfw-ffee4a67-2bf6-4c3a-881a-026232d2e8c3 (visualization) (SVR00004)
[2023-11-22T17:37:15.448Z]    4. references found in dashboard kibana/dashboard/arista_ngfw-3565dc44-1886-49aa-b8d3-523623e605dc.json: arista_ngfw-ffee4a67-2bf6-4c3a-881a-026232d2e8c3 (visualization) (SVR00004)
[2023-11-22T17:37:15.448Z]    5. references found in dashboard kibana/dashboard/arista_ngfw-86b139ff-92ab-4aae-b0d8-c33e3be132f1.json: arista_ngfw-ffee4a67-2bf6-4c3a-881a-026232d2e8c3 (visualization), arista_ngfw-da69ba6a-8008-4b1c-9fa9-fde67de3d129 (search) (SVR00004)
[2023-11-22T17:37:15.448Z]    6. references found in dashboard kibana/dashboard/arista_ngfw-93596b63-d808-4a2f-9cbf-d0e9c4003079.json: arista_ngfw-ffee4a67-2bf6-4c3a-881a-026232d2e8c3 (visualization) (SVR00004)
[2023-11-22T17:37:15.448Z]    7. references found in dashboard kibana/dashboard/arista_ngfw-a4bb8521-b9d4-4d33-be52-b4ccefb2eee1.json: arista_ngfw-ffee4a67-2bf6-4c3a-881a-026232d2e8c3 (visualization), arista_ngfw-746674eb-991f-47d4-a42b-b7b205db4b9b (search) (SVR00004)
[2023-11-22T17:37:15.448Z]    8. references found in dashboard kibana/dashboard/arista_ngfw-c61b1eb0-1cf7-11ee-b346-5b9e0073e798.json: arista_ngfw-ffee4a67-2bf6-4c3a-881a-026232d2e8c3 (visualization), arista_ngfw-b0ca4590-1cf7-11ee-b346-5b9e0073e798 (search) (SVR00004)
[2023-11-22T17:37:15.448Z]    9. file "/var/lib/jenkins/workspace/est-manager_integrations_PR-6954/src/github.com/elastic/integrations/packages/arista_ngfw/kibana/search/arista_ngfw-b0ac29e8-0a25-4f59-a59d-10065bb70af3.json" is invalid: dangling reference found: arista_ngfw-5abdd180-1c43-11ee-b346-5b9e0073e798 (tag) (SVR00003)
[2023-11-22T17:37:15.448Z]   10. file "/var/lib/jenkins/workspace/est-manager_integrations_PR-6954/src/github.com/elastic/integrations/packages/arista_ngfw/kibana/dashboard/arista_ngfw-090e6d40-1dc4-11ee-b346-5b9e0073e798.json" is invalid: expected filter in dashboard: no filter found (SVR00002)
[2023-11-22T17:37:15.448Z]   11. file "/var/lib/jenkins/workspace/est-manager_integrations_PR-6954/src/github.com/elastic/integrations/packages/arista_ngfw/kibana/dashboard/arista_ngfw-0f3dafe6-c66a-4d1e-a9e9-fa3fb418bfaf.json" is invalid: expected filter in dashboard: no filter found (SVR00002)
[2023-11-22T17:37:15.448Z]   12. file "/var/lib/jenkins/workspace/est-manager_integrations_PR-6954/src/github.com/elastic/integrations/packages/arista_ngfw/kibana/dashboard/arista_ngfw-2b026f60-1cf1-11ee-b346-5b9e0073e798.json" is invalid: expected filter in dashboard: no filter found (SVR00002)
[2023-11-22T17:37:15.448Z]   13. file "/var/lib/jenkins/workspace/est-manager_integrations_PR-6954/src/github.com/elastic/integrations/packages/arista_ngfw/kibana/dashboard/arista_ngfw-86b139ff-92ab-4aae-b0d8-c33e3be132f1.json" is invalid: expected filter in dashboard: no filter found (SVR00002)
[2023-11-22T17:37:15.448Z]   14. file "/var/lib/jenkins/workspace/est-manager_integrations_PR-6954/src/github.com/elastic/integrations/packages/arista_ngfw/kibana/dashboard/arista_ngfw-93596b63-d808-4a2f-9cbf-d0e9c4003079.json" is invalid: expected filter in dashboard: no filter found (SVR00002)
[2023-11-22T17:37:15.448Z]   15. file "/var/lib/jenkins/workspace/est-manager_integrations_PR-6954/src/github.com/elastic/integrations/packages/arista_ngfw/kibana/dashboard/arista_ngfw-a4bb8521-b9d4-4d33-be52-b4ccefb2eee1.json" is invalid: expected filter in dashboard: no filter found (SVR00002)
[2023-11-22T17:37:15.448Z]   16. file "/var/lib/jenkins/workspace/est-manager_integrations_PR-6954/src/github.com/elastic/integrations/packages/arista_ngfw/kibana/dashboard/arista_ngfw-c61b1eb0-1cf7-11ee-b346-5b9e0073e798.json" is invalid: expected filter in dashboard: no filter found (SVR00002)

[MakoWish]

This wasn't failing before. Why is it failing now? Can we no longer have "navigation panels" with links to the other dashboards? And what filters? Each visualization is filtered for the correct dataset. Is it wanting a filter on the dashboard itself? If so, that is a terrible thing to enforce. My users temporarily pin and remove filters all day long; often using the "remove all" option. If you put the filter on the dashboard itself, there is nothing preventing them from removing that "saved" filter and populating the dashboards with everything in logs-*. This goes back to the ability to use "saved searches" in Lens visualizations. I am shocked that is still not possible yet. I still stand firm that Lens is not yet a suitable replacement for the other "aggregation based" visualizations. There are too many things Lens still cannot do.

[efd6]

/test

[efd6]

/test

[efd6]

/test

[elasticmachine]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (1/1)	💚
Files	100.0% (8/8)	💚 5.556
Classes	100.0% (8/8)	💚 5.556
Methods	97.436% (38/39)	👍 2.467
Lines	93.945% (962/1024)	👍 6.24
Conditionals	100.0% (0/0)	💚

[efd6]

This LGTM. @P1llus would you take a look as well.

[mrodm]

Hi @MakoWish, please update your branch with the latest contents from main branch. There was an important PR merged updating the CI pipelines. Thanks!

[MakoWish]

@mrodm,

It is not showing that any updates are required. Could we please merge this before more changes on your end break this commit again?

[mrodm]

@mrodm,

It is not showing that any updates are required. Could we please merge this before more changes on your end break this commit again?

Hi @MakoWish ,
I think this branch is outdated compared to main. I checked and the latest merge run in this branch was 10 days ago. Please, could you update your branch again with main ? Thanks!!

Regarding merging this branch, I leave that decision to the codeowners/reviewers of this package.

[drewdaemon]

Could we please merge this before more changes on your end break this commit again?

@mrodm I believe that @MakoWish is referring to the new linter rules that came into effect when this package was upgraded to version 3 (which then failed CI for these changes).

Do you know of any linter rules (package-spec) that may have changed since this branch was last brought up-to-date with main? If not, I think you're safe to merge main @MakoWish and we can support your PR if CI fails.

[MakoWish]

@mrodm, I just updated my main branch, and the arista_add_dashboards branch says it is up to date. There is nothing to update that I can see.

Thank you, @drewdaemon, but I don't have permissions to merge, or I would have done it months ago, hahaha.

[mrodm]

Do you know of any linter rules (package-spec) that may have changed since this branch was last brought up-to-date with main?

@drewdaemon it looks like that this branch was already running with the latest version of elastic-package 0.95.0 and package-spec 3.0.3

go: downloading github.com/elastic/elastic-package v0.95.0
...
go: downloading github.com/elastic/package-spec/v3 v3.0.3

[drewdaemon]

@MakoWish

I don't have permissions to merge, or I would have done it months ago, hahaha

Lol—sorry this has been such a marathon.

But what I'm suggesting is that you can safely follow Mario's direction and merge main into this branch. We haven't added any new linter rules, so it's unlikely that CI will fail on you again. If it does, we will help get the PR green again.

[MakoWish]

Yes, I merged already.

This branch is up to date with elastic/integrations:main.

I checked this arista_add_dashboards branch, and it also says it is up to date.

[elasticmachine]

Package arista_ngfw - 0.10.0 containing this change is available at https://epr.elastic.co/search?package=arista_ngfw