Request to Add Useful Extensions

[Federico-Baldan]

Hi :),

I would like to suggest adding the following extensions, which were previously available and provided significant utility:

Certificate Info:
Description: Retrieves detailed information about certificates stored in secrets, such as expiry dates.
Repository: Certificate Info Extension

Version Update:
Description: Allows users to easily update the image tags of containers (including CronJobs).
Repository: Version Update Extension

Debug Pods:
Description: Provides an option to run debug pods easily via the lens menu.
Repository: Debug Pods Extension
Note: This extension is currently not functional in OpenLens, but it was working as of two years ago.

Kubernetes distribution: Rancher
Desktop OS: Ubuntu 24.04

[robertobandini]

Hi @Federico-Baldan and thanks for your contribution!

I think that as you did, many others could report other useful extensions for the old open lens, which we would now like to use on Freelens.

The extension https://github.com/freelensapp/freelens-node-pod-menu has been forked because it is considered essential and we would like to bring it back directly as a default feature of Freelens.

For the others at the moment, if they already work with Open Lens, they can be easily adapted for Freelens, as was done for "freelens-node-pod-menu".
We could create a doc and an ad hoc example on this.

The adaptation could be requested via an open issue to the same authors of a given extension.

If the extension is not carried forward, those who want it can, if the license allows it, fork it and make their own to adapt to Freelens.

If it is considered particularly important, but the original authors are no longer developing it, we can fork it, if the license allows it, creating a repository in the freelensapp organization and leaving the development to the relative volunteer contributors.

The first option, in case of extensions already existing and already working, should be to open an issue to the original authors, what do you think? @dex4er

[robertobandini]

Hi @Federico-Baldan

do you think you can contribute by trying to open an issue on the extension repositories you indicated to ask if the projects are still alive and if they can adapt them themselves or create a version for Freelens?

If so, you can indicate here in this issue the links to the open issues so we can keep track of them.

If we understand that the projects are closed or there is no direct will to make a version for Freelens, we will see depending on the license to try to do it directly by creating new repos in the freelensapp org.

Let us know what you think, thanks!

[Federico-Baldan]

Hi,
jkroepke/lens-extension-certificate-info#9
pashevskii/debug-pods-lens-extension#13
ottimis/freelens-version-update#5

ty for all

[jkroepke]

I ask myself, if it's possible to setup a freelens compatible app without breaking compatibility to OpenLens?

[dex4er]

@jkroepke We use different namespace for the modules @freelensapp/ instead of @k8slens/ and different semver versions. Eventually we could provide some shim maybe to fake original module and ie. load the right one depends on the application is started (Openlens or Freelens). The same trick as https://www.npmjs.com/package/any-promise in old times.

[dex4er]

My request:

Multi Pod Logs Lens Extension
Description: An extension that enables you to see logs from multiple pods (and multiple containers within the pod) on Kubernetes.
Repository: https://github.com/andrea-falco/lens-multi-pod-logs

[robertobandini]

My request:

Multi Pod Logs Lens Extension Description: An extension that enables you to see logs from multiple pods (and multiple containers within the pod) on Kubernetes. Repository: https://github.com/andrea-falco/lens-multi-pod-logs

Interesting! Will you open an issue to ask about Freelens compatibility?
We can also open a doc here to track compatibile extensions, desidered extensions to be converted, work in progress extensions and so on... so if somebody ask for another extension we can add it there.

[robertobandini]

I ask myself, if it's possible to setup a freelens compatible app without breaking compatibility to OpenLens?

Thanks @jkroepke for your contributions!

[robertobandini]

Then we can refer it also on the readme for example @dex4er

[mmoriani]

Hi, jkroepke/lens-extension-certificate-info#9 pashevskii/debug-pods-lens-extension#13 ottimis/freelens-version-update#5

ty for all

I've updated ottimis/freelens-version-update

[robertobandini]

Thanks @mmoriani so @Federico-Baldan you can test it!
Then we can add it to official compatible extensions list.

[jkroepke]

