I think there is already something in the spec about the not implemented create operation that I mentionned ; Not sure how detailed this is however.
And yes definitly it should be explained in the spec as this is required for someone to build a valid TOSCA topology refering to services (and this is a real need for many scenarios). I think that more details should be provided on implementation guides or examples/validation examples to be built in the interop TC.
Luc
De : Chris Lauwers [mailto:lauwers@ubicity.co
> Envoyé : jeudi 1 octobre 2015 07:08
> À : Luc Boutier <luc@fastconnect.fr>; 'Luca Gioppo' <luca.gioppo@csi.it>; 'TOSCA' <tosca@lists.oasis-open.org>
> Objet : RE: [tosca] Follow up on the boundary definition section
Hi Luc,
Sounds like we’re generally on the same page. In your opinion, is this something that should be spelled out in the spec?
Thanks,
Chris
Hi Chris, Luca,
If I’m not wrong, in the current version of the spec we consider a node that doesn’t have an implementation for create operation as an ‘abstract node’ meaning that the orchestrator is supposed to replace it with a valid implementation.
In alien4cloud we implemented this matching already for ‘on-demand resources’ like compute etc. and plan to do the same for services so admin can define services on a cloud that can be matched against the topology nodes.
So I agree with Chris that the service nodes should be defined in the topology and have no operations implemented as part of the lifecycle interface.
Note also that we plan in a4c to allow matching of services only if the relationship execute no operations on the service side (source or target based on the relationships). If something has to be done on the service side I think it should be done from the other node through remote calls rather than calling some scripts on the service machine.
Luc
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
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:
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:
> # section to gather requirements for the whole template
> requirements:
> monitoring:
> type: tosca.monitoring.system.Zabbix.external
> properties:
> disposition: Required
> dev_ops:
> type: tosca.dev_ops.system.Puppet.external
> properties:
> disposition: Required
> backup:
> type: tosca.backup.system.Bacula.external
> properties:
> disposition: Best-effort
This will solve some needs coming from the monitoring but also from other generic components.
Other generic environment could be:
- 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.