Skip to content
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

Open
lharzenetter opened this issue Nov 15, 2021 · 7 comments

Comments

@lharzenetter
Copy link
Member

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 the SOURCE_ prefix.

@wederbn
Copy link
Member

wederbn commented Feb 10, 2022

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.

@nyuuyn
Copy link
Contributor

nyuuyn commented Feb 10, 2022

The only "solution" would be to use a convention, e.g., search first the target stack than the source stack and so on.
However, this introduces in some cases more issues then it helps, expecially if we think about identical property names, such as, IP, Password, User and so forth.
The ambiguity of these properties makes defining conventions quite hard, that's why we came up with the idea of "SOURCE_" and "TARGET_" in the first place.

We could adopt the yaml feature of referencing properties directly for parameters, which would be more a configuration instead of a convention solution.

@lharzenetter
Copy link
Member Author

lharzenetter commented Feb 11, 2022

The yaml way is not possible in XML as you cannot map the inputs of an operation to properties directly.
However, yaml also uses the SOURCE and TARGET syntax to reference the corresponding Node Template - see here. Instead of using this syntax in the form of mapping the properties to the input parameters, we use this directly in the names of the input variables. The only thing we should check is how the properties are searched according to the standard if there is no direct mapping specified.

@nyuuyn
Copy link
Contributor

nyuuyn commented Feb 11, 2022

I can't find anything specific in the standard (1.3 or the upcoming 2.0) which talks about this. Did you find something?
They only talk about this a little in 2.0 at 4.4.12 but that only outputs what kind of mappings are allowed

@lharzenetter
Copy link
Member Author

I guess so:

4.2.2 Prefixed vs. Unprefixed TARGET names
The list target node types assigned to the TARGETS key in an execution environment would have names prefixed by unique IDs that distinguish different instances of a node in a running model Future drafts of this specification will show examples of how these names/IDs will be expressed.

4.2.2.1 Notes

  • Target of interest is always un-prefixed. Prefix is the target opaque ID. The IDs can be used to find the environment var. for the corresponding target. Need an example here.
  • If you have one node that contains multiple targets this would also be used (add or remove target operations would also use this you would get set of all current targets).

https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.html#_Toc26969452

@nyuuyn
Copy link
Contributor

nyuuyn commented Feb 11, 2022

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?

@lharzenetter
Copy link
Member Author

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.

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

No branches or pull requests

3 participants