Bug 1005923

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.

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.

(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.

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.

Moving to rhevm-future as this will not make it into 3.4.

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.

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

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.