-
Notifications
You must be signed in to change notification settings - Fork 29
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
Autoamtically Search Source-Stack While Whecking for ConnectTo Parameters #220
Comments
Currently, we search for parameters without prefix at the second node where the connects to operation is NOT defined. That means, sometimes that could be the SOURCE and sometimes the TARGET node of the connects to. However, I guess that is intended as we assume that in most cases we need information (endpoints, etc.) from the other side of the connects to relation. So, I´m not sure if we should change that. What do you think @nyuuyn ? See here. |
The only "solution" would be to use a convention, e.g., search first the target stack than the source stack and so on. We could adopt the yaml feature of referencing properties directly for parameters, which would be more a configuration instead of a convention solution. |
The yaml way is not possible in XML as you cannot map the inputs of an operation to properties directly. |
I can't find anything specific in the standard (1.3 or the upcoming 2.0) which talks about this. Did you find something? |
I guess so:
|
If I understand it correctly according to the whole section we can only use properties of the source and target node(s), not the nodes they are hosted on, e.g., the IP of the underlying infrastructure right? |
No, I read it like the whole target stack is meant because otherwise nothing would work if you have an IP-address defined at a VM and you connect to an application hosted on this VM. |
Current Behavior:
Currently, you must prefix a source param with
SOURCE_
to enable the plan builder to find the corresponding parameter automatically without explicitly specifying theSOURCE_
prefix.The text was updated successfully, but these errors were encountered: