-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
add container configurators for bootstrapping localstack #9050
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
Conversation
c84d121
to
55bbc11
Compare
7617c1f
to
06472e7
Compare
06472e7
to
c8cb194
Compare
testfailures are unrelated to the changes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a great set of changes. Just some minor nits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, love the new configuration options and used patterns!
5346793
to
fcac5b7
Compare
Motivation
With the new
Container
concept and theContainerFactory
fixture introduced in #8781, we now want an easy and re-usable way to configure containers. For instance, to test extensions, I always want to create a fresh localstack pro container with certain default configurations. The code doing the configuration should ideally be re-usable, have high-level concepts of the localstack container (such as "mount the localstack volume directory", "set gateway listen correctly"), while allowing fine-grained configuration of containers.In #8994 I introduced a concept that is inspired by the Functional Options Pattern from go. I evolved this into a basic set of configurators that are typical for localstack.
This gives a very neat way of configuring the container together with the container factory, where you can see exactly what configurations are being added to the container:
Furthermore, I wanted a way to stream container logs when running container tests, so I added a fixture that can be used as follows:
This creates a new background thread that will stream the logs of the container into a logger called
container.<container-name>
.Changes
ContainerConfigurator
conceptContainer
aware of these configuratorsconfigure_container
method used by the CLI to use these configuratorsContainer
VolumeMappings.add
instead ofappend
so we can maybe get rid of one of the functionsTODO