-
Type:
New Feature
-
Status: Deferred
-
Priority:
Critical
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: Spec
-
Labels:None
-
Proposal:
-
Resolution:
Node types provide interfaces the operations of which represent its local management behavior. But our goal is to enable management of a service template "globally", i.e. to specify management actions that are composed of operations of the individual node templates (and their instances). For this purpose an API is need that allows access to the instances of service templates, the instances of node templates and relationship templates as well as access to the service definition. Such a standardized API is need that allows to specify global management behavior in a portable manner. In the cloud domain, APIs are typically build following the REST architectural style, i.e. this API should be a REST-based API
1.
|
"Real-Time" Topology Updates for Boundary Systems |
|
Deferred | Unassigned |
Yes, the plans are considered to be the management API for the cloud service itself, while the node type interfaces are the "local" management APIs for the ingredients of the cloud service.
The issue at hand has nothing to do with standardizing management APIs for cloud services. The issue is that we need access to instance information about the ingredients of such an cloud service. For example, you need the actual IP address of the DBMS a particular app server is connected to. For this purpose, we need an API that allows you to navigate the "connected_to" relationship template originating from the instance of the AppServer node template to the instance of the DBMS node template.
This is the initial draft of the portability API proposed to resolve TOSCA Issue 24:
https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/46381
Note explicitly, that this draft version of the API does not reflect the latest changes of the TOSCA language (metamodel) resulting from other TOSCA issues; thus, the API will have to be adopted as the TOSCA language evolves.
The following presentation describes why a Plan Portability API is required for TOSCA:
https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/46756
An Ad Hoc committee was formed to investigate, and will work using this JIRA issue as central tracking/commenting mechanism. All TC members are free to participate. Please contact the co-leaders, Tobias Kunze and Frank Leymann, if you wish to join in.
Deliverables:
A) Recommendation to TC as to whether this belongs in v1.0 or v.next.
B) Develop the proposal into a concrete spec change, if deemed appropriate to use the cycles now.
Changing title to be more accurate.
I uploaded a presentation summarizing the Plan Portability API draft. It's more efficient to look at slides than scrolling jointly through the document. Here is the link:
https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/49559
The draft TOSCA Plan Portability API reflects an earlier variant of version 1 of the TOSCA specification: an update of the API spec must reflect the latest work towards TOSCA version 2. Also, the current draft is very much geared towards an imperative style of processing service templates while the actual work in the TC is more focussed on a declarative style: this focus should be reflected in the API. Finally, the Simple Profile strives towards faster adoption of TOSCA by other communities, especially by Openstack. The following document should stimulate a discussion within the TC about if, when and how to revitalize work on the API:
https://www.oasis-open.org/apps/org/workgroup/tosca/download.php/53671
In my opinion, the plans define the management API for the service template. The "build" and the "remove" plans are two examples, and are included in the SPEC.
The other plans (or APIs) for operation and management (O&M) are hard to standardize because different apps have different O&M policies.
On the other side, I think the REST style is not mandate. For example, SOAP style is available as well. Furthermore, if the implementArtifact are all provided in an package (e.g. CSAR), the script style is also OK.