Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow configMapRef in the Trigger metadata #5229

Closed
majusmisiak opened this issue Nov 30, 2023 · 5 comments
Closed

Allow configMapRef in the Trigger metadata #5229

majusmisiak opened this issue Nov 30, 2023 · 5 comments
Labels
feature-request All issues for new features that have not been committed to needs-discussion

Comments

@majusmisiak
Copy link

Proposal

Currently in Trigger configuration we have a field authenticationRef that allows to reference secrets that are defined externally.

I would like to be able to do the same thing for the Trigger metadata field.

Use-Case

I am using Kafka scaler will following configuration (I truncated most configuration fields for clarity):

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: my-app
spec:
  maxReplicaCount: 3
  scaleTargetRef:
    name: my-app
  triggers:
  - type: kafka
    metadata:
      bootstrapServers: kafka.localdomain:9092
      lagThreshold: "10"
    authenticationRef:
      name: my-app
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: my-app
spec:
  secretTargetRef:
  - parameter: username
    name: kafka-auth
    key: KAFKA_JAAS_USER
  - parameter: password
    name:kafka-auth
    key: KAFKA_JAAS_PASSWORD

The Secret ( kafka-auth ) is defined in the cluster environment, it is provisioned independently of the application.

The ScaledObject and TriggerAuthentication are part of the Application lifecycle. They are part of shared deployment template used by the development Teams. The developers can manage it's configuration (for example, change the values of maxReplicaCount or lagThreshold).

However, the Developer typically will not configure metadata.bootstrapServers, since that is related to the environment and closely linked to the authentication parameters.

Also this variable is typically shared (all microservices deployed to the namespace connect to the same bootstrap server).

What I would like to do is put fields like bootstrapServers (or sasl, tls configuration) in the environment and reference it from the ScaledObject as such instead:

  triggers:
  - type: kafka
    metadata:
      bootstrapServers:
        configMapRef:
          - name: kafka-config
            key: bootstrapServers

(or similar)

RIght now, that does not seem possible.

Is this a feature you are interested in implementing yourself?

Maybe

Anything else?

No response

@majusmisiak majusmisiak added feature-request All issues for new features that have not been committed to needs-discussion labels Nov 30, 2023
@tomkerkhove
Copy link
Member

This is a good idea, but would need to be available for all scalers and related parameters IMO.

@kedacore/keda-maintainers thoughts?

@tomkerkhove
Copy link
Member

Created #5233 to consolidate proposals

Copy link

stale bot commented Jan 31, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale All issues that are marked as stale due to inactivity label Jan 31, 2024
@JorTurFer
Copy link
Member

Isn't this fixed by #5111?

@stale stale bot removed the stale All issues that are marked as stale due to inactivity label Jan 31, 2024
@tomkerkhove
Copy link
Member

Jup, duplicate of #4830

@tomkerkhove tomkerkhove closed this as not planned Won't fix, can't repro, duplicate, stale Feb 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request All issues for new features that have not been committed to needs-discussion
Projects
Status: Ready To Ship
Development

No branches or pull requests

3 participants