Considerations when upgrading Wazi Deploy

The upward compatibility between two consecutive Wazi Deploy versions is ensured. However, warnings might be displayed in the console to indicate that you should conform to the new specifications when you upgrade from one Wazi Deploy version to another. Review the following instructions to know how to adapt your code.

Upgrading from 3.0.3 to 3.0.4

In the deployment analysis, the notion of template has been replaced with the notion of parameterized queries. If you want to write your own deployment analysis scenario, consider the following consequences to adapt your code:
- The -t template argument in the wazideploy-evidence and the corresponding template:str argument in the evidence APIs are deprecated. They are replaced with -q query in the command and query:str in the API. So, do not use them any more. For more information, see Writing the command in file mode or direct mode, Python API evidence function, or Ansible wd_evidence module according to your need.
- In The evidence configuration file, template_search_path no longer exists and template_extensions is renamed query_extensions. So, modify your queries if they reference these fields.
In Wazi Deploy 3.0.4, you cannot use an index folder that was created with a previous version because the internal indexing process has changed. For more information, see the index command.
If the force_lock variable was not set to False (because it is the default value) in the member_archive, member_copy, and member_restore building blocks, the copy step might now fail if the target dataset is used or if the user has no authority to run the command that checks if the dataset is used. Such was not the case in the Wazi Deploy previous version. You might have to set the force_lock variable to True. For more information, see the member_archive, member_copy, and member_restore building blocks.

Upgrading from 3.0.2 to 3.0.3

In Python, the spec: root level is obsolete. To adapt your code to this evolution, complete the following actions:
- In the environment variables file, remove this spec root level and move the embedded lines to the left.
- In the Jinja2 templates and in the environment variables that reference this spec level, remove spec.
See the comparison between the two code samples below.
The extra_vars prefix used for declaration in Python is obsolete. You can remove any references of the extra_vars prefix from the Jinja2 templates and the environment variables.
The following code samples compare an excerpt from an environment variables file where the spec root level and extra_vars prefix have been removed in 3.0.3.
- The following code corresponds to version 3.0.2:
```
spec:
  default_db2_user: "{{ extra_vars.db2_user if extra_vars.db2_user is defined else 'USER1' }}"
  db2_sys_def:
    package_maxrc: 4
    plan_maxrc: 4
    user: "{{ env.spec.default_db2_user }}"
```
- The following code corresponds to version 3.0.3:
```
default_db2_user: "{{ db2_user if db2_user is defined else 'USER1' }}"
db2_sys_def:
  package_maxrc: 4
  plan_maxrc: 4
  user: "{{ default_db2_user }}"
```
The following variables of the include_vars building block are renamed:
- The var_file_name_include property is now var_include_vars in the deployment method.
- The include_file_name_default variable is now include_vars_default in the environment variables file. This include_vars_default variable is a group variable.
Review your deployment method and your environment variables file and adapt them to these modifications.