RE: [tosca] Follow up on the boundary definition section

Hi all,

Great conversation. It would be helpful to capture the key points as JIRA issue comments, if you would be so kind.

Thanks,

Paul

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Luca Gioppo
Sent: Thursday, October 01, 2015 6:18 AM
To: tosca@lists.oasis-open.org
Subject: RE: [tosca] Follow up on the boundary definition section

Hi Saji, wellcome,

I really like the lid you opened :D

I really believe that ALL those things need to find adeguate modeling in the standard, either by finding the proper way to map them using the existing entities or by defining a proper new one.

I think, that it could be useful for all to treat each one as a separate issue so we can talk about them; for example licence keys are very different than billing system integration so I believe that we will come out with different solution for the 2 problems (or I do not understand well one of the two and so is better to have a single thread for each).

Also even if the idea of Chris really got me I have now a concern after reading your mail.

The concern is this:

- there are lots of external "virtual" systems that need/could need to be addressed, if we add to the topology a node to map that object we end up with lots of nodes just to map the internals of the orchestrator.

- a generic TOSCA writer guy would be a little scared to have to "map" all these things and draw all those relations and creating all those nodes. The reason for a boundary section was to briefly state the need for a component of the orchestrator.

Here, as correctly stated by Chris, we are setting constraints on the orchestrator:

- this TOSCA file need an orchestrator able to do those things: scaling+monitoring + billing etc

We can for sure think of the existance of different flavour of orchestrators.

We could have a basic one just able to do deploy and than you are on your own, to the more sophisticated capable of offering to the customer many features (this is where all implementors compete).

So maybe a section dedicated could be in the long run easier.

Luca

> _________________________________________________________________________

Il 1 ottobre 2015 alle 11.07 saji.thoppil@wipro.com ha scritto:

>

>

Hi,

I am new to TOSCA & OASIS itself, therefore please excuse me if I am saying something absurd here!

Going though Luca’s mail, I was wondering if the boundary definition may(optionally) carry the following. Considering these may be critical for a service functioning.

1)      Security System ( SIEM, IDS, IPS, AV)

2)      Misc Network (GLB, CDN, Latency to a destination)

3)      License Keys (3^rd party)

4)      DR (like a dual site/zone)

5)      Billing System integration

6)      Monitoring (CMDB, Event Monitor, Synthetic Transaction, BLA, ITSM entry)

7)      SLA (RPO/RTO, Operation Team, Tier, Dial home, VPN Tunnel)

8)      Compliance (ITAR, HIPPA etc)

9)      External Surround System (Version of a application/component)

Cheers

Saji

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Luca Gioppo

>   Sent: Thursday, October 1, 2015 1:06 PM

>   To: Luc Boutier <luc@fastconnect.fr>; 'Chris Lauwers' <lauwers@ubicity.com>; 'TOSCA' <tosca@lists.oasis-open.org>

>   Subject: RE: [tosca] Follow up on the boundary definition section

I really very much like the proposal of Chris.

Usually is better to have a behaviour be esplicitly stated rather than leaving the default implementation of the "null".

If we think instead that specifying nothing "means" abstract that should be the clearly explained in the spec since at the moment is not so clear it could be "orchestrator if you find nothing use the default behaviour".

We should also have clear examples of when some null are legitimate and where no (there could be nodes where is not admitted to have no lifecycle: we need to feed the validator)

Luca

>  _________________________________________________________________________

>

>

Il 1 ottobre 2015 alle 9.14 Luc Boutier <luc@fastconnect.fr> ha scritto:

>

>

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

From: Luc Boutier [mailto:luc@fastconnect.fr]

>  Sent: Wednesday, September 30, 2015 9:41 PM

>  To: Chris Lauwers <lauwers@ubicity.com>; 'Luca Gioppo' <luca.gioppo@csi.it>; 'TOSCA' <tosca@lists.oasis-open.org>

>  Subject: RE: [tosca] Follow up on the boundary definition section

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

De : tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] De la part de Chris Lauwers

>  Envoyé : jeudi 1 octobre 2015 05:35

>  À : Luca Gioppo <luca.gioppo@csi.it>; TOSCA <tosca@lists.oasis-open.org>

>  Objet : 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

>  Sent: Wednesday, July 01, 2015 7:54 AM

>  To: TOSCA <tosca@lists.oasis-open.org>

>  Subject: [tosca] Follow up on the boundary definition section

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:

>  # 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:

- 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

>

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

tosca message