[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] Follow up on the boundary definition section
Hi Luca, Could we model these “external components” just like all other nodes in the service template, but with a different interface? Instead of using the standard lifecycle
management interface that creates/instantiates node templates, we could introduce a different interface that “connects to” the external component with the goal of managing it as necessary for the service.
The same concept could also be used for multi-tenant services where we don’t necessarily need to instantiate a new service, but rather we would have to create
a new tenant on an existing (multi-tenant) service. Chris From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Luca Gioppo I have some more use cases for the need of a boundary definition section.
The goal here is to have a place at ServiceTemplate level to express the needs for external components in the orchestrator environment:
USE CASE The Service descried in the TOSCA file REQUIRE the presence of a monitoring system or of a backup system or a devops system
If the requirement is not met than the orchestrator needs to follow the disposition of the requirement
The proposed modeling is as follows: boundary_definitions: This will solve some needs coming from the monitoring but also from other generic components.
Other generic environment could be: - DNS - schedulers - central LDAP - any centralized system that the service will not deploy but will use
The modeling proposed allows to presen some use cases for some of the most immedate examples and to leave implementors open path in adding value added features to the orchestrator since those are the ones that could make customers choose
one in place of another. Luca |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]