https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# extensions
a
This message was deleted.
b
All of the directories within the 
./tmp/
directory are just duplicates of the other directories that were created when running the publish-pkgs script. So everything within that directory including the 
assets
, 
charts
, 
extensions
, and 
index.yaml
are necessary.
g
Ok, and if I want to publish the generated helm chart to a separate helm repo I would just use 
./tmp/assets/<my-extension-name>/<my-extension-name>-<version>.tgz
or 
./assets/<my-extension-name>/<my-extension-name>-<version>.tgz
and then I can delete all the files/dirs that 
publish-pkgs
created?
b
You will need those other files/directories within your separate helm repo since those files are referenced within the chart. That includes all of the minified javascript to load the extension and a few other necessary files.
g
Are there any examples of pushing this to a Harbor helm repo?
Guessing it would be something like 
helm cm-push ./tmp my-harbor-helm-repo
It looks like 
spec.plugin.endpoint
in the generated 
cr.yaml
file references the 
extensions
directory on the github repo so does that mean this all needs to be committed to the git repo that implements the extension or is there a way to publish all the generated code to a separate helm repo?
I just noticed this part of the documentation:
Note: Currently, we only support publishing Extension Helm charts into a public Github repository, if you inted to deploy an extension from a private repository/registry, we recommend utilizing the Extension Catalog Image method.
So I'll take a look at using an ECI instead...
Eh, I'd prefer not to require docker
@billions-vase-14972 So if I want to go the helm chart route, is there a way to do it without having to commit auto generated files to my git repo? Does the github workflow approach avoid that?
b
If going the helm chart route, those files will have to be available for your cluster to fetch them. Wherever you plan on publishing your extension is up to you, but the main thing is that the 
spec.plugin.endpoint
needs to be accessible from your cluster. Also the endpoint is determined by the options provided to the 
publish-pkgs
command. There are alternatives to docker, I don't think it's documented (yet) but there is the ability to use podman to build the ECI. You could emulate the gitlab workflow to accomplish that. The main difference is passing the option 
l
into the publish-pkgs script.
g
I would prefer to publish a helm chart to a harbor helm repo but I've only ever published a chart 
.tgz
file but you're saying the files in the packaged 
.tgz
file reference files outside of it, so I can't just publish it like an ordinary helm chart?
b
Unfortunately not, we are planning on revisiting the extension build to address this issue in the coming months. But for now, just publishing the packaged chart 
.tgz
is not enough. The chart just supplies a simple way to create a 
uiplugin
resource, which the Rancher backend will then use the metadata available from the packaged chart to fetch the necessary files in order to load the extension. These files are key. It would probably be possible to store those files elsewhere and publish a chart on it's own, as long as the endpoint is referencing where those files are stored - but that would take some manual effort on your own
g
Ok, that is quite a bummer as we generally avoid committing auto generated code to our repos
Does the github workflow approach avoid having to commit the generated code to the repo or no?
b
No, it simply builds and commits the generated code for you
g
Ok so the current options are: 1. Build a helm chart and commit the auto generated code to the git repo 2. Build an Extension Catalog Image (via docker or podman) which would build a standalone image from the extension source code at the time of the build and would not require committing any generated code to the extension source git repo?
b
Correct
g
Ok, guess I'll try out option 2 to avoid storing auto generated code in a source code repo. Thanks for the clarification.
b
Sure thing, sorry for the confusing build process. I do hope to tackle this soon
g
No problem
Would the improvement for the helm chart building be to package up all the compiled extension source code locally into the 
.tgz
?
b
That's one of the routes we're discussing, another is packaging it into an OCI image.
👍 1
g
Is the custom rancher extension development a recent feature or has it been around for a while?
b
It's been around for a little while and was a bit experimental for sometime, but has really been gaining steam this year.
g
Ok and just to confirm, implementing a rancher extension is the way to have Rancher interface with a custom node driver and has replaced the need for https://github.com/rancher/ui-driver-skel for RKE2, is that accurate?
b
That's correct, the 
ui-driver-skel
repository is setup for ember and will not work with the current dashboard for RKE2.
g
Ok thanks for confirming
👍 1
So did dashboard used to use ember and now it uses vue?
b
Yep, the old repository can be found here, you can also still see some of the ember ui when creating/managing an RKE1 cluster.
👍 1
g
I recently upgraded to v2.8.5, is that the most recent stable version or is v2.9.X stable?
b
v2.9.2
is the latest stable version
👍 1
g
One more question for you, if an extension defines 
machine-config
for a custom node driver, does Rancher create the related machineconfig resoures in the API at the time of installing the extension?
I've been using the developer load feature so far and the UI worked great and I noticed that once it was no longer loaded the UI didn't render as expected, but a script of mine that creates a RKE2 cluster by calling the Rancher API still works fine so I just want to confirm that all the resources related to my extension's 
machine-config
get created up front when installing the extension and everything after that is only related to the UI rendered if creating a cluster graphically?
b
As far as I understand, once you load the driver into the cluster/node driver list, that machine config should still exist. There will be some generic UI once the extension no longer exists
g
Ok thanks
I just built an Extension Catalog Image and pushed it to my Harbor registry.. how do I install the extension in the Harbor UI now? I don't see anything in the documentation for this under the ECI section...
b
Do you mean how do you install it in the Rancher UI? There's some documentation here about importing an ECI
g
If I click 
Explore
next to the 
local
cluster and go to the 
Apps > Repositories
section I only see options for adding a helm repo...
Ah there it is, reading through that now.
I imported the extension catalog image and then I get this error in the rancher logs:
Copy code
2024/09/30 19:14:36 [ERROR] error syncing 'rancher-extension-triton-charts': handler helm-clusterrepo-download: Get "<http://10.43.108.163:8080/index.yaml>": dial tcp 10.43.108.163:8080: connect: connection refused, requeuing
The URL I used was 
<http://harbor.vrcis.com/rancher/rancher-extension-triton:0.1.0|harbor.vrcis.com/rancher/rancher-extension-triton:0.1.0>
which I can successfully 
docker pull <http://harbor.vrcis.com/rancher/rancher-extension-triton:0.1.0|harbor.vrcis.com/rancher/rancher-extension-triton:0.1.0>
locally without issue and it's a public repo
Wondering why Rancher is using 
10.43.108.163
and what that is
Followed those instructions and then I get this:
Copy code
2024/09/30 19:50:02 [ERROR] error syncing 'ui-plugin-catalog-repo': handler helm-clusterrepo-download: Get "<http://ui-plugin-catalog-svc.cattle-ui-plugin-system:8080/index.yaml>": dial tcp: lookup ui-plugin-catalog-svc.cattle-ui-plugin-system on 10.10.50.158:53: no such host, requeuing
Looks like that's using one of our nameservers on the VM that hosts our Rancher docker container which can't resolve 
ui-plugin-catalog-svc.cattle-ui-plugin-system
but that should be resolved by the local cluster DNS, right?
b
The 
10.43.108.163
is the ClusterIP, we ended up targeting that due to the docker version of Rancher having issues with the kube-dns lookup. It should be able to resolve the service correctly, but it's likely the deployment the service is targeting is failing. I tried importing the ECI in my cluster, the deployment that is created with the 
<http://harbor.vrcis.com/rancher/rancher-extension-triton:0.1.0|harbor.vrcis.com/rancher/rancher-extension-triton:0.1.0>
image is on a crashloopbackoff with the error
Copy code
exec /usr/sbin/nginx: exec format error
I don't know why this nginx container is failing to load. Would you be able to link the repo/build here? You can DM me if need be.
g
Yea, I’ll DM you in a minute
For audit purposes, I see the error you mentioned via:
Copy code
e4194ad3a5bf:/var/lib/rancher # kubectl -n cattle-ui-plugin-system logs deploy/rancher-extension-triton
exec /usr/sbin/nginx: exec format error
6 Views
Open in Slack
PreviousNext
Powered by