Page tree
Skip to end of metadata
Go to start of metadata

1       TOSCA Policies

This section is non-normative and describes the approach TOSCA Simple Profile plans to take for policy description with TOSCA Service Templates.  In addition, it explores how existing TOSCA Policy Types and definitions might be applied in the future to express operational policy use cases.

1.1 A declarative approach

TOSCA Policies are a type of requirement that govern use or access to resources which can be expressed independently from specific applications (or their resources) and whose fulfillment is not discretely expressed in the application’s topology (i.e., via TOSCA Capabilities).   

TOSCA deems it not desirable for a declarative model to encourage external intervention for resolving policy issues (i.e., via imperative mechanisms external to the Cloud). Instead, the Cloud provider is deemed to be in the best position to detect when policy conditions are triggered, analyze the affected resources and enforce the policy against the allowable actions declared within the policy itself. 

1.1.1 Declarative considerations

  • Natural language rules are not realistic, too much to represent in our specification; however, regular expressions can be used that include simple operations and operands that include symbolic names for TOSCA metamodel entities, properties and attributes.
  • Complex rules can actually be directed to an external policy engine (to check for violation) returns true|false then policy says what to do (trigger or action).
  • Actions/Triggers could be:
    • Autonomic/Platform corrects against user-supplied criteria
    • External monitoring service could be utilized to monitor policy rules/conditions against metrics, the monitoring service could coordinate corrective actions with external services (perhaps Workflow engines that can analyze the application and interact with the TOSCA instance model).

1.2 Consideration of Event, Condition and Action

1.3 Types of policies

Policies typically address two major areas of concern for customer workloads:

  • Access Control – assures user and service access to controlled resources are governed by rules which determine general access permission (i.e., allow or deny) and conditional access dependent on other considerations (e.g., organization role, time of day, geographic location, etc.).
  • Placement – assures affinity (or anti-affinity) of deployed applications and their resources; that is, what is allowed to be placed where within a Cloud provider’s infrastructure. 
  • Quality-of-Service (and continuity) - assures performance of software components (perhaps captured as quantifiable, measure components within an SLA) along with consideration for scaling and failover.

1.3.1 Access control policies

Although TOSCA Policy definitions could be used to express and convey access control policies, definitions of policies in this area are out of scope for this specification.  At this time, TOSCA encourages organizations that already have standards that express policy for access control to provide their own guidance on how to use their standard with TOSCA.

1.3.2 Placement policies

There must be control mechanisms in place that can be part of these patterns that accept governance policies that allow control expressions of what is allowed when placing, scaling and managing the applications that are enforceable and verifiable in Cloud.

 

These policies need to consider the following:

  • Regulated industries need applications to control placement (deployment) of applications to different countries or regions (i.e., different logical geographical boundaries).[MR1] 

1.3.2.1 Placement for governance concerns

In general, companies and individuals have security concerns along with general “loss of control” issues when considering deploying and hosting their highly valued application and data to the Cloud.  They want to control placement perhaps to ensure their applications are only placed in datacenter they trust or assure that their applications and data are not placed on shared resources (i.e., not co-tenanted).

 

In addition, companies that are related to highly regulated industries where compliance with government, industry and corporate policies is paramount. In these cases, having the ability to control placement of applications is an especially significant consideration and a prerequisite for automated orchestration.

1.3.2.2 Placement for failover

Companies realize that their day-to-day business must continue on through unforeseen disasters that might disable instances of the applications and data at or on specific data centers, networks or servers.  They need to be able to convey placement policies for their software applications and data that mitigate risk of disaster by assuring these cloud assets are deployed strategically in different physical locations.  Such policies need to consider placement across geographic locations as wide as countries, regions, datacenters, as well as granular placement on a network, server or device within the same physical datacenter. Cloud providers must be able to not only enforce these policies but provide robust and seamless failover such that a disaster’s impact is never perceived by the end user.

1.3.3 Quality-of-Service (QoS) policies

Quality-of-Service (apart from failover placement considerations) typically assures that software applications and data are available and performant to the end users.  This is usually something that is measurable in terms of end-user responsiveness (or response time) and often qualified in SLAs established between the Cloud provider and customer.  These QoS aspects can be taken from SLAs and legal agreements and further encoded as performance policies associated with the actual applications and data when they are deployed.  It is assumed that Cloud provider is able to detect high utilization (or usage load) on these applications and data that deviate from these performance policies and is able to bring them back into compliance.

