On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <[email protected]> wrote: > > > On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek < > [email protected]> wrote: > >> >> >> On 5 Apr 2019, at 09:31, Martin Tessun <[email protected]> wrote: >> >> 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]> ha scritto: >> >>> >>> >>> On 3 Apr 2019, at 13:24, Martin Perina <[email protected]> wrote: >>> >>> >>> >>> 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 >>> >>> >>> 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? >> >> >> Also 4.3 >> >> If so: safelease is probably only required on RHEL 7 hypervisors then. In >> that case we don't need it for RHEL 8 Hypervisors. >> >> >> If we won’t have it on RHEL 8/4.4 then you are effectively cutting off >> <4.4 support in 4.4 vdsm. Which also means no live migration between 4.3 >> compat level which means no way to upgrade to 4.4 with running VMs. >> I do not think that’s acceptable >> > > I think that the suggestion here is not to drop clusterLevel < 4.4; it is > to disallow storage pools that have ISO/EXPORT domains attached to them. > Theoretically, we could ask our users to first detach their obsolete SDs > from the data center, and only then add a 4.4 host. > If a host upgrades to 4.4 while its datacenter still has ISO/EXPORT, the > host must become non-operational. >
Sounds like a good plan. > I think that this is something we can both implement in code AND request > from users. > >> >> 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. >>>> >>> > ... or at least provide the documentation for users to do this themselves. > >> 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/ >>> >>> _______________________________________________ >>> 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/45RWPIMLH6MYVUBPOZ6VP3PNWHMWVCCB/ >>> >> >> >> -- >> >> 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/GVQCEPGMK5BNC623564DBGQV7NEVQNWP/ >> > _______________________________________________ > 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/WCN6UE25YXDZLHCI26FJA34KG3Z6Q4OA/ >
_______________________________________________ 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/UV2ZMS2ZXVIK73IHBCEI6IJRR2FOQRMO/
