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

Re: [ovirt-devel] ovirt_master_hc-system-tests failed
by Gil Shinar 24 May '17

24 May '17

Hi Sahina, Thanks a lot for looking into it. Adding ovirt devel. On Tue, May 23, 2017 at 9:51 AM, Sahina Bose <sabose(a)redhat.com> wrote: > From the logs, it looks like an issue installing the HE > > [ INFO ] Stopping websocket-proxy service", " |- [ INFO ] > Stage: Misc configuration", " |- [ INFO ] Stage: Package > installation", " |- [ INFO ] Stage: Misc configuration", > " |- [ ERROR ] Failed to execute stage 'Misc configuration': > Failed to enable service 'openvswitch'", " |- [ INFO ] Stage: > Clean up", " |- Log file is located at > /var/log/ovirt-engine/setup/ovirt-engine-setup-20170522230910-t50bkj.log", > " |- [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/ > answers/20170522230919-setup.conf'", " |- [ INFO ] Stage: > Pre-termination", " |- [ INFO ] Stage: Termination", " > |- [ ERROR ] Execution of setup failed", " |- > HE_APPLIANCE_ENGINE_SETUP_FAIL", "[ ERROR ] Engine setup failed on the > appliance", "[ ERROR ] Failed to execute stage 'Closing up': Engine setup > failed on the appliance", " > > And from the /var/log/ovirt-engine/setup/ovirt-engine-setup- > 20170522230910-t50bkj.log: > 2017-05-22 23:09:19,645-0400 DEBUG otopi.plugins.otopi.services.systemd > plugin.execute:926 execute-output: ('/bin/systemctl', 'enable', > u'openvswitch.service') stderr: > Failed to execute operation: No such file or directory > > 2017-05-22 23:09:19,645-0400 DEBUG otopi.context > context._executeMethod:142 method exception > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in > _executeMethod > method['method']() > File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- > engine-setup/ovirt-engine/network/ovirtproviderovn.py", line 531, in > _restart_ovn_services > self._restart_service(service) > File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- > engine-setup/ovirt-engine/network/ovirtproviderovn.py", line 513, in > _restart_service > state=True, > File "/usr/share/otopi/plugins/otopi/services/systemd.py", line 122, in > startup > service=name, > RuntimeError: Failed to enable service 'openvswitch' > > > > On Sun, May 21, 2017 at 1:32 PM, Gil Shinar <gshinar(a)redhat.com> wrote: > >> Hi Sahina, >> >> Can you please assist? >> http://jenkins.ovirt.org/job/ovirt_master_hc-system-tests/105/ >> >> Thanks >> Gil >> > >

2 2

Heads up - Findbugs checks back on ovirt-engine master branch
by Tal Nisan 23 May '17

23 May '17

Hey everyone, Due to a bug in the check-patch Jenkins jobs the findbugs checks were effectively disabled for the last weeks in the master branch (the stable branches are using a separate job for findbugs so there it still worked). With the help of Daniel Belensky from the RHV DevOps team we've identified and solved the problem in the Jenkins job. We've also fixed the warnings that got in the code base during the period the job was not running and now the findbugs job is running correctly on master branch as a part of the check-patch with no warnings. Please be sure to note CI failures that may arise due to new warnings in pushed patches.

2 2

Re: [ovirt-devel] Change in ovirt-engine[master]: core: backup flag added to storage domain static
by shubham dubey 23 May '17

23 May '17

yes I just forget to add that. Can anyone tell me how to push the new changes to same commit? Thanks, Shubham On Tue, May 23, 2017 at 1:27 PM, Code Review <gerrit(a)ovirt.org> wrote: > From Eli Mesika <emesika(a)redhat.com>: > > Eli Mesika has posted comments on this change. > > Change subject: core: backup flag added to storage domain static > ...................................................................... > > > Patch Set 1: > > Did you forgot to add the relevant upgrade script that added that field > ???? > > -- > To view, visit https://gerrit.ovirt.org/77142 > To unsubscribe, visit https://gerrit.ovirt.org/settings > > Gerrit-MessageType: comment > Gerrit-Change-Id: I1453b52f4330d0e5cb12d8fa08426fd68f3cd329 > Gerrit-PatchSet: 1 > Gerrit-Project: ovirt-engine > Gerrit-Branch: master > Gerrit-Owner: shubham dubey <sdubey504(a)gmail.com> > Gerrit-Reviewer: Eli Mesika <emesika(a)redhat.com> > Gerrit-Reviewer: Greg Sheremeta <gshereme(a)redhat.com> > Gerrit-Reviewer: Jenkins CI > Gerrit-Reviewer: Maor Lipchuk <mlipchuk(a)redhat.com> > Gerrit-Reviewer: Martin Peřina <mperina(a)redhat.com> > Gerrit-Reviewer: gerrit-hooks <automation(a)ovirt.org> > Gerrit-HasComments: No >

4 10

[VDSM] check-merge fails: error: [Errno 98] Address already in use
by Nir Soffer 23 May '17

23 May '17

I see these failure in check-merge *13:26:59* Error occured, aborting*13:26:59* Traceback (most recent call last):*13:26:59* File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 360, in do_run*13:26:59* self.cli_plugins[args.ovirtverb].do_run(args)*13:26:59* File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 184, in do_run*13:26:59* self._do_run(**vars(args))*13:26:59* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in wrapper*13:26:59* return func(*args, **kwargs)*13:26:59* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in wrapper*13:26:59* return func(*args, prefix=prefix, **kwargs)*13:26:59* File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, in do_deploy*13:26:59* prefix.deploy()*13:26:59* File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 635, in wrapper*13:26:59* return func(*args, **kwargs)*13:26:59* File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line 110, in wrapper*13:26:59* with utils.repo_server_context(args[0]):*13:26:59* File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__*13:26:59* return self.gen.next()*13:26:59* File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 100, in repo_server_context*13:26:59* root_dir=prefix.paths.internal_repo(),*13:26:59* File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, in _create_http_server*13:26:59* generate_request_handler(root_dir),*13:26:59* File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__*13:26:59* self.server_bind()*13:26:59* File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind*13:26:59* SocketServer.TCPServer.server_bind(self)*13:26:59* File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind*13:26:59* self.socket.bind(self.server_address)*13:26:59* File "/usr/lib64/python2.7/socket.py", line 224, in meth*13:26:59* return getattr(self._sock,name)(*args)*13:26:59* error: [Errno 98] Address already in use Failed build: http://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x86_64/1794/conso… Other builds with same error: http://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x86_64/1793/conso… http://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x86_64/1790/conso… Nir

3 2

[vdsm] branching out 4.1.2
by Francesco Romani 23 May '17

23 May '17

Hi all, patches against the 4.1 branch are piling up, so I'm thinking about branching out 4.1.2 tomorrow (20170523) The activity on the 4.1.2 front was quite low lately, so we should expect quite few double backports. Thoughts? I'll go forward and branch if noone objects. Bests, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

6 7

VmIconDaoTest compiling error
by shubham dubey 23 May '17

23 May '17

I have done some changes in ovirt-engine now while compiling I am getting following error in file VmIconDaoTest. Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.466 sec <<< FAILURE! testGetVmIconByDataUrlWithValidUrl(org.ovirt.engine.core.dao.VmIconDaoTest) Time elapsed: 18 sec <<< FAILURE! java.lang.AssertionError: expected:<1> but was:<0> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.ovirt.engine.core.dao.VmIconDaoTest.testGetVmIconByDataUrlWithValidUrl(VmIconDaoTest.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:75) at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86) at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:254) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:89) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:193) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) ... ... Failed tests: testGetVmIconByDataUrlWithValidUrl(org.ovirt.engine.core.dao.VmIconDaoTest): expected:<1> but was:<0> I haven't even done any change in VmIconDaoTest file but this error is there. I even try to change the value result.get(0) to result.get(1) in testGetVmIconByDataUrlWithValidUrl but that didn't work. Thanks in advance. Shubham

3 6

Regarding dao tests
by shubham dubey 22 May '17

22 May '17

I have made some changes to engine code and the try to run dao test. $PGPASSWORD=engine \ ./packaging/dbscripts/schema.sh \ -c apply -u engine -d engine_dao_tests This command run sucessfully. but after compiling through make I am getting following error ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check (checkstyle) on project common: You have 7 Checkstyle violations. -> [Help 1] so can anyone tell me what that means? Thanks, Shubham

3 4

[ OST Manual Job ] Updated default fallback repo
by Daniel Belenky 22 May '17

22 May '17

Hi all, Please note that we've updated the default fallback repo in manual job <http://jenkins.ovirt.org/job/ovirt-system-tests_manual/>. The fallback repo defines the source from which the RPMs that are not part of the patch being tested are being taken. Until today, the default source was 'latest_tested' repo, which is now replaced by 'latest_release'. *Note* that 'latest_tested' repository shouldn't be used on regular basis, as this repository is changing as the experimental flow runs, so in order to avoid failures - please use the stable 'latest_release' repo, which contains all the rpm's that were released in the last official release of oVirt. Thanks, -- DANIEL BELENKY Associate sw engineer RHEV DEVOPS Red Hat Israel <https://www.redhat.com/> dbelenky(a)redhat.com IRC: #rhev-integ, #rhev-dev <https://red.ht/sig>

2 2

[Engine] Runtime log controll script
by Roy Golan 21 May '17

21 May '17

Ever wanted to raise level of the engine logs and wanted to to that fast and runtime? This is a small wrapper around wildfly mgmt interface, called *log-control* to do the trick[1] Example, debug the db interaction layer: ./log-control org.ovirt.engine.core.dal debug It will first try blantly to add the log category and then will set the log level according to what you set. It is simple and stupid. More interesting logger categories: business logic (commands, queries) - org.ovirt.engine.core.bll hosts interaction - org.ovirt.engine.core.vdsbroker various utilities - org.ovirt.engine.core.utils aaa - org.ovirt.engine.exttool.aaa General suggestion - I think is is it time for *ovirt-engine-contrib* so mini-helpers like that can exists and when they are solid can go into mainstream repo, if needed in there. [1] https://gist.github.com/rgolangh/1cb9f9b3b7f7f0a1d16b5a976d90bd55 Thanks, Roy

5 7

ovirt-provider-ovn - appliance inclusion / default enablement
by Sandro Bonazzola 18 May '17

18 May '17

Hi, with https://gerrit.ovirt.org/76855 it's requested to increase the appliance size by adding ovirt-provider-ovn and its dependencies. This raise a few questions. The support for ovirt-provider-ovn is enabled by default in engine-setup and going to be installed by default in the appliance so we're pushing to use it. Why not requiring it at ovirt-engine spec file level? Answer given in the commit message of above patch is: We do not want to have a hard dependency in the form of an rpm require. OVN and openvswitch are relatively heavy and complex, and are still experimental. We would not want to force everybody to pull them onto any Engine host. So why adding it to the appliance, which is the default for hosted engine which is our recommeded way to deploy oVirt, and enable it by default? How this differs from DWH? ovirt-engine requires ovirt-engine-setup which requires ovirt-engine-dwh setup which requires ovirt-engine-dwh. Why can't we just require ovirt-provider-ovn in ovirt-engine instead of tweaking the appliance? If we decide it's not mandatory, why not make the default to not enabling it in engine-setup and avoid to add it to the appliance? Being optional, adding it collides with Bug 1401931 <https://bugzilla.redhat.com/show_bug.cgi?id=1401931> - [RFE] reduce the size of the appliance 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>

5 10

[ OST Failure Report ] [ oVirt master ] [ 14/05/2017 ] [ test-repo_ovirt_experimental_master ]
by Shlomo Ben David 18 May '17

18 May '17

Hi, Test failed: [ test-repo_ovirt_experimental_master ] Link to suspected patches: N/A Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6665/ Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6665/artif… Error snippet from the log: <error> 2017-05-14 03:56:31,782-0400 ERROR (jsonrpc/3) [storage.TaskManager.Task] (Task='661acb48-075b-494a-8fb4-64c04ed99bcb') Unexpected error (task:871) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 878, in _run return fn(*args, **kargs) File "/usr/lib/python2.7/site-packages/vdsm/logUtils.py", line 52, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 2172, in getAllTasksInfo allTasksInfo = self._pool.getAllTasksInfo() File "/usr/lib/python2.7/site-packages/vdsm/storage/securable.py", line 77, in wrapper raise SecureError("Secured object is not in safe state") SecureError: Secured object is not in safe state 2017-05-14 03:56:31,785-0400 INFO (jsonrpc/3) [storage.TaskManager.Task] (Task='661acb48-075b-494a-8fb4-64c04ed99bcb') aborting: Task is aborted: u'Secured object is not in safe state' - code 100 (task:1176) 2017-05-14 03:56:31,786-0400 ERROR (jsonrpc/3) [storage.Dispatcher] Secured object is not in safe state (dispatcher:81) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/dispatcher.py", line 73, in wrapper result = ctask.prepare(func, *args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 106, in wrapper return m(self, *a, **kw) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 1184, in prepare raise self.error SecureError: Secured object is not in safe state 2017-05-14 03:56:31,786-0400 INFO (jsonrpc/3) [jsonrpc.JsonRpcServer] RPC call Host.getAllTasksInfo failed (error 654) in 0.00 seconds (__init__:577) 2017-05-14 03:56:31,796-0400 INFO (jsonrpc/5) [dispatcher] Run and protect: getAllTasksStatuses(spUUID=None, options=None) (logUtils:51) 2017-05-14 03:56:31,797-0400 ERROR (jsonrpc/5) [storage.TaskManager.Task] (Task='568f515e-365b-47e4-8b2f-24e15deb6ae9') Unexpected error (task:871) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 878, in _run return fn(*args, **kargs) File "/usr/lib/python2.7/site-packages/vdsm/logUtils.py", line 52, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 2132, in getAllTasksStatuses allTasksStatus = self._pool.getAllTasksStatuses() File "/usr/lib/python2.7/site-packages/vdsm/storage/securable.py", line 77, in wrapper raise SecureError("Secured object is not in safe state") SecureError: Secured object is not in safe state 2017-05-14 03:56:31,797-0400 INFO (jsonrpc/5) [storage.TaskManager.Task] (Task='568f515e-365b-47e4-8b2f-24e15deb6ae9') aborting: Task is aborted: u'Secured object is not in safe state' - code 100 (task:1176) 2017-05-14 03:56:31,798-0400 ERROR (jsonrpc/5) [storage.Dispatcher] Secured object is not in safe state (dispatcher:81) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/dispatcher.py", line 73, in wrapper result = ctask.prepare(func, *args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 106, in wrapper return m(self, *a, **kw) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 1184, in prepare raise self.error SecureError: Secured object is not in safe state <error> Best Regards, Shlomi Ben-David | Software Engineer | Red Hat ISRAEL RHCSA | RHCVA | RHCE IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) OPEN SOURCE - 1 4 011 && 011 4 1

5 5

Fwd: UPDATE: Bugzilla 5 beta server is back online
by Sandro Bonazzola 18 May '17

18 May '17

---------- Forwarded message ---------- From: Christine Freitas <cfreitas(a)redhat.com> Date: Mon, May 15, 2017 at 6:03 PM Subject: UPDATE: Bugzilla 5 beta server is back online Hello All, The Bugzilla 5 beta server [1] is back online. We encourage you to test your current scripts and take part in the beta discussions on the Fedora development list [2]. Partners and customers may also use their existing communications channels to share feedback or questions. We've extended the beta window and ask that you provide feedback or questions by Wednesday, June 14th. The official release date for Bugzilla 5 will be determined based on the beta feedback. We will communicate to you as the beta continues to progress. For more information refer to: https://beta-bugzilla.redhat.com/page.cgi?id=whats-new.html https://beta-bugzilla.redhat.com/page.cgi?id=release-notes.html https://beta-bugzilla.redhat.com/page.cgi?id=faq.html https://beta-bugzilla.redhat.com/docs/en/html/using/index.html https://beta-bugzilla.redhat.com/docs/en/html/api/index.html Cheers, the Red Hat Bugzilla team. 1: https://beta-bugzilla.redhat.com/ 2: https://lists.fedoraproject.org/archives/list/devel%40lists. fedoraproject.org/ -- 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

Feature: enhanced OVA support
by Arik Hadas 17 May '17

17 May '17

Hi everyone, We would like to share our plan for extending the currently provided support for OVA files with: 1. Support for uploading OVA. 2. Support for exporting a VM/template as OVA. 3. Support for importing OVA that was generated by oVirt (today, we only support those that are VMware-compatible). 4. Support for downloading OVA. This can be found on the feature page <http://www.ovirt.org/develop/release-management/features/virt/enhance-impor…> . Your feedback and cooperation will be highly appreciated. Thanks, Arik

5 7

[VDSM] Adding Pylint to 'check' target
by Fred Rolland 15 May '17

15 May '17

Hi, We are introducing Pylint to be performed as part of the 'check' target. Once that patch [1] will be merged, every execution of 'make check' will include also a Pylint analysis. Note that execution time will be longer by about 2 minutes. However, you are can use 'jobs' flag to tell 'make' to execute recipes simultaneously. Be aware that the output of the jobs will be interleaved. For example, running 'make' with two parallel jobs: make --jobs=2 check Regards, Freddy [1] https://gerrit.ovirt.org/#/c/76390/

4 3

Vdsm merge rights
by Dan Kenigsberg 14 May '17

14 May '17

I'd like to nominate Francesco to the vdsm-maintainers https://gerrit.ovirt.org/#/admin/groups/uuid-becbf722723417c336de6c16467496… list, so he can merge patches without waiting for Nir, Adam or me. I believe that he proved to be thorough and considerate (and paranoid) as the job requires. Vdsm maintainers, please approve. Dan

7 7

[VDSM] network test failure - failing all builds
by Nir Soffer 13 May '17

13 May '17

I'm seeing now this failure on multiple untreated patches. Seems to be related to these patches merged today: https://gerrit.ovirt.org/#/q/topic:ip_refactoring+is:merged *21:04:36* ======================================================================*21:04:36* FAIL: test_add_delete_and_read_rule (network.ip_rule_test.TestIpRule)*21:04:36* ----------------------------------------------------------------------*21:04:36* Traceback (most recent call last):*21:04:36* File "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/network/ip_rule_test.py", line 47, in test_add_delete_and_read_rule*21:04:36* self.assertEqual(1, len(rules))*21:04:36* AssertionError: 1 != 2*21:04:36* -------------------- >> begin captured logging << --------------------*21:04:36* 2017-05-12 21:04:18,381 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip rule add from all to 192.168.99.1 dev lo table main (cwd None) (commands:69)*21:04:36* 2017-05-12 21:04:18,393 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93)*21:04:36* 2017-05-12 21:04:18,393 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip rule (cwd None) (commands:69)*21:04:36* 2017-05-12 21:04:18,404 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93)*21:04:36* 2017-05-12 21:04:18,406 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip rule del from all to 192.168.99.1 dev lo table main (cwd None) (commands:69)*21:04:36* 2017-05-12 21:04:18,417 DEBUG (MainThread) [root] SUCCESS: <err> = ''; <rc> = 0 (commands:93)*21:04:36* --------------------- >> end captured logging << ---------------------

2 4

Fwd: UPDATE: Bugzilla 5 beta window extended
by Sandro Bonazzola 12 May '17

12 May '17

FYI ---------- Forwarded message ---------- From: Christine Freitas <cfreitas(a)redhat.com> Date: Thu, May 11, 2017 at 6:05 PM Subject: UPDATE: Bugzilla 5 beta window extended Hello All, Due to issues found during testing, the Bugzilla 5 beta server [1] was put into maintenance mode. Therefore, we are extending the beta window by 4 weeks, once the server comes back online. We are targeting early next week to have the beta available to you. Once the server comes back online, we will update you on the date by which feedback is due. We sincerely apologize for any inconvenience, and look forward to your feedback once we are back online. Cheers, the Red Hat Bugzilla team For more information on the Bugzilla 5 beta refer to: https://beta-bugzilla.redhat.com/page.cgi?id=whats-new.html https://beta-bugzilla.redhat.com/page.cgi?id=release-notes.html https://beta-bugzilla.redhat.com/page.cgi?id=faq.html https://beta-bugzilla.redhat.com/docs/en/html/using/index.html https://beta-bugzilla.redhat.com/docs/en/html/api/index.html Cheers, the Red Hat Bugzilla team. 1: https://beta-bugzilla.redhat.com/ -- 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

OST 4.1 failure: Error: ('Error while sending HTTP request', error('cannot add/remove handle - multi_perform() already running', ))
by Nir Soffer 12 May '17

12 May '17

I got this failure in 4.1 build[1], which should not be relevant to the tested patch[2] - is this a known issue? *13:31:47* # add_hosts: *13:31:47* Error while running thread*13:31:47* Traceback (most recent call last):*13:31:47* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in _ret_via_queue*13:31:47* queue.put({'return': func()})*13:31:47* File "/home/jenkins/workspace/ovirt-system-tests_manual/ovirt-system-tests/basic-suite-4.1/test-scenarios/002_bootstrap.py", line 320, in _add_host_4*13:31:47* name=CLUSTER_NAME,*13:31:47* File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 8726, in add*13:31:47* return self._internal_add(host, headers, query, wait)*13:31:47* File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 211, in _internal_add*13:31:47* context = self._connection.send(request)*13:31:47* File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 300, in send*13:31:47* sys.exc_info()[2]*13:31:47* File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 295, in send*13:31:47* return self.__send(request)*13:31:47* File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 413, in __send*13:31:47* self._multi.add_handle(curl)*13:31:47* Error: ('Error while sending HTTP request', error('cannot add/remove handle - multi_perform() already running',)) [1] http://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests… [2] https://gerrit.ovirt.org/76645 Nir

6 26

DBUnit upgrade and format change
by Allon Mureinik 12 May '17

12 May '17

