xlab-si / xopera-opera

xOpera orchestrator compliant with TOSCA YAML v1.3 in the making
https://xlab-si.github.io/xopera-docs/
Apache License 2.0
35 stars 14 forks source link

`public_address` doesn't recognize port for deployment #244

Closed abitrolly closed 2 years ago

abitrolly commented 2 years ago

So I need to set public_address so that opera knows where to connect to run playbook. If I add port to public_address, such as 127.0.0.1:2222 (because SSH is on different port), then opera no longer can connect to it.

Failed to connect to the host via ssh: ssh: Could not resolve hostname 127.0.0.1:2222: Name or service not known

Means it tried to resolve the whole string as a single hostname.

anzoman commented 2 years ago

@abitrolly, thanks for opening this. This is (again) some configuration for connecting to hosts that belongs to behavioral Ansible inventory parameters and to support it the option would be to add another environoment variable (e.g., OPERA_SSH_PORT). But we can continue like this with new env vars for our Ansible inventory to eternity and here the problem is also that if we will support new executors we will need new env vars to configure them as well. The issue is therefore connected to #243, which targets enabling config files for xOpera that will configure the orchestrator and the executors behind TOSCA.

In the meantime you can resolve your issue by specifying the SSH connection port within your Ansible playbook with ansible_port variable and set_facts like this (also see this link):

- name: Change ssh port to 2222
  set_fact:
    ansible_port: 2222
abitrolly commented 2 years ago

I ended up with passing input variables all the the way down to type and then to playbook as vars instead of facts. The code is below. Unfortunately, all the nodes will share the same port as I don't have time to investigate if I should define a property or an attribute for web server type to hold the port value to be overridden in template.

node_types:
  type_web_server:
    derived_from: tosca.nodes.WebServer
    interfaces:
      Standard:
        operations:
          create:
            implementation: playbooks/create.yaml
            inputs:
              ssh_port:
                type: string
                value: { get_input: ssh_port }
  vars:
    ansible_port: "{{ ssh_port }}"
anzoman commented 2 years ago

Hi, @abitrolly good that you fixed this, yes you could define ssh_port TOSCA property to allow overriding the ssh_port input for create Standard interface operation (attributes are more used when you try get some values back from executors). So, you can do it like this:

node_types:
  type_web_server:
    derived_from: tosca.nodes.WebServer
    properties:
      ssh_port:
        type: integer
        default: 22
    interfaces:
      Standard:
        operations:
          create:
            implementation: playbooks/create.yaml
            inputs:
              ssh_port:
                type: integer
                value: { get_property: [SELF, ssh_port] }
abitrolly commented 2 years ago
opera.error.ParseError: [DataTypeReferenceWrapper] Invalid reference data_types/int
[[Command exited with 1]]

type: integer worked. I don't know why TOSCA needs this type micromanagement at this point. I don't think types matter on this level, so everything could be just a string.

anzoman commented 2 years ago

@abitrolly ah I forgot that it was integer and not int (as I often do with other data types like boolean and bool). Honestly, I can't judge about the usefulness of these TOSCA data types, but on the other hand they come in handy sometimes when the executors behind TOSCA (e.g., Ansible, bash, Python, etc.) require parameters of certain type.

anzoman commented 2 years ago

This seems to be resolved now, so I'm closing it.