On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <[email protected]> wrote:
> 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 > > Just please don't forget that 4.4 engine will need to support 4.2, 4.3 and 4.4 hosts and we will need to allow migrating VMs from 4.2/4.3 hosts (EL7) to 4.4 hosts (EL8), so we need to be careful about implications of removing ISO and export data domains > > 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 <[email protected]> > ha scritto: > >> On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <[email protected]> wrote: >> >>> >>> >>> On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <[email protected]> wrote: >>> >>>> On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <[email protected]> >>>> 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/f433ed5aaf67729b787cf82ee21b0f17af968be4/lib/vdsm/storage/clusterlock.py#L127 >>>> 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/> > > [email protected] > <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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected]/message/JZZEG5LQLLAGS4XAIQPAEP655RA4YAYY/ > -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
_______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/GRB2666BFX3OIUMNP6DFUNJQYYOWEWAE/
