Exposed service logs view

[kozhuhds]

Exposed service logs view for other Grafana plugins to consume.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jarben]

Do we need preload:true when exposing components? (I used to think this was for non-hook component extensions only)

[kozhuhds]

yeah, I think so. It doesn't work for me without preload: true.

[jarben]

Interesting, might need some insights from @leventebalogh, also whether we need to specify the extension in the plugin.json

[leeoniya]

please take a look at this thread before proceeding with preload: true. ideally we can avoid introducing this rather than trying to undo it later.

https://raintank-corp.slack.com/archives/C077S1MP40M/p1719937543634869

[jarben]

Thanks @leeoniya, looks like no need for preload: true is supported in 11.1.0, and it requires the plugin.json metadata as mentioned by @sympatheticmoose in the thread:

we'd tried a metadata extractor approach which proved unviable, but theres alternatives by just having the information manually added to plugin.json etc

[leventebalogh]

@jarben @leeoniya

Unfortunately we currently need the preload: true flag. It's true, that we are working on only loading plugins when they are used (extensions or normal plugin usage), but the PR is not yet merged and deployed.

ideally we can avoid introducing this rather than trying to undo it later.

Yeah, I agree that this would be ideal, however unfortunately we cannot avoid it for now. Regarding undoing it later: once the PR mentioned above is merged preload: true won't have an effect, which means that even though we still need to do clean ups in the plugin.json, it won't affect performance.

we need to specify the extension in the plugin.json

Yes, that would be great, thanks. (We can only preload plugins properly if we know what they are exposing.)

[jarben]

Thanks @leventebalogh ! So is this PR just a prerequisite? Or is it for Grafana extensions only, not plugin extensions?

once the grafana/grafana#86624 is merged preload: true won't have an effect, which means that even though we still need to do clean ups in the plugin.json, it won't affect performance.

Makes me think that the cloud-home-app also uses preload:true to be able to show notification banners anywhere in Grafana, not just after the plugin is loaded. How would we handle this use case if preload:true doesn't work anymore?

[leventebalogh]

Exactly @jarben, that PR was only a prerequisite, it still relies on preload: true (here), but the preloading doesn't block the Grafana app boot process anymore. :)

Makes me think that the cloud-home-app also uses preload:true to be able to show notification banners anywhere in Grafana, not just after the plugin is loaded. How would we handle this use case if preload:true doesn't work anymore?

Yea, I guess plugins like like this will still need to be preloaded (cloud-home-app is an exception already). What would be good if they wouldn't block the boot process at least, but unfortunately we couldn't do that with the cloud-home-app, as one of the external libraries it's using is causing weird bugs if it is initialised after Grafana has loaded.

[jarben]

Thanks @leventebalogh, great to see the cloud-home-app exception was considered in the PR.
Do you remember which library caused the issue? @grafana/cloud-ab-testing?

[leventebalogh]

Exactly, it's the third-party library that it is using for A/B testing. (The issue is that it's somehow causing a re-rendering of the whole AppChrome in case it's not loaded before Grafana boots up. I was trying to debug it, but couldn't find the root cause during a time-box.)

[jarben]

What happens when this is empty when optional?

[kozhuhds]

this is a really good question, and I would say a more global one.
Explore logs app has 2 modes: 'service_selection' | 'service_details'. Not sure I can imagine the situation where we need to "embed" and start from service_selection view. So my initial idea was to use only service_details view with a particular service_name filter filled (this is a condition to have this mode opened, otherwise explore logs app redirects to service_selection). I am thinking about sticking to this (and this made me think about some other changes - like I need to disable removing service_name filter for example) wdyt @jarben ?

so answering your question:

1. If initialFilters are empty and the mode is service_details currently it just redirects to explore logs app with service_selection view enabled.
2. If initialDS is empty it applies the default one.

[jarben]

Interesting, thanks for all the details @kozhuhds! So the question is whether to make the extension generic or specific to a service?

• If generic, making the mode as a param would make sense so users can explicitly choose service_selection if that's what they want.
• if service-specific, what if we rename the extension to explore-service-logs/v1 and make the service_name param required? (we can also make an extension such as explore-services)

[jarben]

Should this be a prop?

[gtk-grafana]

Please note that this PR will probably need some updates after the #477 is merged

[kozhuhds]

yeah, after #477 is merged it is becoming a way harder to expose the service logs view since now it contains browser history pushes/redirects everywhere. Not sure how to approach this since at the end of the day it will be just a copy of existing scene components (but without redirects)

cc @gtk-grafana @jarben

[jarben]

yeah, after #477 is merged it is becoming a way harder to expose the service logs view since now it contains browser history pushes/redirects everywhere. Not sure how to approach this since at the end of the day it will be just a copy of existing scene components (but without redirects)

cc @gtk-grafana @jarben

Outch

[gtk-grafana]

yeah, after #477 is merged it is becoming a way harder to expose the service logs view since now it contains browser history pushes/redirects everywhere. Not sure how to approach this since at the end of the day it will be just a copy of existing scene components (but without redirects)

I'll discuss this with the squad tomorrow morning, but with #477 we were addressing user feedback that it's super frustrating that the entire app has a single entry in the browser history, i.e. going back in history would delete everything you did in the app and take you to the last page before entering the app, and there's no way to go forward again after going back so users were forced to manually re-add their filters every time they went back.

I would expect that this would work the same way as split panes in explore, where url parameters are stored in an array of panes, and state changes are pushed to location history and can be traversed in the same order as the user's actions in the any of the panes. This should allow the embedding application to sync state between panes without degrading the UX.

The only functional part of the URL right now is the slug (last part of the path), I imagine it wouldn't be too much work to update the code to store/retrieve the slug from the search parameters instead.

Is there a design doc for embedding scene apps within other apps/core?

[jarben]

yeah, after #477 is merged it is becoming a way harder to expose the service logs view since now it contains browser history pushes/redirects everywhere. Not sure how to approach this since at the end of the day it will be just a copy of existing scene components (but without redirects)

I'll discuss this with the squad tomorrow morning, but with #477 we were addressing user feedback that it's super frustrating that the entire app has a single entry in the browser history, i.e. going back in history would delete everything you did in the app and take you to the last page before entering the app, and there's no way to go forward again after going back so users were forced to manually re-add their filters every time they went back.

I would expect that this would work the same way as split panes in explore, where url parameters are stored in an array of panes, and state changes are pushed to location history and can be traversed in the same order as the user's actions in the any of the panes. This should allow the embedding application to sync state between panes without degrading the UX.

The only functional part of the URL right now is the slug (last part of the path), I imagine it wouldn't be too much work to update the code to store/retrieve the slug from the search parameters instead.

Is there a design doc for embedding scene apps within other apps/core?

An option is also if the extension does its own routing using extension params by bypassing the url routing and using components directly..

[kozhuhds]

hey, prepared a product DNA for this feature.

@jarben @gtk-grafana

[gtk-grafana]

I created an issue for this: #530, I'm going close out this PR and move the discussion there as I think this is a bigger lift then anticipated and will require some planning and collaboration with the other explore app squads.