Bug 1597471 - 'Add to Flavor ~ was successfully initialized' is shown even if a request of creating flavor fails
Summary: 'Add to Flavor ~ was successfully initialized' is shown even if a request of ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.9.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: GA
: 5.10.0
Assignee: Gilles Dubreuil
QA Contact: Dave Johnson
URL:
Whiteboard:
Depends On:
Blocks: 1610131
TreeView+ depends on / blocked
 
Reported: 2018-07-03 01:49 UTC by Keigo Noha
Modified: 2022-03-13 15:11 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1610131 (view as bug list)
Environment:
Last Closed: 2018-07-31 03:28:52 UTC
Category: ---
Cloudforms Team: Openstack
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
List of tasks (352.77 KB, image/png)
2018-07-05 02:21 UTC, Gilles Dubreuil
no flags Details

Description Keigo Noha 2018-07-03 01:49:45 UTC
Description of problem:
'Add to Flavor ~ was successfully initialized' is shown even if a request of creating flavor fails

Version-Release number of selected component (if applicable):
5.9.2

How reproducible:
Everytime

Steps to Reproduce:
1. Launch CFME
2. Setup Provider for packstack installed OSP environment.
3. Add provider for admin project and demo project.
4. Try to create a flavor to demo project.

Actual results:
The message, 'Add to Flavor ~ was successfully initialized', is shown

Expected results:
A different error message should be shown.

Additional info:
In OSP, creating flavor is allowed to admin project only.
If the user, even if admin user, tries to create a flavor to non-admin project,
the request is rejected with 'Policy doesn't allow os_compute_api:os-flavor-manage to be performed.'

In /var/www/miq/vmdb/log/evm.log, the error message is logged.
~~~
[----] I, [2018-07-03T10:35:38.106004 #2195:ab2da4]  INFO -- : MIQ(MiqQueue.put) Message id: [1177000000017485],  id: [], Zone: [default], Role: [ems_operations], Server: [], Ident: [generic], Target id: [], Instance id: [], Task id: [], Command: [Flavor.create_flavor], Timeout: [600], Priority: [100], State: [ready], Deliver On: [], Data: [], Args: [1177000000000013, {"name"=>"test_demoenv", "ram"=>"1024", "vcpus"=>"1", "disk"=>"5", "swap"=>"5", "rxtx_factor"=>"1.0", "is_public"=>true, "ems_id"=>"", "ems"=>{"id"=>1177000000000013, "name"=>"rhosp10-testuser", "created_on"=>"2018-07-02T14:24:18.319+09:00", "updated_on"=>"2018-07-03T09:56:58.904+09:00", "guid"=>"da17951c-3840-4857-a006-4fb833892582", "zone_id"=>1177000000000001, "api_version"=>"v2", "uid_ems"=>nil, "host_default_vnc_port_start"=>nil, "host_default_vnc_port_end"=>nil, "provider_region"=>"", "last_refresh_error"=>"Expected(200) <=> Actual(500 InternalServerError)\nexcon.error.response\n  :body          => \"{\\\"explanation\\\": \\\"The server has either erred or is incapable of performing the requested operation.\\\", \\\"code\\\": 500, \\\"error\\\": {\\\"message\\\": \\\"Remote error: Conflict Instance a9248fb4-11f5-4725-9e37-02c83164e7cc is not ready (HTTP 409) (Request-ID: req-5e7c2862-1e38-489d-8f9c-0a1281218c5f)\\\\n[u'\\\", \\\"traceback\\\": null, \\\"type\\\": \\\"RemoteError\\\"}, \\\"title\\\": \\\"Internal Server Error\\\"}\"\n  :cookies       => [\n  ]\n  :headers       => {\n    \"Content-Length\"         => \"368\"\n    \"Content-Type\"           => \"application/json; charset=UTF-8\"\n    \"Date\"                   => \"Tue, 03 Jul 2018 00:56:58 GMT\"\n    \"X-Openstack-Request-Id\" => \"req-2288cf68-d0f3-486f-812d-1d75805bf8fe\"\n  }\n  :host          => \"192.168.122.158\"\n  :local_address => \"192.168.122.127\"\n  :local_port    => 55318\n  :path          => \"/v1/9bf1cb51f3ce45869466774455345978/stacks/demoSTACK/d49c81bd-3e35-4c02-a20e-260b043edcf4\"\n  :port          => 8004\n  :reason_phrase => \"Internal Server Error\"\n  :remote_ip     => \"192.168.122.158\"\n  :status        => 500\n  :status_line   => \"HTTP/1.1 500 Internal Server Error\\r\\n\"\n", "last_refresh_date"=>"2018-07-03T09:56:58.893+09:00", "provider_id"=>nil, "realm"=>nil, "tenant_id"=>1177000000000001, "project"=>nil, "parent_ems_id"=>nil, "subscription"=>nil, "last_metrics_error"=>nil, "last_metrics_update_date"=>nil, "last_metrics_success_date"=>nil, "tenant_mapping_enabled"=>true, "enabled"=>true, "options"=>{}, "$$hashKey"=>"object:20"}}]
[----] I, [2018-07-03T10:35:38.106118 #2195:ab2da4]  INFO -- : MIQ(MiqTask.generic_action_with_callback) Task: [1177000000000102] Queued the action: [Creating flavor for user 1177000000000001] being run for user: [1177000000000001]
[----] I, [2018-07-03T10:35:38.424270 #1847:745108]  INFO -- : MIQ(MiqServer#populate_queue_messages) Fetched 1 miq_queue rows for queue_name=generic, wcount=4, priority=200
[----] I, [2018-07-03T10:35:39.273905 #2121:745108]  INFO -- : MIQ(MiqGenericWorker::Runner#get_message_via_drb) Message id: [1177000000017485], MiqWorker id: [1177000000000099], Zone: [default], Role: [ems_operations], Server: [], Ident: [generic], Target id: [], Instance id: [], Task id: [], Command: [Flavor.create_flavor], Timeout: [600], Priority: [100], State: [dequeue], Deliver On: [], Data: [], Args: [1177000000000013, {"name"=>"test_demoenv", "ram"=>"1024", "vcpus"=>"1", "disk"=>"5", "swap"=>"5", "rxtx_factor"=>"1.0", "is_public"=>true, "ems_id"=>"", "ems"=>{"id"=>1177000000000013, "name"=>"rhosp10-testuser", "created_on"=>"2018-07-02T14:24:18.319+09:00", "updated_on"=>"2018-07-03T09:56:58.904+09:00", "guid"=>"da17951c-3840-4857-a006-4fb833892582", "zone_id"=>1177000000000001, "api_version"=>"v2", "uid_ems"=>nil, "host_default_vnc_port_start"=>nil, "host_default_vnc_port_end"=>nil, "provider_region"=>"", "last_refresh_error"=>"Expected(200) <=> Actual(500 InternalServerError)\nexcon.error.response\n  :body          => \"{\\\"explanation\\\": \\\"The server has either erred or is incapable of performing the requested operation.\\\", \\\"code\\\": 500, \\\"error\\\": {\\\"message\\\": \\\"Remote error: Conflict Instance a9248fb4-11f5-4725-9e37-02c83164e7cc is not ready (HTTP 409) (Request-ID: req-5e7c2862-1e38-489d-8f9c-0a1281218c5f)\\\\n[u'\\\", \\\"traceback\\\": null, \\\"type\\\": \\\"RemoteError\\\"}, \\\"title\\\": \\\"Internal Server Error\\\"}\"\n  :cookies       => [\n  ]\n  :headers       => {\n    \"Content-Length\"         => \"368\"\n    \"Content-Type\"           => \"application/json; charset=UTF-8\"\n    \"Date\"                   => \"Tue, 03 Jul 2018 00:56:58 GMT\"\n    \"X-Openstack-Request-Id\" => \"req-2288cf68-d0f3-486f-812d-1d75805bf8fe\"\n  }\n  :host          => \"192.168.122.158\"\n  :local_address => \"192.168.122.127\"\n  :local_port    => 55318\n  :path          => \"/v1/9bf1cb51f3ce45869466774455345978/stacks/demoSTACK/d49c81bd-3e35-4c02-a20e-260b043edcf4\"\n  :port          => 8004\n  :reason_phrase => \"Internal Server Error\"\n  :remote_ip     => \"192.168.122.158\"\n  :status        => 500\n  :status_line   => \"HTTP/1.1 500 Internal Server Error\\r\\n\"\n", "last_refresh_date"=>"2018-07-03T09:56:58.893+09:00", "provider_id"=>nil, "realm"=>nil, "tenant_id"=>1177000000000001, "project"=>nil, "parent_ems_id"=>nil, "subscription"=>nil, "last_metrics_error"=>nil, "last_metrics_update_date"=>nil, "last_metrics_success_date"=>nil, "tenant_mapping_enabled"=>true, "enabled"=>true, "options"=>{}, "$$hashKey"=>"object:20"}}], Dequeued in: [1.175226473] seconds
[----] I, [2018-07-03T10:35:39.274080 #2121:745108]  INFO -- : MIQ(MiqQueue#deliver) Message id: [1177000000017485], Delivering...
[----] I, [2018-07-03T10:35:39.285032 #2121:745108]  INFO -- : MIQ(ManageIQ::Providers::Openstack::CloudManager#with_provider_connection) Connecting through ManageIQ::Providers::Openstack::CloudManager: [rhosp10-testuser]
[----] E, [2018-07-03T10:35:40.267465 #2121:745108] ERROR -- : MIQ(ManageIQ::Providers::Openstack::CloudManager::Flavor.raw_create_flavor) flavor=[ManageIQ::Providers::Openstack::CloudManager::Flavor], error=[Expected(200) <=> Actual(403 Forbidden)
excon.error.response
  :body          => "{\"forbidden\": {\"message\": \"Policy doesn't allow os_compute_api:os-flavor-manage to be performed.\", \"code\": 403}}"
  :cookies       => [
  ]
  :headers       => {
    "Content-Length"               => "112"
    "Content-Type"                 => "application/json; charset=UTF-8"
    "Date"                         => "Tue, 03 Jul 2018 01:35:40 GMT"
    "Openstack-Api-Version"        => "compute 2.15"
    "Vary"                         => "OpenStack-API-Version, X-OpenStack-Nova-API-Version"
    "X-Compute-Request-Id"         => "req-2e4401e4-d9b0-4d47-8abf-475114f9fb8b"
    "X-Openstack-Nova-Api-Version" => "2.15"
  }
  :host          => "192.168.122.158"
  :local_address => "192.168.122.127"
  :local_port    => 41394
  :path          => "/v2.1/9bf1cb51f3ce45869466774455345978/flavors"
  :port          => 8774
  :reason_phrase => "Forbidden"
  :remote_ip     => "192.168.122.158"
  :status        => 403
  :status_line   => "HTTP/1.1 403 Forbidden\r\n"
]
[----] E, [2018-07-03T10:35:40.267812 #2121:745108] ERROR -- : MIQ(MiqQueue#deliver) Message id: [1177000000017485], Error: [Policy doesn't allow os_compute_api:os-flavor-manage to be performed.]
[----] I, [2018-07-03T10:35:40.267932 #2121:745108]  INFO -- : MIQ(MiqQueue#delivered) Message id: [1177000000017485], State: [error], Delivered in [0.993855266] seconds
[----] I, [2018-07-03T10:35:40.269887 #2121:745108]  INFO -- : MIQ(MiqQueue#m_callback) Message id: [1177000000017485], Invoking Callback with args: ["Finished", "error", "Policy doesn't allow os_compute_api:os-flavor-manage to be performed.", "nil"]
[----] I, [2018-07-03T10:35:40.270191 #2121:745108]  INFO -- : MIQ(MiqTask#update_status) Task: [1177000000000102] [Finished] [Error] [Policy doesn't allow os_compute_api:os-flavor-manage to be performed.]
~~~

So, the message in UI should show this error for user to take the next action in the user side.

Comment 2 Gilles Dubreuil 2018-07-05 02:20:25 UTC
I don't think this is a bug, let me explain why.

Effectively, on the OpenStack side of things, Nova policy forbids, by default, non admin user to manage flavors: "compute_extension:flavormanage": "rule:admin_api"

Meanwhile, this default policy can be changed, for example by emptying the above rule allowing projects to handle their own flavors.
In which case CloudForms would not provide such warning when a non admin user hanldes flavors.

Also, there is no direct way for CloudForms to check the Nova policy in place in the policy.json and therefore validating the current user against the flavors actions won't work. In other words, we can't check the user is admin as the policy can be changed. 

On the UI side, the initial message, for instance 'Add of Flavor "blah" was successfully initialized', is because the request (of adding a flavor) has been submitted to the task queue, that's the way the UI works, asynchronously. Later on the tasks fails, that can be seen in the evm.log but the user needs to check the tasks list available from the User tab (Top right): "Tasks -> All Tasks". See attached capture.

Comment 3 Gilles Dubreuil 2018-07-05 02:21:11 UTC
Created attachment 1456631 [details]
List of tasks

Comment 4 Gilles Dubreuil 2018-07-05 06:05:55 UTC
As this is an architectural constraint, a new feature to obtain a different behaviour such as "blocking users to modify flavors unless they are allowed to"  would require:

- To add the function to either obtain the policy status a of Nova cluster alternatively once might be tempted to work on the side effect of a failed connection (initiate a flavor change request and trap it). 

Create a RFE accordingly if desired.

Thank you.

Comment 5 Keigo Noha 2018-07-09 00:59:14 UTC
Hello Gilles,

Thank you for your update.
I don't agree with your opinion. Could you consider following points?

If a newbie of ManageIQ/CMFE sees the message, he/she will think 'OK, my request was accepted and it will be going well.'.
But the actual meaning of the message just said that 'Your request is accepted into the queue. You need to check the result in other pages'.
The asynchronous behavior is desired and an expected behavior in its architecture. I completely understand this behavior.

On the other hand, we need to think that the UI is really easy to understand and  can be manipulated without special knowledge or shown message clearly states what happens and what the user should do for the next.

My opinion to the message is that the message needs to contain that the request is into the queue successfully. You need to check the Task page to know whether the request was successfully processed or not.(The message should contain the link to the task page.).

How do you think about it?

Best Regards,
Keigo Noha

Comment 6 Gilles Dubreuil 2018-07-09 02:41:57 UTC
Hi Keigo,

Thank you for your feedback.

You've got a good point about having the request's message providing details/link to the tasks list.

I believe the feature should be defined as a RFE in order to implement it for all tasks to benefit from it and not having to update each request independently.

Comment 10 Gilles Dubreuil 2018-07-31 03:28:52 UTC
We confirm this is not a bug meanwhile and to be addressed with BZ#1610131


Note You need to log in before you can comment on or make changes to this bug.