Bug 977674

Summary: REST-API: No concurrent option under first agent in power management
Product: Red Hat Enterprise Virtualization Manager Reporter: Artyom <alukiano>
Component: ovirt-engine-restapiAssignee: Ori Liel <oliel>
Status: CLOSED WONTFIX QA Contact: Pavel Stehlik <pstehlik>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.4.0CC: acathrow, bazulay, emesika, iheim, jkt, juan.hernandez, juwu, oliel, oramraz, pstehlik, Rhev-m-bugs
Target Milestone: ---Keywords: Triaged
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Linux   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-14 09:07:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
engine.log none

Description Artyom 2013-06-25 06:44:23 UTC 
Created attachment 764952 [details]
engine.log

Description of problem:
No concurrent option under agent with order 1, if added second agent you can see this option under agent with order 2.

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


How reproducible:
Add host and configure power management with some user, password and address
Go to rest api https://[rhevm_address]/api/hosts
Find under your host power management, under power management agents
Find agent with order 1.

Steps to Reproduce:
1.
2.
3.

Actual results:
No concurrent option under agent with order 1.

Expected results:
concurrent option under agent with order 1(true or false)

Additional info:
if added second agent you can see this option under agent with order 2.
Comment 1 Artyom 2013-06-25 07:44:24 UTC 
rhevm sf18
link on feature documentation http://www.ovirt.org/Features/Design/DetailedHostPMMultipleAgents#API
Comment 2 Barak Dagan 2013-06-25 10:53:00 UTC 
IMHO, there is no point to have the concurrent tag under each agent, since to have concurrency all of the two agents need to have the same value. This tag should / attribute should belong to higher level such as the agents or the power_management itself.
Comment 3 Ori Liel 2013-11-27 13:33:42 UTC 
I posted a fix for this: 

  http://gerrit.ovirt.org/21781

But there's a complication we should consider: now that 'concurrent' is displayed for both agents, how should 'update' behave? The user might update only one of the them, or both - but with contradictory values. These options didn't exist while 'concurrent' only appeared in the secondary agent. 

Since up until now, updating 'concurrent' was done in the second agent only, this should still work, or we'd be breaking API. To be symmetrical, we should probably also allow updating 'concurrent' using only the first agent. And if the user tried to update both 'concurrent' fields with contradictory values, that should fail validation. 

On top of this, I want to point out the I think 'concurrent' field should be deprecated; the existing 'order' field is enough. To make both agent concurrent, simply give them the same order number. This solution also scales to 3 or more agents.
Comment 4 Eli Mesika 2013-11-27 14:38:04 UTC 
(In reply to Ori Liel from comment #3)

> On top of this, I want to point out the I think 'concurrent' field should be
> deprecated; the existing 'order' field is enough. To make both agent
> concurrent, simply give them the same order number. This solution also
> scales to 3 or more agents.

Basically agree, it means that we should have to persist the order and get rid of the concurrent plag , however , this is a slightly big chnage that we may get to in 3.5
Comment 5 Barak 2013-12-30 10:37:54 UTC 
I agree with comment #3 we should use the order to dictate concurrency.
This will provide the necessary definition also for N fencing devices.
Comment 6 Eli Mesika 2014-01-02 11:35:00 UTC 
(In reply to Barak from comment #5)
> I agree with comment #3 we should use the order to dictate concurrency.
> This will provide the necessary definition also for N fencing devices.

Agree as well, Only concern is that this BZ is targeted to 3.4 and I think we could not make it to 3.4

We have to

1) create a separate table vds_pm_agent
2) change the code all around including API to use this table
3) handle the db upgrade
4) test that we have no regressions 

IMHO this is for 3.5
Comment 7 Barak 2014-07-14 09:07:21 UTC 
The code is being refactored for 3.6.
I'm closing this bug as WONTFIX, as this is a minor detail that will be changed for next version.

In addition the cuncurent flag on the first power-management card might be confusing when no second card is added.
Comment 8 Julie 2014-09-17 11:54:35 UTC 
Hi Ori,
   I see this bug has been flagged for release notes. Please select the correct Doc Type and provide the doc text ASAP for this bugs to make it in the 3.5 Beta Manager Release Notes. Please set the require_release_note flag to - if no doc text is required.

Cheers,
Julie
Comment 9 Eli Mesika 2014-09-17 12:27:33 UTC 
(In reply to Julie from comment #8)
> Hi Ori,
>    I see this bug has been flagged for release notes. Please select the
> correct Doc Type and provide the doc text ASAP for this bugs to make it in
> the 3.5 Beta Manager Release Notes. Please set the require_release_note flag
> to - if no doc text is required.
> 
> Cheers,
> Julie

Bug was closed as WONTFIX , no release notes are required