On 5 Apr 2019, at 09:31, Martin Tessun <mtessun@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.skrivanek@redhat.com> ha scritto:
On 3 Apr 2019, at 13:24, Martin Perina <mperina@redhat.com> wrote:
On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun@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 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.
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@redhat.com> ha scritto:
On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken@redhat.com> wrote:
On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer@redhat.com> wrote:
On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <sbonazzo@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/... 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@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-leave@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/JZZEG5LQLLAGS4...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/GRB2666BFX3OIU...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/45RWPIMLH6MYVU...
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@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
On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 5 Apr 2019, at 09:31, Martin Tessun <mtessun@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.skrivanek@redhat.com> ha scritto:
On 3 Apr 2019, at 13:24, Martin Perina <mperina@redhat.com> wrote:
On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun@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
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.
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.
Just want to mention in this context the integration between oVirt and muCommander that I'm working on to allow downloading, uploading and deleting disk images from oVirt storage domains via a lightweight, cross-platform, open source file manager with a dual-pane interface. A demo is available: https://youtu.be/daCSlDB_3Jc Specifically, muCommander could identify ISO files and upload them with the appropriate image content-type.
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@redhat.com> ha scritto:
On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken@redhat.com> wrote:
On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer@redhat.com> wrote:
On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <sbonazzo@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/... 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@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-leave@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/JZZEG5LQLLAGS4...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/GRB2666BFX3OIU...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/45RWPIMLH6MYVU...
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@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-leave@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/GVQCEPGMK5BNC6...
On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 5 Apr 2019, at 09:31, Martin Tessun <mtessun@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.skrivanek@redhat.com> ha scritto:
On 3 Apr 2019, at 13:24, Martin Perina <mperina@redhat.com> wrote:
On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun@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 <nsoffer@redhat.com> ha scritto:
On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken@redhat.com> wrote:
On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer@redhat.com> wrote:
On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <sbonazzo@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/... 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@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-leave@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/JZZEG5LQLLAGS4...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/GRB2666BFX3OIU...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/45RWPIMLH6MYVU...
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@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-leave@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/GVQCEPGMK5BNC6...
On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <danken@redhat.com> wrote:
On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek < michal.skrivanek@redhat.com> wrote:
On 5 Apr 2019, at 09:31, Martin Tessun <mtessun@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.skrivanek@redhat.com> ha scritto:
On 3 Apr 2019, at 13:24, Martin Perina <mperina@redhat.com> wrote:
On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun@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.
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 <nsoffer@redhat.com> ha scritto:
On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken@redhat.com> wrote:
On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer@redhat.com> wrote:
> On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <sbonazzo@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/... > 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@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-leave@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/JZZEG5LQLLAGS4...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/GRB2666BFX3OIU...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/45RWPIMLH6MYVU...
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@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-leave@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/GVQCEPGMK5BNC6...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/WCN6UE25YXDZLH...
On 7 Apr 2019, at 13:41, Nir Soffer <nsoffer@redhat.com> wrote:
On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <danken@redhat.com <mailto:danken@redhat.com>> wrote:
On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek <michal.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> wrote:
On 5 Apr 2019, at 09:31, Martin Tessun <mtessun@redhat.com <mailto:mtessun@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.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> ha scritto:
On 3 Apr 2019, at 13:24, Martin Perina <mperina@redhat.com <mailto:mperina@redhat.com>> wrote:
On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun@redhat.com <mailto:mtessun@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 <nsoffer@redhat.com <mailto:nsoffer@redhat.com>> ha scritto: On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken@redhat.com <mailto:danken@redhat.com>> wrote:
On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer@redhat.com <mailto:nsoffer@redhat.com>> wrote: On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <sbonazzo@redhat.com <mailto:sbonazzo@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/ <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/... <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/> sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
-- 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 -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/JZZEG5LQLLAGS4... <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 <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/GRB2666BFX3OIU... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GRB2666BFX3OIUMNP6DFUNJQYYOWEWAE/>
Devel mailing list -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/45RWPIMLH6MYVU... <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/> sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
-- 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 -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/GVQCEPGMK5BNC6... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GVQCEPGMK5BNC623564DBGQV7NEVQNWP/> _______________________________________________ Devel mailing list -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/WCN6UE25YXDZLH... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/WCN6UE25YXDZLHCI26FJA34KG3Z6Q4OA/>
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 Il giorno lun 8 apr 2019 alle ore 10:34 Michal Skrivanek < michal.skrivanek@redhat.com> ha scritto:
On 7 Apr 2019, at 13:41, Nir Soffer <nsoffer@redhat.com> wrote:
On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <danken@redhat.com> wrote:
On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek < michal.skrivanek@redhat.com> wrote:
On 5 Apr 2019, at 09:31, Martin Tessun <mtessun@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.skrivanek@redhat.com> ha scritto:
On 3 Apr 2019, at 13:24, Martin Perina <mperina@redhat.com> wrote:
On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun@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 <nsoffer@redhat.com> ha scritto:
On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken@redhat.com> wrote:
> > > On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer@redhat.com> > wrote: > >> On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola < >> sbonazzo@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/... >> >> 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@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-leave@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/JZZEG5LQLLAGS4...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/GRB2666BFX3OIU...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/45RWPIMLH6MYVU...
-- SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/>
sbonazzo@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-leave@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/GVQCEPGMK5BNC6...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/WCN6UE25YXDZLH...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/WQPWH3ZB7IKECW...
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig>
On 9 Apr 2019, at 13:05, Sandro Bonazzola <sbonazzo@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 <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@redhat.com <mailto:michal.skrivanek@redhat.com>> ha scritto:
On 7 Apr 2019, at 13:41, Nir Soffer <nsoffer@redhat.com <mailto:nsoffer@redhat.com>> wrote:
On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <danken@redhat.com <mailto:danken@redhat.com>> wrote:
On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek <michal.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> wrote:
On 5 Apr 2019, at 09:31, Martin Tessun <mtessun@redhat.com <mailto:mtessun@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.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> ha scritto:
On 3 Apr 2019, at 13:24, Martin Perina <mperina@redhat.com <mailto:mperina@redhat.com>> wrote:
On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun@redhat.com <mailto:mtessun@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 <nsoffer@redhat.com <mailto:nsoffer@redhat.com>> ha scritto: On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken@redhat.com <mailto:danken@redhat.com>> wrote:
On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer@redhat.com <mailto:nsoffer@redhat.com>> wrote: On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <sbonazzo@redhat.com <mailto:sbonazzo@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/ <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/... <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/> sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
-- 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 -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/JZZEG5LQLLAGS4... <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 <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/GRB2666BFX3OIU... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GRB2666BFX3OIUMNP6DFUNJQYYOWEWAE/>
Devel mailing list -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/45RWPIMLH6MYVU... <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/> sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
-- 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 -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/GVQCEPGMK5BNC6... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GVQCEPGMK5BNC623564DBGQV7NEVQNWP/> _______________________________________________ Devel mailing list -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/WCN6UE25YXDZLH... <https://lists.ovirt.org/archives/list/devel@ovirt.org/message/WCN6UE25YXDZLHCI26FJA34KG3Z6Q4OA/>
_______________________________________________ Devel mailing list -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@ovirt.org> 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/devel@ovirt.org/message/WQPWH3ZB7IKECW... <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/> sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
Il giorno mar 9 apr 2019 alle ore 13:46 Michal Skrivanek < michal.skrivanek@redhat.com> ha scritto:
On 9 Apr 2019, at 13:05, Sandro Bonazzola <sbonazzo@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.skrivanek@redhat.com> ha scritto:
On 7 Apr 2019, at 13:41, Nir Soffer <nsoffer@redhat.com> wrote:
On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <danken@redhat.com> wrote:
On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek < michal.skrivanek@redhat.com> wrote:
On 5 Apr 2019, at 09:31, Martin Tessun <mtessun@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.skrivanek@redhat.com> ha scritto:
On 3 Apr 2019, at 13:24, Martin Perina <mperina@redhat.com> wrote:
On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun@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 < nsoffer@redhat.com> ha scritto:
> On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken@redhat.com> > wrote: > >> >> >> On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer@redhat.com> >> wrote: >> >>> On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola < >>> sbonazzo@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/... >>> >>> 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@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-leave@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/JZZEG5LQLLAGS4...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/GRB2666BFX3OIU...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/45RWPIMLH6MYVU...
-- SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/>
sbonazzo@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-leave@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/GVQCEPGMK5BNC6...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/WCN6UE25YXDZLH...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/WQPWH3ZB7IKECW...
-- SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig>
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig>
On 9 Apr 2019, at 13:55, Sandro Bonazzola <sbonazzo@redhat.com> wrote: Il giorno mar 9 apr 2019 alle ore 13:46 Michal Skrivanek < michal.skrivanek@redhat.com> ha scritto:
On 9 Apr 2019, at 13:05, Sandro Bonazzola <sbonazzo@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 Currently we do need it IIUC, for iso and export domains. They were not removed in time in previous releases and removing them without a way of supporting them in old cluster in new version is IMHO unacceptable for upgrades. At least until we have a clear plan. From my perspective carrying it forward is the least effort and least risk, but if someone wants to do otherwise it’s fine as well, supposing the transition is properly taken care of. This is for storage team to sort out - to find a feasible plan or maintain safelease
Thanks, michal
Il giorno lun 8 apr 2019 alle ore 10:34 Michal Skrivanek < michal.skrivanek@redhat.com> ha scritto:
On 7 Apr 2019, at 13:41, Nir Soffer <nsoffer@redhat.com> wrote:
On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <danken@redhat.com> wrote:
On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek < michal.skrivanek@redhat.com> wrote:
On 5 Apr 2019, at 09:31, Martin Tessun <mtessun@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.skrivanek@redhat.com> ha scritto:
On 3 Apr 2019, at 13:24, Martin Perina <mperina@redhat.com> wrote:
On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun@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 < nsoffer@redhat.com> ha scritto:
> On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken@redhat.com> > wrote: > >> >> >> On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer@redhat.com> >> wrote: >> >>> On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola < >>> sbonazzo@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/... >>> >>> 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@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-leave@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/JZZEG5LQLLAGS4...
-- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/GRB2666BFX3OIU...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/45RWPIMLH6MYVU...
-- SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/>
sbonazzo@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-leave@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/GVQCEPGMK5BNC6...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/WCN6UE25YXDZLH...
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@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/WQPWH3ZB7IKECW...
-- SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <https://red.ht/sig>
-- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo@redhat.com <https://red.ht/sig>
Hi Michal, On 4/10/19 8:00 AM, Michal Skrivanek wrote:
On 9 Apr 2019, at 13:55, Sandro Bonazzola <sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>> wrote:
Il giorno mar 9 apr 2019 alle ore 13:46 Michal Skrivanek <michal.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> ha scritto:
On 9 Apr 2019, at 13:05, Sandro Bonazzola <sbonazzo@redhat.com <mailto:sbonazzo@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
Currently we do need it IIUC, for iso and export domains. They were not removed in time in previous releases and removing them without a way of supporting them in old cluster in new version is IMHO unacceptable for upgrades. At least until we have a clear plan. From my perspective carrying it forward is the least effort and least risk, but if someone wants to do otherwise it’s fine as well, supposing the transition is properly taken care of. This is for storage team to sort out - to find a feasible plan or maintain safelease
While I agree here, I see this slightly different: As long as you have a 4.3 cluster level, you have safelease, as the Hypervisors are RHEL 7. Once we have RHEL 8 hypervisors, these will be added to a 4.3 cluster for the purpose of upgrading that one to 4.4 cluster level. As we don't support Export-/ISO-Domains in Cluster Level 4.4 it is an acceptable first step to get rid of any Export- or ISO-domains. I agree it isn't the nicest way, but probably the best one as safelease has no further support. Does that sound reasonable? Cheers, Martin
Thanks, michal
Il giorno lun 8 apr 2019 alle ore 10:34 Michal Skrivanek <michal.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> ha scritto:
On 7 Apr 2019, at 13:41, Nir Soffer <nsoffer@redhat.com <mailto:nsoffer@redhat.com>> wrote:
On Sun, Apr 7, 2019, 14:34 Dan Kenigsberg <danken@redhat.com <mailto:danken@redhat.com>> wrote:
On Fri, Apr 5, 2019 at 8:33 PM Michal Skrivanek <michal.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> wrote:
On 5 Apr 2019, at 09:31, Martin Tessun <mtessun@redhat.com <mailto:mtessun@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.skrivanek@redhat.com <mailto:michal.skrivanek@redhat.com>> ha scritto:
On 3 Apr 2019, at 13:24, Martin Perina <mperina@redhat.com <mailto:mperina@redhat.com>> wrote:
> > > On Wed, Apr 3, 2019 at 10:22 AM Martin > Tessun <mtessun@redhat.com > <mailto:mtessun@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 <nsoffer@redhat.com >> <mailto:nsoffer@redhat.com>> ha scritto: >> >> On Tue, Apr 2, 2019 at 6:40 PM Dan >> Kenigsberg <danken@redhat.com >> <mailto:danken@redhat.com>> wrote: >> >> >> >> On Tue, Apr 2, 2019 at 6:07 PM >> Nir Soffer <nsoffer@redhat.com >> <mailto:nsoffer@redhat.com>> wrote: >> >> On Tue, Apr 2, 2019 at 5:00 >> PM Sandro Bonazzola >> <sbonazzo@redhat.com >> <mailto:sbonazzo@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/... >> 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@redhat.com >> <mailto:sbonazzo@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 > <mailto:devel@ovirt.org> > To unsubscribe send an email to > devel-leave@ovirt.org > <mailto:devel-leave@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/JZZEG5LQLLAGS4... > > > > -- > Martin Perina > Manager, Software Engineering > Red Hat Czech s.r.o. > _______________________________________________ > Devel mailing list -- devel@ovirt.org > <mailto:devel@ovirt.org> > To unsubscribe send an email to > devel-leave@ovirt.org > <mailto:devel-leave@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/GRB2666BFX3OIU... _______________________________________________ Devel mailing list -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@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/45RWPIMLH6MYVU...
-- SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
-- 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 <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@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/GVQCEPGMK5BNC6...
_______________________________________________ Devel mailing list -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@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/WCN6UE25YXDZLH...
_______________________________________________ Devel mailing list -- devel@ovirt.org <mailto:devel@ovirt.org> To unsubscribe send an email to devel-leave@ovirt.org <mailto:devel-leave@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/WQPWH3ZB7IKECW...
-- SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo@redhat.com <mailto:sbonazzo@redhat.com>
-- 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
participants (6)
-
Arik Hadas -
Dan Kenigsberg -
Martin Tessun -
Michal Skrivanek -
Nir Soffer -
Sandro Bonazzola