Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add provider info to service request counter #12740

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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

silv-io
Copy link
Member

@silv-io silv-io commented Jun 11, 2025

Motivation

/cc @mmaureenliu

Changes

@silv-io silv-io added the semver: minor Non-breaking changes which can be included in minor releases, but not in patch releases label Jun 11, 2025
Copy link

Test Results - Preflight, Unit

21 613 tests  ±0   19 956 ✅  - 2   6m 28s ⏱️ +15s
     1 suites ±0    1 655 💤 ±0 
     1 files   ±0        2 ❌ +2 

For more details on these failures, see this check.

Results for commit b6d93f4. ± Comparison against base commit 5b623bf.

@@ -42,13 +42,15 @@ def __call__(self, chain: HandlerChain, context: RequestContext, response: Respo
err_type = self._get_err_type(context, response) if response.status_code >= 400 else None
service_name = context.operation.service_model.service_name
operation_name = context.operation.name
provider = config.SERVICE_PROVIDER_CONFIG.get_provider(service_name)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this line seems to suggest that there's a 1:1 relationship of service_name to provider, which I think is not true - did I misread the function or the 1:1 relationship actually is true in the community version?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a running instance the relation is 1:1. Only one provider can be active at once. The active provider is defined in the config

Copy link

LocalStack Community integration with Pro

    2 files  ±0      2 suites  ±0   1h 42m 28s ⏱️ +12s
4 872 tests ±0  4 095 ✅ ±0  777 💤 ±0  0 ❌ ±0 
4 874 runs  ±0  4 095 ✅ ±0  779 💤 ±0  0 ❌ ±0 

Results for commit b6d93f4. ± Comparison against base commit 5b623bf.

Copy link
Member

@thrau thrau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking a stab at this! My high-level feedback is: if we include the service provider in each service request, we'll also need to adapt the analytics backend, specifically the materialized view that stores the AWS service request. We can do that, but this creates additional work, is quite a substantial change. Also, since the set of providers doesn't (because it currently cannot) change during the runtime of LocalStack, we'll be sending redundant data for each request.

It might be more efficient to capture the configured providers once at startup, similar to how we log environment variables. This would avoid redundancy and keep the data leaner. Happy to provide more guidance if needed, but suggest to sync up with @vittoriopolverino on this

@mmaureenliu
Copy link

Thanks for taking a stab at this! My high-level feedback is: if we include the service provider in each service request, we'll also need to adapt the analytics backend, specifically the materialized view that stores the AWS service request. We can do that, but this creates additional work, is quite a substantial change. Also, since the set of providers doesn't (because it currently cannot) change during the runtime of LocalStack, we'll be sending redundant data for each request.

It might be more efficient to capture the configured providers once at startup, similar to how we log environment variables. This would avoid redundancy and keep the data leaner. Happy to provide more guidance if needed, but suggest to sync up with @vittoriopolverino on this

Just want some clarification on the "capture the configured providers once at startup" suggestion - do you mean at each session start, send a map of provider to service to the data backend, and let the data backend figure out the provider for each service within the session?

@vittoriopolverino
Copy link
Member

suggest to sync up with @vittoriopolverino on this

Happy to support on this. +1 to what Thomas already pointed out

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver: minor Non-breaking changes which can be included in minor releases, but not in patch releases
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants