[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (TOSCA-229) Requirements / target filters and subsituable / selectable are too confusing.
[ https://issues.oasis-open.org/browse/TOSCA-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=59195#comment-59195 ]
Matthew Rutkowski edited comment on TOSCA-229 at 3/19/15 1:55 PM:
-------------------------------------------------------------------
Hi Luc,
Let me share my thoughts for the ideas you have.
1) I am open to looking at use cases for having the target-filter in the Node Type if there is a compelling use case; however, the editors have agreed that for a proper meta-model it really should only be in the Node Template which I agree with as it would greatly complicate the validation of type-matching as Node Types get subclassed if for no other reason.
2)
was (Author: mrutkows):
Hi Luc,
Let me share my thoughts for the ideas you have.
Edit
Comment
Assign
More
Open Issue
Close Issue
Defer
Export
Details
Type: Improvement Improvement
Status: New
Priority: Major Major
Resolution: Unresolved
Affects Version/s: None
Fix Version/s: None
Component/s: Profile-YAML, (1)
Spec - Simple Profile
Labels:
None
Proposal:
So in my opinion we should:
- Move target_filters to the node type's requirement section as it make sense here: I create a reusable implementation of a MySQL that is based on sh scripts so I want to be able to specify the host requirement to specify that the os type is linux.
- Remove target_filters from the node templates requirement section.
- Remove the directives and keep only an abstract keyword that is false by default (or substitutable if abstract is not clear enough). I don't seen the need for directives right now, a single substitutable seems to do the job and is quite simpler in my opinion.
- Make Compute node abstract (or substituable) - same as block storage or other IaaS components.
Note that a type may be abstract too and not just a node template. I don't see the scenario of a Compute node that is not selectable somehow as this is instantiated on the cloud... For me Compute node is by definition an abstract node that is substitutable and the orchestrator should find a valid match to instantiate a VM with the right required contraints or find a real machine if bare-metal is supported by the orchestrator.
- Use the substitution mechanism for both substitution and selectable in a topology. The orchestrator implementation is responsible for providing the valid mechanisms to put in front.
At the end that leaves the TOSCA user with only 2 notions and use cases which is much simpler to explain and understand and leaves also in my opinion more flexibility both to users and implementors.
- On a type - or substituable type (that defines a reusable entity) I can specify requirements with target_filters to make sure that when someone reuse my entity it will be a compliant usage based on my nodes real requirements.
- In a topology template every node that the orchestrator must provide (by offering selection or automatic best-match or both -- specific to implementation and vendor) must be defined as an abstract (or substitutable) node.
PS: I'm really sorry I was not able to make it to the tuesday call as I know I come a bit late with my points but still hope this is makes sense for you too.
Description
There is too many notions in the requirements management in the current simple profile document. This makes things very hard to follow while there is actually in my opinion not that many notions to be defined.
Target filter makes no sense in my opinion in their current placement (on the node template requirements) as they are duplicated with the selectable directive.
I think it would be more consistent to use the 'selectable' directive in every situations rather than relying on target_filter.
I also think that selectable pattern is also exactly the same as substitutable from a user perspective as this answer a single need:
- I want to link some components to a node that is abstract and I rely on the orchestrator tool to provide a node that match my requirement.
The fact that the orchestrator provides a selectable or automatic (substitutable) matching (or both with a best-match) is a tool feature and has no place in the specification in my opinion. The matching and quality of matching feature and presentation of the feature is implementor specific.
Activity
All
Comments
History
Activity
Matthew Rutkowski added a comment - Yesterday 8:29 AM
I understand this sentiment and have been advocating for simplifying the requirement definition as I have been struggling to do going back to last November. Once we determined that an "abstract node" (i.e., a "selectable" node) was needed (in order to produce models where the other nodes actually had some placeholder to point to) which you would NOT have with a dangling requirement, I thought let me rewrite all the spec.'s use cases in this way... and I did. However, during the same period I was participating in the Container work group and it became apparent that there are MANY cases where the template (application) author has a paradigm where they simply want to describe their app (Containee) and a few requirements for their host (Container) and it would feel unnatural and awkward for them to actually be forced to create a "selectable" node. Since then, I have seen this point of view repeated at the SoftwareComponent (Containee) to Compute node (Container) level as well. That is, I want to describe my application and a few properties for the guest image or memory and not be forced to model the actual Compute node every time (in fact this was in one of our earliest use cases).
The same argument could be made for Database as well (and a reality with Trove in OpenStack).
Needless to say, over the last few weeks, I have become quite accepting that template/app authors SHOULD have a choice of either describing their abstract requirements within their application node(s) using a target_filter <or> be able to do so using an abstract node (also using the same target_filter). Then we can show how both can be seamlessly made equivalent/interchangeable when needed and hope I have shown this initially in the WD05, Rev9 YAML spec. in section 11 by adding section 11.1 "Alternative using a node template".
Chris Lauwers added a comment - Yesterday 10:55 PM
I agree with Matt. I think there sometimes is value in supporting different mechanisms to express the same thing, since each mechanism may be more convenient than the others for different use cases.
That said, I believe it might be possible to avoid confusion by making the grammar for these mechanisms more similar. Specifically, I would argue the following:
1. target_filter should be renamed to node_filter to reflect what it actually does (in fact, the supporting prose in the document already refers to target_filter as node filters)
2. in a requirement assignment, I would like to see target_filter/node_filter be a sub-keyname of the node keyname (rather than a top-level keyname in the requirement assignment) since that would make the grammar for nodes in a requirement assignment (almost) identical to the grammar for selectable node templates.
I would love to understand better how we can further harmonize selectable and substitutable node templates
Luc Boutier added a comment - Today 4:46 AM
Well I can understand the need, thanks for the clarification. Not a big fan but that's personal ;)
1) I am open to looking at use cases for having the target-filter in the Node Type if there is a compelling use case; however, the editors have agreed that for a proper meta-model it really should only be in the Node Template which I agree with as it would greatly complicate the validation of type-matching as Node Types get subclassed if for no other reason.
2)
> Requirements / target filters and subsituable / selectable are too confusing.
> -----------------------------------------------------------------------------
>
> Key: TOSCA-229
> URL: https://issues.oasis-open.org/browse/TOSCA-229
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: Improvement
> Components: Profile-YAML, Spec - Simple Profile
> Reporter: Luc Boutier
>
> There is too many notions in the requirements management in the current simple profile document. This makes things very hard to follow while there is actually in my opinion not that many notions to be defined.
> Target filter makes no sense in my opinion in their current placement (on the node template requirements) as they are duplicated with the selectable directive.
> I think it would be more consistent to use the 'selectable' directive in every situations rather than relying on target_filter.
> I also think that selectable pattern is also exactly the same as substitutable from a user perspective as this answer a single need:
> - I want to link some components to a node that is abstract and I rely on the orchestrator tool to provide a node that match my requirement.
> The fact that the orchestrator provides a selectable or automatic (substitutable) matching (or both with a best-match) is a tool feature and has no place in the specification in my opinion. The matching and quality of matching feature and presentation of the feature is implementor specific.
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]