March 2019 - Devel - oVirt List Archives

Re: [Vdo-devel] impact of --emulate512 setting for VDO volumes
by Guillaume Pavese 02 Mar '19

02 Mar '19

Thank you very much for your answer. I am copying ovirt-devel too as that could be of interest to them. Guillaume Pavese Ingénieur Système et Réseau Interactiv-Group On Sat, Mar 2, 2019 at 7:00 AM Michael Sclafani <sclafani(a)redhat.com> wrote: > Hi! > > 512 emulation was intended to support drivers that only do a fraction of > their I/O in blocks smaller 4KB. It is not optimized for performance in any > way. Under the covers, VDO is still operating on 4KB physical blocks, so > each 512-byte read is potentially amplified to a 4KB read, and each > 512-byte write to a 4KB read followed by a 4KB write. A workload consisting > exclusively of 512-byte randomly-distributed writes could effectively be > amplified by a factor of 16. > > We have a suite of automated tests we run in 512e mode on a nightly basis. > That suite is a subset of our regular tests, containing only ones we expect > would be likely to expose problems specific to the emulation. > > There should be no penalty to having emulation enabled on a volume that no > longer uses it. If the I/O is 4KB-aligned and 4KB or larger, having it > enabled won't affect it. > It does not appear the setting can be modified by the VDO manager, but I > cannot remember at this moment why that should be so. > > Hope this helps. > > On Fri, Mar 1, 2019 at 2:24 PM Guillaume Pavese < > guillaume.pavese(a)interactiv-group.com> wrote: > >> Hello, >> >> We are planning to deploy VDO with oVirt 4.3 on centos 7.6 (on SSD >> devices). >> As oVirt does not support 4K devices yet, VDO volumes are created with >> the parameter "--emulate512 enabled" >> >> What are the implications of this setting? Does it impact performance? If >> so, is it IOPS or throughput that is impacted? What about reliability (is >> that mode equally tested as standard mode)? >> >> As I saw on RH Bugzilla, support for 4K devices in oVirt will need to >> wait at least for Centos 7.7 >> Once that is supported, would it be possible to transition/upgrade an >> emulate512 vdo volume to a standard one? >> >> Thanks, >> >> Guillaume Pavese >> Ingénieur Système et Réseau >> Interactiv-Group >> _______________________________________________ >> Vdo-devel mailing list >> Vdo-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/vdo-devel >> >

1 0

[RHV] [CQ weekly status] [01-03-2019]
by Dafna Ron 01 Mar '19

01 Mar '19

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-RHV-4.2:* GREEN (#1) Last failure was on 28-02-2019 for project rhevm-appliance due to a failed build-artifacts job. this issue is still happening and message was sent to developer. *CQ-RHV-Master:* GREEN (#1) Last failure is identical to 4.2 - build-artifacts for the same project. ** We do not yet have a 4.3 CQ job which we will start working on next week. Current running jobs for 4.2 [1] and for master [2] can be found below: [1] https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Change%20qu… [2] https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Change%20qu… 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)

1 0

[Ovirt] [CQ weekly status] [01-03-2019]
by Dafna Ron 01 Mar '19

01 Mar '19

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 27-02-2019 on project ovirt-provider-ovn due to a failed build-artifacts job. this issue is now fixed. Please note that this is a CQ job failure but not an OST job failure as we exit if no package is available. *CQ-4.3*: RED (#1) We added a CQ job for 4.3 but not all projects created the branch yet. I created a google sheet to follow the advancement of this work and I will use this report to ask all the managers to go over the doc and add info: https://docs.google.com/spreadsheets/d/1i142cTN_0QwOvogtlQiF6bcIYxTpBqYBed2… *CQ-Master:* RED (#1) We have sporadic failures in test get_host_devices this is effecting all projects and we have yet to know what is causing the issue. Michal checked the issue and thinks the test should be modified to do a re-try as the info is filled by the host 4 seconds after the query is sent. Milan was asked to add a loop with 1s delay to get_host_devices to fix the test. Please note that we have ruled out a possible infra cause for this failure before alerting dev as the failure is sporadic and happens on multiple projects. Jira: https://ovirt-jira.atlassian.net/browse/OVIRT-2686 Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] 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)

1 0

[ OST Failure Report ] [ oVirt Master ] [ 27-02-2019 ] [ 002_bootstrap.get_host_devices]
by Galit Rosenthal 01 Mar '19

01 Mar '19

Hi, we are failing basic suite master (vdsm, ovirt-engine-sdk ...) It happens sporadically. We disqualify that this is an infra issue. Can you please have a look at the issue? ERROR: <testcase classname="002_bootstrap" name="get_host_devices" time="0.077"> <error type="exceptions.RuntimeError" message="*Could not find block_vda_1 device in host devices*: "><![CDATA[Traceback (most recent call last): File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 142, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 60, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 79, in wrapper prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py", line 1016, in get_host_devices raise RuntimeError('Could not find block_vda_1 device in host devices: {}'.format(device_list)) RuntimeError: Could not find block_vda_1 device in host devices: ]]></error> Thanks, Galit Examples, Full logs: [1] https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/ovirt-m… [2] https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/ovirt-m… _______________________________________________ Infra mailing list -- infra(a)ovirt.org To unsubscribe send an email to infra-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/infra@ovirt.org/message/WXW6II3NYEXHI… -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)gmail.com T: 972-9-7692230 <https://red.ht/sig>

9 14

unboundid-ldapsdk-4.0.9 is now available for testing
by Sandro Bonazzola 01 Mar '19

01 Mar '19

On Fedora we had previously 4.0.7. The new releases 4.0.7 will be soon available within repositories for Fedora >= 30 and includes several bug fixes and enhancements. You can see release notes for 4.0.8 and 4.0.9 here: https://github.com/pingidentity/ldapsdk/releases In oVirt this package is required by ovirt-engine-extension-aaa-ldap. If you're going to test the package, please provide feedback here. Martin, Ravi, let me know if you see value in backporting this version to Fedora 28 and EL7 for oVirt 4.3 consumption. Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

[NOTICE] infra issue in progress in jenkins
by Dafna Ron 01 Mar '19

01 Mar '19

Hi, We had a job fail due to a failure in yum. it seems yum is searching for repodata in a wrong location. Evgheni is currently working to investigate and fix the problem and will update soon Jira opened: https://ovirt-jira.atlassian.net/browse/OVIRT-2689 Thanks, Dafna

1 1