Il giorno mar 9 apr 2019 alle ore 13:46 Michal Skrivanek < michal.skriva...@redhat.com> ha scritto:
> > > On 9 Apr 2019, at 13:05, Sandro Bonazzola <sbona...@redhat.com> 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 > Because: 1) safelease has no active maintainer 2) safelease has no CI 3) safelease has been already declared obsoleted by sanlock 4) I don't really want to invest time into something without having decided we need it > > Thanks, > michal > > > > Il giorno lun 8 apr 2019 alle ore 10:34 Michal Skrivanek < > michal.skriva...@redhat.com> ha scritto: > >> >> >> On 7 Apr 2019, at 13:41, Nir Soffer <nsof...@redhat.com> wrote: >> >> >> >> On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <dan...@redhat.com> wrote: >> >>> >>> >>> 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. >>> >> >> 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 < >>>>>> 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/ >>> >> >> _______________________________________________ >> 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/WQPWH3ZB7IKECWYJBWUE4IVUMH3GSSW2/ >> > > > -- > SANDRO BONAZZOLA > > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > Red Hat EMEA <https://www.redhat.com/> > > sbona...@redhat.com > <https://red.ht/sig> > > > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbona...@redhat.com <https://red.ht/sig>
_______________________________________________ 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/IVXKPEJZMCJHKJ7P7EO7WDDT6WR3OACA/
