Production-ready: Configure possible different Image

[slopezz]

In 3scale SaaS we have been using successfully limitador for a couple of years together with Redis, to protect all our public endpoints. However:

• We are using an old image community image
• Yamls are managed individually via ArgoCD

We would like to update how we manage limitador application, and use the most recommended limitador setup using limitador-operator, with a production-ready grade.

Current limitador-operator:

• Do not permit to configure an image/tag/pullSecretName via CR
• Operator image repository is harcoded to quay.io/kuadrant/limitador
• Operator image tag can be overriden on a weird way: setting in the Operator Subscription CR the envvar RELATED_IMAGE_LIMITADOR.
  • However, only a different tag inside same image repo quay.io/kuadrant/limitador can be used because it is harcoded

Desired features :

• With the possibility of using productized images which are in private image repositories (so requires a pullSecretName reference pointing to a secret holding the private image repo credentials), the image/tag/pullSecretName should be able to be configured via CR to override default values
• Not very important immediately as we will use community images from OperatorHub installation, but eventually I guess would be required if it is needed to use productized images elsewhere

Possible CR config

apiVersion: limitador.kuadrant.io/v1alpha1
kind: Limitador
metadata:
  name: limitador-sample
spec:
  image:
    name: brew.registry.redhat.io/rh-osbs/3scale-mas-limitador-rhel8
    tag: 1.2.0-2
    pullSecretName: brew-pull-secret  # this secret holds the private image repo credentials

Which should create something like:

kind: Deployment
apiVersion: apps/v1
metadata:
  name: limitador
spec:
...
  template:
    spec:
      imagePullSecrets:
        - name: brew-pull-secret
...
      containers:
        - name: limitador
          image: brew.registry.redhat.io/rh-osbs/3scale-mas-limitador-rhel8:1.2.0-2

[KevFan]

Operator image tag can be overriden on a weird way: setting in the Operator Subscription CR the envvar RELATED_IMAGE_LIMITADOR.
However, only a different tag inside same image repo quay.io/kuadrant/limitador can be used because it is harcoded

No, I believe the whole image can be overriden using RELATED_IMAGE_LIMITADOR env var currently 🤔

• limitador-operator/pkg/limitador/image.go

  Lines 13 to 15 in e110bb7

  	func GetLimitadorImageVersion() string {
  	return helpers.FetchEnv("RELATED_IMAGE_LIMITADOR", defaultImageVersion)
  	}

• limitador-operator/pkg/helpers/helpers.go

  Lines 49 to 56 in e110bb7

  	func FetchEnv(key string, def string) string {
  	val, ok := os.LookupEnv(key)
  	if !ok {
  	return def
  	}
  	return val
  	}

[slopezz]

Hi @KevFan , TBH I did not check carefully the code, @eguzki told me that this operator image override was a bit hacky and could easily be improved.

So, in our specific case, overriding operator image is not a must, since possibly we will keep using community images for simplicity (not productized images), so from our side this issue can be closed.

However, if you think other people might be interested on using productized images, operator need to permit overriding 2 different images:

• Override limitador-operator image (to be done on the operator Subscription with and envvar maybe)?
• Override limitador app image via limitador CR fields for every possible limitador CR?

In addition, in case you want to override any of the images (operator or limitador app) in order to use for example a productized image, aside from updating the image, you will need to specify the imagePullSecrets,name containing the credentials to access the private image repo (like productized image repo which is private), and you would need a way to specific this pullSecretName on both operator.Subscription with an envvar? and in the limitador CR.

[KevFan]

Hi @slopezz, I don't think overriding limitator-operator image is typically a done thing since this is controlled by the CSV typically 🤔

Feels odd over an operator to override it's own running image. So unless this is provided by OLM itself, I dont think we will support this.

Allow overriding limitador app image and allowing pulling from private repos I think has some value. I'm due to write an RFC for this so we have a consistent way of allowing this across all kuadrant components. Once we have this decided, we can follow up with an implementation

[KevFan]

Part of the functionality is completed by #133 but doesn't allow for pulling from private repos