frontend: Display a8r.io service metadata in service views

[mastermaxx03]

Summary

Adds UI support for a8r.io service discovery annotations in Headlamp.

Related Issue

Fixes #4377

Changes

• Added a "Service Information" section to the Service details view to display a8r.io annotations
• Displayed text-based annotations such as owner, description, and dependencies
• Rendered link-based annotations (logs, documentation, repository, chat) as actionable links
• Added an optional Owner column in the Service list view
• Added row actions for logs, documentation, repository, and chat when valid URLs are present

Steps to Test

1. Create or use a Service with a8r.io annotations (e.g. owner, logs, repository).
2. Open the Service details page and verify the "Service Information" section is rendered correctly.
3. Open the Services list view and verify the Owner column is populated when annotations exist.
4. Open the row actions menu and verify links appear only for valid URLs.

Screenshots

Service list view with optional Owner column populated via a8r.io annotations.

Service list row actions menu showing quick-access links (Logs, Documentation, Contact Team) derived from a8r.io annotations, alongside existing actions.

Service details view displaying the new “Service Information” section populated from a8r.io annotations, including description, owner, dependencies, and external links.

Notes for the Reviewer

• Handles missing or malformed annotations gracefully.
• No behavior change for Services without a8r.io annotations.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: mastermaxx03 / name: Animesh (899a6fa)

[k8s-ci-robot]

Welcome @mastermaxx03!

It looks like this is your first PR to kubernetes-sigs/headlamp 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/headlamp has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[mastermaxx03]

Hi @kahirokunn 👋
I’ve opened a PR implementing the a8r.io annotations support as discussed in #4377.

Would appreciate a review when you have time. Happy to iterate on any feedback.
Thanks!

[kahirokunn]

@mastermaxx03 Thank you so much for this excellent PR!
I've just finished reading through the code.

I'd like to share a few concerns I noticed:
There's a discrepancy in the number of icons shown between Details and List views, and the processing logic appears to be implemented as completely separate systems.
However, upon carefully reviewing the code, I believe these two implementations are likely performing very similar operations, and I don't think there's a need to have a difference in the number of buttons displayed.

Rather than duplicating the entire processing logic again in the List view, would you consider refactoring the A8RServiceInfo side to organize the processing, and then leveraging that shared logic for both Details and List views?

[mastermaxx03]

@mastermaxx03 Thank you so much for this excellent PR! I've just finished reading through the code.

I'd like to share a few concerns I noticed: There's a discrepancy in the number of icons shown between Details and List views, and the processing logic appears to be implemented as completely separate systems. However, upon carefully reviewing the code, I believe these two implementations are likely performing very similar operations, and I don't think there's a need to have a difference in the number of buttons displayed.

Rather than duplicating the entire processing logic again in the List view, would you consider refactoring the A8RServiceInfo side to organize the processing, and then leveraging that shared logic for both Details and List views?

Hey @kahirokunn Thanks for calling that out. happy to clarify.

Right now, the difference is intentional: the Details view is meant to surface all supported a8r.io annotations, including more descriptive fields like description, owner, and dependencies, while the List view actions are kept intentionally small and focused on a few high-signal actions (logs, documentation, repository, chat) to avoid clutter in the row menu.

Because of that, the two views currently use separate logic paths, which I agree does introduce some duplication on the parsing side.

We could refactor this so both views share a small helper for processing the annotations, while still keeping the List view limited to a curated subset of actions. I'm more than happy to do that it if you think this is a better direction.

[kahirokunn]

@mastermaxx03 Thanks for the clarification.
I understand and agree with the intention.
It makes sense that the List view shows fewer items and fewer icons than the Details view to avoid clutter, and I think that’s a great choice.

That said, the meaning/function of the data is the same in both places (they’re both derived from the same a8r.io annotations), so I’d like to apply the DRY principle here.

As you mentioned, providing a shared helper for parsing/processing the annotations sounds like a good direction. From a maintenance perspective, it would be ideal that changes in the annotation handling are applied consistently to both views automatically.

Thanks again.
I’d appreciate it if you could refactor toward that approach.

[mastermaxx03]

@mastermaxx03 Thanks for the clarification. I understand and agree with the intention. It makes sense that the List view shows fewer items and fewer icons than the Details view to avoid clutter, and I think that’s a great choice.

That said, the meaning/function of the data is the same in both places (they’re both derived from the same a8r.io annotations), so I’d like to apply the DRY principle here.

As you mentioned, providing a shared helper for parsing/processing the annotations sounds like a good direction. From a maintenance perspective, it would be ideal that changes in the annotation handling are applied consistently to both views automatically.

Thanks again. I’d appreciate it if you could refactor toward that approach.

I’ll refactor this to introduce a small shared helper responsible for parsing and normalising the a8r.io annotations (filtering, ordering, icon resolution, linkability), and then have both the Details view and the List view consume that shared logic. I'll push an update shortly.
Thanks a lot for your guidance :)

[mastermaxx03]

Thanks for the review feedback earlier! @kahirokunn
I’ve refactored the logic to use a shared helper from A8RServiceInfo so both List and Details views stay consistent.
Happy to iterate further if needed :)

[kahirokunn]

The refactoring is excellent. I'm LGTM on the logic.
Just a minor point, but I've also commented on the unrelated diff for a8r.

[kahirokunn]

I've reviewed the processing myself.
I expect the final feedback will be to make it an atomic commit.

@sniok @illume @joaquimrocha Everyone, do you have any thoughts on this UI, etc.?

[illume]

Hey hey. Thanks!

Can you please change the commit message to match the commit message guide lines? Check some of the other messages to see the capitalization of the verb at the start.

Also, thanks for the review @kahirokunn

[Copilot]

Pull request overview

This pull request adds UI support for a8r.io service discovery annotations in Headlamp, enabling users to easily access service metadata such as owner, documentation links, logs, and communication channels directly from the UI.

Changes:

• Added a new A8RServiceInfo component to display a8r.io annotations as formatted metadata with icons
• Enhanced the Service list view with an Owner column and row action menu items for quick access to external links
• Added a conditional "Service Information" section in Service details view when a8r.io annotations are present

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
frontend/src/components/service/A8RServiceInfo.tsx	New component that parses and displays a8r.io annotations with icons, labels, and external links
frontend/src/components/service/List.tsx	Adds Owner column and row actions menu for a8r.io link annotations (logs, docs, repository, chat)
frontend/src/components/service/Details.tsx	Conditionally displays Service Information section, adds key props to map operations, and applies minor code cleanup

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[illume]

Please run the frontend tests locally? There’s a GitHub check failure.

[mastermaxx03]

Please run the frontend tests locally? There’s a GitHub check failure.

Hey @illume I’m working on these changes now. I’ll fix the frontend test failures and I'll push an updated, atomic commit shortly.

[mastermaxx03]

Hi @illume and @kahirokunn,
I’ve pushed updates addressing the review feedback:

• Added the missing MDI icons to the icon cache
• Updated Storybook snapshots where required
• Squashed the changes into a single clean commit

All frontend tests and Storybook tests are now passing locally.
let me know if you’d like anything adjusted further!

[kahirokunn]

Let's try running ci.

[illume]

Great, thank you for that.

[illume]

Thanks again.

I have some notes after review for your consideration:

• Can you please add some states to ServiceDetails.stories.tsx which cover these new additions?
• There's a check failing in CI... Can you please run "npm run i18n"? It looks like there are translation strings that need to be generated. Don't worry about translating them all! But it needs the generated changes checked in.
• Please don't render the Owner column unless there are a8r annotations
• I left another note about adding tsdoc documentation to one of the functions (if you could also document any new interface fields that would be good).
• One little thing with the commit message. Since the vast majority of changes are in frontend/ (and fewer in app/ or backend/) it's good to add a bit more context. Since it touches two areas, you can add these areas into the context part of the commit message.

frontend: App: service: Add a8r.io service metadata support and icons

[mastermaxx03]

Thanks again.

I have some notes after review for your consideration:

• Can you please add some states to ServiceDetails.stories.tsx which cover these new additions?
• There's a check failing in CI... Can you please run "npm run i18n"? It looks like there are translation strings that need to be generated. Don't worry about translating them all! But it needs the generated changes checked in.
• Please don't render the Owner column unless there are a8r annotations
• I left another note about adding tsdoc documentation to one of the functions (if you could also document any new interface fields that would be good).
• One little thing with the commit message. Since the vast majority of changes are in frontend/ (and fewer in app/ or backend/) it's good to add a bit more context. Since it touches two areas, you can add these areas into the context part of the commit message.

frontend: App: service: Add a8r.io service metadata support and icons

I’ve gone through your notes and addressed all of them:

• Added Storybook states in ServiceDetails.stories.tsx and ServiceList.stories.tsx to cover services with and without a8r annotations
• Ran npm run i18n and checked in the generated translation files
• Updated the Services list so the Owner column is only rendered when a8r.io/owner annotations are present
• Added TSDoc to the referenced function and documented the new interface fields
• Updated the commit message to better reflect the frontend areas touched

