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

Skip to content

update api-dependencies and check cloudwatch/logs enabled #9576

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

Merged
merged 8 commits into from
Nov 13, 2023

Conversation

steffyP
Copy link
Member

@steffyP steffyP commented Nov 7, 2023

Motivation

Previous PR #9494 enabled the loading of specific services only.
In this PR we update the API_DEPENDENCIES for community, and added checks for before calling non-required services.

Changes

  • Lambda

    • prevent EventSourceListener to start if the event-source service is not loaded
    • skip the start of LogHandler thread, if logs is not enabled
    • skip building vpc-config if ec2 is not enabled
  • CloudWatch-Util

    • added checks before calling service (logs + cloudwatch)
    • the publish_lambda_metric is also used by lambda
  • Logs

    • skip metric-filter if cloudwatch is disabled
  • updated API_DEPENDENCIES

    • kinesis: removed dependency on dynamodb as it doesn't seem to be called
    • lambda: removed cloudwatch + logs, added sts

Testing

Automated testing of this fix is hard, mainly because also for bootstrapped-test we cannot invoke the lambda.
As a manual check:

cat > index.py << EOL
import json
def handler(event, context):
    print(json.dumps(event))
    return event
EOL

zip function.zip index.py

awslocal lambda create-function \
    --function-name lambda-only-test \
    --runtime python3.9 \
    --zip-file fileb://function.zip \
    --handler index.handler \
    --role arn:aws:iam::000000000000:role/lambda-role

awslocal lambda create-event-source-mapping \
    --function-name lambda-only-test \
    --batch-size 1 \
    --starting-position "TRIM_HORIZON" \
    --event-source-arn "arn:aws:dynamodb:us-east-1:000000000000:table/MusicCollection/stream/2020-07-28T21:53:39.112" \
    --maximum-batching-window-in-seconds 1 \
    --maximum-retry-attempts 1

Before it would keep logging errors:

localstack  | 2023-11-08T11:58:16.004  INFO --- [   asgi_gw_0] l.aws.handlers.service     : Service 'dynamodbstreams' is not enabled. Please check your 'SERVICES' configuration variable.
localstack  | 2023-11-08T11:58:16.007 ERROR --- [functhread57] l.s.l.e.stream_event_sourc : Cannot describe target stream arn:aws:dynamodb:us-east-1:000000000000:table/MusicCollection/stream/2020-07-28T21:53:39.112 of event source mapping eb910335-cc95-4d52-957b-aa035ae57476: An error occurred (InternalFailure) when calling the DescribeStream operation: Service 'dynamodbstreams' is not enabled. Please check your 'SERVICES' configuration variable.

With this changes, we can add a mocked event-source-mapping without any errors, also invoke the lambda, logs and cloudwatch will not be enabled, and there are also no errors in the localstack logs.

@steffyP steffyP added the semver: patch Non-breaking changes which can be included in patch releases label Nov 7, 2023
@@ -63,6 +67,12 @@ def start_listeners_for_asf(event_source_mapping: Dict, lambda_service: LambdaSe
)
if self_managed_endpoints.get("KAFKA_BOOTSTRAP_SERVERS"):
service_type = "kafka"
elif not is_api_enabled(service_type):
Copy link
Member Author

Choose a reason for hiding this comment

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

did not add the this logic to the start_listeners as the function will be removed for v3

@@ -62,10 +63,15 @@ def run_log_loop(self, *args, **kwargs) -> None:
)

def start_subscriber(self) -> None:
if not is_api_enabled("logs"):
Copy link
Member Author

Choose a reason for hiding this comment

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

just preventing the thread start here. we can discuss if there are better approaches to handle this when logs are disabled.

Copy link

github-actions bot commented Nov 7, 2023

LocalStack Community integration with Pro

       2 files  ±0         2 suites  ±0   1h 25m 49s ⏱️ + 17m 38s
2 306 tests ±0  2 008 ✔️ ±0  298 💤 ±0  0 ±0 
2 307 runs  ±0  2 008 ✔️ ±0  299 💤 ±0  0 ±0 

