Skip to content
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

Drop support for Localstack < v0.11.0 #37

Open
jtdoepke opened this issue Sep 24, 2020 · 0 comments · May be fixed by #48
Open

Drop support for Localstack < v0.11.0 #37

jtdoepke opened this issue Sep 24, 2020 · 0 comments · May be fixed by #48

Comments

@jtdoepke
Copy link
Contributor

jtdoepke commented Sep 24, 2020

Starting in Localstack v0.11.0, all services are exposed through a single port (4566). In v0.11.6 (not release yet as of this writing) services will be exposed only through that port. We should drop support for Localstack < v0.11.0 and make a new major version release of pytest-localstack.

Why

Compatibility with Localstack will break if we don't. Also we will no longer have to maintain a list of services and default ports in constants.py. When new services are added to Localstack, we won't have to release a new version of pytest-localstack to add support for them.

How

API

  • pytest_localstack.patch_fixture(services=None): Launch Localstack with all services running. Stays the same. We no longer have to pass a default list of services to the container.
  • pytest_localstack.patch_fixture(services=["A", "B", "C"]): Launch Localstack running services A, B, and C. Stays the same. They will use the new default port 4566. We will pass the service names as given to Localstack and assume the user knows what they want.
  • pytest_localstack.patch_fixture(services={"A": 12345}): Launch Localstack with service A running on port 12345. Drop this.

Health checks

Custom health checks are used in pytest-localstack to check that services are ready to receive traffic before the tests start. Starting in Localstack v0.10.8, a health check endpoint was added at /health. Replace our health checks with a request to that endpoint.

Patching existing clients

Since we're making a breaking change anyway, consider dropping support for patching pre-existing botocore/boto3 clients/resources. The code for that is really hard to maintain and breaks whenever AWS makes a significant change to the botocore internals. Take a look at how moto does patching.

@jtdoepke jtdoepke linked a pull request Jun 7, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant