On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek <michal.skriva...@redhat.com> wrote:
> > > On 5 Apr 2019, at 09:31, Martin Tessun <mtes...@redhat.com> 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.skriva...@redhat.com> ha scritto: > >> >> >> On 3 Apr 2019, at 13:24, Martin Perina <mper...@redhat.com> wrote: >> >> >> >> On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtes...@redhat.com> 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. 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 <nsof...@redhat.com> >>> ha scritto: >>> >>>> On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <dan...@redhat.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsof...@redhat.com> wrote: >>>>> >>>>>> On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <sbona...@redhat.com> >>>>>> 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/> >>> >>> sbona...@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@ovirt.org >>> To unsubscribe send an email to devel-le...@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/JZZEG5LQLLAGS4XAIQPAEP655RA4YAYY/ >>> >> >> >> -- >> Martin Perina >> Manager, Software Engineering >> Red Hat Czech s.r.o. >> >> _______________________________________________ >> Devel mailing list -- devel@ovirt.org >> To unsubscribe send an email to devel-le...@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/GRB2666BFX3OIUMNP6DFUNJQYYOWEWAE/ >> >> _______________________________________________ >> Devel mailing list -- devel@ovirt.org >> To unsubscribe send an email to devel-le...@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/45RWPIMLH6MYVUBPOZ6VP3PNWHMWVCCB/ >> > > > -- > > SANDRO BONAZZOLA > > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > > Red Hat EMEA <https://www.redhat.com/> > > sbona...@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@ovirt.org > To unsubscribe send an email to devel-le...@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/GVQCEPGMK5BNC623564DBGQV7NEVQNWP/ >
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@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/WCN6UE25YXDZLHCI26FJA34KG3Z6Q4OA/
