frontend Map: Allow plugins to customize the map

[sniok]

Basic Map extension

This PR introduces 2 new functions that allow for the simplest case of extending the Map.

You can read the full docs page over here https://github.com/headlamp-k8s/headlamp/blob/7cbc2ef226bab1f65ad6d8ddccaf07b43c093f95/docs/development/plugins/functionality/extending-the-map.md
You can add your own nodes and edges, customize the icon for the nodes and show a details page for the node.

1. registerMapSource
   registers a "Source" which provides Nodes and Edges to the map

2. registerKindIcon
   adds an icon for a specific resource "kind", which is displayed on the node and the map search (not the global one)

[joaquimrocha]

This looks very reasonable. I have 2 questions, however:

1. Does it makes sense somehow to unify the details page for the map and for other places?Right now we have the notion of a details route, associated with a KubeObject, but a component is registered for this just as a normal route by using registerRoute.
2. I think the "framework" you are proposing matches a lot the case where we want to display kubernetes resources, but I wonder if it makes sense to abstract it to something that is not Kubernetes specific. Say e.g. we want to display users? Or we want to display clusters?

[sniok]

1. Does it makes sense somehow to unify the details page for the map and for other places?Right now we have the notion of a details route, associated with a KubeObject, but a component is registered for this just as a normal route by using registerRoute.

Absolutely, I think would be perfect for adding details page, especially for custom resources. Even now we could already replace all routes to render KubeObjectDetails component.

2. I think the "framework" you are proposing matches a lot the case where we want to display kubernetes resources, but I wonder if it makes sense to abstract it to something that is not Kubernetes specific. Say e.g. we want to display users? Or we want to display clusters?

Yes it can support other objects as well, when we register a source it currently only returns nodes with the type "kubeObject" but it can return any type. The only missing piece for now is registering custom node type.

So it is going to look something like this:

// register customUser type
registerNodeType('customUser', { renderNode: (nodeData) => <div>{nodeData.name}</div> } ))

registerMapSource({
   useData() {
      // specify type and pass any data
      return {  nodes: [{ id: 'some-user', type: 'customUser', data: { name: 'user-name' } }] }
   }
})

[sniok]

Removed the registerKindDetailsPage method from this PR as it needs some more investigation and thought

[sniok]

Rebased and updated after the map refactor. Added a way to define custom Details component for each node

Please check out the latest doc version
https://github.com/headlamp-k8s/headlamp/blob/7cbc2ef226bab1f65ad6d8ddccaf07b43c093f95/docs/development/plugins/functionality/extending-the-map.md

[sniok]

When using the sample code from the latest doc linked above and running the latest version of this branch, the node content is not visible. Would you know what the issue could be?

hi Fabian, instead of defining a node as

{
  id: "123",
  data: {
    resource: someKubeObject,
  }
}

it now should be defined as

{
  id: "123",
  kubeObject: someKubeObject
}

that's my bad, I forgot to update the markdown example, it's fixed now.
There's also a working example in plugin/examples/customizing-map although it's pretty much the same thing

[faebr]

Hi @sniok, with the new example it works as expected now, this looks great! I have some follow-up questions / ideas:

• Using this new plugin api, the CRD's could be added using a plugin to the map instead of in the base code as we demo'ed to you ( our code implementing CRD in the map is now outdated due to the changes you have done since ). Would you still prefer this feature to be in the core code itself, then I could look into adapting it or would you be more interested in a CRD plugin?
• In the dropdown to select the kind of resources to show in the map, it cuts off the text, what would you think of making the box adjustable using a fit-content() ? (ae687ce)
• Is there a specific reason you remove loops in the graph? We could think of Scenario's where it would be nice to allow loops in case we would like to have edges not only represent owner-references but other dependencies. Since by default edges show owner-references only, there should not be any loops anyhow or am I wrong? ( example: 9cb6e50 )

[joaquimrocha]

• Using this new plugin api, the CRD's could be added using a plugin to the map instead of in the base code as we demo'ed to you ( our code implementing CRD in the map is now outdated due to the changes you have done since ). Would you still prefer this feature to be in the core code itself, then I could look into adapting it or would you be more interested in a CRD plugin?

I will let @sniok answer the other questions. For this one, my impression is that we should support CRDs/CRs from the core, without the need for a plugin. What a plugin could eventually do is deregister/override how a certain CRD is shown, in case e.g. an application wants to have a custom view of its CRDs.

[sniok]

Hi @sniok, with the new example it works as expected now, this looks great! I have some follow-up questions / ideas:

• Using this new plugin api, the CRD's could be added using a plugin to the map instead of in the base code as we demo'ed to you ( our code implementing CRD in the map is now outdated due to the changes you have done since ). Would you still prefer this feature to be in the core code itself, then I could look into adapting it or would you be more interested in a CRD plugin?

+1 on what @joaquimrocha said, Custom Resources should be supported in core. and plugins then can provide edges and additional details component.

• In the dropdown to select the kind of resources to show in the map, it cuts off the text, what would you think of making the box adjustable using a fit-content() ? (ae687ce)

yeah that sounds good!

• Is there a specific reason you remove loops in the graph? We could think of Scenario's where it would be nice to allow loops in case we would like to have edges not only represent owner-references but other dependencies. Since by default edges show owner-references only, there should not be any loops anyhow or am I wrong? ( example: 9cb6e50 )

I don't think loops were intentionally removed, it just was overlooked since there weren't any loops during development, but map should support any graph, with or without loops. That fix for grouping you proposed looks good.

Edges can represent any kind of relationship, not just ownership, we have an option to introduce labels and custom styles for edges, there was no need for it yet but it's definitely something we'd want to do.

[faebr]

• In the dropdown to select the kind of resources to show in the map, it cuts off the text, what would you think of making the box adjustable using a fit-content() ? (ae687ce)

yeah that sounds good!

• Is there a specific reason you remove loops in the graph? We could think of Scenario's where it would be nice to allow loops in case we would like to have edges not only represent owner-references but other dependencies. Since by default edges show owner-references only, there should not be any loops anyhow or am I wrong? ( example: 9cb6e50 )

I don't think loops were intentionally removed, it just was overlooked since there weren't any loops during development, but map should support any graph, with or without loops. That fix for grouping you proposed looks good.

Edges can represent any kind of relationship, not just ownership, we have an option to introduce labels and custom styles for edges, there was no need for it yet but it's definitely something we'd want to do.

Labels and custom styles for edges would be a nice feature!

I created an mr with these small changes in case this helps: #2963

For the CRD on the map within the core code I talked to my team but we can not commit for a timeline right now, I will update you when this changes.