-p/--place is silently ignored by acquire/release when -c env.yaml is also given

[hornmich]

Issue: -p/--place is silently ignored by acquire/release when -c env.yaml is also given

Summary

Since commit a9b59e4e ("remote/client: make acquire/release operate on all RemotePlaces in env"), invoking labgrid-client with both -c env.yaml and -p NAME silently ignores -p and operates on every RemotePlace in the env config. There is no way for the user to opt out of the env-wide behavior without dropping -c entirely.

Affected version

• master at commit a9b59e4e and later.

Reproducer

Coordinator with three empty places test-place-1, test-place-2, test-place-3.

multi.yaml:

targets:
  main:
    resources:
      RemotePlace:
        name: test-place-1
  second:
    resources:
      RemotePlace:
        name: test-place-2
  third:
    resources:
      RemotePlace:
        name: test-place-3

$ labgrid-client -c multi.yaml -p test-place-2 acquire
Selected role second from configuration file
acquired place test-place-1
acquired place test-place-2
acquired place test-place-3

$ labgrid-client who
User     Host     Place         Changed
labgrid  labgrid  test-place-1  ...
labgrid  labgrid  test-place-2  ...
labgrid  labgrid  test-place-3  ...

Expected: only test-place-2 acquired.
Actual: all three places acquired; the -p test-place-2 argument has no effect on which places are touched. release exhibits the same behavior.

Root cause

labgrid/remote/client.py:

async def acquire(self):
    errors = []
    places = self.get_place_names_from_env() if self.env else [self.args.place]
    for place in places:
        ...

Impact

• CI pipelines and ad-hoc users that historically used labgrid-client -c env.yaml -p NAME acquire (a documented and idiomatic combination prior to a9b59e4e) silently acquire every place in the env, contending with other users / pipelines and locking resources that should remain free.
• The behavior change is silent: -p is parsed and even printed (Selected role second from configuration file), suggesting it took effect. There is no warning or error.

Expected behavior

When the user explicitly supplies a place via -p/--place, LG_PLACE, or the legacy PLACE env var, acquire/release should operate on that single place only, even if -c env.yaml is also provided.

Proposed fix

Patch attached.

0001-remote-client-let-p-restrict-env-wide-acquire-releas.patch

[jluebbe]

Yes, the log message should be fixed.

But: why would you only acquire a subset of the places needed by the test environment? If the test environment is not "complete", how can you run the testsuite correctly?

[hornmich]

Our CI/CD setup evolved historically. It could perhaps have been designed differently, but there were practical reasons for the current approach.

The devices in our environment differ in architecture, hardware configuration, and performance characteristics. As a result, some tests may complete much sooner than others, or fail quickly. By handling devices individually, the pipeline can release a device as soon as it is no longer needed, allowing another job — potentially from a different PR — to acquire it and continue testing.

In other words, we intentionally managed each device independently to achieve higher CI throughput while still using a shared environment file. This approach worked well until we started using the latest master version of Labgrid.

In my opinion, the API behaviour should make the intention explicit. If -p has no effect when used together with -c, then these options should probably be mutually exclusive. More importantly, however, I believe there is no harm in allowing users to opt out by handling -p in this case, as it preserves the existing full-environment acquisition behaviour for users who rely on it.