Check out what's in the latest release of Kabanero Learn More

Configuring a Kabanero CR instance to use an alternative collection repository

A Kabanero custom resource (CR) instance can be configured to use an alternative collection repository. When you have created a new collection repository, as described in Working with collections, follow these steps to use that collection repository with Kabanero:

  1. Create organizational-level teams in GitHub to administer the cloned collection(s), and add members to those teams. These members will be able to use the Kabanero CLI to administer the collections in the namespace where the Kabanero CR instance is configured.

  2. Obtain the URL to the collection repository. If a Git release was created for the collections, the URL format will be: https://<github.com>/<organization>/collections/releases/download/<release>/kabanero-index.html

    • Replace <github.com> with your GitHub or GHE hostname

    • Replace <organization> with your GitHub organization name

    • Replace <release> with the name of the release that was created

  3. Find the name of your Kabanero CR instance. Use oc get kabaneros -n kabanero to obtain a list of all Kabanero CR instances in namespace kabanero. The default name for the CR instance is kabanero. Then, edit the speific CR instance using oc edit kabanero <name> -n kabanero, replacing <name> with the instance name.

  4. Modify your Kabanero CR instance to target the new collections that were pushed to the remote GitHub repository, and the teams in GitHub that should administer the collection(s). Specifically:

    • The Spec.Collections.Repositories.url attribute should be set to the URL of the alternative collection repository.

    • The Spec.Github.organization attribute should be set to the organization hosting the collections in the remote GitHub repository. In the example above, the organization name is my_org.

    • The Spec.Github.teams attribute should be set to a comma separated list of GitHub teams in the remote GitHub repository, whose members can administer the collection using the Kabanero CLI.

    • The Spec.Github.apiurl attribute should be set to the API URL for the remote GitHub repository being used. For example, the API URL for github.com is api.github.com.

      A modified Kabanero CR instance for a collection repository located in the my_org organization of the github.example.com GitHub repository using release v0.1 of collections might look like this:

      apiVersion: kabanero.io/v1alpha1
      kind: Kabanero
      metadata:
        name: kabanero
        namespace: kabanero
      spec:
        collections:
          repositories:
          - name: custom
            url: https://github.example.com/my_org/collections/releases/download/v0.1/kabanero-index.yaml
            activateDefaultCollections: true
        github:
          organization: my_org
          teams:
            - collection-admins
            - admins
          apiurl: api.github.com

      For more information about other fields that can be customized in the Kabanero CR instance, see Configuring a Kabanero CR instance.

      After editing, save your changes. The updated Kabanero CR instance is applied to your cluster.

  5. The Kabanero operator will now load the collections in the repository. To see a list of all collections in the kabanero namespace, use oc get collections -n kabanero. If the kabanero-operator is unable to apply the collections, the Status section of the Kabanero CR instance or the Collection CR instances will contain more information.

Need help?

If you have questions, we would like to hear from you. You can reach out to the community for assistance on the Kabanero Slack channel.