[ovirt-devel] Re: ost test suits relevance

[Roy Golan]

On Mon, 22 Jun 2020 at 13:28, Galit Rosenthal  wrote:

>
>1. dr-suite-master - Tal Nissan, can we remove?
>2. he-basic-ipv6-suite-master (doesn't contain updating centos7/8 as
>he-basic-iscsi/master  - Dominik has a patch for this suite
>3. metric-suite (contain only 4.3 version) - Shirly and Evgeny are
>responsible
>4. performance-suite-master - Roy Golan ?
>
> You can remove, but maybe consult with @Martin Perina 
to see if someone on his team can use it. Anyhow I'd like to be removed
from being an owner.


> On Mon, Jun 22, 2020 at 12:41 PM Artem Hrechanychenko 
> wrote:
>
>> Hi,
>> during porting of several OST suites to python3 I found that some of them
>> are not updated for  some period of time.
>>
>> Does anyone know the relevance of next test suits?
>>
>>1. dr-suite-master
>>2. he-basic-ipv6-suite-master (doesn't contain updating centos7/8 as
>>he-basic-iscsi/master
>>3. metric-suite (contain only 4.3 version)
>>4. performance-suite-master
>>
>>
>> https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git;a=tree
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/32OZDGRH6IGRN6LGDW5I2C6E6C3GCBT4/
>>
>
>
> --
>
> GALIT ROSENTHAL
>
> SOFTWARE ENGINEER
>
> Red Hat
>
> <https://www.redhat.com/>
>
> ga...@redhat.comT: 972-9-7692230
> <https://red.ht/sig>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/QIQFX6PMLQYRC72AYZKCB4CEJKKLIUBZ/

[ovirt-devel] Re: Proposing Benny Zlotnik as an Engine Storage maintainer

[Roy Golan]

On Sun, 23 Feb 2020 at 12:30, Fred Rolland  wrote:

> +1
>
> On Fri, Feb 21, 2020 at 8:53 PM Tal Nisan  wrote:
>
>> Hi everyone,
>> Benny joined the Storage team in November 2016 and since then played a
>> key role in investigating very complex customer bugs around oVirt engine as
>> well as contributing to features such as DR, Cinberlib, new export/import
>> mechanism and also rewrote and still maintains the LSM mechanism.
>> Given his big contribution and knowledge around the engine I'd like to
>> nominate Benny as an engine storage maintainer.
>>
>> Your thoughts please.
>> Tal.
>>
>
+2 :)

___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/G52XI2QDSJNAOMZURGAFQJH2RZIHJBRX/
>>
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GRZXZEA3MQKOVCILNQZZVAZ64HMPYQOQ/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/TRNHBAOMERUWGUFFFSWDP323BVB3D4R3/

[ovirt-devel] ovirt-engine on master compiles and runs on Java-11

[Roy Golan]

Hi all,

ovirt-engine project reached a nice milestone, compiling and running on
Java-11 
The move itself needed care to see nothing breaks and with the help of OST
it remaind
like unbroken, but the move was mostly painless and didn't require changes
to
real business logic code. It was mainly to deal with 2 things, working with
modules and
lack of support from GWT.

Modular JDK (project jigsaw) landed in java-9 is more relevant to the
delivery of the sofware
rather to the development of it. Specifically now you can ship your
software only with
a subset of the jdk, or produce your jar as a module so it can expose or
hide internal
with real enforcment(even no reflection).
The relevant part to the change here is that java doesn't provide EE code
in the jdk,
specifically java.xml, java.annotation, javax.activation [1]

GWT and specifically the gwt compiler doesn't recognize java syntax beyond
8, and
efforts of the community to support don't look promising. Luckily since it
is strictly
compile-time only concern the invocation of the gwt compiler, which is
invoked by
maven, is instructed to use java-8 javac. This means the frontend artifacts
are
remain uneffected by this change.

Morning comes, I want to rebase and compile the project!
This should not be huge change, and is document here [2]:
- install java-11-openjdk-devel
- make java-11 binaries available on your path *before java-8 *(use your
favorite method
  I use alternatives)
- install maven >= 3.5.0

Please report any problem here and also if the README [2] is not helping
enough
please help improve it!

P.S - Obviously it is strongly encouraged to get familiar with what java 9,
10, and 11
brought in and start make use of it. If you think you have code you want to
contribute
to master, but is going to be backported to 4.3 bare in mind the difference
in java version.

Thanks,
  Roy

[1] covered in the git log https://gerrit.ovirt.org/#/c/98623/
[2]
https://github.com/oVirt/ovirt-engine/blob/master/README.adoc#note-on-java-versions
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/3XFFWGD3YCPDGGAQLX5IFCB6H63NJDSD/

[ovirt-devel] [ANN] Incubating terraform-provider-ovirt

[Roy Golan]

Hi all,

Happy to announce the incubation of a terraform provider[1] for oVirt which
is the
the result of a community effort started by ESM-MSC institute [2]
and then picked up by @imjoey [3] which is now the main maintainer of the
project.

Terraform with an ovirt provider makes it easy to declaratively create
virtualized environments.
One usage we will make of it is to create an installer for OKD 4 [4] which
will lay an OKD cluster on top of oVirt resources.

[1] https://github.com/oVirt/terraform-provider-ovirt
[2] https://github.com/EMSL-MSC/terraform-provider-ovirt
[3] https://github.com/imjoey/terraform-provider-ovirt
[4] https://github.com/openshift/installer

Roy
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/EF7OQUVTY53GV3A7NVQVUT7UCUYKK5CH/

[ovirt-devel] Re: [ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 17-05-19 ] [ 004_basic_sanity.run_vms ]

[Roy Golan]

On Fri, 17 May 2019 at 12:34, Dafna Ron  wrote:

> Hi,
>
> We are failing to run vm in project ovirt-engine on master branch on both
> basic and upgrade suites
>
> CQ reported this patch as root cause:
>
> https://gerrit.ovirt.org/#/c/99372/6 - core: Initial Ignition support over
> custom script 
>
> I can see errors in the log related to cloud-init which happen at the same
> time we try to run the vm.
> There are also NPE on GetVMLeaseInfo happening before.
>
> Roy can you please take a look?
>
> Full logs from first failure can be found here:
>
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/14148/artifact/basic-suite.el7.x86_64/test_logs/basic-suite-master/post-004_basic_sanity.py/
>
>
> Thanks,
> Dafna
>

Thanks Dafna for the heads up - here is a fix
https://gerrit.ovirt.org/100133

+Andrej Krejcir  can you have a look?


>
> Error from log:
>
> 2019-05-16 12:53:46,184-04 INFO
>  [org.ovirt.engine.core.vdsbroker.CreateVDSCommand] (default task-2)
> [ad7888f0-4368-4792-b6a8-f7cd4b0ebbe6] START, CreateVDSCommand( CreateVD
> SCommandParameters:{hostId='31dd3a99-5821-437b-8995-232cfcd67d84',
> vmId='362080c4-4d08-4b40-b6e7-9c04bf854d68', vm='VM [vm0]'}), log id:
> 522026aa
> 2019-05-16 12:53:46,190-04 INFO
>  [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]
> (default task-2) [ad7888f0-4368-4792-b6a8-f7cd4b0ebbe6] START, CreateBrok
> erVDSCommand(HostName = lago-basic-suite-master-host-1,
> CreateVDSCommandParameters:{hostId='31dd3a99-5821-437b-8995-232cfcd67d84',
> vmId='362080c4-4d08-4b40-b6e7-9c04bf854d68
> ', vm='VM [vm0]'}), log id: 6bbd62c6
> 2019-05-16 12:53:46,201-04 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] (default
> task-2) [ad7888f0-4368-4792-b6a8-f7cd4b0ebbe6] Failed in 'CreateBrokerVDS'
> method, for vds: 'lago-basic-suite-master-host-1'; host:
> 'lago-basic-suite-master-host-1': Failed to build cloud-init data:
> 2019-05-16 12:53:46,201-04 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] (default
> task-2) [ad7888f0-4368-4792-b6a8-f7cd4b0ebbe6] Command
> 'CreateBrokerVDSCommand(HostName = lago-basic-suite-master-host-1,
> CreateVDSCommandParameters:{hostId='31dd3a99-5821-437b-8995-232cfcd67d84',
> vmId='362080c4-4d08-4b40-b6e7-9c04bf854d68', vm='VM [vm0]'})' execution
> failed: Failed to build cloud-init data:
> 2019-05-16 12:53:46,201-04 DEBUG
> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] (default
> task-2) [ad7888f0-4368-4792-b6a8-f7cd4b0ebbe6] Exception:
> java.lang.RuntimeException: Failed to build cloud-init data:
> at
> org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand.getPayload(CreateBrokerVDSCommand.java:177)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand.generateDomainXml(CreateBrokerVDSCommand.java:90)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand.createInfo(CreateBrokerVDSCommand.java:52)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand.executeVdsBrokerCommand(CreateBrokerVDSCommand.java:44)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVdsCommandWithNetworkEvent(VdsBrokerCommand.java:123)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:111)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:65)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31)
> [dal.jar:]
> at
> org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:397)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand(Unknown
> Source) [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.CreateVDSCommand.executeVmCommand(CreateVDSCommand.java:37)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.ManagingVmCommand.executeVDSCommand(ManagingVmCommand.java:17)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:65)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31)
> [dal.jar:]
> at
> org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:397)
> [vdsbroker.jar:]
> at
> org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand$$super(Unknown
> 

[ovirt-devel] Re: ovirt-vdsmfake

[Roy Golan]

long ago I hooked it into the performance suite. Anyway, I don't thing an
rpm is needed and you can remove it. If needed you
just fire mvn to run it.

On Wed, 20 Mar 2019 at 17:38, Martin Sivak  wrote:

> I only ever used it compiled from source for developer side validation. I
> never used any packages..
>
> Martin
>
> On Wed, Mar 20, 2019 at 4:35 PM Sandro Bonazzola 
> wrote:
>
>>
>>
>> Il giorno mer 20 mar 2019 alle ore 16:30 Greg Sheremeta <
>> gsher...@redhat.com> ha scritto:
>>
>>> Ok 
>>>
>>> Then I guess it stays. :)
>>>
>>
>> Stays on master only? Do we need it in 4.3?
>> Looking at google looks like only documentation available is
>> https://www.ovirt.org/develop/developer-guide/vdsm/fake.html
>> I don't see it used in OST, does it make sense to add a test using it for
>> scale?
>>
>>
>>
>>>
>>> On Wed, Mar 20, 2019 at 10:34 AM Martin Sivak  wrote:
>>>
 Really? I was definitely using it last year for scheduling testing.

 Martin

 On Wed, Mar 20, 2019 at 3:30 PM Greg Sheremeta 
 wrote:

> It is abandoned, and hasn't worked in quite some time. Last commit was
> 2017, and even in 2017 it wasn't always reliable so we stopped using it.
>
> Greg
>
>
> On Wed, Mar 20, 2019 at 10:02 AM Sandro Bonazzola 
> wrote:
>
>> Hi,
>> on master we have ovirt-vdsmfake package.
>> Is there any reason for branching it and/or add it to 4.3 pipeline?
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat.com
>> 
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/CSCEZN7SVXYDVZZSZ5NJDH3QK2R4NPKD/
>>
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/U7JMX4SUNYRMG4USZMR5GOXLOHJ4SIXK/
>

>>>
>>> --
>>>
>>> GREG SHEREMETA
>>>
>>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>>
>>> Red Hat NA
>>>
>>> 
>>>
>>> gsher...@redhat.comIRC: gshereme
>>> 
>>>
>>
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat.com
>> 
>>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/HJDK6RDLYABZI5C4YTL3QROW4XOFWBNN/

[ovirt-devel] Re: Missed ovirt-openshift-extensions release?

[Roy Golan]

On Mon, 18 Mar 2019 at 12:00, Sandro Bonazzola  wrote:

>
>
> Il giorno lun 18 mar 2019 alle ore 10:42 Roy Golan  ha
> scritto:
>
>>
>>
>> On Mon, 18 Mar 2019 at 10:52, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> Il giorno lun 18 mar 2019 alle ore 09:49 Roy Golan 
>>> ha scritto:
>>>
>>>> We should, as tech-preview
>>>>
>>>
>>> I see the jenkins job is not building RPMs,
>>> https://jenkins.ovirt.org/job/oVirt_ovirt-openshift-extensions_standard-on-ghpush/
>>> We should start getting them built and tested by CI starting from master
>>>
>>
>> The project artifacts are containers, no RPMs at all. The job above build
>> and push containers to quay.io/rgolangh .
>> If there is no official registry namespace for ovirt yet, now its the
>> time to create it.
>>
>
>
> I've a question then, should we drop:
> - ovirt-flexvolume-driver.x86_64
> - ovirt-provisioner.x86_64
>
> from ovirt-master-snapshot ? I understood they came from
> ovirt-openshift-extensions codebase in the past
>
> Yes indeed need to be removed. Thanks!



>
>>
>>>
>>>>
>>>> On Mon, 18 Mar 2019 at 10:46, Sandro Bonazzola 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> Il giorno mer 13 mar 2019 alle ore 15:48 Roy Golan 
>>>>> ha scritto:
>>>>>
>>>>>> No, I just bumped the tag for next release :) but github is probably
>>>>>> announcing a new release when a tag is pushed.
>>>>>>
>>>>>>
>>>>> So, just to be sure, we are not going to release any artifact built
>>>>> from ovirt-openshift-extensions in 4.3 right?
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 13 Mar 2019 at 15:49, Sandro Bonazzola 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> just seen
>>>>>>> https://twitter.com/RealGophersShip/status/1105791600762986496
>>>>>>> Are we missing a release of ovirt-openshift-extensions?
>>>>>>> It wasn't included in 4.3.2 RC2
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> SANDRO BONAZZOLA
>>>>>>>
>>>>>>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>>>>>>
>>>>>>> Red Hat EMEA <https://www.redhat.com/>
>>>>>>>
>>>>>>> sbona...@redhat.com
>>>>>>> <https://red.ht/sig>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> SANDRO BONAZZOLA
>>>>>
>>>>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>>>>
>>>>> Red Hat EMEA <https://www.redhat.com/>
>>>>>
>>>>> sbona...@redhat.com
>>>>> <https://red.ht/sig>
>>>>>
>>>>
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>>
>>> Red Hat EMEA <https://www.redhat.com/>
>>>
>>> sbona...@redhat.com
>>> <https://red.ht/sig>
>>>
>>
>
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://red.ht/sig>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/CJOQWMS3V53L3SWDVJ4YANIZDIYV2CXN/

[ovirt-devel] Re: Missed ovirt-openshift-extensions release?

[Roy Golan]

On Mon, 18 Mar 2019 at 10:52, Sandro Bonazzola  wrote:

>
>
> Il giorno lun 18 mar 2019 alle ore 09:49 Roy Golan  ha
> scritto:
>
>> We should, as tech-preview
>>
>
> I see the jenkins job is not building RPMs,
> https://jenkins.ovirt.org/job/oVirt_ovirt-openshift-extensions_standard-on-ghpush/
> We should start getting them built and tested by CI starting from master
>

The project artifacts are containers, no RPMs at all. The job above build
and push containers to quay.io/rgolangh .
If there is no official registry namespace for ovirt yet, now its the time
to create it.

>
>
>>
>> On Mon, 18 Mar 2019 at 10:46, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> Il giorno mer 13 mar 2019 alle ore 15:48 Roy Golan 
>>> ha scritto:
>>>
>>>> No, I just bumped the tag for next release :) but github is probably
>>>> announcing a new release when a tag is pushed.
>>>>
>>>>
>>> So, just to be sure, we are not going to release any artifact built from
>>> ovirt-openshift-extensions in 4.3 right?
>>>
>>>
>>>
>>>>
>>>>
>>>> On Wed, 13 Mar 2019 at 15:49, Sandro Bonazzola 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> just seen
>>>>> https://twitter.com/RealGophersShip/status/1105791600762986496
>>>>> Are we missing a release of ovirt-openshift-extensions?
>>>>> It wasn't included in 4.3.2 RC2
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --
>>>>>
>>>>> SANDRO BONAZZOLA
>>>>>
>>>>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>>>>
>>>>> Red Hat EMEA <https://www.redhat.com/>
>>>>>
>>>>> sbona...@redhat.com
>>>>> <https://red.ht/sig>
>>>>>
>>>>
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>>
>>> Red Hat EMEA <https://www.redhat.com/>
>>>
>>> sbona...@redhat.com
>>> <https://red.ht/sig>
>>>
>>
>
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://red.ht/sig>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/OIXZKL2V5OZORUB2VHJU3SD4VEYZAMPR/

[ovirt-devel] Re: Missed ovirt-openshift-extensions release?

[Roy Golan]

We should, as tech-preview

On Mon, 18 Mar 2019 at 10:46, Sandro Bonazzola  wrote:

>
>
> Il giorno mer 13 mar 2019 alle ore 15:48 Roy Golan  ha
> scritto:
>
>> No, I just bumped the tag for next release :) but github is probably
>> announcing a new release when a tag is pushed.
>>
>>
> So, just to be sure, we are not going to release any artifact built from
> ovirt-openshift-extensions in 4.3 right?
>
>
>
>>
>>
>> On Wed, 13 Mar 2019 at 15:49, Sandro Bonazzola 
>> wrote:
>>
>>> Hi,
>>> just seen https://twitter.com/RealGophersShip/status/1105791600762986496
>>> Are we missing a release of ovirt-openshift-extensions?
>>> It wasn't included in 4.3.2 RC2
>>>
>>> Thanks,
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>>
>>> Red Hat EMEA <https://www.redhat.com/>
>>>
>>> sbona...@redhat.com
>>> <https://red.ht/sig>
>>>
>>
>
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://red.ht/sig>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/I3XNXXEYNKPI5B4EVVPKQVQUWGBWPLTV/

[ovirt-devel] Re: Missed ovirt-openshift-extensions release?

[Roy Golan]

No, I just bumped the tag for next release :) but github is probably
announcing a new release when a tag is pushed.



On Wed, 13 Mar 2019 at 15:49, Sandro Bonazzola  wrote:

> Hi,
> just seen https://twitter.com/RealGophersShip/status/1105791600762986496
> Are we missing a release of ovirt-openshift-extensions?
> It wasn't included in 4.3.2 RC2
>
> Thanks,
>
> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/C4YIBGBVMNYFXDT3N45LWCMJAPJSI4RR/

[ovirt-devel] Re: imageio proxy and engine dev setup

[Roy Golan]

On Tue, 5 Feb 2019 at 20:58, Nir Soffer  wrote:

> On Tue, Feb 5, 2019 at 6:46 PM Fedor Gavrilov  wrote:
>
>> Right!
>>
>> Oh, it just occured to me that imageio prject is two parts and they
>> expect me to be in proxy/ directory in the installation docs.
>> There is indeed a make-install goal there :)
>>
>> Tried running it and it seems now setup script recognizes it now.
>>
>
> Right, the instructions should be improved to show all the steps.
>
> This should work:
>
> git clone ...
> cd ovirt-imageio
> make
> cd proxy
> make install-dev ENGINE_PREFIX=/home/nsoffer/ovirt-engine
>
> /home/nsoffer/ovirt-engine/bin/engine-setup
> (configure it...)
>
> There are 2 bugs here - 1. the engine will fail to talk with the proxy
because the default proxy
address is localhost:54323 which will fail ssl verification. This needs to
be address in the
engine setup plugin
2. The engine will not fail an attempt to upload when it can't actually
communicate with the proxy. ImageTransfer needs validation there.

To fix it you need to:
$ENGINE_PREFIX/bin/engine-config -s
ImageProxyAddress=OVIRT-ENGINE-FQDN:54323

export PYTHONPATH=/home/nsoffer/src/ovirt-imageio/common
> ./ovirt-imageio-proxy
>
> Nir
>
>
>> Thanks!
>> Fedor Gavrilov
>>
>> - Исходное сообщение -
>> От: "Fedor Gavrilov" 
>> Кому: "Nir Soffer" 
>> Копия: "devel" 
>> Отправленные: Вторник, 5 Февраль 2019 г 17:33:15
>> Тема: [ovirt-devel] Re: imageio proxy and engine dev setup
>>
>> Hi,
>>
>> I tried that already unfortunately. Executing make install-dev from
>> imageio sources directory complains about no such target.
>> Autocomplete for make suggests the following:
>>
>> [fgavrilo@localhost ovirt-imageio]$ make
>> all check   clean   common  daemon  distproxy   rpm srpm
>>
>> Wasn't successful with these targets either.
>>
>> Fedor Gavrilov
>>
>> - Исходное сообщение -
>> От: "Nir Soffer" 
>> Кому: "Fedor Gavrilov" 
>> Копия: "devel" , "Daniel Erez" , "Roy
>> Golan" 
>> Отправленные: Вторник, 5 Февраль 2019 г 17:18:42
>> Тема: Re: [ovirt-devel] imageio proxy and engine dev setup
>>
>> On Tue, Feb 5, 2019 at 5:05 PM Fedor Gavrilov 
>> wrote:
>>
>> > Hi,
>> >
>> > It seems to be rather difficult to have development setup for the engine
>> > with imageio proxy.
>> > engine-setup script never asks about it, running it again with
>> > --reconfigure-optional-components changes nothing and answers file
>> contains
>> > no mention of imageio (thus,
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1446094 does not look to be
>> > fixed for dev setups). There is no package to install separately either.
>> >
>> > Quite confused now. Do you happen to know what am I missing?
>> >
>>
>> Installing with development engine (not installed with rpms) is documented
>> here:
>>
>>
>>
>> http://ovirt.github.io/ovirt-imageio/installation.html#installation-with-ovirt-engine-developer-environment
>>
>>
>> >
>> > Fedor Gavrilov
>> > ___
>> > Devel mailing list -- devel@ovirt.org
>> > To unsubscribe send an email to devel-le...@ovirt.org
>> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> > oVirt Code of Conduct:
>> > https://www.ovirt.org/community/about/community-guidelines/
>> > List Archives:
>> >
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/JTLEMRZMGMNNLKNCJ45L2VJO5EANY56W/
>> >
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/HVEXCKBLSRDRTSLHM2SYCHFQVVQQEBUF/
>>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IPWTKN6Y2GGF3JBTZXH2RG75E2EDC4DX/

[ovirt-devel] Re: Issue in host deploy

[Roy Golan]

On Wed, 12 Sep 2018 at 14:48 Ravi Shankar Nori  wrote:

> postgres=# select * from pg_database ;
> datname | datdba | encoding | datcollate  |  datctype   |
> datistemplate | datallowconn | datconnlimit | datlastsysoid | datfrozenxid
> | datminmxid | dattablespace |   datacl
>
>
> ++--+-+-+---+--+--+---+--++---+
> -
>  postgres   | 10 |6 | en_US.UTF-8 | en_US.UTF-8 |
> f | t|   -1 | 13288 |  548
> |  1 |  1663 |
>  engineMnew9|  16384 |6 | en_US.UTF-8 | en_US.UTF-8 |
> f | t|   -1 | 13288 |  548
> |  1 |  1663 |
>  template1  | 10 |6 | en_US.UTF-8 | en_US.UTF-8 |
> t | t|   -1 | 13288 |  548
> |  1 |  1663 | {=c/postgres,postgres=CTc/postg
> res}
>  template0  | 10 |6 | en_US.UTF-8 | en_US.UTF-8 |
> t | f|   -1 | 13288 |  548
> |  1 |  1663 | {=c/postgres,postgres=CTc/postg
> res}
>  engine |  21876 |6 | en_US.UTF-8 | en_US.UTF-8 |
> f | t|   -1 | 13288 |  548
> |  1 |  1663 |
>  engine_dao_tests   |  16384 |6 | en_US.UTF-8 | en_US.UTF-8 |
> f | t|   -1 | 13288 |  548
> |  1 |  1663 |
>  engine42   |  16384 |6 | en_US.UTF-8 | en_US.UTF-8 |
> f | t|   -1 | 13288 |  548
> |  1 |  1663 |
>  engineMnew8|  16384 |6 | en_US.UTF-8 | en_US.UTF-8 |
> f | t|   -1 | 13288 |  548
> |  1 |  1663 |
>  engine_master_aaa_jdbc |  16384 |6 | en_US.UTF-8 | en_US.UTF-8 |
> f | t|   -1 | 13288 |  548
> |  1 |  1663 |
> (9 rows)
>
> I think the problem is the null characters in the op code returned to
> VdsDeploy.
>
>
While java handle \u in a string, it seems that postgres will refuse to
do so.

ovirt=# insert into testa values (1, U&'\');
ERRERROR:  invalid byte sequence for encoding "UTF8": 0x00


Do you know why it started to appear as an op code? I'd blame host deploy
and eliminate those.

>
> On Wed, Sep 12, 2018 at 7:36 AM, Roy Golan  wrote:
>
>> Collate of the db is wrong?
>>
>> Can you give the output of 'select * from pg_database ;'
>>
>> Mine is:
>>Name|  Owner   | Encoding |  Collate   |   Ctype|   Access
>> privileges
>>
>> ---+--+--+++---
>>  ovirt | postgres | UTF8 | en_US.utf8 | en_US.utf8 |
>>
>>
>>
>> On Wed, 12 Sep 2018 at 13:46 Ravi Shankar Nori  wrote:
>>
>>> Hi,
>>>
>>> Host deploy is failing on master with errors. The issue seems to be that
>>> the opcode that is returned from vdsm has Unicode null characters in it
>>> (obtained using a break point in VdsDeploy.userVisibleLog).
>>>
>>> "Failed to execute stage 'Initializing': Invalid response opcode
>>> '\u\u\u\u\u\u\u\u\u\u\uCONFIRM'"
>>>
>>> Resulting in below errors when the message is inserted into database.
>>>
>>> Can someone take a look
>>>
>>> 2018-09-11 13:38:11,121-04 INFO
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>>> (VdsDeploy) [669a0081] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing
>>> Host 192.168.122.57. Stage: Initializing.
>>> 2018-09-11 13:38:39,231-04 INFO
>>> [org.ovirt.engine.core.utils.transaction.TransactionSupport] (VdsDeploy)
>>> [669a0081] transaction rolled back
>>> 2018-09-11 13:38:39,231-04 ERROR
>>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [669a0081]
>>> Error during deploy dialog
>>> 2018-09-11 13:38:39,246-04 ERROR
>>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
>>> (EE-ManagedThreadFactory-engine-Thread-11) [669a0081] Error during host
>>> 192.168.122.57 install
>>> 2018-09-11 13:38:41,791-04 ERROR
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDi

[ovirt-devel] Re: Issue in host deploy

[Roy Golan]

Collate of the db is wrong?

Can you give the output of 'select * from pg_database ;'

Mine is:
   Name|  Owner   | Encoding |  Collate   |   Ctype|   Access
privileges
---+--+--+++---
 ovirt | postgres | UTF8 | en_US.utf8 | en_US.utf8 |



On Wed, 12 Sep 2018 at 13:46 Ravi Shankar Nori  wrote:

> Hi,
>
> Host deploy is failing on master with errors. The issue seems to be that
> the opcode that is returned from vdsm has Unicode null characters in it
> (obtained using a break point in VdsDeploy.userVisibleLog).
>
> "Failed to execute stage 'Initializing': Invalid response opcode
> '\u\u\u\u\u\u\u\u\u\u\uCONFIRM'"
>
> Resulting in below errors when the message is inserted into database.
>
> Can someone take a look
>
> 2018-09-11 13:38:11,121-04 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [669a0081] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing
> Host 192.168.122.57. Stage: Initializing.
> 2018-09-11 13:38:39,231-04 INFO
> [org.ovirt.engine.core.utils.transaction.TransactionSupport] (VdsDeploy)
> [669a0081] transaction rolled back
> 2018-09-11 13:38:39,231-04 ERROR
> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [669a0081]
> Error during deploy dialog
> 2018-09-11 13:38:39,246-04 ERROR
> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
> (EE-ManagedThreadFactory-engine-Thread-11) [669a0081] Error during host
> 192.168.122.57 install
> 2018-09-11 13:38:41,791-04 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engine-Thread-11) [669a0081] EVENT_ID:
> VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during
> installation of Host 192.168.122.57: CallableStatementCallback; SQL
> [{call insertauditlog(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}ERROR: invalid byte
> sequence for encoding "UTF8": 0x00; nested exception is
> org.postgresql.util.PSQLException: ERROR: invalid byte sequence for
> encoding "UTF8": 0x00.
>
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/JJMZVSHKB37I3CNM5UVD3Y5AZUQDZ7TI/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IV64HB376O5TDTFF4SLEBHLZ2AQRSAJR/

[ovirt-devel] Re: Adding a supported distro

[Roy Golan]

You are trying to add a new host right and not adding a new type of guest
os? I think that's the confusion here.

You install would have to match  the file we maintain in
ovirt-host-deploy/src/plugins/ovirt-host-deploy/vdsm/software.py

@util.export
class Plugin(plugin.PluginBase):
"""Software prerequisites plugin."""

_SUPPORTED = [
{
'distro': ('redhat', 'centos'),
'version': '7.0',
},
{
'distro': ('fedora', ),
'version': '22',
},
{
'distro': ('ibm_powerkvm', ),
'version': '2.1.0',
},
]



You can hack it in https://gerrit.ovirt.org/ovirt-host-deploy

On Tue, 10 Jul 2018 at 23:02  wrote:

> Anyone got an idea?
>
> Thanks,
> Bob
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/M46EP7HZ4M6R5TJ6MTAUQQGKYAGWPFO6/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/BYZP37S7SFPLMSBMCXJH3LO4ZD6WNV7P/

[ovirt-devel] Re: [ovirt-users] PollVDSCommand Error: java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils

[Roy Golan]

On Tue, 26 Jun 2018 at 09:47 Deekshith  wrote:

> What about data if i cleanup the OS ?
>
>
>

See here
https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/

If you want to avoid the backup/restore you can try reinstalling some of
the packages:
   yum reinstall ovirt-engine-wildfly

and run engine-setup.



>  Regards
>
> Deekshith
>
>
>
> *From:* Roy Golan [mailto:rgo...@redhat.com]
> *Sent:* 26 June 2018 12:14
> *To:* Deekshith
> *Cc:* Greg Sheremeta; devel; users
>
>
> *Subject:* Re: [ovirt-users] PollVDSCommand Error:
> java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>
>
>
>
>
> On Tue, 26 Jun 2018 at 07:23 Deekshith  wrote:
>
> Hi team
>
> It was installed 1 year back , 10 days before we were not able to take the
> console and webadmin of the server, it was working only 10 minutes once
> manually restart the server, so I tried refreshing the engine (engine
> cleanup)but same issue ,so I upgraded my centos 7.2 to 7.4 then i got
> webadmin and console of the server ,now my first problem is resolved ...but
> host is not coming up
>
>
>
> I recommend you do an engine-backup, clean up the os (yum update, ensure
> proper ovirt repo for you version) and do engine-setup and restore.
>
>
>
>
>
>
>
> Regards
>
> Deekshith
>
> *From:* Greg Sheremeta [mailto:gsher...@redhat.com]
> *Sent:* 25 June 2018 06:49
> *To:* deeksh...@binaryindia.com
> *Cc:* Roy Golan; devel; users; allent...@gmail.com
>
>
> *Subject:* Re: [ovirt-users] PollVDSCommand Error:
> java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>
>
>
> Is this a fresh install or an upgrade to 4.1?
>
>
>
> On Mon, Jun 25, 2018 at 3:41 AM Deekshith 
> wrote:
>
> Dear team
>
> Engine version is 4.1 and I am able to take the console and webadmin from
> the browser. All the vm data is available in the host . But host is not
> coming up.
>
> I upgrade from the NET( YUM UPDATE) all the necessary packages downloaded
> .. let me know if any log files needed.
>
>
>
> Please help me to resolve the issue .
>
>
>
>  Regards
>
> Deekshith
>
>
>
>
>
> *From:* Greg Sheremeta [mailto:gsher...@redhat.com]
> *Sent:* 22 June 2018 03:22
> *To:* deeksh...@binaryindia.com
> *Cc:* Roy Golan; devel; users; allen_j...@mrpl.co.in
> *Subject:* Re: [ovirt-users] PollVDSCommand Error:
> java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>
>
>
> Is your engine functioning at all? I'm not sure if you're saying your
> entire engine doesn't work, or just host deploy doesn't work.
>
> What version of ovirt engine is this?
>
> How did you install -- fresh installation, upgrade? From source or rpm?
>
>
>
> Best wishes,
>
> Greg
>
>
>
>
>
> On Wed, Jun 20, 2018 at 12:35 AM Deekshith 
> wrote:
>
> Dear team
>
> Please find the attached server and host logs.. ovirt host
> unresponsive(down), unable to install node packages.
>
>
>
> Regards
>
> Deekshith
>
>
>
> *From:* Roy Golan [mailto:rgo...@redhat.com]
> *Sent:* 19 June 2018 06:57
> *To:* Greg Sheremeta
> *Cc:* devel; users; deeksh...@binaryindia.com; allen_j...@mrpl.co.in
> *Subject:* Re: [ovirt-users] PollVDSCommand Error:
> java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>
>
>
>
>
> On Tue, 19 Jun 2018 at 16:04 Greg Sheremeta  wrote:
>
> Sending to devel list.
>
>
>
> Anyone ever seen this before? It sounds like a bad installation if Java
> classes are missing / classloader issues are present.
>
>
>
> 2018-06-18 11:23:11,287+05 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74] EVENT_ID:
> VDS_INSTALL_IN_PROGRESS(509), Correlation ID:
> d6a2578b-c58f-43be-b6ad-30a3a0a57a74, Call Stack: null, Custom ID: null,
> Custom Event ID: -1, Message: Installing Host Node. Retrieving installation
> logs to:
> '/var/log/ovirt-engine/host-deploy/ovirt-host-deploy-20180618112311-mrpl.kvm2-d6a2578b-c58f-43be-b6ad-30a3a0a57a74.log'.
>
> 2018-06-18 11:23:12,131+05 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74] EVENT_ID:
> VDS_INSTALL_IN_PROGRESS(509), Correlation ID:
> d6a2578b-c58f-43be-b6ad-30a3a0a57a74, Call Stack: null, Custom ID: null,
> Custom Event ID: -1, Message: Installing Host Node. Stage: Termination.
>
> 2018-06-18 11:23:12,193+05 INFO
> [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor)
> [] Connecting to mrpl.kvm2/172.31.1.32
>
> 2018-06-18 11:

[ovirt-devel] Re: [ovirt-users] PollVDSCommand Error: java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils

[Roy Golan]

On Tue, 26 Jun 2018 at 07:23 Deekshith  wrote:

> Hi team
>
> It was installed 1 year back , 10 days before we were not able to take the
> console and webadmin of the server, it was working only 10 minutes once
> manually restart the server, so I tried refreshing the engine (engine
> cleanup)but same issue ,so I upgraded my centos 7.2 to 7.4 then i got
> webadmin and console of the server ,now my first problem is resolved ...but
> host is not coming up
>
>
>
I recommend you do an engine-backup, clean up the os (yum update, ensure
proper ovirt repo for you version) and do engine-setup and restore.



>
>
> Regards
>
> Deekshith
>
> *From:* Greg Sheremeta [mailto:gsher...@redhat.com]
> *Sent:* 25 June 2018 06:49
> *To:* deeksh...@binaryindia.com
> *Cc:* Roy Golan; devel; users; allent...@gmail.com
>
>
> *Subject:* Re: [ovirt-users] PollVDSCommand Error:
> java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>
>
>
> Is this a fresh install or an upgrade to 4.1?
>
>
>
> On Mon, Jun 25, 2018 at 3:41 AM Deekshith 
> wrote:
>
> Dear team
>
> Engine version is 4.1 and I am able to take the console and webadmin from
> the browser. All the vm data is available in the host . But host is not
> coming up.
>
> I upgrade from the NET( YUM UPDATE) all the necessary packages downloaded
> .. let me know if any log files needed.
>
>
>
> Please help me to resolve the issue .
>
>
>
>  Regards
>
> Deekshith
>
>
>
>
>
> *From:* Greg Sheremeta [mailto:gsher...@redhat.com]
> *Sent:* 22 June 2018 03:22
> *To:* deeksh...@binaryindia.com
> *Cc:* Roy Golan; devel; users; allen_j...@mrpl.co.in
> *Subject:* Re: [ovirt-users] PollVDSCommand Error:
> java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>
>
>
> Is your engine functioning at all? I'm not sure if you're saying your
> entire engine doesn't work, or just host deploy doesn't work.
>
> What version of ovirt engine is this?
>
> How did you install -- fresh installation, upgrade? From source or rpm?
>
>
>
> Best wishes,
>
> Greg
>
>
>
>
>
> On Wed, Jun 20, 2018 at 12:35 AM Deekshith 
> wrote:
>
> Dear team
>
> Please find the attached server and host logs.. ovirt host
> unresponsive(down), unable to install node packages.
>
>
>
> Regards
>
> Deekshith
>
>
>
> *From:* Roy Golan [mailto:rgo...@redhat.com]
> *Sent:* 19 June 2018 06:57
> *To:* Greg Sheremeta
> *Cc:* devel; users; deeksh...@binaryindia.com; allen_j...@mrpl.co.in
> *Subject:* Re: [ovirt-users] PollVDSCommand Error:
> java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>
>
>
>
>
> On Tue, 19 Jun 2018 at 16:04 Greg Sheremeta  wrote:
>
> Sending to devel list.
>
>
>
> Anyone ever seen this before? It sounds like a bad installation if Java
> classes are missing / classloader issues are present.
>
>
>
> 2018-06-18 11:23:11,287+05 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74] EVENT_ID:
> VDS_INSTALL_IN_PROGRESS(509), Correlation ID:
> d6a2578b-c58f-43be-b6ad-30a3a0a57a74, Call Stack: null, Custom ID: null,
> Custom Event ID: -1, Message: Installing Host Node. Retrieving installation
> logs to:
> '/var/log/ovirt-engine/host-deploy/ovirt-host-deploy-20180618112311-mrpl.kvm2-d6a2578b-c58f-43be-b6ad-30a3a0a57a74.log'.
>
> 2018-06-18 11:23:12,131+05 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74] EVENT_ID:
> VDS_INSTALL_IN_PROGRESS(509), Correlation ID:
> d6a2578b-c58f-43be-b6ad-30a3a0a57a74, Call Stack: null, Custom ID: null,
> Custom Event ID: -1, Message: Installing Host Node. Stage: Termination.
>
> 2018-06-18 11:23:12,193+05 INFO
> [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor)
> [] Connecting to mrpl.kvm2/172.31.1.32
>
> 2018-06-18 11:23:12,206+05 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
> (org.ovirt.thread.pool-7-thread-47) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74]
> Error: java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>
> 2018-06-18 11:23:12,206+05 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
> (org.ovirt.thread.pool-7-thread-47) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74]
> Command 'PollVDSCommand(HostName = Node,
> VdsIdVDSCommandParametersBase:{runAsync='true',
> hostId='d862d5c8-c75e-42ee-867f-ca16a228c2ad'})' execution failed:
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/apache/commons/lang/StringUtils
>
> 

[ovirt-devel] Re: Deprecating direct RPM downloads from Jenkins

[Roy Golan]

On Tue, 19 Jun 2018 at 17:53 Barak Korren  wrote:

> On 19 June 2018 at 17:37, Michal Skrivanek 
> wrote:
>
>>
>>
>> On 19 Jun 2018, at 07:16, Barak Korren  wrote:
>>
>> Hi there,
>>
>>
>> TL;DR: Is your build/CI/other process consuming RPMs directly from
>> Jenkins? Could it be changed to consume from other available places?
>>
>>
>>
+Gal Ben Haim   fyi the lago doc page points to
jenkins for latest rpm downloads
https://lago.readthedocs.io/en/0.20/README.html


>> In STDCI V1 we supported obtaining of the latest CI build for a
>> particular project in a particular branch on a particular platform directly
>> from Jenkins, by using the "latestSuccessfulBuild" dynamic link that
>> Jenkins generates.
>>
>> This was possible in STDCI V1 because we had one-to-one correlation
>> between jenkins jobs and project/branch/platform combinations. That is no
>> longer the case in STDCI V2 where each project gets just two fixed jobs
>> that adjust themselves automatically to run needed functionality.
>>
>> We could implement some equivalent functionality in STDCI V2 by for e.g.
>> uploading builds to some predictable locations on an artifact server, but
>> that will take some non-trivial amount of work, so it leads us to the
>> question if this functionality is really needed.
>>
>>
>> does this affect the repo/rpms created as part of a “ci please build” run
>> in any way?
>>
>
> The URL for the RPM will be different but as long as you use the full
> job/build URL it will work. In short, no.
>
> This only affects you if you need some kind of a 'meta' URL to find the
> build from the lastest _merged_ commit.
>
>
>>
>>
>> There are a couple of alternatives locations to get recently built
>> packages from:
>> - The 'tested' repo which contains all the packages that passed CQ/OST
>> - The 'snapshot' repo which contains a nightly snapshot of 'tested'.
>>
>> So given the options above, if you have a build/CI/other process that
>> currently consumes builds from Jenkins, could it be changed to consume from
>> the other available locations?
>>
>> --
>> Barak Korren
>> RHV DevOps team , RHCE, RHCi
>> Red Hat EMEA
>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/A5LFDPPFWXTEEZLZFSBGZVJNEIP3H7HC/
>>
>>
>>
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GX6GRYIVJ2WE4WGBWFMTGPBT3E4SMTYB/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/UOA35ONXQJXZVBBETJVC7R3AVNDAMPOS/

[ovirt-devel] Re: Can't install latest master (OST) - due to deps failure

[Roy Golan]

On Thu, 21 Jun 2018 at 12:04 Yedidyah Bar David  wrote:

> 2018-06-21 11:47 GMT+03:00 Yaniv Kaul :
> >
> > Error: Package:
> >
> ovirt-host-deploy-java-1.8.0-0.0.master.20180620111438.git925eabd.el7.noarch
> > (alocalsync)
> >Requires: ovirt-host-deploy =
> > 1.8.0-0.0.master.20180620111438.git925eabd.el7
> >Available:
> > ovirt-host-deploy-1.8.0-0.0.master.20180531090832.git9811a30.el7.noarch
> > (alocalsync)
> >ovirt-host-deploy =
> > 1.8.0-0.0.master.20180531090832.git9811a30.el7
> >
>
>
I just now did yum update the bastion host but I keep getting the exact
same thing.


Is this an update, or a new install?
>
> Probably a result of:
>
> https://gerrit.ovirt.org/92348
>
> It did pass check-patch, which also installs:
>
> 15:28:40 + yum install -y
>
> /home/jenkins/workspace/ovirt-host-deploy_master_check-patch-el7-x86_64/ovirt-host-deploy/exported-artifacts/python2-ovirt-host-deploy-1.8.0-0.0.master.20180618152722.git925eabd.el7.noarch.rpm
>
> /home/jenkins/workspace/ovirt-host-deploy_master_check-patch-el7-x86_64/ovirt-host-deploy/exported-artifacts/ovirt-host-deploy-common-1.8.0-0.0.master.20180618152722.git925eabd.el7.noarch.rpm
>
> /home/jenkins/workspace/ovirt-host-deploy_master_check-patch-el7-x86_64/ovirt-host-deploy/exported-artifacts/ovirt-host-deploy-java-1.8.0-0.0.master.20180618152722.git925eabd.el7.noarch.rpm
>
> /home/jenkins/workspace/ovirt-host-deploy_master_check-patch-el7-x86_64/ovirt-host-deploy/exported-artifacts/ovirt-host-deploy-javadoc-1.8.0-0.0.master.20180618152722.git925eabd.el7.noarch.rpm
>
> But does not try to install only ovirt-host-deploy, or only
> ovirt-host-deploy-java, so we do not verify that dependencies work
> well.
>
> Adding Gal.
> --
> Didi
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/RB5AVPQ5VH3QEDAURYJAJ6NWQNYWMICJ/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/CWQ6DZPXZR2MOJE6GQ5AN2DZRAL2AHIX/

[ovirt-devel] Re: [ovirt-users] PollVDSCommand Error: java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils

[Roy Golan]

On Tue, 19 Jun 2018 at 16:04 Greg Sheremeta  wrote:

> Sending to devel list.
>
> Anyone ever seen this before? It sounds like a bad installation if Java
> classes are missing / classloader issues are present.
>
> 2018-06-18 11:23:11,287+05 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74] EVENT_ID:
> VDS_INSTALL_IN_PROGRESS(509), Correlation ID:
> d6a2578b-c58f-43be-b6ad-30a3a0a57a74, Call Stack: null, Custom ID: null,
> Custom Event ID: -1, Message: Installing Host Node. Retrieving installation
> logs to:
> '/var/log/ovirt-engine/host-deploy/ovirt-host-deploy-20180618112311-mrpl.kvm2-d6a2578b-c58f-43be-b6ad-30a3a0a57a74.log'.
> 2018-06-18 11:23:12,131+05 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74] EVENT_ID:
> VDS_INSTALL_IN_PROGRESS(509), Correlation ID:
> d6a2578b-c58f-43be-b6ad-30a3a0a57a74, Call Stack: null, Custom ID: null,
> Custom Event ID: -1, Message: Installing Host Node. Stage: Termination.
> 2018-06-18 11:23:12,193+05 INFO
> [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor)
> [] Connecting to mrpl.kvm2/172.31.1.32
> 2018-06-18 11:23:12,206+05 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
> (org.ovirt.thread.pool-7-thread-47) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74]
> Error: java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
> 2018-06-18 11:23:12,206+05 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
> (org.ovirt.thread.pool-7-thread-47) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74]
> Command 'PollVDSCommand(HostName = Node,
> VdsIdVDSCommandParametersBase:{runAsync='true',
> hostId='d862d5c8-c75e-42ee-867f-ca16a228c2ad'})' execution failed:
> java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError:
> org/apache/commons/lang/StringUtils
> 2018-06-18 11:23:12,707+05 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand]
> (org.ovirt.thread.pool-7-thread-47) [d6a2578b-c58f-43be-b6ad-30a3a0a57a74]
> Error: java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
>
>
Is that a regular installation and what version?
jdk version?
server.log engine.log


> On Tue, Jun 19, 2018 at 8:50 AM Deekshith 
> wrote:
>
>> Dear team
>>
>> Please find attached ovirt-engine log .
>>
>>
>>
>> Regards
>>
>> Deekshith
>>
>>
>>
>> *From:* Greg Sheremeta [mailto:gsher...@redhat.com]
>> *Sent:* 19 June 2018 05:53
>> *To:* deeksh...@binaryindia.com
>> *Cc:* users
>> *Subject:* Re: [ovirt-users] Unable to start Ovirt engine
>>
>>
>>
>> What does it say in the
>> /var/log/ovirt-engine/setup/ovirt-engine-setup-xx.log?
>>
>>
>>
>> On Sun, Jun 17, 2018 at 6:01 AM Deekshith 
>> wrote:
>>
>> Hi Team
>>
>> Please anyone help me to solve this issue.
>>
>>
>>
>>
>>
>>
>>
>> ___
>> Users mailing list -- us...@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/us...@ovirt.org/message/QPBXKHLK4NSU62Z3AWVR4QOGXKBCF7C3/
>>
>>
>>
>>
>> --
>>
>> *GREG SHEREMETA*
>>
>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>
>> Red Hat NA
>>
>> 
>>
>> gsher...@redhat.comIRC: gshereme
>>
>> 
>>
>>
>>
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
> ___
> Users mailing list -- us...@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/us...@ovirt.org/message/2AA4B5IPQL7O2BOMLTOC3U3KXPIJNQR2/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/CNB5GPCOWH6P3BAWBH2W3BZFVUWTQEXO/

[ovirt-devel] [ANN] introducing ovirt-openshift-extensions

[Roy Golan]

Hi all,

Running Openshift on oVirt seems more and more attractive and is starting
to get attention.
It is very easy to do so today without needing any special configuration,
however, to tighten the integration and to take advantage of the underlying
infra
provider(ovirt) we can do better. For example, oVirt can connect various
storage
providers, and serve disk space to containers[1][2]. Also, Openshift can
ask oVirt
for VMs and deploy them as master or application nodes for its usage,
without
making the administrator doing all that manually.

This project[1] is the home for the ovirt-flexvolume-driver and
ovirt-provisioner[3]
and merging ovirt-cloudprovider[4] is a work in progress.

The code under this repository is work-in-progress and moving quickly,
however,
it has automation (stdci v2 :)) and is working and does at least what you
observe in
the demo videos. Yet I highly appreciate if any of you that will try will
provide feedback
be that #ovirt channel/ mailing list or to report bugs directly in the Github
project page 

[1] https://github.com/oVirt/ovirt-openshift-extensions
[2] https://ovirt.org/blog/2018/02/your-container-volumes-served-by-ovirt/
[3] https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/
[4] https://github.com/rgolangh/ovirt-k8s-cloudprovider


Thanks,
Roy
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives:

Re: [ovirt-devel] [ovirt-users] ovirt-system-tests hackathon report

[Roy Golan]

I missed it :( indeed calendar invite to the list didn't work.

On Tue, 13 Mar 2018 at 21:58 Eyal Edri  wrote:

> On Tue, Mar 13, 2018 at 8:00 PM, Yaniv Kaul  wrote:
>
>>
>>
>> On Mar 13, 2018 6:27 PM, "Sandro Bonazzola"  wrote:
>>
>> 4 people accepted calendar invite:
>> - Devin A. Bougie
>> - Francesco Romani
>> - Jiri Belka
>> - suporte, logicworks
>>
>> 4 people tentatively accepted calendar invite:
>> - Amnon Maimon
>> - Andreas Bleischwitz
>> - Arnaud Lauriou
>> - Stephen Pesini
>>
>> 2 mailing lists accepted calendar invite: us...@ovirt.org,
>> devel@ovirt.org (don't ask me how) so I may have missed someone in above
>> list
>>
>>
>> 4 patches got merged:
>> Add check for host update to the 1st host.
>>  Merged Yaniv Kaul
>> 
>> ovirt-system-tests
>>  
>> master
>> (add_upgrade_check)
>> 
>>  4:10
>> PM
>> basic-suite-master: add vnic_profile_mappings to register vm
>>  Merged Eitan Raviv
>> 
>> ovirt-system-tests
>>  
>> master
>> (register-template-vnic-mapping)
>> 
>>  2:50
>> PM
>> Revert "ovirt-4.2: Skipping 002_bootstrap.update_default_cluster"
>>  Merged Eyal Edri
>> 
>> ovirt-system-tests
>> 
>> master
>> 
>>  11:36
>> AM
>> seperate 4.2 tests and utils from master 
>> Merged Eyal Edri
>> 
>> ovirt-system-tests
>> 
>> master
>> 
>>  11:35
>> AM
>>
>> 13 patches has been pushed / reviewed / rebased
>>
>> Add gdeploy to ovirt-4.2.repo 
>> Daniel Belenky
>> 
>> ovirt-system-tests
>> 
>> master
>> 
>>  4:53
>> PM
>> Cleanup of test code - next() replaced with any()
>> 
>> Martin Sivák
>> 
>> ovirt-system-tests
>> 
>> master
>> 
>>  4:51
>> PM
>> Add network queues custom property and use it in the vnic profile for VM0
>> 
>> Yaniv Kaul
>> 
>> ovirt-system-tests
>>  
>> master
>> (multi_queue_config)
>> 
>>  4:49
>> PM
>> new suite: he-basic-iscsi-suite-master 
>> Yuval Turgeman
>> 
>> ovirt-system-tests
>>  
>> master
>> (he-basic-iscsi-suite-master)
>> 
>>  4:47
>> PM
>> Collect host-deploy bundle from the engine
>> 
>> Yedidyah Bar David
>> 
>> ovirt-system-tests
>> 
>> master
>> 
>>  4:41
>> PM
>> network-suite-master: Make openstack_client_config fixture available to
>> all ...  Merge Conflict Marcin Mirecki
>> 
>> ovirt-system-tests
>> 
>> master
>> 

Re: [ovirt-devel] [ovirt-users] cloud-init not working on master/4.2?

[Roy Golan]

On Wed, 3 Jan 2018 at 08:41 Roy Golan <rgo...@redhat.com> wrote:

> On Wed, 3 Jan 2018 at 07:54 Barak Korren <bkor...@redhat.com> wrote:
>
>> On 2 January 2018 at 22:17, Roy Golan <rgo...@redhat.com> wrote:
>> >
>> >
>> > On Tue, 2 Jan 2018 at 14:10 Eitan Raviv <era...@redhat.com> wrote:
>> >>
>> >> Roy,
>> >> What do you mean  'ignored my password changes'?
>> >
>> >
>> > I set the root pwd of my VM using cloud-init but I wasn't able to login.
>>
>> Try to see if you can catch cloud-init doing its thing in the VM
>> console, you might see an error message there.
>>
>> It is the engine fault, it doesn't send the cloudinit details to vdsm.
> Still I'd be happy if someone could try it out on 4.2 or master.
>

WORKS on master.

>
> I suppose you'll need a serial console for that, as scrolling up in
>> SPICE/VNC is impossible.
>>
>>
>> --
>> Barak Korren
>> RHV DevOps team , RHCE, RHCi
>> Red Hat EMEA
>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] cloud-init not working on master/4.2?

[Roy Golan]

On Wed, 3 Jan 2018 at 07:54 Barak Korren <bkor...@redhat.com> wrote:

> On 2 January 2018 at 22:17, Roy Golan <rgo...@redhat.com> wrote:
> >
> >
> > On Tue, 2 Jan 2018 at 14:10 Eitan Raviv <era...@redhat.com> wrote:
> >>
> >> Roy,
> >> What do you mean  'ignored my password changes'?
> >
> >
> > I set the root pwd of my VM using cloud-init but I wasn't able to login.
>
> Try to see if you can catch cloud-init doing its thing in the VM
> console, you might see an error message there.
>
> It is the engine fault, it doesn't send the cloudinit details to vdsm.
Still I'd be happy if someone could try it out on 4.2 or master.

I suppose you'll need a serial console for that, as scrolling up in
> SPICE/VNC is impossible.
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] cloud-init not working on master/4.2?

[Roy Golan]

On Tue, 2 Jan 2018 at 14:10 Eitan Raviv <era...@redhat.com> wrote:

> Roy,
> What do you mean  'ignored my password changes'?
>

I set the root pwd of my VM using cloud-init but I wasn't able to login.

what is a flow that reproduces your problem?
>
> - Import Centos 7 base image from ovirt-glance as a template and create a
VM from it.
- Run-Once the VM, set root user/pass using cloud-init in the dialog.
- Try to login with your new user/pass

Even before the VM OS boots you can `virsh -r dumpxml ID | grep -i payload`


> On Tue, Jan 2, 2018 at 1:59 PM, Roy Golan <rgo...@redhat.com> wrote:
>
>> I had problems bootstrapping my glance images, cloud init seems to ignore
>> my password changes and then I realized I'm missing the cdrom in the domxml.
>>
>> To solve it I disabled the DomainXML feature(engine preparing the domxml,
>> not vdsm) and it started working.
>>
>> Before I open a bug can anyone try to reproduce on 4.2?
>>
>> The workaround with engine-config:
>>
>> echo DomainXML | engine-config -s DomainXML=false --cver=4.2 -p /dev/stdin
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Eitan Raviv
> IRC: erav (#ovirt #vdsm #devel #rhev-dev)
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [ovirt-users] cloud-init not working on master/4.2?

[Roy Golan]

I had problems bootstrapping my glance images, cloud init seems to ignore
my password changes and then I realized I'm missing the cdrom in the domxml.

To solve it I disabled the DomainXML feature(engine preparing the domxml,
not vdsm) and it started working.

Before I open a bug can anyone try to reproduce on 4.2?

The workaround with engine-config:

echo DomainXML | engine-config -s DomainXML=false --cver=4.2 -p /dev/stdin
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Health inspections questions

[Roy Golan]

On Sun, 17 Dec 2017 at 13:03 Guy Chen  wrote:

> Hi
>
>
>

>
> 2017-12-17 12:04:28,152+0200 ERROR (qgapoller/3) [virt.periodic.Operation]
>  >
> operation failed (periodic:215) Traceback (most recent call last): File
> "/usr/lib/python2.7/site-packages/vdsm/virt/periodic.py", line 213, in
> __call__ self._func() File
> "/usr/lib/python2.7/site-packages/vdsm/virt/qemuguestagent.py", line 200,
> in _cleanup vms = set([vm_id for vm_id, vm_obj in self._cif.getVMs()])
> ValueError: too many values to unpack
>

looks like _cif.getVMS() is returning more than just the vm_id, and vm_obj

vdsm | guest agent developers?
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] planned Jenkins restart

[Roy Golan]

Did you had a chance to tweak the GC settings too?

On Wed, Nov 22, 2017, 2:29 AM Evgheni Dereveanchin 
wrote:

> Maintenance completed, Jenkins is back up and running.
> The OS, Jenkins core and all plugins were updated this time:
> https://ovirt-jira.atlassian.net/browse/OVIRT-1760
>
> As always - if you see any issues please report them to Jira.
>
> Regards,
> Evgheni Dereveanchin
>
> On Wed, Nov 22, 2017 at 12:46 AM, Evgheni Dereveanchin <
> edere...@redhat.com> wrote:
>
>> Hi everyone,
>>
>> I'll be performing a planned Jenkins restart within the next hour.
>> No new jobs will be scheduled during this maintenance period.
>> I will inform you once it is over.
>>
>> Regards,
>> Evgheni Dereveanchin
>>
>
>
>
> --
> Regards,
> Evgheni Dereveanchin
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt CI now supports Fedora 27 and Fedora Rawhide

[Roy Golan]

On Sat, 18 Nov 2017 at 16:25 Roy Golan <rgo...@redhat.com> wrote:

>
>
> On Sun, Oct 15, 2017, 2:12 PM Barak Korren <bkor...@redhat.com> wrote:
>
>> Over the TLV shut-down we took the time to add support for using Fedora
>> 27 as well as Fedora Rawhide in the oVirt CI system.
>>
>> To use Fedora 27 just use 'fc27' as you would for other Fedora versions
>> in the CI YAML files and/or file extensions in the 'automation/' directory.
>>
>> Using Fedora rawhide is similar, you just use 'fcraw' to refer to it.
>>
>
>
> Wonderful, I'll take of ovirt-engine.
>

 https://gerrit.ovirt.org/84371 automation: Support Fedora 27


>> --
>> Barak Korren
>> RHV DevOps team , RHCE, RHCi
>> Red Hat EMEA
>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt CI now supports Fedora 27 and Fedora Rawhide

[Roy Golan]

On Sun, Oct 15, 2017, 2:12 PM Barak Korren  wrote:

> Over the TLV shut-down we took the time to add support for using Fedora 27
> as well as Fedora Rawhide in the oVirt CI system.
>
> To use Fedora 27 just use 'fc27' as you would for other Fedora versions in
> the CI YAML files and/or file extensions in the 'automation/' directory.
>
> Using Fedora rawhide is similar, you just use 'fcraw' to refer to it.
>


Wonderful, I'll take of ovirt-engine.

>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 16-11-2017 ] [ 002_bootstrap.add_dc ]

[Roy Golan]

this patch you mentioned fixes the problem. Those errors shouldn't occur now

On Thu, 16 Nov 2017 at 12:59 Eyal Edri  wrote:

> https://gerrit.ovirt.org/#/c/84231/ ?
>
> On Thu, Nov 16, 2017 at 12:57 PM, Martin Perina 
> wrote:
>
>>
>>
>> On Thu, Nov 16, 2017 at 11:43 AM, Eyal Edri  wrote:
>>
>>> Please give it highest priority, we can't let it fail into the weekend.
>>>
>>> On Thu, Nov 16, 2017 at 12:40 PM, Dafna Ron  wrote:
>>>
 Hi,

 we have a CQ failure in add_dc test. I can see at engine long that we
 have an issue with 'extension.aaa.jdbc.binding.api.AuthnExtension'

 I don't think that the patch reported was the actual cause of the
 failure. Yesterday we were failing on missing package ovirt-cockpit-sso
 which we added to our repos. and I think perhaps we now exposed an issue
 with sso support which was undiscovered before.


 *Link to suspected patches: *

 These are the reported patches:

 https://gerrit.ovirt.org/#/c/83790/

 https://gerrit.ovirt.org/#/c/83779/



 * Here is the original patch for the sso support:
 https://gerrit.ovirt.org/#/c/82997/ 
 Link to Job: *
 http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3877/
 

 http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3878/

 *Link to all logs:*


 *
 http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3877/artifact/
 
 http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3878/artifact/
 
 (Relevant) error snippet from the log:  *


 2017-11-15 16:50:07,115-05 INFO  
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (ServerService 
 Thread Pool -- 45) [] Loading extension 'internal-authn'
 2017-11-15 16:50:07,118-05 INFO  
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager] (ServerService 
 Thread Pool -- 45) [] Extension 'internal-authn' loaded
 2017-11-15 16:50:07,118-05 DEBUG 
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace."ovirt-engine-extension-aaa-jdbc".authn.internal-authn]
  (ServerService Thread Pool -- 45) [] Config BEGIN
 2017-11-15 16:50:07,118-05 DEBUG 
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace."ovirt-engine-extension-aaa-jdbc".authn.internal-authn]
  (ServerService Thread Pool -- 45) [] ovirt.engine.aaa.authn.profile.name: 
 internal
 2017-11-15 16:50:07,118-05 DEBUG 
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace."ovirt-engine-extension-aaa-jdbc".authn.internal-authn]
  (ServerService Thread Pool -- 45) [] ovirt.engine.extension.provides: 
 org.ovirt.engine.api.extensions.aaa.Authn
 2017-11-15 16:50:07,118-05 DEBUG 
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace."ovirt-engine-extension-aaa-jdbc".authn.internal-authn]
  (ServerService Thread Pool -- 45) [] 
 ovirt.engine.extension.binding.jbossmodule.class: 
 org.ovirt.engine.extension.aaa.jdbc.binding.api.AuthnExtension
 2017-11-15 16:50:07,118-05 DEBUG 
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace."ovirt-engine-extension-aaa-jdbc".authn.internal-authn]
  (ServerService Thread Pool -- 45) [] ovirt.engine.aaa.authn.authz.plugin: 
 internal-authz
 2017-11-15 16:50:07,118-05 DEBUG 
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace."ovirt-engine-extension-aaa-jdbc".authn.internal-authn]
  (ServerService Thread Pool -- 45) [] 
 ovirt.engine.extension.bindings.method: jbossmodule
 2017-11-15 16:50:07,118-05 DEBUG 
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace."ovirt-engine-extension-aaa-jdbc".authn.internal-authn]
  (ServerService Thread Pool -- 45) [] config.datasource.file: 
 /etc/ovirt-engine/aaa/internal.properties
 2017-11-15 16:50:07,118-05 DEBUG 
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace."ovirt-engine-extension-aaa-jdbc".authn.internal-authn]
  (ServerService Thread Pool -- 45) [] ovirt.engine.extension.name: 
 internal-authn
 2017-11-15 16:50:07,118-05 DEBUG 
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace."ovirt-engine-extension-aaa-jdbc".authn.internal-authn]
  (ServerService Thread Pool -- 45) [] 
 ovirt.engine.extension.binding.jbossmodule.module: 
 org.ovirt.engine.extension.aaa.jdbc
 2017-11-15 16:50:07,118-05 DEBUG 
 [org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace."ovirt-engine-extension-aaa-jdbc".authn.internal-authn]
  (ServerService Thread Pool -- 45) [] Config END
 

Re: [ovirt-devel] speed up engine development with SKIP_CHECKS

[Roy Golan]

On Sun, 12 Nov 2017 at 19:29 Greg Sheremeta  wrote:

> Hi,
>
> I've added a SKIP_CHECKS flag to the ovirt-engine build here [1]. Thanks
> to Roy for the idea [2].
>
> TL;DR: you'll save roughly 2 minutes 10 seconds per full compile with
> SKIP_CHECKS. You'll save more (3 min 10 sec) if you don't need a 'clean'.
> You'll save the most (about 3 min 20 sec) if you can skip rebuilding GWT.
>
> Here are some statistics (3 runs per command, for averages sake)
>
> My test machine is a
> Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
> 256GB Samsung SSD (old, using SATA)
> 32GB DDR3 @ 1333 MT/s
>
> ---
>
> fresh master checkout
>
> no clean, no gwt, skip checks:
>
> make install-dev PREFIX=/home/greg/ovirt-engine BUILD_GWT=0 SKIP_CHECKS=1
> 1:04.38 total
> 1:06.04 total
> 1:04.41 total
>
> same as above, but now change one non-GWT class in the utils project
>
> make install-dev PREFIX=/home/greg/ovirt-engine BUILD_GWT=0 SKIP_CHECKS=1
> 1:05.49 total
>
> Ok, pretend we recompiled and our utils class change had an error.
> Same as above, change the one non-GWT class in the utils project again,
> and use the resume (-pl) functionality:
>
> make install-dev PREFIX=/home/greg/ovirt-engine BUILD_GWT=0 SKIP_CHECKS=1
> EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:utils"
> 17.958 total  (yes, 18 seconds, obviously a world record for any engine
> build)
>
>
"-pl" is very useful mvn directive. It compiles only the *p*roject-*l*ist
supplied. hence "pl". Add "-am" (*a*lso *m*ake) when you want to compile
what utils depends on (like common) or "amd" (*a*lso *m*ake *d*ependents)
if you want to compile also projectd depends on utils (like vdsbroker)

[The resume piece is EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.ui:webadmin"
> -- I personally need to use this more often!]
>
> ---
>
> no clean, no gwt, run checks (but skip unit tests):
>
> make install-dev PREFIX=/home/greg/ovirt-engine BUILD_GWT=0 BUILD_UT=0
> 3:07.66 total
> 3:16.69 total
> 3:14.28 total
>
> clean, no gwt, skip checks:
>
> make clean install-dev PREFIX=/home/greg/ovirt-engine BUILD_GWT=0
> SKIP_CHECKS=1
>
> 4:17.74 total
> 4:15.76 total
> 4:13.90 total
>
> no clean, gwt (1 permutation for chrome), skip checks:
>
> make install-dev PREFIX=/home/greg/ovirt-engine BUILD_GWT=1
> SKIP_CHECKS=1 DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari"
>
> 4:25.63 total
> 4:26.71 total
> 4:30.69 total
>
> no clean, gwt (1 permutation for chrome), run checks but skip unit tests:
>
> make install-dev PREFIX=/home/greg/ovirt-engine BUILD_GWT=1 BUILD_UT=0
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=safari"
>
> 6:44.23 total
>
> And the whole enchilada [3] ... clean, gwt (1 permutation for chrome), run
> checks, run unit tests:
>
> 11:52.25 total ... wow :)
>
>
Nice one Greg!

Now can we have "make WHOLE_ENCHILADA=1" please? :)

>
> Hope this helps you have a faster change-compile-check cycle :)
>
> Best wishes,
> Greg
>
>
> [1] https://gerrit.ovirt.org/#/c/83961/
> [2] https://www.mail-archive.com/devel@ovirt.org/msg10377.html
> [3] https://idioms.thefreedictionary.com/whole+enchilada
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] gitreview support

[Roy Golan]

Merged to ovirt-engine and should be on imagio and some other projects as
well (nice one Nir!)

On Sun, 29 Oct 2017 at 14:34 Nir Soffer <nsof...@redhat.com> wrote:

> On Sun, Oct 29, 2017 at 2:04 PM Roy Golan <rgo...@redhat.com> wrote:
>
>> On Sun, 29 Oct 2017 at 13:54 Dan Kenigsberg <dan...@redhat.com> wrote:
>>
>>> On Sun, Oct 29, 2017 at 12:01 PM, Roy Golan <rgo...@redhat.com> wrote:
>>> > I sent a patch [1] to add gitreview file for zero git review setup.
>>> >
>>> > gitreview is a git command to for submitting branches for gerrit and
>>> can
>>> > help to ease submitting and reviewing. Checkout the Usage page:
>>> > https://docs.openstack.org/infra/git-review/usage.html
>>> >
>>> > [1]  https://gerrit.ovirt.org/83335
>>>
>>> Nice! Care to send a similar patch for Vdsm?
>>>
>>
>> https://gerrit.ovirt.org/83337
>>
>
> Thanks! merged.
>
>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] gitreview support

[Roy Golan]

On Sun, 29 Oct 2017 at 13:54 Dan Kenigsberg <dan...@redhat.com> wrote:

> On Sun, Oct 29, 2017 at 12:01 PM, Roy Golan <rgo...@redhat.com> wrote:
> > I sent a patch [1] to add gitreview file for zero git review setup.
> >
> > gitreview is a git command to for submitting branches for gerrit and can
> > help to ease submitting and reviewing. Checkout the Usage page:
> > https://docs.openstack.org/infra/git-review/usage.html
> >
> > [1]  https://gerrit.ovirt.org/83335
>
> Nice! Care to send a similar patch for Vdsm?
>

https://gerrit.ovirt.org/83337
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] gitreview support

[Roy Golan]

I sent a patch [1] to add gitreview file for zero git review setup.

gitreview is a git command to for submitting branches for gerrit and can
help to ease submitting and reviewing. Checkout the Usage page:
https://docs.openstack.org/infra/git-review/usage.html

[1]  https://gerrit.ovirt.org/83335
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Host installation failure - master

[Roy Golan]

On Mon, 23 Oct 2017 at 21:51 Martin Perina  wrote:

> On Mon, Oct 23, 2017 at 6:21 PM, Yaniv Kaul  wrote:
>
>> I'm failing to install hosts on o-s-t on Master.
>> What worries me is not that I'm failing (though it is a bit of a
>> surprise, perhaps something I've done?), but that there are no logs around
>> it.
>>
>
> ​Please see my response below, but which logs are you ​
> ​missing?
> ​
> ​
>
>>
>> /var/log/ovirt-engine/host-deploy is empty and so is
>> /var/log/ovirt-engine/ansible.
>>
>
> Logs for both part of host installation (host-deploy and ansible) are​
>
> ​in /var/log/ovirt-engine/host-deploy, but they are created once each part
> successfully started.
> ​
>
>>
>>
>> All I'm seeing:
>> Host lago-basic-suite-master-host-0 installation failed. Unexpected
>> connection termination.
>>
>> Server.log:
>> 2017-10-23 12:16:33,041-04 WARN
>> [org.apache.sshd.client.session.ClientSessionImpl]
>> (sshd-SshClient[346b54f3]-nio2-thread-2) Exception caught:
>> java.io.IOException: Connection timed out
>> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
>> [rt.jar:1.8.0_151]
>> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
>> [rt.jar:1.8.0_151]
>> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
>> [rt.jar:1.8.0_151]
>> at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.8.0_151]
>> at 
>> sun.nio.ch.UnixAsynchronousSocketChannelImpl.finishWrite(UnixAsynchronousSocketChannelImpl.java:582)
>> [rt.jar:1.8.0_151]
>> at 
>> sun.nio.ch.UnixAsynchronousSocketChannelImpl.finish(UnixAsynchronousSocketChannelImpl.java:190)
>> [rt.jar:1.8.0_151]
>> at 
>> sun.nio.ch.UnixAsynchronousSocketChannelImpl.onEvent(UnixAsynchronousSocketChannelImpl.java:213)
>> [rt.jar:1.8.0_151]
>> at sun.nio.ch.EPollPort$EventHandlerTask.run(EPollPort.java:293)
>> [rt.jar:1.8.0_151]
>> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151]
>>
>>
>> Engine.log:
>>
>> 2017-10-23 12:16:33,046-04 DEBUG
>> [org.ovirt.engine.core.uutils.ssh.SSHClient]
>> (EE-ManagedThreadFactory-engine-Thread-1) [83a00e1] Executed: 'umask 0077;
>> MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-X
>> X)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr
>> \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}"
>> -x &&  "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine DIALO
>> G/customization=bool:True'
>> 2017-10-23 12:16:33,056-04 ERROR
>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy) [83a00e1]
>> Error during deploy dialog
>>
>
> ​So this means that SSH connection to the host using which the host deploy
> should be started failed. The reason is above in server.log, that SSH
> connection timed out. This error appears even before host-deploy is
> executed, that's we don't have any host-deploy log created.
> ​
>
>
>> 2017-10-23 12:16:33,057-04 DEBUG
>> [org.ovirt.engine.core.uutils.ssh.SSHDialog]
>> (EE-ManagedThreadFactory-engine-Thread-1) [83a00e1] execute leave
>> 2017-10-23 12:16:33,057-04 ERROR
>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
>> (EE-ManagedThreadFactory-engine-Thread-1) [83a00e1] Error during host
>> lago-basic-suite-master-host-0 install
>> 2017-10-23 12:16:33,065-04 ERROR
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
>> (EE-ManagedThreadFactory-engine-Thread-1) [83a00e1] EVENT_ID:
>> VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during
>> installation of Host lago-basic-suite-master-host-0: Unexpected connection
>> termination.
>>
>
> ​Here is an ERROR event in audit_log for above issue.
>
> perhaps reposync was stalling the rpm installation/download and this
triggered the ssh timeout?

> ​
>
>
>> 2017-10-23 12:16:33,065-04 ERROR
>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
>> (EE-ManagedThreadFactory-engine-Thread-1) [83a00e1] Error during host
>> lago-basic-suite-master-host-0 install, preferring first exception:
>> Unexpected connection termination
>> 2017-10-23 12:16:33,065-04 ERROR
>> [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand]
>> (EE-ManagedThreadFactory-engine-Thread-1) [83a00e1] Host installation
>> failed for host 'c4138375-aa53-4c36-8907-306803ae4282',
>> 'lago-basic-suite-master-host-0': Unexpected connection termination
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] How to build a particular module of code

[Roy Golan]

On Thu, 19 Oct 2017 at 20:12 Greg Sheremeta <gsher...@redhat.com> wrote:

> Since I needed to do a bunch of ovirt-engine recompiles today and I'm
> disabling checks to make it go faster, I figured I'd share:
>
> make install-dev PREFIX=/home/greg/ovirt-engine
> DEV_EXTRA_BUILD_FLAGS="-Danimal.sniffer.skip -Dcheckstyle.skip
> -Dgwt.compiler.localWorkers=1"
> DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.cssResourceStyle=pretty
> -Dgwt.userAgent=safari" BUILD_UT=0 BUILD_GWT=1
>
> make install-dev -- note I left out "clean", so that speeds things up
>
>
Then this worth a new make rule for 'install-dev-quick' or similar that
will have all of those inside.  another option is to add a SKIP_CHECKS=1
that will achieve the same without extra rule:

  make install-dev SKIP_CHECKS=1


> -Danimal.sniffer.skip -- skips animal sniffer [1], which takes quite some
> time
>
> -Dcheckstyle.skip -- skips checkstyle, which also takes much time
>
> -Dgwt.cssResourceStyle=pretty -- doesn't completely obfuscate classes in
> GWT, which allows you to use Dev Tools to inspect elements and see exactly
> where they come from [example: 
> shows me I need to go right to the NetworkFilterParameterEditor class to
> mess with this widget, specifically the "wrapper" css style
>
> -Dgwt.userAgent=safari -- if building GWT, build only 1 permutation for
> Chrome/Safari
>
> -Dgwt.compiler.localWorkers=1 -- use 1 thread for compiling GWT. Since I
> only used Safari, it's not necessary to have this here on this particular
> compile run, but you'll want to use this when doing more than 1
> permutation/browser. It'll help prevent a crash during GWT compile, which,
> of course, is the ultimate time waster :)
>
> BUILD_UT=0 -- skip unit tests
>
> BUILD_GWT=1 -- if you don't need a GWT rebuild, change to 0 for a *huge*
> speedup :) [there must be a way to have that auto-detected ... hmm ...]
>
>


> ...
>
> Before pushing a final version of a patch, you should enable the checks
> and make sure they all pass. (They do run in CI, though.)
>
> Best wishes,
> Greg
>
>
> [1] http://www.mojohaus.org/animal-sniffer/
>
> On Tue, Oct 17, 2017 at 4:01 PM, shubham dubey <sdubey...@gmail.com>
> wrote:
>
>> Thanks,it worked.
>>
>> On Wed, Oct 18, 2017 at 1:24 AM, Roy Golan <rgo...@redhat.com> wrote:
>>
>>> The answer is in the pom.xml of uicommonweb, in its groupId:
>>>   grep parent -A 1 frontend/webadmin/modules/uicommonweb/pom.xml
>>>
>>> So change it to "-pl *org.ovirt.engine.ui*:uicommonweb"
>>>
>>>
>>>
>>> On Tue, 17 Oct 2017 at 21:54 shubham dubey <sdubey...@gmail.com> wrote:
>>>
>>>> Hi,
>>>> I have tried to build uicommonweb alone using
>>>> make install-dev PREFIX="$HOME/ovirt-engine" EXTRA_BUILD_FLAGS="-pl
>>>> org.ovirt.engine.core:uicommonweb"
>>>>
>>>> but getting error that
>>>> [ERROR] Could not find the selected project in the reactor:
>>>> org.ovirt.engine.core:uicommonweb
>>>>
>>>> Am I doing something wrong?
>>>>
>>>> On Tue, Oct 17, 2017 at 11:50 PM, shubham dubey <sdubey...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks,
>>>>> This is exactly what I needed:)
>>>>>
>>>>> On Tue, Oct 17, 2017 at 11:37 PM, Greg Sheremeta <gsher...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> I never do it, but
>>>>>>
>>>>>>
>>>>>> https://www.ovirt.org/develop/developer-guide/engine/engine-development-environment
>>>>>> has an example :
>>>>>>
>>>>>>
>>>>>> To rebuild a single artifact, for example utils:
>>>>>>
>>>>>>   make clean install-dev PREFIX=$HOME/ovirt-engine \
>>>>>>   EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:utils"
>>>>>>
>>>>>>
>>>>>> You can also disable animal sniffer, check style, unit tests, and GWT
>>>>>> to speed things up. Just make sure they actually run before you push :)
>>>>>>
>>>>>> Greg
>>>>>>
>>>>>> On Oct 17, 2017 1:56 PM, "shubham dubey" <sdubey...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I have a simple query.
>>>>>>>
>>>>>>> Whenever I do any change in my 

Re: [ovirt-devel] Cockpit oVirt support

[Roy Golan]

On Thu, 19 Oct 2017 at 14:02 Michal Skrivanek <michal.skriva...@redhat.com>
wrote:

>
> > On 18 Oct 2017, at 11:42, Roy Golan <rgo...@redhat.com> wrote:
> >
> >
> >
> > On Wed, 18 Oct 2017 at 10:25 Michal Skrivanek <
> michal.skriva...@redhat.com> wrote:
> > Hi all,
> > I’m happy to announce that we finally finished initial contribution of
> oVirt specific support into the Cockpit management platform
> > See below for more details
> >
> > There are only limited amount of operations you can do at the moment,
> but it may already be interesting for troubleshooting and simple admin
> actions where you don’t want to launch the full blown webadmin UI
> >
> > Worth noting that if you were ever intimidated by the complexity of the
> GWT UI of oVirt portals and it held you back from contributing, please take
> another look!
> >
> > Thanks,
> > michal
> >
> >
> > Congrats Michal, Marek and team, this is very nice! The unified look &
> feel is such a powerful thing (I didn't realize for a while that you left
> webadmin).
>
> and thanks to this[1] it’s going to be even more seamless when you click
> in Host view on Host Console button
>
>
+1
So why won't we integrate that as an optional tab using a ui plugin?

[1] https://github.com/mareklibra/ovirt-cockpit-sso
>
> >> Begin forwarded message:
> >>
> >> From: Marek Libra <mli...@redhat.com>
> >> Subject: Re: Cockpit 153 released
> >> Date: 17 October 2017 at 16:02:59 GMT+2
> >> To: Development discussion for the Cockpit Project <
> cockpit-de...@lists.fedorahosted.org>
> >> Reply-To: Development discussion for the Cockpit Project <
> cockpit-de...@lists.fedorahosted.org>
> >>
> >> Walk-through video for the new "oVirt Machines" page can be found here:
> https://youtu.be/5i-kshT6c5A
> >>
> >> On Tue, Oct 17, 2017 at 12:08 PM, Martin Pitt <mp...@redhat.com> wrote:
> >> http://cockpit-project.org/blog/cockpit-153.html
> >>
> >> Cockpit is the modern Linux admin interface. We release regularly. Here
> >> are the release notes from version 153.
> >>
> >>
> >> Add oVirt package
> >> -
> >>
> >> This version introduces the "oVirt Machines" page on Fedora for
> controlling
> >> oVirt virtual machine clusters.  This code was moved into Cockpit as it
> shares
> >> a lot of code with the existing "Machines" page, which manages virtual
> machines
> >> through libvirt.
> >>
> >> This feature is packaged in cockpit-ovirt and when installed it will
> replace
> >> the "Machines" page.
> >>
> >> Thanks to Marek Libra for working on this!
> >>
> >> Screenshot:
> >>
> >> http://cockpit-project.org/images/ovirt-overview.png
> >>
> >> Change: https://github.com/cockpit-project/cockpit/pull/7139
> >>
> >>
> >> Packaging cleanup
> >> -
> >>
> >> This release fixes a lot of small packaging issues that were spotted by
> >> rpmlint/lintian.
> >>
> >> Get it
> >> --
> >>
> >> You can get Cockpit here:
> >>
> >> http://cockpit-project.org/running.html
> >>
> >> Cockpit 153 is available in Fedora 27:
> >>
> >> https://bodhi.fedoraproject.org/updates/cockpit-153-1.fc27
> >>
> >> Or download the tarball here:
> >>
> >> https://github.com/cockpit-project/cockpit/releases/tag/153
> >>
> >>
> >> Take care,
> >>
> >> Martin Pitt
> >>
> >> ___
> >> cockpit-devel mailing list -- cockpit-de...@lists.fedorahosted.org
> >> To unsubscribe send an email to
> cockpit-devel-le...@lists.fedorahosted.org
> >>
> >>
> >>
> >>
> >> --
> >> MAREK LIBRA
> >> SENIOR SOFTWARE ENGINEER
> >> Red Hat Czech
> >>
> >> ___
> >> cockpit-devel mailing list -- cockpit-de...@lists.fedorahosted.org
> >> To unsubscribe send an email to
> cockpit-devel-le...@lists.fedorahosted.org
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Cockpit oVirt support

[Roy Golan]

On Wed, 18 Oct 2017 at 10:25 Michal Skrivanek 
wrote:

> Hi all,
> I’m happy to announce that we finally finished initial contribution of
> oVirt specific support into the Cockpit management platform
> See below for more details
>
> There are only limited amount of operations you can do at the moment, but
> it may already be interesting for troubleshooting and simple admin actions
> where you don’t want to launch the full blown webadmin UI
>
> Worth noting that if you were ever intimidated by the complexity of the
> GWT UI of oVirt portals and it held you back from contributing, please take
> another look!
>
> Thanks,
> michal
>
>
Congrats Michal, Marek and team, this is very nice! The unified look & feel
is such a powerful thing (I didn't realize for a while that you left
webadmin).

> Begin forwarded message:
>
> *From: *Marek Libra 
> *Subject: **Re: Cockpit 153 released*
> *Date: *17 October 2017 at 16:02:59 GMT+2
> *To: *Development discussion for the Cockpit Project <
> cockpit-de...@lists.fedorahosted.org>
> *Reply-To: *Development discussion for the Cockpit Project <
> cockpit-de...@lists.fedorahosted.org>
>
> Walk-through video for the new "oVirt Machines" page can be found here:
> https://youtu.be/5i-kshT6c5A
>
> On Tue, Oct 17, 2017 at 12:08 PM, Martin Pitt  wrote:
>
>> http://cockpit-project.org/blog/cockpit-153.html
>>
>> Cockpit is the modern Linux admin interface. We release regularly. Here
>> are the release notes from version 153.
>>
>>
>> Add oVirt package
>> -
>>
>> This version introduces the "oVirt Machines" page on Fedora for
>> controlling
>> oVirt virtual machine clusters.  This code was moved into Cockpit as it
>> shares
>> a lot of code with the existing "Machines" page, which manages virtual
>> machines
>> through libvirt.
>>
>> This feature is packaged in cockpit-ovirt and when installed it will
>> replace
>> the "Machines" page.
>>
>> Thanks to Marek Libra for working on this!
>>
>> Screenshot:
>>
>> http://cockpit-project.org/images/ovirt-overview.png
>>
>> Change: https://github.com/cockpit-project/cockpit/pull/7139
>>
>>
>> Packaging cleanup
>> -
>>
>> This release fixes a lot of small packaging issues that were spotted by
>> rpmlint/lintian.
>>
>> Get it
>> --
>>
>> You can get Cockpit here:
>>
>> http://cockpit-project.org/running.html
>>
>> Cockpit 153 is available in Fedora 27:
>>
>> https://bodhi.fedoraproject.org/updates/cockpit-153-1.fc27
>>
>> Or download the tarball here:
>>
>> https://github.com/cockpit-project/cockpit/releases/tag/153
>>
>>
>> Take care,
>>
>> Martin Pitt
>>
>> ___
>> cockpit-devel mailing list -- cockpit-de...@lists.fedorahosted.org
>> To unsubscribe send an email to
>> cockpit-devel-le...@lists.fedorahosted.org
>>
>>
>
>
> --
> Marek Libra
>
> senior software engineer
> Red Hat Czech
>
> 
> ___
> cockpit-devel mailing list -- cockpit-de...@lists.fedorahosted.org
> To unsubscribe send an email to cockpit-devel-le...@lists.fedorahosted.org
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] How to build a particular module of code

[Roy Golan]

The answer is in the pom.xml of uicommonweb, in its groupId:
  grep parent -A 1 frontend/webadmin/modules/uicommonweb/pom.xml

So change it to "-pl *org.ovirt.engine.ui*:uicommonweb"



On Tue, 17 Oct 2017 at 21:54 shubham dubey  wrote:

> Hi,
> I have tried to build uicommonweb alone using
> make install-dev PREFIX="$HOME/ovirt-engine" EXTRA_BUILD_FLAGS="-pl
> org.ovirt.engine.core:uicommonweb"
>
> but getting error that
> [ERROR] Could not find the selected project in the reactor:
> org.ovirt.engine.core:uicommonweb
>
> Am I doing something wrong?
>
> On Tue, Oct 17, 2017 at 11:50 PM, shubham dubey 
> wrote:
>
>> Thanks,
>> This is exactly what I needed:)
>>
>> On Tue, Oct 17, 2017 at 11:37 PM, Greg Sheremeta 
>> wrote:
>>
>>> I never do it, but
>>>
>>>
>>> https://www.ovirt.org/develop/developer-guide/engine/engine-development-environment
>>> has an example :
>>>
>>>
>>> To rebuild a single artifact, for example utils:
>>>
>>>   make clean install-dev PREFIX=$HOME/ovirt-engine \
>>>   EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:utils"
>>>
>>>
>>> You can also disable animal sniffer, check style, unit tests, and GWT to
>>> speed things up. Just make sure they actually run before you push :)
>>>
>>> Greg
>>>
>>> On Oct 17, 2017 1:56 PM, "shubham dubey"  wrote:
>>>
 Hi,
 I have a simple query.

 Whenever I do any change in my code I
 run "make install-dev PREFIX="$HOME/ovirt-engine"".
 But it takes a large time to compile.
 I think there is a way to compile only that part of code
 which I have changed. Like if I make changes in
 uicommonweb then, how I compile only that part?

 Thanks in advance.

 Shubham

 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel

>>>
>>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Heads up: post-merge STDCI triggering is coming to GitHub

[Roy Golan]

Congratulations and thumbs up for you and the team for the support - I
guess this is good news for our hub based projects.

On Sun, 1 Oct 2017 at 14:19 Barak Korren  wrote:

> Over the next few days we're going to review and merge a new patch [1]
> that will finally provide the capability to trigger STDCI jobs when PRs are
> merged in GitHub.
>
> Once this patch is merged, projects in GitHub that have the proper hook
> configured, can have 'check-merged' jobs be triggered for them when patches
> are merged (Please note that this is a different hook then the one that is
> used for triggering on PR events).
>
> Following this we will also review and merge a series of patches [2] which
> closes our GitHub functionality gap further by providing the ability to
> automatically build merged PRs or pushed commits and submit them to the
> change queue for OST testing and publishing.
>
> This essentially means that, once mentioned patches are merged, projects
> in GitHub will be able to fully participate in all the oVirt CI processes.
>
> Some aspects of the GitHub functionality are actually a little more
> advanced then what is currently available for Gerrit. It is not longer
> needed to specify complex YAML in the 'jenkins' repo. Instead, only a
> single line is needed to enable the functionality (We left this requirement
> because we don't want to blindly run jobs for everything that hits the
> webhook). Everything else, including target platforms and versions can no
> be specified via a simple YAML file in the project's own source repository.
>
> An example of this yaml file can be seen in the 'ovirt-ansible' project.
> We are working on further documentation and will update when its ready.
>
> [1]: https://gerrit.ovirt.org/c/81971/
> [2]:
> https://gerrit.ovirt.org/q/topic:%2522change-queue-github%2522+(status:open%20OR%20status:merged)
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Unable to start VMs

[Roy Golan]

On Mon, 25 Sep 2017 at 22:52 Alexander Wels <aw...@redhat.com> wrote:

> On Monday, September 25, 2017 3:50:56 PM EDT Roy Golan wrote:
> > So somewhere in the code somebody used the Arch and not the family. See
> the
> > enum getFamily() method
> >
>
> Yep, in particular line 23 of FeatureSupported.java.
>
> I meant the caller of the method on this line. Do you have it in the trace
so we can see who passed x86_64 as arch ?

> On Mon, 25 Sep 2017 at 22:31 Alexander Wels <aw...@redhat.com> wrote:
> > > On Monday, September 25, 2017 3:24:14 PM EDT Roy Golan wrote:
> > > > what JRE are you using? any change with that?
> > >
> > > So I just figured out the problem, and its really strange. It has
> nothing
> > > to
> > > do with the SSL as the stack trace is mentioning. I manually stepped
> > > through
> > > the code to see what was going on and it turns out it is failing in
> > > FeatureSupported.java in supportedInConfig call from hotPlugMemory.
> > >
> > > The Config.getValue(feature, version.getValue()) (version is 4.2)
> is
> > > returning a map containing x86=true and ppc=true. But then it compares
> > > this to
> > > ArchitectureType.name() it returns null, because .name() return
> x86_64. No
> > > it
> > > appears that sometime during the last few months we dropped the _64 in
> the
> > > ArchitectureType, or at least in the database.
> > >
> > > As soon as I added a vdc_options tha contains x86_64 value for that
> key it
> > > started working. Now I have checked with Greg who has a fresh database
> > > that he
> > > can start VMs no problem, and his database contains x86 instead of
> x86_64.
> > >
> > > > On Mon, 25 Sep 2017 at 21:12 Alexander Wels <aw...@redhat.com>
> wrote:
> > > > > Hi guys,
> > > > >
> > > > > I see to be having an issue starting VMs with the latest master.
> > >
> > > Whenever
> > >
> > > > > I
> > > > > try to start a VM I get null pointer exception. And the VM doesn't
> > >
> > > start.
> > >
> > > > > I
> > > > > have debugged the engine, and it appears that the null pointer
> happens
> > > > > after
> > > > > the engine tries to connect to the host. In the stack trace I see
> > > > > SSLPeerUnverifiedException, so it appears something went wrong
> with a
> > > > > certificate somewhere.
> > > > >
> > > > > I have put my hosts in maintaince and re-enrolled the certificate,
> but
> > > > > that
> > > > > doesn't appear to be helping at all. Any other place I need to
> look at
> > >
> > > to
> > >
> > > > > make
> > > > > sure the engine can talk to the hosts? This appears to have started
> > >
> > > after
> > >
> > > > > I
> > > > > upgraded Wildfly to 11, so it is possible it has something to do
> with
> > >
> > > that
> > >
> > > > > as
> > > > > well.
> > > > >
> > > > > Any help figuring this out would be appreciated.
> > > > >
> > > > > Alexander
> > > > > ___
> > > > > Devel mailing list
> > > > > Devel@ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Unable to start VMs

[Roy Golan]

So somewhere in the code somebody used the Arch and not the family. See the
enum getFamily() method


On Mon, 25 Sep 2017 at 22:31 Alexander Wels <aw...@redhat.com> wrote:

> On Monday, September 25, 2017 3:24:14 PM EDT Roy Golan wrote:
> > what JRE are you using? any change with that?
> >
>
> So I just figured out the problem, and its really strange. It has nothing
> to
> do with the SSL as the stack trace is mentioning. I manually stepped
> through
> the code to see what was going on and it turns out it is failing in
> FeatureSupported.java in supportedInConfig call from hotPlugMemory.
>
> The Config.getValue(feature, version.getValue()) (version is 4.2) is
> returning a map containing x86=true and ppc=true. But then it compares
> this to
> ArchitectureType.name() it returns null, because .name() return x86_64. No
> it
> appears that sometime during the last few months we dropped the _64 in the
> ArchitectureType, or at least in the database.
>
> As soon as I added a vdc_options tha contains x86_64 value for that key it
> started working. Now I have checked with Greg who has a fresh database
> that he
> can start VMs no problem, and his database contains x86 instead of x86_64.
>
> > On Mon, 25 Sep 2017 at 21:12 Alexander Wels <aw...@redhat.com> wrote:
> > > Hi guys,
> > >
> > > I see to be having an issue starting VMs with the latest master.
> Whenever
> > > I
> > > try to start a VM I get null pointer exception. And the VM doesn't
> start.
> > > I
> > > have debugged the engine, and it appears that the null pointer happens
> > > after
> > > the engine tries to connect to the host. In the stack trace I see
> > > SSLPeerUnverifiedException, so it appears something went wrong with a
> > > certificate somewhere.
> > >
> > > I have put my hosts in maintaince and re-enrolled the certificate, but
> > > that
> > > doesn't appear to be helping at all. Any other place I need to look at
> to
> > > make
> > > sure the engine can talk to the hosts? This appears to have started
> after
> > > I
> > > upgraded Wildfly to 11, so it is possible it has something to do with
> that
> > > as
> > > well.
> > >
> > > Any help figuring this out would be appreciated.
> > >
> > > Alexander
> > > ___
> > > Devel mailing list
> > > Devel@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Unable to start VMs

[Roy Golan]

what JRE are you using? any change with that?

On Mon, 25 Sep 2017 at 21:12 Alexander Wels  wrote:

> Hi guys,
>
> I see to be having an issue starting VMs with the latest master. Whenever I
> try to start a VM I get null pointer exception. And the VM doesn't start. I
> have debugged the engine, and it appears that the null pointer happens
> after
> the engine tries to connect to the host. In the stack trace I see
> SSLPeerUnverifiedException, so it appears something went wrong with a
> certificate somewhere.
>
> I have put my hosts in maintaince and re-enrolled the certificate, but that
> doesn't appear to be helping at all. Any other place I need to look at to
> make
> sure the engine can talk to the hosts? This appears to have started after I
> upgraded Wildfly to 11, so it is possible it has something to do with that
> as
> well.
>
> Any help figuring this out would be appreciated.
>
> Alexander
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Why do we recommend to send a patch initially as draft?

[Roy Golan]

On Tue, 19 Sep 2017 at 08:26 Eyal Edri <ee...@redhat.com> wrote:

>
>
> On Sep 19, 2017 01:22, "Greg Sheremeta" <gsher...@redhat.com> wrote:
>
> On Mon, Sep 18, 2017 at 3:42 PM, Roy Golan <rgo...@redhat.com> wrote:
>
>>
>> On Mon, 18 Sep 2017 at 22:30 Yaniv Kaul <yk...@redhat.com> wrote:
>>
>>> Here[1]:
>>> "Anyone can send a patch
>>>
>>
> That's no longer true. We have a whitelist. [2][3]
>
>
> Small correction, anyone can send a patch, only people from the whitelist
> can trigger CI jobs on it, for reasons discussed before, mostly security
> related.
>
>
>
>> Initially a patch should be sent as draft"
>>>
>>
> I think we should edit that to be more along the lines of "consider
> initially posting as a draft" with guidelines to assist the decision.
>
>
>> A draft is hidden from the public, why is it better to send as such?
>>>
>>
> I've sent draft patches for 2 reasons.
> 1. I made progress on something and want to preserve it, but it's so WIP
> that I wouldn't want anyone to see it. That might be because it could
> confuse people, or it might be that the code is a prototype and/or so
> terrible that I'd be embarrassed if anyone saw it :D Lately I'm more likely
> to 'git format-patch | gdrive upload -' if it's something in this category.
> 2. I don't want to waste CI resources on something. Sometimes related to 1.
>
>
>> I see few advantages and they all drawn from the assumption the initial
>> patchset is always some sort of work in progress in really most of the
>> cases:
>> 1. It doesn't invoke automation and waste resources. First the developer
>> should run it and be passed the checkstyle/pep/other errors locally.
>> 2. Default reviewers feature hopefully will put the reviewers in place
>> automatically so it not hidden.
>>
>
> Hmm, I believe the "hopefully" doesn't work. A few weeks ago I got a
> notification that I had a draft to look at [because I was a default
> reviewer], but when I followed the link, I received a "not found" error.
>
> By 'hopefully' I mean I hope people who care about certain areas stepped
forward to be listed as default reviewers.

About the draft 'not found' - If you get that all the time I think this is
a bug.

Best wishes,
> Greg
>
> [2] http://lists.ovirt.org/pipermail/devel/2017-February/029633.html
> [3] https://ovirt-jira.atlassian.net/browse/OVIRT-1154
>
>
>> 3. After the patch is bit more mature it is worth publishing to get more
>> reviews. Half baked or controversial patches may be costly to review. After
>> they are published the reviewer can expect higher quality and can estimate
>> better the effort in review
>>
>> IMHO we don't use this practice enough.
>>
>> TIA,
>>> Y.
>>>
>>> [1] https://www.ovirt.org/develop/dev-process/working-with-gerrit/
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Why do we recommend to send a patch initially as draft?

[Roy Golan]

On Mon, 18 Sep 2017 at 22:30 Yaniv Kaul  wrote:

> Here[1]:
> "Anyone can send a patch
> Initially a patch should be sent as draft"
>
> A draft is hidden from the public, why is it better to send as such?
>

I see few advantages and they all drawn from the assumption the initial
patchset is always some sort of work in progress in really most of the
cases:
1. It doesn't invoke automation and waste resources. First the developer
should run it and be passed the checkstyle/pep/other errors locally.
2. Default reviewers feature hopefully will put the reviewers in place
automatically so it not hidden.
3. After the patch is bit more mature it is worth publishing to get more
reviews. Half baked or controversial patches may be costly to review. After
they are published the reviewer can expect higher quality and can estimate
better the effort in review

IMHO we don't use this practice enough.

TIA,
> Y.
>
> [1] https://www.ovirt.org/develop/dev-process/working-with-gerrit/
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-07 ] [import_template_from_glance]

[Roy Golan]

Both the fix and the Network patch for MacPool are merged.

On Tue, 12 Sep 2017 at 00:15 Roy Golan <rgo...@redhat.com> wrote:

> On Mon, 11 Sep 2017 at 23:41 Dan Kenigsberg <dan...@redhat.com> wrote:
>
>> On Mon, Sep 11, 2017 at 10:47 PM, Roy Golan <rgo...@redhat.com> wrote:
>> >
>> >
>> > On Mon, 11 Sep 2017 at 22:34 Allon Mureinik <amure...@redhat.com>
>> wrote:
>> >>
>> >> That was more a less the my guess from the brief look I took at the
>> >> stacktrace.
>> >>
>> >> I don't want to +2 a patch in the network area, but I'd suggest merging
>> >> this patch (which seems right regardless of the recent failure), and
>> see if
>> >> it solves the OST issue.
>> >>
>> > OST will run with the network patch reverted, so I need to bring it
>> into the
>> > Q again (revert the reverted :))
>>
>> Even I can do that. I've rebase your patches on top of current master,
>> and reintroduced Mucha's patch (https://gerrit.ovirt.org/#/c/81639/).
>> If OST passes, I'll ask you to backport your injection fixes - we need
>> to solve the MAC collision bug in ovirt-4.1, too.
>>
>> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/1129/ is green
>
>>
>> >
>> > On my side, with the MacPool changes it works, imported vms from
>> domains,
>> > started vm, basic editing.
>> >
>> > To add to that, CoCoAsyncTaskHelper is another @Singleton EJB, but if
>> I'm
>> > not mistaken here it should be available _before_ the Backend in order
>> to
>> > keep compensation running? in case we have a complete action that needs
>> to
>> > during compensation.
>> > Maybe this is a reason for MacPool to NOT depend on Backend, so
>> compensation
>> > would complete?
>> > Needs a second look.
>> >
>> >
>> >> On Mon, Sep 11, 2017 at 9:47 PM, Roy Golan <rgo...@redhat.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Mon, 11 Sep 2017 at 21:30 Roy Golan <rgo...@redhat.com> wrote:
>> >>>>
>> >>>> I think I solved it with https://gerrit.ovirt.org/#/c/81636/  so the
>> >>>> revert can be reverted. +Martin Mucha want to test it? It is working
>> on my
>> >>>> end.
>> >>>>
>> >>> sorry its this https://gerrit.ovirt.org/c/81637/2
>> >>>>
>> >>>>
>> >>>> On Mon, 11 Sep 2017 at 18:41 Dan Kenigsberg <dan...@redhat.com>
>> wrote:
>> >>>>>
>> >>>>> On Mon, Sep 11, 2017 at 4:46 PM, Dusan Fodor <dfo...@redhat.com>
>> wrote:
>> >>>>> >
>> >>>>> > Hello all,
>> >>>>> > this same error still causes OST to fail.
>> >>>>> >
>> >>>>>
>> >>>>> We are aware of it, but do not understand it at all.
>> >>>>>
>> >>>>> Anyway, a revert is proposed and
>> https://gerrit.ovirt.org/#/c/81618/
>> >>>>> would be merged once approved by CI.
>> >>>>>
>> >>>>> >
>> >>>>> > Jobs:
>> >>>>> >
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466
>> >>>>> >
>> >>>>> >
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471
>> >>>>> >
>> >>>>> > Logs:
>> >>>>> >
>> >>>>> >
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>> >>>>> >
>> >>>>> >
>> >>>>> > On Mon, Sep 11, 2017 at 1:22 PM, Eyal Edri <ee...@redhat.com>
>> wrote:
>> >>>>> >>
>> >>>>> >>
>> >>>>> >>
>> >>>>> >> On Mon, Sep 11, 2017 at 1:21 PM, D

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-07 ] [import_template_from_glance]

[Roy Golan]

On Mon, 11 Sep 2017 at 23:41 Dan Kenigsberg <dan...@redhat.com> wrote:

> On Mon, Sep 11, 2017 at 10:47 PM, Roy Golan <rgo...@redhat.com> wrote:
> >
> >
> > On Mon, 11 Sep 2017 at 22:34 Allon Mureinik <amure...@redhat.com> wrote:
> >>
> >> That was more a less the my guess from the brief look I took at the
> >> stacktrace.
> >>
> >> I don't want to +2 a patch in the network area, but I'd suggest merging
> >> this patch (which seems right regardless of the recent failure), and
> see if
> >> it solves the OST issue.
> >>
> > OST will run with the network patch reverted, so I need to bring it into
> the
> > Q again (revert the reverted :))
>
> Even I can do that. I've rebase your patches on top of current master,
> and reintroduced Mucha's patch (https://gerrit.ovirt.org/#/c/81639/).
> If OST passes, I'll ask you to backport your injection fixes - we need
> to solve the MAC collision bug in ovirt-4.1, too.
>
> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/1129/ is green

>
> >
> > On my side, with the MacPool changes it works, imported vms from domains,
> > started vm, basic editing.
> >
> > To add to that, CoCoAsyncTaskHelper is another @Singleton EJB, but if I'm
> > not mistaken here it should be available _before_ the Backend in order to
> > keep compensation running? in case we have a complete action that needs
> to
> > during compensation.
> > Maybe this is a reason for MacPool to NOT depend on Backend, so
> compensation
> > would complete?
> > Needs a second look.
> >
> >
> >> On Mon, Sep 11, 2017 at 9:47 PM, Roy Golan <rgo...@redhat.com> wrote:
> >>>
> >>>
> >>>
> >>> On Mon, 11 Sep 2017 at 21:30 Roy Golan <rgo...@redhat.com> wrote:
> >>>>
> >>>> I think I solved it with https://gerrit.ovirt.org/#/c/81636/  so the
> >>>> revert can be reverted. +Martin Mucha want to test it? It is working
> on my
> >>>> end.
> >>>>
> >>> sorry its this https://gerrit.ovirt.org/c/81637/2
> >>>>
> >>>>
> >>>> On Mon, 11 Sep 2017 at 18:41 Dan Kenigsberg <dan...@redhat.com>
> wrote:
> >>>>>
> >>>>> On Mon, Sep 11, 2017 at 4:46 PM, Dusan Fodor <dfo...@redhat.com>
> wrote:
> >>>>> >
> >>>>> > Hello all,
> >>>>> > this same error still causes OST to fail.
> >>>>> >
> >>>>>
> >>>>> We are aware of it, but do not understand it at all.
> >>>>>
> >>>>> Anyway, a revert is proposed and https://gerrit.ovirt.org/#/c/81618/
> >>>>> would be merged once approved by CI.
> >>>>>
> >>>>> >
> >>>>> > Jobs:
> >>>>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466
> >>>>> >
> >>>>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471
> >>>>> >
> >>>>> > Logs:
> >>>>> >
> >>>>> >
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
> >>>>> >
> >>>>> >
> >>>>> >
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
> >>>>> >
> >>>>> >
> >>>>> > On Mon, Sep 11, 2017 at 1:22 PM, Eyal Edri <ee...@redhat.com>
> wrote:
> >>>>> >>
> >>>>> >>
> >>>>> >>
> >>>>> >> On Mon, Sep 11, 2017 at 1:21 PM, Dan Kenigsberg <
> dan...@redhat.com>
> >>>>> >> wrote:
> >>>>> >>>
> >>>>> >>> On Mon, Sep 11, 2017 at 8:59 AM, Dan Kenigsberg <
> dan...@redhat.com>
> >>>>> >>> wrote:
> >>>>> >>> > On Thu, Sep 7, 2017 at 6:12 PM, Evgheni Dereveanchin
> >>>>> >>> > <edere...@redhat.com> wrote:
> >>>>> >>> >> Test failed: [ import_template_from_glance ]
> >&g

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-07 ] [import_template_from_glance]

[Roy Golan]

On Mon, 11 Sep 2017 at 22:34 Allon Mureinik <amure...@redhat.com> wrote:

> That was more a less the my guess from the brief look I took at the
> stacktrace.
>
> I don't want to +2 a patch in the network area, but I'd suggest merging
> this patch (which seems right regardless of the recent failure), and see if
> it solves the OST issue.
>
> OST will run with the network patch reverted, so I need to bring it into
the Q again (revert the reverted :))

On my side, with the MacPool changes it works, imported vms from domains,
started vm, basic editing.

To add to that, CoCoAsyncTaskHelper is another @Singleton EJB, but if I'm
not mistaken here it should be available _before_ the Backend in order to
keep compensation running? in case we have a complete action that needs to
during compensation.
Maybe this is a reason for MacPool to NOT depend on Backend, so
compensation would complete?
Needs a second look.


On Mon, Sep 11, 2017 at 9:47 PM, Roy Golan <rgo...@redhat.com> wrote:
>
>>
>>
>> On Mon, 11 Sep 2017 at 21:30 Roy Golan <rgo...@redhat.com> wrote:
>>
>>> I think I solved it with https://gerrit.ovirt.org/#/c/81636/  so the
>>> revert can be reverted. +Martin Mucha <mmu...@redhat.com> want to test
>>> it? It is working on my end.
>>>
>>> sorry its this https://gerrit.ovirt.org/c/81637/2
>>
>>>
>>> On Mon, 11 Sep 2017 at 18:41 Dan Kenigsberg <dan...@redhat.com> wrote:
>>>
>>>> On Mon, Sep 11, 2017 at 4:46 PM, Dusan Fodor <dfo...@redhat.com> wrote:
>>>> >
>>>> > Hello all,
>>>> > this same error still causes OST to fail.
>>>> >
>>>>
>>>> We are aware of it, but do not understand it at all.
>>>>
>>>> Anyway, a revert is proposed and https://gerrit.ovirt.org/#/c/81618/
>>>> would be merged once approved by CI.
>>>>
>>>> >
>>>> > Jobs:
>>>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466
>>>> >
>>>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471
>>>> >
>>>> > Logs:
>>>> >
>>>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>>>> >
>>>> >
>>>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>>>> >
>>>> >
>>>> > On Mon, Sep 11, 2017 at 1:22 PM, Eyal Edri <ee...@redhat.com> wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Mon, Sep 11, 2017 at 1:21 PM, Dan Kenigsberg <dan...@redhat.com>
>>>> wrote:
>>>> >>>
>>>> >>> On Mon, Sep 11, 2017 at 8:59 AM, Dan Kenigsberg <dan...@redhat.com>
>>>> wrote:
>>>> >>> > On Thu, Sep 7, 2017 at 6:12 PM, Evgheni Dereveanchin
>>>> >>> > <edere...@redhat.com> wrote:
>>>> >>> >> Test failed: [ import_template_from_glance ]
>>>> >>> >>
>>>> >>> >> Link to suspected patches:
>>>> >>> >> https://gerrit.ovirt.org/#/c/80450/
>>>> >>> >
>>>> >>> > Martin, this is "core: when initializing MacPool also register in
>>>> it
>>>> >>> > nics in snapshots"
>>>> >>> > and the error seems somewhat related to it
>>>> >>>
>>>> >>> Gil, can you tell us which is the last Engine patch that passed
>>>> OST? I
>>>> >>> tried to build https://gerrit.ovirt.org/#/c/76309/ but I'm guessing
>>>> >>> that "ci please build" does not work on merged patches.
>>>> >>
>>>> >>
>>>> >> Not sure I follow, the latest working engine should be deployed to
>>>> tested repo,
>>>> >> So if you'll run the manual job w/o any custom repos it should work
>>>> ( if it doesn't, then it means something slipped in the tested repo and we
>>>> should investigate ).
>>>> >>
>>>> >> But anyhow, your 'ci please build' also 

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-07 ] [import_template_from_glance]

[Roy Golan]

On Mon, 11 Sep 2017 at 21:30 Roy Golan <rgo...@redhat.com> wrote:

> I think I solved it with https://gerrit.ovirt.org/#/c/81636/  so the
> revert can be reverted. +Martin Mucha <mmu...@redhat.com> want to test
> it? It is working on my end.
>
> sorry its this https://gerrit.ovirt.org/c/81637/2

>
> On Mon, 11 Sep 2017 at 18:41 Dan Kenigsberg <dan...@redhat.com> wrote:
>
>> On Mon, Sep 11, 2017 at 4:46 PM, Dusan Fodor <dfo...@redhat.com> wrote:
>> >
>> > Hello all,
>> > this same error still causes OST to fail.
>> >
>>
>> We are aware of it, but do not understand it at all.
>>
>> Anyway, a revert is proposed and https://gerrit.ovirt.org/#/c/81618/
>> would be merged once approved by CI.
>>
>> >
>> > Jobs:
>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466
>> >
>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471
>> >
>> > Logs:
>> >
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>> >
>> >
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>> >
>> >
>> > On Mon, Sep 11, 2017 at 1:22 PM, Eyal Edri <ee...@redhat.com> wrote:
>> >>
>> >>
>> >>
>> >> On Mon, Sep 11, 2017 at 1:21 PM, Dan Kenigsberg <dan...@redhat.com>
>> wrote:
>> >>>
>> >>> On Mon, Sep 11, 2017 at 8:59 AM, Dan Kenigsberg <dan...@redhat.com>
>> wrote:
>> >>> > On Thu, Sep 7, 2017 at 6:12 PM, Evgheni Dereveanchin
>> >>> > <edere...@redhat.com> wrote:
>> >>> >> Test failed: [ import_template_from_glance ]
>> >>> >>
>> >>> >> Link to suspected patches:
>> >>> >> https://gerrit.ovirt.org/#/c/80450/
>> >>> >
>> >>> > Martin, this is "core: when initializing MacPool also register in it
>> >>> > nics in snapshots"
>> >>> > and the error seems somewhat related to it
>> >>>
>> >>> Gil, can you tell us which is the last Engine patch that passed OST? I
>> >>> tried to build https://gerrit.ovirt.org/#/c/76309/ but I'm guessing
>> >>> that "ci please build" does not work on merged patches.
>> >>
>> >>
>> >> Not sure I follow, the latest working engine should be deployed to
>> tested repo,
>> >> So if you'll run the manual job w/o any custom repos it should work (
>> if it doesn't, then it means something slipped in the tested repo and we
>> should investigate ).
>> >>
>> >> But anyhow, your 'ci please build' also worked, and produced RPMs on
>> the job, so you can still try it:
>> >>
>> >> Patch Set 26:
>> >> Build Successful
>> >>
>> http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-on-demand-fc25-x86_64/377/
>> : SUCCESS
>> >>
>> http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-on-demand-el7-x86_64/428/
>> : SUCCESS
>> >>
>> >>
>> >>>
>> >>>
>> >>> >
>> >>> >>
>> >>> >> Link to Job:
>> >>> >>
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2397/
>> >>> >>
>> >>> >> Link to logs:
>> >>> >>
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2397/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>> >>> >>
>> >>> >> Error snippet from log:
>> >>> >>
>> >>> >> 
>> >>> >>
>> >>> >> 2017-09-07 08:21:48,657-04 INFO
>> >>> >> [org.ovirt.engine.core.bll.AddVmTemplateCommand]
>> >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-21) [74b41edb]
>> Lock Acquired
>> >>> >> to object
>> >>> >>
>> 'EngineLock:{exclusiveLocks='[2c2b56b5-cac6-469d-b0e0-97443

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-07 ] [import_template_from_glance]

[Roy Golan]

I think I solved it with https://gerrit.ovirt.org/#/c/81636/  so the revert
can be reverted. +Martin Mucha  want to test it? It is
working on my end.

On Mon, 11 Sep 2017 at 18:41 Dan Kenigsberg  wrote:

> On Mon, Sep 11, 2017 at 4:46 PM, Dusan Fodor  wrote:
> >
> > Hello all,
> > this same error still causes OST to fail.
> >
>
> We are aware of it, but do not understand it at all.
>
> Anyway, a revert is proposed and https://gerrit.ovirt.org/#/c/81618/
> would be merged once approved by CI.
>
> >
> > Jobs:
> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466
> >
> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471
> >
> > Logs:
> >
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
> >
> >
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
> >
> >
> > On Mon, Sep 11, 2017 at 1:22 PM, Eyal Edri  wrote:
> >>
> >>
> >>
> >> On Mon, Sep 11, 2017 at 1:21 PM, Dan Kenigsberg 
> wrote:
> >>>
> >>> On Mon, Sep 11, 2017 at 8:59 AM, Dan Kenigsberg 
> wrote:
> >>> > On Thu, Sep 7, 2017 at 6:12 PM, Evgheni Dereveanchin
> >>> >  wrote:
> >>> >> Test failed: [ import_template_from_glance ]
> >>> >>
> >>> >> Link to suspected patches:
> >>> >> https://gerrit.ovirt.org/#/c/80450/
> >>> >
> >>> > Martin, this is "core: when initializing MacPool also register in it
> >>> > nics in snapshots"
> >>> > and the error seems somewhat related to it
> >>>
> >>> Gil, can you tell us which is the last Engine patch that passed OST? I
> >>> tried to build https://gerrit.ovirt.org/#/c/76309/ but I'm guessing
> >>> that "ci please build" does not work on merged patches.
> >>
> >>
> >> Not sure I follow, the latest working engine should be deployed to
> tested repo,
> >> So if you'll run the manual job w/o any custom repos it should work (
> if it doesn't, then it means something slipped in the tested repo and we
> should investigate ).
> >>
> >> But anyhow, your 'ci please build' also worked, and produced RPMs on
> the job, so you can still try it:
> >>
> >> Patch Set 26:
> >> Build Successful
> >>
> http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-on-demand-fc25-x86_64/377/
> : SUCCESS
> >>
> http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-on-demand-el7-x86_64/428/
> : SUCCESS
> >>
> >>
> >>>
> >>>
> >>> >
> >>> >>
> >>> >> Link to Job:
> >>> >> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2397/
> >>> >>
> >>> >> Link to logs:
> >>> >>
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2397/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
> >>> >>
> >>> >> Error snippet from log:
> >>> >>
> >>> >> 
> >>> >>
> >>> >> 2017-09-07 08:21:48,657-04 INFO
> >>> >> [org.ovirt.engine.core.bll.AddVmTemplateCommand]
> >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-21) [74b41edb] Lock
> Acquired
> >>> >> to object
> >>> >>
> 'EngineLock:{exclusiveLocks='[2c2b56b5-cac6-469d-b0e0-9744309ca8c1=TEMPLATE,
> >>> >> CirrOS_0.3.5_for_x86_64_glance_template=TEMPLATE_NAME]',
> sharedLocks='[]'}'
> >>> >> 2017-09-07 08:21:48,675-04 INFO
> >>> >> [org.ovirt.engine.core.bll.AddVmTemplateCommand]
> >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-21) [74b41edb]
> Running
> >>> >> command: AddVmTemplateCommand internal: true. Entities affected :
> ID:
> >>> >> d279c4e9-09e7-4dd9-9eff-10b31ee2adfc Type: StoragePoolAction group
> >>> >> CREATE_TEMPLATE with role type USER
> >>> >> 2017-09-07 08:21:48,695-04 INFO
> >>> >>
> [org.ovirt.engine.core.bll.storage.disk.CreateAllTemplateDisksCommand]
> >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-21) [74b41edb]
> Running
> >>> >> command: CreateAllTemplateDisksCommand internal: true.
> >>> >> 2017-09-07 08:21:48,722-04 INFO
> >>> >> [org.ovirt.engine.core.utils.transaction.TransactionSupport]
> >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-21) [74b41edb]
> transaction
> >>> >> rolled back
> >>> >> 2017-09-07 08:21:48,722-04 ERROR
> >>> >> [org.ovirt.engine.core.bll.AddVmTemplateCommand]
> >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-21) [74b41edb]
> Command
> >>> >> 'org.ovirt.engine.core.bll.AddVmTemplateCommand' failed: null
> >>> >> 2017-09-07 08:21:48,722-04 ERROR
> >>> >> [org.ovirt.engine.core.bll.AddVmTemplateCommand]
> >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-21) [74b41edb]
> Exception:
> >>> >> java.lang.NullPointerException
> >>> >> at
> >>> >>
> 

Re: [ovirt-devel] can't create a VM on engine master

[Roy Golan]

https://gerrit.ovirt.org/#/c/81636/ should solve it. I made
MacPoolPerCluster @DependOn("Backend") which should make the config
available at init time

On Mon, 11 Sep 2017 at 21:08 Roy Golan <rgo...@redhat.com> wrote:

> Maybe the MacPoolPerCluster EJB bean is started before the Backed bean,
> probably a backfire of Wildfly 11 move
>
> I'll try to make a dependency and see if it helps
>
> On Mon, 11 Sep 2017 at 18:40 Benny Zlotnik <bzlot...@redhat.com> wrote:
>
>> This error can be observed in server.log:
>> 2017-09-11 18:37:03,268+03 ERROR
>> [org.jboss.as.controller.management-operation] (Controller Boot Thread)
>> WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" =>
>> "engine.ear")]) - failure description: {"WFLYCTL0080: Failed services" =>
>> {"jboss.deployment.subunit.\"engine.ear\".\"bll.jar\".component.MacPoolPerCluster.START"
>> => "java.lang.IllegalStateException: WFLYEE0042: Failed to construct
>> component instance
>> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to
>> construct component instance
>> Caused by: javax.ejb.EJBException:
>> org.jboss.weld.exceptions.WeldException: WELD-49: Unable to invoke
>> public void
>> org.ovirt.engine.core.bll.CpuFlagsManagerHandler.initDictionaries() on
>> org.ovirt.engine.core.bll.CpuFlagsManagerHandler@7f971888
>> Caused by: org.jboss.weld.exceptions.WeldException: WELD-49:
>> Unable to invoke public void
>> org.ovirt.engine.core.bll.CpuFlagsManagerHandler.initDictionaries() on
>> org.ovirt.engine.core.bll.CpuFlagsManagerHandler@7f971888
>> Caused by: java.lang.reflect.InvocationTargetException
>> Caused by: java.lang.NullPointerException"}}
>>
>>
>> On Mon, Sep 11, 2017 at 6:11 PM, Benny Zlotnik <bzlot...@redhat.com>
>> wrote:
>>
>>> Yes, reverting this patch[1] helped (there's a discussion about OST
>>> failing)
>>>
>>> [1] - https://gerrit.ovirt.org/#/c/80450/
>>>
>>> On Mon, Sep 11, 2017 at 6:05 PM, Greg Sheremeta <gsher...@redhat.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> With a fresh engine (new path and new db) and a fresh f24 4.1 host, I'm
>>>> unable to add a VM either via the UI or REST API. Both hang, and I see no
>>>> helpful logs. Engine log just says it's running the command, and then
>>>> nothing. I don't see anything in vdsm.log that suggests the command came
>>>> through, so I think it's a problem in engine. Logs attached.
>>>>
>>>> Anyone else seeing this?
>>>>
>>>> Greg
>>>>
>>>> --
>>>>
>>>> GREG SHEREMETA
>>>>
>>>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>>>>
>>>> Red Hat
>>>>
>>>> <https://www.redhat.com/>
>>>>
>>>> gsher...@redhat.comIRC: gshereme
>>>> <https://red.ht/sig>
>>>>
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] how to print api method name and params in ovirt

[Roy Golan]

This might help you *Bug 1479301*
 - [RFE] Add elapsed
times of operations to the engine.log



On Tue, 5 Sep 2017 at 06:29 pengyixiang  wrote:

> hello, everyone!
> We need to customed ovirt, and now I need to know which api been
> called and transport's params after button been pushed in engine, I try to
> add logs like this in vdsm:
>
>  455 @api.method
>  456 def hotplugDisk(self, params):
>  457 syslog.syslog("---in VM hotplugDisk")
>  458 syslog.syslog("params:%s" % (params))
>  459 try:
>  460 utils.validateMinimalKeySet(params, ('vmId', 'drive'))
>  461 except ValueError:
>  462 self.log.error('Missing one of required parameters: vmId,
> drive')
>  463 return {'status': {'code':
> errCode['MissParam']['status']['code'],
>  464'message': 'Missing one of required '
>  465   'parameters: vmId, drive'}}
>  466 return self.vm.hotplugDisk(params)
>
> but the number of api method is too much,  where should I add is better to
> print called api method name and params?
>
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Slack channel

[Roy Golan]

On Mon, 4 Sep 2017 at 11:14 Artyom Lukianov  wrote:

> Like an alternative to Slack or gitter, you can run ZNC
>  server on some VM, that will save all messages
> for you.
>
> Right, still it is an IRC technology, and every user must set it up in
order to keep their presence (which you get out-of-the-box from
above-mentioned). Not everyone can/will do it.


> On Thu, Aug 24, 2017 at 5:31 AM, Marc Young <3vilpeng...@gmail.com> wrote:
>
>> Is there hope for slack over IRC?
>>
>> The problem with IRC is all the connect/disconnect chatter (and offline
>> being a black hole)
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Slack channel

[Roy Golan]

On Sun, 3 Sep 2017 at 17:11 Dan Kenigsberg <dan...@redhat.com> wrote:

> Last time I checked, slack was not ready for real use. It lost my
> confidence when it decided to hide my two weeks old chat because my group
> account used up all its free resources.
> That's closed-source mentality at its worst.
>
>
Slacks unpaid gives keeps the team's recent 10k messages, so I'm not sure
what went wrong there.

What's your opinion about other suggestions?

On Sep 3, 2017 16:09, "Roy Golan" <rgo...@redhat.com> wrote:
>
> I think SLA uses is mostly and it works well for them but there isn't much
> presence of all other teams on slack.
>
> Opening the discussion here, I think we need to give our community a push
> here, and modernize the communication our channel. Lets consider:
> - slack
> - gitter
> - self hosted service
>
> Slack experience is good, but again, wasn't adopted much further by ovirt.
> Some folks prefer other OS solution.
>
> I think gitter plays nice for communities and uses your github identity so
> its open for everyone. Slack is bit different in the approach. But I don't
> have experience with gitter at all so help out here people who do.
>
> Self hosted service, like RocketChat, means $$$ and time, and is less
> visible on the internet but has other advantages of course.
>
>
> Sandro, Eyal maybe you already have something up your sleeve?
>
>
> On Thu, 24 Aug 2017 at 16:00 Eyal Edri <ee...@redhat.com> wrote:
>
>> Marc,
>> I just sent you an invitation, see if you can signup.
>>
>> On Thu, Aug 24, 2017 at 3:53 PM, Eyal Edri <ee...@redhat.com> wrote:
>>
>>> I think Roy is mostly using it, so maybe he can update the settings.
>>>
>>> On Thu, Aug 24, 2017 at 3:48 PM, Marc Young <3vilpeng...@gmail.com>
>>> wrote:
>>>
>>>> That slack team requires either an invite or an `@redhat.com` email to
>>>> sign up
>>>>
>>>> On Wed, Aug 23, 2017 at 11:58 PM, Yaniv Kaul <yk...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Aug 24, 2017 at 6:03 AM, Greg Sheremeta <gsher...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Some of the teams have dedicated slack channels. We don't have a
>>>>>> global ovirt team one that I know of.
>>>>>>
>>>>>
>>>>> There's https://ovirt.slack.com/ - but I'm not sure how used it is.
>>>>> Y.
>>>>>
>>>>>
>>>>>>
>>>>>> You can disable connect / disconnect chatter with a setting in
>>>>>> hexchat. And you can catch what you missed by using an irc proxy.
>>>>>>
>>>>>> Full disclosure : I love slack and would love to see us fully cut
>>>>>> over.
>>>>>>
>>>>>> Greg Sheremeta, MBA
>>>>>> Sr. Software Engineer
>>>>>> Red Hat, Inc.
>>>>>> gsher...@redhat.com
>>>>>>
>>>>>> On Aug 23, 2017 10:31 PM, "Marc Young" <3vilpeng...@gmail.com> wrote:
>>>>>>
>>>>>> Is there hope for slack over IRC?
>>>>>>
>>>>>> The problem with IRC is all the connect/disconnect chatter (and
>>>>>> offline being a black hole)
>>>>>>
>>>>>> ___
>>>>>> Devel mailing list
>>>>>> Devel@ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>>
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> Devel mailing list
>>>>>> Devel@ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Eyal edri
>>>
>>>
>>> ASSOCIATE MANAGER
>>>
>>> RHV DevOps
>>>
>>> EMEA VIRTUALIZATION R
>>>
>>>
>>> Red Hat EMEA <https://www.redhat.com/>
>>> <https://red.ht/sig> TRIED. TESTED. TRUSTED.
>>> <https://redhat.com/trusted>
>>> phone: +972-9-7692018 <+972%209-769-2018>
>>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>>
>>
>>
>>
>> --
>>
>> Eyal edri
>>
>>
>> ASSOCIATE MANAGER
>>
>> RHV DevOps
>>
>> EMEA VIRTUALIZATION R
>>
>>
>> Red Hat EMEA <https://www.redhat.com/>
>> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>> phone: +972-9-7692018 <+972%209-769-2018>
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Slack channel

[Roy Golan]

I think SLA uses is mostly and it works well for them but there isn't much
presence of all other teams on slack.

Opening the discussion here, I think we need to give our community a push
here, and modernize the communication our channel. Lets consider:
- slack
- gitter
- self hosted service

Slack experience is good, but again, wasn't adopted much further by ovirt.
Some folks prefer other OS solution.

I think gitter plays nice for communities and uses your github identity so
its open for everyone. Slack is bit different in the approach. But I don't
have experience with gitter at all so help out here people who do.

Self hosted service, like RocketChat, means $$$ and time, and is less
visible on the internet but has other advantages of course.


Sandro, Eyal maybe you already have something up your sleeve?


On Thu, 24 Aug 2017 at 16:00 Eyal Edri  wrote:

> Marc,
> I just sent you an invitation, see if you can signup.
>
> On Thu, Aug 24, 2017 at 3:53 PM, Eyal Edri  wrote:
>
>> I think Roy is mostly using it, so maybe he can update the settings.
>>
>> On Thu, Aug 24, 2017 at 3:48 PM, Marc Young <3vilpeng...@gmail.com>
>> wrote:
>>
>>> That slack team requires either an invite or an `@redhat.com` email to
>>> sign up
>>>
>>> On Wed, Aug 23, 2017 at 11:58 PM, Yaniv Kaul  wrote:
>>>


 On Thu, Aug 24, 2017 at 6:03 AM, Greg Sheremeta 
 wrote:

> Some of the teams have dedicated slack channels. We don't have a
> global ovirt team one that I know of.
>

 There's https://ovirt.slack.com/ - but I'm not sure how used it is.
 Y.


>
> You can disable connect / disconnect chatter with a setting in
> hexchat. And you can catch what you missed by using an irc proxy.
>
> Full disclosure : I love slack and would love to see us fully cut over.
>
> Greg Sheremeta, MBA
> Sr. Software Engineer
> Red Hat, Inc.
> gsher...@redhat.com
>
> On Aug 23, 2017 10:31 PM, "Marc Young" <3vilpeng...@gmail.com> wrote:
>
> Is there hope for slack over IRC?
>
> The problem with IRC is all the connect/disconnect chatter (and
> offline being a black hole)
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>


>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>>
>> Eyal edri
>>
>>
>> ASSOCIATE MANAGER
>>
>> RHV DevOps
>>
>> EMEA VIRTUALIZATION R
>>
>>
>> Red Hat EMEA 
>>  TRIED. TESTED. TRUSTED. 
>> phone: +972-9-7692018 <+972%209-769-2018>
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>
>
>
>
> --
>
> Eyal edri
>
>
> ASSOCIATE MANAGER
>
> RHV DevOps
>
> EMEA VIRTUALIZATION R
>
>
> Red Hat EMEA 
>  TRIED. TESTED. TRUSTED. 
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] planned Gerrit maintenance

[Roy Golan]

Some interesting features added, worth noting:
- Comments to email
- Change Assignee - Nice for workflow, the patch is done and now waits for
a reviewers? pass the stick. Can be used in more than one way I guess.
Worth discussions.
- new UI (not GWT, but not that beauty as well... probably will take time
to shape up)

https://www.gerritcodereview.com/releases/2.14.md#Release-Highlights

On Thu, 31 Aug 2017 at 01:48 Evgheni Dereveanchin 
wrote:

> The maintenance window is over.
> Gerrit was upgraded to version 2.14.3 and a full reindex was performed.
> The OS was updated to include all the latest security patches as well.
>
> If you hit any issues that may be caused by the upgrade
> please let me know or report them to Jira.
>
> On Wed, Aug 30, 2017 at 11:19 PM, Evgheni Dereveanchin <
> edere...@redhat.com> wrote:
>
>> Hi everyone,
>>
>> I will be performing updates on gerrit.ovirt.org during the next two
>> hours.
>> Within this period the Gerrit UI and Git repositories may be unavailable.
>>
>> I will follow up as soon as maintenance activities are over.
>>
>> --
>> Regards,
>> Evgheni Dereveanchin
>>
>
>
>
> --
> Regards,
> Evgheni Dereveanchin
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Authentication error are not helpful - " The redirection URI for client is not registered "

[Roy Golan]

When using OST you get an engine on isolated network, that in order to make
available you must tunnel. When tunnelling you end up with a URI with a
uncommon port or hostname that will result an error while authenticating:

URL: https://localhost:9000/ovirt-engine

This displays this error:

*" The redirection URI for client is not registered "
*See screenshot 

Can we expose the expected valid redirect urls? Is it used for something
else than obscurity?

If we can expose it then at least a message of the form would be better:

*  " Please make sure to connect to https://EXPECTED/URL " *

\R
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Roy Golan]

This is for 4.1 https://gerrit.ovirt.org/#/c/78916/ , track that, it should
be in.

On Tue, 8 Aug 2017 at 15:10 Martin Sivak <msi...@redhat.com> wrote:

> What stomp heartbeat? There is no such thing in the Python json rpc client.
>
> Martin
>
> On Tue, Aug 8, 2017 at 1:04 PM, Roy Golan <rgo...@redhat.com> wrote:
> > Why isn't the stomp heartbeat enough?
> >
> > On Tue, 8 Aug 2017 at 13:45 Martin Sivak <msi...@redhat.com> wrote:
> >>
> >> MOM and hosted engine use the ping verb to verify the connection is
> >> still OK. The RPC client did not have any reconnect logic in the past
> >> (and I think it still does not..).
> >>
> >> Martin
> >>
> >> On Tue, Aug 8, 2017 at 12:01 PM, Roy Golan <rgo...@redhat.com> wrote:
> >> > Petr, why do you need the ping verb? what are you after?
> >> >
> >> > On Tue, 8 Aug 2017 at 11:54 Martin Sivak <msi...@redhat.com> wrote:
> >> >>
> >> >> > The proposed solution is focused on making sure a command does one
> >> >> > thing
> >> >> > and
> >> >> > not two:
> >> >> > A ping that has no side effects and a "watchdog" mechanism to
> confirm
> >> >> > connectivity.
> >> >>
> >> >> This sounds as exactly the right solution right now.
> >> >>
> >> >> >>> Still someone could call conirmConnectivity, no?
> >> >>
> >> >> We do not protect any other endpoints that can cause the host to go
> >> >> wild (storage or even setupNetworks). I agree with Edward it is the
> >> >> responsibility of the caller to do the right thing. You need to be
> >> >> root or have the certificate to talk to VDSM anyway.
> >> >>
> >> >> Martin
> >> >>
> >> >> On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas <eh...@redhat.com>
> wrote:
> >> >> >
> >> >> >
> >> >> > On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer <nsof...@redhat.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan <rgo...@redhat.com>
> wrote:
> >> >> >>>
> >> >> >>> Still someone could call conirmConnectivity, no? so the state
> isn't
> >> >> >>> guarded from localhost tinkering anyhow. If you really need a
> >> >> >>> solution
> >> >> >>> you
> >> >> >>> can acuire a token for this operation by setupNetworks, and
> confirm
> >> >> >>> connectivity with this token passed back.
> >> >> >>>
> >> >> >>> I'm not sure about the severity of the problem here, I'll let
> other
> >> >> >>> reply, but I'm against this kind of solution.
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>> On Mon, 7 Aug 2017 at 15:32 Petr Horacek <phora...@redhat.com>
> >> >> >>> wrote:
> >> >> >>>>
> >> >> >>>> Hello,
> >> >> >>>>
> >> >> >>>> current VDSM ping verb has a problem - it confirms network
> >> >> >>>> connectivity as a side-effect. After Engine calls setupNetwork
> it
> >> >> >>>> pings VDSM host to confirm that external network connectivity is
> >> >> >>>> not
> >> >> >>>> broken. This prohibits other users to call ping from localhost
> >> >> >>>> since
> >> >> >>>> it would confirm connectivity even though networking could be
> >> >> >>>> broken.
> >> >> >>
> >> >> >>
> >> >> >> Vdsm can save the client ip setting up the network. Getting a ping
> >> >> >> from
> >> >> >> this
> >> >> >> client can confirm that the connectivity was restored. pings from
> >> >> >> other
> >> >> >> hosts
> >> >> >> can be ignored.
> >> >> >>
> >> >> >> The client address is available in a thread local variable
> >> >> >> (context.client_host)
> >> >> >> during all api calls. see vds

Re: [ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Roy Golan]

Why isn't the stomp heartbeat enough?

On Tue, 8 Aug 2017 at 13:45 Martin Sivak <msi...@redhat.com> wrote:

> MOM and hosted engine use the ping verb to verify the connection is
> still OK. The RPC client did not have any reconnect logic in the past
> (and I think it still does not..).
>
> Martin
>
> On Tue, Aug 8, 2017 at 12:01 PM, Roy Golan <rgo...@redhat.com> wrote:
> > Petr, why do you need the ping verb? what are you after?
> >
> > On Tue, 8 Aug 2017 at 11:54 Martin Sivak <msi...@redhat.com> wrote:
> >>
> >> > The proposed solution is focused on making sure a command does one
> thing
> >> > and
> >> > not two:
> >> > A ping that has no side effects and a "watchdog" mechanism to confirm
> >> > connectivity.
> >>
> >> This sounds as exactly the right solution right now.
> >>
> >> >>> Still someone could call conirmConnectivity, no?
> >>
> >> We do not protect any other endpoints that can cause the host to go
> >> wild (storage or even setupNetworks). I agree with Edward it is the
> >> responsibility of the caller to do the right thing. You need to be
> >> root or have the certificate to talk to VDSM anyway.
> >>
> >> Martin
> >>
> >> On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas <eh...@redhat.com> wrote:
> >> >
> >> >
> >> > On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer <nsof...@redhat.com>
> wrote:
> >> >>
> >> >> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan <rgo...@redhat.com> wrote:
> >> >>>
> >> >>> Still someone could call conirmConnectivity, no? so the state isn't
> >> >>> guarded from localhost tinkering anyhow. If you really need a
> solution
> >> >>> you
> >> >>> can acuire a token for this operation by setupNetworks, and confirm
> >> >>> connectivity with this token passed back.
> >> >>>
> >> >>> I'm not sure about the severity of the problem here, I'll let other
> >> >>> reply, but I'm against this kind of solution.
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Mon, 7 Aug 2017 at 15:32 Petr Horacek <phora...@redhat.com>
> wrote:
> >> >>>>
> >> >>>> Hello,
> >> >>>>
> >> >>>> current VDSM ping verb has a problem - it confirms network
> >> >>>> connectivity as a side-effect. After Engine calls setupNetwork it
> >> >>>> pings VDSM host to confirm that external network connectivity is
> not
> >> >>>> broken. This prohibits other users to call ping from localhost
> since
> >> >>>> it would confirm connectivity even though networking could be
> broken.
> >> >>
> >> >>
> >> >> Vdsm can save the client ip setting up the network. Getting a ping
> from
> >> >> this
> >> >> client can confirm that the connectivity was restored. pings from
> other
> >> >> hosts
> >> >> can be ignored.
> >> >>
> >> >> The client address is available in a thread local variable
> >> >> (context.client_host)
> >> >> during all api calls. see vdsm.common.api.context_string() for
> example
> >> >> usage.
> >> >>
> >> >> This infrastructure is available in 4.1.
> >> >
> >> >
> >> > The proposed solution is focused on making sure a command does one
> thing
> >> > and
> >> > not two:
> >> > A ping that has no side effects and a "watchdog" mechanism to confirm
> >> > connectivity.
> >> >
> >> > Does it make sense to confirm connectivity from localhost? In many
> cases
> >> > it
> >> > probably does not,
> >> > but there may be cases where it does make sense... it is not the
> >> > functionality to determine what
> >> > makes sense or not, it is the usage of it who has the responsibility
> to
> >> > use
> >> > it correctly.
> >> >
> >> >>
> >> >> Nir
> >> >>
> >> >>>>
> >> >>>>
> >> >>>> In order to fix this problem ping should be split to ping2 (which
> >> >>>> just
> >> >>>> returns Success with no side-effect) and confirmConnectivity.
> Change
> >> >>>> on VDSM side was introduced in [1], we still need to expose new
> verbs
> >> >>>> in Engine.
> >> >>>>
> >> >>>> Regards,
> >> >>>> Petr
> >> >>>>
> >> >>>> [1] https://gerrit.ovirt.org/#/c/80119/
> >> >>>> ___
> >> >>>> Devel mailing list
> >> >>>> Devel@ovirt.org
> >> >>>> http://lists.ovirt.org/mailman/listinfo/devel
> >> >>>
> >> >>> ___
> >> >>> Devel mailing list
> >> >>> Devel@ovirt.org
> >> >>> http://lists.ovirt.org/mailman/listinfo/devel
> >> >>
> >> >>
> >> >> ___
> >> >> Devel mailing list
> >> >> Devel@ovirt.org
> >> >> http://lists.ovirt.org/mailman/listinfo/devel
> >> >
> >> >
> >> >
> >> > ___
> >> > Devel mailing list
> >> > Devel@ovirt.org
> >> > http://lists.ovirt.org/mailman/listinfo/devel
> >> ___
> >> Devel mailing list
> >> Devel@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Roy Golan]

Petr, why do you need the ping verb? what are you after?

On Tue, 8 Aug 2017 at 11:54 Martin Sivak <msi...@redhat.com> wrote:

> > The proposed solution is focused on making sure a command does one thing
> and
> > not two:
> > A ping that has no side effects and a "watchdog" mechanism to confirm
> > connectivity.
>
> This sounds as exactly the right solution right now.
>
> >>> Still someone could call conirmConnectivity, no?
>
> We do not protect any other endpoints that can cause the host to go
> wild (storage or even setupNetworks). I agree with Edward it is the
> responsibility of the caller to do the right thing. You need to be
> root or have the certificate to talk to VDSM anyway.
>
> Martin
>
> On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas <eh...@redhat.com> wrote:
> >
> >
> > On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer <nsof...@redhat.com> wrote:
> >>
> >> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan <rgo...@redhat.com> wrote:
> >>>
> >>> Still someone could call conirmConnectivity, no? so the state isn't
> >>> guarded from localhost tinkering anyhow. If you really need a solution
> you
> >>> can acuire a token for this operation by setupNetworks, and confirm
> >>> connectivity with this token passed back.
> >>>
> >>> I'm not sure about the severity of the problem here, I'll let other
> >>> reply, but I'm against this kind of solution.
> >>>
> >>>
> >>>
> >>> On Mon, 7 Aug 2017 at 15:32 Petr Horacek <phora...@redhat.com> wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>> current VDSM ping verb has a problem - it confirms network
> >>>> connectivity as a side-effect. After Engine calls setupNetwork it
> >>>> pings VDSM host to confirm that external network connectivity is not
> >>>> broken. This prohibits other users to call ping from localhost since
> >>>> it would confirm connectivity even though networking could be broken.
> >>
> >>
> >> Vdsm can save the client ip setting up the network. Getting a ping from
> >> this
> >> client can confirm that the connectivity was restored. pings from other
> >> hosts
> >> can be ignored.
> >>
> >> The client address is available in a thread local variable
> >> (context.client_host)
> >> during all api calls. see vdsm.common.api.context_string() for example
> >> usage.
> >>
> >> This infrastructure is available in 4.1.
> >
> >
> > The proposed solution is focused on making sure a command does one thing
> and
> > not two:
> > A ping that has no side effects and a "watchdog" mechanism to confirm
> > connectivity.
> >
> > Does it make sense to confirm connectivity from localhost? In many cases
> it
> > probably does not,
> > but there may be cases where it does make sense... it is not the
> > functionality to determine what
> > makes sense or not, it is the usage of it who has the responsibility to
> use
> > it correctly.
> >
> >>
> >> Nir
> >>
> >>>>
> >>>>
> >>>> In order to fix this problem ping should be split to ping2 (which just
> >>>> returns Success with no side-effect) and confirmConnectivity. Change
> >>>> on VDSM side was introduced in [1], we still need to expose new verbs
> >>>> in Engine.
> >>>>
> >>>> Regards,
> >>>> Petr
> >>>>
> >>>> [1] https://gerrit.ovirt.org/#/c/80119/
> >>>> ___
> >>>> Devel mailing list
> >>>> Devel@ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/devel
> >>>
> >>> ___
> >>> Devel mailing list
> >>> Devel@ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/devel
> >>
> >>
> >> ___
> >> Devel mailing list
> >> Devel@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Roy Golan]

Still someone could call conirmConnectivity, no? so the state isn't guarded
from localhost tinkering anyhow. If you really need a solution you can
acuire a token for this operation by setupNetworks, and confirm
connectivity with this token passed back.

I'm not sure about the severity of the problem here, I'll let other reply,
but I'm against this kind of solution.



On Mon, 7 Aug 2017 at 15:32 Petr Horacek  wrote:

> Hello,
>
> current VDSM ping verb has a problem - it confirms network
> connectivity as a side-effect. After Engine calls setupNetwork it
> pings VDSM host to confirm that external network connectivity is not
> broken. This prohibits other users to call ping from localhost since
> it would confirm connectivity even though networking could be broken.
>
> In order to fix this problem ping should be split to ping2 (which just
> returns Success with no side-effect) and confirmConnectivity. Change
> on VDSM side was introduced in [1], we still need to expose new verbs
> in Engine.
>
> Regards,
> Petr
>
> [1] https://gerrit.ovirt.org/#/c/80119/
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Nested virtualization on Fedora 26

[Roy Golan]

Jakub thanks for sharing this.

Tarek, Nelly, I believe you hit this as well lately.

On Tue, Jul 25, 2017, 6:15 PM Jakub Niedermertl  wrote:

> Hi all,
>
> in case someone else is also struggling with nested virtualization on
> Fedora 26, here is a bug [1] tracking the problem including a workaround.
>
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1474874
>
> Jakub
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] status update: consuming the BLOCK_THRESHOLD event from libvirt (rhbz#1181665)

[Roy Golan]

On Wed, Jul 19, 2017 at 12:46 PM Francesco Romani 
wrote:

> Hi all,
>
>
> With libvirt 3.2.0 and onwards, it seems we have now the tools to solve
> https://bugzilla.redhat.com/show_bug.cgi?id=1181665
>
> and eventually get rid of the disk polling we do. This change is
> expected to have huge impact on performance, so I'm working on it.
>
>
> I had plans for a comprehensive refactoring in this area, but looks like
> a solution backportable for 4.1.z is appealing, so I
>
> started with this first, saving the refactoring (which I still very much
> want) for later.
>
>
> So, quick summary: libvirt >= 3.2.0 allows to set a threshold to any
> node in the backing chain of each drive of a VM
>
> (
> https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainSetBlockThreshold
> ),
> and fire one event exactly once
>
> when that threshold is crossed. The event needs to be explicitely
> rearmed after.
>
> This is exactly what we need to get rid of polling in the steady state,
> so far so good.
>
>
> The problem is: we can't use this for some important flows we have, and
> which involve usage of disks not (yet) attached to a given VM.
>
>
>


> Possibly affected flows:
>
> - live storage migration:
>
>   we use flags = (libvirt.VIR_DOMAIN_BLOCK_COPY_SHALLOW |
>  libvirt.VIR_DOMAIN_BLOCK_COPY_REUSE_EXT |
>  VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB)
>
>   meaning that Vdsm is in charge of handling the volume
>
> - snapshots:
>
>   we use snapFlags = (libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT
> |
>  libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_NO_METADATA)
>
>
>   (same meaning as above)
>
> - live merge: should be OK (according to a glance at the source and a
> chat with Adam).
>
>
> So looks like we will need to bridge this gap.
>
>
> So we can still use the BLOCK_THRESHOLD event for steady state, and
> avoid polling in the vast majority of the cases.
>
> With "steady state" I mean that the VM is running, with no
> administration (snapshot, live merge, live storage migration...)
> operation in progress.
>
> I think it is fair to assume that VMs are in this state the vast
> majority of the time.
> For the very important cases on which we cannot depend on events, we can
> fall back to polling, but in a smarter way:
>
> instead of polling everything every 2s, let's just poll just the drives
> involved in the ongoing operations.
>
> Those should be far less of the total amount of drives, and for a far
> shorter time than today, so polling should be practical.
>
> Since the event fires once, we will need to rearm it only if the
> operation is ongoing, and only just before to start it (both conditions
> easy to check)
> We can disable the polling on completion, or on error. This per se is
> easy, but we will need a careful review of the flows, and perhaps some
> safety nets in place.
>
>
Consider fusing polling and events into a single pipeline of events so they
can be used together. If a poll triggers an event (with distinguished
origin)
then it all the handling is done in one place and it should be easy to stop
or start polling, or remove them totally.


> Anyway, should we miss to disable the polling, we will "just" have some
> overhead.
>
>

> On recovery, we will need to make sure to rearm all the relevant events,
> but  we can just plug in the recovery we must do already, so this should
> be easy as well.
>
>
What is needed in order to 'rearm' it? is there an API to get the state of
event subscription?
If we lost an event how do we know to rearm it? is it idempotent to rearm?

Remind me, do we extend a disk if the VM paused with out of space event?

How will we handle 2 subsequent events if we didn't extend between them?
(expecting the extend to be async operation)

So it seems to me this could fly and we can actually have the
> performance benefits of events.
>
>
However, due to the fact that we need to review some existing and
> delicate flows, I think we should still keep the current polling code
> around for the next release.
>
> +1


> I believe the best route is:
>
> 1. offer the new event-based code for 4.2, keep the polling around.
> Default to events for performance
>
> 2. remove the polling completely in 4.3
>
>
> Still wonder if removing them totally is good. The absence of the events
should be supervised somehow - like in today, a failure to poll getstats of
a domain will result in a VM going unresponsive. Not the most accurate
state but at least gives some visibility. So polling should cover us where
events will fail. (similar to engine's vms monitoring)

I'm currently working on the patches here:
>
> https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:watermark-event-minimal
>
>
> Even though the basics are in place, I don't think they are ready for
> review yet.
>
>
> Comments welcome, as usual.
>
>
> --
> Francesco Romani
> Senior SW Eng., Virtualization R
> Red Hat
> IRC: fromani github: @fromanirh
>

Re: [ovirt-devel] Error in running engine-setup

[Roy Golan]

sudo - postgres and append those lines into data/postgresql.conf

  autovacuum_vacuum_scale_factor = 0.01
  autovacuum_analyze_scale_factor = 0.075
  autovacuum_max_workers = 6
  maintenance_work_mem = 65536


restart and try engine setup again

On Wed, Jul 19, 2017 at 10:59 AM shubham dubey <sdubey...@gmail.com> wrote:

> Yes I have changed the permission for /var/lib/pgsql/data to 700 and
> running as normal user
> but that doesn't fix the problem.
> Here is the logs maybe that will explain more:
> https://pastebin.com/44d4XeyC
>
> On Wed, Jul 19, 2017 at 1:26 PM, Roy Golan <rgo...@redhat.com> wrote:
>
>> Your /var/lib/pgsql/data folder should be owned by postgres:postgres with
>> 700 permission. Otherwise the daemon will fail to start.
>>
>> So change it, restart pg service and don't run engine setup under root
>> user - this should fix it
>>
>>
>> On Wed, Jul 19, 2017 at 8:46 AM Yedidyah Bar David <d...@redhat.com>
>> wrote:
>>
>>> On Tue, Jul 18, 2017 at 9:49 PM, shubham dubey <sdubey...@gmail.com>
>>> wrote:
>>> > I am having a issue in running $HOME/ovirt-engine/bin/engine-setup.
>>> > Earlier I was getting this error
>>> >
>>> > [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 13]
>>> > Permission denied: '/var/lib/pgsql/data/postgresql.conf'
>>> >
>>> > then I just change the permission of
>>> /var/lib/pgsql/data/postgresql.conf and
>>> > /var/lib/pgsql/data/ * to 777
>>> > now I am getting this error
>>> >
>>> > [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 1]
>>> Operation
>>> > not permitted: '/var/lib/pgsql/data/postgresql.conf.20170719001357'
>>> >
>>> >
>>> > So, any solution for that?
>>>
>>> I do not think it should try to configure postgresql in dev-env.
>>> Can you please share engine-setup logs? Thanks.
>>>
>>> >
>>> >
>>> > Thanks,
>>> > Shubham
>>> >
>>> > ___
>>> > Devel mailing list
>>> > Devel@ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> --
>>> Didi
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Error in running engine-setup

[Roy Golan]

Your /var/lib/pgsql/data folder should be owned by postgres:postgres with
700 permission. Otherwise the daemon will fail to start.

So change it, restart pg service and don't run engine setup under root user
- this should fix it


On Wed, Jul 19, 2017 at 8:46 AM Yedidyah Bar David  wrote:

> On Tue, Jul 18, 2017 at 9:49 PM, shubham dubey 
> wrote:
> > I am having a issue in running $HOME/ovirt-engine/bin/engine-setup.
> > Earlier I was getting this error
> >
> > [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 13]
> > Permission denied: '/var/lib/pgsql/data/postgresql.conf'
> >
> > then I just change the permission of /var/lib/pgsql/data/postgresql.conf
> and
> > /var/lib/pgsql/data/ * to 777
> > now I am getting this error
> >
> > [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 1]
> Operation
> > not permitted: '/var/lib/pgsql/data/postgresql.conf.20170719001357'
> >
> >
> > So, any solution for that?
>
> I do not think it should try to configure postgresql in dev-env.
> Can you please share engine-setup logs? Thanks.
>
> >
> >
> > Thanks,
> > Shubham
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> --
> Didi
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Question about general testing

[Roy Golan]

On Tue, Jul 18, 2017 at 4:14 PM Greg Sheremeta  wrote:

> On Tue, Jul 18, 2017 at 9:08 AM, Yaniv Kaul  wrote:
>
>>
>>
>> On Jul 18, 2017 8:45 AM, "Greg Sheremeta"  wrote:
>>
>>
>>
>> On Tue, Jul 18, 2017 at 8:40 AM, Yaniv Kaul  wrote:
>>
>>>
>>>
>>> On Jul 18, 2017 5:11 AM, "Eyal Edri"  wrote:
>>>
>>>
>>>
>>> On Tue, Jul 18, 2017 at 11:47 AM, Petr Kotas  wrote:
>>>
 Hi Marc,

 I have been working on a development environment for the oVirt. The
 environment is basically two VMs running beside together. One runs the
 engine, second is a host that runs the vdsm with nested virtualization.
  I am now working on the vagrant file with orchestration to make the
 environment setup easier. So if You would wait for a few more days, You
 will be able to start from my setup.

>>>
>>> Hi Petr,
>>> I would advise you to look into oVirt System Tests which are already
>>> being used for over a year in oVirt's CI/CD flow and are continously
>>> finding real regressions on a weekly basis.
>>>
>>>
>>> I strongly agree here. Very strongly, let's not reinvent the wheel here.
>>>
>>
>> What would be super useful is for OST (or something) to stand up an
>> environment at a specific commit, aka an instant development environment.
>> Maybe with Eclipse (Che?) ready to go right at that project state. It
>> sounds like Petr is trying to create something like that.
>>
>>
>> Eyal already sent instructions on how it can easily be achieved. One
>> Jenkins job to do the build, and then you point your repo to use its
>> output.
>> Y.
>>
>
> Right, but that's an rpm centric process. You have to execute a build that
> generates rpms to feed OST, and then you can't live-edit the (for example)
> engine code and re-start / test (fast development cycle).
>
> Or am I missing something?
>
>
One would have to start the suite on his own baremetal, (run_suite) and in
the end, when the VM are left running like you said, tweak the source code
on the engine VM. Then with 'runtest' re run the test scenarios

 export SUITE=basic-suite-master
 lago ovirt runtest ../basic-suite-master/test-scenarios/some-test.py

Of course that you'd have to tunnel the newtork for debugging, it should
work.



>>
>>
>>>
>>> It is used to continously test each oVirt project in CI, and continuous
>>> deliver it to a 'tested' repo only if it passed the system tests validation.
>>> The oVirt Systems tests project is getting updated also very frequently
>>> with new tests, which you can find here [3]
>>>
>>> We already have testing suites for 'basic install with normal
>>> engine/RHEL hypervisors', 'hosted engine', 'hyper converged setup with
>>> gluster', 'next gen node based installation'.
>>> In addition, we support exporting the environment and importing it, so
>>> basically you can bring up a complex setup once, export it and use it later
>>> for demo purposes or just reproducing a bug.
>>>
>>> In general, Lago also supports other distros such as Debian, Fedora and
>>> can be installed either with RPMs or PiP.
>>>
>>>
>>> It also supports many little features you'll end up implementing
>>> yourself, spare yourself the pleasure.
>>> Y.
>>>
>>>
>>> For more info you can read here [1][2], There are also multiple videos
>>> and slidedesk available on both projects if you're interested.
>>>
>>>
>>> [1] http://ovirt-system-tests.readthedocs.io/en/latest/
>>> [2] http://lago.readthedocs.io/en/latest/
>>> [3]
>>> https://gerrit.ovirt.org/gitweb?p=ovirt-system-tests.git;a=shortlog;h=refs%2Fheads%2Fmaster
>>>
>>>
>>>

 As for the containers. For you to have a full test setup, you would
 need to place a VM inside the container and run a nested virtualization
 inside. This is what the two projects you mentioned are doing. Therefore
 they are not that lightweight as you would like.

 I would recommend using the VM environment, which is the simplest
 solution.

 I will send a reply again once my environment is up.

 Petr






 On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta 
 wrote:

> Does ovirt-system-tests meet your needs? It can leave the VMs standing
> when it's done.
>
> On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
> wrote:
>
>> I've been trying for weeks to come up with a better (most
>> specifically lighter) testing environment for external API requests
>> (specifically vagrant).
>>
>> Right now It basically hooks into a real running oVirt to spin up and
>> test VMs. It works but it's not portable or lightweight.
>>
>> I've been looking into the docker containers:
>>https://github.com/oVirt/ovirt-container-engine (doesnt look like
>> this is going to stay maintained? )
>>https://github.com/oVirt/ovirt-containers (this requires

Re: [ovirt-devel] Fwd: [IMPORTANT] Implementing materialized views

[Roy Golan]

I think that a convention of {table_name}_MVIEW should be clear enough to
prevent us from trying to write insert/delete/update on it.

In general I like the idea and I wonder if it will help with the vms,vds
tables under load (could be worse to keep the view refreshed in fact
because of frequent updates)

On Tue, Jul 18, 2017 at 12:11 PM Eli Mesika  wrote:

> On Tue, Jul 18, 2017 at 8:56 AM, Yedidyah Bar David 
> wrote:
>
>> On Tue, Jul 18, 2017 at 1:29 AM, Martin Perina 
>> wrote:
>> > Hello,
>> >
>> > to make things completely clear: any developer which will perform any
>> > changes around permissions tables need to use only predefined stored
>> > procedures for permissions handling. If for some reason direct SQL
>> update is
>> > performed, then materialized view will not be refreshed until some
>> > permission stored procedure is called, which could cause strange
>> results.
>>
>> Isn't it possible to prevent such accidents somehow?
>>
>> E.g., is it possible that:
>> 1. We rename current table ("permissions") to some "private"
>> name (e.g. "permissions_tab")
>>
> ​This is possible ​
>
>
>
>> 2. We create the materialized view having the name of the
>> original table ("permissions")
>>
>
> ​The MV replaces the views that uses the permissions table.
> The plan is to rename the original view to something else and have the
> created MV with the original view name
>
>
>
>> 3. We do what's needed (?) so that direct inserts/updates/deletes
>> on the view either fail or do the right thing.
>>
>
> ​See my answer in 1)
> ​
>
>
>>
>> >
>> > Eli has already removed all such code within patch [3], so this is just
>> a
>> > warning for future.
>> >
>> > Thanks
>> >
>> > Martin
>> >
>> >
>> > On Mon, Jul 17, 2017 at 9:47 PM, Eli Mesika  wrote:
>> >>
>> >>
>> >> Materialized Views [1] can be used to reduce query time on complex
>> queries
>> >> with low data update
>> >>
>> >> The first candidates to use this feature are all the *permission* views
>> >>
>> >> There is already a RFE [2] opened for that.
>> >>
>> >> Please make sure that each call that handles the permissions table
>> data is
>> >> using the corresponding SP in dbscripts/multi_level_administration.sql
>> >> No direct access to the permissions table is allowed !
>> >>
>> >> In case that a direct access to the permissions table is used, you
>> should
>> >> replace the code in a call to the corresponding SP as you can see in
>> [3]
>> >>
>> >> A direct use that will not be replaced with a call to the
>> corresponding SP
>> >> may cause that direct changes to the permissions table will not be
>> reflected
>> >> in the
>> >> *permission* Materialized Views and the views will remain dirty until a
>> >> change that is calling one of the SPs that handle the data of the
>> >> permissions table is issued and cause the Materialized Views to be
>> refreshed
>> >>
>> >> Please check your code for direct use of the permissions table and
>> consult
>> >> with me if you have any questions or issues.
>> >>
>> >> Thanks
>> >>
>> >> Eli Mesika
>> >>
>> >> [1] https://wiki.postgresql.org/wiki/Materialized_Views
>> >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1470991
>> >> [3] https://gerrit.ovirt.org/#/c/79287/
>> >>
>> >>
>> >> ___
>> >> Devel mailing list
>> >> Devel@ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> >
>> >
>> > ___
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>> --
>> Didi
>>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Question about general testing

[Roy Golan]

On Tue, Jul 18, 2017 at 11:47 AM Petr Kotas  wrote:

> Hi Marc,
>
> I have been working on a development environment for the oVirt. The
> environment is basically two VMs running beside together. One runs the
> engine, second is a host that runs the vdsm with nested virtualization.
>  I am now working on the vagrant file with orchestration to make the
> environment setup easier. So if You would wait for a few more days, You
> will be able to start from my setup.
>
> Interesting, can you share a link?


> As for the containers. For you to have a full test setup, you would need
> to place a VM inside the container and run a nested virtualization inside.
> This is what the two projects you mentioned are doing. Therefore they are
> not that lightweight as you would like.
>
> I would recommend using the VM environment, which is the simplest solution.
>
> I will send a reply again once my environment is up.
>
> Petr
>
>
>
>
>
>
> On Thu, Jul 13, 2017 at 4:52 PM, Greg Sheremeta 
> wrote:
>
>> Does ovirt-system-tests meet your needs? It can leave the VMs standing
>> when it's done.
>>
>> On Thu, Jul 13, 2017 at 10:39 AM, Marc Young <3vilpeng...@gmail.com>
>> wrote:
>>
>>> I've been trying for weeks to come up with a better (most specifically
>>> lighter) testing environment for external API requests (specifically
>>> vagrant).
>>>
>>>


> Right now It basically hooks into a real running oVirt to spin up and test
>>> VMs. It works but it's not portable or lightweight.
>>>
>>> I've been looking into the docker containers:
>>>https://github.com/oVirt/ovirt-container-engine (doesnt look like
>>> this is going to stay maintained? )
>>>https://github.com/oVirt/ovirt-containers (this requires openshift
>>> making it a giant yak to shave)
>>>
>>> Are there any thoughts on where to head from here? Im looking to purely
>>> launch oVirt of specific versions and run some tests against it (launching
>>> real VMs).
>>>
>>> I got the first docker one working, but it turned into a turtles problem
>>> because there was no host, and adding a host requires ssh to be running
>>> (which isnt), etc etc.
>>>
>>>


I too thing ovirt-system-tests may be a good fit. It has already suites for
master branch (coming 4.2) and 4.1 and writing a test is very easy, it uses
the python SDK which is exactly what you want.

Basically you can write your own suite, by copy-paste an already existing
suite and just modify it to your needs.

You said you wanted real VMs, but in case you want to test API calls and
interaction you can consider vdsmfake[1] which will simulate multi hosts
and multi vms all in one

[1] https://github.com/oVirt/ovirt-vdsmfake

> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> Greg Sheremeta, MBA
>> Sr. Software Engineer
>> Red Hat, Inc.
>> gsher...@redhat.com
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-system-tests failure for basic-suite-4.1

[Roy Golan]

AFAIR lago expects libvirt to run with no sasl (I guess this machine was
vdsm before that?)

I think if you just comment out every thing in /etc/libvirt/libvirtd.conf
and restart libvirtd service it should work for you.

On Sun, Jul 16, 2017 at 5:18 AM Marc Young <3vilpeng...@gmail.com> wrote:

> Sorry it took a while to get back.
>
> libvirtd is running, but with a line that may be related, might not
>
> [myoung@server ovirt-system-tests]$ sudo service libvirtd status
> Redirecting to /bin/systemctl status  libvirtd.service
> ● libvirtd.service - Virtualization daemon
>Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled;
> vendor preset: enabled)
>Active: active (running) since Sat 2017-07-15 21:14:05 CDT; 2min 24s ago
>  Docs: man:libvirtd(8)
>http://libvirt.org
>  Main PID: 3139 (libvirtd)
>CGroup: /system.slice/libvirtd.service
>├─2757 /sbin/dnsmasq
> --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro
> --dhcp-script=/usr/libexec/libvirt_leaseshelper
>├─2758 /sbin/dnsmasq
> --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro
> --dhcp-script=/usr/libexec/libvirt_leaseshelper
>└─3139 /usr/sbin/libvirtd --listen
>
> Jul 15 21:14:04 server.blindrage.local systemd[1]: Starting Virtualization
> daemon...
> Jul 15 21:14:05 server.blindrage.local systemd[1]: Started Virtualization
> daemon.
> Jul 15 21:14:05 server.blindrage.local dnsmasq[2757]: read /etc/hosts - 4
> addresses
> Jul 15 21:14:05 server.blindrage.local dnsmasq[2757]: read
> /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
> Jul 15 21:14:05 server.blindrage.local dnsmasq-dhcp[2757]: read
> /var/lib/libvirt/dnsmasq/default.hostsfile
> Jul 15 21:15:43 server.blindrage.local libvirtd[3139]: libvirt version:
> 2.0.0, package: 10.el7_3.9 (CentOS BuildSystem ,
> 2017-05-25-20:52:28, c1bm.rdu2.centos.org)
> Jul 15 21:15:43 server.blindrage.local libvirtd[3139]: hostname:
> server.blindrage.local
> Jul 15 21:15:43 server.blindrage.local libvirtd[3139]: End of file while
> reading data: Input/output error
>
>
> system tests still fail:
>
>   # Copying any deploy scripts: Success (in 0:00:00)
> libvirt: XML-RPC error : authentication failed: Failed to start SASL
> negotiation: -7 (SASL(-7): invalid parameter supplied: Unexpectedly missing
> a prompt result)
>   # Missing current link, setting it to default
>
> @ Initialize and populate prefix: ERROR (in 0:00:01)
>
> Error occured, aborting
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 954, in main
> cli_plugins[args.verb].do_run(args)
>   File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 184,
> in do_run
> self._do_run(**vars(args))
>   File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 190, in do_init
> do_build=not skip_build,
>   File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1089, in
> virt_conf_from_stream
> do_build=do_build
>   File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1214, in
> virt_conf
> net_specs=conf['nets'],
>   File "/usr/lib/python2.7/site-packages/lago/virt.py", line 90, in
> __init__
> libvirt_url=libvirt_url,
>   File "/usr/lib/python2.7/site-packages/lago/providers/libvirt/utils.py",
> line 87, in get_libvirt_connection
> LIBVIRT_CONNECTIONS[name] = libvirt.openAuth(libvirt_url, auth)
>   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in
> openAuth
> if ret is None:raise libvirtError('virConnectOpenAuth() failed')
> libvirtError: authentication failed: Failed to start SASL negotiation: -7
> (SASL(-7): invalid parameter supplied: Unexpectedly missing a prompt result)
>
>
> On Fri, Jul 14, 2017 at 6:43 AM, Marc Young <3vilpeng...@gmail.com> wrote:
>
>> I did set up libvirtd per docs but I'll double check to make sure human
>> error isn't the problem
>>
>> On Fri, Jul 14, 2017, 6:33 AM Eyal Edri  wrote:
>>
>>> Hey Marc,
>>>
>>> Thanks for trying out OST!
>>> From a first look, lt looks like libvirtd isn't running or configured
>>> properly.
>>> oVirt system tests rely on Lago to work, have you gone through the
>>> install steps to make sure Lago is installed properly?
>>>
>>>
>>> You can check out recent documentation at [1] or [2]. Once you have Lago
>>> up and running, you can run OST.
>>>
>>> [1] http://lago.readthedocs.io/en/stable/
>>> [2]
>>> http://ovirt-system-tests.readthedocs.io/en/latest/docs/general/installation.html
>>>
>>>
>>> On Fri, Jul 14, 2017 at 1:56 PM, Marc Young <3vilpeng...@gmail.com>
>>> wrote:
>>>
 I'm following the introduction docs[1] to get familiar with the
 ovirt-system-tests and encountered a failure on first run. I dug around but
 I'm not familiar enough to know if it's something I set up incorrectly, a
 real failure, etc. Git ref is a3b1753

 Shortened error below [2]
 full Output far below[3]

 [1]
 

Re: [ovirt-devel] Chaning the statistics monitoring interval to 30s

[Roy Golan]

On Thu, Jul 6, 2017 at 12:18 PM Roy Golan <rgo...@redhat.com> wrote:

> Action items:
> - Demonstrate the effect of the reduction of stats collection on the
> system - WIP
> - Code changes:
>   - config item change: NumberVmRefreshesBeforeSave from 5 to 10
>   - make the 'poll' vms job to fire at NumberVmRefreshesBeforeSave / 2 (or
> just make the code to support explicit time interval)
>   - VDSM should get a config set with the sampling inteval - to support
> back-compat
>
> - Chages to DWH sampling and ManageIQ?

>
>
>
> On Thu, Jul 6, 2017 at 11:00 AM Yaniv Kaul <yk...@redhat.com> wrote:
>
>> On Thu, Jul 6, 2017 at 10:04 AM, Oved Ourfali <oourf...@redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Jul 6, 2017 at 9:38 AM, Arik Hadas <aha...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jul 5, 2017 at 9:36 PM, Shirly Radco <sra...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> SHIRLY RADCO
>>>>>
>>>>> BI SOFTWARE ENGINEER,
>>>>>
>>>>> Red Hat Israel <https://www.redhat.com/>
>>>>>
>>>>> sra...@redhat.com
>>>>>  <https://red.ht/sig>
>>>>>  <https://redhat.com/summit>
>>>>>
>>>>>
>>>>> On Wed, Jul 5, 2017 at 6:35 PM, Arik Hadas <aha...@redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 5, 2017 at 5:57 PM, Roy Golan <rgo...@redhat.com> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I would like to get feedback on $subject and see if I'm missing
>>>>>>> something. The impact of this is simply less resource consumption and by
>>>>>>> that we can support even greater number of hosts [1] and vms in the 
>>>>>>> system.
>>>>>>>
>>>>>>
>>>>>>> If you think more relaxed statistics collection will affect a core
>>>>>>> flow let me know - as far as I see I didn't spot anything critical.
>>>>>>>
>>>>>>
>>>>>>> The overhead of a cycle per host something like that: 2 roundtrips
>>>>>>> per host in a cycle, (vm + host stats) and tons of memory allocation for
>>>>>>> char[] -> json-> maps of maps -> VM/Vds statistics -> Maps -> 
>>>>>>> serialiazing
>>>>>>> to DB.
>>>>>>>
>>>>>>> To minimize the effect of this change we can leave a call to 'list'
>>>>>>> verb to at least detect vms existence in the same rate as today.
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Pros
>>>>>>> - Engine has rore resources to support more hosts/vms/other
>>>>>>> activities of the engine
>>>>>>> - Vdsm will have more resources as well (need to tweak vdsm to
>>>>>>> collect in the same
>>>>>>> frequency)
>>>>>>> - less DB writes and reads, approx half of what the system will do
>>>>>>> in the in its lifefpan (cause this is what is mainly does all the time)
>>>>>>>
>>>>>>> Cons
>>>>>>> - DWH/Dashboard will have less entries, I'm not sure what is
>>>>>>> graphical affect given our hourly resolution (cmiiw here)
>>>>>>>
>>>>>>
>>>>>> What's the frequency of the queries done by DWH/Dashboard? Do they
>>>>>> count on the _update_date column of the queried data?
>>>>>>
>>>>>
>>>>> Current frequency is 20 seconds.
>>>>> The configurations are queried based on the _update_date, but
>>>>>  statistics are queried every interval.
>>>>>
>>>>> The affect will be less accuracy in the hourly calculations.
>>>>>
>>>>
>>>> Ack. So if the proposed change is done, it would probably make sense to
>>>> increase the inverval of those queries to be higher than 30 sec, or at
>>>> least taking into consideration the _update_date of vm_statistics as well.
>>>>
>>>>

Re: [ovirt-devel] Chaning the statistics monitoring interval to 30s

[Roy Golan]

Action items:
- Demonstrate the effect of the reduction of stats collection on the system
- WIP
- Code changes:
  - config item change: NumberVmRefreshesBeforeSave from 5 to 10
  - make the 'poll' vms job to fire at NumberVmRefreshesBeforeSave / 2 (or
just make the code to support explicit time interval)
  - VDSM should get a config set with the sampling inteval - to support
back-compat




On Thu, Jul 6, 2017 at 11:00 AM Yaniv Kaul <yk...@redhat.com> wrote:

> On Thu, Jul 6, 2017 at 10:04 AM, Oved Ourfali <oourf...@redhat.com> wrote:
>
>>
>>
>> On Thu, Jul 6, 2017 at 9:38 AM, Arik Hadas <aha...@redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Jul 5, 2017 at 9:36 PM, Shirly Radco <sra...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> --
>>>>
>>>> SHIRLY RADCO
>>>>
>>>> BI SOFTWARE ENGINEER,
>>>>
>>>> Red Hat Israel <https://www.redhat.com/>
>>>>
>>>> sra...@redhat.com
>>>>  <https://red.ht/sig>
>>>>  <https://redhat.com/summit>
>>>>
>>>>
>>>> On Wed, Jul 5, 2017 at 6:35 PM, Arik Hadas <aha...@redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 5, 2017 at 5:57 PM, Roy Golan <rgo...@redhat.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I would like to get feedback on $subject and see if I'm missing
>>>>>> something. The impact of this is simply less resource consumption and by
>>>>>> that we can support even greater number of hosts [1] and vms in the 
>>>>>> system.
>>>>>>
>>>>>
>>>>>> If you think more relaxed statistics collection will affect a core
>>>>>> flow let me know - as far as I see I didn't spot anything critical.
>>>>>>
>>>>>
>>>>>> The overhead of a cycle per host something like that: 2 roundtrips
>>>>>> per host in a cycle, (vm + host stats) and tons of memory allocation for
>>>>>> char[] -> json-> maps of maps -> VM/Vds statistics -> Maps -> 
>>>>>> serialiazing
>>>>>> to DB.
>>>>>>
>>>>>> To minimize the effect of this change we can leave a call to 'list'
>>>>>> verb to at least detect vms existence in the same rate as today.
>>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>>>
>>>>>> Pros
>>>>>> - Engine has rore resources to support more hosts/vms/other
>>>>>> activities of the engine
>>>>>> - Vdsm will have more resources as well (need to tweak vdsm to
>>>>>> collect in the same
>>>>>> frequency)
>>>>>> - less DB writes and reads, approx half of what the system will do in
>>>>>> the in its lifefpan (cause this is what is mainly does all the time)
>>>>>>
>>>>>> Cons
>>>>>> - DWH/Dashboard will have less entries, I'm not sure what is
>>>>>> graphical affect given our hourly resolution (cmiiw here)
>>>>>>
>>>>>
>>>>> What's the frequency of the queries done by DWH/Dashboard? Do they
>>>>> count on the _update_date column of the queried data?
>>>>>
>>>>
>>>> Current frequency is 20 seconds.
>>>> The configurations are queried based on the _update_date, but
>>>>  statistics are queried every interval.
>>>>
>>>> The affect will be less accuracy in the hourly calculations.
>>>>
>>>
>>> Ack. So if the proposed change is done, it would probably make sense to
>>> increase the inverval of those queries to be higher than 30 sec, or at
>>> least taking into consideration the _update_date of vm_statistics as well.
>>>
>>>
>>
>> Note that it will cause issues with cloudforms to change those queries to
>> 30 seconds, so I guess we'll still query it every 20 seconds (although the
>> data won't change in some of those queries).
>>
>
> I thought it was configurable in ManageIQ how often to query, but in any
> case even if we query every 20 seconds, we'll get updated VM stats, which
> is fine, and not as updated hosts stats, which is fine as well, from my
> perspective.
> Y.
>
>
>>
>>
>>
>>>>
>>>>> I'm asking because if they query the database every minute and say
>>>>> "the time now is 10:30 and the queried data is ..." then there should not
>>>>> be less entries.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1430876
>>>>>>
>>>>>
>>>>>>
>>>>>> ___
>>>>>> Devel mailing list
>>>>>> Devel@ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Devel mailing list
>>>>> Devel@ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>
>>>>
>>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Chaning the statistics monitoring interval to 30s

[Roy Golan]

Hi all,

I would like to get feedback on $subject and see if I'm missing something.
The impact of this is simply less resource consumption and by that we can
support even greater number of hosts [1] and vms in the system.

If you think more relaxed statistics collection will affect a core flow let
me know - as far as I see I didn't spot anything critical.

The overhead of a cycle per host something like that: 2 roundtrips per host
in a cycle, (vm + host stats) and tons of memory allocation for char[] ->
json-> maps of maps -> VM/Vds statistics -> Maps -> serialiazing to DB.

To minimize the effect of this change we can leave a call to 'list' verb to
at least detect vms existence in the same rate as today.

Pros
- Engine has rore resources to support more hosts/vms/other activities of
the engine
- Vdsm will have more resources as well (need to tweak vdsm to collect in
the same
frequency)
- less DB writes and reads, approx half of what the system will do in the
in its lifefpan (cause this is what is mainly does all the time)

Cons
- DWH/Dashboard will have less entries, I'm not sure what is graphical
affect given our hourly resolution (cmiiw here)


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1430876
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 03-07-2017 ] [ 006_migrations.migrate_vm ]

[Roy Golan]

On Wed, Jul 5, 2017 at 10:13 AM Eyal Edri  wrote:

> On Wed, Jul 5, 2017 at 10:02 AM, Yaniv Kaul  wrote:
>
>>
>>
>> On Wed, Jul 5, 2017 at 9:39 AM, Irit Goihman  wrote:
>>
>>> https://gerrit.ovirt.org/#/c/78536 was indeed the offending patch, the
>>> change was reverted and OST should pass now.
>>>
>>
>> - Do we know why?
>> - O-S-T seems to be a great tool for finding JSON-RPC/STOMP issues. I
>> suggest running it on every change related to these.
>>
>
> In addition, if we have collectd installed now, can't we add a test that
> will check if CPU/Memory consumption spike above the normal and fail before
> it reach actions like vm run/migration?
>

on my list.

>
>
>>
>> Y.
>>
>>
>>>
>>> On Tue, Jul 4, 2017 at 5:19 PM, Eyal Edri  wrote:
>>>
 Guys,

 I think we proved which vdsm works ( git sha1: 28558d7 ) and what was
 the changelog since until the point it fails, so you have the list of
 changes and steps to reproduce locally.
 Which again, is reproducible on CI and locally, so please go over the
 changes done or reproduce the problem locally and see the issue on a live
 system.





 On Tue, Jul 4, 2017 at 5:07 PM, Piotr Kliczewski <
 piotr.kliczew...@gmail.com> wrote:

> Looking at the last experimental job the reason of the failure is:
>
> 2017-07-04 09:39:10,491-04 ERROR
> [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default
> task-18) [] Operation Failed: [Cannot run VM. There is no host that
> satisfies current scheduling constraints. See below for details:, The host
> lago-basic-suite-master-host0 did not satisfy internal filter 
> CPUOverloaded
> because its CPU is too loaded.]
>
> Do we think that vdsm increased its cpu consumption recently?
>
> On Tue, Jul 4, 2017 at 3:54 PM, Irit Goihman 
> wrote:
>
>> I've checked vdsm logs and couldn't find anything related to my
>> change.
>> I'll run OST without my changes and see if it runs successfully.
>>
>> On Tue, Jul 4, 2017 at 4:49 PM, Eyal Edri  wrote:
>>
>>>
>>>
>>> On Tue, Jul 4, 2017 at 4:29 PM, Dafna Ron  wrote:
>>>
 This issue is reproduced locally as well.

 you can run the following to reproduce locally

 ./run_suite.sh -s
 http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-el7-x86_64/2694/
 basic-suite-master

 you will have the environment still running which would allow to
 view the live environment.
 if you have any issues please ping me and I will help any way I
 can.

 Thanks,
 Dafna



>>> Here is the list of changes done from the vdsm that is verified ( in
>>> tested now ) to HEAD:
>>>
>>> * 74b2276 - (HEAD -> master, origin/master, origin/HEAD) stomp: add
>>> integration tests for client reconnect (6 hours ago) Irit Goihman <
>>> igoih...@redhat.com>
>>> * 2a2f6cd - stomp: set default heartbeat values and add grace period
>>> (6 hours ago) Irit Goihman 
>>> * 56c306a - tests: Make random uuid test repeatable (17 hours ago)
>>> Nir Soffer 
>>> * 864d4e3 - python3: Fix UUID packing/unpacking on python 3 (17
>>> hours ago) Nir Soffer 
>>> * 4ac4221 - python3: Improve uuid packing tests (17 hours ago) Nir
>>> Soffer 
>>> * d264c8d - python3: Run misc_test in python 3 (17 hours ago) Nir
>>> Soffer 
>>> * f923b0b - storage: Added disk type change logging (18 hours ago)
>>> Denis Chaplygin 
>>> * f1d54a1 - net: Unneeded newline is added when updating only the
>>> mtu (25 hours ago) Edward Haas 
>>> * 9056d61 - virt: metadata: remove dead code (26 hours ago)
>>> Francesco Romani 
>>> * 08982b4 - virt: network: use core.find_device_guest_address (31
>>> hours ago) Francesco Romani 
>>> * 62e2bc5 - python3: Run qcow2_test on python 3 (2 days ago) Nir
>>> Soffer 
>>> * 42f5efb - stomp: implement client reconnect (2 days ago) Irit
>>> Goihman 
>>>
>>>



 On 07/04/2017 01:35 PM, Barak Korren wrote:



 On 4 July 2017 at 14:32, Irit Goihman  wrote:

> https://gerrit.ovirt.org/#/c/78536 broke network functional tests
> but a fix was merged today: https://gerrit.ovirt.org/#/c/78925/
>
> I tried to run OST with my fix yesterday and still encountered the
> same failures.
>

 Here is a reproducer of the 

Re: [ovirt-devel] New Gerrit 2.13 UI updates

[Roy Golan]

A better search (Ctrl+g) AND Blame! I finally feel it's 2012 ;-)

Although they keep releasing, the features are coming in tortoise pcae. I
wonder what's next for gerrit.

Thanks Evgheni!

BTW the new theme for ovirt is still in plan?

On Thu, Jun 29, 2017 at 3:48 PM Eyal Edri  wrote:

> FYI,
>
> Following last night Gerrit upgrade to 2.13.8 ( Thanks Evgheni! ), there
> are some nice updates worth mentioning:
> (I really like the new 'blame' option on the diff screen... :)
> User Interface
>
>- The UI can now be loaded in an iFrame by enabling
>gerrit.canLoadInIFrame
>
> 
>  in
>the site configuration.
>
>
> Change
> Screen
>
>-
>
>Issue 106 :
>Allow to select merge commit's parent for diff base in change screen.
>-
>
>Issue 3035 :
>Allow to remove specific votes from a change, while leaving the reviewer on
>the change.
>-
>
>Issue 3487 :
>Use ‘Ctrl-Alt-e’ instead of ‘e’ to open edit mode.
>
>
> Diff
> Screens
>
>-
>
>Add all syntax highlighting available in CodeMirror.
>-
>
>Improve search experience in diff screen.
>
>Ctrl-F, Ctrl-G and Shift-Ctrl-G now bind to the search dialog box
>provided by CodeMirror's search add-on. Enter and Shift-Enter navigate
>among the search results from the CodeMirror search, just like they do in a
>normal browser search. Esc now clears the search result.
>
>If the user sets Render to Slow in the diff preferences and the file
>is less than 4000 lines (huge), then Ctrl-F, Ctrl-G and Shift-Ctrl-G fall
>back to the browser search.
>-
>
>Issue 2968 :
>Allow to go back to change list by keyboard shortcut from diff screens.
>-
>
>Blame annotations.
>
>By enabling change.allowBlame
>
> ,
>blame annotations can be shown in the side-by-side diff screen gutter.
>Clicking the annotation opens the relevant change.
>
>
> User
> Preferences
>
>-
>
>Issue 989 :
>New option to control email notifications.
>
>Users can now choose between ‘Enabled’, ‘Disabled’ and ‘CC Me on
>Comments I Write’.
>-
>
>New option to control adding ‘Signed-off-by’ footer in commit message
>of new changes created online.
>-
>
>New option to control auto-indent width in inline editor.
>-
>
>Issue 890 :
>New diff option to control whether to skip unchanged files when navigating
>to the previous or the next file.
>
> 
> Full changelog: https://www.gerritcodereview.com/releases/2.13.md
>
>
> --
>
> Eyal edri
>
>
> ASSOCIATE MANAGER
>
> RHV DevOps
>
> EMEA VIRTUALIZATION R
>
>
> Red Hat EMEA 
>  TRIED. TESTED. TRUSTED. 
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] OST failing in 000_check_repo_closure

[Roy Golan]

Works for me as well.

On Tue, Jun 27, 2017 at 4:58 PM Milan Zamazal  wrote:

