Skip to content

Fix EC2 default security group creation when no tags are provided - #487

Open
justinokamoto wants to merge 3 commits into
dask:mainfrom
justinokamoto:main
Open

justinokamoto wants to merge 3 commits into
dask:mainfrom
justinokamoto:main

Conversation

@justinokamoto

Copy link
Copy Markdown

PR #471 (#471) added a required tags parameter to create_default_security_group to support tagging resources at creation time. However, it introduced two bugs:

  1. The call site in get_security_group was not updated to pass tags, causing a TypeError at runtime whenever EC2Cluster tried to create a default security group:

    TypeError: create_default_security_group() missing 1 required
    positional argument: 'tags'

  2. Even after passing tags=None, the TagSpecifications list was always included in the CreateSecurityGroup API call — even when the resulting Tags list was empty. AWS rejects this with:

    InvalidParameterValue: Tag specification must have at least one tag

Fix 1: Pass tags=None from get_security_group to create_default_security_group, since get_security_group has no tags of its own to forward (callers that do, like ECS, pass tags directly and are unaffected).

Fix 2: Only include TagSpecifications in the API call when there is at least one non-empty tag to attach.

PR dask#471 (dask#471) added a
required `tags` parameter to `create_default_security_group` to support
tagging resources at creation time. However, it introduced two bugs:

1. The call site in `get_security_group` was not updated to pass `tags`,
   causing a `TypeError` at runtime whenever EC2Cluster tried to create
   a default security group:

     TypeError: create_default_security_group() missing 1 required
     positional argument: 'tags'

2. Even after passing `tags=None`, the `TagSpecifications` list was
   always included in the `CreateSecurityGroup` API call — even when the
   resulting `Tags` list was empty. AWS rejects this with:

     InvalidParameterValue: Tag specification must have at least one tag

Fix 1: Pass `tags=None` from `get_security_group` to
`create_default_security_group`, since `get_security_group` has no tags
of its own to forward (callers that do, like ECS, pass tags directly and
are unaffected).

Fix 2: Only include `TagSpecifications` in the API call when there is at
least one non-empty tag to attach.
Test collection fails under pytest 9 with:

  Failed: Marks cannot be applied to fixtures.
  See docs: https://docs.pytest.org/en/stable/deprecations.html#applying-a-mark-to-a-fixture-function

Several fixtures were decorated with `@pytest.mark.external`. pytest has
never applied marks on fixtures to the tests that use them (see
pytest-dev/pytest#3664), so these marks were
silent no-ops. pytest 7.4 started emitting a deprecation warning for
this, and pytest 9.0 turned it into a hard error. The CI environments
install pytest unpinned, so they picked up the new behavior.

Because the marks were no-ops, the conftest `--create-external-resources`
gate never applied to tests that only got the mark through a fixture.
Those tests were skipped only at runtime by `skip_without_credentials`.

Remove the marks from the fixtures and put `@pytest.mark.external` on
the tests that use them, where it was missing. This matches the pattern
already used in the Nebius and DigitalOcean tests, and makes the
external-resource gate work as intended.
@justinokamoto

justinokamoto commented Oct 8, 2026 •

Copy link
Copy Markdown
Author

Including unrelated test fixes so CI passes. Problem was CI doesn't pin pytest and eventually picked up pytest 9.0 which errors when fixtures are marked with @pytest.mark.external (previously it was a no-op). See b7570b9 commit message for details.

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 this pull request may close these issues.

1 participant