Hi all, In an attempt to make maintaining Engine's DAO tests a bit more manageable, yesterday I've merged patches to upgrade the DBUnit version we're using to the latest available version, 2.5.3 [1], and changed the format to flat-XML [2], ending up with a fixures.xml file which is almost 10K lines shorter. What do you need to know about this change? Frankly, not much. The format itself is pretty self-descriptive. To add a row to a table in the test database, just add a row to fixtures.xml: <table_name some_column="some_value" some_other_column="123"/> Note that you can pretty much add such a row wherever you want in the file, but in the interest of maintainability, please group rows from the same tables together, and leave an empty line between tables (as the file currently is). Note also that DBUnit 2.5.3 doesn't seem to allow timezones, offsets or whitespaces at the end of timestamp values. Since our tests don't really depend on them, I just removed the handful of instances we had. If anyone wants to take a deeper look, I'd gladly review it :-) If this change causes trouble to anyone (it shouldn't - it was tested both on my machine and in the CI, several times), please let me know. You friendly neighborhood cleanup guy, Allon [1] https://gerrit.ovirt.org/#/c/76678/ [2] https://gerrit.ovirt.org/#/c/76679/

1 0

[ OST Failure Report ] [ oVirt master][12-05-2017][ 002_bootstrap.add_hosts ]
by Sandro Bonazzola 12 May '17

12 May '17

http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/1440/testRepo… ('Error while sending HTTP request', error('cannot add/remove handle - multi_perform() already running',)) -------------------- >> 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/test-repo_ovirt_experimental_4.1/ovirt-system-tests/basic-suite-4.1/test-scenarios/002_bootstrap.py", line 320, in _add_host_4 name=CLUSTER_NAME, File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 8726, in add return self._internal_add(host, headers, query, wait) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 211, in _internal_add context = self._connection.send(request) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 300, in send sys.exc_info()[2] File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 295, in send return self.__send(request) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 413, in __send self._multi.add_handle(curl) Error: ('Error while sending HTTP request', error('cannot add/remove handle - multi_perform() already running',)) --------------------- >> end captured logging << --------------------- Looks like it started failing on latest ovirt-host-deploy build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_4.1/1431/ Sadly I can't find ovirt-host-deploy logs within the archived artifacts. Simone, Didi, can you please have a look? Ondra, can you also check? I'm not sure about the meaning of the error reported by the SDK. -- 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 2

[VDSM] travis builds fails since "network: report dpdk devices as nics"
by Nir Soffer 11 May '17

11 May '17

Travis builds are failing because the lshw package was not added to the vdsm test docker images. The offending patch is: network: report dpdk devices as nics added link_info dictionary for dpdk dev information. Currently it contains hard coded and empty values. getLinks now reports dpdk devices as nics and providing their link_info as well. Signed-off-by: Irit Goihman <igoihman(a)redhat.com> Change-Id: I67b2083e9c6f032472fd75f6800c864083ffdef5 When adding new build dependencies, please add the required packages to docker/Dockerfile.* Thanks, Nir

2 4

ovirt-engine and vdsm repositories hooks
by Shlomo Ben David 11 May '17

11 May '17

Hi All, I updated the *ovirt-engine* and *vdsm* project hooks to the new (all) hooks. The new hooks are separated into 3 groups: - check hooks - check bug-url - check target milestone - check product - check backport - update hooks - set_post - set_modified - update_tracker - all (include both check and update hooks) I will update the other projects during next week. If you have any questions/suggestions/issues, please send an email to infra(a)ovirt.org. Best Regards, Shlomi Ben-David | Software Engineer | Red Hat ISRAEL RHCSA | RHCVA | RHCE IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci) OPEN SOURCE - 1 4 011 && 011 4 1

1 0

[OST/SDK4] ValueError: urandom is not a valid RngSource
by Milan Zamazal 10 May '17

10 May '17

Hi, I'm trying to run ovirt-system-tests from git master with basic-suite-master on my RHEL machine. The tests had been failing on missing ovirtsdk4 Python module, so I installed python-ovirt-engine-sdk4-4.0.4-2.el7ev.x86_64 package. Now the tests fail early and I'm getting the following error: 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/pdm/ovirt/lago/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py", line 215, in add_cluster add_cluster_4(prefix) File "/home/pdm/ovirt/lago/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py", line 256, in add_cluster_4 ballooning_enabled=True, File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 3758, in add return readers.ClusterReader.read_one(reader) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/readers.py", line 1740, in read_one obj.required_rng_sources = [types.RngSource(s.lower()) for s in Reader.read_strings(reader)] File "/usr/lib/python2.7/site-packages/enum/__init__.py", line 330, in __call__ return cls.__new__(cls, value) File "/usr/lib/python2.7/site-packages/enum/__init__.py", line 642, in __new__ raise ValueError("%s is not a valid %s" % (value, cls.__name__)) ValueError: urandom is not a valid RngSource Does anybody know what's wrong and how to make the tests working? Thank you, Milan

2 2

[missing_subjectAltName] in engine ca certificate?
by Nir Soffer 10 May '17

10 May '17

I imported the certificate from my engine into chrome[1], but Chrome refuses to use it because: This server could not prove that it is ...; its security certificate is from [missing_subjectAltName]. Same certificate used to work 2 weeks ago, looks like new Chrome version changed the rules. Without importing engine CA, there is no way to upload images via engine. Tested on engine 4.1.1 and 4.1.2 on Centos 7.3. Is this known issue? [1] from http:// <engine_url>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA Nir

6 8

Failing to make vdsm (master) - sanlock-python is not a build dep?
by Yaniv Kaul 10 May '17

10 May '17

I'm trying to follow http://www.ovirt.org/develop/developer-guide/vdsm/developers/ to build vdsm, and I'm failing (master, on F25). There is one issue in the middle: [ykaul@ykaul vdsm]$ sudo dnf install `cat automation/check-patch.packages.fc*` ... Package rpm-build-4.13.0.1-1.fc25.x86_64 is already installed, skipping. Package rpmlint-1.9-9.fc25.noarch is already installed, skipping. Package sudo-1.8.19p2-1.fc25.x86_64 is already installed, skipping. Package yum-3.4.3-510.fc25.noarch is already installed, skipping. Package yum-utils-1.1.31-511.fc25.noarch is already installed, skipping. Error: Unable to find a match. And then, ./autogen.sh --system succeeds, but 'make' fails: Making all in api make[3]: Entering directory '/home/ykaul/vdsm/lib/vdsm/api' Generate vdsm-api.html chmod u+w . PYTHONPATH=./../../:./../../vdsm \ /usr/bin/python schema_to_html.py vdsm-api.yml vdsm-api.html Traceback (most recent call last): File "schema_to_html.py", line 29, in <module> from vdsm.api import vdsmapi File "/home/ykaul/vdsm/lib/vdsm/api/vdsmapi.py", line 28, in <module> from vdsm import utils File "/home/ykaul/vdsm/lib/vdsm/utils.py", line 33, in <module> from .compat import pickle File "/home/ykaul/vdsm/lib/vdsm/compat.py", line 96, in <module> import sanlock ImportError: No module named sanlock which seems to be solved with manually installing sanlock-python.

3 4

[ OST Failure Report ] [ oVirt master][09-05-2017][ 002_bootstrap.add_hosts ]
by Anton Marchukov 09 May '17

09 May '17

Hello. Today around 11 am the add host for master started to consistently fail. We found the following in /var/log/messages (as I understand it might get there through journald as the host deploy log claims that vdsmd unit startup failed): May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: Traceback (most recent call last): May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File "/usr/bin/vdsm-tool", line 219, in main May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: return tool_command[cmd]["command"](*args) May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/tool/network.py", line 48, in upgrade_networks May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: netupgrade.upgrade() May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/netupgrade.py", line 55, in upgrade May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: _create_unified_configuration(rconfig, NetInfo(netinfo(vdsmnets))) May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/netupgrade.py", line 133, in _create_unified_configuration May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: RunningConfig.store() May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/netconfpersistence.py", line 204, in store May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: _store_net_config() May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/network/netconfpersistence.py", line 281, in _store_net_config May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: utils.rmTree(real_old_safeconf_dir) May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 125, in rmTree May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: shutil.rmtree(directoryToRemove) May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File "/usr/lib64/python2.7/shutil.py", line 232, in rmtree May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: onerror(os.path.islink, path, sys.exc_info()) May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File "/usr/lib64/python2.7/shutil.py", line 230, in rmtree May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: raise OSError("Cannot call rmtree on a symbolic link") May 9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: OSError: Cannot call rmtree on a symbolic link May 9 07:01:25 lago-basic-suite-master-host1 systemd: vdsm-network.service: control process exited, code=exited status=1 The full logs of the run you can find in Jenkins artifacts: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6589/artif… Any vdsm patches merged that might cause this? -- Anton Marchukov Senior Software Engineer - RHEV CI - Red Hat

