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-115) Requirements Capabilities to provide interfaces


    [ http://tools.oasis-open.org/issues/browse/TOSCA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33936#action_33936 ] 

Travis Tripp commented on TOSCA-115:
------------------------------------

I'm not sure if this belongs on this issue or should be raised separately because I believe it applies to Node Types as well. However, there either needs to be a way to specify whether an interface / operation should be executed by the engine or we need to specify that all operation implementations needs to be idempotent if they are called inappropriately.

For example, if I have a VM image the includes Apache and whether I have an Apache Node Type or an Apache Capability that has an interface / operation the does installation, then either the engine needs to be able to deduce if install should be executed or the script should check to see if Apache is already installed before installing.  

Or is this assumed to be handled by Type Implementations, where you'd use one implementation in the case where it is pre-installed and an alternate implementation where you don't need to install it.

> Requirements Capabilities to provide interfaces
> -----------------------------------------------
>
>                 Key: TOSCA-115
>                 URL: http://tools.oasis-open.org/issues/browse/TOSCA-115
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: New Feature
>    Affects Versions: V1.1_CSD01
>            Reporter: Kevin Wilson
>
> Requirements and capabilities should provide specific interface definitions. So that the designer of a app can depend on a contract set of public properties that are to be provided and a contracted set method/interfaces that are provided by the requirement. 
> For example:
> If I have a dependency on a DB Server, and need to run SQL on that server, at design time, I would like to know the methods supported by the DBServer requirement so that I can leverage that in my component scripting. 
> On the implementation side providing the component, the script/method to execute the script may be different for each DBServer type. IE commands to run SQL on MySQL are not the same commands that would be used for Oracle. However, the SQL may the same in some cases. 
> Similar methods/use cases exist for J2EE server deploy methods etc. 
> By providing a interface on the Requirement/Capability we can leverage the workflows specific to the capability in a generic way. And the designer would be able to identify the contracted calls that are made available.
> https://www.oasis-open.org/apps/org/workgroup/tosca/document.php?document_id=49635 

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