Skip to content

Accessing Other Dependent Resources for a Managed Dependent Resource #964

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

Closed
csviri opened this issue Feb 22, 2022 · 4 comments · Fixed by #979
Closed

Accessing Other Dependent Resources for a Managed Dependent Resource #964

csviri opened this issue Feb 22, 2022 · 4 comments · Fixed by #979

Comments

@csviri
Copy link
Collaborator

csviri commented Feb 22, 2022

The purpose of the issue to prepare and discuss a design and implementation, regarding how Dependent Resource might access other dependent resources in managed mode.

Problem statement

Dependent Resources are not independent of each other, it's a common usecase to use output or generally speaking data from other dependent resources. In standalone mode, when dependent resources created manually reference to an other dependent resource can be passed when dependent resource is created. For managed mode this is more problematic, since those are instantiated and managed by the system. But should have access to other dependent resources.

Proposed Solution

A way would be to inject the other managed dependent resources. (Eventually the plan is to allow to describe most of the workflows with dependent resources), making this available via an interface:

public interface ManagedDependentResource {

void setDependentResourceContext(DependentResourceContext context)

}

Where the DependentResourceContext will contain a list of managed dependent resources.

Notes:

@metacosm
Copy link
Collaborator

Note that you can already pass information around using the Context object but it might be interesting to make things a little bit more structured, indeed.

@csviri
Copy link
Collaborator Author

csviri commented Feb 22, 2022

yes, would like to remove generic map from context eventually if possible.

@metacosm
Copy link
Collaborator

yes, would like to remove generic map from context eventually if possible.

Out of curiosity: why? This provides a way for users to pass information around without the SDK having to know about it.

@csviri
Copy link
Collaborator Author

csviri commented Feb 23, 2022

I meant that, it might be eventually not needed or necessary to have. But we will see.

@csviri csviri self-assigned this Mar 1, 2022
@csviri csviri closed this as completed Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants