Looking at: https://github.com/rdo-management/python-rdomanager-oscplugin/blob/master/rdomanager_oscplugin/v1/overcloud_deploy.py#L364 This code is: - Downloading the templates - Generating the parameters to pass into the stack create - Creating the stack The plan is never updated in Tuskar, which means that if the user views the plan through the UI, it will show the defaults instead of what the user may have entered from the command line. The process should be: - Collect the parameters - Update the plan configuration in Tuskar with the plan parameters - Download the templates - Create the stack
We were not planning to update the Tuskar plan with the deploy parameters, but use the already existing commands for that. Currently deploying will ignore the parameters in the Tuskar plan but I'm working on changing that: See also: https://bugzilla.redhat.com/show_bug.cgi?id=1227873 There is also a patch to make it possible to load Tuskar parameters from a JSON file, but it's not required for this. https://bugzilla.redhat.com/show_bug.cgi?id=1227870
There is a review up that starts to move these defaults so they are sent to Tuskar when the undercloud is installed. https://review.gerrithub.io/#/c/236804/ This means that the defaults instack added will be visible in the UI and editable.
Patch for review: https://review.gerrithub.io/#/c/236804/
ON_DEV since the patch is posted for review
*** Bug 1233485 has been marked as a duplicate of this bug. ***
Another option is to set the deafaults in the Tuskar element, when installing: https://review.openstack.org/#/c/193868/1
Ben/Lennart, Which patch(es) do we need? I see 2 mentioned here: https://review.gerrithub.io/#/c/236804/ https://review.openstack.org/#/c/193868/1
AFAIK, that should do it. Lennart wrote the patches though so probably best for him to confirm.
Yes, although this one is closely related as well: https://review.gerrithub.io/#/c/237311/1 It does the same change for scaling parameters so that they do not override the Tuskar settings.
This is the same issue, with the same fixes, as 1227873. *** This bug has been marked as a duplicate of bug 1227873 ***