Uploaded image for project: 'Couchbase Kubernetes'
  1. Couchbase Kubernetes
  2. K8S-1284

RedHat Marketplace Requirements

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Fixed
    • None
    • 2.0.0
    • operator
    • Medium

    Description

       In preparation for submitting your operator for inclusion into the Open Marketplace, there are some technical requirements for CAO that need to be addressed beforehand.
       
      The main technical requirement for all operators is that they must support the ability to run in an offline or disconnected OpenShift environment, with no direct access to the internet from nodes. The way this is addressed is by changing the operator to use an environment variable as the application/operand image source instead of hard coding or using a user-set variable (from the CR/values.yaml).
       
      To satisfy this requirement, you'll need to:
       

      1.     Remove any reference of image locations from the operator code.
        1. I.e. if you have hard coded references to images in your operator for downloads.
      2. Add the env vars to the with RELATED_IMAGE_<identifier> to the operator CSV.
        1. Example:  clusterserviceversion.yaml
      3. Reference the env variable in the operator source code.'
        1. Example: ubinoop_controller.go
      4. Update your operator images and metadata in Red Hat's Container Certification tool at connect.redhat.com.

      The engineering team has also provided a repo with this info as well as an example operator.   Here is a link to that repo:  https://github.com/zachncst/om-env-example/blob/master/README.md
       
       

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            simon.murray Simon Murray added a comment - - edited

            How is this a better user experience?

            • All clusters have the same version, there is no way to run multiple clusters with different versions in the same namespace.
            • To upgrade Couchbase I need to reinstall my operator rather than just change a variable...
            • ...and then the upgrade affects all couchbase clusters (unless explicitly overridden), so piecemeal upgrades are not a thing; if one breaks they all break, not acceptable for enterprise.
            • This also bypasses all the safety checks the dynamic admission controller does at runtime to prevent unsupported upgrade paths and downgrades; these errors disappear into the ether rather than being directly reported to the user.
            • It also bypasses image format and version checking.
            • The image is a mandatory field; to remove the constraint and only run validation on any other  platform is going to be a technical challenge.
            • This also makes the whole product harder to document as we have to worry about some special snowflake that needs custom instructions that are liable to change without our notification.

            I'm struggling to see anything better, perhaps I'm just blinkered

            That said if they really want some environment variables we can do it for them and we just allow overrides (or they can just set them and we'll ignore them), but I can guarantee users using our templates will just explicitly state the Couchbase server version, at which point it's wasted effort.  Matt Carabine you have to support this, any input?

            simon.murray Simon Murray added a comment - - edited How is this a better user experience? All clusters have the same version, there is no way to run multiple clusters with different versions in the same namespace. To upgrade Couchbase I need to reinstall my operator rather than just change a variable... ...and then the upgrade affects all couchbase clusters (unless explicitly overridden), so piecemeal upgrades are not a thing; if one breaks they all break, not acceptable for enterprise. This also bypasses all the safety checks the dynamic admission controller does at runtime to prevent unsupported upgrade paths and downgrades; these errors disappear into the ether rather than being directly reported to the user. It also bypasses image format and version checking. The image is a mandatory field; to remove the constraint and only run validation on any other  platform is going to be a technical challenge. This also makes the whole product harder to document as we have to worry about some special snowflake that needs custom instructions that are liable to change without our notification. I'm struggling to see anything better, perhaps I'm just blinkered That said if they really want some environment variables we can do it for them and we just allow overrides (or they can just set them and we'll ignore them), but I can guarantee users using our templates will just explicitly state the Couchbase server version, at which point it's wasted effort.  Matt Carabine you have to support this, any input?

            Josh Manning replied on 2/3 to our thread. 

            evan.pease Evan Pease (Inactive) added a comment - Josh Manning replied on 2/3 to our thread. 

            Evan Pease assigning back to you since I don't what's the latest on these requirements. Can you please provide an update? Thanks!

            anil Anil Kumar (Inactive) added a comment - Evan Pease assigning back to you since I don't what's the latest on these requirements. Can you please provide an update? Thanks!

            Linked to K8S-1412

            tommie Tommie McAfee added a comment - Linked to K8S-1412

            We have initial marketplace compatibility ready for 2.0.  Change adds a specific code path that will only be engaged when operator is started with a specific set of environment variables. 

            There is a certain point  worth noting for support or possible documentation, which is the environment variables will always override the values provided to spec.image for couchbase/backup/exporter custom resources.  The way around this currently is to edit csv within olm and remove the relatedImages section, as this will subsequently prevent envvars from being mounted to operator pods.

            tommie Tommie McAfee added a comment - We have initial marketplace compatibility ready for 2.0.  Change adds a specific code path that will only be engaged when operator is started with a specific set of environment variables.  There is a certain point  worth noting for support or possible documentation, which is the environment variables will always override the values provided to spec.image for couchbase/backup/exporter custom resources.  The way around this currently is to edit csv within olm and remove the relatedImages section, as this will subsequently prevent envvars from being mounted to operator pods.

            People

              tommie Tommie McAfee
              evan.pease Evan Pease (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty