allow scaling custom resource

[wjiec]

This PR implements the features described in #2779.

[wjiec]

The reason for blocking here is that command call the internal/dao/registry::Meta.loadCRDs method during initialization (and as part of the init of the whole app), and if it doesn't block here, it will result in an incorrect list of CRDs being read (and theoretically, other resources will have the same problem...).

But this also creates additional problems, in my cluster with a slightly higher load, a total of 96 CRDs takes about ~2s to synchronize.

I didn't think of any good way (or I'm missing something) to solve this problem, does anyone have any ideas?

[derailed]

@wjiec This could indeed be a problem. As you've noted any cluster with lots of resources will become a pb.
The idea here is to leverage k9s eventual consistance so we would not have to block til all caches are updated.

I think we could perhaps lazy eval the crd instead to gauge whether it is scalable once the user decides to actually view it.
Would this make sense?

[wjiec]

@derailed I've also considered checking if the crd is scalable when the view is created, but consider a scenario where if k9s needs to display a crd resource that supports scalable as soon as it starts up, and at that point the cache may not have finished synced, then factory.Get will either return a NotFound error or will need to block until that crd finish synced. Doesn't seem like an optimal approach in this case either?

The current logic decides whether to wait for the cache to finish sync based on the wait parameter, which I see is false in most cases, and only in some special cases does it have wait = true, which I think might be acceptable?

Or we make the key binding dynamic, and when the crds sync is done, we update the view to add the scale cmd.

What do you think?

[derailed]

@wjiec Thank you for your input and sorry for the delay... I like the idea of eventually enabling the scaling option once the resource is synced. This allows for a non blocking approach.

[derailed]

@wjiec Thank you for taking this on Jayson!

[derailed]

@wjiec This could indeed be a problem. As you've noted any cluster with lots of resources will become a pb.
The idea here is to leverage k9s eventual consistance so we would not have to block til all caches are updated.

I think we could perhaps lazy eval the crd instead to gauge whether it is scalable once the user decides to actually view it.
Would this make sense?

[wjiec]

@derailed I spent some time looking into the logic in Meta, and I found that all resources (including CRDs) are actually loaded during loadPreferred, and that loadCRDs don't bring any additional changes (even the previous assignment of meta.Name = crd.Name resulted in the wrong GVRs being registered to Meta. resMetas).

loadCRDs now wait for the cache to sync and add scaleCat for the corresponding CRD. In scale_extender it is dynamically decided whether to add a Scale command to the view based on the presence or absence of a scaleCat.

What do you think of this?