Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Tosca v1.2 and v1.3 enhancements 2019 05-06

49 Aufrufe

Veröffentlicht am

This presentation presents an overview of new features introduced in Versions 1.2 and 1.3 of the TOSCA cloud orchestration standard.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Tosca v1.2 and v1.3 enhancements 2019 05-06

  1. 1. TOSCA Enhancements— Post v1.1 May 6, 2019
  2. 2. TOSCA Feature Categories Copyright © 2019 Ubicity Corp. 2 Modeling Features Topology, Node, and Relationship Templates Reusable Components (Types) Requirements and Node Filters Substitution Orchestration Features Interfaces, Operations, and Notifications Artifact Processing Workflows Policies
  3. 3. TOSCA v1.2 Enhancements Copyright © 2018 Ubicity Corp. 3
  4. 4. TOSCA Orchestration Examples TOSCA is a language specification only – Intentionally does not prescribe orchestrator implementations – To allow a rich ecosystem of TOSCA implementation However, user feedback suggests that examples of orchestration implementations might be useful: – To avoid confusion about language features – To simplify explanations of language features – To improve portability TOSCA Simple Profile in YAML v1.2 introduces non-normative chapters describing orchestrator functionality Chapter 13 – Artifact Processing and creating portable Service Templates Chapter 14 – Abstract nodes and target node filters matching Copyright © 2019 Ubicity Corp. 4
  5. 5. Orchestration Enhancements—Artifact Processing Chapter 13 introduces the concept of Artifact Processor – Defines comprehensive set of artifact processing steps – Each artifact type is handled by its own artifact processor – To ensure portability, artifact processors must define standard mechanism for exchanging information with orchestrator • Operation inputs and outputs • Artifact properties – TOSCA v1 currently only defines information exchange standard for shell scripts • Through environment variables Copyright © 2019 Ubicity Corp. 5 Orchestration Features Interfaces, Operations, and Notifications Artifact Processing Workflows Policies
  6. 6. Orchestration Enhancements—Operation Implementations Extended Operation Implementation Grammar 1. Support for specifying execution environment 2. Support for timeout values Copyright © 2019 Ubicity Corp. 6 Orchestration Features Interfaces, Operations, and Notifications Artifact Processing Workflows Policies
  7. 7. Extended Operation Implementation Grammar interfaces: Standard: create: implementation: primary: artifacts/create.sh operation_host : HOST timeout : 100 Copyright © 2019 Ubicity Corp. 7 Support for execution host – Borrows from and generalizes workflow syntax – Specifies the node on which operations should be executed – ORCHESTRATOR, SELF, or HOST for node operations – ORCHESTRATOR, SOURCE, or TARGET for relationship operations Support for timeout values – Specifies how long orchestrator should wait for operation to complete before it times out – Expressed in seconds
  8. 8. Orchestration Enhancements—Policy Triggers Policy trigger condition leverages the condition clause definition introduced with workflows in TOSCA v1.1 – Part of broader (and ongoing) effort to harmonize workflow and policy syntax Copyright © 2019 Ubicity Corp. 8 Orchestration Features Interfaces, Operations, and Notifications Artifact Processing Workflows Policies
  9. 9. Chapter 14—Matching Non-normative chapter to ease understanding of TOSCA orchestrator matching process. – Matching abstract node templates in service templates with substituting service template (in service catalog) – Matching dangling requirements in node templates with resources (in inventory) that have the capability to fulfill the requirement Unfortunately, Chapter 14 includes incorrect examples – V1.3 removes Chapter 14 – Corrected version of Chapter 14 will get re- introduced in TOSCA v2.0 Copyright © 2019 Ubicity Corp. 9 Modeling Features Topology, Node, and Relationship Templates Reusable Components (Types) Requirements and Node Filters Substitution
  10. 10. Modeling Enhancements—Substitution Mapping – Substitution mappings allow complete mapping of all Node Type keynames Copyright © 2019 Ubicity Corp. 10 Modeling Features Topology, Node, and Relationship Templates Reusable Components (Types) Requirements and Node Filters Substitution
  11. 11. Substitution Mapping properties: <property_name>: <property_value> <property_name>: [<input_name>] <property_name>: [<node_template_name>, <property_name>] interfaces: <interface_name>: <operation_name>: <workflow_name> Copyright © 2019 Ubicity Corp. 11 Property Mappings – Explicit property-to-input mappings • Without requiring input names to match – Property-to-property mappings • Deprecated in v1.3 – Property-to-constant-value mappings • Replaced with substitution_filter in v1.3 Interface Mappings – Operation-to-workflow mapping
  12. 12. Modeling Enhancements—Type Definitions 1. Additional String types 2. Schema constraints on strings 3. Abstract node types Copyright © 2019 Ubicity Corp. 12 Modeling Features Topology, Node, and Relationship Templates Reusable Components (Types) Requirements and Node Filters Substitution
  13. 13. String Data Type Enhancements properties: event_object: type: tosca.datatypes.json constraints: - schema: > { "$schema": "http://json-schema.org/draft-04/schema#", "title": "Event", "description": "Example Event type schema", "type": "object", "properties": { "uuid": { "description": "The unique ID for the event.", "type": "string" }, "code": { "type": "integer" }, "message": { "type": "string" } }, "required": ["uuid", "code"] } Copyright © 2019 Ubicity Corp. 13 tosca.datatype.json – In support of ECMA-404 / IETF RFC 7158 • JSON Data Interchange Format tosca.datatype.xml – For XML-formatted strings Schema constraint on string types. – When supplied on a Property definition, a TOSCA Orchestrator MAY choose use the contained schema definition for validation – Expects constraint schema to be supplied in-line
  14. 14. Abstract Node Types node_types: tosca.nodes.Abstract.Compute: derived_from: tosca.nodes.Root tosca.nodes.Compute: derived_from: tosca.nodes.Abstract.Compute tosca.nodes.Abstract.Storage: derived_from: tosca.nodes.Root tosca.nodes.Storage.ObjectStorage: derived_from: tosca.nodes.Abstract.Storage tosca.nodes.Storage.BlockStorage: derived_from: tosca.nodes.Abstract.Storage capability_types: tosca.capabilities.Container: derived_from: tosca.capabilities.Root tosca.capabilities.Compute: derived_from: tosca.capabilities.Container Copyright © 2019 Ubicity Corp. 14 Create abstract base types for a number of normative TOSCA node types – Motivated by ETSI NFV requirements – To extract properties that are common between TOSCA node types and ETSI NFV information models Create abstract base types for a number of normative TOSCA capability types – In support of new abstract node types
  15. 15. TOSCA v1.3 Enhancements Copyright © 2018 Ubicity Corp. 15
  16. 16. Operation Output Mappings tosca_definitions_version: tosca_simple_yaml_1_3 topology_template: node_templates: server: type: tosca.nodes.Compute interfaces: Standard: configure: outputs: ip1: [ SELF, private_address ] ip2: [ SELF, public_address ] Copyright © 2019 Ubicity Corp. 16 Interface definitions formally define output mappings that specify: – The named output values that are expected to be returned by interface operations. – The attributes on nodes or relationships into which these output values must be stored. Enables instance model to accurately reflect that state of the objects under management.
  17. 17. Notifications in Interface Definitions tosca_definitions_version: tosca_simple_yaml_1_3 topology_template: node_templates: db_1: type: org.ego.nodes.Database interfaces: HealthMonitor: notifications: heartbeat: outputs: tick: [ SELF, still_alive ] failure_report: outputs: level: [SELF, failure_level] time: [SELF, failure_time] environment: [SELF, failure_context] Copyright © 2019 Ubicity Corp. 17 Interface notifications define events that are delivered asynchronously to the orchestrator – As a result of external events (e.g. load changes, failures, or other changes) – Rather than as a result of lifecycle management operations performed by the orchestrator. Interface notifications include output mappings – To allow the instance model to accurately reflect the state of the objects under management.
  18. 18. Orchestration Enhancements—Artifact Processing 1. Artifact properties Copyright © 2019 Ubicity Corp. 18 Orchestration Features Interfaces, Operations, and Notifications Artifact Processing Workflows Policies
  19. 19. Artifact Properties artifacts: sw_image: description: Image for virtual machine type: tosca.artifacts.Deployment.Image.VM file: images/vm_image.qcow2 checksum: ba411cafee2f0f702572369da0b765e2 version: 3.2 checksum_algorithm: MD5 properties: name: vSRX container_format: BARE disk_format: QCOW2 min_disk: 1 GB size: 649 MB Copyright © 2019 Ubicity Corp. 19 – Artifact Processors may need additional details about artifacts (beyond the artifact type) to process the artifact correctly – This information is provided using artifact properties – TOSCA v1.2 includes property definitions in artifact type definitions, but not property assignments in artifact definitions – TOSCA v1.3 fixes this oversight
  20. 20. Orchestration Enhancements—Workflows 1. Improved condition grammar 2. Harmonize actions/activities across workflows and policies 3. External workflows Copyright © 2019 Ubicity Corp. 20 Orchestration Features Interfaces, Operations, and Notifications Artifact Processing Workflows Policies
  21. 21. Improved Condition Clauses condition: - not: - and: - my_attribute1: [{equal: value1}] - my_attribute2: [{equal: value1}] condition: - or: - and: - protocol: { equal: http } - port: { equal: 80 } - and: - protocol: { equal: https } - port: { equal: 431 } Copyright © 2019 Ubicity Corp. 21 – Condition clauses now support ‘not’ operator – Condition clauses deprecate the (redundant) assert statement
  22. 22. Harmonize Actions/Activities across Workflows and Policies workflows: deploy: steps: tomcat_install: target: tomcat activities: - set_state: creating - call_operation: org.example.if.std.create - set_state: created policies: - recover_policy: type: org.ego.policies.trigger.RecoveryPolicy triggers: - mon_fail_trigger: action: - delegate: failure_recovery_workflow Copyright © 2019 Ubicity Corp. 22 Workflow steps and policy triggers both allow a set of activities to be specified – Unifies grammar that was inconsistent in previous versions Activities can include – Set the state of a node – Call an operation defined on a TOSCA interface – Inline another workflow – Delegate to another workflow
  23. 23. External Workflows topology_template: workflows: deploy: implementation: description: workflow implemented in Mistral type: mycompany.artifacts.Mistral file: my_workflow.workbook.mistral.yaml outputs: ip1: [ server, private_address ] ip2: [ server, public_address ] Copyright © 2019 Ubicity Corp. 23 Allow service topologies to be deployed and managed using non- TOSCA workflows – Specified using 3rd-party workflow languages – Packaged with service templates as artifacts Support output mappings for external workflows – To allow the instance model to accurately reflect the state of the managed objects after the external workflow has been run.
  24. 24. Orchestration Enhancements—Policies 1. Link policy trigger events to interface notifications Copyright © 2019 Ubicity Corp. 24 Orchestration Features Interfaces, Operations, and Notifications Artifact Processing Workflows Policies
  25. 25. Link Policy Trigger Events to Interface Notifications policies: - recover_policy: type: org.ego.policies.trigger.RecoveryPolicy description: > Kicks in if the database or app_logic nodes fail. targets: [ db_1, app_logic_1 ] triggers: - mon_fail_trigger: event: org.example.if.Monitor.on_failure action: - delegate: failure_recovery_workflow ... Copyright © 2019 Ubicity Corp. 25 – Policy triggers define event / condition / action – Events in policy triggers now refer to newly-introduced notifications in interface definitions – Enables true closed-loop automation
  26. 26. Modeling Enhancements—Templates 1. Consistent use of ‘occurrences’ keyword in capability definitions and capability assignments. 2. Prepare for multiple node instances Copyright © 2019 Ubicity Corp. 26 Modeling Features Topology, Node, and Relationship Templates Reusable Components (Types) Requirements and Node Filters Substitution
  27. 27. Multiple Node Instances (Experimental) tosca_definitions_version: tosca_simple_yaml_1_3 topology_template: inputs: numberOfSites: type: integer node_templates: sdwan: type: VPN site: type: VPNSite occurrences: [1, UNBOUNDED] instance_count: { get_input: numberOfSites } requirements: - vpn: sdwan Allow multiple node instances to be created from the same node template. – For services with a variable number of nodes of the same type. • E.g. ONAP CCVPN use case Grammar extensions – ‘occurrences’ keyword to specify how many instances are allowed – ‘instance_count’ keyword to specify desired number of instances at deployment time
  28. 28. Modeling Enhancements—Types 1. Formalize grammar for refining entity definitions 2. Improved support for complex data types Copyright © 2019 Ubicity Corp. 28 Modeling Features Topology, Node, and Relationship Templates Reusable Components (Types) Requirements and Node Filters Substitution
  29. 29. Formalize Grammar for Refining Entity Definitions capability_types: tosca.capabilities.Endpoint: derived_from: tosca.capabilities.Root properties: secure: type: boolean default: false tosca.capabilities.Endpoint.Admin: derived_from: tosca.capabilities.Endpoint # Change Endpoint secure indicator to true # from its default of false properties: secure: true Copyright © 2019 Ubicity Corp. 29 Derived types can refine properties defined in base types. – A property definition is a refinement when a property with the same name already exists in a base type. Property refinements can: – Assign a new (compatible) property type – Assign a (final) fixed value – Specify or change a default value – Add constraints. – Turn an optional property into a required property. Refinement grammar for capability, requirement, and interface definitions to be formalized in future versions.
  30. 30. Improved Support for Complex Data Types data_types: DailyTasks: derived_from: map entry_schema: type: list entry_schema: type: Task key_schema: type: DayOfWeek Copyright © 2019 Ubicity Corp. 30 Nested complex types – List of lists – List of maps – Map of lists – Map of maps Datatypes that derive from list or map – Add entry_schema Support for key_schema – To define the type of keys in maps get_input support for complex data types – Extract sub-elements of complex data types
  31. 31. Modeling Enhancements—Requirements None Copyright © 2019 Ubicity Corp. 31 Modeling Features Topology, Node, and Relationship Templates Reusable Components (Types) Requirements and Node Filters Substitution
  32. 32. Modeling Enhancements—Substitution 1. Explicit substitutability 2. Property mapping corrections 3. Substitution filter 4. Multiple top-level templates in CSAR Copyright © 2019 Ubicity Corp. 32 Modeling Features Topology, Node, and Relationship Templates Reusable Components (Types) Requirements and Node Filters Substitution
  33. 33. Explicit Substitutability tosca_definitions_version: tosca_simple_yaml_1_3 topology_template: inputs: vendorInput: type: string rulesInput: type: list entry_schema: FirewallRules node_templates: firewall: type: abstract.Firewall directives: - substitute properties: vendor: { get_input: vendorInput } rules: { get_input: rulesInput } Copyright © 2019 Ubicity Corp. 33 Version 1.2 orchestrators are expected to substitute abstract node templates – Node templates were considered abstract if no implementation was provided for create operation of Standard lifecycle management interface. Issues with v1.2 approach: – Does not work with custom interfaces. – Behavior is orchestrator-specific. – Does not allow for ‘dummy’ data structure nodes. V1.3 introduces explicit substitute directive – Service designer controls substitutability
  34. 34. Substitution mappings support the following – Property-to-input mappings • Mapping of properties of an abstract node to inputs of its substituting template. – Property-to-property mappings have been deprecated • Mapping of properties of an abstract node to properties of nodes in its substituting template. • If substituting template is valid, all its nodes already have property values assigned, which makes property-to- property mapping unnecessary/impossible. – Property-to-constant mappings have been deprecated • The mapping of a (variable) property to a constant value is confusing and counter-intuitive • This feature was not intended to imply a mapping at all, but rather was intended to be used as a mechanism for controlling the selection of a substituting template when multiple substitution candidates are available. • Selection control has been formalized instead using substitution_filter grammar. Property Mapping Corrections Copyright © 2019 Ubicity Corp. 34
  35. 35. Substitution Filters tosca_definitions_version: tosca_simple_yaml_1_3 description: Service template for an ACME firewall topology_template: inputs: rulesInput: type: list entry_schema: FirewallRules substitution_mappings: node_type: abstract.Firewall substitution_filter: properties: vendor: { equal: ACME } properties: rules: [ rulesInput ] node_templates: acme: type: ACMEFirewall properties: rules: { get_input: rulesInput } acmeConfig: # ACME-specific properties go here. Copyright © 2019 Ubicity Corp. 35 Used by substituting template to limit the set of abstract node templates for which it is a substitution candidate Template is candidate for substitution if: – The type in the substitution_mappings section matches the type of the abstract node template. – The property values of the abstract node template satisfy the constraints defined in the substitution_filter
  36. 36. Multiple Top-Level Templates in CSAR TOSCA-Meta-File-Version: 1.1 CSAR-Version: 1.1 Created-By: OASIS TOSCA TC Entry-Definitions: definitions/tosca_elk.yaml Other-Definitions: definitions/tosca_moose.yaml definitions/tosca_deer.yaml Copyright © 2019 Ubicity Corp. 36 – Substitution mapping requires Orchestrator to have access to one or more substituting service templates – These templates cannot be included into top-level service template using import statements • Would result in multiple topology_template statements in the same service template – Instead: • Package substituting templates as top-level templates in CSAR • Use Other-Definitions statement in TOSCA.meta to point to those other top- level templates

×