feature: Add new commands to the kubectl kcp client

[cmoulliard]

Feature Description

The cli and specifically kubectl kcp workspace command should be improved to :

• Display the tree of the workspaces from root or sub-level
• List the synctarget associated to a workspace (or several workspaces),
• Show the status of a synctarget,
• Display the resources sync with a physical cluster and their workspace

Proposed Solution

N/A

Alternative Solutions

N/A

Want to contribute?

• I would like to work on this issue.

Additional Context

No response

[ncdc]

Hi @cmoulliard, thanks for the suggestions! A few comments:

Display the tree of the workspaces from root or sub-level
This is already filed as #1838

List the synctarget associated to a workspace (or several workspaces)

This is not the model we're aiming for. SyncTargets are an internal detail that compute/cluster administrators need to know about, but it's not something end users will see. We do, however, want them to know about Locations, which may be coming from other workspaces, and we'll need a way for kubectl get locations to show these (this will probably involve a custom insertion in the apiserver handler chain to show this "projected" view).

Show the status of a synctarget

This should be kubectl get synctarget/<name> and/or kubectl describe synctarget/<name>. Is there information missing from either of those views that you're interested in seeing?

Display the resources sync with a physical cluster and their workspace

This is going away as part of #1888

[ncdc]

Also, I'd recommend filing 1 issue per feature request, if possible 😄

[cmoulliard]

This should be kubectl get synctarget/<name> and/or kubectl describe synctarget/<name>. Is there information missing from either of those views that you're interested in seeing?

The information should be displayed in a more user-friendly format like:

KUBECONFIG=_tmp/.kcp/admin.kubeconfig k kcp get sync -A
NAME   STATUS   AGE
kind   READY    10m
ocp    PENDING  15min

and

KUBECONFIG=_tmp/.kcp/admin.kubeconfig k kcp describe sync/kind -A

Name: kind
Created: date
Status: Ready|Prending|Error
Reason: reason why status is equal to ....
PhysicalCluster: server: https://127.0.0.1:54532 (we need to know where the syncTarget is pointing to :-) )
workspaces:
- root:my-org
- etc
virtualWorkspaces: 
- url : xxxxx
- etc

[cmoulliard]

This is not the model we're aiming for.

The most important is to be able to show the appropriate information to the user according to their role:

• user => list and read workspace(s) they can access like the resources they can apply for,
• logical clusters managers =>claim to create a logical cluster (= workspaces) that users (= developers) will consume
• physical cluster managers => manage the syncer deployment on their k8s cluster and kcp clusters connected (= synctarget I suppose)

[ncdc]

We display the following columns for kubectl get synctarget -o wide:

// +kubebuilder:printcolumn:name="Location",type="string",JSONPath=`.metadata.name`,priority=1
// +kubebuilder:printcolumn:name="Ready",type="string",JSONPath=`.status.conditions[?(@.type=="Ready")].status`,priority=2
// +kubebuilder:printcolumn:name="Synced API resources",type="string",JSONPath=`.status.syncedResources`,priority=3
// +kubebuilder:printcolumn:name="Key",type="string",JSONPath=`.metadata.labels['internal\.workload\.kcp\.dev/key']`,priority=4
// +kubebuilder:printcolumn:name="Age",type="date",JSONPath=".metadata.creationTimestamp"

Example:

NAME   LOCATION   READY   SYNCED API RESOURCES                                                                                                                                                 KEY                                      AGE
kind   kind       True    [{"group":"apps","identityHash":"74cfc00074fa5bd8de25e588df5818f308cf19b8b1eb17baf9600becf61737c9","resource":"deployments","state":"Accepted","versions":["v1"]}]   53AzOKTaM41h4Zvpf3oNPi5NntRn4inqUdQWhj   24h

A couple of comments:

1. We probably should show these without needing to specify -o wide. @davidfestal would you agree?
2. The format for "Synced API Resources" needs improvement

We show the following for kubectl describe synctarget:

Spec:
  Supported API Exports:
    Workspace:
      Export Name:  kubernetes
  Unschedulable:    false
Status:
  Conditions:
    Last Transition Time:      2022-09-08T12:40:56Z
    Status:                    True
    Type:                      Ready
    Last Transition Time:      2022-09-08T12:40:56Z
    Status:                    True
    Type:                      HeartbeatHealthy
  Last Syncer Heartbeat Time:  2022-09-08T14:20:05Z
  Synced Resources:
    Group:          apps
    Identity Hash:  74cfc00074fa5bd8de25e588df5818f308cf19b8b1eb17baf9600becf61737c9
    Resource:       deployments
    State:          Accepted
    Versions:
      v1
  Virtual Workspaces:
    URL:  https://192.168.4.118:6443/services/syncer/root/kind/0df6bdfe-5c4f-4f96-80b4-9abf8571a9d4

we need to know where the syncTarget is pointing to
I'd recommend filing this as its own feature request

workspaces:
- root:my-org
- etc

Could you please create a new discussion (or issue) specifically for "For a given SyncTarget, how can I determine which workspaces have content going to it?"

user => list and read workspace(s) they can access like the resources they can apply for,

Is this more "there are potentially lots of workspaces in the hierarchy, how do I know which ones exist that I can use?"

logical clusters managers =>claim to create a logical cluster (= workspaces) that users (= developers) will consume

I don't understand this - could you please clarify/reword?

[cmoulliard]

Example:

Cool except to display the resources synchronized as using the json syntax [[{"...] is not really readable when displayed in one line

[cmoulliard]

1. We probably should show these without needing to specify -o wide. @davidfestal would you agree?

I personally agree :-)

[davidfestal]

For a given SyncTarget, how can I determine which workspaces have content going to it

I'm not against it, as far as it is consistent with the common Kube behavior, and if we fix the Synced API resources format.

[ncdc]

Created kcp-dev/contrib-tmc#99 to remove the -o wide need

[ncdc]

And #1966 for chatting about how to know which workspaces are getting synced to a SyncTarget

[ncdc]

I'm closing this as it's hard to track multiple distinct requests in a single issue. @cmoulliard please feel free to create new discussions or issues for any remaining items you have. Thanks!

/close

[openshift-ci]

@ncdc: Closing this issue.

In response to this:

I'm closing this as it's hard to track multiple distinct requests in a single issue. @cmoulliard please feel free to create new discussions or issues for any remaining items you have. Thanks!

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.