[ovirt-devel] Re: VDSM and safelease

On 9 Apr 2019, at 13:05, Sandro Bonazzola <sbonazzo(a)redhat.com&gt; wrote: Looks like this will take a while either we'll drop safelease or port the code to use it on RHEL 8. In the meanwhile, pushed https://gerrit.ovirt.org/99293 allowing to continue pre-integration testing but why not just build safelease for rhel 8 for now? it’s a plain C app without any dependency, so it should be a trivial rebuild I would rather avoid breaking stuff this early without a clear plan and commitment to fix it in time. It’s easy to forget and then we’ll end up with serious gap in functionality and/or the upgrade flow

Thanks, michal Il giorno lun 8 apr 2019 alle ore 10:34 Michal Skrivanek < michal.skrivanek(a)redhat.com&gt; ha scritto: > > > On 7 Apr 2019, at 13:41, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: > > > > On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <danken(a)redhat.com&gt; wrote: > >> >> >> On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek < >> michal.skrivanek(a)redhat.com&gt; wrote: >> >>> >>> >>> On 5 Apr 2019, at 09:31, Martin Tessun <mtessun(a)redhat.com&gt; 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 < >>> michal.skrivanek(a)redhat.com&gt; ha scritto: >>> >>>> >>>> >>>> On 3 Apr 2019, at 13:24, Martin Perina <mperina(a)redhat.com&gt; wrote: >>>> >>>> >>>> >>>> On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun(a)redhat.com&gt; >>>> 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. >> > > and what would happen to those? You could have a lot of data on export > domain…that could be very surprising. > So when you start the upgrade you would basically see your new shiny 4.4 > host won’t become operational and you’d be presented with a decision to > either stop the upgrade or cut off iso/storage domains before continuing. > > 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. >> > > that part is easy. > > > Sounds like a good plan. > > >> I think that this is something we can both implement in code AND request >> from users. >> > > it still means the gaps needs to be closed first. We can’t break v2v > conversions - as Tomas pointed out earlier we need a way(API) how to get > the drivers iso mounted on a conversion host. And get rid of floppies. > > Thanks, > michal > > >>> 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 < >>>>> 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... >>>>> >>>> >>>> >>>> -- >>>> Martin Perina >>>> Manager, Software Engineering >>>> Red Hat Czech s.r.o. >>>> >>>> _______________________________________________ >>>> 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/GRB2666BFX3... >>>> >>>> _______________________________________________ >>>> 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/45RWPIMLH6M... >>>> >>> >>> >>> -- >>> 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/GVQCEPGMK5B... >>> >> _______________________________________________ >> 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/WCN6UE25YXD... >> > > _______________________________________________ > 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/WQPWH3ZB7IK... > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>