> Daniel Belenky  writes:
>
> > I've sent a workaround patch [1] that supposes to fix this.
> > Please notice that I'm still testing it on the different suites in OST
> > (basic_suite_master is working).
> > You can try to run OST locally with this patch
> >
> > [1] https://gerrit.ovirt.org/#/c/78710/1
>
> Yes, this workaround suppresses the problem, thank you.
>
> > On Tue, Jun 27, 2017 at 2:35 PM, Milan Zamazal 
> wrote:
> >
> >> Daniel Belenky  writes:
> >>
> >> > can you please attach the lago log here?
> >>
> >> Here it is:
> >>
> >>
> >>
> >> > On Tue, Jun 27, 2017 at 2:21 PM, Milan Zamazal 
> >> wrote:
> >> >
> >> >> Daniel Belenky  writes:
> >> >>
> >> >> > The same test is working in the experimental flow, so looks like a
> >> local
> >> >> > issue.
> >> >> > Are you using the most up to date master branch of ost?
> >> >>
> >> >> Yes, the latest version from git.
> >> >>
> >> >> > On Tue, Jun 27, 2017 at 1:58 PM, Milan Zamazal <
> mzama...@redhat.com>
> >> >> wrote:
> >> >> >
> >> >> >> I tried to run OST on current basic-suite-master and it fails in
> >> >> >> 000_check_repo_closure.  Is it only my local problem or is there
> >> >> >> something broken?  How can I get OST running again?
> >> >> >>
> >> >> >> ## Params: ['repoclosure', '-t', '--config=/home/pdm/ovirt/
> >> >> >> lago/ovirt-system-tests/basic-suite-master/reposync-config.
> >> >> repo_repoclosure',
> >> >> >> '--lookaside=ovirt-master-tested-el7', '--lookaside=ovirt-master-
> >> >> snapshot-static-el7',
> >> >> >> '--lookaside=glusterfs-3.10-el7',
> '--lookaside=centos-updates-el7',
> >> >> >> '--lookaside=centos-base-el7', '--lookaside=centos-extras-el7',
> >> >> >> '--lookaside=epel-el7', '--lookaside=centos-ovirt-4.0-el7',
> >> >> >> '--lookaside=centos-kvm-common-el7', '--lookaside=centos-opstools-
> >> >> testing-el7',
> >> >> >> '--lookaside=copr-sac-gdeploy-el7', '--repoid=internal_repo'].
> >> >> >> ## Exist status: 1
> >> >> >> ## Output: Reading in repository metadata - please wait
> >> >> >> Checking Dependencies
> >> >> >> Repos looked at: 12
> >> >> >>centos-base-el7
> >> >> >>centos-extras-el7
> >> >> >>centos-kvm-common-el7
> >> >> >>centos-opstools-testing-el7
> >> >> >>centos-ovirt-4.0-el7
> >> >> >>centos-updates-el7
> >> >> >>copr-sac-gdeploy-el7
> >> >> >>epel-el7
> >> >> >>glusterfs-3.10-el7
> >> >> >>internal_repo
> >> >> >>ovirt-master-snapshot-static-el7
> >> >> >>ovirt-master-tested-el7
> >> >> >> Num Packages in Repos: 37128
> >> >> >> package: cockpit-ostree-138-1.el7.x86_64 from internal_repo
> >> >> >>   unresolved deps:
> >> >> >>  /usr/libexec/rpm-ostreed
> >> >> >> package: python2-botocore-1.4.43-1.el7.noarch from internal_repo
> >> >> >>   unresolved deps:
> >> >> >>  python-dateutil >= 0:2.1
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Milan
> >> >> >> ___
> >> >> >> Devel mailing list
> >> >> >> Devel@ovirt.org
> >> >> >> http://lists.ovirt.org/mailman/listinfo/devel
> >> >> >>
> >> >>
> >>
> >>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Heads up: VdcAction* classes names have been changed

[Roy Golan]

On Mon, Jun 19, 2017 at 8:57 PM Moti Asayag  wrote:

> Please note that the engine might fail to start if there are uncompleted
> commands stored in the *command_entities* table due to (de)serialization
> issue.
> If you encountered such exceptions during the engine startup, please
> delete the entire content of that table.
>
> On Mon, Jun 19, 2017 at 4:10 PM, Tal Nisan  wrote:
>
>> Hi all,
>> I've merged patches to change the legacy name "VdcAction*" to "Action*",
>> the Vdc prefix is here from long time ago and doesn't make much sense
>> anymore (if it ever did).
>> Please make sure you rebase your patches before submitting and make sure
>> CI passes again even if it passed before rebasing.
>>
>> Changed classes are:
>> VdcActionType -> ActionType
>> VdcActionTypeDeserializer -> ActionTypeDeserializer
>> VdcActionParametersBase -> ActionParametersBase
>> VdcActionUtils -> ActionUtils
>>
>> Thanks for the reviewers that helped review those long and boring patches
>> (amureini, masayah, frolland, ishaby, awels, gsheremeta, oourfali)
>>
>> Next up on my list is VdcQuery*, stay tuned :)
>>
>>
I'm just missing a mail prior to this kind of change - can you please give
a heads up next time?

>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Regards,
> Moti
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ENGINE][ACTION_NEEDED] - default maintainers, per path

[Roy Golan]

The patch is now merged and the it should start working immediately. For
anyone who is listed as a default reviewer I suggest to test it with a test
patch by some other submitter. (except for those who used groups of course)

Thanks everyone for the cooperation on this.


On Mon, May 29, 2017 at 2:24 PM Roy Golan <rgo...@redhat.com> wrote:

> 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@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/
>
>
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [ENGINE][ACTION_NEEDED] - default maintainers, per path

[Roy Golan]

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@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/
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] ovirt-engine-contrib (was "Runtime log controll script" )

[Roy Golan]

On Wed, May 10, 2017 at 11:17 AM Roy Golan <rgo...@redhat.com> wrote:

> On Wed, Apr 19, 2017 at 3:09 PM Shmuel Melamud <smela...@redhat.com>
> wrote:
>
>> Hi!
>>
>> On Tue, Apr 18, 2017 at 6:40 PM, Roy Golan <rgo...@redhat.com> wrote:
>> >>>> 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.
>> >>>
>> >>> Nice job, Roy! +1 to the "ovirt-engine-contrib" idea.
>> >>
>> >> +1 [aside -- suggest adding engine build aliases, git aliases, shell
>> >> functions for building / maintaining multiple engine compilations and
>> >> databases, etc.]
>> >>
>> >
>> > Exactly. Should it be a 'contrib' folder under the repo and then later
>> we
>> > can create an rpm out of it if we want?
>>
>>
>
>> I collect my utilities here
>> https://github.com/smelamud/ovirt-engine-dev-scripts. And there are
>> some other collections AFAIK.
>>
>> Shmuel
>>
>
> I'm proposing a contrib folder for a start. All, please review and comment:
>
> https://gerrit.ovirt.org/76652 contrib: Introduce contrib folder
>

This patch is merged and you can find the 'contrib' folder under the root
of the engine repo.
Please read the contrib/README.adoc before contributing.

Thanks all for the feedback and review.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Engine] Runtime log controll script

[Roy Golan]

On Wed, Apr 19, 2017 at 3:09 PM Shmuel Melamud <smela...@redhat.com> wrote:

> Hi!
>
> On Tue, Apr 18, 2017 at 6:40 PM, Roy Golan <rgo...@redhat.com> wrote:
> >>>> 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.
> >>>
> >>> Nice job, Roy! +1 to the "ovirt-engine-contrib" idea.
> >>
> >> +1 [aside -- suggest adding engine build aliases, git aliases, shell
> >> functions for building / maintaining multiple engine compilations and
> >> databases, etc.]
> >>
> >
> > Exactly. Should it be a 'contrib' folder under the repo and then later we
> > can create an rpm out of it if we want?
>
>

> I collect my utilities here
> https://github.com/smelamud/ovirt-engine-dev-scripts. And there are
> some other collections AFAIK.
>
> Shmuel
>

I'm proposing a contrib folder for a start. All, please review and comment:

https://gerrit.ovirt.org/76652 contrib: Introduce contrib folder
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] New design for the Gerrit UI

[Roy Golan]

The footer links are useful but the footer itself has no presence.  Most
dashboards will fill a page and with such a thin footer nobody is going to
look at what is has to offer. So we can make the footer in a different
color and noticeable etc or move the links to the header.

On Sun, May 7, 2017 at 10:35 AM Barak Korren <bkor...@redhat.com> wrote:

> The current scheme seems a little buggy on FF. See how the top green bar
> is not stretched to cover the top of the oVirt logo.
>
>
>
> On 6 May 2017 at 12:49, Yaniv Kaul <yk...@redhat.com> wrote:
>
>>
>>
>> On Fri, May 5, 2017 at 5:33 PM, Greg Sheremeta <gsher...@redhat.com>
>> wrote:
>>
>>> Here's my take.
>>>
>>> The line on the top is a little thicker than I like, but we have the
>>> same thickness in oVirt (I checked). I'm ok with shrinking it in both
>>> places.
>>>
>>> I put in the logo from the oVirt login page. I added patternfly and
>>> bootstrap. Changed the font to OpenSans. Positioned things and fixed
>>> paddings. Changed the button and form field to patternfly type (blue button)
>>>
>>
>> Looks very good now. I wonder how far are we from being ADA compliant
>> (also a general question to our UI - I know Patternfly should help us there
>> as well).
>> Y.
>>
>>
>>
>>>
>>> Best wishes,
>>> Greg
>>>
>>>
>>> On Fri, May 5, 2017 at 2:15 AM, Roy Golan <rgo...@redhat.com> wrote:
>>>
>>>>
>>>> Adding UX people +Eldan Hildesheim <i...@eldanet.com> +Alexander Wels
>>>> <aw...@redhat.com> +Greg Sheremeta <gsher...@redhat.com>
>>>>
>>>> On Fri, May 5, 2017 at 2:32 AM Martin Perina <mper...@redhat.com>
>>>> wrote:
>>>>
>>>>> On Thu, May 4, 2017 at 1:13 PM, Nir Soffer <nsof...@redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, May 4, 2017 at 4:26 PM Evgheni Dereveanchin <
>>>>>> edere...@redhat.com> wrote:
>>>>>>
>>>>>>> Thanks everyone for the great feedback!
>>>>>>>
>>>>>>> So there's two options I see now:
>>>>>>> 1) keep the default header scheme with white background, just add
>>>>>>> the project logo into the corner
>>>>>>> 2) try to adapt to the Patternfly scheme as used in oVirt's Admin UI
>>>>>>> currently.
>>>>>>>
>>>>>>> I've swapped the header background color to #393f45 as used in oVirt
>>>>>>> for a quick test:
>>>>>>> https://gerrit-staging.phx.ovirt.org/
>>>>>>>
>>>>>>
>>>>>> Looks good!
>>>>>>
>>>>>
>>>>> ​Much better for my eyes now, thanks a lot!
>>>>> ​
>>>>>
>>>>>
>>>>>>
>>>>>> The oVirt logo needs little more space around it, and it also should
>>>>>> be centered vertically.
>>>>>> Modifying the logo margin to 8px and width to 108px works for me
>>>>>> using chrome,
>>>>>> see attached screenshot.
>>>>>>
>>>>>> [image: Screenshot from 2017-05-04 20-11-39.png]
>>>>>>
>>>>>> Nir
>>>>>>
>>>>>> Is this more readable? If yes - I can continue working in this
>>>>>>> direction to add gradients
>>>>>>> and other patternfly style elements.
>>>>>>>
>>>>>> Otherwise I'll just go with option 1 and stick to the default style
>>>>>>> we have now.
>>>>>>>
>>>>>>> On Thu, May 4, 2017 at 2:45 PM, Martin Sivak <msi...@redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> > It will help if someone can suggest an alternate CSS which we can
>>>>>>>> use or specific color codes,
>>>>>>>>
>>>>>>>> Well.. keep it as it is or make it really dark (like the patternfly
>>>>>>>> menu). I do not care about logos but big area filled with non-neutral 
>>>>>>>> color
>>>>>>>> is always going to be an issue.
>>>>>>>>
>>>>>>>> Martin
>>>>>>>>
>>>&g

Re: [ovirt-devel] New design for the Gerrit UI

[Roy Golan]

Adding UX people +Eldan Hildesheim  +Alexander Wels
 +Greg Sheremeta 

On Fri, May 5, 2017 at 2:32 AM Martin Perina  wrote:

> On Thu, May 4, 2017 at 1:13 PM, Nir Soffer  wrote:
>
>>
>>
>> On Thu, May 4, 2017 at 4:26 PM Evgheni Dereveanchin 
>> wrote:
>>
>>> Thanks everyone for the great feedback!
>>>
>>> So there's two options I see now:
>>> 1) keep the default header scheme with white background, just add the
>>> project logo into the corner
>>> 2) try to adapt to the Patternfly scheme as used in oVirt's Admin UI
>>> currently.
>>>
>>> I've swapped the header background color to #393f45 as used in oVirt for
>>> a quick test:
>>> https://gerrit-staging.phx.ovirt.org/
>>>
>>
>> Looks good!
>>
>
> ​Much better for my eyes now, thanks a lot!
> ​
>
>
>>
>> The oVirt logo needs little more space around it, and it also should be
>> centered vertically.
>> Modifying the logo margin to 8px and width to 108px works for me using
>> chrome,
>> see attached screenshot.
>>
>> [image: Screenshot from 2017-05-04 20-11-39.png]
>>
>> Nir
>>
>> Is this more readable? If yes - I can continue working in this direction
>>> to add gradients
>>> and other patternfly style elements.
>>>
>> Otherwise I'll just go with option 1 and stick to the default style we
>>> have now.
>>>
>>> On Thu, May 4, 2017 at 2:45 PM, Martin Sivak  wrote:
>>>
 > It will help if someone can suggest an alternate CSS which we can use
 or specific color codes,

 Well.. keep it as it is or make it really dark (like the patternfly
 menu). I do not care about logos but big area filled with non-neutral color
 is always going to be an issue.

 Martin

 On Thu, May 4, 2017 at 2:15 PM, Eyal Edri  wrote:

>
>
> On Thu, May 4, 2017 at 3:05 PM, Martin Perina 
> wrote:
>
>> I agree with Milan and Martin, even after few minutes looking at it,
>> the green
>> with combination of white background just made my eyes burning :-(
>>
>> Would it be possible to use more darker colors (at least for top
>> banner/menu)?
>> For example darker colors we use in oVirt engine welcome page ...
>>
>
> Thanks for the feedback,
> It will help if someone can suggest an alternate CSS which we can use
> or specific color codes,
> otherwise it will be long trial and error process until we'll find
> something that will suite everyone.
>
>
>
>>
>>
>> Martin
>>
>> On Thu, May 4, 2017 at 5:53 AM, Martin Sivak 
>> wrote:
>>
>>> I agree with Milan here. The light green background makes the menu
>>> items to be almost unreadable, the search button (slightly different
>>> green color) blends with the background and generally the color pulls
>>> my eyes away from the content. I wouldn't feel comfortable looking at
>>> the screen for a whole day.
>>>
>>> Martin
>>>
>>> On Thu, May 4, 2017 at 9:57 AM, Milan Zamazal 
>>> wrote:
>>> > Evgheni Dereveanchin  writes:
>>> >
>>> >> 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/
>>> >
>>> > Thank you for the preview.  While it fits better with oVirt
>>> services,
>>> > there is one thing that makes me uncomfortable with it: low
>>> contrast.
>>> > The top green bar is probably directly violating Web Accessibility
>>> > Guidelines (AA level; see
>>> > https://www.w3.org/TR/WCAG20/#visual-audio-contrast-contrast),
>>> but I
>>> > find all the green parts harder to read than in the current
>>> version.
>>> > So it would be nice if the contrast could be improved.
>>> >
>>> > Thanks,
>>> > Milan
>>> > ___
>>> > Devel mailing list
>>> > Devel@ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/devel
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>> ___
>> Infra mailing list
>> in...@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
>>
>
>
> --
>
> Eyal edri
>
>
> ASSOCIATE MANAGER
>
> RHV DevOps
>
> EMEA VIRTUALIZATION R
>
>
> Red Hat EMEA 

Re: [ovirt-devel] Subject: [ OST Failure Report ] [ oVirt master ] [ 26-04-2017 ] [vm_run]

[Roy Golan]

On Thu, Apr 27, 2017 at 12:08 PM Evgheni Dereveanchin 
wrote:

> Test failed: 004_basic_sanity/vm_run
>
> Link to job:
> http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_experimental_master/6481/
>
> This is the job where this error first appeared, however Master was
> failing
> for several days prior to that. It may be unrelated to the patch
> triggering
> this job as it fixed the previous issue:
> https://gerrit.ovirt.org/76080
>
>
I'm looking into it now.


> Engine log:
>
> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6481/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-004_basic_sanity.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>
> Host VDSM log:
>
> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6481/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-004_basic_sanity.py/lago-basic-suite-master-host0/_var_log/vdsm/vdsm.log
>
> Error snippet from the test log:
>
> 
>
> 2017-04-26 10:08:48,074-0400 ERROR (vm/1f45f85e) [virt.vm]
> (vmId='1f45f85e-4cc0-4240-94ce-14c488018e76') The vm start process failed
> (vm:682)
> Traceback (most recent call last):
>   File "/usr/share/vdsm/virt/vm.py", line 608, in _startUnderlyingVm
> self._run()
>   File "/usr/share/vdsm/virt/vm.py", line 2130, in _run
> domxml = hooks.before_vm_start(self._buildDomainXML(),
>   File "/usr/share/vdsm/virt/vm.py", line 1809, in _buildDomainXML
> self._appendDevices(domxml)
>   File "/usr/share/vdsm/virt/vm.py", line 1766, in _appendDevices
> domxml.appendDeviceXML(deviceXML)
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/libvirtxml.py", line
> 502, in appendDeviceXML
> self._devices.appendChild(etree_element=vmxml.parse_xml(deviceXML))
>   File "/usr/lib/python2.7/site-packages/vdsm/virt/vmxml.py", line 48, in
> parse_xml
> return etree.fromstring(xml_string)
>   File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1300, in XML
> parser.feed(text)
>   File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1642, in feed
> self._raiseerror(v)
>   File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1506, in
> _raiseerror
> raise err
> ParseError: not well-formed (invalid token): line 2, column 63
> 2017-04-26 10:08:48,084-0400 INFO  (vm/1f45f85e) [virt.vm]
> (vmId='1f45f85e-4cc0-4240-94ce-14c488018e76') Changed state to Down: not
> well-formed (invalid token): line 2, column 63 (code=1) (vm:1312)
>
> 
>
> --
> Regards,
> Evgheni Dereveanchin
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Subject: [ OST Failure Report ] [ oVirt master ] [ 24-04-2017 ] [import_template_from_glance]

[Roy Golan]

On Wed, Apr 26, 2017 at 3:04 PM Roy Golan <rgo...@redhat.com> wrote:

>
> Still not working. More help is needed as also +Marcin Mirecki
> <mmire...@redhat.com> and I are waiting for this to work
>
> I see the import fails with another reason, the parameters class have
> changed and now fails -
>
> Caused by: org.codehaus.jackson.map.JsonMappingException: Can not deserialize 
> instance of java.util.LinkedHashMap out of VALUE_NUMBER_INT token
>
> We have a custom properties problem here. Looking deeper now
>
> Please review -
https://gerrit.ovirt.org/#/c/76080/



>
> On Wed, Apr 26, 2017 at 2:08 PM Evgheni Dereveanchin <edere...@redhat.com>
> wrote:
>
>> Hi Eli,
>>
>> The patch was merged yesterday yet master is still failing.
>> Could you please take a look?
>>
>> Link to job with patch merged:
>>
>> http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_experimental_master/6468/
>> Engine.log with the same error as before:
>>
>> http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_experimental_master/6468/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>>
>>
>>
>>
>> On Tue, Apr 25, 2017 at 4:53 PM, Gil Shinar <gshi...@redhat.com> wrote:
>>
>>> Hi Eli,
>>>
>>> When was it merged? I looked at the patch in your former message and it
>>> is not merged.
>>> Master is still failing on add_secondary_storage_domains
>>>
>>> Thanks
>>> Gil
>>>
>>> On Tue, Apr 25, 2017 at 5:19 PM, Eli Mesika <emes...@redhat.com> wrote:
>>>
>>>> The fix for that regression was merged to master, please sync and check
>>>> again
>>>>
>>>> On Tue, Apr 25, 2017 at 5:14 PM, Eli Mesika <emes...@redhat.com> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> Please review the fixing patch
>>>>> https://gerrit.ovirt.org/#/c/76013/2
>>>>>
>>>>> On Tue, Apr 25, 2017 at 3:00 PM, Fred Rolland <froll...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Eli hi,
>>>>>>
>>>>>> It seems there is some issue in the squash patch [1].
>>>>>>
>>>>>> Regarding the issue found by the OST, if you start from a fresh DB,
>>>>>> wrong values will be inserted in the "spec_params" column in the 
>>>>>> vm_device
>>>>>> table. [2]
>>>>>> We will get '58ca7b19-0071-00c0-01d6-0212' instead of a map
>>>>>> like { "vram" : "65536" }
>>>>>>
>>>>>> It will fail the creation of the AddVmTemplateCommand that we see in
>>>>>> the log.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Freddy
>>>>>>
>>>>>> [1] https://gerrit.ovirt.org/#/c/74382/
>>>>>> [2]
>>>>>> https://gerrit.ovirt.org/#/c/74382/8/packaging/dbscripts/data/01200_insert_vm_device.sql
>>>>>>
>>>>>> On Tue, Apr 25, 2017 at 12:13 PM, Fred Rolland <froll...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Looking at it
>>>>>>>
>>>>>>> On Tue, Apr 25, 2017 at 12:11 AM, Nadav Goldin <ngol...@redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Test failed:
>>>>>>>> add_secondary_storage_domains/import_template_from_glance
>>>>>>>>
>>>>>>>> Link to suspected patches: https://gerrit.ovirt.org/#/c/74382/
>>>>>>>>
>>>>>>>> Link to Job:
>>>>>>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6456/
>>>>>>>> (started in 6451)
>>>>>>>>
>>>>>>>> Link to all logs:
>>>>>>>>
>>>>>>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6456/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/
>>>>>>>>
>>>>>>>> Engine log:
>>>>>>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6456/artifact/exported-artifacts/basic-suit-ma

Re: [ovirt-devel] Subject: [ OST Failure Report ] [ oVirt master ] [ 24-04-2017 ] [import_template_from_glance]

[Roy Golan]

Still not working. More help is needed as also +Marcin Mirecki
 and I are waiting for this to work

I see the import fails with another reason, the parameters class have
changed and now fails -

Caused by: org.codehaus.jackson.map.JsonMappingException: Can not
deserialize instance of java.util.LinkedHashMap out of
VALUE_NUMBER_INT token

We have a custom properties problem here. Looking deeper now



On Wed, Apr 26, 2017 at 2:08 PM Evgheni Dereveanchin 
wrote:

> Hi Eli,
>
> The patch was merged yesterday yet master is still failing.
> Could you please take a look?
>
> Link to job with patch merged:
>
> http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_experimental_master/6468/
> Engine.log with the same error as before:
>
> http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_experimental_master/6468/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>
>
>
>
> On Tue, Apr 25, 2017 at 4:53 PM, Gil Shinar  wrote:
>
>> Hi Eli,
>>
>> When was it merged? I looked at the patch in your former message and it
>> is not merged.
>> Master is still failing on add_secondary_storage_domains
>>
>> Thanks
>> Gil
>>
>> On Tue, Apr 25, 2017 at 5:19 PM, Eli Mesika  wrote:
>>
>>> The fix for that regression was merged to master, please sync and check
>>> again
>>>
>>> On Tue, Apr 25, 2017 at 5:14 PM, Eli Mesika  wrote:
>>>
 Hi

 Please review the fixing patch
 https://gerrit.ovirt.org/#/c/76013/2

 On Tue, Apr 25, 2017 at 3:00 PM, Fred Rolland 
 wrote:

> Eli hi,
>
> It seems there is some issue in the squash patch [1].
>
> Regarding the issue found by the OST, if you start from a fresh DB,
> wrong values will be inserted in the "spec_params" column in the vm_device
> table. [2]
> We will get '58ca7b19-0071-00c0-01d6-0212' instead of a map
> like { "vram" : "65536" }
>
> It will fail the creation of the AddVmTemplateCommand that we see in
> the log.
>
> Regards,
>
> Freddy
>
> [1] https://gerrit.ovirt.org/#/c/74382/
> [2]
> https://gerrit.ovirt.org/#/c/74382/8/packaging/dbscripts/data/01200_insert_vm_device.sql
>
> On Tue, Apr 25, 2017 at 12:13 PM, Fred Rolland 
> wrote:
>
>> Looking at it
>>
>> On Tue, Apr 25, 2017 at 12:11 AM, Nadav Goldin 
>> wrote:
>>
>>> Test failed:
>>> add_secondary_storage_domains/import_template_from_glance
>>>
>>> Link to suspected patches: https://gerrit.ovirt.org/#/c/74382/
>>>
>>> Link to Job:
>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6456/
>>> (started in 6451)
>>>
>>> Link to all logs:
>>>
>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6456/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/
>>>
>>> Engine log:
>>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6456/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>>>
>>> Error snippet from the test log:
>>>
>>> 
>>>
>>> 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_master/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
>>> line 803, in import_template_from_glance
>>> generic_import_from_glance(api, image_name=CIRROS_IMAGE_NAME,
>>> image_ext='_glance_template', as_template=True)
>>>   File
>>> "/home/jenkins/workspace/test-repo_ovirt_experimental_master/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
>>> line 641, in generic_import_from_glance
>>> lambda: api.disks.get(disk_name).status.state == 'ok',
>>>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
>>> 264, in assert_true_within_long
>>> assert_equals_within_long(func, True, allowed_exceptions)
>>>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
>>> 251, in assert_equals_within_long
>>> func, value, LONG_TIMEOUT, allowed_exceptions=allowed_exceptions
>>>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
>>> 230, in assert_equals_within
>>> '%s != %s after %s seconds' % (res, value, timeout)
>>> AssertionError: False != True after 600 seconds
>>>
>>>
>>> 

Re: [ovirt-devel] OST failure NoClassDefFoundError

[Roy Golan]

Its OST, I have no option to upgrade

On Tue, Apr 25, 2017 at 8:59 AM Oved Ourfali <oourf...@redhat.com> wrote:

> I guess you need to upgrade vdsm-jsonrpc-java.
> Did you try that?
>
> On Tue, Apr 25, 2017 at 12:57 AM, Roy Golan <rgo...@redhat.com> wrote:
>
>> I get this on basic suite from a built RPM[1]:
>>
>> Caused by: java.lang.NoClassDefFoundError: 
>> org/apache/commons/lang/StringUtils
>>  at 
>> org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message.withCorrelationId(Message.java:75)
>>  [vdsm-jsonrpc-java-client.jar:]
>>  at 
>> org.ovirt.vdsm.jsonrpc.client.reactors.stomp.SSLStompClient.sendMessage(SSLStompClient.java:85)
>>  [vdsm-jsonrpc-java-client.jar:]
>>  at 
>> org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.call(JsonRpcClient.java:83) 
>> [vdsm-jsonrpc-java-client.jar:]
>>
>>
>> My patch under test certainly didn't touch this area [2]
>>
>> [1]
>> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/290/artifact/exported-artifacts/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>>
>> [2] https://gerrit.ovirt.org/#/c/75262/
>>
>> Did anyone see that?
>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] OST failure NoClassDefFoundError

[Roy Golan]

I get this on basic suite from a built RPM[1]:

Caused by: java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
at 
org.ovirt.vdsm.jsonrpc.client.reactors.stomp.impl.Message.withCorrelationId(Message.java:75)
[vdsm-jsonrpc-java-client.jar:]
at 
org.ovirt.vdsm.jsonrpc.client.reactors.stomp.SSLStompClient.sendMessage(SSLStompClient.java:85)
[vdsm-jsonrpc-java-client.jar:]
at 
org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.call(JsonRpcClient.java:83)
[vdsm-jsonrpc-java-client.jar:]


My patch under test certainly didn't touch this area [2]

[1]
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/290/artifact/exported-artifacts/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log

[2] https://gerrit.ovirt.org/#/c/75262/

Did anyone see that?
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Abusing injection and DB access

[Roy Golan]

On Thu, Apr 6, 2017 at 11:26 AM Roy Golan <rgo...@redhat.com> wrote:

> On Wed, Apr 5, 2017 at 11:34 PM Moti Asayag <masa...@redhat.com> wrote:
>
>> On Wed, Apr 5, 2017 at 11:17 PM, Roy Golan <rgo...@redhat.com> wrote:
>>
>>
>>
>> On Wed, Apr 5, 2017 at 9:06 PM Moti Asayag <masa...@redhat.com> wrote:
>>
>> Hi All,
>>
>> ATM, there are 78 occurrences of "Injector.injectMembers(new
>> AuditLogableBase())" in ovirt-engine project, which their main purpose is
>> to ease the resolve of the placeholders of the audit log message while
>> logging an event.
>>
>> For instance AuditLogType.MAC_ADDRESS_IS_EXTERNAL is being used from
>> ImportVmCommandBase.java in the following way:
>>
>> private AuditLogableBase createExternalMacsAuditLog(VM vm, Set
>> externalMacs) {
>> AuditLogableBase logable = *Injector.injectMembers*(new
>> AuditLogableBase());
>> logable.setVmId(vm.getId());
>> logable.setCustomCommaSeparatedValues("MACAddr", externalMacs);
>> return logable;
>> }
>>
>> The entry in the properties file is:
>> MAC_ADDRESS_IS_EXTERNAL=VM ${*VmName*} has MAC address(es) ${MACAddr},
>> which is/are out of its MAC pool definitions.
>>
>> Therefore the only purpose of the injection is to allow the
>> AuditLogDirector to resolve the ${*VmName*} which is already known at
>> the time of creating the AuditLogableBase entry.
>>
>> The result is injecting the DAOs for the AuditLogableBase instance and
>> using the VM dao to retrieve the VM entry from the DB.
>> This is just a wastef of injection and DB access while both can be spared.
>>
>> This could have been easily replaced by one of the following:
>>
>>- auditLogableBase.setVmName(vm.getName());
>>
>> - setVmName is protected so not usable as is
>>
>>
>> It will become public if we agree on
>>
>>
>> https://gerrit.ovirt.org/#/c/75244/2/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/auditloghandling/AuditLogableBase.java
>>
>>
>>
>>- auditLogableBase.addCustomValue("VmName", vm.getName());
>>
>> I prefer this, it is readable. and BTW it is fluent, it returns 'this' so
>> use
>>
>>   AuditLogDirector(new AuditLogableBase(type)
>>   .addCustomValue("VmName", vm.getName()));
>>
>>
>> I'm okay with this as well.
>>
>>
>> Please pick up any occurrence from your domain and send a patch to
>> replace it where possible.
>> Thanks in advance,
>> Moti
>>
>>
>> +1
>>
>> Frankly the fact that all the DAOs sets protected access in
>> AuditLogableBase is a total abuse. Every command should declare its own
>> deps.
>>
>>
>> That will require a huge effort.
>>
>
> Removed them all, https://gerrit.ovirt.org/75262 compile +1
> Now need to fix the tests - I'd appreciate help here
>
> Verified +1 the removal of all protected DAO's in AuditLogableBase.
Instead of constant injection of *66* dao fields for *every* command inject
only *9* which are most atm, They will be removed as well in the future.

Please help review, its a long, but stupid patch which just adds injections.
https://gerrit.ovirt.org/75262




>
>>
>> ___
>>
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>>
>> --
>> Regards,
>> Moti
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] [ENGINE] [RFC] A configuration verb for contexual vdsm operation mode

[Roy Golan]

On Tue, Apr 4, 2017 at 2:20 PM Piotr Kliczewski <pklic...@redhat.com> wrote:

> I wonder why we not go in the same approach as we went for vm status
> changes. Why not to pull for older versions and expect a push from new
> implementation.
> This would allow as to keep current code as it is for backward
> compatibility purposes and create new one (reuse parts of the old one) for
> new approach.
> We could change stats collection (collectd based) and still get important
> data using push.
>
> If we want to pass cluster version we could use connection negotiation
> like we do for heartbeat interval. It can be passed every time engine
> connects so there is no
> need for persistence. We could define custom headers and as a result it
> won't break vdsm-client code.
>
>
Passing the cluster version isn't a problem. The main benefit would be to
spare precious cpu and memory for vdsm and for virtualization.


> Please note that we are not good at deprecating api and I am not going to
> say anything about cleanup or removal.
> Whatever we introduce it is going to stay so we need to be careful.
>
>
> On Tue, Apr 4, 2017 at 12:28 PM, Michal Skrivanek <
> michal.skriva...@redhat.com> wrote:
>
>>
>> On 4 Apr 2017, at 12:21, Roy Golan <rgo...@redhat.com> wrote:
>>
>>
>>
>> On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek <
>> michal.skriva...@redhat.com> wrote:
>>
>>> On 4 Apr 2017, at 12:10, Roy Golan <rgo...@redhat.com> wrote:
>>>
>>>
>>>
>>> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <yk...@redhat.com> wrote:
>>>
>>> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgo...@redhat.com> wrote:
>>>
>>> I'm working on a POC lately on a change to stats collection and
>>> retrieval by VDSM. The moto is to cut all we can from host/vm stats
>>> (possibly caps) and report only core-business stuff to the engine. Engine
>>> will retrieve the rest through a 3rd party provider
>>>
>>> (nevermind what is it atm)
>>>
>>>
>>> I hope it’s the same one as for VM stats, collectd:)
>>>
>>
>> Intended for this as well.
>>
>>
>> great!
>>
>>
>>>
>>> Being backward compatible by design, I have to support 2 API versions
>>> for Host.getStats , '4.1' and '4.2'.
>>> Except from supplying less parameters, I want VDSM to do less stuff. It
>>> doesn't need to sample what it doesn't report. In other words I want
>>> '4.1-sampling' and '4.2-sampling'
>>>
>>> # Introducing 'configuration' Verb:
>>>
>>> As engine knows always(Hosted Engine as well) what cluster version this
>>> host belongs to, it can configure VDSM to operate in cluster version mode.
>>>
>>>
>>> why not running it in parallel for one version?
>>>
>>> What is the benefit?
>>
>>
>> just so you do not need any configuration verb nor persistence, not much
>> else.
>>
>>
>>>   Host.configure(config={version: 4.2}
>>>
>>> Consider this verb, pre-activating using 'Host.getCaps' to set the
>>> context.
>>> It will set the righjt sampling method, and other stuff if needed then
>>> API endpoints will have the right permutation of the api to answer it.
>>>
>>> 4.2 host can operate in 4.1 mode:
>>>   Host.configure(config={version: 4.1}
>>>
>>> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
>>> engine needs to know this is a new vdsm that has the verb available. One
>>> way to overcome that is to fire the verb for every host regardless of the
>>> version and disregard an error that implies the verb doesn't exist.
>>>
>>>
>>> Isn't it solved by host re-installation?
>>>
>>>
>>> We allow maintenance + change host cluster so not always. Was this
>>> changed?
>>>
>>>
>>>
>>> # Engine:
>>> Engine will have a handling of the verb per version.
>>> Host/Vms monitoring should be changed - I suggest to move out of the
>>> monitoring code the whole stats collection as it is a different task which
>>> is orthogonal to 'monitoring' and in 4.2 more than before.
>>>
>>>
>>> I know configuration for VDSM has been discussed before and there are
>>> probably tons of ways to do it. When you share your thoughts please
>>> remember that configuration is a by-product of the effort.
>>>
>>>
>>> How do we persist this level o

Re: [ovirt-devel] [VDSM] [ENGINE] [RFC] A configuration verb for contexual vdsm operation mode

[Roy Golan]

On Tue, Apr 4, 2017 at 1:28 PM Michal Skrivanek <michal.skriva...@redhat.com>
wrote:

> On 4 Apr 2017, at 12:21, Roy Golan <rgo...@redhat.com> wrote:
>
>
>
> On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek <
> michal.skriva...@redhat.com> wrote:
>
>> On 4 Apr 2017, at 12:10, Roy Golan <rgo...@redhat.com> wrote:
>>
>>
>>
>> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <yk...@redhat.com> wrote:
>>
>> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgo...@redhat.com> wrote:
>>
>> I'm working on a POC lately on a change to stats collection and retrieval
>> by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
>> and report only core-business stuff to the engine. Engine will retrieve the
>> rest through a 3rd party provider
>>
>> (nevermind what is it atm)
>>
>>
>> I hope it’s the same one as for VM stats, collectd:)
>>
>
> Intended for this as well.
>
>
> great!
>
>
>>
>> Being backward compatible by design, I have to support 2 API versions for
>> Host.getStats , '4.1' and '4.2'.
>> Except from supplying less parameters, I want VDSM to do less stuff. It
>> doesn't need to sample what it doesn't report. In other words I want
>> '4.1-sampling' and '4.2-sampling'
>>
>> # Introducing 'configuration' Verb:
>>
>> As engine knows always(Hosted Engine as well) what cluster version this
>> host belongs to, it can configure VDSM to operate in cluster version mode.
>>
>>
>> why not running it in parallel for one version?
>>
>> What is the benefit?
>
>
> just so you do not need any configuration verb nor persistence, not much
> else.
>
> I'm trying to figure out, based on fromani's work, how much overhead the
sampling cause. If it is quite a bit cpu and memory we can spare then it is
definitely worth shutting it off selectively.

>
>>   Host.configure(config={version: 4.2}
>>
>> Consider this verb, pre-activating using 'Host.getCaps' to set the
>> context.
>> It will set the righjt sampling method, and other stuff if needed then
>> API endpoints will have the right permutation of the api to answer it.
>>
>> 4.2 host can operate in 4.1 mode:
>>   Host.configure(config={version: 4.1}
>>
>> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since
>> engine needs to know this is a new vdsm that has the verb available. One
>> way to overcome that is to fire the verb for every host regardless of the
>> version and disregard an error that implies the verb doesn't exist.
>>
>>
>> Isn't it solved by host re-installation?
>>
>>
>> We allow maintenance + change host cluster so not always. Was this
>> changed?
>>
>>
>>
>> # Engine:
>> Engine will have a handling of the verb per version.
>> Host/Vms monitoring should be changed - I suggest to move out of the
>> monitoring code the whole stats collection as it is a different task which
>> is orthogonal to 'monitoring' and in 4.2 more than before.
>>
>>
>> I know configuration for VDSM has been discussed before and there are
>> probably tons of ways to do it. When you share your thoughts please
>> remember that configuration is a by-product of the effort.
>>
>>
>> How do we persist this level on VDSM? Or we don't, and if VDSM is
>> restarted it is again back to 4.1 mode until Engine tells it otherwise?
>>
>> Y.
>>
>>
>> Must persist it somehow otherwise there is a race when the engine will
>> send send a stats request and will get the wrong answer.  I'm wondering if
>> using differnt endpoints is the right solution here to prevent that from
>> happening.
>>   method: Host.getStats version: 4.1
>>
>>
>> would it be a problem? assuming that the code is easily started/stopped
>> within vdsm, we can just change the behavior based on receiving one or the
>> other verb for the first time after vdsm starts
>>
>
> But we should prefer a deliberate action. Doing that as a side effect is
> surprising for an API verb. What would happen in case you invoke
> 'vdsm-client’ ?
>
>
> I do not mean to switch for any client, more like a single “upgrade” of
> communication once the new verb is called. So once the engine calls the new
> verb the legacy stats thread is stopped and vdsClient  stops
> returning meaningful data.
> Actually, moving host back to older cluster doesn’t really need switching
> back either - you still have the new engine capable of handling the new
> verb despite older cluster.
>
>
>
>
>>
>> Thanks,
>> michal
>>
>>
>>
>>
>>
>>
>> Nevertheless it can be potentially beneficial to more functions in vdsm.
>>
>> Thanks,
>> Roy
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [Engine] Runtime log controll script

[Roy Golan]

On Tue, Apr 18, 2017 at 6:04 PM Greg Sheremeta <gsher...@redhat.com> wrote:

> On Tue, Apr 18, 2017 at 7:40 AM, Martin Betak <mbe...@redhat.com> wrote:
>
>>
>>
>> On Tue, Apr 18, 2017 at 9:52 AM, Roy Golan <rgo...@redhat.com> wrote:
>>
>>> 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.
>>>
>>
>> Nice job, Roy! +1 to the "ovirt-engine-contrib" idea.
>>
>
> +1 [aside -- suggest adding engine build aliases, git aliases, shell
> functions for building / maintaining multiple engine compilations and
> databases, etc.]
>
>
Exactly. Should it be a 'contrib' folder under the repo and then later we
can create an rpm out of it if we want?

Btw VDSM has a contrib folder as well with interesting stuff (just stumbled
upon profile-stats which I was completely unaware of)

>
>>
>>>
>>> [1] https://gist.github.com/rgolangh/1cb9f9b3b7f7f0a1d16b5a976d90bd55
>>>
>>> Thanks,
>>> Roy
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Greg Sheremeta, MBA
> Sr. Software Engineer
> Red Hat, Inc.
> gsher...@redhat.com
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [Engine] Runtime log controll script

[Roy Golan]

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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] [ENGINE] [RFC] A configuration verb for contexual vdsm operation mode

[Roy Golan]

On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek <michal.skriva...@redhat.com>
wrote:

> On 4 Apr 2017, at 12:10, Roy Golan <rgo...@redhat.com> wrote:
>
>
>
> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <yk...@redhat.com> wrote:
>
> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgo...@redhat.com> wrote:
>
> I'm working on a POC lately on a change to stats collection and retrieval
> by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
> and report only core-business stuff to the engine. Engine will retrieve the
> rest through a 3rd party provider
>
> (nevermind what is it atm)
>
>
> I hope it’s the same one as for VM stats, collectd:)
>

Intended for this as well.

>
>
> Being backward compatible by design, I have to support 2 API versions for
> Host.getStats , '4.1' and '4.2'.
> Except from supplying less parameters, I want VDSM to do less stuff. It
> doesn't need to sample what it doesn't report. In other words I want
> '4.1-sampling' and '4.2-sampling'
>
> # Introducing 'configuration' Verb:
>
> As engine knows always(Hosted Engine as well) what cluster version this
> host belongs to, it can configure VDSM to operate in cluster version mode.
>
>
> why not running it in parallel for one version?
>
> What is the benefit?

>
>   Host.configure(config={version: 4.2}
>
> Consider this verb, pre-activating using 'Host.getCaps' to set the context.
> It will set the righjt sampling method, and other stuff if needed then API
> endpoints will have the right permutation of the api to answer it.
>
> 4.2 host can operate in 4.1 mode:
>   Host.configure(config={version: 4.1}
>
> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since engine
> needs to know this is a new vdsm that has the verb available. One way to
> overcome that is to fire the verb for every host regardless of the version
> and disregard an error that implies the verb doesn't exist.
>
>
> Isn't it solved by host re-installation?
>
>
> We allow maintenance + change host cluster so not always. Was this
> changed?
>
>
>
> # Engine:
> Engine will have a handling of the verb per version.
> Host/Vms monitoring should be changed - I suggest to move out of the
> monitoring code the whole stats collection as it is a different task which
> is orthogonal to 'monitoring' and in 4.2 more than before.
>
>
> I know configuration for VDSM has been discussed before and there are
> probably tons of ways to do it. When you share your thoughts please
> remember that configuration is a by-product of the effort.
>
>
> How do we persist this level on VDSM? Or we don't, and if VDSM is
> restarted it is again back to 4.1 mode until Engine tells it otherwise?
>
> Y.
>
>
> Must persist it somehow otherwise there is a race when the engine will
> send send a stats request and will get the wrong answer.  I'm wondering if
> using differnt endpoints is the right solution here to prevent that from
> happening.
>   method: Host.getStats version: 4.1
>
>
> would it be a problem? assuming that the code is easily started/stopped
> within vdsm, we can just change the behavior based on receiving one or the
> other verb for the first time after vdsm starts
>

But we should prefer a deliberate action. Doing that as a side effect is
surprising for an API verb. What would happen in case you invoke
'vdsm-client' ?


>
> Thanks,
> michal
>
>
>
>
>
>
> Nevertheless it can be potentially beneficial to more functions in vdsm.
>
> Thanks,
> Roy
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] [ENGINE] [RFC] A configuration verb for contexual vdsm operation mode

[Roy Golan]

On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <yk...@redhat.com> wrote:

> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgo...@redhat.com> wrote:
>
> I'm working on a POC lately on a change to stats collection and retrieval
> by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
> and report only core-business stuff to the engine. Engine will retrieve the
> rest through a 3rd party provider (nevermind what is it atm)
>
> Being backward compatible by design, I have to support 2 API versions for
> Host.getStats , '4.1' and '4.2'.
> Except from supplying less parameters, I want VDSM to do less stuff. It
> doesn't need to sample what it doesn't report. In other words I want
> '4.1-sampling' and '4.2-sampling'
>
> # Introducing 'configuration' Verb:
>
> As engine knows always(Hosted Engine as well) what cluster version this
> host belongs to, it can configure VDSM to operate in cluster version mode.
>
>   Host.configure(config={version: 4.2}
>
> Consider this verb, pre-activating using 'Host.getCaps' to set the context.
> It will set the righjt sampling method, and other stuff if needed then API
> endpoints will have the right permutation of the api to answer it.
>
> 4.2 host can operate in 4.1 mode:
>   Host.configure(config={version: 4.1}
>
> Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since engine
> needs to know this is a new vdsm that has the verb available. One way to
> overcome that is to fire the verb for every host regardless of the version
> and disregard an error that implies the verb doesn't exist.
>
>
> Isn't it solved by host re-installation?
>

We allow maintenance + change host cluster so not always. Was this changed?

>
>
> # Engine:
> Engine will have a handling of the verb per version.
> Host/Vms monitoring should be changed - I suggest to move out of the
> monitoring code the whole stats collection as it is a different task which
> is orthogonal to 'monitoring' and in 4.2 more than before.
>
>
> I know configuration for VDSM has been discussed before and there are
> probably tons of ways to do it. When you share your thoughts please
> remember that configuration is a by-product of the effort.
>
>
> How do we persist this level on VDSM? Or we don't, and if VDSM is
> restarted it is again back to 4.1 mode until Engine tells it otherwise?
> Y.
>

Must persist it somehow otherwise there is a race when the engine will send
send a stats request and will get the wrong answer.  I'm wondering if using
differnt endpoints is the right solution here to prevent that from
happening.
  method: Host.getStats version: 4.1


>
>
>
> Nevertheless it can be potentially beneficial to more functions in vdsm.
>
> Thanks,
> Roy
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [VDSM] [ENGINE] [RFC] A configuration verb for contexual vdsm operation mode

[Roy Golan]

I'm working on a POC lately on a change to stats collection and retrieval
by VDSM. The moto is to cut all we can from host/vm stats (possibly caps)
and report only core-business stuff to the engine. Engine will retrieve the
rest through a 3rd party provider (nevermind what is it atm)

Being backward compatible by design, I have to support 2 API versions for
Host.getStats , '4.1' and '4.2'.
Except from supplying less parameters, I want VDSM to do less stuff. It
doesn't need to sample what it doesn't report. In other words I want
'4.1-sampling' and '4.2-sampling'

# Introducing 'configuration' Verb:

As engine knows always(Hosted Engine as well) what cluster version this
host belongs to, it can configure VDSM to operate in cluster version mode.

  Host.configure(config={version: 4.2}

Consider this verb, pre-activating using 'Host.getCaps' to set the context.
It will set the righjt sampling method, and other stuff if needed then API
endpoints will have the right permutation of the api to answer it.

4.2 host can operate in 4.1 mode:
  Host.configure(config={version: 4.1}

Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since engine
needs to know this is a new vdsm that has the verb available. One way to
overcome that is to fire the verb for every host regardless of the version
and disregard an error that implies the verb doesn't exist.

# Engine:
Engine will have a handling of the verb per version.
Host/Vms monitoring should be changed - I suggest to move out of the
monitoring code the whole stats collection as it is a different task which
is orthogonal to 'monitoring' and in 4.2 more than before.


I know configuration for VDSM has been discussed before and there are
probably tons of ways to do it. When you share your thoughts please
remember that configuration is a by-product of the effort.
Nevertheless it can be potentially beneficial to more functions in vdsm.

Thanks,
Roy
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] GUI error on master: Uncaught exception: com.google.gwt.core.client.JavaScriptException: (TypeError)

[Roy Golan]

On Mon, Apr 3, 2017 at 4:09 PM Nadav Goldin  wrote:

> Right. Missed that exclude, thanks.
> I'll send a patch to include it from tested - all *debuginfo* packages
> look like just a few MBs.
>
>
+Guy Chen 


>
> On Mon, Apr 3, 2017 at 3:55 PM, Greg Sheremeta 
> wrote:
> > Hmm, I think *-debuginfo is explicitly excluded now.
> >
> > https://gerrit.ovirt.org/#/c/73497/8/common/yum-repos/ovirt-master.repo
> >
> > [ovirt-master-tested-el7]
> > name=oVirt Master Latest Tested
> > baseurl=http://resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/
> > enabled=1
> > gpgcheck=0
> > max_connections=10
> > exclude =  *-debuginfo
> >
> > [ovirt-master-snapshot-static-el7]
> > name=oVirt Master Nightly Statics
> > baseurl=
> http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/el7/
> > exclude= *-debuginfo
> >
> >
> > Could that be the problem?
> >
> > On Sun, Apr 2, 2017 at 1:38 PM, Nadav Goldin  wrote:
> >>
> >> > Any chance you can install them and retry?
> >> > sudo yum install ovirt-engine-webadmin-portal-debuginfo
> >>
> >> Surprisingly OST didn't pull it. I see it is listed in the reposync
> >> config under the 'ovirt-master-snapshot-static', but I think its not
> >> there any more. Is it built like all other packages consumed in the
> >> experimental flow?
> >>
> >>
> >>
> >>
> >> On Sun, Apr 2, 2017 at 4:00 PM, Yaniv Kaul  wrote:
> >> >
> >> >
> >> > On Sun, Apr 2, 2017 at 3:18 PM, Greg Sheremeta 
> >> > wrote:
> >> >>
> >> >> """
> >> >> GWT symbolmaps are not installed, please install
> >> >> them to de-obfuscate the UI stack traces
> >> >> 2017-04-02 06:12:25,980-04 ERROR
> >> >> """
> >> >>
> >> >> Any chance you can install them and retry?
> >> >> sudo yum install ovirt-engine-webadmin-portal-debuginfo
> >> >
> >> >
> >> > && sudo systemctl restart ovirt-engine
> >> >
> >> > Y.
> >> >
> >> >>
> >> >>
> >> >>
> >> >> On Sun, Apr 2, 2017 at 6:25 AM, Nadav Goldin 
> >> >> wrote:
> >> >>>
> >> >>> Hi,
> >> >>> Running OST basic-suite-master and logging to the GUI, appears a
> >> >>> warning pop-up window:
> >> >>> Uncaught exception occurred. Please try reloading the page. Details:
> >> >>> (TypeError) : a.i is undefined
> >> >>> Please have your administrator check the UI logs
> >> >>>
> >> >>> ui.log:
> >> >>> 2017-04-02 06:12:25,975-04 INFO
> >> >>> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
> >> >>> (default task-3) [] GWT symbolmaps are not installed, please install
> >> >>> them to de-obfuscate the UI stack traces
> >> >>> 2017-04-02 06:12:25,980-04 ERROR
> >> >>> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
> >> >>> (default task-3) [] Permutation name:
> E0637AA26393B2D56C4B42EFB5EA0C00
> >> >>> 2017-04-02 06:12:25,980-04 ERROR
> >> >>> [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService]
> >> >>> (default task-3) [] Uncaught exception:
> >> >>> com.google.gwt.core.client.JavaScriptException: (TypeError) : a.i is
> >> >>> undefined
> >> >>> at
> >> >>>
> >> >>> Unknown.itp(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.Btp(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.pWo(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.sWo(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.JYo(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.MYo(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.jYo(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.mYo(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.PPe(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.E_(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.T_(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.onreadystatechange<(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.Bu(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.Eu(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at
> >> >>>
> >> >>> Unknown.Du/<(
> https://192.168.201.3/ovirt-engine/webadmin/?locale=en_US#dashboard-main)
> >> >>> at 

Re: [ovirt-devel] Live demo session on how to debug oVirt GWT applications

[Roy Golan]

On Fri, Mar 31, 2017 at 4:49 PM Vojtech Szocs  wrote:

> Hello,
>
> the slides are here:
> http://redhat.slides.com/vszocs/debugging-ovirt-gwt-applications?token=brh5Tzaz
>
> I've made some new discoveries while working on this, the biggest one is
> that SDBG (link below) actually works for oVirt WebAdmin!
>
>
Intellij supports super dev mode. Does anyone have experience with it?


> This means there's a viable alternative to existing GWT debug method,
> which doesn't restrict you to using an ancient (NPAPI-compliant) browser,
> while still being able to use Java IDE (Eclipse) as well as reaping the
> benefits of SDM code server (fast incremental recompiles).
>
> If you're an oVirt UI maintainer, I highly suggest you to join this
> session, spend ~1 hour of your time and in return, get the knowledge to be
> more productive when dealing with our GWT code.
>
> Regards,
> Vojtech
>
>
> On Tue, Mar 28, 2017 at 3:56 PM, Vojtech Szocs  wrote:
>
> Update: moving the session to Tue, Apr 4 @ the same time as originally
> planned.
>
> Regards,
> ​V​
> ojtech
>
> PS: Greg sent me a link to SDBG project [1] which allows you to debug GWT
> application via Super Dev Mode from within Java Eclipse IDE. I'm going to
> cover this in the presentation as well.
>
> [1] http://sdbg.github.io/
>
>
> On Mon, Mar 27, 2017 at 8:09 PM, Vojtech Szocs  wrote:
>
> Hello UI devs,
>
> with oVirt master UI using the latest GWT SDK [1], I'd like to host a live
> demo session with two goals in mind:
>
> a, explain how the (Java IDE based) Classic Dev Mode works and mention its
> limitations
> b, explain how the (browser based) Super Dev Mode works and encourage
> people to start using it to boost their productivity
>
> [1] http://www.mail-archive.com/devel@ovirt.org/msg08558.html
>
> The Classic vs. Super Dev Mode are two possible ways to debug GWT
> applications. This session will give you the knowledge to decide which one
> to use in a specific situation.
>
> Proposed time: Mon, Apr 3 @ 5pm CET / 6pm TLV / 11am US EST. (This can be
> changed as needed.)
>
> Let me know if this kind of session interests you or if the above time
> doesn't fit you but you'd still like to join.
>
> Thanks,
> Vojtech
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt master UI now uses GWT 2.8

[Roy Golan]

On Wed, Mar 15, 2017 at 6:53 PM Vojtech Szocs  wrote:

> Hello folks,
>
> we're using the latest GWT version in master UI now [1].
>
> We can start using Java 8 syntax in our frontend code. GWT 2.8 also brings
> partial support for Java 8 standard library APIs, see "JDK emulation" at
> [2] for details.
>
> [1] https://gerrit.ovirt.org/#/q/topic:gwtupgrade
> [2] http://www.gwtproject.org/release-notes.html#Release_Notes_2_8_0_RC1
>
> Effectively, all Engine (Java Maven) modules [3] are now Java 8 source &
> target compilant.
>
> [3] except backend/manager/modules/extensions-api-root
>
> With this upgrade, the GWT UI should be a bit faster - generated
> JavaScript should take advantage of new web APIs (e.g. using ES6 Maps to
> implement Java HashMap) as well as general performance improvements (e.g.
> using a faster "long" emulation).
>
> GWT 2.8 removes deRPC (direct-eval RPC) mechanism but that's OK because
> we're already using the standard GWT RPC [4].
>
> [4] https://gerrit.ovirt.org/#/c/65735/
>
> There are no changes to existing build & development process:
> - debugging via Java IDE (aka Classic Dev Mode) remains the default debug
> method
> - debugging via browser (aka Super Dev Mode) can be enabled via
> DEV_BUILD_GWT_SUPER_DEV_MODE flag [5]
>
> [5] example: $ make gwt-debug DEBUG_MODULE=webadmin
> DEV_BUILD_GWT_SUPER_DEV_MODE=1
>
> Note that in GWT 2.8 the Super Dev Mode is the new default debug method
> (with Classic Dev Mode being deprecated).
>
> There are still some post-upgrade tasks to do, we're tracking them on
> Trello: https://trello.com/b/o26RrVLz/post-gwt-2-8-upgrade-tasks
>
> If you encounter any issues related to GWT compilation or debugging, let
> me know.
>
> Regards,
> Vojtech
>
>

Congrats for this upgrade and effort.

It is interesting that now Optional and Map are now emulated and it will be
interesting to see how we can improve the value object usage.

What does jsinterop brings in?



> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Introducing engine micro-benchmarks

[Roy Golan]

On Thu, Mar 23, 2017, 12:40 PM Eldad Marciano <emarc...@redhat.com> wrote:

> very cool!
> In terms of scale that sounds great for unit test | benchmarks,
> assume we have some loaded DB. we can create some benchmarks for launching
> vms for example, what do you think will be the challenge ?
>

It is mainly for small chunks of code, without involving integration, like
db, if I understand your proposal correctly, otherwise the deviation will
be too big.

>
> On Thu, Mar 23, 2017 at 12:25 PM Martin Sivak <msi...@redhat.com> wrote:
>
> Hi,
>
> I am just wondering whether you tried Roman's Hystrix integration to
> see what command was so slow?
>
> Martin
>
> On Thu, Mar 23, 2017 at 11:05 AM, Roy Golan <rgo...@redhat.com> wrote:
> > Lately we came across an interesting case where multi-host+mult-networks
> > resulted editing a host to conclude in minutes. One assumption that was
> > raised which we wanted to eliminate was that the decryption we perform
> on a
> > fence agent password might be taking too long.
> >
> > So these days it's an easy task thanks to JMH[1], supplied by the jdk
> > itself. I kickstarted [2] and added a 'DecryptionBenchmark', see the
> output
> > as an example[3]
> >
> > Although The JMH project recommends to create a separate project I find
> it
> > would be less trivial to people to contribute benchmarks let alone just
> > playing around with current code they want to test.
> >
> > - So, (when it will be merged) you add your benchmark under
> >  backend/manager/modules/benchmarks/MyBenchmark.java
> >
> > - run it from intellij using the jmh plugin exactly like a unit-test
> > OR
> > - mvn test -P benchmarks -pl org.ovirt.engine:benchmarks
> > OR
> > - java -jar benchmarks.jar
> >
> > I hope this would serve all of us well, please review and add your
> > benchmarks.
> >
> > PS - this will not run in the CI atm.
> >
> > [1] http://openjdk.java.net/projects/code-tools/jmh/
> > [2] https://gerrit.ovirt.org/74537 microbenchmarks: Introduce
> > microbenchmarks using JMH
> > [3] DecryptionBenchmark output (short version):
> >
> > # Run complete. Total time: 00:09:06
> >
> > Benchmark Mode  SamplesScore  Score error
> > Units
> > b.DecryptionBenchmark.decryption thrpt   50  101.2581.270
> > ops/s
> > b.DecryptionBenchmark.encryption thrpt   50  238.5874.667
> > ops/s
> > b.DecryptionBenchmark.decryption  avgt   500.0100.000
> > s/op
> > b.DecryptionBenchmark.encryption  avgt   500.0040.000
> > s/op
> > b.DecryptionBenchmark.decryptionsample 55440.0100.000
> > s/op
> > b.DecryptionBenchmark.encryptionsample130670.0040.000
> > s/op
> > b.DecryptionBenchmark.decryptionss   500.0140.001
> > s
> > b.DecryptionBenchmark.encryptionss   500.0090.001
> > s
> >
> > Process finished with exit code 0
> >
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Introducing engine micro-benchmarks

[Roy Golan]

On Thu, Mar 23, 2017 at 3:17 PM Greg Sheremeta <gsher...@redhat.com> wrote:

> +1, any plans to get this into CI and perhaps using statistics (standard
> deviation) to give us warnings?
>
> Still didn't work the details of producing reports from that. There is a
jenkins-jmh plugin  that can help https://github.com/blackboard/jmh-jenkins
. If anyone has experience with something similar I'd be happy to hear
about it.

I still want to build something like BrowserLab [4], and I'm currently
> working on
>
selenium + phantomjs in OST.
>

I'm very interested in this work. Thanks.


>
> Greg
>
> [4]
> https://code.facebook.com/posts/1368798036482517/browserlab-automated-regression-detection-for-the-web/
>
> On Thu, Mar 23, 2017 at 6:40 AM, Eldad Marciano <emarc...@redhat.com>
> wrote:
>
> very cool!
> In terms of scale that sounds great for unit test | benchmarks,
> assume we have some loaded DB. we can create some benchmarks for launching
> vms for example, what do you think will be the challenge ?
>
> On Thu, Mar 23, 2017 at 12:25 PM Martin Sivak <msi...@redhat.com> wrote:
>
> Hi,
>
> I am just wondering whether you tried Roman's Hystrix integration to
> see what command was so slow?
>
> Martin
>
> On Thu, Mar 23, 2017 at 11:05 AM, Roy Golan <rgo...@redhat.com> wrote:
> > Lately we came across an interesting case where multi-host+mult-networks
> > resulted editing a host to conclude in minutes. One assumption that was
> > raised which we wanted to eliminate was that the decryption we perform
> on a
> > fence agent password might be taking too long.
> >
> > So these days it's an easy task thanks to JMH[1], supplied by the jdk
> > itself. I kickstarted [2] and added a 'DecryptionBenchmark', see the
> output
> > as an example[3]
> >
> > Although The JMH project recommends to create a separate project I find
> it
> > would be less trivial to people to contribute benchmarks let alone just
> > playing around with current code they want to test.
> >
> > - So, (when it will be merged) you add your benchmark under
> >  backend/manager/modules/benchmarks/MyBenchmark.java
> >
> > - run it from intellij using the jmh plugin exactly like a unit-test
> > OR
> > - mvn test -P benchmarks -pl org.ovirt.engine:benchmarks
> > OR
> > - java -jar benchmarks.jar
> >
> > I hope this would serve all of us well, please review and add your
> > benchmarks.
> >
> > PS - this will not run in the CI atm.
> >
> > [1] http://openjdk.java.net/projects/code-tools/jmh/
> > [2] https://gerrit.ovirt.org/74537 microbenchmarks: Introduce
> > microbenchmarks using JMH
> > [3] DecryptionBenchmark output (short version):
> >
> > # Run complete. Total time: 00:09:06
> >
> > Benchmark Mode  SamplesScore  Score error
> > Units
> > b.DecryptionBenchmark.decryption thrpt   50  101.2581.270
> > ops/s
> > b.DecryptionBenchmark.encryption thrpt   50  238.5874.667
> > ops/s
> > b.DecryptionBenchmark.decryption  avgt   500.0100.000
> > s/op
> > b.DecryptionBenchmark.encryption  avgt   500.0040.000
> > s/op
> > b.DecryptionBenchmark.decryptionsample 55440.0100.000
> > s/op
> > b.DecryptionBenchmark.encryptionsample130670.0040.000
> > s/op
> > b.DecryptionBenchmark.decryptionss   500.0140.001
> > s
> > b.DecryptionBenchmark.encryptionss   500.0090.001
> > s
> >
> > Process finished with exit code 0
> >
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
>
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gsher...@redhat.com
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel