> On 9 Apr 2019, at 13:05, Sandro Bonazzola <[email protected]> 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 > <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 > <[email protected] <mailto:[email protected]>> ha scritto: > > >> On 7 Apr 2019, at 13:41, Nir Soffer <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> On 5 Apr 2019, at 09:31, Martin Tessun <[email protected] >> <mailto:[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] <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? >>> >> >> 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 <[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/ <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 >>>>>> <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/f433ed5aaf67729b787cf82ee21b0f17af968be4/lib/vdsm/storage/clusterlock.py#L127> >>>>>> https://github.com/oVirt/vdsm/blob/master/lib/vdsm/storage/sd.py#L320 >>>>>> <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/ <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/ >>>>> <https://www.ovirt.org/site/privacy-policy/> >>>>> oVirt Code of Conduct: >>>>> https://www.ovirt.org/community/about/community-guidelines/ >>>>> <https://www.ovirt.org/community/about/community-guidelines/> >>>>> List Archives: >>>>> https://lists.ovirt.org/archives/list/[email protected]/message/JZZEG5LQLLAGS4XAIQPAEP655RA4YAYY/ >>>>> >>>>> <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/ >>>>> <https://www.ovirt.org/site/privacy-policy/> >>>>> oVirt Code of Conduct: >>>>> https://www.ovirt.org/community/about/community-guidelines/ >>>>> <https://www.ovirt.org/community/about/community-guidelines/> >>>>> List Archives: >>>>> https://lists.ovirt.org/archives/list/[email protected]/message/GRB2666BFX3OIUMNP6DFUNJQYYOWEWAE/ >>>>> >>>>> <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/ >>>> <https://www.ovirt.org/site/privacy-policy/> >>>> oVirt Code of Conduct: >>>> https://www.ovirt.org/community/about/community-guidelines/ >>>> <https://www.ovirt.org/community/about/community-guidelines/> >>>> List Archives: >>>> https://lists.ovirt.org/archives/list/[email protected]/message/45RWPIMLH6MYVUBPOZ6VP3PNWHMWVCCB/ >>>> >>>> <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/ <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/ >> <https://www.ovirt.org/site/privacy-policy/> >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> <https://www.ovirt.org/community/about/community-guidelines/> >> List Archives: >> https://lists.ovirt.org/archives/list/[email protected]/message/GVQCEPGMK5BNC623564DBGQV7NEVQNWP/ >> >> <https://lists.ovirt.org/archives/list/[email protected]/message/GVQCEPGMK5BNC623564DBGQV7NEVQNWP/> >> _______________________________________________ >> 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/ >> <https://www.ovirt.org/site/privacy-policy/> >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> <https://www.ovirt.org/community/about/community-guidelines/> >> List Archives: >> https://lists.ovirt.org/archives/list/[email protected]/message/WCN6UE25YXDZLHCI26FJA34KG3Z6Q4OA/ >> >> <https://lists.ovirt.org/archives/list/[email protected]/message/WCN6UE25YXDZLHCI26FJA34KG3Z6Q4OA/> > > _______________________________________________ > 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/ > <https://www.ovirt.org/site/privacy-policy/> > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > <https://www.ovirt.org/community/about/community-guidelines/> > List Archives: > https://lists.ovirt.org/archives/list/[email protected]/message/WQPWH3ZB7IKECWYJBWUE4IVUMH3GSSW2/ > > <https://lists.ovirt.org/archives/list/[email protected]/message/WQPWH3ZB7IKECWYJBWUE4IVUMH3GSSW2/> > > > -- > 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>
_______________________________________________ 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/PCAIBIUALNPYV2K3NXZHFIRFE6QA3M6K/