Results for commit 46c2cc9. ± Comparison against base commit 9dc7713.

♻️ This comment has been updated with latest results.

@coveralls
Copy link

coveralls commented Nov 8, 2023

Coverage Status

coverage: 84.005%. remained the same
when pulling 46c2cc9 on strict_service_cw_logs
into 9dc7713 on master.

@steffyP steffyP marked this pull request as ready for review November 8, 2023 13:29
@steffyP steffyP requested review from bentsku and removed request for silv-io November 8, 2023 13:29
Copy link
Contributor

@bentsku bentsku left a comment

Choose a reason for hiding this comment

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

LGTM! This is awesome! Also, great catch for sts. 🚀

"es": ["opensearch"],
"lambda": ["logs", "cloudwatch", "s3", "sqs"],
"kinesis": ["dynamodb"],
"lambda": ["s3", "sqs", "sts"],
Copy link
Contributor

Choose a reason for hiding this comment

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

good catch! 👍

@steffyP steffyP force-pushed the strict_service_cw_logs branch from 7dad74e to 9353f57 Compare November 9, 2023 10:11
@steffyP steffyP added this to the 3.0 milestone Nov 13, 2023
@steffyP steffyP force-pushed the strict_service_cw_logs branch from 9353f57 to 46c2cc9 Compare November 13, 2023 09:08
Copy link
Member

@joe4dev joe4dev left a comment

Choose a reason for hiding this comment

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

This PR covers the basic Lambda scenarios 👍
It's gonna be tough to maintain these conditionals for many service combinations.

I tested the provided testing scenario with SERVICES=lambda and this PR fixes Lambda create-function, invoke, and (dummy) event source mapping (already create-function would fail without this PR) 👏👏👏 .

⚠️ I assume DLQs and success/failure destinations would fail with an exception in the event_manager.py 🤔 Would it provide some helpful logging output?

I guess one of the relevant scenarios for 3.0 is related to users who have set SERVICES since a long time before it got re-purposed. Obviously, any user code depending on other services within Lambda could fail somewhat implicitly but this likely falls under misconfiguration.

Out of the scope for this PR but I just wanted to comment on integrations to consider for ext:

  • X-Ray
  • and potentially ECR for pulling Lambda
  • IAM

@@ -40,6 +44,12 @@ def start_listeners_for_asf(event_source_mapping: Dict, lambda_service: LambdaSe
)
if self_managed_endpoints.get("KAFKA_BOOTSTRAP_SERVERS"):
service_type = "kafka"
elif not is_api_enabled(service_type):
LOG.info(
Copy link
Member

Choose a reason for hiding this comment

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

Is info sufficient here or should this rather be a warning given the functionality just does not work and it might be a misconfiguration?
Maybe the question is how often is it a misconfiguration vs. intentional disabling 🤷

Copy link
Member Author

Choose a reason for hiding this comment

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

IMO info should be fine, because it's impossible to pass a valid/existing source-arn here (otherwise the service would be available).

@steffyP
Copy link
Member Author

steffyP commented Nov 13, 2023

⚠️ I assume DLQs and success/failure destinations would fail with an exception in the event_manager.py 🤔 Would it provide some helpful logging output?

Generally for every access of a service that is disabled, we would throw a 501 error with the message Service '<service-name>' is not enabled. Please check your 'SERVICES' configuration variable.

I guess one of the relevant scenarios for 3.0 is related to users who have set SERVICES since a long time before it got re-purposed. Obviously, any user code depending on other services within Lambda could fail somewhat implicitly but this likely falls under misconfiguration.

Yes, they should run into issues quite fast though. We expect to get those kind of reports, for most customers removing the SERVICES will probably the most reasonable thing to do.
In general we will have more reactive approach for the usage of SERVICES as it's 1) impossible to test everything, and 2) we don't know yet how (or if) people will use it.

@steffyP steffyP merged commit d4933e0 into master Nov 13, 2023
@steffyP steffyP deleted the strict_service_cw_logs branch November 13, 2023 13:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver: patch Non-breaking changes which can be included in patch releases
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants