Highlight ownerReference links in cluster mode

[olensmar]

In K8s objects can be "owned" by another object - see https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/

Monokle could/should identify these references (using the existing refMapper approach) and show them - perhaps with a dedicated icon / section in the "outgoing links" popup (containing all objects the selected object "owns"), and a dedicated "owner" icon in the "incoming links" popup for owned objects!?

For the below EndpointSlice there would be an "owners" section in the "incoming links" popup - and the corresponding Service would have a "Children" section in its "outgoing links" popup

[chargio]

• Add the owner reference to the display (special section). Special type of resources.
• Show the owned resource in the details for an object
• Show the owner resource in the details for an object

[chargio]

• Show resources being deleted when you delete a parent.
• Show resources owner when you delete a child. I.e. "This is managed by X, if you delete it the lifecycle will still be owned by the object owner and could be recreated".

[julioramosest]

UI and UX notes: https://www.figma.com/file/ttKKFbqVWEPg3BNseXmSsb/Towards-2.0?node-id=1581%3A8363&t=F82D71D6R5jCpNxf-1

(@olensmar I'm suggesting 3 options for the highlighting of the owner/dependent links in the resources list - let's discuss)

[chargio]

Validation will be done in the core (link to issue). this is the UI part for Desktop

[chargio]

• [ ] It should be possible to use the ownerReferenceLink in cluster mode to navigate resources. Both up (this object is owned by this other) and down (this objects owns these others)

[chargio]

@olensmar Would you want to tackle this one? It should be in the core.

[olensmar]

@chargio sure - I can do the processing part - the UI updates will have to be done separately

[olensmar]

@WitoDelnat @devcatalin Using the standard refMapper approach works for identifying these refs but there is no way to distinguish ownerRefs from other refs in the resulting ResourceRef objects: to differentiate these from "regular" outgoing refs, we could do one of the following

• introduce a new ResourceRefType = ownerRef value
• add an isOwnerRef property to the ResourceRef type which would be true for both the incoming and outgoing refs for an ownerReference, which would result in less work in the UI to single these out..

I suggest the latter of these two - but wanted your take first...

[olensmar]

PR in core waiting for approval - https://github.com/kubeshop/monokle-core/pull/287