1.4 Policy relationship considerations

  • Performance policies can be related to scalability policies.  Scalability policies tell the Cloud provider exactly how to scale applications and data when they detect an application’s performance policy is (or about to be) violated (or triggered).  
  • Scalability policies in turn are related to placement policies which govern where the application and data can be scaled to.
  • There are general “tenant” considerations that restrict what resources are available to applications and data based upon the contract a customer has with the Cloud provider. This includes other constraints imposed by legal agreements or SLAs that are not encoded programmatically or associated directly with actual application or data..

1.5 Use Cases

This section includes some initial operation policy use cases that we wish to describe using the TOSCA metamodel.  More policy work will be done in future versions of the TOSCA Simple Profile in YAML specification.

1.5.1 Placement

1.5.1.1 Use Case 1: Simple placement for failover

1.5.1.1.1 Description

This use case shows a failover policy to keep at least 3 copies running in separate containers. In this simple case, the specific containers to use (or name is not important; the Cloud provider must assure placement separation (anti-affinity) in three physically separate containers.

1.5.1.1.2 Features

This use case introduces the following policy features:

  • Simple separation on different “compute” nodes (up to discretion of provider).
  • Simple separation by region (a logical container type) using an allowed list of region names relative to the provider.
    • Also, shows that set of allowed “regions” (containers) can be greater than the number of containers requested.
1.5.1.1.3 Logical Diagram

 Sample YAML: Compute separation

failover_policy_1:

  type: tosca.policy.placement.Antilocate

  description: My placement policy for Compute node separation

  properties:

    # 3 diff target containers

    container type: Compute

    container_number: 3

1.5.1.1.4 Notes
  • There may be availability (constraints) considerations especially if these policies are applied to “clusters”.
  • There may be future considerations for controlling max # of instances per container.

1.5.1.2 Use Case 2: Controlled placement by region

1.5.1.2.1 Description

This use case demonstrates the use of named “containers” which could represent the following:

  • Datacenter regions
  • Geographic regions (e.g., cities, municipalities, states, countries, etc.)
  • Commercial regions (e.g., North America, Eastern Europe, Asia Pacific, etc.)
1.5.1.2.2 Features

This use case introduces the following policy features:

  • Separation of  resources (i.e., TOSCA nodes) by logical regions, or zones.
1.5.1.2.3 Sample YAML: Region separation amongst named set of regions

failover_policy_2:

  type: tosca.policy.placement

  description: My failover policy with allowed target regions (logical containers)

  properties:

    container type: region 

    container_number: 3

    # If “containers” keyname is provided, they represent the allowed set

    # of target containers to use for placement for .

    containers: [ region1, region2, region3, region4 ]

1.5.1.3 Use Case 3: Co-locate based upon Compute affinity

1.5.1.3.1 Description

Nodes that need to be co-located to achieve optimal performance based upon access to similar Infrastructure (IaaS) resource types (i.e., Compute, Network  and/or Storage).

 

This use case demonstrates the co-location based upon Compute resource affinity; however, the same approach could be taken for Network as or Storage affinity as well. :

1.5.1.3.2 Features

This use case introduces the following policy features:

  • Node placement based upon Compute resource affinity.
  • The concept of placement based upon IaaS resource utilization is not future-thinking, as Cloud should guarantee equivalent performance of application performance regardless of placement.  That is, all network access between application nodes and underlying Compute or Storage should have equivalent performance (e.g., network bandwidth, network or storage access time, CPU speed, etc.).

1.5.1.4 Notes

1.5.1.4.1 Sample YAML: Region separation amongst named set of regions

keep_together_policy:

  type: tosca.policy.placement.Colocate

  description: Keep associated nodes (groups of nodes) based upon Compute

  properties:

    affinity: Compute

1.5.2 Scaling

1.5.2.1 Use Case 1:  Simple node autoscale

1.5.2.1.1 Description

Start with X nodes and scale up to Y nodes, capability to do this from a dashboard for example.

1.5.2.1.2 Features

This use case introduces the following policy features:

  • Basic autoscaling policy
1.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>

1.5.2.1.4 Notes
  • Assume horizontal scaling for this use case
    • Horizontal scaling, implies “stack-level” control using Compute nodes to define a “stack” (i.e., The Compute node’s entire HostedOn relationship dependency graph is considered part of its “stack”)
    • Assume Compute node has a SoftwareComponent that represents a VM application.
    • Availability Zones (and Regions if not same) need to be considered in further use cases.
    • If metrics are introduced, there is a control-loop (that monitors).  Autoscaling is a special concept that includes these considerations.
    • Mixed placement and scaling use cases need to be considered:
      • Example: Compute1 and Compute2 are 2 node templates. Compute1 has 10 instances, 5 in one region 5 in other region.
  • No labels