Description of problem: Service has parent service defined ("ancestry": "<parent_id>"). When retiring parent service, child service is not retired. Version-Release number of selected component (if applicable): 5.10.0.4 How reproducible: always Steps to Reproduce: 1. create two services POST /api/services { "action": "create", "resources": [ {"name": "test_rest_1", "description": "test service 1"}, {"name": "test_rest_2", "description": "test service 2"} ] } 2. make the first service parent to the second service POST /api/services/:first_service_id { "action": "add_resource", "resource": { "resource": {"href": "https://<addr>/api/services/:second_service_id"} } } 3. retire the first (parent) service POST /api/services/:first_service_id { "action": "retire" } 4. check retirement POST /api/services { "action": "query", "resources": [ { "id": <first_service_id> }, { "id": <second_service_id> } ] } Actual results: Parent (first) service is retired, child (second) service is not retired. Expected results: Parent (first) service is retired, child (second) service is also retired.
- it is a regression - it behaves the same when the services were added using UI UI Test Scenario: 1. create a service catalog item 2. create a service catalog bundle and specify the service catalog item created in step 1 as a resource 3. order Service Bundle 4. retire Service Bundle => only parent service is retired
@Martin, can you tell me please if this worked in Fine?
Similar issue was fixed on 5.8.3.0, see https://bugzilla.redhat.com/show_bug.cgi?id=1496936 and it works as expected (both services are retired) on 5.9.4.1
Could I please have a working 5.8.3.0 example of this?
I don't have any 5.8 appliance at my disposal, we don't test on 5.8 anymore. It works as expected on 5.9 (both parent and child services are retired), you can test it there. You can easily reproduce it by yourself using the REST requests in the bug description, there's no special setup needed. Let me know if you need help with any specific step.
The API call listed as the second setup in this bug's setup is wrong. The API call does not work as stated in the description. Which is why I was hoping for a reproducer. For anyone looking at this ticket in the future, the correct call to add a resource to a service is fixed in our documentation here: https://github.com/ManageIQ/manageiq_docs/pull/918 @Martin, can you please retest with the correct setup?
Drew, you can see in the description of this BZ that the request I originally posted is the same as the one described in the documentation (no extra brackets), i.e. correct. The proof that it's working - the response for exactly the same request I already posted: { "success": true, "message": "Assigned resource services id:4 to Service id:3 name:'test_rest_1'" } Also GET /api/services/4 { ... ancestry: 3 ... } meaning service with id 4 is now ancestor of service with id 3, as expected. Question: Have you tested the requests I posted? Can you reproduce the issue on 5.10.0.4 ?
https://github.com/ManageIQ/manageiq/pull/17784
Hey Martin, I'm sorry for the confusion. This was opened as an API bug, which is partially why I was confused. I really don't think it is an API bug. In our documentation for latest, for g (https://manageiq.org/docs/reference/gaprindashvili/api/reference/services#service-add-remove-resources), and for f (https://manageiq.org/docs/reference/fine/api/reference/services#service-add-remove-resources), we have the exact same api call and it's different than what you have listed in your setup. I was running the call in the docs, which is wrong, and fails silently -- hence the request for the reproducer. The PR listed in comment 9 will fix the documentation on latest. You're correct, this is a verifiable automate bug on 5.10.0.4.
https://github.com/ManageIQ/manageiq/pull/17912 (the 5.9 PR is here: https://github.com/ManageIQ/manageiq/pull/17881)
Changing component to Automate per comment 12
https://github.com/ManageIQ/manageiq/pull/18184
New commits detected on ManageIQ/manageiq/hammer: https://github.com/ManageIQ/manageiq/commit/274cb014a392b7169a06d663336f004d33157587 commit 274cb014a392b7169a06d663336f004d33157587 Author: Madhu Kanoor <mkanoor> AuthorDate: Wed Nov 14 11:54:56 2018 -0500 Commit: Madhu Kanoor <mkanoor> CommitDate: Wed Nov 14 11:54:56 2018 -0500 Merge pull request #18184 from d-m-u/1608958 Don't create retire subtasks for service templates (cherry picked from commit a1ba9b09c282016952357de3669157d73b33253d) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1608958 app/models/service_template.rb | 4 + spec/models/service_retire_task_spec.rb | 19 + 2 files changed, 23 insertions(+)
https://github.com/ManageIQ/manageiq/pull/18251 and https://github.com/ManageIQ/manageiq/pull/18252 are relevant to this as well, sorry.
Hey Tasos! Any chance you could retest for me on that appliance, please? I've applied a change that will likely fix this.
Service retirement now errors out, leaving the service in a status of Pending. There is a recursion error in evm.log: **** [...] [----] I, [2018-12-17T15:15:24.231290 #9353:10c2f8c] INFO -- : Q-task_id([r31_service_retire_request_31]) MIQ(ServiceRetireTask#after_request_task_create) - creating service tasks for service <ServiceRetireTask :4426> [----] I, [2018-12-17T15:15:24.248137 #9353:10c2f8c] INFO -- : Q-task_id([r31_service_retire_request_31]) MIQ(ServiceRetireTask#after_request_task_create) - creating service tasks for service <ServiceRetireTask :4427> [----] I, [2018-12-17T15:15:24.263667 #9353:10c2f8c] INFO -- : Q-task_id([r31_service_retire_request_31]) MIQ(ServiceRetireTask#after_request_task_create) - creating service tasks for service <ServiceRetireTask :4428> [----] I, [2018-12-17T15:15:24.279035 #9353:10c2f8c] INFO -- : Q-task_id([r31_service_retire_request_31]) MIQ(ServiceRetireTask#after_request_task_create) - creating service tasks for service <ServiceRetireTask :4429> [----] I, [2018-12-17T15:15:24.294907 #9353:10c2f8c] INFO -- : Q-task_id([r31_service_retire_request_31]) MIQ(ServiceRetireTask#after_request_task_create) - creating service tasks for service <ServiceRetireTask :4430> [----] I, [2018-12-17T15:15:24.310826 #9353:10c2f8c] INFO -- : Q-task_id([r31_service_retire_request_31]) MIQ(ServiceRetireTask#after_request_task_create) - creating service tasks for service <ServiceRetireTask :4431> /usr/share/ruby/psych/visitors/visitor.rb:16:in `visit': stack level too deep (SystemStackError) [...] from /var/www/miq/vmdb/app/models/service_retire_task.rb:63:in `block in create_task' from /var/www/miq/vmdb/app/models/service_retire_task.rb:54:in `tap' from /var/www/miq/vmdb/app/models/service_retire_task.rb:54:in `create_task' from /var/www/miq/vmdb/app/models/service_retire_task.rb:44:in `block in create_retire_subtasks' from /opt/rh/cfme-gemset/gems/activerecord-5.0.7.1/lib/active_record/relation/delegation.rb:38:in `collect' from /opt/rh/cfme-gemset/gems/activerecord-5.0.7.1/lib/active_record/relation/delegation.rb:38:in `collect' from /var/www/miq/vmdb/app/models/service_retire_task.rb:34:in `create_retire_subtasks' from /var/www/miq/vmdb/app/models/service_retire_task.rb:30:in `after_request_task_create' from /var/www/miq/vmdb/app/models/service_retire_task.rb:46:in `block in create_retire_subtasks' from /opt/rh/cfme-gemset/gems/activerecord-5.0.7.1/lib/active_record/relation/delegation.rb:38:in `collect' from /opt/rh/cfme-gemset/gems/activerecord-5.0.7.1/lib/active_record/relation/delegation.rb:38:in `collect' from /var/www/miq/vmdb/app/models/service_retire_task.rb:34:in `create_retire_subtasks' from /var/www/miq/vmdb/app/models/service_retire_task.rb:30:in `after_request_task_create' from /var/www/miq/vmdb/app/models/service_retire_task.rb:46:in `block in create_retire_subtasks' [...] ****
Alright, take two. Sorry about this, but do you mind retesting one more time for me please?
This code on master has the no-op here: https://github.com/ManageIQ/manageiq/blob/hammer/app/models/service/retirement_management.rb#L11 which the listed appliance doesn't have, and I suspect that's why the stack level too deep error from the previous testing request. I and Tina are in the process of discussing what the final retirement changes should look like, and so while my retesting request in comment 23 is valid and definitely still applicable I'm not sure why the no-op isn't on that appliance to start with.
Sorry, comment 24 was about code on hammer, not master.
Hi, I still see the same recursion error.
Hey, we're having trouble provisioning on master at the moment and it's been a long couple weeks with the break. I'm sorry about this but may I please have another reproducer?
https://github.com/ManageIQ/manageiq/pull/18283
Errors should be fixed by https://github.com/ManageIQ/manageiq/pull/18348.
The validation errors shown in comment 32 do not prevent retirement from succeeding. Comment 32 states: "On 5.10.0.31, both the parent and child service now get retired, but there are errors logged to evm.log:" The PR in comment 33 resolves the validation error.
Issue being tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1666834
Verified on 5.10.0.31.