search

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

`opera deploy --clean-state` doesn't reset inputs #240

Closed abitrolly closed 2 years ago

abitrolly commented 2 years ago

When opera deploy is run with inputs and then rerun without input, but with --clean-state flag, the old inputs are reused.

cankarm commented 2 years ago

@abitrolly thanks for being active and also creating the PR to make the xOpera better.

However I would like to explain you what "clean state" means.

xOpera is state-full, which means that all successful operations are stored and will not be performed again using deploy, unless --clean-state is issued. In --clean-state the orchestrator deletes the state. This means that on deploy is forced to re-run everything on existing (fully or partially deployed) application, without deleting instances that might exist deployed somewhere. This option can be useful when some instances were manually deleted or failed due to unknown reason and you would like to re-run everything to let the Ansible reinforce the state.

If you will re-run clean state with new inputs, you might create new components (VMs, Functions) next to existing ones, while the old ones will be still there and will not be controlled by xOpera anymore, because the state of those has been deleted. This means that only manual intervention would be able to clean instances there.

Therefore, I would be careful to make this change - if the inputs are different extensively, we would need to be able to remove the instances which are not needed anymore. I guess we should find another solution for this.

@anzoman - any thoughts about that?

abitrolly commented 2 years ago

As I understand inputs are parameters that are manually set for deployment. They don't contain ids of allocated resources that are needed to query previously allocated resources. So old inputs won't help to recover missing ids after the --clean-state is specified, so no reason to keep them around. At least in terraform I would expect that.

anzoman commented 2 years ago

Hey @abitrolly, this is an interesting topic within orchestration. So, from my point of view orchestration inputs are not directly part of the xOpera's orchestration state, but state is only described in .opera/instances file, where the instances and their state are listed. As you said inputs are only parameters that are used when the orchestration starts and they often include secrets like SSH keys, passwords and cloud credentials, so the best way would be that we wouldn't even copy raw inputs file to .opera storage folded, but to encrypt them and store them in Ansible/HashiCorp vault or to just use them during deployment and don't copy nothing to storage folder at all, which is probably the safest strategy (also see #143).

The -c/--clean-state switch is useful mostly when you want delete old instance files and redeploy everything from the start (we also have -r/--resume, which starts continues deployment from where it was interrupted) and by deleting opera inputs we would make it obligatory for the users to override the inputs which is now optional - so for instance when you run opera deploy -i inputs.yaml service.yaml and if you wish to redeploy and clean state you can do just opera deploy -c and the same inputs (and also the same TOSCA service template, whose path copied to .opera/root_file) will be used, or opera deploy -c -i newinputs.yaml and you will override previous inputs from .opera/inputs. I'm also saying that .opera storage folder should resemble the project (usually in current directory) you are deploying, which includes the main TOSCA service template and the corresponding inputs and by deleting one of those two you lose some info about the initial project.

All in all, I wouldn't change the behaviour of -c/--clean-state flag right now, but we can always do this in the future if we'll find out that we misunderstood some orchestration operations. I don't know exactly how other types of orchestrators (such as Terraform, AWS CloudFormation or OpenStack Heat) do it, but we also plan to take a look at these tools more in detail and we'll see how their perception of orchestration operations differ from ours.

anzoman commented 2 years ago

I think that we can close this for now and can reopen this issue anytime in the future if we find out that inputs need resetting while cleaning current orchestration state.