radon-h2020 / radon-ctt

RADON Continuous Testing Tool (CTT)
Apache License 2.0
0 stars 5 forks source link

Relative paths in create.yml are not resolved properly #58

Closed duelle closed 4 years ago

duelle commented 4 years ago

When using relative paths in the create.yml, the referenced files cannot be found.

In the attached example opera.zip, files are organized as follows:

When executing opera in the opera folder like this: opera deploy radon-ctt/servicetemplate.yml the template seems to be found and the deployment is started according to the output. This fails in the end because the docker-compose.yml cannot be found.

Related to: #57

duelle commented 4 years ago

To investigate the current directory during execution of the shell script in the create.yml, I used the create-pwd.yml which shows that the working directory is a temporary directory (in my case it was /tmp/tmp...).

anzoman commented 4 years ago

Hi, @duelle the origin of your problem is actually not in xOpera orchestrator itself. Ok, let me explain this a little bit further.

For xOpera to found the desired path of docker-compose.yml file which is opera/deploy/docker-compose/docker-compose.yml you have to extend the declaration of TOSCA interfaces and add a dependency to your node type definition like this:

node_types:
  radon.nodes.docker.WebApplication:
    derived_from: tosca.nodes.SoftwareComponent
    interfaces:
      Standard:
        operations:
          create:
            implementation:
              primary: create.yml
              dependencies:
                - ../deploy/docker-compose/docker-compose.yml
    requirements:
      - host:
          capability: tosca.capabilities.Compute
          relationship: tosca.relationships.HostedOn

As you can see I have to go back to the root of the CSAR to found the actual file. That's because you're running xOpera from opera folder. You also had the wrong relationship type in the requirements of the WebApplication node type so I had to replace DependsOn with HostedOn which is logical because you want to run this playbook on the defined workstation.

The next thing is usage of the docker-compose.yml. When you add a dependency to that file, xOpera actually copies it to the location of the playbook (in our case that is radon-ctt directory) so that file becomes adjacent to your create.yml Ansible playbook. So that copied file is not actually on your target machine (if we suppose that the deployment would be run on some VM) but it is accessible to xOpera and Ansible playbooks so you have to copy it within the playbook (you can use Ansible copy or template module for that). So after the changes your playbook would look like that:

- name: Run SockShop
  hosts: localhost
  gather_facts: no
  tasks:
    - name: Copy minio webhook template to target node
      copy:
        src: "docker-compose.yml"
        dest: "/tmp/docker-compose.yml"

    - name: run docker-compose from shell
      shell: "docker-compose -f /tmp/docker-compose.yml up -d front-end edge-router catalogue catalogue-db carts carts-db orders orders-db shipping queue-master rabbitmq payment user user-db"

Below is your zipfile with some changes.

opera.zip

Try to run the service template again and let me know if everything went ok :)

For me it was working fine (I tried running on an Openstack VM) and the result is below.

result

I know that sometimes it is more convenient to put those TOSCA service artefacts in a separate folder but I would also recommend that for the future you consider placing your main TOSCA service templates to the root of CSAR which makes imports and dependencies more natural (for instance you could have your servicetemplate.yml in opera folder and run it from there).

cankarm commented 4 years ago

Thanks @anzoman for the detailed triage of the issue.

duelle commented 4 years ago

Thanks for your help @anzoman. I included the changes in our demo repository [1] as a reference. [1] https://github.com/radon-h2020/demo-ctt-sockshop