Created attachment 1336837 [details] Original cloud volume Description of problem: When you try to change a cloud volume in a service catalog it allows the change in the UI but the service catalog runs with the original cloud volume value. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Create a service item using Openstack with a cloud volume of 1 gig. 2. Order the service and notice that the 1 gig is the value used. 3. Modify/edit service provisioning dialog and change Cloud volume name to 'changed' with a value of 10 gig. 4. Save and order the updated service. 5. Notice the cloud volume is using the original (1 gig) and not the changed (10 gig) Actual results: Expected results: Additional info: You can look for this in the automation.log: Adding volume to storage: {:name=>"original_volume", :size=>"1"} Including screenshot of original and then changed ...
Created attachment 1336838 [details] Changed cloud volume
Please assess the impact of this issue and update the severity accordingly. Please refer to https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity for a reminder on each severity's definition. If it's something like a tracker bug where it doesn't matter, please set the severity to Low.
Sending to Openstack team to review: The logic that sets up the :volumes hash [1] only runs when the request is created but would also need to run when it is updated [2]. Having said that, is there a reason we are parsing this data upfront? It seems the data should be collected but the dialog and parsed when the task is running and about to use the data. This would allow for automate method to update the fields and would also avoid the issue being reported here. [1] https://github.com/ManageIQ/manageiq-providers-openstack/blob/master/app/models/manageiq/providers/openstack/cloud_manager/provision_workflow.rb#L23 [2] https://github.com/ManageIQ/manageiq/blob/master/app/models/miq_request_workflow.rb#L89
Automate scripts should be able to update the :volumes field directly. The volume form parser only has to populate that value when that information is being changed in the UI, since the volume form is dealing with certain limitations in the provisioning system. https://github.com/ManageIQ/manageiq/pull/16189 should fix the problem by causing set_request_values to happen on updates.
tested 3 times on RHOS 12, 5.9.0.21 BTW, works on 5.8.3.2: https://bugzilla.redhat.com/show_bug.cgi?id=1514570
Jad, I haven't been able to reproduce the failure you are seeing. Can you please provide more details on exactly what symptoms you are seeing on 5.9.0.21?
Sam, I just followed the Steps to Reproduce above. Before submitting provisioning request, I ordered a 1 GB volume After submitting, edited the request and changed volume size form 1 to 10 GB and click submit. I got a flash message stating the my request was resubmitted with required changes. What happened actually is that volume was created with original size (1 GB) You can take a look at 10.35.64.32: APP: 10.0.0.23
Jad, The steps to reproduce involve ordering an instance, then editing the catalog item, and then ordering a new instance to see whether the changes to the catalog took place. Your comment says that you ordered an instance, and while the request was being processed you edited the request itself. That's not the same set of steps. If you have auto-approval turned on (which is the default), then you might have edited the request only after it was already being processed by Openstack. I have tried it both ways, as described in the original comment (creating and then editing the catalog item), as well as creating and editing the request (with autoapproval turned off so that there is no risk of a race condition). In both cases, it works correctly. Can you please confirm whether you still see the problem when following the steps in the original report? Thanks!
Sam, I remember that I managed to verify this on 5.83 by following samesteps: https://bugzilla.redhat.com/show_bug.cgi?id=1514570 According to my understanding, the scenario is not talking creating new instance. During instance creation process, there a period of time were the user can edit the request and modify volume size among other parameters and them resubmitting. I followed this these steps on 5.8.3.2 over RHOS 12 and worked for me. Maybe the reporter o bug can shed some light on what he exactly meab on steps to reproduce Thanks!
HI William, Did you disable auto approve mode while provisioning the instance ?
Jadh, I don't think I needed to disable the auto-approval. I modified the dialog and then ordered the Catalog item again. Billy
Circling back on this, Jad, were you creating an instance and then editing the request, or were you ordering an instance, editing the service dialog, and then ordering again? This bug seems to be about the latter case. In any case, as far as I can tell the bug is fixed.
Sam, I will follow the second scenario when reproducing, but looks like i need to disable auto approval How could auto approval be disabled ?
Need help on creating Service dialog for provisioning instance via service catalog May you have a datastore with already configured Service dialog that can be imported to my env ?
Thanks Sam, very helpful instructions. According to your instructions, it is working now The bug can be moved to ON_QA to be verified
Verified on 5.9.4.7