5 5

[ OST Failure Report ] [ oVirt master ] [ 07-05-2017 ] [ add_secondary_storage_domains ]
by Daniel Belenky 07 May '17

07 May '17

Hi, The following test failed: 002_bootstrap.add_secondary_storage_domains <http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6573/testR…> *Error snippet from VDSM Log:* 2017-05-07 08:09:03,906-0400 ERROR (monitor/e48ddb8) [storage.Monitor] Setting up monitor for e48ddb84-77fc-41d8-98ce-a40140649c8d failed (monitor:329) Traceback (most recent call last): File "/usr/share/vdsm/storage/monitor.py", line 326, in _setupLoop self._setupMonitor() File "/usr/share/vdsm/storage/monitor.py", line 348, in _setupMonitor self._produceDomain() File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 392, in wrapper value = meth(self, *a, **kw) File "/usr/share/vdsm/storage/monitor.py", line 366, in _produceDomain self.domain = sdCache.produce(self.sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 112, in produce domain.getRealDomain() File "/usr/share/vdsm/storage/sdc.py", line 53, in getRealDomain return self._cache._realProduce(self._sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 136, in _realProduce domain = self._findDomain(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 153, in _findDomain return findMethod(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 178, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: (u'e48ddb84-77fc-41d8-98ce-a40140649c8d',) *Error snippet from SUPERVDSM Log:* MainProcess|jsonrpc/6::ERROR::2017-05-07 08:09:09,960::supervdsm_server::96::SuperVdsm.ServerCallback::(wrapper) Error in mount Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_server.py", line 94, in wrapper res = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_server.py", line 136, in mount timeout=timeout, cgroup=cgroup) File "/usr/lib/python2.7/site-packages/vdsm/storage/mount.py", line 262, in _mount _runcmd(cmd, timeout) File "/usr/lib/python2.7/site-packages/vdsm/storage/mount.py", line 297, in _runcmd raise MountError(rc, ";".join((out, err))) MountError: (32, ';mount.nfs: Connection timed out\n') MainProcess|jsonrpc/1::ERROR::2017-05-07 08:09:09,960::supervdsm_server::96::SuperVdsm.ServerCallback::(wrapper) Error in mount Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_server.py", line 94, in wrapper res = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/supervdsm_server.py", line 136, in mount timeout=timeout, cgroup=cgroup) File "/usr/lib/python2.7/site-packages/vdsm/storage/mount.py", line 262, in _mount _runcmd(cmd, timeout) File "/usr/lib/python2.7/site-packages/vdsm/storage/mount.py", line 297, in _runcmd raise MountError(rc, ";".join((out, err))) MountError: (32, ';mount.nfs: Connection timed out\n') *Links*: Job's artifacts <http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6573/artif…>, All related logs <http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6573/artif…>, Engine Log <http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6573/artif…>, Host 1 SuperVdsm Log <http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6573/artif…>, Host 1 Vdsm Log <http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6573/artif…> Please assist to investigate the failure. Thanks, -- DANIEL BELENKY RHV DEVOPS Red Hat EMEA <https://www.redhat.com/> IRC: #rhev-integ #rhev-dev <https://red.ht/sig>

2 1

Announcing Douglas Landgraf as ovirt-log-collector maintainer
by Sandro Bonazzola 04 May '17

04 May '17

Hi, Douglas Landgraf took a major role in the ovirt-log-collector project and he's currently default assignee for bugs related to it. Douglas already has maintainer permissions on log-collector. I'd like to thank Douglas for his contribution and I hope he'll keep up the good work! 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>

1 0

planned Jenkins restart
by Evgheni Dereveanchin 04 May '17

04 May '17

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new builds will be scheduled during this maintenance period. I will inform you once it is over. Regards, Evgheni Dereveanchin

1 1

Re: [ovirt-devel] qemu packaging - add the "qemu" user to a "gluster" group?
by Karen Noel 03 May '17

03 May '17

----_com.ninefolders.hd3.email_963684395295557_alt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CitDb2xlIGZvciBGZWRvcmEvdmlydAorSmVmZiBmb3IgZm9yIHFlbXUgdXBzdHJlYW0KCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpGcm9tOiBTYW5kcm8gQm9uYXp6b2xhClNlbnQ6 IEFwciAyOCwgMjAxNyA1OjA4IEFNClRvOiBOaWVscyBkZSBWb3M7IE1pcm9zbGF2IFJlemFuaW5h OyBLYXJlbiBOb2VsOyBEb3JvbiBGZWRpdWNrCkNjOiBkZXZlbApTdWJqZWN0OiBSZTogcWVtdSBw YWNrYWdpbmcgLSBhZGQgdGhlICJxZW11IiB1c2VyIHRvIGEgImdsdXN0ZXIiIGdyb3VwPwoKPgo+ Cj4gT24gV2VkLCBBcHIgMjYsIDIwMTcgYXQgMzozNiBQTSwgTmllbHMgZGUgVm9zIDxuZGV2b3NA cmVkaGF0LmNvbT4gd3JvdGU6Cj4+Cj4+IEhpLAo+Pgo+PiBXZSdyZSB0cnlpbmcgdG8gaW1wcm92 ZSB0aGUgZGVidWdhYmlsaXR5IG9mIEdsdXN0ZXIgYmFja2VkIFZNcyBhbmQgb25lCj4+IG9mIHRo ZSBmZWF0dXJlcyBmb3IgdGhpcyBpcyB0byBiZSBhYmxlIHRvIGdhdGhlciAic3RhdGVkdW1wcyIu IFRoZXNlCj4+IHN0YXRlZHVtcHMgaW5jbHVkZSBtZW1vcnkgYWxsb2NhdGlvbiBkZXRhaWxzIGFu ZCBvdGhlciBpbmZvcm1hdGlvbiBhYm91dAo+PiB0aGUgR2x1c3RlciBjbGllbnQuIFFFTVUgaXMg b25lIG9mIHRoZSBhcHBsaWNhdGlvbnMgdGhhdCBjYW4gYmUKPj4gY29uZmlndXJlZCB0byB1c2Ug bGliZ2ZhcGkuc28gR2x1c3RlciBjbGllbnQuCj4+Cj4+IEdsdXN0ZXIgcHJvdmlkZXMgdGhlIC92 YXIvcnVuL2dsdXN0ZXIvIGRpcmVjdG9yeSBhbmQgdGhlIGxpYmdmYXBpLnNvCj4+IGxpYnJhcnkg dGhhdCBxZW11IChpbiBibG9jay9nbHVzdGVyLmMpIHVzZXMgdGhhdC4gV291bGQgdGhlcmUgYmUg YQo+PiBwcm9ibGVtIGZvciB0aGUgInFlbXUiIHBhY2thZ2VzIHRvIHVzZSBhZGQgdGhlICJxZW11 IiB1c2VyIHRvIGEKPj4gImdsdXN0ZXIiIGdyb3VwPyBJJ20gbm90IHN1cmUgeWV0IGhvdyB0aGlz IGlzIGRvbmUgZm9yIG90aGVyIHBhY2thZ2VzCj4+IHdpdGggdGhlaXIgb3duIHVzZXJzLCBidXQg dGhlcmUgd291bGQgYmUgYSBkZXBlbmRlbnQgaW5zdGFsbGF0aW9uIG9yZGVyCj4+IG9mIHNvbWUg a2luZCAobmVlZHMgcnBtIHRyaWdnZXJzPykuCj4+Cj4+IFdoYXQgaXMgeW91ciBvcGluaW9uIG9u IHRoaXMgaXNzdWUsIG9yIHdvdWxkIHlvdSByZWNvbW1lbmQgYW4gb3RoZXIKPj4gYXBwcm9hY2g/ Cj4KPgo+IEFkZGluZyBNaXJvc2xhdiwgS2FyZW4gYW5kIERvcm9uLgo+IEknbSBub3Qgc3VyZSBh Ym91dCBob3cgbGliZ2ZhcGkgaXMgY29uc3VtZWQgYnkgcWVtdS1rdm0oLWV2Ly1yaGV2KSBidXQg aWYgaXRzIHN1cHBvcnQgaXMgZW5hYmxlIGJ5IGRlZmF1bHQgYW5kIGRvZXNuJ3QgcmVxdWlyZSBh ZGRpdGlvbmFsIHFlbXUta3ZtIHN1YiBwYWNrYWdlcyB0byBiZSBlbmFibGVkLCBJIHdvdWxkIHN1 Z2dlc3QgdG8ganVzdCBmb2xsb3fCoGh0dHBzOi8vZmVkb3JhcHJvamVjdC5vcmcvd2lraS9QYWNr YWdpbmc6VXNlcnNBbmRHcm91cHMKPiBhbmQgYWRkIHRoZSBxZW11IHVzZXIgdG8gdGhlIGdsdXN0 ZXIgZ3JvdXAgaW4gJXByZS4KPgo+IEZyb20gb1ZpcnQgcG9pbnQgb2YgdmlldywgSSB0aGluayBp dCBzaG91bGRuJ3QgYWZmZWN0IHVzIHZlcnkgbXVjaC4gT24gQ2VudE9TIFZpcnQgU0lHIHdlJ2xs IGNvbnN1bWUgd2hhdGV2ZXIgd2lsbCBjb21lIGZyb20gcWVtdS1rdm0tcmhldi4KPgo+IMKgCj4+ Cj4+Cj4+IFRoYW5rcywKPj4gTmllbHMKPj4KPj4gUFM6IGh0dHBzOi8vYnVnemlsbGEucmVkaGF0 LmNvbS8xNDQ1NTY5IGNhbiBiZSB1c2VkIHRvIHJlcGx5IGFzIHdlbGwKPj4KPj4KPj4gRnJvbSBo dHRwOi8vbGlzdHMuZ2x1c3Rlci5vcmcvcGlwZXJtYWlsL2dsdXN0ZXItZGV2ZWwvMjAxNy1BcHJp bC8wNTI2MjkuaHRtbDoKPj4gT24gVHVlLCBBcHIgMjUsIDIwMTcgYXQgMDc6NTM6MDZQTSArMDIw MCwgTmllbHMgZGUgVm9zIHdyb3RlOgo+PiA+IEhpLAo+PiA+Cj4+ID4gUmVjZW50bHkgYSBuZXcg YWJpbGl0eSB0byB0cmlnZ2VyIHN0YXRlZHVtcHMgdGhyb3VnaCB0aGUgR2x1c3Rlci1DTEkgWzBd Cj4+ID4gaGFzIGJlZW4gYWRkZWQuIFRoaXMgbWFrZXMgaXQgcG9zc2libGUgdG8gZ2V0IHN0YXRl ZHVtcCBmcm9tCj4+ID4gYXBwbGljYXRpb25zIHRoYXQgdXNlIGdmYXBpLiBCeSBkZWZhdWx0LCBz dGF0ZWR1bXBzIGFyZSBzYXZlZCB1bmRlcgo+PiA+IC92YXIvcnVuL2dsdXN0ZXIvLi4uIGFuZCB0 aGlzIGRpcmVjdG9yeSBpcyBvbmx5IHdyaXRhYmxlIGJ5IHJvb3QuCj4+ID4gQXBwbGljYXRpb25z IHRoYXQgdXNlIGdmYXBpIGRvIG5vdCByZXF1aXJlIHJvb3QgcGVybWlzc2lvbnMgKGxpa2UgUUVN VSksCj4+ID4gYW5kIHRoZXJlZm9yZSBmYWlsIHRvIHdyaXRlIHRoZSBzdGF0ZWR1bXAgOi0vCj4+ ID4KPj4gPiBPbmUgYXBwcm9hY2ggd291bGQgYmUgdG8gY3JlYXRlIGEgImdsdXN0ZXIiIGdyb3Vw IGFuZCBnaXZlIHRoZSBncm91cAo+PiA+IHBlcm1pc3Npb25zIHRvIHdyaXRlIHRvIC92YXIvcnVu L2dsdXN0ZXIvLi4uIE90aGVyICdmaXhlcycgaW5jbHVkZQo+PiA+IHNldHRpbmcgQUNMcyBvbiB0 aGUgZGlyZWN0b3J5IHNvIHRoYXQgc3BlY2lmaWVkIHVzZXJzIGNhbiB3cml0ZSB0aGVyZS4KPj4g PiBiZWNhdXNlIG1hbnkgZGFlbW9ucyBoYXZlIGEgImhvbWUgZGlyZWN0b3J5IiB0aGF0IGRvZXMg bm90IGV4aXN0LCBpdAo+PiA+IHByb2JhYmx5IGlzIG5vdCBhIGdvb2QgaWRlYSB0byB1c2UgJEhP TUUgdG8gc3RvcmUgc3RhdGVkdW1wcy4KPj4gPgo+PiA+IFdoYXQgc3VnZ2VzdGlvbnMgZG8gb3Ro ZXJzIGhhdmU/Cj4+ID4KPj4gPiBUaGFua3MsCj4+ID4gTmllbHMKPj4gPgo+PiA+Cj4+ID4gMC4g aHR0cHM6Ly9naXRodWIuY29tL2dsdXN0ZXIvZ2x1c3RlcmZzL2Jsb2IvbWFzdGVyL2RvYy9kZWJ1 Z2dpbmcvc3RhdGVkdW1wLm1kCj4+Cj4+Cj4KPgo+Cj4gLS0gCj4KPiBTQU5EUk/CoEJPTkFaWk9M QQo+Cj4gQVNTT0NJQVRFIE1BTkFHRVIsIFNPRlRXQVJFIEVOR0lORUVSSU5HLCBFTUVBIEVORyBW SVJUVUFMSVpBVElPTiBSJkQKPgo+IFJlZCBIYXTCoEVNRUEKPgo+IFRSSUVELiBURVNURUQuIFRS VVNURUQu ----_com.ninefolders.hd3.email_963684395295557_alt Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KPCEtLQpkaXYjZF8xNDkzMzc2NDc2MjU2IHAge2ZvbnQt ZmFtaWx5OkNhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTox Mi4wcHQ7IGNvbG9yOiMxRjQ5N0R9Ci0tPgo8L3N0eWxlPjxkaXYgaWQ9J2RfMTQ5MzM3NjQ3NjI1 Nicgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZToxMi4wcHQ7IGNvbG9yOiMxRjQ5N0QiPjxwIGRpcj0ibHRyIj48YnI+CitD b2xlIGZvciBGZWRvcmEvdmlydDxicj4KK0plZmYgZm9yIGZvciBxZW11IHVwc3RyZWFtPC9wPgo8 ZGl2IGlkPSJzaWduYXR1cmUteCIgc3R5bGU9Ii13ZWJraXQtdXNlci1zZWxlY3Q6bm9uZTsgZm9u dC1mYW1pbHk6Q2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OjEyLjBwdDsgY29sb3I6IzFGNDk3RCI+PGRpdj48YSBocmVmPSJodHRwOi8vd3d3Ljlmb2xkZXJz LmNvbS8iIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDA5QkRGIj48YnI+PC9h PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9InF1b3RlZF9zZXBhcmF0ZV9ib2R5Ii8+PGRp diBpZD0icXVvdGVkX2hlYWRlciIgc3R5bGU9ImNsZWFyOmJvdGg7Ij48aHIgc3R5bGU9ImhlaWdo dDoycHg7Ym9yZGVyLXdpZHRoOjA7Y29sb3I6I0UxRTFFMTtiYWNrZ3JvdW5kLWNvbG9yOiNFMUUx RTE7Ii8+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7IHBhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmksIEFyaWFs LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxiPkZyb206PC9iPiBTYW5kcm8gQm9uYXp6b2xhPGJy PjxiPlNlbnQ6PC9iPiBBcHIgMjgsIDIwMTcgNTowOCBBTTxicj48Yj5Ubzo8L2I+IE5pZWxzIGRl IFZvczsgTWlyb3NsYXYgUmV6YW5pbmE7IEthcmVuIE5vZWw7IERvcm9uIEZlZGl1Y2s8YnI+PGI+ Q2M6PC9iPiBkZXZlbDxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IHFlbXUgcGFja2FnaW5nIC0gYWRk IHRoZSAmcXVvdDtxZW11JnF1b3Q7IHVzZXIgdG8gYSAmcXVvdDtnbHVzdGVyJnF1b3Q7IGdyb3Vw Pzxicj48L3NwYW4+PC9kaXY+PC9kaXY+PGJyIHR5cGU9J2F0dHJpYnV0aW9uJz48ZGl2IGlkPSJx dW90ZWRfYm9keSI+PGJsb2NrcXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAw IC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBk aXI9Imx0ciI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPk9uIFdlZCwgQXByIDI2LCAyMDE3IGF0IDM6MzYgUE0sIE5pZWxzIGRlIFZvcyA8 c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0bzpuZGV2b3NAcmVkaGF0LmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm5kZXZvc0ByZWRoYXQuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgg MC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0 OjFleCI+SGksPGJyPgo8YnI+CldlJ3JlIHRyeWluZyB0byBpbXByb3ZlIHRoZSBkZWJ1Z2FiaWxp dHkgb2YgR2x1c3RlciBiYWNrZWQgVk1zIGFuZCBvbmU8YnI+Cm9mIHRoZSBmZWF0dXJlcyBmb3Ig dGhpcyBpcyB0byBiZSBhYmxlIHRvIGdhdGhlciAic3RhdGVkdW1wcyIuIFRoZXNlPGJyPgpzdGF0 ZWR1bXBzIGluY2x1ZGUgbWVtb3J5IGFsbG9jYXRpb24gZGV0YWlscyBhbmQgb3RoZXIgaW5mb3Jt YXRpb24gYWJvdXQ8YnI+CnRoZSBHbHVzdGVyIGNsaWVudC4gUUVNVSBpcyBvbmUgb2YgdGhlIGFw cGxpY2F0aW9ucyB0aGF0IGNhbiBiZTxicj4KY29uZmlndXJlZCB0byB1c2UgbGliZ2ZhcGkuc28g R2x1c3RlciBjbGllbnQuPGJyPgo8YnI+CkdsdXN0ZXIgcHJvdmlkZXMgdGhlIC92YXIvcnVuL2ds dXN0ZXIvIGRpcmVjdG9yeSBhbmQgdGhlIGxpYmdmYXBpLnNvPGJyPgpsaWJyYXJ5IHRoYXQgcWVt dSAoaW4gYmxvY2svZ2x1c3Rlci5jKSB1c2VzIHRoYXQuIFdvdWxkIHRoZXJlIGJlIGE8YnI+CnBy b2JsZW0gZm9yIHRoZSAicWVtdSIgcGFja2FnZXMgdG8gdXNlIGFkZCB0aGUgInFlbXUiIHVzZXIg dG8gYTxicj4KImdsdXN0ZXIiIGdyb3VwPyBJJ20gbm90IHN1cmUgeWV0IGhvdyB0aGlzIGlzIGRv bmUgZm9yIG90aGVyIHBhY2thZ2VzPGJyPgp3aXRoIHRoZWlyIG93biB1c2VycywgYnV0IHRoZXJl IHdvdWxkIGJlIGEgZGVwZW5kZW50IGluc3RhbGxhdGlvbiBvcmRlcjxicj4Kb2Ygc29tZSBraW5k IChuZWVkcyBycG0gdHJpZ2dlcnM/KS48YnI+Cjxicj4KV2hhdCBpcyB5b3VyIG9waW5pb24gb24g dGhpcyBpc3N1ZSwgb3Igd291bGQgeW91IHJlY29tbWVuZCBhbiBvdGhlcjxicj4KYXBwcm9hY2g/ PGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PkFkZGluZyBNaXJvc2xhdiwgS2Fy ZW4gYW5kIERvcm9uLjwvZGl2PjxkaXY+SSdtIG5vdCBzdXJlIGFib3V0IGhvdyBsaWJnZmFwaSBp cyBjb25zdW1lZCBieSBxZW11LWt2bSgtZXYvLXJoZXYpIGJ1dCBpZiBpdHMgc3VwcG9ydCBpcyBl bmFibGUgYnkgZGVmYXVsdCBhbmQgZG9lc24ndCByZXF1aXJlIGFkZGl0aW9uYWwgcWVtdS1rdm0g c3ViIHBhY2thZ2VzIHRvIGJlIGVuYWJsZWQsIEkgd291bGQgc3VnZ2VzdCB0byBqdXN0IGZvbGxv dyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZmVkb3JhcHJvamVjdC5vcmcvd2lraS9QYWNrYWdpbmc6 VXNlcnNBbmRHcm91cHMiPmh0dHBzOi8vZmVkb3JhcHJvamVjdC5vcmcvd2lraS9QYWNrYWdpbmc6 VXNlcnNBbmRHcm91cHM8L2E+PC9kaXY+PGRpdj5hbmQgYWRkIHRoZSBxZW11IHVzZXIgdG8gdGhl IGdsdXN0ZXIgZ3JvdXAgaW4gJXByZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkZyb20gb1Zp cnQgcG9pbnQgb2YgdmlldywgSSB0aGluayBpdCBzaG91bGRuJ3QgYWZmZWN0IHVzIHZlcnkgbXVj aC4gT24gQ2VudE9TIFZpcnQgU0lHIHdlJ2xsIGNvbnN1bWUgd2hhdGV2ZXIgd2lsbCBjb21lIGZy b20gcWVtdS1rdm0tcmhldi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PiZuYnNwOzwvZGl2Pjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAw LjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6 MWV4Ij4KPGJyPgpUaGFua3MsPGJyPgpOaWVsczxicj4KPGJyPgpQUzogPGEgaHJlZj0iaHR0cHM6 Ly9idWd6aWxsYS5yZWRoYXQuY29tLzE0NDU1NjkiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vYnVnemlsbGEucmVkaGF0LmNvbS88d2JyPjE0NDU1Njk8L2E+IGNhbiBi ZSB1c2VkIHRvIHJlcGx5IGFzIHdlbGw8YnI+Cjxicj4KPGJyPgpGcm9tIDxhIGhyZWY9Imh0dHA6 Ly9saXN0cy5nbHVzdGVyLm9yZy9waXBlcm1haWwvZ2x1c3Rlci1kZXZlbC8yMDE3LUFwcmlsLzA1 MjYyOS5odG1sIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbGlzdHMu Z2x1c3Rlci5vcmcvPHdicj5waXBlcm1haWwvZ2x1c3Rlci1kZXZlbC8yMDE3LTx3YnI+QXByaWwv MDUyNjI5Lmh0bWw8L2E+Ojxicj4KT24gVHVlLCBBcHIgMjUsIDIwMTcgYXQgMDc6NTM6MDZQTSAr MDIwMCwgTmllbHMgZGUgVm9zIHdyb3RlOjxicj4KJmd0OyBIaSw8YnI+CiZndDs8YnI+CiZndDsg UmVjZW50bHkgYSBuZXcgYWJpbGl0eSB0byB0cmlnZ2VyIHN0YXRlZHVtcHMgdGhyb3VnaCB0aGUg R2x1c3Rlci1DTEkgWzBdPGJyPgomZ3Q7IGhhcyBiZWVuIGFkZGVkLiBUaGlzIG1ha2VzIGl0IHBv c3NpYmxlIHRvIGdldCBzdGF0ZWR1bXAgZnJvbTxicj4KJmd0OyBhcHBsaWNhdGlvbnMgdGhhdCB1 c2UgZ2ZhcGkuIEJ5IGRlZmF1bHQsIHN0YXRlZHVtcHMgYXJlIHNhdmVkIHVuZGVyPGJyPgomZ3Q7 IC92YXIvcnVuL2dsdXN0ZXIvLi4uIGFuZCB0aGlzIGRpcmVjdG9yeSBpcyBvbmx5IHdyaXRhYmxl IGJ5IHJvb3QuPGJyPgomZ3Q7IEFwcGxpY2F0aW9ucyB0aGF0IHVzZSBnZmFwaSBkbyBub3QgcmVx dWlyZSByb290IHBlcm1pc3Npb25zIChsaWtlIFFFTVUpLDxicj4KJmd0OyBhbmQgdGhlcmVmb3Jl IGZhaWwgdG8gd3JpdGUgdGhlIHN0YXRlZHVtcCA6LS88YnI+CiZndDs8YnI+CiZndDsgT25lIGFw cHJvYWNoIHdvdWxkIGJlIHRvIGNyZWF0ZSBhICJnbHVzdGVyIiBncm91cCBhbmQgZ2l2ZSB0aGUg Z3JvdXA8YnI+CiZndDsgcGVybWlzc2lvbnMgdG8gd3JpdGUgdG8gL3Zhci9ydW4vZ2x1c3Rlci8u Li4gT3RoZXIgJ2ZpeGVzJyBpbmNsdWRlPGJyPgomZ3Q7IHNldHRpbmcgQUNMcyBvbiB0aGUgZGly ZWN0b3J5IHNvIHRoYXQgc3BlY2lmaWVkIHVzZXJzIGNhbiB3cml0ZSB0aGVyZS48YnI+CiZndDsg YmVjYXVzZSBtYW55IGRhZW1vbnMgaGF2ZSBhICJob21lIGRpcmVjdG9yeSIgdGhhdCBkb2VzIG5v dCBleGlzdCwgaXQ8YnI+CiZndDsgcHJvYmFibHkgaXMgbm90IGEgZ29vZCBpZGVhIHRvIHVzZSAk SE9NRSB0byBzdG9yZSBzdGF0ZWR1bXBzLjxicj4KJmd0Ozxicj4KJmd0OyBXaGF0IHN1Z2dlc3Rp b25zIGRvIG90aGVycyBoYXZlPzxicj4KJmd0Ozxicj4KJmd0OyBUaGFua3MsPGJyPgomZ3Q7IE5p ZWxzPGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7IDAuIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9nbHVzdGVyL2dsdXN0ZXJmcy9ibG9iL21hc3Rlci9kb2MvZGVidWdnaW5nL3N0YXRlZHVt cC5tZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29t L2dsdXN0ZXIvPHdicj5nbHVzdGVyZnMvYmxvYi9tYXN0ZXIvZG9jLzx3YnI+ZGVidWdnaW5nL3N0 YXRlZHVtcC5tZDwvYT48YnI+Cjxicj4KPGJyPgo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBj bGVhcj0iYWxsIj48ZGl2Pjxicj48L2Rpdj4tLSA8YnI+PGRpdiBjbGFzcz0iZ21haWxfc2lnbmF0 dXJlIj48ZGl2IGRpcj0ibHRyIj48ZGl2PjxkaXYgZGlyPSJsdHIiPjxkaXYgZGlyPSJsdHIiPjxk aXYgZGlyPSJsdHIiPjxkaXYgZGlyPSJsdHIiPjxwIHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2Zv bnQtZmFtaWx5Om92ZXJwYXNzLHNhbnMtc2VyaWY7Zm9udC13ZWlnaHQ6Ym9sZDttYXJnaW46MHB4 O3BhZGRpbmc6MHB4O2ZvbnQtc2l6ZToxNHB4O3RleHQtdHJhbnNmb3JtOnVwcGVyY2FzZSI+PHNw YW4+U0FORFJPPC9zcGFuPiZuYnNwOzxzcGFuPkJPTkFaWk9MQTwvc3Bhbj48L3A+PHAgc3R5bGU9 ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1mYW1pbHk6b3ZlcnBhc3Msc2Fucy1zZXJpZjtmb250LXNp emU6MTBweDttYXJnaW46MHB4IDBweCA0cHg7dGV4dC10cmFuc2Zvcm06dXBwZXJjYXNlIj48c3Bh bj5BU1NPQ0lBVEUgTUFOQUdFUiwgU09GVFdBUkUgRU5HSU5FRVJJTkcsIEVNRUEgRU5HIFZJUlRV QUxJWkFUSU9OIFImYW1wO0Q8L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LWZhbWlseTpvdmVycGFz cyxzYW5zLXNlcmlmO21hcmdpbjowcHg7Zm9udC1zaXplOjEwcHg7Y29sb3I6cmdiKDE1MywxNTMs MTUzKSI+PGEgaHJlZj0iaHR0cHM6Ly93d3cucmVkaGF0LmNvbS8iIHN0eWxlPSJjb2xvcjpyZ2Io MCwxMzYsMjA2KTttYXJnaW46MHB4IiB0YXJnZXQ9Il9ibGFuayI+UmVkIEhhdCZuYnNwOzxzcGFu PkVNRUE8L3NwYW4+PC9hPjwvcD48dGFibGUgYm9yZGVyPSIwIiBzdHlsZT0iY29sb3I6cmdiKDAs MCwwKTtmb250LWZhbWlseTpvdmVycGFzcyxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTptZWRpdW0iPjx0 Ym9keT48dHI+PHRkIHdpZHRoPSIxMDBweCI+PGEgaHJlZj0iaHR0cHM6Ly9yZWQuaHQvc2lnIiB0 YXJnZXQ9Il9ibGFuayI+PGltZyBzcmM9Imh0dHBzOi8vd3d3LnJlZGhhdC5jb20vcHJvZmlsZXMv cmgvdGhlbWVzL3JlZGhhdGRvdGNvbS9pbWcvbG9nby1yZWQtaGF0LWJsYWNrLnBuZyIgd2lkdGg9 IjkwIiBoZWlnaHQ9ImF1dG8iPjwvYT48L3RkPjx0ZCBzdHlsZT0iZm9udC1zaXplOjEwcHgiPjxk aXY+PGEgaHJlZj0iaHR0cHM6Ly9yZWRoYXQuY29tL3RydXN0ZWQiIHN0eWxlPSJjb2xvcjpyZ2Io MjA0LDAsMCk7Zm9udC13ZWlnaHQ6Ym9sZCIgdGFyZ2V0PSJfYmxhbmsiPlRSSUVELiBURVNURUQu IFRSVVNURUQuPC9hPjwvZGl2PjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+CjwvZGl2PjwvZGl2Pgo8L2Jsb2NrcXVvdGU+ PC9kaXY+ ----_com.ninefolders.hd3.email_963684395295557_alt--

5 4