Description of problem: After running engine-cleanup, the default iso domain remains in "/etc/exports" and the directory "/var/lib/exports/iso/" remains. This prevents reinstall without the following additional manual steps: - rm /etc/exports (or editing the file) - rm -rf /var/lib/exports/iso
not sure removing is it best, but if exist, we can detect on re-install and ask user if to clean it, or re-import it (instead of creating a new one)
Running engine-cleanup: # engine-cleanup WARNING: Executing oVirt Engine cleanup utility. This utility will wipe all existing data including configuration settings, certificates and database. I think we can modify engine-cleanup for: - removing the entries in /etc/exports commented with '#rhev installer' - call exportfs -ra - ask the user if to clean the iso domain directory In engine-setup, if the iso domain exists: - ask if we have to re-import it or ask for another path. If this is a new install, the iso domain will be empty. If this is a re-install and the user has not cleaned up the iso domain with engine-cleanup, it could be better not asking him twice.
I recommend just adding an option to the engine-cleanup to remove nfs export configuration. It should not be enabled by default, so the basic flow will remain the same. If the user would like to cleanup the config, she would supply a parameter to the engine-cleanup, or we can do this with interactive prompt. Also, I think that "#rhev" comment is incorrect in the /etc/exports, it's better to use the basedefs.APP_NAME value for the product name.
(In reply to comment #3) > Also, I think that "#rhev" comment is incorrect in the /etc/exports, it's > better to use the basedefs.APP_NAME value for the product name. this small part is submitted for review, link in the external bug tracker.
(In reply to comment #3) > If the user would like to cleanup the config, she would supply a parameter > to the engine-cleanup, or we can do this with interactive prompt. I've implemented the engine-cleanup part using an interactive prompt and submitted upstream for review.
I've implemented the engine-setup part trying to use the existing validation / prompt / confirm structure and submitted upstream for review. This should complete the change set for this bug.
patch 11506 merged: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=20775e7818f6e036f014b7e3f1ffbdaa801d9815
patch 11548 merged: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=620aa50e5af186417379f3ce03da004973b646af
patch 11556 merged: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=0c16a4ea73e6731d25460f451d51f5181198c8c0
as RC is built, moving to ON_QA (hopefully did not catch incorrect bugs when doing this)
We need to adapt a fix for the new setup.
Current behaviour of ovirt-engine 3.3: The files in the iso domain are never deleted by cleanup. If during setup /var/lib/exports/iso exists, and user chooses to create an iso domain, setup defaults in the next question about the path to a timestamped name - e.g. /var/lib/exports/iso-20131016100521 , but can reuse an existing path if user chooses so. The exports: - If you have a directory /etc/exports.d: during setup, a new file is added there during cleanup, user can choose if to delete it, default is to delete - If you only have /etc/exports: during setup, a line is added if not already exists during cleanup currently nothing is done. Rationale: the user can use this domain independently of ovirt-engine, to export iso files to other machines in the lan. So we should not remove it during cleanup. To be consistent, we should probably also remove the line from /etc/export if added by setup and user chooses so. It also might make sense to actually do remove the iso domain files/dirs if user chooses so, perhaps with a different question. In any case, if the essence of this bug is to allow setup after cleanup without doing any manual action, it can be closed without further changes. What do you think?
I do a lot of testing so for me it's fine when setup works after cleanup without manual action. You could add the question to remove the iso's but I don't think that will get used a lot. Mostly when you want to remove ovirt it's for reinstall and you don't want to transfer all the iso's . Or the iso's are mounted on an nfs share and you remove all the shared iso's on a network this way by not thinking things trough.
Very well, I am closing this bug. Thanks for the feedback! Changed target back to 3.3 as it's already solved there.