Red Hat Bugzilla – Bug 977674
REST-API: No concurrent option under first agent in power management
Last modified: 2016-02-10 14:06:33 EST
Created attachment 764952 [details]
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):
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:
No concurrent option under agent with order 1.
concurrent option under agent with order 1(true or false)
if added second agent you can see this option under agent with order 2.
link on feature documentation http://www.ovirt.org/Features/Design/DetailedHostPMMultipleAgents#API
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.
I posted a fix for this:
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.
(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
I agree with comment #3 we should use the order to dictate concurrency.
This will provide the necessary definition also for N fencing devices.
(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
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.
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.
(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.
Bug was closed as WONTFIX , no release notes are required