[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-87) Use Case: Specifying additional constraints / preferences when selecting target resources (Nodes) (e.g. prefer a specific Firewall)
[ http://tools.oasis-open.org/issues/browse/TOSCA-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33595#action_33595 ]
Aaron Zhang commented on TOSCA-87:
----------------------------------
After thinking over on this issue, I believe that we don't need any extension to TOSCA in order to resolve this issue.
In TOSCA, a NodeTemplate can exposes requirements to the lower layer node, the Requirements are expressed as properties; The straightforward way is to define a property, say unTrustResource, or more specific, unTrustFirewall, and when TOSCA container looks for lower level node resources, it will abandon those that are in the untrust list.
Further question is, whether it's necessary to define a set of properties with defined semantics for a Requirement. (This's is real interoperability to me).
> Use Case: Specifying additional constraints / preferences when selecting target resources (Nodes) (e.g. prefer a specific Firewall)
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: TOSCA-87
> URL: http://tools.oasis-open.org/issues/browse/TOSCA-87
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: Task
> Components: Interop
> Environment: Use case for development against TOSCA-v1.0-cs01.
> Reporter: Matthew Rutkowski
> Assignee: Aaron Zhang
>
> How does a service template designer provide additional "constraints" to the provider deploying the template in order to convey preference of certain node types (or resources) over another.
> Example:
> A service template declares its need for a Firewall node, but prefers type AAA over type XXX due to reliability.
> Notes:
> Aaron: High Level Suggestion: Extend TOSCA NodeTemplate/NodeType to support specifying additional conditions for target VM resources.
> Options:
> a) Let the deployer specify/recommends the firewall(s) he trusts
> b) Let the deployer specify the firewall(s) he doesn't trust.
> Matt: Perhaps an alternative use case using an artifact type to allow desire for matching to a specific Java runtime (provider, version) over another. Could these be constraints expressed as Reg. Exp. against node or artifact properties?
> Reference:
> https://www.oasis-open.org/apps/org/workgroup/tosca-interop/download.php/48504/New%20Scenarios%20for%20TOSCA%20from%20Huawei.pptx
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]