[Lambda DevX] Support for Config Hot Reloading #11477
Conversation
| while True: | ||
| time.sleep(1) | ||
| epoch_last_modified = self._config_file_epoch_last_modified_or_now() | ||
| if epoch_last_modified > epoch_last_loaded: | ||
| epoch_last_loaded = epoch_last_modified | ||
| self._load_lambda_debug_mode_config() |
There was a problem hiding this comment.
I am not a fan of this endless loops, even though the thread is a daemon thread. I would prefer an orderly shutdown of the thread, by using an stopping event as loop condition, and shutting it down on shutdown of the lambda service.
There was a problem hiding this comment.
changed to SERVICE_PLUGINS.is_running("lambda"), and also synched the start to the starts of the lambda provider
| self._watch_thread = Thread( | ||
| target=self._watch_logic, args=(), daemon=True, name="LambdaDebugModeConfigWatch" | ||
| ) | ||
| TMP_THREADS.append(self._watch_thread) |
There was a problem hiding this comment.
Appending it to TMP_THREADS accomplishes nothing here, as it is unstoppable.
Instead, as seen in the other comment, I would prefer shutting it down when the lambda service shuts down.
| @@ -75,7 +76,10 @@ def get_environment( | |||
|
|
|||
| try: | |||
| yield execution_environment | |||
| execution_environment.release() | |||
| if is_lambda_debug_timeout_enabled_for(lambda_arn=function_version.qualified_arn): | |||
| self.stop_environment(execution_environment) | |||
There was a problem hiding this comment.
Is this something the users expect? This would effectively stop the possibility of leaving the debugger attached for multiple invocations, which should be theoretically possible currently, right?
Does it make sense, maybe, to only stop the environment if something actually changed for it?
There was a problem hiding this comment.
Leaving the debugger attached is definitely the behaviour we envision. However, this is not an experience we can offer consistently at the moment. I cannot get this to work for python for example. Currently it is impossible to debug a lambda function more than once.
I am of the idea of providing this behaviour to unblock, whilst we continue the work on integrating more tightly the Lambda Debug Mode and the debuggers. What do you think?
There was a problem hiding this comment.
That is fine by me, let's keep it as a temporary workaround!
| @@ -75,7 +76,10 @@ def get_environment( | |||
|
|
|||
| try: | |||
| yield execution_environment | |||
| execution_environment.release() | |||
| if is_lambda_debug_timeout_enabled_for(lambda_arn=function_version.qualified_arn): | |||
| self.stop_environment(execution_environment) | |||
There was a problem hiding this comment.
That is fine by me, let's keep it as a temporary workaround!
| self._initialised_event.set() | ||
|
|
||
| # Monitor for file changes whilst the lambda service is running. | ||
| while SERVICE_PLUGINS.is_running("lambda"): |
There was a problem hiding this comment.
Not too happy with this here. could we have an internal shutdown / running state (for example a threading Event) which is checked here, and call stop() triggering the event in on_before_stop, just as we do the ensure_running now?
Motivation
Currently the configuration for Lambda Debug Mode is loaded on startup and cannot be changed until the next restart of LocalStack. This may not only be inconvenient whenever changes to the configuration may be required after startup, but also means that it is impossible for the user to provide configurations for Lambda functions for which the arn is unknown before startup. Such scenario may occur when using dynamic naming in cloud formation. Hence, these changes add initial support for the hot reloading of the Lambda Debug Mode configuration file. This is achieved by updating the config when changes are detected in the file, and stopping a lambda container after evaluation iff this is being debugged. Stopping the container after evaluation is encouraged by the difficulty/feasibility or reconfiguring the container (consider ports), and has the added benefit of unblocking the scenario of debugging the same lambda function more than once.
Changes
Testing
As the development of a testing stack for Lambdas debugging is being developed, I refer to manual testing using the Lambda Debug Mode sampled provided here: localstack-samples/localstack-pro-samples#253