OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[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=33740#action_33740 ] 

Frank Leymann  commented on TOSCA-87:
-------------------------------------

@Travis

The intend of policies is to allow the specification of QoS, of non-functional behavior.  A Policy Type is associated with a Node Type by means of the AppliesTo element nested in a Policy Type. This allows a cloud provider, for example, to state that the implementation of a Node Type he provides may show some specific non-functional behavior, i.e. the Node Types themselves don't specify such QoS, such behavior.  Thus, associating Policy Types with Node Types is an announcement that implementations of such Node Types are ready to support particular behavior. 

The definition that instances of Node Types are required to show a particular behavior is made at the Node Template level.  The Policy that is specified at a Node Template must be enforced by the TOSCA container.  Thus, the container will typically perform matchmaking to ensure enforcement. 

I think it's a matter of taste whether or not QoS or non-functional properties could be expressed as requirements or capabilities. I am not aware that anybody in the TC implements Policies already.  Thus, we should rectify this concept. 

> 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]