Re: [tosca-comment] TOSCA Scale definition

["Matt Rutkowski" <mrutkows@us.ibm.com>]

Hi Manas,

Policies are considered "dangling"
Requirements, which can be attached to various parts of a topology (model)
such as a single Node, Group of Nodes, or the entire topology.

In the case of Scaling (and it is not
perfect), the goal was to have each "Compute container" express
that they had the Capability to be horizontally scaled and therefore could
accept a Scaling policy (as a Requirement).  

This relationship between Policy (a
dangling Req.) and a Capability has not been formally described in the
spec. as Policies will impact our goal of a "closed loop" system
that can be Monitored (with Events) which can activate (Trigger) policies'
clauses (based on Rules).  This closed-loop system requires coordination
with the Instance and Monitoring WG ad-hocs and will (in my hopes) be better
flushed out by end of this year.  In OpenStack, Senlin would have
been the Policy engine, working with Ceilometer (or Monasca) to monitor
the state of the instances and Trigger scaling based upon the Container
(Compute node) type (e.g., Nova for VMs, Kubernetes for Docker Containers,
etc.).

Please bear in mind that Polices (being
"dangling" Requirements) do not necessarily need to have a corresponding
Capability; that is, the Orchestrator can work with the Provider (providing
Cloud platform) to assure that they are "fulfilled" (somehow)
at deployment time and adhered to during the application's running life-span.

Additionally, I repeatedly comment,
that in "Cloud" systems scaling (placement, failover, etc.) happen
automatically with guidance from the policies; there should be little or
no imperative "actions" (or workflows) that try to manage this
externally since the Provider Cloud's monitoring and platform can react
(and take corrective action) faster than any external mechanism (which
would actually "get in the way").

Kind regards,
Matt Rutkowski

STSM, Master Inventor, IBM Open Cloud Technologies
and Standards
Apache OpenWhisk Incubator Project Lead,
Initial Committer
Chair, Lead Editor OASIS TOSCA Simple Profile
WG,
Co-Chair OASIS TOSCA Interop. SC,
Founder of DMTF Cloud Audit (CADF) Standard
mrutkows@us.ibm.com,  mobile: 512-431-5002




From:      
 Manas Mal <MMal@advaoptical.com>
To:      
 "paul.lipton@ca.com"
<paul.lipton@ca.com>, "sramasw@Brocade.com" <sramasw@Brocade.com>,
"tosca-comment@lists.oasis-open.org" <tosca-comment@lists.oasis-open.org>
Date:      
 06/15/2017 02:32 AM
Subject:    
   [tosca-comment]
TOSCA Scale definition
Sent by:    
   <tosca-comment@lists.oasis-open.org>

---

Hello All,
 
The TOSCA scale definition as per the auto-scale
policy is as follows:
 
12.5.2.1.3 Sample YAML
my_scaling_policy_1:
type: tosca.policy.scaling
description: Simple node autoscaling
properties:
min_instances: <integer>
max_instances: <integer>
default_instances: <integer>
increment: <integer>
 
 
However we have the scalable capability
definition of the VDU.
5.5.13 tosca.capabilities.Scalable
5.5.13.2 Definition
tosca.capabilities.Scalable:
derived_from: tosca.capabilities.Root
properties:
min_instances:
type: integer
default: 1
max_instances:
type: integer
default: 1
default_instances:
type: integer
 
So there is a confusion as to which one
should be used for auto-scale definition for a VDU?
Please clarify the same.
 
Regards,
Manas