feat: Add weather-aware demand scaler for climate-based autoscaling

[alvidofaisal]

This PR introduces a new weather-aware demand scaler that enables KEDA to automatically scale applications based on real-time weather conditions. This scaler is particularly useful for applications that experience demand fluctuations correlated with weather patterns, such as:

• Energy management systems (higher demand during extreme temperatures)
• Delivery and logistics applications (increased orders during bad weather)
• Weather-dependent services (tourism, outdoor activities)
• IoT and monitoring systems that need to handle weather-related data spikes

Key Features:

• Weather API Integration: Connects to weather services to fetch real-time weather data
• Configurable Conditions: Supports multiple weather parameters (temperature, humidity, wind speed, precipitation, etc.)
• Flexible Thresholds: Allows setting custom scaling thresholds based on weather conditions
• Multiple Weather Providers: Extensible design to support various weather API providers
• Comprehensive Testing: Includes unit tests and integration test scenarios

Implementation Details:

• Added WeatherAwareDemandScaler with support for weather-based metrics
• Integrated with the scalers builder for seamless KEDA integration
• Provided comprehensive documentation with usage examples
• Follows KEDA's scaler interface and best practices

Example Usage:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: weather-aware-app
spec:
  scaleTargetRef:
    name: weather-app
  triggers:
  - type: weather-aware-demand
    metadata:
      weatherProvider: "openweathermap"
      apiKey: "your-api-key"
      location: "New York,US"
      condition: "temperature"
      threshold: "30"
      operator: ">"

Checklist

• [x] When introducing a new scaler, I agree with the scaling governance policy
• [x] I have verified that my change is according to the deprecations & breaking changes policy
• [x] Tests have been added
• [x] Changelog has been updated and is aligned with our changelog requirements
• [x] A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• [x] A PR is opened to update the documentation on (repo) (if applicable)
• [x] Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #

Relates to kedacore/keda-docs#1568

[SpiritZhou]

Could you please follow the documentation(https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md#changelog), update the CHANGE.MD file with the new issue, and move the documentation to https://github.com/kedacore/keda-docs?

[alvidofaisal]

Could you please follow the documentation(https://github.com/kedacore/keda/blob/main/CONTRIBUTING.md#changelog), update the CHANGE.MD file with the new issue, and move the documentation to https://github.com/kedacore/keda-docs?

Apologies, will do that shortly.

[rickbrouwer]

This scaler does not yet use all the features of TypedConfig available in the scalersconfig package

[rickbrouwer]

Add the checks that are not done via TypedConfig in a CustomValdidator.

Something like (example!):

func (m *weatherAwareDemandScalerMetadata) Validate() error {
	if m.WeatherAPIEndpoint == "" && m.DemandAPIEndpoint == "" {
		return fmt.Errorf("at least one of weatherApiEndpoint or demandApiEndpoint must be provided")
	}
	
	if m.WeatherAPIEndpoint != "" && m.WeatherLocation == "" {
		return fmt.Errorf("weatherLocation is required when weatherApiEndpoint is provided")
	}
	
	if m.TargetDemandPerReplica <= 0 {
		return fmt.Errorf("targetDemandPerReplica must be greater than 0")
	}
	
	if m.WeatherEffectScaleFactor <= 0 {
		return fmt.Errorf("weatherEffectScaleFactor must be greater than 0")
	}
	
	return nil
}

[SpiritZhou]

Is it possible to add an e2e test?

[alvidofaisal]

Is it possible to add an e2e test?

To implement this effectively, we'd need to set up mock weather and demand API endpoints within the E2E test environment. Given that this involves a bit of setup and ensuring the mocks are robust for different test scenarios, it might expand the scope of this initial PR quite a bit.

Would it be acceptable to address the E2E test in a dedicated follow-up PR? This way, we can merge the core scaler functionality first and then focus on building a comprehensive E2E test for it.

[rickbrouwer]

The current implementation serves a different use case than what's documented. There are still some differences in the explanation of the PR and the actual code. The PR description suggests a pure weather-based scaler with flexible conditions/operators. But the actual code is by badWeatherConditions: "temp_below:0,rain_above:5"

I therefore find it somewhat difficult to judge the whole thing. It's looks like more of a "demand scaler with weather adjustment" rather than a "weather-aware scaler". Also in the code there is "negative" naming like badWeatherConditions implies only adverse scenarios, and therefore maybe limiting flexibility. Also the PR suggest support for multiple weather providers.

[alvidofaisal]

The current implementation serves a different use case than what's documented. There are still some differences in the explanation of the PR and the actual code. The PR description suggests a pure weather-based scaler with flexible conditions/operators. But the actual code is by badWeatherConditions: "temp_below:0,rain_above:5"

I therefore find it somewhat difficult to judge the whole thing. It's looks like more of a "demand scaler with weather adjustment" rather than a "weather-aware scaler". Also in the code there is "negative" naming like badWeatherConditions implies only adverse scenarios, and therefore maybe limiting flexibility. Also the PR suggest support for multiple weather providers.

Thanks for your feedback, my apologies for that mismatch.

I will rework it to be more flexible and will share the updates soon.

[alvidofaisal]

I've fixed it to be much more flexible:

• Removed the rigid badWeatherConditions approach
• Now uses weatherParameter, weatherOperator, weatherThreshold so you can define any condition
• Supports pure weather-based scaling, weather-adjusted demand, or just demand-only
• Fixed the HTTP timeout bug that was breaking tests

The implementation now actually matches what is in the PR.

[stale[bot]]

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[bot]]

This issue has been automatically closed due to inactivity.