Skip to content

resource/remote: handle unknown resource - #1959

Open
Svendsen991 wants to merge 1 commit into
labgrid-project:masterfrom
Svendsen991:remote/invalid-resource
Open

resource/remote: handle unknown resource#1959
Svendsen991 wants to merge 1 commit into
labgrid-project:masterfrom
Svendsen991:remote/invalid-resource

Conversation

@Svendsen991

@Svendsen991 Svendsen991 commented Aug 21, 2026

Copy link
Copy Markdown

Description

Instead of failing to create a RemotePlaceManager print out a warning on unknown remote resources and continue.

This will allow use of standard tools like labgrid-client's console together with a remote place where some of its resources are unknown/custom.

This will add value for projects using not yet upstreamed resources or if they're simply too custom for upstream. So useful labgrid-client tools can still be used without any workarounds.

Current workaround is importing labgrid client main in custom project where the custom resources are registered and create custom command to run labgrid-client.

Checklist

  • PR has been tested locally

It was tested by adding an unknown resource to an exporter and adding it to a place with a serial connection like

# Exporter yaml
DUT-X:
  linux:
    cls: 'USBSerialPort'
    match:
      ID_PATH: 'X'
    speed: 115200
  wifi:
    cls: 'WifiService'
    address: 'x'
    username: 'root'
    ssid: 'ssidX'

@Svendsen991
resource/remote: handle unknown resource
a98a801 
Instead of failing to create a RemotePlaceManager print out a warning on
unknown remote resources and continue.

This will allow use of standard tools like labgrid-client's console
together with a remote place where some of its resources are
unknown/custom.

Signed-off-by: Emil Svendsen <emas@bang-olufsen.dk>
@Svendsen991
Svendsen991 force-pushed the remote/invalid-resource branch from 6d0df0a to a98a801 Compare August 21, 2026 12:22
@jluebbe

jluebbe commented Aug 26, 2026

Copy link
Copy Markdown
Member

This would mean that if you run the same testsuite in different environments (perhaps some outdated and missing new drivers), you'd just get a warning and then surprising errors when it tries to bind the drivers.

So, I don't think simply warning and continuing there is a viable approach.

@Svendsen991

Svendsen991 commented Aug 27, 2026

Copy link
Copy Markdown
Author

This would mean that if you run the same testsuite in different environments (perhaps some outdated and missing new drivers), you'd just get a warning and then surprising errors when it tries to bind the drivers.

So, I don't think simply warning and continuing there is a viable approach.

In an outdated environment. The most normal case where only new resources has been added. It should still work as expected.
If you modify or delete resources in your coordinator you can get surprising errors regardless and it's not guaranteed to be in the remote on_resource_added anyway.

Also I see these possible errors[1]? And I find them as informative if not more than InvalidConfigError(f"unknown resource class {resource}").

[1]
When cls is a string
https://github.com/labgrid-project/labgrid/blob/master/labgrid/target.py#L123
https://github.com/labgrid-project/labgrid/blob/master/labgrid/factory.py#L166

raise KeyError(f"No driver/resource/protocol of type '{string}' in factory, perhaps not registered?")

When having access to cls (I guess here it will not be outdated because you have access to the class)
https://github.com/labgrid-project/labgrid/blob/master/labgrid/target.py#L147

raise NoResourceFoundError(
     f"no {cls.__name__} resource{name_msg} found in {self}"
)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

enhancement

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@Svendsen991 @jluebbe @Bastian-Krause