For the conditional Owner column, I used the hideColumns prop to dynamically hide/show the column.
Ready for review @kahirokunn @illume

[Copilot]

Pull request overview

Copilot reviewed 21 out of 21 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[illume]

Thank you! Great work.

I'll wait a bit before merging to give @kahirokunn some time to give a final review (since they reported the issue).

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: illume, mastermaxx03

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [illume]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[sniok]

Thanks for contributing!
Current implementation only displays these annotations on the server but I think we should display it on any resource that contains them. I think it should be part of the metadata component. That way we can support any resource and also make it look more cohesive with existing information

cc @kahirokunn what do you think?

[illume]

Current implementation only displays these annotations on the server

AFAIK people are only using it on services.

I think it should be part of the metadata component. That way we can support any resource and also make it look more cohesive with existing information

Agree it should probably show with the other meta data... (But also, it's kind of fine separated.)

btw. Looking at them side by side, I realise our meta data component is rendering quite weird with all that space between the keys and values.

[kahirokunn]

btw. Looking at them side by side, I realise our meta data component is rendering quite weird with all that space between the keys and values.

It's been quite a journey to get here. Thank you so much for all your hard work and patience throughout this process!
How about we address illume's last feedback, and once that's resolved, we can proceed with merging? Really appreciate your dedication on this!

[mastermaxx03]

btw. Looking at them side by side, I realise our meta data component is rendering quite weird with all that space between the keys and values.

It's been quite a journey to get here. Thank you so much for all your hard work and patience throughout this process! How about we address illume's last feedback, and once that's resolved, we can proceed with merging? Really appreciate your dedication on this!

It has been fun ngl!
@kahirokunn Just to clarify:
We are keeping a separate section for 'Services' right or move the a8r.io info into the MetadataDisplay component?

Regarding the spacing issue in the metadata component - that seems like a pre-existing issue. Should I address that in this PR or would that be better as a separate fix?

[kahirokunn]

Thank you for all your work on this!

While integrating into the MetadataDisplay component might be good in theory, I think doing so would expand the scope significantly and take us away from the main focus of this PR (the a8r.io integration). I believe keeping the separate 'Services' section as it is now makes sense for this PR.

Regarding the spacing issue. I agree that it's a pre-existing issue and would be better addressed in a separate PR to keep this one focused.

Everything looks good to me! Let's move forward with this. LGTM! 🚀

[kahirokunn]

By the way, I was originally considering integrating this as button-style displays in this section.

However, to be honest, having too many buttons lined up could make it look like Excel where it's hard to tell what each button does, and I know some people would find having so many buttons overwhelming. So I'm actually positive about having a dedicated a8r section.

That said, I'm not a senior designer or anything, so UX design experts might have different perspectives. However, I believe this PR has accomplished its core objective, so I think it's best to move forward now and address any minor concerns in separate PRs or issues. This approach will help us maintain momentum and iterate more quickly on improvements.

[mastermaxx03]

By the way, I was originally considering integrating this as button-style displays in this section.

However, to be honest, having too many buttons lined up could make it look like Excel where it's hard to tell what each button does, and I know some people would find having so many buttons overwhelming. So I'm actually positive about having a dedicated a8r section.

That said, I'm not a senior designer or anything, so UX design experts might have different perspectives. However, I believe this PR has accomplished its core objective, so I think it's best to move forward now and address any minor concerns in separate PRs or issues. This approach will help us maintain momentum and iterate more quickly on improvements.

I agree with your analysis. That said, if there are more improvements needed on the UX side, I'll look into it and raise separate PRs for those.

[illume]

That said, if there are more improvements needed on the UX side, I'll look into it and raise separate PRs for those.

Ok.

Let's go with this as a first iteration.

• Let's keep the issue open to allow feedback on design if anyone is interested in further refinements. I've added these points in the issue to finish:
  • Should it go in with the MetadataDisplay ? (at top or bottom)
  • Should it go in the action button icons area?
  • Is it better as a row of icons only? (just above the meta data table)
    • separated from the other actions?
  • Should this work for all resources, not just services?
  • We should also document this, or make it more easily discoverable.
  • What about a "headlamp" based prefix that would work as well as the a8r one?
  • Should the service information go to the top?
• I opened an an issue to improve the MetadataDisplay design so it's readable (with the keys not being so spaced from the values)