Bug 1255114

What is the basis of this request? Is it a Fedora/EL packaging standard?

In my opinion, logs must NOT be dropped when a package is removed.
Modified conf files should be kept, too. As well as the ovirtmgmt network that was created per Engine's request.

The only thing that might be relevant, is to remove the vdsm-created /etc/libvirt/nwfilter/vdsm-no-mac-spoofing.xml when Vdsm is unconfigured. This, too, may hurt the use case of removing Vdsm while VMs are running.

Yeela - consult the list of things that should be removed with Dan and Yaniv, and implement accordingly.

It was standard RHEL7 installation

OK after your explanation, logs and configuration files are relevant to keep

Bug can be closed

Hi, sorry I disagree here. These leftovers causes issues. I can agree on logs, changed configs (and these should be handled by RPM themselves - .rpmnew .rpmold). 
But there are some more files left, which shouldn't. Especially weird vdsm DB for network interfaces. VDSM itself apparently don't solve this case.
Please reconsider, and better fix this bug.

(In reply to Pavel Stehlik from comment #4)
> Hi, sorry I disagree here. These leftovers causes issues. I can agree on
> logs, changed configs (and these should be handled by RPM themselves -
> .rpmnew .rpmold). 
> But there are some more files left, which shouldn't. Especially weird vdsm
> DB for network interfaces. VDSM itself apparently don't solve this case.
> Please reconsider, and better fix this bug.

Please specify a list of things you've identified that remain and you want to be deleted.

/run/libvirt/network/vdsm-ovirtmgmt.xml
/etc/pki/vdsm
/var/lib/vdsm
/usr/share/vdsm
/usr/lib/firewalld/services/vdsm.xml

and based on c#1 also all unchanged (default) config files vdsm package created.

(In reply to Pavel Stehlik from comment #6)
> /run/libvirt/network/vdsm-ovirtmgmt.xml
> /etc/pki/vdsm
> /var/lib/vdsm
> /usr/share/vdsm
> /usr/lib/firewalld/services/vdsm.xml
> 
> and based on c#1 also all unchanged (default) config files vdsm package
> created.

I'm surprised TPS or Errata tests are not complaining about these.

I agree that all leftovers undre /usr/share/vdsm and I am taking care of it.

/run/libvirt/network/vdsm-ovirtmgmt.xml should not be removed, when taking into consideration comment#1.

Dan,
What do you think about the rest in comment#6?

Pavel,
Do you have any fedora guidelines to work by,
so we can be sure to determine the correct files to be removed.

vdsm data directory and vdsm python lib are removed by:   
oVirt gerrit 48706

(In reply to Yeela Kaplan from comment #9)
> Pavel,
> Do you have any fedora guidelines to work by,
> so we can be sure to determine the correct files to be removed.
> 
> vdsm data directory and vdsm python lib are removed by:   
> oVirt gerrit 48706

No, I don't have any specific Fedora, but this is more standard LSB and RPM guideline.

I think that 

 /etc/pki/vdsm
 /var/lib/vdsm
 /usr/lib/firewalld/services/vdsm.xml

can all be safely removed. However, users may be a bit surprised that after removing Vdsm and reinstalling it, the host must be re-added to Engine (in order to recreate the keys and firewall rules).

I will refer to all paths mentioned originally as to what should or should not be removed and why.

1. /run/libvirt/network/vdsm-ovirtmgmt.xml
    should not be removed, when taking into consideration comment#1.

2. The following should not be removed as it hurts the user experience when working with engine (take a look at comment#11):
   /etc/pki/vdsm
   /etc/pki/vdsm/certs/vdsmcert.pem
   /etc/pki/vdsm/keys/vdsmkey.pem
   /var/lib/vdsm
   /usr/lib/firewalld/services/vdsm.xml
   /etc/vdsm/vdsm.id

3. logs should not be removed. May be needed even if vdsm is no longer installed:
   /var/log/vdsm 
   /var/log/vdsm/supervdsm.log
   /var/log/vdsm/vdsm.log

4. mom's files which are not under vdsm's directories should not be removed by us:
   /usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmInterface.py
   /usr/lib/python2.7/site-packages/mom/HypervisorInterfaces
/vdsmxmlrpcInterface.py
   /usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmInterface.pyc
   /usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmInterface.pyo

5. The following have been removed by oVirt gerrit 48706:
   /usr/share/vdsm
   /usr/lib/python2.7/site-packages/vdsm

6. libvirt should not be touched as well: 
   /etc/libvirt/nwfilter/vdsm-no-mac-spoofing.xml
   /etc/libvirt/qemu/networks/autostart/vdsm-ovirtmgmt.xml
   /etc/libvirt/qemu/networks/vdsm-ovirtmgmt.xml

7. Regarding /etc/vdsm that contains vdsm configuration,
we should decide if we want to keep it after vdsm removal because the user might have added special configuration (it's the same as in section 2 if the user wants to reinstall vdsm later).
Also we should take into consideration that vdsm.id is under /etc/vdsm and we want to keep it as I mentioned in section 2.
Dan/Oved what do you think about this?

This is a general issue that should be decided: 
Do we want to keep the support for the host configuration if it still in engine?
I think the answer is that we should, otherwise we will hurt the usability of the system.

Moti - please give your opinion on the engine-related files.
I think they can be removed, but I might be missing something.

Yeela -
1. Agree
2. I think they can be removed - but let's wait for Moti's feedback
3. Agree
4. Agree
6. Not sure about those. Dan?
7. I think we should keep. Dan?

(In reply to Oved Ourfali from comment #13)
> Moti - please give your opinion on the engine-related files.
> I think they can be removed, but I might be missing something.

When a host is being added to the engine, the host-deploy is responsible to install and configure it. The engine doesn't expect any files to appear.
Therefore engine-related files shouldn't be kept after vdsm removal.

> 
> Yeela -
> 1. Agree
> 2. I think they can be removed - but let's wait for Moti's feedback
> 3. Agree
> 4. Agree
> 6. Not sure about those. Dan?
> 7. I think we should keep. Dan?

What Moti is saying is correct, host-deploy will take care of adding these files.
But the problem is that currently the user does not have to add the host to engine (which will use host-deploy) every time vdsm is removed.


If we remove these files, the user will have to re-deploy the host on engine side every time, and that's why I think we should not touch these files.

vdsm.conf and vdsm.id must not be deleted, in case it was modified by the user.

all /etc/libvirt/qemu/networks/{autostart}/vdsm-* network definitions and /etc/libvirt/nwfilter/vdsm-no-mac-spoofing.xml can be deleted

all assuming no VMs are running.

This bug was fixed and is slated to be in the upcoming version. As we
are focusing our testing at this phase on severe bugs, this bug was
closed without going through its verification step. If you think this
bug should be verified by QE, please set its severity to high and move
it back to ON_QA