Red Hat Bugzilla – Bug 1005923
[RFE]vdsClient must have a confirmation message for active verbs that can change storage/network/other
Last modified: 2016-02-10 14:30:42 EST
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
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)?
9. Is the sales team involved in this request and do they have any additional input?
10. List any affected packages or components.
11. Would the customer be able to assist in testing this functionality if implemented?
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.
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)
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.
> 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.
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):
releaseDomainLock - not sure
not sure about SPM commands.
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:
"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?
No|n|N|RETURN which is default cancels operation.