You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
node_types:
sodalite.nodes.DockerNetwork:
derived_from: tosca.nodes.SoftwareComponent
properties:
name:
type: string
description: The name of the network
required: true
...
interfaces:
Standard:
type: tosca.interfaces.node.lifecycle.Standard
operations:
create:
inputs:
docker_network_name: { default: { get_property: [ SELF, name ] } }
implementation:
primary: playbooks/add_network.yml
Background
TOSCA gives the possibility to define which are the operations that can be executed on the node types, such as create, delete.
TOSCA is application agnostic, which means that does not have information related to the implementation of the application.
But through interfaces, scripts can be executed through the lifecycle of the application (create, stop, start e.t.c.) such the initialization of a database. Those scripts are linked to the operations of interfaces, as we see in the example above.
Those scripts can be python scripts, ansible playbooks e.t.c. For sodalite, we use ansible playbooks as artifacts.
TOSCA and Ansible are two seperate things.
The 'bridge' between TOSCA and Ansible is the interfaces in the node type.
Tasks
1. Pass info from TOSCA to ansible - probably not work from the reasoner for it
An editor is prepared in IDE for authoring Ansible DSL.
The operation create or docker_network_name should be passed to the playbook.
There are two options
a. Through cross-model references, b) If this approach does not work and we need to rely on the KB content
2. Autocompletion when authoring ansible dsl in ide
As presented in presentation here
Auto-completion should be provided both for the words belonging to the syntax and to the name of modules.
In order to provide the second feature, all the names of the modules need to be saved in the KB.
More info here: #38
3. Ansible metamodel
Save ansible metamodel to KB so as defect predictor to predict bugs for ansible by applying semantic reasoner.
Saving of ansible will be done in a different api than saveAADM/RM so delay in time will not be an issue
The text was updated successfully, but these errors were encountered:
Example
Background
TOSCA gives the possibility to define which are the operations that can be executed on the node types, such as create, delete.
TOSCA is application agnostic, which means that does not have information related to the implementation of the application.
But through interfaces, scripts can be executed through the lifecycle of the application (create, stop, start e.t.c.) such the initialization of a database. Those scripts are linked to the operations of interfaces, as we see in the example above.
Those scripts can be python scripts, ansible playbooks e.t.c. For sodalite, we use ansible playbooks as artifacts.
TOSCA and Ansible are two seperate things.
The 'bridge' between TOSCA and Ansible is the interfaces in the node type.
Tasks
1. Pass info from TOSCA to ansible - probably not work from the reasoner for it
An editor is prepared in IDE for authoring Ansible DSL.
The operation create or docker_network_name should be passed to the playbook.
There are two options
a. Through cross-model references, b) If this approach does not work and we need to rely on the KB content
2. Autocompletion when authoring ansible dsl in ide
As presented in presentation here
Auto-completion should be provided both for the words belonging to the syntax and to the name of modules.
In order to provide the second feature, all the names of the modules need to be saved in the KB.
More info here: #38
3. Ansible metamodel
Save ansible metamodel to KB so as defect predictor to predict bugs for ansible by applying semantic reasoner.
Saving of ansible will be done in a different api than saveAADM/RM so delay in time will not be an issue
The text was updated successfully, but these errors were encountered: