Bug 1005923 - [RFE]vdsClient must have a confirmation message for active verbs that can change storage/network/other
[RFE]vdsClient must have a confirmation message for active verbs that can cha...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs (Show other bugs)
3.3.0
Unspecified Unspecified
medium Severity high
: ---
: ---
Assigned To: Dima Kuznetsov
Tareq Alayan
infra
: FutureFeature, Triaged
Depends On: 1101553 1101554
Blocks: 902971
  Show dependency treegraph
 
Reported: 2013-09-09 12:46 EDT by Marina
Modified: 2016-02-10 14:30 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-04-07 08:16:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
sherold: Triaged+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 28174 master ABANDONED client: Add warning prompt on dangerous commands Never

  None (edit)
Description Marina 2013-09-09 12:46:21 EDT
1. Proposed title of this feature request
vdsClient must have a confirmation message for active verbs that can change storage/network/other

2. Who is the customer behind the request?
Account: name (acct #) GSS
TAM customer: yes
SRM customer: yes
Strategic: yes

3. What is the nature and description of the request?
Add a confirmation message to vdsClient before proceeding with any of the active verbs that can actually change storage. 
For instance: deactivateStorageDomain, destroyStoragePool, reconstructMaster and many many others.

4. Why does the customer need this? (List the business requirements here)
vdsClient can change RHEV storage easily, but it will not update the database on the engine side.
This will result in a broken setup.
Documentation states it is not-supported, but who reads documentation until your setup is destroyed?
The tool should notify the user itself to be more transparent.
The customers do not understand what the tool actually does and it leads into some disastrous scenarios, that could be avoided, if the customers would not run those commands.

5. How would the customer like to achieve this? (List the functional requirements here)
The tool should let the user know:
- it is unsupported to run it without recommendation from an open support case.
- the change will be disruptive for the setup, since the tool does not update the engine.
The tool should not proceed, if user does not confirm.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
Just run the tool with one of such verbs and see what happens.

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
I could not find.

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
ASAP.

9. Is the sales team involved in this request and do they have any additional input?
No.

10. List any affected packages or components.
vdsm

11. Would the customer be able to assist in testing this functionality if implemented?
of course.
Comment 3 Mooli Tayer 2013-11-25 07:42:41 EST
I Understand a customer wanted this, However I think we should seriously consider again if we want this implemented. These are my reasons:

1.) Users of vdcClient should know and be responsible for what they are doing.
2.) This will break scripts (they will have to add a -y or something) and introduce a descent amount of code. 
3.) No matter how many yes/no we add you can always mess things up using vdsClient. It is not it's responsibility to safe guard users (like the UI should) taking this responsibility upon our self is problematic.

Want to close as won't fix.
Comment 4 Marina 2013-11-25 08:46:18 EST
Mooli.
This is exactly my problem.
Customers do not know what they are doing and why it is dangerous.
They thing - oh, nice tool, let's use it, without thinking about the implications and without knowing this tool is unsupported, and then somehow end up with ruined environment that sometimes no way to restore it..

If this is completely impossible to add a confirmation message, which I think is quite a must; we should at a very list to have a BIG CAPITAL WARNING LETTERs saying what will happen and that it may destroy their environment. And still, thinking about the consequences, I think we must have this confirmation step. IMO.
Comment 5 Mooli Tayer 2013-11-26 05:47:45 EST
(In reply to Marina from comment #4)

Hi Marina,

As developers There is no way for us to hide things altogether.
What ever interfaces that ovirt installs for its use are open
for inquisitive minds. Some use them wisely. It is better to
invest resources in making them better and that clashes with
writing them for someone not knowing what he is doing 
(that's what sandboxes are for).

This is my offer:
We raise the bar for using vdsClient.

Using selinux we make it optionally harder to access vdsClient.
ovirt-engine can continue talking to vdsClient but for users 
to use it they will need to do one of:

a.) disable some selinux boolean.
b.) make local policy changes.
c.) disable selinux altogether.

Users will basically need to gain permissions
beyond regular root.

That is under the assumption that selinux is enforcing.

This is currently under discussion with PM.

> Mooli.
> This is exactly my problem.
> Customers do not know what they are doing and why it is dangerous.
> They thing - oh, nice tool, let's use it, without thinking about the
> implications and without knowing this tool is unsupported, and then somehow
> end up with ruined environment that sometimes no way to restore it..
> 
> If this is completely impossible to add a confirmation message, which I
> think is quite a must; we should at a very list to have a BIG CAPITAL
> WARNING LETTERs saying what will happen and that it may destroy their
> environment. And still, thinking about the consequences, I think we must
> have this confirmation step. IMO.
Comment 9 Barak 2013-12-26 06:36:21 EST
Arthur,

I share Mooli's opinion, the vdsCli is not officially supported (there only for debug). So there are 3 options:

1 - not install vdsClient altogether (sos report use it ... need to handle it ??)
2 - handle it through SELinux policy as suggested above (still open sos issue)
3 - Add the warning in vdsClient and a confirmation question to all the "destructive" API calls. 

Personally I would close this RFE as won't fix, a person with root access to the machine has so many ways to do destructive operation that this is not that significant.

However if PM would like to go a head with option 3 above, such a generic infra is not that hard to add, the only missing data is the list of destructive API calls to protect. 

Till such list is provided we will not proceed with implementation.

If you wish to push it forward please work with GSS to define the list.
Comment 10 Barak 2013-12-26 06:38:17 EST
Moving to rhevm-future as this will not make it into 3.4.
Comment 12 Marina 2013-12-26 11:55:11 EST
1. I we cannot avoid customers using the tool, why not to make it better and less disruptive? We all would benefit out of it.
2. I agree with derrick. Disclaimer + a flag to disable confirmation message sounds like a good idea to me.

3. As for the list of the commands, here is what I think should be protected. But I might be missing something, if I do - please add.
The logic I am following is that basically any storage/network command that would change the system without notifying the database and cause incosistency that is not recoverable from the manager (for instance - migrated VM status will be updated on the manager relatively fast and would not cause much danger; while deleting and image is irrecoverable and does not perform all the confirmations UI does):

deactivateStorageDomain
destroyStoragePool
reconstructMaster
delNetwork
deleteImage
deleteVolume
deleteVolumeByDescr
destroyStoragePool
editNetwork
extendStorageDomain
extendVolume
forcedDetachStorageDomain
formatStorageDomain
mergeSnapshots
moveImage
moveMultiImage
reconstructMaster
releaseDomainLock - not sure
removeVG
not sure about SPM commands.
Comment 13 Barak 2014-04-08 07:39:09 EDT
Arthur,

I don't think this is RFE shouyld make it into the vdsCli,
But if you want to push it forward please define:
- general message for all api calls that you want to warn about.
- go over the list of APIs and approve them
Comment 14 Arthur Berezin 2014-05-08 14:14:42 EDT
ACK on following list:

deactivateStorageDomain 
destroyStoragePool 
reconstructMaster 
deleteImage 
deleteVolume 
deleteVolumeByDescr 
destroyStoragePool 
extendStorageDomain
extendVolume 
forcedDetachStorageDomain 
formatStorageDomain
mergeSnapshots 
moveImage 
moveMultiImage 
reconstructMaster
releaseDomainLock
removeVG 



"Please note that vdsClient is not a supported tool and should be used only with direct guidance from support representative.
This operation might cause data corruption, would you like to proceed?
[_n][Y]"

No|n|N|RETURN which is default cancels operation.

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