Hi Sandro, Michal, On 4/5/19 9:01 AM, Sandro Bonazzola wrote: > > > Il giorno gio 4 apr 2019 alle ore 19:15 Michal Skrivanek > <[email protected] <mailto:[email protected]>> ha > scritto: > > > > On 3 Apr 2019, at 13:24, Martin Perina <[email protected] > <mailto:[email protected]>> wrote: > >> >> >> On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <[email protected] >> <mailto:[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 > > In general we can’t remove anything while the corresponding > cluster level is still supported. So feel free to drop anything we > used in <4.2, but think twice and (run that through virt team at > least) before you remove anything used in 4.2+ > > > Ok, so: do we need to take safelease with us in 4.4? If the answer is > yes, I need to request to find a maintainer for it since we'll need to > package it for RHEL 8 / CentOS 8. > This is currently blocking pre-integration testing with RHEL 8 Beta so > it needs to be addressed quickly in order to be able to proceed. >
First question: Up to which clusterlevel is safelease needed? Is it needed in 4.2 cluster level? If so: safelease is probably only required on RHEL 7 hypervisors then. In that case we don't need it for RHEL 8 Hypervisors. So in case we remove safelease from RHV 4.4/RHEL 8 based hypervisors we should be fine. In case safelease is needed for the engine, we need to think if we want to move the engine to RHEL 8 in that case. Cheers, Martin > > >> >> 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] <mailto:[email protected]>> ha scritto: >>> >>> On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> >>> On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola >>> <[email protected] >>> <mailto:[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] <mailto:[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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[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/ > _______________________________________________ > Devel mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[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/45RWPIMLH6MYVUBPOZ6VP3PNWHMWVCCB/ > > > > -- > > SANDRO BONAZZOLA > > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > > Red Hat EMEA <https://www.redhat.com/> > > [email protected] <mailto:[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/TA7F5C7RXIBSAKBQ27SQ2QLF4DF55B2O/
