Description of problem: When a openstack-tripleo-heat-templates get updated, the files served through swift do not get updated before overcloud deploy --update-plan-only . Usually this should also work on a openstack overcloud stack update -e /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.yaml The environment file references yum_update.sh indirectly: ./overcloud-resource-registry-puppet.yaml: OS::TripleO::Tasks::PackageUpdate: extraconfig/tasks/yum_update.yaml $ openstack overcloud update stack -i overcloud -e /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.yaml When reached the 1st break point and do a : $ swift download overcloud extraconfig/tasks/yum_update.sh There is no change in the file served by swift. looking at the code: https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/v1/overcloud_deploy.py#L144 https://github.com/openstack/python-tripleoclient/blob/master/tripleoclient/v1/overcloud_update.py#L54 It seems the environment files aren't processed on update. Version-Release number of selected component (if applicable): OSP10 How reproducible: always Steps to Reproduce: 1. e.g. do a change to yum_update.sh 2. openstack overcloud update stack -i overcloud -e /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.yaml 3. when reach break point check file: $ swift download overcloud extraconfig/tasks/yum_update.sh Actual results: no updated content in swift Expected results: updated versions in swift when do rpm update and run overcloud update. Additional info:
Why are you passing overcloud-resource-registry-puppet.yaml as an environment file? I don't think it's necessary because it's used internally as the default resource registry anyways. I tried to test your use case, and I edited yum_update.sh and scaled out the cloud. I could see my changes in swift, so it works for me. The template files are uploaded to swift in the beginning of the Mistral flow (by the way it doesn't matter if they are referenced from any template/environment file or not). Can you check the bug again and tell me what I'm doing different?
I recreated the issue. The command "openstack overcloud update stack" really doesn't update the plan files in swift. The only way to update them is by "openstack overcloud deploy --update-plan-only --templates <templates_dir> --stack <stack_name>". It makes sense to expect that the update stack command will update the files as well, the same as deploy --update-plan-only command does, and we should see the files in swift updated regardless if there's an environmental file that refers to them or not (regardless which -e files you passed on the command line). The title of the bug that "tripleo client ignores environment file parameters" is a bit confusing. The environment files are not ignored, but currently they are not saved with the plan and there's a separate bug on that (in the case of the environmental file that appeared in this bug, overcloud-resource-registry-puppet.yaml, it happens to be saved in the plan because it's inside the templates directory and gets uploaded to swift with the rest of the files).
Minor updates were completely overhauled in OSP12, via https://bugs.launchpad.net/tripleo/+bug/1715557 . This means the swift plan now gets updated based on templates (although there may be a bug with non-default templates location, currently tracked at https://bugs.launchpad.net/tripleo/+bug/1745357 ). In OSP12 and 13, the -e/--environment argument no longer exists. In OSP10, the version mentioned in this bug, it was already deprecated according to the help message: usage: openstack overcloud update stack [-h] [--templates [TEMPLATES]] [-i] [-a] [-e <HEAT ENVIRONMENT FILE>] [--answers-file ANSWERS_FILE] [stack] Updates packages on overcloud nodes [...] -e <HEAT ENVIRONMENT FILE>, --environment-file <HEAT ENVIRONMENT FILE> Environment files to be passed to the heat stack- create or heat stack-update command. (Can be specified more than once.) This argument is deprecated. The command now utilizes a deployment plan, which should be updated prior to running this command, should that be required. Otherwise this argument will be silently ignored. Looking at the history, it looks like the message was updated to resolve another update issue: https://bugs.launchpad.net/tripleo/+bug/1626128 and completely resolving this ( https://bugs.launchpad.net/tripleo/+bug/1614928 ) was more intricate than expected and difficult to backport, so moved to Ocata / OSP11. Based on this I am closing the bug. It is no longer valid in OSP12 or 13 as the argument no longer exists, and it sounds like it is handled as best as could be done in OSP10 by updating both the docs to use --update-plan-only and the help message.