sanlock 3.7.1 for Fedora 28, 29, and 30 is available now in the
updates-testing repo.
The main change in this version is support for configurable sector size and
alignment,
needed for 4k support in 4.3.z.
If you have oVirt Fedora hosts please test this version and submit feedback:
f28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2f7165dc3f
f29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2f7165dc3f
f30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-0349c17155
To update use:
sudo dnf update --enablerepo=updates-testing sanlock python2-sanlock
Sandro: we discussed building sanlock for CentOS once we release it for
Fedora,
so we can start using it for OST now.
Eyal, what do we need to start using this sanlock version in the CI and OST?
Nir
Hi,
This mail is to provide the current status of CQ and allow people to review
status before and after the weekend.
Please refer to below colour map for further information on the meaning of
the colours.
*CQ-4.2*: GREEN (#1)
Last CQ job failure on 4.2 was 05-04-2019 on project ovirt-provider-ovn due
to a code regression which was caused by [1]
The issue has been found and a patch created [2] but due to the hotplug_cpu
failure, it took a long time to verify the fix before merge.
[1] https://gerrit.ovirt.org/#/c/98723/ - Stateless dhcpv6 does not support
fixed IPs
[2] https://gerrit.ovirt.org/#/c/99193/ - Fix bug when fixed IPs are not
provisioned
*CQ-4.3*: RED (#3)
We have been having constant failures on tests:
hotplug_cpu
add_master_storage_domain
The failures on these two are very frequent and I need to re-trigger tests
on multiple failures daily.
There is a mail thread on this and several people have joined in to help
debug the issue but I think that this issue needs more help from some of
the other teams as its been going on for the last two weeks at least.
This is also disrupting fixing actual regressions as the testing keep
failing on these two unrelated issues.
*CQ-Master:* RED (#3)
Master and 4.3 have the same issues.
Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found
here:
[1]
http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu…
[2]
https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q…
[3]
http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change…
Happy week!
Dafna
-------------------------------------------------------------------------------------------------------------------
COLOUR MAP
Green = job has been passing successfully
** green for more than 3 days may suggest we need a review of our test
coverage
1.
1-3 days GREEN (#1)
2.
4-7 days GREEN (#2)
3.
Over 7 days GREEN (#3)
Yellow = intermittent failures for different projects but no lasting or
current regressions
** intermittent would be a healthy project as we expect a number of
failures during the week
** I will not report any of the solved failures or regressions.
1.
Solved job failures YELLOW (#1)
2.
Solved regressions YELLOW (#2)
Red = job has been failing
** Active Failures. The colour will change based on the amount of time the
project/s has been broken. Only active regressions would be reported.
1.
1-3 days RED (#1)
2.
4-7 days RED (#2)
3.
Over 7 days RED (#3)
Hi,
On yesterday's vdsm weekly call, we were discussing the need of making
Python 3 vdsm RPM packages.
Some facts:
- it doesn't make a lot sense to spend much time on trying to package
everything - it's completely impossible i.e. to run vdsm without having
'sanlock' module
- our current vdsm.spec file is crap
Two non-exclusive propositions were raised:
- let's try to make a quick-and-dirty patch, that will completely
overwrite the existing 'vdsm.spec' (effectively making it Python 3-only)
for testing purposes, and maintain it for a while
- in the meantime, let's write a completely new, clean and beautiful
spec file in an package-by-package, incremental manner, (also Python
3-only) that would eventually substitute the original one
The quick-and-dirty spec file would be completely unsupported by CI. The
new one would get a proper CI sub-stage in 'build-artifacts' stage.
The steps needed to be done are:
- prepare autotools/Makefiles to differentiate Python 2/Python 3 RPM builds
- prepare the new spec file (for now including only 'vdsm-common' package)
- split 'build-artifacts' stage into 'build-py27' and 'build-py36'
sub-stages (the latter currently running on fc28 only)
The only package we can start with, when making the new spec file, is
'vdsm-common', as it doesn't depend on anything else (or at least I hope
so...).
There were also propositions about how to change the new spec file in
regard to the old one (like making 'vdsm' package a meta-package). This
is a good time for these propositions to be raised, reviewed and
documented (something like this maybe?
https://docs.google.com/document/d/13EXN1Iwq-OPoc2A5Y3PJBpOiNC10ugx6eCE72K6…)
so we can align the new spec file as we build it.
I can lay the groundwork by doing the autotools/Makefiles and
'build-artifacts' splitting. Gal Zaidman agreed on starting to work on
the new spec file. Milan mentioned, that he had something like the
quick-and-dirty patch, maybe he can share it with us.
Questions, comments are welcome.
Regards, Marcin
On 5 Apr 2019, at 09:31, Martin Tessun <mtessun(a)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(a)redhat.com> ha scritto:
>
>
> On 3 Apr 2019, at 13:24, Martin Perina <mperina(a)redhat.com> wrote:
>
>
>
> On Wed, Apr 3, 2019 at 10:22 AM Martin Tessun <mtessun(a)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(a)redhat.com>
>> ha scritto:
>>
>>> On Tue, Apr 2, 2019 at 6:40 PM Dan Kenigsberg <danken(a)redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Apr 2, 2019 at 6:07 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
>>>>
>>>>> On Tue, Apr 2, 2019 at 5:00 PM Sandro Bonazzola <sbonazzo(a)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(a)redhat.com
>> <https://red.ht/sig>
>>
>>
>> --
>> Martin Tessun
>> Senior Technical Product Manager KVM, Red Hat GmbH (Munich Office)
>>
>> mobile +49.173.6595494
>> desk +49.89.205071-107
>> fax +49.89.205071-111
>>
>> GPG Fingerprint: EDBB 7C6A B5FE 9199 B861 478D 3526 E46D 0D8B 44F0
>>
>> Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
>> Commercial register: Amtsgericht Muenchen, HRB 153243,
>> Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
>>
>> _______________________________________________
>> Devel mailing list -- devel(a)ovirt.org
>> To unsubscribe send an email to devel-leave(a)ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/JZZEG5LQLLAGS…
>>
>
>
> --
> Martin Perina
> Manager, Software Engineering
> Red Hat Czech s.r.o.
>
> _______________________________________________
> Devel mailing list -- devel(a)ovirt.org
> To unsubscribe send an email to devel-leave(a)ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GRB2666BFX3OI…
>
> _______________________________________________
> Devel mailing list -- devel(a)ovirt.org
> To unsubscribe send an email to devel-leave(a)ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/45RWPIMLH6MYV…
>
--
SANDRO BONAZZOLA
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://red.ht/sig>
--
Martin Tessun
Senior Technical Product Manager KVM, Red Hat GmbH (Munich Office)
mobile +49.173.6595494
desk +49.89.205071-107
fax +49.89.205071-111
GPG Fingerprint: EDBB 7C6A B5FE 9199 B861 478D 3526 E46D 0D8B 44F0
Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
Hallo,
currently OST network-suite-4.2 is broken by a test
executed unintentional in network-suite-4.2.
To unbreak,
https://gerrit.ovirt.org/#/c/99289/
can be used.
Because Edy is not available to merge, it would be helpful if someone
else with merge power would merge the change/
Thanks
Dominik
The self-hosted documentation for network labels appears to be inaccurate.
https://{{ MY_DOMAIN }}/ovirt-engine/apidoc/#/services/network_labels/methods/add
The documentation asks the user to post to the following URI:
POST /ovirt-engine/api/networks/123/labels
However that results in a 404. The following URL should be posted to instead for a successful response:
POST /ovirt-engine/api/networks/123/networklabels
I discovered the discrepancy when trying to curl loop automate adding networks to my cluster, and resulted in 404s. The 'links' section of the specific network label actually do contain the right URI to hit to get the proper label tagging:
"link": [
{
"href": "/ovirt-engine/api/networks/929fec34-7a34-4c1b-9451-e6abf6733ac6/networklabels",
"rel": "networklabels"
},
{
"href": "/ovirt-engine/api/networks/929fec34-7a34-4c1b-9451-e6abf6733ac6/permissions",
"rel": "permissions"
},
{
"href": "/ovirt-engine/api/networks/929fec34-7a34-4c1b-9451-e6abf6733ac6/vnicprofiles",
"rel": "vnicprofiles"
}
]
The hosted documentation also has confusing information with networklabels being used in the results of some requests, but this section here also just says 'labels':
https://ovirt.github.io/ovirt-engine-api-model/4.1/#services/network_labels…
