ansh0014 commented on issue #6915:
URL: https://github.com/apache/camel-k/issues/6915#issuecomment-6414694063
Hi @squakez,
I completely agree with this refactoring approach. Running dedicated
operators (like Strimzi or ArkMQ) per scaler adds too much overhead and CI
flakiness when we only need to verify the autoscale loop (0 -> 1 -> 0).
Here is a proposed structure for this unified test setup:
### 1. Directory Structure (`e2e/keda`)
- `e2e/keda/setup/`:
- `keda-setup.sh`: Installs the KEDA operator release.
- Subfolders with minimal, operator-less `Deployment` + `Service`
manifests per broker:
- `activemq/activemq-ephemeral.yaml` (e.g. single pod
`apache/activemq-classic`, ports 61616 and 8161)
- `artemis/artemis-ephemeral.yaml`
- `rabbitmq/rabbitmq-ephemeral.yaml`
- `e2e/keda/files/`: Integration samples for each scaler.
- `e2e/keda/keda_scalers_test.go`: A unified test suite exercising each
component.
### 2. Standardized E2E Verification Flow
For each scaler (e.g. ActiveMQ):
1. Apply the ephemeral broker `Deployment` + `Service`.
2. Apply consumer Integration (`keda.auto: true`).
3. Verify consumer scales to 0 when idle.
4. Trigger producer or push message to queue -> verify consumer scales up to
>= 1.
5. Verify messages are drained and consumer scales back to 0.
### 3. Dedicated Workflow (`.github/workflows/keda.yml`)
- Single workflow replacing fragmented individual scaler workflows.
- Single KEDA operator installation step.
- Runs `make test-keda` or individual matrix test targets.
I can contribute the **ActiveMQ** ephemeral manifest and test scenario
following this pattern. Let me know if this structure matches your vision!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
