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

Changes in inputs produce an error if redeployed #248

Open alexmaslenn opened 2 years ago

alexmaslenn commented 2 years ago

Description

After a service template with inputs is deployed, a removing an input can cause an error.

Steps

Consider having the following simple service template service.yaml file with inputs section:

tosca_definitions_version: tosca_simple_yaml_1_3

topology_template:
  inputs:
    input1:
      type: string
    input2:
      type: string

  node_templates:
    my-workstation:
      type: tosca.nodes.Compute
      attributes:
        private_address: { get_input: input1 }
        public_address:  { get_input: input2 }

with inputs.yaml file being

input1: localhost
input2: localhost

After we successfully execute the deployment with opera deploy -i input.yaml service.yaml we make the following changes in the files, removing input2:

tosca_definitions_version: tosca_simple_yaml_1_3

topology_template:
  inputs:
    input1:
      type: string

  node_templates:
    my-workstation:
      type: tosca.nodes.Compute
      attributes:
        private_address: { get_input: input1 }
input1: localhost

Current behaviour

Execution of the command opera deploy -i input.yaml service.yaml -c returns the following error:

opera.error.DataError: Undeclared inputs: input2

This happens because if instances directory is present in .opera file storage, inputs are read from the storage, not from the file provided in -i arg.

Expected behaviour

No error is returned and deployment is successful.

anzoman commented 2 years ago

Thanks @alexmaslenn, we will fix that ASAP.

alexmaslenn commented 2 years ago

Lets not hurry. It is connected to #240 I think. Maybe some other connected issues will arise.

anzoman commented 2 years ago

Huh okay I'll hold my horses. We need to be careful and explore any additional issues, so please supply here or in separate issues (if not connected) when you find anything unusual with TOSCA inputs.

alexmaslenn commented 2 years ago

@anzoman I've tested another scenario and found an issue that is connected I guess #250

cankarm commented 2 years ago

Maybe this is irrelevant and my next point can be wrong, but... I guess that appropriate approach should be to use opera diff or opera update when you do any changes on the deployed IaC (service and inputs definition)?

Somehow I think that it is OK, that it is failing - explaining you that you actually changed something after deploy, so you might be very careful with executing this command.

anzoman commented 2 years ago

@cankarm good point, opera diff should be used to see changes and then opera update to apply them.

But here (as @alexmaslenn described before) we are talking about redeploying with -c/--clean.state option which should erase the opera's storage folder properly and the user should be able to redeploy anything regardless of the current state of already deployed application (the user is already warned that "the clean state deploy option might have unexpected consequences on the already deployed blueprint").

alexmaslenn commented 2 years ago

@cankarm I've tested opera diff -i input.yaml service.yaml with the scenario above and it also fails.

Undeclared inputs: input2
anzoman commented 2 years ago

@alexmaslenn strange, this definitely needs to be fixed.