[ovirt-devel] Re: VDSM and safelease

On 4/3/19 8:25 AM, Sandro Bonazzola wrote: So, according to the thread we have a few action items: - Decide if we'll drop export domain and iso domain in 4.4

If we do so, we still need a way to clean these old domains up, aka moving the ISOs to a Data Domain or "migrating" an existing ISO domain into a data Domain. Export Domain is probably easier, as the OVAs can simply be copied to a central location. Maybe having an export domain available as a second way to upload VMs (e.g. for bulk-imports) still makes sense. Esp. as I believe v2v is relying on export domains today. So while I am in favor of getting rid of unneeded code, we need to think about the benefits they both have and how to get them implemented in case we agree on removing the old domains. So what are the benefits of the ISO domain: - Easy to add new ISOs (just copy them to the NFS location - simple way of sharing between DCs/RHV-Ms - Having a central place for the ISOs The 3rd item can be achieved by admins simply using one Storage Domain just for ISOs. The 2nd would probably require some sort of read-only SDs or a way to have one SD shared between DCs with just one DC having write-access. The 1st one is probably hardest, as there is no easy way of adding data to the Storage Domain without tooling. Maybe there are also other ways of achieving this, the above are just my ideas. Next - what are the benefits of Export Domain: - Unattended Import - Bulk Im- and Export - Central location - Easily sharable between DCs/RHV-Ms The 4th one is already achieved as we have a common Import/Export tool, so the OVAs can be easily shared and used by different DCs/RHV-Ms The 3rd one is something that could be easily achieved administrately. The 2nd one is already more complicated, but can probably be solved with Ansible (as the 1st one probably as well). So from my PoV it is easiest to remove the Export Domain while still having all needed features available. The ISO domain seems a bit harder to me. Please think about how to solve this, before we decide on removing both of them. Cheers, Martin - Move requirements from safelease to vdsm for numactl, dmidecode and virt-v2v if not already done - Elect a maintainer for safelease for 4.3 scope - Deprecate safelease in 4.3 and remove it on master if we agree on removing iso and export domain in 4.4 Il giorno mar 2 apr 2019 alle ore 18:14 Nir Soffer <nsoffer(a)redhat.com&gt; ha scritto: > On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken(a)redhat.com&gt; wrote: > >> >> >> On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: >> >>> On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <sbonazzo(a)redhat.com&gt; >>> wrote: >>> >>>> Hi, >>>> I stumbled upon safelease package, introduced in oVirt 3.6. >>>> I realigned the spec file with Fedora Rawhide: >>>> https://gerrit.ovirt.org/#/c/99123/ >>>> and then I stopped working on it and decided to open a thread here. >>>> >>>> safelease package is required in vdsm. >>>> I searched for the home page for this package since it moved and >>>> found: https://ovirt.org/develop/developer-guide/vdsm/safelease.html >>>> This says that sanlock is meant to obsolete safelease. >>>> I'm assuming that safelease was used in 3.6 and replaced later by >>>> sanlock then kept for backward compatibility. >>>> In 4.3 we dropped support for 3.6 level clusters, is this package >>>> still needed? >>>> >>> >>> safelease is our clusterlock with V1 storage domains - export and iso >>> domains. >>> >>> https://github.com/oVirt/vdsm/blob/f433ed5aaf67729b787cf82ee21b0f17af968b... >>> https://github.com/oVirt/vdsm/blob/master/lib/vdsm/storage/sd.py#L320 >>> >>> Once we remove these domains we can remove also safelease. >>> >>> If it's still needed, why is it requiring: >>>> # Numactl is not available on s390[x] and ARM >>>> %ifnarch s390 s390x %{arm} >>>> Requires: numactl >>>> %endif >>>> >>>> %ifarch x86_64 >>>> Requires: python2-dmidecode >>>> Requires: dmidecode >>>> Requires: virt-v2v >>>> %endif >>>> >>> >>> These are hacks Yaniv added so we can make vdsm noarch package. Since >>> then we reverted >>> back to vdsm arch specific package but the bad requirements remained in >>> safelease. >>> >>> We can safely remove the requirements from safelease if vdsm requires >>> these packages, but >>> I'm not sure who has time to work on safelease. >>> >>> I think it is time to remove export and iso domain in 4.4. >>> >> >> Would it be possible? >> If an ovirt-4.3 storage pool has an ISO domain, and we add an ovirt-4.4 >> host to it, we would like it to be able to become SPM. >> > > In rhel 8.1, vdsm 4.4, I don't want to support export or iso domain > regardless of the > cluster version. > > We don't have the time to port all code in vdsm to python 3. If you want > python 3, you need > to remove some features. > > If you want to mix 4.4. host with 4.3, env, detach the iso domain and > export domain? > > Tal, what do you think? > >> -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> -- Martin Tessun Senior Technical Product Manager KVM, Red Hat GmbH (Munich Office) mobile +49.173.6595494 desk +49.89.205071-107 fax +49.89.205071-111 GPG Fingerprint: EDBB 7C6A B5FE 9199 B861 478D 3526 E46D 0D8B 44F0 Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/JZZEG5LQLLA...