kubectl get triggerauthentication should show information about scaledobjects

[tomkerkhove]

kubectl get triggerauthentication should show information about scaledobjects where it is being used

[tomkerkhove]

As per @zroubalik :

It is not possible with current implementation. It would require some logic in the operator, to watch ScaledObjects/ScaledJobs and TriggerAuths and then map triggerauth usages and store them probably into triggerauth.Status. Then we will be able to print them here.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[tomkerkhove]

@zroubalik Do you want to keep this one open or not?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[SpiritZhou]

Hi all, I am trying to solve this issue. Here is my proposal:

1. Add a Status variable in triggerauthentication and ScalingRules variables in Status for saving related ScaledObject/ScaledJob's name.
2. In reconciled of ScaledObject/ScaledJob controller, get triggerauthentication from ScaledObject/ScaledJob's authenticationref and update status of triggerauthentication.
3. The status will be string format as "kubectl get" still not supports array type so I will combine all ScaledObject/ScaledJobs' names into a string.

And here are my concerns:
I find that SO/SJ and triggerauthentication are not watch with each other. We may need to add logic in both SO/SJ and triggerauthentication. Or should we update the watch logic in SO/SJ to watch triggerauthentication's update? I prefer to add updating logic in both SO/SJ and triggerauthentication. What do you think? @tomkerkhove @JorTurFer @zroubalik

[tomkerkhove]

Any thoughts @JorTurFer @zroubalik?

I think the above approach is fine, except that we only need a "scaling rules" section.

[JorTurFer]

I missed this issue 😨
Honestly, I won't do it because the information will not be usable from kubectl if there are 2 or more usages. I mean, we can update the .status for listing all the places where is used, but displaying them as part of kubectl output (even though I see the value) will finish with not usable behavior IMO.
As a user, I'd like this feature if the same TriggerAuthentication is used more than once, so the expected length of that field is large. Said this, I'd agree with having the information as part of the TriggerAuthentication .status and not displaying the info as part of kubectl, adding too much information makes the cli not usable IMO.
The question is, does having those values in status and not displaying them make sense?

I'd like to know what @zroubalik thinks too

[tomkerkhove]

I personally think the current approach is useless as you don't know where it is being used and adding it to the output is just a simple effort that has big impact to operators/end-users.

(although I believe "status" is the wrong name for this though)

[JorTurFer]

(although I believe "status" is the wrong name for this though)

No no, I meant in .status section (like .metadata or .spec), something like

status:
  usages:
    - so/namespace/so-name
    - sj/namespace/sj-name
    - sx/namespace...

adding it to the output is just a simple effort that has big impact to operators/end-users.

I agree, but if the information is unstructured, it's not usable. operators/end-users can use jsonpath for extracting the information that they want if we have already set in the triggerauthentication.
Just to clarify, I'm not against adding the information to the triggerauthentication, I'm not sure about displaying it as part of the output.

As an example, we use a ClusterTriggerAuthentication in at least 10 places like these ScaledJobs:

- prd-mypoints-calculatepoints-subscriber-job/mypoints-calculatepoints-subscriber-job
- prd-mypoints-calculatepoints-publisher-job/mypoints-calculatepoints-publisher-job

If you print them as part of kubectl output, both will be displayed in a single line, which is not usable at all taking into account that kubectl displays a table with the info.

But I agree that having the info available to be queried using kubectl get ... -o jsonpath could be useful

[tomkerkhove]

The open PR has nice example of what it should like look IMO:

I think this is super valuable but curious about your thoughts why this is not ideal? (although I think we are aligned but talking about different things)

[JorTurFer]

let me pull that code and show you what I mean

[JorTurFer]

This is how it looks with one ScaledObject:

It looks well and useful, but this is how it looks with 3 ScaledObject:

Basically, the table is split into 2 lines, making the info not readable. In this case , I have 3 ScaledObjects for the example, but we in case of ClusterTriggerAuthentications, this could grow untill the moon, making the command literally not usable.
Due to this, I'd not expose the info as part of the command output but using -o jsonpath.
This approach also has another important point and it's that we can use arrays and treat each so/sj as an element in the array, not needing to concatenate them to use a string porperty, keeping to the users the option to join them or use them line by line

[tomkerkhove]

This is how it looks with one ScaledObject: It looks well and useful, but this is how it looks with 3 ScaledObject:

Frankly, I do not have a problem with this, it is better than what we have today and only a workaround until Kubernetes has proper support. This should, however, require -o wide flag and not be done by default.

Due to this, I'd not expose the info as part of the command output but using -o jsonpath.

Why one or the other if we can do both?

[JorTurFer]

If we add it only with -o wide I don't have any objection, but I prefer to not set it in the default output

[tomkerkhove]

I totally agree with you! @SpiritZhou Would you mind aligning with this please?

[SpiritZhou]

Sure. Will update it soon.