@jkroepke We use different namespace for the modules @freelensapp/ instead of @k8slens/ and different semver versions. Eventually we could provide some shim maybe to fake original module and ie. load the right one depends on the application is started (Openlens or Freelens). The same trick as https://www.npmjs.com/package/any-promise in old times.

Does node resolve the packages name by file system? If so, a symlink may be sufficient.

symlink k8slens link to freelens

[dex4er]

WIndows does not have symlinks.

[jkroepke]

WIndows does not have symlinks.

of course, windows have symlinks: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mklink

Secondly, electron asar archive support symlinks as well.

[dex4er]

Ok, so as I checked, it won't help us: it is very easy to adapt plugins from (Open)Lens to Freelens, but it would be difficult to make them working in 2 different applications from the same TGZ package.

It is because of dependencies and incompatible namespaces of the modules.

My experiment:

andrea-falco/lens-multi-pod-logs@master...dex4er:freelens-multi-pod-logs:freelens

The installed extension works:

Rather than introducing the methods incompatible with Node.js ecosystem and actually hackish (ie. using symlinks) we should help to adapt some extensions or do it ourselves as they are on Free and Open-Source licenses.

It the best case we can just fork some repos, patch it then publish NPM pakages to our namespace and update any further changes from the upstream repos.

[robertobandini]

Since open lens is stuck at the end of 2023 and there is no further support for old extensions, I think it comes naturally that they will continue alongside Freelens, since adapting them is currently very easy.

[jkroepke]

@dex4er thats fine and I would agree with you. Symlink could be a low hanging fruit, but fail fast and reject the proposal is fine to me.

I agree, compability to freelens is just search and replace, I do that already on a branch and test it locally.

Everythink works fine including the old lens bugs on install 😅

[dex4er]

@jkroepke So what I really think, symlinks are not really low hanging fruit because of how NPM works.
Extensions are installed with npm install (see

freelens/packages/core/src/extensions/install-extension/install-extension.injectable.ts

Line 18 in 925788d

const baseNpmInstallArgs = [

) then really it would be significant effort to fool NPM to *not (re)install some package and use symlinks instead. Actually npm link command with some fake @k8slens/extensions package that really uses our @freelensapp/extensions maybe.

So it will be some additional tricky code with not so clear tricks to fool NPM vs single search-and-replace in source module of extension.

[robertobandini]

@jkroepke Please open issue about every bug. Thanks!

[jkroepke]

Done! lens-certificate-info is compatible now.

[robertobandini]

Great @jkroepke!! Thank you very much! Also for your questions and thoughts on extensions compatibility.

[dex4er]

There is a bad news: releasing 1.0.0 version will make this extension incompatible again.

So now I want to rethink goals of 1.0.0 release. The most important is to make extension easy to adapt now and later to keep compatibility as much as possible. In this case we should release 1.0.0 real soon and go with other things later, ie. in 1.1.0.

[jkroepke]

is there any help in terms of migration? docs?

[robertobandini]

Yes: application now works and updates are important but not critical. Further updates also won't break compatibility with extensions. My proposition is to go to v1.0.0 now and set the updates as a goal for further v1.1.0.

That's ok, I agree, it will be important to work on updates to maintain functionality and security from 1.1.0.

[robertobandini]

is there any help in terms of migration? docs?

I would like to create one or more doc pages about extensions, I also created this issue.
#114
I think we can use the wiki section here, or start extending the github pages website, another repo under this org.
Do you think you can help here or do you have some other idea/opinion?
Otherwise I'll take care of it as soon as I have time.

If you want to start working on updating dependencies I think there is a lot to do.

[jkroepke]

Do you think you can help here or do you have some other idea/opinion?

It looks like but JS/TS knowledge based on google search and other lens extension. In mean time, I accept other maintainer offerings (e.g. prometheus), so my available time for maintain things is mainly used for other projects. Sorry at this point.

[robertobandini]

Do you think you can help here or do you have some other idea/opinion?

It looks like but JS/TS knowledge based on google search and other lens extension. In mean time, I accept other maintainer offerings (e.g. prometheus), so my available time for maintain things is mainly used for other projects. Sorry at this point.

Yep! I really understand you about "time" and of course all my respect and thanks for the contributions to Prometheus!