Skip to content

[Proposal] Allow configuring request timeout per plugin instead of using a single global timeout #287

Description

@Andreagit97

Today, NRI uses a single global request timeout for all plugins

func getPluginRequestTimeout() time.Duration {

This works well when all plugins have similar latency characteristics, but it becomes limiting when one plugin legitimately needs a longer timeout while the rest should keep a shorter and stricter one.

In our use case, we never hit the 2-second default timeout, but there is the risk that a slow run could hit it in production, causing the plugin to be detached. We would prefer to run with more margin (e.g., 5/10 seconds). We could force users to change the containerd config to raise the timeout for all the plugins, but it seems a little bit invasive.

It would be nice to let the plugin specify its own timeout (maybe checking it is below a reasonable upper bound (60/120sec)) so that users have a solution out of the box without changing the global config.

Would it make sense to support a per-plugin request timeout, with the current global timeout kept as the default/fallback?

If this sounds acceptable, I’d be happy to help further refine the proposal.

This is slightly related to #114, but it doesn't propose the same thing

Note

For our use case, bumping the default timeout to 5/10s could be a solution as well, but it would be nice to find a generic solution for everyone

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions