May 2017 - Devel - oVirt List Archives

New design for the Gerrit UI
by Evgheni Dereveanchin 06 Sep '17

06 Sep '17

Hi everyone, The Infra team is working on customizing the look of Gerrit to make it fit better with other oVirt services. I want to share the result of this effort. Hopefully we can gather some feedback before applying the design to oVirt's instance of Gerrit. Please visit the Staging instance to check it out: https://gerrit-staging.phx.ovirt.org/ The new design is inspired by oVirt's main website. There is a known glitch that the "Loading Gerrit Code Review" message is overlapped by the logo when the UI is loading. If you spot any other issues or have ideas for improvement feel free to respond to this thread or share your feedback in the following JIRA ticket: https://ovirt-jira.atlassian.net/browse/OVIRT-912 -- Regards, Evgheni Dereveanchin

17 28

Lowering the bar for wiki contribution?
by Roy Golan 22 Jun '17

22 Jun '17

I'm getting the feeling I'm not alone in this, authoring and publishing a wiki page isn't as used to be for long time. I want to suggest a bit lighter workflow: 1. Everyone can merge their page - (it's a wiki) Same as with (public and open) code, no one has the motivation to publish a badly written wiki page under their name. True, it can have an impact, but not as with broken code 2. Use Page-Status marker The author first merges the draft. Its now out there and should be updated as time goes and its status is DRAFT. Maintainers will come later and after review would change the status to PUBLISH. That could be a header in on the page: --- page status: DRAFT/PUBLISH --- Simple I think, and should work.

14 23

[ENGINE][ACTION_NEEDED] - default maintainers, per path
by Roy Golan 19 Jun '17

19 Jun '17

Hi all, Some time ago the infra team enabled *gerrit default reviewer plugin* which you probably noticed if you logged in to gerrit. What we can do is for example set the stable branch maintainers per branch automatically: [filter "branch:ovirt-engine-4.1"] reviewer = stableBranchMaintainersGroup Put people based on path: [filter "branch:master file:^frontend/.*"] reviewer = j.r.r.t(a)shire.me *Action Needed:* Nominate yourself, or others, by amending this patch online [1]. Once this patch is fully acked and agreed we will merge it. If something can't get consensus we will defer it from the patch till maintainers agree. [1] https://gerrit.ovirt.org/#/c/77488/

1 1

Re: [ovirt-devel] Making event types backwards compatible?
by Michal Skrivanek 07 Jun '17

07 Jun '17

> On 29 May 2017, at 11:44, Juan Hernández <jhernand(a)redhat.com> wrote: > >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote: >> >>> On 29 May 2017, at 10:39, Juan Hernández <jhernand(a)redhat.com> wrote: >>> >>> Hello, >>> >>> It has been recently requested that the API provides event types: >>> >>> [RFE] Expose event types to API >>> https://bugzilla.redhat.com/1453170 >>> >>> Currently the API provides the event code and description, for example: >>> >>> <event href="/ovirt-engine/api/events/8021" id="8021"> >>> <code>19</code> >>> <description>Host myhost failed to recover.</description >>> ... >>> </event> >>> >>> There is no documentation of what is the meaning of codes, except the >>> source code of the engine itself. This forces some applications to add >>> their own code to name mapping. For example, the 'ovirt' Ruby gem used >>> by older versions of ManageIQ to interact with oVirt contains the following: >>> >>> https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485 >>> >>> We could avoid this by adding to the API a new event attribute that >>> indicates the type: >>> >>> <event href="/ovirt-engine/api/events/8021" id="8021"> >>> <code>19</code> >>> <type>host_recover_failure</type> >>> <description>Host myhost failed to recover.</description> >>> ... >>> </event> >>> >>> Ideally this should be defined as an enum, so that it will be >>> represented as an enum in the SDKs. Alternatively it could just be an >>> string, and we could reuse the 'name' attribute: >>> >>> <event href="/ovirt-engine/api/events/8021" id="8021"> >>> <code>19</code> >>> <name>host_recover_failure</name> >>> <description>Host myhost failed to recover.</description> >>> ... >>> </event> >>> >>> However, the key point to making this useful would be to keep the types >>> (or names) backwards compatible, so that users of the API can rely on >>> their values and meanings. >>> >>> So this is my question to you: can we commit to keep the names and >>> meanings of the backend event types backwards compatible? >> >> Do we even have to make it bw compatible? >> I guess it depends on the actual usage of those names… >> The ovirt ruby gem itself doesn’t do much with it > > We need to make keep it backwards compatible or else tell users "don't > rely on these values, as they may change without notice". > > The 'ovirt' gem doesn't do anything special, it just creates its own > code to name mapping. But the users of the 'ovirt' gem (the ManageIQ > oVirt provider) do rely on the name. For example: > > > https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models… > > That means that if we ever change the meaning of a code the ManageIQ > provider, for example, will break. Right,then it indeed needs to stay stable. But how is maintaining the enum string different from the code? It is the same information, so if MIQ doesn't use the name directly then it doesn't really matter if it's a code or string. Perhaps deprecate the code and keep the name fixed? Thanks, michal > >>> >>> Regards, >>> Juan Hernandez >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >

4 6

[ovirt-system-tests] ssh to an oVirt VM in Lago
by Valentina Makarova 06 Jun '17

06 Jun '17

Hello! Please, help me to find way to execute some command in oVirt VM. Is it possible to get ssh connection to non-host VM in LAGO? And how can I get ssh connection through the console in my computer? I installed ovirt-system-tests and run tests from basic-suite-master. So there is 2 hosts and 3 vms in my configuration. And I want to execute command inside the vm0 using LAGO (as part of my own test). It is easy for host vm and engine, there is method ''ssh" in ovirt-engine-api-model. And this task for host vm can be performed as there prefix.virt_env.get_vm(VM_NAME).ssh(['bash_command_what_i_want']) Please give me advice, can Iget connection to vm0 in a similar way? And a second question is about ssh to this vm connection from my laptop's console. According run_vm test from 004_basic_sanity.py ( https://github.com/oVirt/ovirt-system-tests/blob/master/basic-suite-master/… ) vm0 should contain interface with ip 192.168.200.200, but ping this from engine (192.168.200.4) Destination Host Unreachable. And 'ping vm0' defined vm0 as 192.168.201.213 and also couldn't reach vm0. And in webadmin (https://engine/ovirt-engine/webadmin/#vms) IP Address field is empty. What is a right way to get connection to vm0 console and execute some command there? Sincerely, Valentina Makarova

5 7

Engine query & action result classes are now final
by Vojtech Szocs 02 Jun '17

02 Jun '17

Hi everyone, yesterday, we merged https://gerrit.ovirt.org/#/c/75705/ which seals Engine query & action result classes. We will follow this up with renaming "VdcReturnValueBase" to "ActionReturnValue" and doing similar renames to existing "VdcSomething" classes. The reason for finalizing those result classes is to avoid us implementing a GWT custom field serializer for each such subclass, therefore limiting our exposure to GWT RPC specifics when transferring objects between client and server. On a side note, we also upgraded GWT 2.8.0 to 2.8.1 which fixes a GWT compiler bug we had to work around: https://gerrit.ovirt.org/#/c/77264/ Regards, Vojtech

1 1

Regarding site bug fix
by shubham dubey 31 May '17

31 May '17

Hi, I want to fix some issues in ovirt site. Since I never did a pull request before, hence want to know few things. 1)can I fix multiple bug and send a single pr for them. 2) when I fix a issue did I need to write something in the comment of the bug (like 'fixed' or 'patch send'). thanks in advance and I will appreciate for extra related info:) Shubham

2 3

Wednesday Website
by Sandro Bonazzola 31 May '17

31 May '17

Hi, oVirt website issues are piling up, currently counting 63 issues[1] reported. I'd like to propose to dedicate one hour next Wednesday, picking one of them and trying to address it. Most of them doesn't require programming skills. [1] https://github.com/oVirt/ovirt-site/issues -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

ovirt-engine-nodejs failing build on fc26
by Sandro Bonazzola 31 May '17

31 May '17

Hi, just an heads up that ovirt-engine-nodejs fails to build on fc26: http://jenkins.ovirt.org/job/ovirt-engine-nodejs_master_build-artifacts-fc2… -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

3 4

[VDSM] Fedora rawhide build - works!
by Nir Soffer 31 May '17

31 May '17

Hi all, We have now a Fedora rawhide build on travis: https://travis-ci.org/nirs/vdsm/builds/231649060 To make it work, I had to: - disable kvm2ovirt import test, since ovirt-imageio-common is not available for rawhide on ovirt repos Building ovirt-imageio for rawhide should be easy - disable 2 tests importing blivet, since importing it fail with ValueError on rawhide (blivet bug?) The build is using ovirtorg/vdsm-test-fedora-rawhide image. Please review: https://gerrit.ovirt.org/#/q/topic:rawhide Cheers, Nir

2 3

Re: [ovirt-devel] Making event types backwards compatible?
by Oved Ourfali 30 May '17

30 May '17

On May 30, 2017 11:28, "Juan Hernández" <jhernand(a)redhat.com> wrote: On 05/30/2017 09:38 AM, Tomas Jelinek wrote: > > > On Tue, May 30, 2017 at 9:16 AM, Juan Hernández <jhernand(a)redhat.com > <mailto:jhernand@redhat.com>> wrote: > > On 05/30/2017 08:55 AM, Tomas Jelinek wrote: > > > > > > On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek < mskrivan(a)redhat.com <mailto:mskrivan@redhat.com> > > <mailto:mskrivan@redhat.com <mailto:mskrivan@redhat.com>>> wrote: > > > > > On 29 May 2017, at 11:44, Juan Hernández <jhernand(a)redhat.com <mailto:jhernand@redhat.com> > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> wrote: > > > > > >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote: > > >> > > >>> On 29 May 2017, at 10:39, Juan Hernández < jhernand(a)redhat.com <mailto:jhernand@redhat.com> > > <mailto:jhernand@redhat.com <mailto:jhernand@redhat.com>>> wrote: > > >>> > > >>> Hello, > > >>> > > >>> It has been recently requested that the API provides event > types: > > >>> > > >>> [RFE] Expose event types to API > > >>> https://bugzilla.redhat.com/1453170 > <https://bugzilla.redhat.com/1453170> > > <https://bugzilla.redhat.com/1453170 > <https://bugzilla.redhat.com/1453170>> > > >>> > > >>> Currently the API provides the event code and description, for > > example: > > >>> > > >>> <event href="/ovirt-engine/api/events/8021" id="8021"> > > >>> <code>19</code> > > >>> <description>Host myhost failed to recover.</description > > >>> ... > > >>> </event> > > >>> > > >>> There is no documentation of what is the meaning of codes, > > except the > > >>> source code of the engine itself. This forces some > applications > > to add > > >>> their own code to name mapping. For example, the 'ovirt' Ruby > > gem used > > >>> by older versions of ManageIQ to interact with oVirt contains > > the following: > > >>> > > >>> > > > https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/ event.rb#L25-L485 > <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/ event.rb#L25-L485> > > > <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/ event.rb#L25-L485 > <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/ event.rb#L25-L485>> > > >>> > > >>> We could avoid this by adding to the API a new event > attribute that > > >>> indicates the type: > > >>> > > >>> <event href="/ovirt-engine/api/events/8021" id="8021"> > > >>> <code>19</code> > > >>> <type>host_recover_failure</type> > > >>> <description>Host myhost failed to recover.</description> > > >>> ... > > >>> </event> > > >>> > > >>> Ideally this should be defined as an enum, so that it will be > > >>> represented as an enum in the SDKs. Alternatively it could > just > > be an > > >>> string, and we could reuse the 'name' attribute: > > >>> > > >>> <event href="/ovirt-engine/api/events/8021" id="8021"> > > >>> <code>19</code> > > >>> <name>host_recover_failure</name> > > >>> <description>Host myhost failed to recover.</description> > > >>> ... > > >>> </event> > > >>> > > >>> However, the key point to making this useful would be to keep > > the types > > >>> (or names) backwards compatible, so that users of the API can > > rely on > > >>> their values and meanings. > > >>> > > >>> So this is my question to you: can we commit to keep the > names and > > >>> meanings of the backend event types backwards compatible? > > >> > > >> Do we even have to make it bw compatible? > > >> I guess it depends on the actual usage of those names… > > >> The ovirt ruby gem itself doesn’t do much with it > > > > > > We need to make keep it backwards compatible or else tell > users "don't > > > rely on these values, as they may change without notice". > > > > > > The 'ovirt' gem doesn't do anything special, it just creates > its own > > > code to name mapping. But the users of the 'ovirt' gem (the > ManageIQ > > > oVirt provider) do rely on the name. For example: > > > > > > > > > > https://github.com/ManageIQ/manageiq-providers-ovirt/blob/ master/app/models/manageiq/providers/redhat/infra_ manager/event_parser.rb#L80-L92 > <https://github.com/ManageIQ/manageiq-providers-ovirt/blob/ master/app/models/manageiq/providers/redhat/infra_ manager/event_parser.rb#L80-L92> > > > <https://github.com/ManageIQ/manageiq-providers-ovirt/blob/ master/app/models/manageiq/providers/redhat/infra_ manager/event_parser.rb#L80-L92 > <https://github.com/ManageIQ/manageiq-providers-ovirt/blob/ master/app/models/manageiq/providers/redhat/infra_ manager/event_parser.rb#L80-L92>> > > > > > > hmmm, while we are on topic, this pretty much looks like that manageiq > > does not only rely on the code but also on the actual value of it > since > > it is parsing it: > > > > # sample message: "Interface nic1 (VirtIO) was added to VM v5. (User: > > admin@internal-authz)" message.split(/\s/)[7][0...-1] > > > > Is this something we commit to maintain? Or should we commit to > maintain it? > > > > That is a good point, that isn't very future proof. We should also find > a way to make less fragile. Any suggestion? > > > The only doable thing which comes to my mind is something like this: > The msg is defined like this: > USER_ADD_VM_POOL_WITH_VMS_FAILED=Failed to create VM Pool ${VmPoolName} > (User: ${UserName}). > > e.g. the msg type and the variables. If we could expose in the api not > only the substituted msg but also the variable/value binding, we could > commit to keep the variable names backward compatible. > > So, something like: > > <event href="/ovirt-engine/api/events/8021" id="8021"> > <code>19</code> > <type>USER_ADD_VM_POOL_WITH_VMS_FAILED</type> > <description>the substituted msg.</description> > <parameters> > <parameter> > <key>VmPoolName</key> > <value>The Pool Name<value> > </parameter> > ... > </parameters> > </event> > > Not really rock solid since the variables would still be defined in the > AuditLogMessages.properties but still better and still easier to parse > on the client side. > That makes sense to me. I have opened the following bug to track that: [RFE] Add properties to events https://bugzilla.redhat.com/1456711 Note that for the particular case of the VM name, which is what ManageIQ is trying to do in that caode, the current best way is to use the <vm .../> link that is part of the event. I have opened the following ManageIQ issue to track it: Avoid parsing the descriptions of events https://github.com/ManageIQ/manageiq-providers-ovirt/issues/45 I think it was introduced while working on targeted refresh, but if we have an alternative then of course it would be better. > > > > > > > > > That means that if we ever change the meaning of a code the ManageIQ > > > provider, for example, will break. > > > > Right,then it indeed needs to stay stable. > > But how is maintaining the enum string different from the code? It is > > the same information, so if MIQ doesn't use the name directly then it > > doesn't really matter if it's a code or string. > > Perhaps deprecate the code and keep the name fixed? > > > > Thanks, > > michal > > > > > > > >>> > > >>> Regards, > > >>> Juan Hernandez > > >>> > > >>> > > >>> _______________________________________________ > > >>> Devel mailing list > > >>> Devel(a)ovirt.org <mailto:Devel@ovirt.org> > <mailto:Devel@ovirt.org <mailto:Devel@ovirt.org>> > > >>> http://lists.ovirt.org/mailman/listinfo/devel > <http://lists.ovirt.org/mailman/listinfo/devel> > > <http://lists.ovirt.org/mailman/listinfo/devel > <http://lists.ovirt.org/mailman/listinfo/devel>> > > > > > _______________________________________________ > > Devel mailing list > > Devel(a)ovirt.org <mailto:Devel@ovirt.org> > <mailto:Devel@ovirt.org <mailto:Devel@ovirt.org>> > > http://lists.ovirt.org/mailman/listinfo/devel > <http://lists.ovirt.org/mailman/listinfo/devel> > > <http://lists.ovirt.org/mailman/listinfo/devel > <http://lists.ovirt.org/mailman/listinfo/devel>> > > > > > > _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

2 1

[ OST Failure Report ] [ oVirt master ] [ 29/05/2017 ] [test_ovn_provider_keystone_token]
by Barak Korren 30 May '17

30 May '17

Test failed: [ test_ovn_provider_keystone_token ] Link to suspected patches: - https://gerrit.ovirt.org/#/c/76775/ Link to Job: - jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6899/ Link to all logs: - http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6899/artif… Error snippet from log: <error> Incorrect provider auth token value: PogQegXeOZwDg1dpKdrp-Wc2qJLt5QzSYMbeHZiPRU5wCCDOEaHRHXzvjY9FEso5Y2zdbzDIXHzxAT0XVpaKiQ -------------------- >> begin captured logging << -------------------- requests.packages.urllib3.connectionpool: INFO: * Starting new HTTPS connection (1): 192.168.201.3 py.warnings: WARNING: * Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html requests.packages.urllib3.connectionpool: DEBUG: "POST /v2.0/tokens HTTP/1.1" 200 None --------------------- >> end captured logging << --------------------- </error> This had been failing constantly for 5 runs... -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

3 2

[ OST Failure Report ] [ oVirt master ] [ 28-05-2017 ] [ 004_basic_sanity.hotunplug_disk ]
by Dafna Ron 29 May '17

29 May '17

This is a multi-part message in MIME format. --------------992DE8C067CE91FDF29339AC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ** *Hi All, * * ** *We are seeing the same failure**sporadically**in *three*different places (hotunplug disk). * *We think this is a race condition which was introduced to OST with the the live storage migration test (lock on the disk is preventing the hotunplug). * Test failed: [ 004_basic_sanity.hotunplug_disk] Link to suspected patches: https://gerrit.ovirt.org/#/c/77083 Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6881 ** Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6881/artif… Error snippet from the log: <error> * Error Message status: 409 reason: Conflict detail: Cannot hot unplug Virtual Disk. Disk vm0_disk0 is being moved or copied. Stacktrace 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 129, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 68, in wrapper return func(prefix.virt_env.engine_vm().get_api(), *args, **kwargs) File "/home/jenkins/workspace/test-repo_ovirt_experimental_master/ovirt-system-tests/basic-suite-master/test-scenarios/004_basic_sanity.py", line 498, in hotunplug_disk disk.deactivate() File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", line 31839, in deactivate headers={"Correlation-Id":correlation_id} File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 122, in request persistent_auth=self.__persistent_auth File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", line 79, in do_request persistent_auth) File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", line 162, in __do_request raise errors.RequestError(response_code, response_reason, response_body) RequestError: status: 409 reason: Conflict detail: Cannot hot unplug Virtual Disk. Disk vm0_disk0 is being moved or copied. from engine log: 2017-05-28 09:05:32,891-04 INFO [org.ovirt.engine.core.bll.storage.disk.HotUnPlugDiskFromVmCommand] (default task-10) [6d47ba60-4491-48ab-bb1c-fb0cdbeb76b0] Failed to Acquire Lock to object 'EngineLock:{exclusiveLocks='[9e7d8b37-2afb-4012-9bc9-8cc277ac9cdd=<DISK, ACTION_TYPE_FAILED_DISKS_LOCKED$diskAliases vm0_disk0>]', sharedLocks='[461224f5-a2af-4be2-ba1b-3563a88f398c=<VM, ACTION_TYPE_FAILED_VM_IS_LOCKED>]'}' 2017-05-28 09:05:32,891-04 WARN [org.ovirt.engine.core.bll.storage.disk.HotUnPlugDiskFromVmCommand] (default task-10) [6d47ba60-4491-48ab-bb1c-fb0cdbeb76b0] Validation of action 'HotUnPlugDiskFromVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__HOT_UNPLUG,VAR__TYPE__DISK,ACTION_TYPE_FAILED_DISK_IS_BEING_MIGRATED,$DiskName vm0_disk0 2017-05-28 09:05:32,895-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-10) [] Operation Failed: [Cannot hot unplug Virtual Disk. Disk vm0_disk0 is being moved or copied.] 2017-05-28 09:05:33,323-04 INFO [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (DefaultQuartzScheduler8) [99f56ceb-3c13-423f-b015-71222a8fec01] Ending command 'org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand' successfully. 2017-05-28 09:05:33,324-04 INFO [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (DefaultQuartzScheduler8) [99f56ceb-3c13-423f-b015-71222a8fec01] Lock freed to object 'EngineLock:{exclusiveLocks='[9e7d8b37-2afb-4012-9bc9-8cc277ac9cdd=<DISK, ACTION_TYPE_FAILED_DISK_IS_BEING_MIGRATED$DiskName vm0_disk0>]', sharedLocks='[461224f5-a2af-4be2-ba1b-3563a88f398c=<VM, ACTION_TYPE_FAILED_OBJECT_LOCKED>]'}' ** *</error>* * * --------------992DE8C067CE91FDF29339AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Hi All, <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">We are seeing the same failure<span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"> sporadically<span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"> in <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">three<span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"> different places (hotunplug disk). <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">We think this is a race condition which was introduced to OST with the the live storage migration test (lock on the disk is preventing the hotunplug). <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Test failed: [ 004_basic_sanity.hotunplug_disk] <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Link to suspected patches: <a class="moz-txt-link-freetext" href="https://gerrit.ovirt.org/#/c/77083">https://gerrit.ovirt.org/#/c/77083</a> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Link to Job: <a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6881">http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6881</a> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Link to all logs: <a class="moz-txt-link-freetext" href="http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6881/artif…">http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6881/artif…</a> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;">Error snippet from the log: <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"><error> <h3 style="box-sizing: border-box; color: rgb(51, 51, 51); font-family: Helvetica, Arial, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">Error Message</h3> <pre style="box-sizing: border-box; white-space: pre-wrap; word-wrap: break-word; margin: 0px; color: rgb(51, 51, 51); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">status: 409 reason: Conflict detail: Cannot hot unplug Virtual Disk. Disk vm0_disk0 is being moved or copied.</pre> <h3 style="box-sizing: border-box; color: rgb(51, 51, 51); font-family: Helvetica, Arial, sans-serif; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">Stacktrace</h3> <pre style="box-sizing: border-box; white-space: pre-wrap; word-wrap: break-word; margin: 0px; color: rgb(51, 51, 51); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">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 129, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 68, in wrapper return func(prefix.virt_env.engine_vm().get_api(), *args, **kwargs) File "/home/jenkins/workspace/test-repo_ovirt_experimental_master/ovirt-system-tests/basic-suite-master/test-scenarios/004_basic_sanity.py", line 498, in hotunplug_disk disk.deactivate() File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", line 31839, in deactivate headers={"Correlation-Id":correlation_id} File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line 122, in request persistent_auth=self.__persistent_auth File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", line 79, in do_request persistent_auth) File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", line 162, in __do_request raise errors.RequestError(response_code, response_reason, response_body) RequestError: status: 409 reason: Conflict detail: Cannot hot unplug Virtual Disk. Disk vm0_disk0 is being moved or copied. from engine log: 2017-05-28 09:05:32,891-04 INFO [org.ovirt.engine.core.bll.storage.disk.HotUnPlugDiskFromVmCommand] (default task-10) [6d47ba60-4491-48ab-bb1c-fb0cdbeb76b0] Failed to Acquire Lock to object 'EngineLock:{exclusiveLocks='[9e7d8b37-2afb-4012-9bc9-8cc277ac9cdd=<DISK, ACTION_TYPE_FAILED_DISKS_LOCKED$diskAliases vm0_disk0>]', sharedLocks='[461224f5-a2af-4be2-ba1b-3563a88f398c=<VM, ACTION_TYPE_FAILED_VM_IS_LOCKED>]'}' 2017-05-28 09:05:32,891-04 WARN [org.ovirt.engine.core.bll.storage.disk.HotUnPlugDiskFromVmCommand] (default task-10) [6d47ba60-4491-48ab-bb1c-fb0cdbeb76b0] Validation of action 'HotUnPlugDiskFromVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__HOT_UNPLUG,VAR__TYPE__DISK,ACTION_TYPE_FAILED_DISK_IS_BEING_MIGRATED,$DiskName vm0_disk0 2017-05-28 09:05:32,895-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-10) [] Operation Failed: [Cannot hot unplug Virtual Disk. Disk vm0_disk0 is being moved or copied.] 2017-05-28 09:05:33,323-04 INFO [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (DefaultQuartzScheduler8) [99f56ceb-3c13-423f-b015-71222a8fec01] Ending command 'org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand' successfully. 2017-05-28 09:05:33,324-04 INFO [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (DefaultQuartzScheduler8) [99f56ceb-3c13-423f-b015-71222a8fec01] Lock freed to object 'EngineLock:{exclusiveLocks='[9e7d8b37-2afb-4012-9bc9-8cc277ac9cdd=<DISK, ACTION_TYPE_FAILED_DISK_IS_BEING_MIGRATED$DiskName vm0_disk0>]', sharedLocks='[461224f5-a2af-4be2-ba1b-3563a88f398c=<VM, ACTION_TYPE_FAILED_OBJECT_LOCKED>]'}' </pre> <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap;"></error> </body> </html> --------------992DE8C067CE91FDF29339AC--

3 3

Re: [ovirt-devel] [oVirt Jenkins] ovirt_4.1_hc-system-tests - Build # 76 - Failure!
by Eyal Edri 29 May '17

29 May '17

Adding devel and Piotr. On Thu, May 25, 2017 at 9:31 AM, Sahina Bose <sabose(a)redhat.com> wrote: > Connecting to lago-hc-basic-suite-4-1-host0.lago.local/192.168.200.2 > 2017-05-24 23:31:00,492-04 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-7-thread-1) [712d05a6] Error: org.ovirt.engine.core.vdsbroker.TransportRunTimeException: Connection issues during send request > 2017-05-24 23:31:00,492-04 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (org.ovirt.thread.pool-7-thread-1) [712d05a6] Exception: java.util.concurrent.ExecutionException: org.ovirt.engine.core.vdsbroker.TransportRunTimeException: Connection issues during send request > Caused by: java.lang.ClassNotFoundException: org.apache.commons.lang.StringUtils from [Module "org.ovirt.vdsm-jsonrpc-java:main" from local module loader @5e91993f (finder: local module finder @1c4af82c (roots: /usr/share/ovirt-engine-wildfly-overlay/modules,/usr/share/ovirt-engine/modules/common,/usr/share/ovirt-engine-extension-aaa-jdbc/modules,/usr/share/ovirt-engine-wildfly/modules,/usr/share/ovirt-engine-wildfly/modules/system/layers/base))] > > > Known issue? > > > On Thu, May 25, 2017 at 9:16 AM, <jenkins(a)jenkins.phx.ovirt.org> wrote: > >> Project: http://jenkins.ovirt.org/job/ovirt_4.1_hc-system-tests/ >> Build: http://jenkins.ovirt.org/job/ovirt_4.1_hc-system-tests/76/ >> Build Number: 76 >> Build Status: Failure >> Triggered By: Started by timer >> >> ------------------------------------- >> Changes Since Last Success: >> ------------------------------------- >> Changes for Build #76 >> [Ondřej Svoboda] Use SDKv4 code in add_labeled_network. >> >> [Barak Korren] Refactor: Use macros in defaults file >> >> [Barak Korren] Default values for 'arch' and 'distro' in STD-CI >> >> >> >> >> ----------------- >> Failed Tests: >> ----------------- >> 1 tests failed. >> FAILED: 002_bootstrap.add_hosts >> >> Error Message: >> >> status: 409 >> reason: Conflict >> detail: Cannot add Host. There is no available server in the cluster to >> probe the new server. >> -------------------- >> begin captured logging << -------------------- >> lago.utils: ERROR: Error while running thread >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in >> _ret_via_queue >> queue.put({'return': func()}) >> File "/home/jenkins/workspace/ovirt_4.1_hc-system-tests/ovirt-sys >> tem-tests/hc-basic-suite-4.1/test-scenarios/002_bootstrap.py", line 141, >> in _add_host >> return api.hosts.add(p) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", >> line 18306, in add >> headers={"Correlation-Id":correlation_id, "Expect":expect} >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", >> line 79, in add >> return self.request('POST', url, body, headers, cls=cls) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", >> line 122, in request >> persistent_auth=self.__persistent_auth >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", >> line 79, in do_request >> persistent_auth) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", >> line 162, in __do_request >> raise errors.RequestError(response_code, response_reason, >> response_body) >> RequestError: >> status: 409 >> reason: Conflict >> detail: Cannot add Host. There is no available server in the cluster to >> probe the new server. >> lago.utils: ERROR: Error while running thread >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in >> _ret_via_queue >> queue.put({'return': func()}) >> File "/home/jenkins/workspace/ovirt_4.1_hc-system-tests/ovirt-sys >> tem-tests/hc-basic-suite-4.1/test-scenarios/002_bootstrap.py", line 141, >> in _add_host >> return api.hosts.add(p) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", >> line 18306, in add >> headers={"Correlation-Id":correlation_id, "Expect":expect} >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", >> line 79, in add >> return self.request('POST', url, body, headers, cls=cls) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", >> line 122, in request >> persistent_auth=self.__persistent_auth >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", >> line 79, in do_request >> persistent_auth) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", >> line 162, in __do_request >> raise errors.RequestError(response_code, response_reason, >> response_body) >> RequestError: >> status: 409 >> reason: Conflict >> detail: Cannot add Host. There is no available server in the cluster to >> probe the new server. >> --------------------- >> end captured logging << --------------------- >> >> Stack Trace: >> 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 >> 129, in wrapped_test >> test() >> File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, >> in wrapper >> return func(get_test_prefix(), *args, **kwargs) >> File "/home/jenkins/workspace/ovirt_4.1_hc-system-tests/ovirt-sys >> tem-tests/hc-basic-suite-4.1/test-scenarios/002_bootstrap.py", line 160, >> in add_hosts >> nt.assert_true(all(vt.join_all())) >> File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in >> _ret_via_queue >> queue.put({'return': func()}) >> File "/home/jenkins/workspace/ovirt_4.1_hc-system-tests/ovirt-sys >> tem-tests/hc-basic-suite-4.1/test-scenarios/002_bootstrap.py", line 141, >> in _add_host >> return api.hosts.add(p) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", >> line 18306, in add >> headers={"Correlation-Id":correlation_id, "Expect":expect} >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", >> line 79, in add >> return self.request('POST', url, body, headers, cls=cls) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", >> line 122, in request >> persistent_auth=self.__persistent_auth >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", >> line 79, in do_request >> persistent_auth) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", >> line 162, in __do_request >> raise errors.RequestError(response_code, response_reason, >> response_body) >> >> status: 409 >> reason: Conflict >> detail: Cannot add Host. There is no available server in the cluster to >> probe the new server. >> -------------------- >> begin captured logging << -------------------- >> lago.utils: ERROR: Error while running thread >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in >> _ret_via_queue >> queue.put({'return': func()}) >> File "/home/jenkins/workspace/ovirt_4.1_hc-system-tests/ovirt-sys >> tem-tests/hc-basic-suite-4.1/test-scenarios/002_bootstrap.py", line 141, >> in _add_host >> return api.hosts.add(p) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", >> line 18306, in add >> headers={"Correlation-Id":correlation_id, "Expect":expect} >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", >> line 79, in add >> return self.request('POST', url, body, headers, cls=cls) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", >> line 122, in request >> persistent_auth=self.__persistent_auth >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", >> line 79, in do_request >> persistent_auth) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", >> line 162, in __do_request >> raise errors.RequestError(response_code, response_reason, >> response_body) >> RequestError: >> status: 409 >> reason: Conflict >> detail: Cannot add Host. There is no available server in the cluster to >> probe the new server. >> lago.utils: ERROR: Error while running thread >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in >> _ret_via_queue >> queue.put({'return': func()}) >> File "/home/jenkins/workspace/ovirt_4.1_hc-system-tests/ovirt-sys >> tem-tests/hc-basic-suite-4.1/test-scenarios/002_bootstrap.py", line 141, >> in _add_host >> return api.hosts.add(p) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", >> line 18306, in add >> headers={"Correlation-Id":correlation_id, "Expect":expect} >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", >> line 79, in add >> return self.request('POST', url, body, headers, cls=cls) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", >> line 122, in request >> persistent_auth=self.__persistent_auth >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", >> line 79, in do_request >> persistent_auth) >> File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py", >> line 162, in __do_request >> raise errors.RequestError(response_code, response_reason, >> response_body) >> RequestError: >> status: 409 >> reason: Conflict >> detail: Cannot add Host. There is no available server in the cluster to >> probe the new server. >> --------------------- >> end captured logging << --------------------- > > > > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > > -- Eyal edri ASSOCIATE MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

4 7

Making event types backwards compatible?
by Juan Hernández 29 May '17

29 May '17

Hello, It has been recently requested that the API provides event types: [RFE] Expose event types to API https://bugzilla.redhat.com/1453170 Currently the API provides the event code and description, for example: <event href="/ovirt-engine/api/events/8021" id="8021"> <code>19</code> <description>Host myhost failed to recover.</description ... </event> There is no documentation of what is the meaning of codes, except the source code of the engine itself. This forces some applications to add their own code to name mapping. For example, the 'ovirt' Ruby gem used by older versions of ManageIQ to interact with oVirt contains the following: https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485 We could avoid this by adding to the API a new event attribute that indicates the type: <event href="/ovirt-engine/api/events/8021" id="8021"> <code>19</code> <type>host_recover_failure</type> <description>Host myhost failed to recover.</description> ... </event> Ideally this should be defined as an enum, so that it will be represented as an enum in the SDKs. Alternatively it could just be an string, and we could reuse the 'name' attribute: <event href="/ovirt-engine/api/events/8021" id="8021"> <code>19</code> <name>host_recover_failure</name> <description>Host myhost failed to recover.</description> ... </event> However, the key point to making this useful would be to keep the types (or names) backwards compatible, so that users of the API can rely on their values and meanings. So this is my question to you: can we commit to keep the names and meanings of the backend event types backwards compatible? Regards, Juan Hernandez

2 2

Fedora wiki: oVirt
by Sandro Bonazzola 29 May '17

29 May '17

Hi, looking at https://fedoraproject.org/wiki/Features/oVirt I think we should state oVirt is not shipped within Fedora anymore and our plans about either abandon the feature or re-target it. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

2 1

ovirt-imageio leaves .guestfs-0 folder under /var/tmp during check-patch
by Gil Shinar 28 May '17

28 May '17

Hi, Should it be like that? Is there a way to clean this leftover in the check-patch script? Thanks Gil

6 24

[ENGINE] standardizing query creation
by Allon Mureinik 26 May '17

26 May '17

Hi list, As you may have noticed, there's a bit of an ambiguity on how query objects are created - some have a constructor from a parameters object, some have a constructor from a parameters object and an EngineContext, and some have both. This ambiguity leads to all sorts of annoying bugs where some queries can't be used as internal queries (because they lack the proper constructor), or other queries couldn't be used without a context. I just merged a series of patches to streamline queries creation and eliminate the problem. Looking forwards, queries should have a single constructor receiving a parameters object and a context and pass them on to super. A unit test was added to enforce this constructor's existence in build time. From a caller's perspective, nothing's changed, and all of the Backend#run[Internal]Query methods were left unchanged. The build, CI and OST suite were ran on this patch series and everything seems to be in order, but please let me know if you encounter any issues. -Allon

1 0

upgrade of CL and DC vs running VMs
by Michal Skrivanek 25 May '17

25 May '17

Hi all, I believe that introduction of bug 1413150 (Add warning to change CL to the match the installed engine version) may have an unfortunate consequence of people actually moving forward with the CL and DC without realizing the constraints on running existing VMs. The periodic nagging is likely going to make people run into the following issue even more frequently We have a cluster level override per VM which takes care of compatibility on CL update by setting the VM’s override to the original CL - that is visible in VM properties, but that’s pretty much it, it’s not very prominent at the moment and it can’t be searched on (bug 1454389). When the update cluster change is made there is a dialog informing you, and there’s also the pending config change for those running VMs…until you shut the VM down, from that time on it only has the CL override set. But the real problem is with DC which AFAIK does not have an override capability, and currently does not have any checks for running VMs. With the above mechanism you can easily get a VM with CL override (say. 3.6) and mindlessly updated DC to 4.1…and once you stop such VM you won’t be able to start it anymore as there is a proper check for unsupported 3.6 CL VM in a newer DC (as implemented by bug 1436577 - Solve DC/Cluster upgrade of VMs with now-unsupported custom compatibility level) We either need to warn/block on DC upgrade, or implement some kind of a DC override (I guess this is a storage question?) Thoughts/ideas? Thanks, michal

3 3

OST - possible failure today due to patches in two projects
by Marcin Mirecki 25 May '17

25 May '17

Hi all, Related patches in two different projects were merged today, which might result in the OST's failing for a while until changes from both projects are picked up. The affected test suite: basic-suite-master The affected test scenario: 098_ovirt_provider_ovn The related patches: https://gerrit.ovirt.org/#/c/77028/ https://gerrit.ovirt.org/#/c/77029/ Thanks, Marcin

2 1

ovirt-provider-ovn versioning issue
by Sandro Bonazzola 25 May '17

25 May '17

Hi, noticed you're going to release ovirt-provider-ovn-1.0-8.tar.gz <http://jenkins.ovirt.org/job/ovirt-provider-ovn_4.1_build-artifacts-fc24-x8…> as a new version. Please note that version is usually something like x.y.z and not x.y-r The release suffix is used in general by distribution packagers to address build issues specific to distributions. If tomorrow I'll have to rebuild ovirt-provider-ovn for CentOS or Fedora I'll have to rename the package to: ovirt-provide-ovn-1.0_8-1.fc27 because you're misusing the release suffix in the package naming. Please consider proper versioning for ovirt-provider-ovn. Thanks. -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

2 1

Jenkins was down
by Gil Shinar 24 May '17

24 May '17

Hi all, Our Jenkins had an issue that caused it to use 100% CPU. We needed to restart it and now it is working fine again. If any of you sent patches that had failed to run check-[patch/merged], build-artifa during that time, please retrigger your patches. Sorry and thanks Gil

1 0

test-repo_ovirt_experimental_4.1 failing
by Dusan Fodor 24 May '17

24 May '17

Hello all, experimental 4.1 is failing. Could anyone assist? [first failed job] <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper…> So far i see 3 issues there: - PollVDSCommand error, which has been discussed previously in thread [ovirt-devel] [OST Failure Report][oVirt master][2017-04-11] [log link] <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper…> - wrong gdeploy package 2017-05-23 15:08:42,709::ERROR::root::Wrong distribution for package: gdeploy-2.0.2 [log link] <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper…> - MOM couldn't connect to VDSM [log link] <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper…>

3 4

high performance VM preset
by Michal Skrivanek 24 May '17

24 May '17

Hi all, we plan to work on an improvement in VM definition for high performance workloads which do not require desktop-class devices and generally favor highest possible performance in expense of less flexibility. We’re thinking of adding a new VM preset in addition to current Desktop and Server in New VM dialog, which would automatically pre-select existing options in the right way, and suggest/warn on suboptimal configuration All the presets and warning can be changed and ignored. There are few things we already identified as boosting performance and/or minimize the complexity of the VM, so we plan the preset to: - remove all graphical consoles and set the VM as headless, making it accessible by serial console. - disable all USB. - disable soundcard. - enable I/O Threads, just one for all disks by default. - set host cpu passthrough (effectively disabling VM live migration), add I/O Thread pinning in a similar way as the existing CPU pinning. We plan the following checks and suggest to perform CPU pinning, host topology == guest topology (number of cores per socket and threads per core should match), NUMA topology host and guest match, check and suggest the I/O threads pinning. A popup on a VM dialog save seems suitable. currently identified task and status can be followed on trello card[1] Please share your thoughts, questions, any kind of feedback… Thanks, michal [1] https://trello.com/c/MHRDD8ZO

4 5

[rhevm-qe-automation/ovirt-ansible] Question on where does the jinja2 var {{ ansible_fqdn }} get set
by Tasdik Rahman 24 May '17

24 May '17

--_000_EC0D0D5060F9400E89D122BCA527DCEEoutlookcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCiBJIHdhcyBoYXZpbmcgYSBsb29rIGF0IHRoZSBhbnNpYmxlIHBsYXlib29rcyB0 byBhdXRtYXRlIHRoZSBpbnN0YWxsYXRpb24gb2Ygb3ZpcnQtZW5naW5lIG9uIGEgcmVtb3RlIGhv c3QgaGVyZSBhdCBodHRwczovL2dpdGh1Yi5jb20vcmhldm0tcWUtYXV0b21hdGlvbi9vdmlydC1h bnNpYmxlLyBzcGVjaWZpY2FsbHkgdGhlIHJvbGUgZW5naW5lLXNldHVwLiBJIHdhcyBjdXJpb3Vz IHdoZXJlIHRoaXMgamluamEgdmFyaWFibGUge3thbnNpYmxlX2ZxZG59fSBnZXRzIHNldC4gIEkg Y291bGQgbm90IHNlZSBpdCBiZWluZyBhc3NpZ25lZCBpbiB0aGUgcGxheWJvb2tzLiBPciBkbyB3 ZSBzZXQgaXQgZHVyaW5nIHRoZSBwbGF5Ym9vayBleGVjdXRpb24gYXMgYSBjb21tYW5kIGxpbmUg YXJnPw0KDQpSZWxldmFudCBzZWFyY2ggaHR0cHM6Ly9naXRodWIuY29tL3JoZXZtLXFlLWF1dG9t YXRpb24vb3ZpcnQtYW5zaWJsZS9zZWFyY2g/dXRmOD0lRTIlOUMlOTMmcT1hbnNpYmxlX2ZxZG4m dHlwZT08aHR0cHM6Ly9naXRodWIuY29tL3JoZXZtLXFlLWF1dG9tYXRpb24vb3ZpcnQtYW5zaWJs ZS9zZWFyY2g/dXRmOD3inJMmcT1hbnNpYmxlX2ZxZG4mdHlwZT0+DQoNCg0KDQpSZWdhcmRzLA0K VGFzZGlrIFJhaG1hbg0KaHR0cDovL3Rhc2Rpa3JhaG1hbi5tZS8NCg0KDQoNCg== --_000_EC0D0D5060F9400E89D122BCA527DCEEoutlookcom_ Content-Type: text/html; charset="utf-8" Content-ID: <F904AC15C81B9244BB3748791CC01E35(a)apcprd02.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzLCAnTHVjaWRhIENvbnNvbGUnLCBtb25vc3BhY2U7 IGZvbnQtc2l6ZTogMTIuOHB4OyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhh bnM6IDI7IHRleHQtaW5kZW50OiAtN3B4OyB3aWRvd3M6IDI7IGJhY2tncm91bmQtY29sb3I6IHJn YigyNDAsIDI0NywgMjU1KTsiIGNsYXNzPSIiPkhlbGxvLDwvc3Bhbj48L2Rpdj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsICdMdWNpZGEgQ29uc29sZScsIG1vbm9zcGFjZTsg Zm9udC1zaXplOiAxMi44cHg7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFu czogMjsgdGV4dC1pbmRlbnQ6IC03cHg7IHdpZG93czogMjsgYmFja2dyb3VuZC1jb2xvcjogcmdi KDI0MCwgMjQ3LCAyNTUpOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogQ29uc29sYXMsICdMdWNpZGEgQ29uc29sZScsIG1vbm9zcGFjZTsgZm9udC1z aXplOiAxMi44cHg7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgb3JwaGFuczogMjsg dGV4dC1pbmRlbnQ6IC03cHg7IHdpZG93czogMjsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0MCwg MjQ3LCAyNTUpOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KJm5ic3A7 SSB3YXMgaGF2aW5nIGEgbG9vayBhdCB0aGUgYW5zaWJsZSBwbGF5Ym9va3MgdG8gYXV0bWF0ZSB0 aGUgaW5zdGFsbGF0aW9uIG9mIG92aXJ0LWVuZ2luZSBvbiBhIHJlbW90ZSBob3N0IGhlcmUgYXQm bmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3JoZXZtLXFlLWF1dG9tYXRp b24vb3ZpcnQtYW5zaWJsZS8iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iZm9udC1mYW1pbHk6IENv bnNvbGFzLCAnTHVjaWRhIENvbnNvbGUnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTIuOHB4OyBm b250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtaW5kZW50OiAt N3B4OyB3aWRvd3M6IDI7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDAsIDI0NywgMjU1KTsiIGNs YXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9yaGV2bS1xZS1hdXRvbWF0aW9uL292aXJ0LWFuc2li bGUvPC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXMsICdMdWNpZGEgQ29uc29s ZScsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMi44cHg7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6 IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1pbmRlbnQ6IC03cHg7IHdpZG93czogMjsgYmFja2dy b3VuZC1jb2xvcjogcmdiKDI0MCwgMjQ3LCAyNTUpOyIgY2xhc3M9IiI+Jm5ic3A7c3BlY2lmaWNh bGx5DQogdGhlIHJvbGUgZW5naW5lLXNldHVwLiBJIHdhcyBjdXJpb3VzIHdoZXJlIHRoaXMgamlu amEgdmFyaWFibGUge3thbnNpYmxlX2ZxZG59fSBnZXRzIHNldC48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBDb25zb2xhcywgJ0x1Y2lkYSBDb25zb2xlJywgbW9ub3NwYWNlOyBmb250 LXNpemU6IDEyLjhweDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBvcnBoYW5zOiAy OyB0ZXh0LWluZGVudDogLTdweDsgd2lkb3dzOiAyOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQw LCAyNDcsIDI1NSk7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBDb25zb2xhcywgJ0x1Y2lkYSBDb25zb2xlJywgbW9ub3NwYWNlOyBmb250LXNp emU6IDEyLjhweDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBvcnBoYW5zOiAyOyB0 ZXh0LWluZGVudDogLTdweDsgd2lkb3dzOiAyOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQwLCAy NDcsIDI1NSk7IiBjbGFzcz0iIj5JDQogY291bGQgbm90IHNlZSBpdCBiZWluZyBhc3NpZ25lZCBp biB0aGUgcGxheWJvb2tzLiBPciBkbyB3ZSBzZXQgaXQgZHVyaW5nIHRoZSBwbGF5Ym9vayBleGVj dXRpb24gYXMgYSBjb21tYW5kIGxpbmUgYXJnPzwvc3Bhbj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJvcnBoYW5zOiAyOyB0ZXh0LWluZGVudDogLTdweDsgd2lkb3dzOiAyOyIgY2xhc3M9 IiI+PGZvbnQgZmFjZT0iQ29uc29sYXMsIEx1Y2lkYSBDb25zb2xlLCBtb25vc3BhY2UiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEyLjgwMDAwMDE5MDczNDg2M3B4OyBiYWNrZ3Jv dW5kLWNvbG9yOiByZ2IoMjQwLCAyNDcsIDI1NSk7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczogMjsgdGV4dC1pbmRlbnQ6 IC03cHg7IHdpZG93czogMjsiIGNsYXNzPSIiPjxmb250IGZhY2U9IkNvbnNvbGFzLCBMdWNpZGEg Q29uc29sZSwgbW9ub3NwYWNlIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMi44 MDAwMDAxOTA3MzQ4NjNweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0MCwgMjQ3LCAyNTUpOyIg Y2xhc3M9IiI+UmVsZXZhbnQgc2VhcmNoJm5ic3A7PC9zcGFuPjwvZm9udD48YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vcmhldm0tcWUtYXV0b21hdGlvbi9vdmlydC1hbnNpYmxlL3NlYXJjaD91 dGY4PeKckyZhbXA7cT1hbnNpYmxlX2ZxZG4mYW1wO3R5cGU9IiBjbGFzcz0iIj5odHRwczovL2dp dGh1Yi5jb20vcmhldm0tcWUtYXV0b21hdGlvbi9vdmlydC1hbnNpYmxlL3NlYXJjaD91dGY4PSVF MiU5QyU5MyZhbXA7cT1hbnNpYmxlX2ZxZG4mYW1wO3R5cGU9PC9hPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IDI7IHRleHQtaW5kZW50OiAtN3B4OyB3aWRvd3M6 IDI7IiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb25zb2xhcywgTHVjaWRhIENvbnNvbGUsIG1vbm9z cGFjZSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAwMTkwNzM0ODYz cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDAsIDI0NywgMjU1KTsiIGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJvcnBoYW5zOiAyOyB0 ZXh0LWluZGVudDogLTdweDsgd2lkb3dzOiAyOyIgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ29uc29s YXMsIEx1Y2lkYSBDb25zb2xlLCBtb25vc3BhY2UiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDEyLjgwMDAwMDE5MDczNDg2M3B4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQwLCAy NDcsIDI1NSk7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IDI7IHRleHQtaW5kZW50OiAtN3B4 OyB3aWRvd3M6IDI7IiBjbGFzcz0iIj48Zm9udCBmYWNlPSJDb25zb2xhcywgTHVjaWRhIENvbnNv bGUsIG1vbm9zcGFjZSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTIuODAwMDAw MTkwNzM0ODYzcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDAsIDI0NywgMjU1KTsiIGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7Ij4NClJlZ2FyZHMsJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi Pg0KVGFzZGlrIFJhaG1hbjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0 OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxhIGhyZWY9Imh0dHA6 Ly90YXNkaWtyYWhtYW4ubWUvIiBjbGFzcz0iIj5odHRwOi8vdGFzZGlrcmFobWFuLm1lLzwvYT48 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_EC0D0D5060F9400E89D122BCA527DCEEoutlookcom_--

2 2