This message was deleted.

Good question… Also wondering the same. For config data of extensions you can use a CRD in the cluster, but user-based settings would not work like that

Good day all. For user-based settings, you could use the same process that we use on Rancher Dashboard: Create user preference function: https://github.com/rancher/dashboard/blob/master/shell/store/prefs.js#L13-L32 Usage examples (creation): https://github.com/rancher/dashboard/blob/master/shell/store/prefs.js#L51-L78 Usage (reading it) in a VueJS component: https://github.com/rancher/dashboard/blob/master/shell/components/TypeDescription.vue#L20 (note the imports on https://github.com/rancher/dashboard/blob/master/shell/components/TypeDescription.vue#L4) You could employ the same procedure in the extensions you’re developing and make usage of this mechanism. There’s a caveat though: Since you will be “creating” a user preference from UI (meaning is not explicitly mapped on the backend) in the event of an upgrade of Rancher (going from 2.8.2 to 2.8.3, as an example) the backend would clear out all of these from the backend stored data… We would recommend that if you create a user preference, it’s naming should start with the string

ui-extension-....

(ex:

ui-extension-user-country

). We are discussing this internally so that a backend change would occur that would prevent the deletion of user preferences that start with

ui-extension-....

. Ofc take this with the due grain of salt since we aren’t making any promises here that it will work like this. Just stating that we are aware of this and taking due diligences with the correct team(s). As for general data, CRD seems a good approach in terms of persistance. Bear in mind that an extension may encompass more than just a UI/frontend part but also have a piece of backend (installable via helm chart, for example, like a depolyment) that manages resources that are specific to your extension. Hope I could help

Immediately some follow up questions then: • are there some examples of how you could render the UI elements for a config CRD for which there only needs to be a single instance, for instance where you would store details for calling out to a different service? • Is there for the extension installations a similar Helm chart UI as for the app-marketplace where you could enter installation parameters?

I know the last one. You can find the installed extension under the system namespaces and do an Upgrade/Edit and see that there are some values. I just don't think there's UI for install options yet

It would be so great if we could, that would solve question number 1 as well 😉

@big-greece-35822, not sure if I fully understand

1)

(sorry, not in my best days, but will try to help). Could you provide a clearer example?

are there some examples of how you could render the UI elements for a config CRD for which there only needs to be a single instance, for instance where you would store details for calling out to a different service?

As for

2)

, there’s no UI for install options, unfortunately.

AS for 1, I have added a CRD containing a few settings for the extension, i.e. for instance and endpoint to call out to to fetch info from and an API key. Now typically for any CRD, you automatically get “lists” and “detail” pages, as most CRDs in the system are plurals. Is there any simple way to skip the lists, and just go into detail editing mode, or creation mode (if first time), using all of the extension framework automatic niceties 🙂… Hope that makes the question (slightly) clearer?

ah, yes 😅 now I understand a bit better what you are trying to achieve… When you’re setting up your extension, you’ll get the list “for free” but if you don’t want users to see that on the navigation part, just omit it from the

basicType

(I think you might still need to do the

configureType

, but you can test that). Example: https://rancher.github.io/dashboard/extensions/api/nav/side-menu#defining-a-page-as-a-side-menu-entry-basictype The rest is just about navigation (Vue routing)… Ofc, bear in mind that the

name

part should be in conformity with the structure of your extension. For an extension registered with id as

myextension

the path for the

details

would be (for a global-level extension):

{
      name:   `myextension-c-cluster-resource-id`,
      params: {
        product:   'myextension',
        cluster:   'local',
        resource:  'my-custom-crd-resource-name',
        id: 'my-crd-item-id',
      }
    }

as for

edit

:

{
      name:   `myextension-c-cluster-resource-id`,
      params: {
        product:   'myextension',
        cluster:   '_',
        resource:  'my-custom-crd-resource-name',
        id: 'my-crd-item-id',
      },
      query: {
        mode: 'edit'
      }
    }

and `create`:

{
      name:   `myextension-c-cluster-resource-create`,
      params: {
        product:   'myextension',
        cluster:   '_',
        resource:  'my-custom-crd-resource-name',
      }
    }

Just add it to a

router-link

vue native component on the param

to

, like: https://github.com/rancher/dashboard/blob/master/shell/components/ResourceList/Masthead.vue#L190-L197

👍 Thanks!