[ovirt-devel] Re: ovirt-containers - is this project still alive?

[Juan Hernández]

I'd say it is completely abandoned, and safe to remove.

On 1/18/19 11:54 AM, Sandro Bonazzola wrote:
> Hi,
> I was removing 4.1 jenkins job and found out a 4.1 job for
> ovirt-containers project.
> Owners are Fabian Deutsch and Evgheni Dereveanchin, in CC.
> Contributors are Juan Hernandez and Simone Tiraboschi.
> I see no activity there in a while, jobs have not been created for 4.2.
> Is this an abandoned project? Can we drop jenkins jobs at all?
> 
> 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/ZQM4MDNUC5HXZUFNZ3DKI2NDVEG4F5K6/

Re: [ovirt-devel] Memory size (1024MB) cannot exceed maximum memory size (0MB).] - when trying to create an instance type

[Juan Hernández]

On 12/25/2017 05:46 PM, Yaniv Kaul wrote:

While trying to add an instance type, I fail with the error:
Operation Failed". Fault detail is "[Cannot add Template. Memory size
(1024MB) cannot exceed maximum memory size (0MB).]

The code is taken from the example in the SDK, so I'm not sure what I'm
doing wrong here.
Code:
 instance_types_service.add(
 types.InstanceType(
 name='myinstancetype',
 description='My instance type',
 memory=1 * 2**30,
 high_availability=types.HighAvailability(
 enabled=True,
 ),
 cpu=types.Cpu(
 topology=types.CpuTopology(
 cores=2,
 sockets=2,
 ),
 ),
 ),
 )


engine.log:
2017-12-25 10:58:19,825-05 INFO
[org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-13)
[265ff704-d89f-471b-8207-fc0e1b8816fd] Lock Acquired to object
'EngineLock:{exclusiveLocks='[myinstancetype=TEMPLATE_NAME,
703e1265-e160-4a76-82e6-06974156b7b9=TEMPLATE]', sharedLocks='[]'}'
2017-12-25 10:58:19,831-05 WARN
[org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-13)
[265ff704-d89f-471b-8207-fc0e1b8816fd] Validation of action 'AddVmTemplate'
failed for user admin@internal-authz. Reasons:
VAR__ACTION__ADD,VAR__TYPE__VM_TEMPLATE,ACTION_TYPE_FAILED_MAX_MEMORY_CANNOT_BE_SMALLER_THAN_MEMORY_SIZE,$maxMemory
0,$memory 1024
2017-12-25 10:58:19,832-05 INFO
[org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-13)
[265ff704-d89f-471b-8207-fc0e1b8816fd] Lock freed to object
'EngineLock:{exclusiveLocks='[myinstancetype=TEMPLATE_NAME,
703e1265-e160-4a76-82e6-06974156b7b9=TEMPLATE]', sharedLocks='[]'}'
2017-12-25 10:58:19,839-05 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(default task-13) [265ff704-d89f-471b-8207-fc0e1b8816fd] method: runAction,
params: [AddVmTemplate,
AddVmTemplateParameters:{commandId='179df9ed-209c-4882-a19a-b76a4fe1adb8',
user='null', commandType='Unknown'}], timeElapsed: 33ms
2017-12-25 10:58:19,846-05 ERROR
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default
task-13) [] Operation Failed: [Cannot add Template. Memory size (1024MB)
cannot exceed maximum memory size (0MB).]


TIA,
Y.



I think this is related to the new `memory_policy.max` attribute that 
was introduced in 4.1. I think that for virtual machines it has a 
default value so that it isn't necessary to explicitly provide it. It 
may not have a default value fro instance types. Can you try adding this 
to the request to create the instance type?


  memory_policy=types.MemoryPolicy(
max=1 * 2**30
  )

Then try again. If it works I think that we need to fix the engine so 
that it assigns a default value, like it does for virtual machines.

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

Re: [ovirt-devel] upgrade_check and upgrade API calls (v4)

[Juan Hernández]

On 12/25/2017 04:21 PM, Yaniv Kaul wrote:

I'm trying to check if a certain host can be upgraded.
1. I'm calling it through the host_service, something like:

host_service = connection.system_service().hosts_service().host_service(
host.id)
is_upgrade = host_service.upgrade_check()

To my surprise, is_upgrade is None. I expected a Boolean.

2. In addition, when trying to upgrade via:
host_service.upgrade()

I'm getting Operation Failed - and it complains there are no upgrades
available.
Alas, in the UI it shows that upgrades available and upgrade does work
through the UI.

Am I misusing the functions?
(The host is a regular host, not ovirt-node btw).

TIA,
Y.



The "upgrade_check" method doesn't return anything, it just triggers the 
execution of the process to check for upgrades. Then only result will be 
that an icon will be displayed in the UI.


That isn't very useful, to be honest, so I'd suggest to open a bug to 
modify this so that the upgrade runs synchronously, and so that the 
method returns the boolean that you expected.

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

Re: [ovirt-devel] ovirt-engine 4.2.0 respin

[Juan Hernández]

On 12/11/2017 10:15 AM, Sandro Bonazzola wrote:

Hi,
a few blockers have been fixed since ovirt-engine-4.2.0 tag so we need to
respin for RC2.
On master a few patches have been merged targeting 4.2.1, here's the
changelog:

fetching 1488853
  - [BZ 1488853](https://bugzilla.redhat.com/1488853) - While downloading
disk the cancel/pause upload button should be disabled
fetching 1506547
1506547 - is in status POST and targeted to ovirt-4.1.9; assignee:
ybron...@redhat.com
fetching 1512911
  - [BZ 1512911](https://bugzilla.redhat.com/1512911) - Internal server
Error on incorrect headers
fetching 1513800
  - [BZ 1513800](https://bugzilla.redhat.com/1513800) - Localdisk hook must
prevent VM from being snapshot.
fetching 1517094
  - [BZ 1517094](https://bugzilla.redhat.com/1517094) - after redesign, the
detach vm from pool button disappeared
fetching 1517974
  - [BZ 1517974](https://bugzilla.redhat.com/1517974) - [AAA] Locale
selector on welcome page doesn't work when using http
fetching 1518702
  - [BZ 1518702](https://bugzilla.redhat.com/1518702) - Webadmin -  ImageIO-
UI - canceling failed upload is not possible via 'upload' button  but only
via 'download' button
fetching 1519246
1519246 - is in status POST and targeted to ovirt-4.2.1; assignee:
slev...@redhat.com
fetching 1520387
1520387 - is in status POST and targeted to ovirt-4.2.1; assignee:
slev...@redhat.com
fetching 1523072
  - [BZ 1523072](https://bugzilla.redhat.com/1523072) - Cannot export a VM
to an export domain when specifying the storage domain by its name
(Incomplete lookup for method signature)
fetching 1523253
  - [BZ 1523253](https://bugzilla.redhat.com/1523253) - When canceling a
download, the engine finalizes the operation as if it was completed
successfully
fetching 1523415
  - [BZ 1523415](https://bugzilla.redhat.com/1523415) - Error while
executing action Edit VM properties: Internal Engine Error

So we need to branch from ovirt-engine-4.2.0 tag and cherry-pick 4.2.0
patches.

I'm going to create the branch now.



What will be the name of that branch?
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Juan Hernández]

On 11/22/2017 12:40 PM, Dafna Ron wrote:

Hi,

I am not sure we should be alerting on 4.2 versions yet but since we are
getting several cq failures for the same reasons and test, I decided
this should be communicated.

The failed test is 002_bootstrap.add_dc in OST 4.2. and all are pointing
to one patch.

Remove mandatory option for cluster in register operation -
https://gerrit.ovirt.org/#/c/84359/*
*

can you please have a look?

I was unable to determine from what log the error was coming from as
well but looking at the failed test and the patch reported there seem to
be a connection.



It is almost impossible that that patch causes that problem. That patch 
is included in a release of the specification of the API that the engine 
and the SDKs aren't using yet.


The stack trace below looks similar to a recent problem in version 4.2 
(not yet released) of the Python SDK, which was fixed by this patch:


  No exceptions when 'raise_exception=False'
  https://gerrit.ovirt.org/83565

Please make sure that you use either a released version of the SDK, or 
else a pre-release build that contains that fix. Latest build from 
Jenkins should work fine.



**

*Link and headline of suspected patches: *

**

Patch that is marked as root cause:

Remove mandatory option for cluster in register operation -
https://gerrit.ovirt.org/#/c/84359/*
*

Patches reported as failed:
1. Add discoveredTargets property to HostService -
https://gerrit.ovirt.org/#/c/84489/

*2. Document the fact that sparse/raw isn't supported on block -
https://gerrit.ovirt.org/#/c/84490/*

3. Update CHANGES.adoc for release 4.2.25 -
https://gerrit.ovirt.org/#/c/84499/*
*

4. [maven-release-plugin] prepare release 4.2.26 -
https://gerrit.ovirt.org/#/c/84500/*
*

**

*

Link to Job:

http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/*

*
*

*Link to all logs:*

*http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/75/artifact/*

*
*

*(Relevant) error snippet from the log: *

*





*

Traceback (most recent call last):
   File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
 testMethod()
   File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 129, in 
wrapped_test
 test()
   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in 
wrapper
 return func(get_test_prefix(), *args, **kwargs)
   File 
"/home/jenkins/workspace/ovirt-4.2_change-queue-tester/ovirt-system-tests/basic-suite-4.2/test-scenarios/002_bootstrap.py",
 line 109, in add_dc
 api = prefix.virt_env.engine_vm().get_api(api_ver=4)
   File "/usr/lib/python2.7/site-packages/ovirtlago/virt.py", line 329, in 
get_api
 return self.get_api_v4()
   File "/usr/lib/python2.7/site-packages/ovirtlago/virt.py", line 338, in 
get_api_v4
 self._api_v4 = self._get_api(api_ver=4)
   File "/usr/lib/python2.7/site-packages/ovirtlago/virt.py", line 316, in 
_get_api
 while not testapi.test():
   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 744, 
in test
 six.reraise(*sys.exc_info())
   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 741, 
in test
 self.system_service().get()
   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 21865, 
in get
 return self._internal_get(headers, query, wait)
   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 202, in 
_internal_get
 context = self._connection.send(request)
   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 370, 
in send
 return self.__send(request)
   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 388, 
in __send
 self.authenticate()
   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 381, 
in authenticate
 self._sso_token = self._get_access_token()
   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 617, 
in _get_access_token
 sso_response = self._get_sso_response(self._sso_url, post_data)
   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 702, 
in _get_sso_response
 self._check_content_type(self.__JSON_CONTENT_TYPE_RE, 'JSON', header_lines)
   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 887, 
in _check_content_type
 raise Error(msg)
Error: The response content type 'text/html; charset=UTF-8' isn't the expected 
JSON

**

**

**





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

Re: [ovirt-devel] failure in CQ due to failed build artifacts

[Juan Hernández]

On 09/27/2017 03:51 PM, Dafna Ron wrote:

hi,

we have some failures in CQ and they seem to be related to failure to
build engine packages.


1. first failure reported:
http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64/5313/

This happened due to failed build:
http://jenkins.ovirt.org/job/ovirt-engine_master_build-artifacts-el7-x86_64/5313/

The failure was:http://pastebin.test.redhat.com/519819

The following builds succeeded.


2. Other failures reported:

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

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

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

This was because of:
http://jenkins.ovirt.org/job/ovirt-engine-api-explorer_master_build-artifacts-el7-x86_64/42/

Error is: http://pastebin.test.redhat.com/519844

Please note, there are two failed attempts after this failure with the
same error.



Those build failure have been fixed by the following patch:

  Fix build issues
  https://gerrit.ovirt.org/82312


Thanks,

Dafna


___
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] Fwd: [rhev-devel] latest ovirt-engine-sdk for fedora 24 location

[Juan Hernández]

The requirement for a newer version of python-pycurl is only for Fedora 
25 or newer, because of this bug:


  engine-python-sdk4 still fails running until updating libcurl on 
fedora 25

  https://bugzilla.redhat.com/1456477

It doesn't affect Fedora 24 because the python-pycurl package was not, 
and will not, be updated.


The problem is that you are trying to build the package for Fedora 24 
using the Fedora 25 .spec. You can build it yourself, from source, and 
using the Fedora 24 .spec. I did that for you, the result is here:


  https://jhernand.fedorapeople.org/rpms

You can install it like this:

  # yum install 
https://jhernand.fedorapeople.org/rpms/python-ovirt-engine-sdk4-4.2.1-1.a1.20170923git43ac4e8.fc24.x86_64.rpm


I also think that staying in Fedora 24 is bad idea, I'd strongly suggest 
you to upgrade.


On 09/23/2017 11:14 AM, Avihai Efrat wrote:

Hi Guys ,

I'm looking for latest master ovirt-engine-sdk for Fedora 24 for testing
purposes.

Looking at resources.ovirt.org site I see it exist for fedora25 but not for
Fedora 24 .

Fedora 25 link:
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/
fc25/x86_64/python-ovirt-engine-sdk4-4.2.1-1.a1.20170906git43ac4e8.fc25.x86_
64.rpm

Fedora 24 link:
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/


I also tried to rebuild latest src.rpm ( As Sandro suggested , see thread
below) but python-pycurl >= 7.43.0-6 is needed & the only matching
python-pycurl for Fedora24 is python-pycurl 7.43.0-2.

*Is there any work around this or am I doomed to upgrade to fc25/26 ? *

Thanks,
Avihai

-- Forwarded message --
From: Avihai Efrat 
Date: Sat, Sep 23, 2017 at 8:16 AM
Subject: Re: [rhev-devel] latest ovirt-engine-sdk for fedora 24 location
To: Sandro Bonazzola 
Cc: rhev-devel 


Thanks Sandro!

I rebuilt latest src.rpm successfully & tried to yum install the rebuilt
rpm but now I fail with :
* python-pycurl >= 7.43.0-6 needed* by python-ovirt-engine-sdk4-4.2.
1-1.a1.20170906git43ac4e8.fc24.x86_64

I checked & the only matching python-pycurl for Fedora24 is
python-pycurl 7.43.0-2.
*python-pycurl* *>= 7.43.0-6 exist only on fc25/26.*

Is there any work around this or am I doomed to upgrade to fc25/26 ?

On Fri, Sep 22, 2017 at 8:46 AM, Sandro Bonazzola 
wrote:




2017-09-22 6:42 GMT+02:00 Avihai Efrat :



Hi Guys ,

I'm looking for latest master ovirt-engine-sdk for Fedora 24 for testing
purposes.

Looking at resources.ovirt.org site I see it exist for fedora25 but not
for Fedora 24 .

Fedora 25 link:
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc2
5/x86_64/python-ovirt-engine-sdk4-4.2.1-1.a1.20170906git43ac
4e8.fc25.x86_64.rpm

Fedora 24 link:
http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/




Fedora 24 is EOL. On master we are providing fedora >= 25 builds and we
are now shifting to Fedora >= 26.
You can take the latest src.rpm and rpmbuild --rebuild it on fedora 24.





--

Regards ,


Avihai EFRAT

SENIOR QUALITY ENGINEER

Red Hat Israel Ltd. 

34 Jerusalem Road, Building A, 1st floor 


Ra'anana, Israel 4350109

aef...@redhat.comT: +972-9-7692170/8272170
   TRIED. TESTED. TRUSTED. 





--

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R

Red Hat EMEA 

TRIED. TESTED. 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-engine-api-model] s390 prerequisite changes

[Juan Hernández]

On 09/22/2017 01:20 PM, Viktor Mihajlovski wrote:

Hi,

I've submitted the following topic branch with changes to the API model
needed for the s390 support in ovirt-engine.

https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine-api-model+branch:master+topic:s390-base

Without these ovirt-engine will fail to build. Should I still go ahead
and push my changes for ovirt-engine, or should I wait for these commits
to be merged (and actually published)?



The changes look good, and they need some documentation.

We need to decide when these changes should be merged to the 
specification of the API. Do you plan to complete your work for version 
4.2 of the engine? I guess not, as we are currently in alpha state 
already. If you plan to complete the feature for version 4.3 of the 
engine then I'd rather wait till a branch of the ovirt-engine-api-model 
is created for version 4.2 of the engine (that will happen soon, in a 
few days), then we can merge your changes to the master branch, which 
will be used for version 4.3 of the engine.


Meanwhile you can submit your changes for the engine. They builds in 
Jenkins will fail, but we can review them anyhow.

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

Re: [ovirt-devel] Subject: [ OST Failure Report ] [ master ] [20-09-2017 ] [ post-002_bootstrap.py ]

[Juan Hernández]

That SDK patch is for the *Ruby* SDK, which isn't used in OST, so I 
think it isn't related.


On 09/20/2017 02:11 PM, Martin Perina wrote:

Ondro, could you please take a look?

On Wed, Sep 20, 2017 at 1:07 PM, Dafna Ron  wrote:


Hi,

We have a failure in test post-002_bootstrap.py

from the logs I can see that lago has an unhandled exception from ovirt
sdk which makes sense since the patch reported on CQ is a change to the
sdk.

*Link to suspected patches: https://gerrit.ovirt.org/#/c/82022/
*

* Link to Job:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2734
 Link
to all logs:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2734/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-002_bootstrap.py/

(Relevant) error snippet from the log:  2017-09-20
09:17:15,676::testlib.py::assert_equals_within::227::ovirtlago.testlib::ERROR::
* Unhandled exception in  Traceback
(most recent call last):   File
"/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 219, in
assert_equals_within res = func()   File
"/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
line 338, in _host_is_up_4 host_status = host_service.get().status
File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line
31529, in get return self._internal_get(headers, query, wait)   File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 202, in
_internal_get return future.wait() if wait else future   File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 53, in wait
 return self._code(response)   File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 199, in
callback self._check_fault(response)   File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 121, in
_check_fault body = self._internal_read_body(response)   File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 307, in
_internal_read_body self._connection.check_xml_content_type(response)
File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 800,
in check_xml_content_type response.headers   File
"/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line 840, in
_check_content_type raise Error(msg) Error: The response content type
'text/html; charset=iso-8859-1' isn't the expected XML 2017-09-20
09:17:15,683::utils.py::wrapper::480::lago.utils::DEBUG::Looking for a
workdir  Thanks, *

Dafna

___
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] s390 draft patches submitted for review

[Juan Hernández]

On 09/18/2017 05:31 PM, Viktor Mihajlovski wrote:

Hi,

I have submitted a topic branch containing the changes necessary to
enable support for the s390 arch in VDSM and would appreciate your
feedback, not only for the code, but also on the procedure:

1. I've submitted the patches as draft, following the suggestions on the
homepage. Not sure whether this is really required.

2. The individual commits are actually tiny, let me know whether this is
OK, or you prefer a single commit.

3. Topic branch here: https://gerrit.ovirt.org/#/q/topic:s390-base



Note that draft changes are generally OK, but they have the inconvenient 
that they are invisible for people that isn't explicitly added as 
reviewers. So you will need to either promote them to regular patches, 
maybe adding a [WIP] prefix to the subject, or else explicitly add 
reviewers, otherwise nobody will see them.

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

Re: [ovirt-devel] Unable to access REST api

[Juan Hernández]

On 09/05/2017 08:49 PM, Marc Young wrote:

While attempting to run some code using the ruby SDK i was never able to
log in successfully (despite being logged into the Administrator portal)

I was met with an SSO error[1].
I then attempted to get to the REST docs (/ovirt-engine/api/v4/model) and
was unable to log in there as well.

Im now locked out of the administrator portal with the error:

  Cannot Login. User Account is Disabled or Locked, Please contact your
system administrator.


a) what did i do wrong per the ruby sdk to lock myself out


Maybe used a wrong password multiple times? I think what we lock the 
account after certain number of failed login attempts.



b) how can i unlock my admin account?


In the engine machine use the "ovirt-aaa-jdbc-tool" command:

  # ovirt-aaa-jdbc-tool user unlock admin

Martin, Ondra, can you confirm?


c) how can i prevent this from locking me out in the future?


Make sure that you don't use wrong passwords.

If you still have problems, enable the debug option of the SDK and share 
the generated log, so we can see what is happening. Be aware that the 
debug log will contain your password.




Server version is 4.1.0.4-1.el7.centos

[1]

Bringing machine 'default' up with 'ovirt4' provider...
==> default: Creating VM with the following settings...
==> default:  -- Name:  jenkins
==> default:  -- Cluster:   Default
==> default:  -- Template:  centos-6-x86_64-v1608
==> default:  -- Console Type:  vnc
==> default:  -- BIOS Serial:
==> default:  -- Memory:
==> default:   Memory:  2048 MB
==> default:   Maximum: 2048 MB
==> default:   Guaranteed:  2048 MB
==> default:  -- Cpu:
==> default:   Cores:   1
==> default:   Sockets: 1
==> default:   Threads: 1
==> default:  -- Cloud-Init:true
==> default: An error occured. Recovering..
==> default: VM is not created. Please run `vagrant up` first.
/home/myoung/.rvm/gems/ruby-2.3.1/gems/ovirt-engine-sdk-4.1.8/lib/ovirtsdk4/connection.rb:266:in
`create_access_token': Error during SSO authentication: access_denied:
Cannot authenticate user 'admin@internal': Cannot Login. User Account is
Disabled or Locked, Please contact your system administrator..
(OvirtSDK4::Error)
 from
/home/myoung/.rvm/gems/ruby-2.3.1/gems/ovirt-engine-sdk-4.1.8/lib/ovirtsdk4/connection.rb:217:in
`send'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/gems/ovirt-engine-sdk-4.1.8/lib/ovirtsdk4/service.rb:172:in
`internal_add'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/gems/ovirt-engine-sdk-4.1.8/lib/ovirtsdk4/services.rb:29450:in
`add'
 from
/home/myoung/repos/github/vagrant-ovirt4/lib/vagrant-ovirt4/action/create_vm.rb:68:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/warden.rb:34:in
`call'
 from
/home/myoung/repos/github/vagrant-ovirt4/lib/vagrant-ovirt4/action/set_name_of_domain.rb:17:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/warden.rb:34:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/warden.rb:95:in
`block in finalize_action'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/warden.rb:34:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/builder.rb:116:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/runner.rb:66:in
`block in run'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/util/busy.rb:19:in
`busy'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/runner.rb:66:in
`run'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/builtin/call.rb:53:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/warden.rb:34:in
`call'
 from
/home/myoung/repos/github/vagrant-ovirt4/lib/vagrant-ovirt4/action/connect_ovirt.rb:31:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/warden.rb:34:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/builtin/config_validate.rb:25:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/warden.rb:34:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/builtin/handle_box.rb:56:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/warden.rb:34:in
`call'
 from
/home/myoung/.rvm/gems/ruby-2.3.1/bundler/gems/vagrant-4572267c33f4/lib/vagrant/action/builder.rb:116:in
`call'
 

Re: [ovirt-devel] [ oVirt Devel ] [oVirt master ] [ OST Failure Report ] [ basic_suite_master & upgrade_suites failed ]

[Juan Hernández]

That failure was cased by this patch:

  restapi: Update to model 4.2.16 and metamodel 1.2.10
  https://gerrit.ovirt.org/81134

And fixed by this one:

  restapi: Add metamodel-server to restapi-definition module
  https://gerrit.ovirt.org/81175

On 08/30/2017 09:09 AM, Daniel Belenky wrote:

*Test Failed:*

1. *basic_suite: *002_bootstrap.add_dc and
2. *upgrade_from_release: *001_upgrade_engine.test_initialize_engine
3. *upgrade_from_prevrelease*:

*Link to test logs:*

1. *basic suite logs

*
2. *upgrade from prev release suite logs

*
3. *upgrade from release suite logs

*


*Suspected patch: https://gerrit.ovirt.org/#/c/79033/41
*


*Please note that this change was the only change under those tests.*
*Error snippet from basic-suite /var/log/ovirt-engine/server.log:*

ERROR [io.undertow.request] (default task-5) UT005023: Exception
handling request to /ovirt-engine/api/v4/datacenters:
java.lang.RuntimeException: org.jboss.resteasy.spi.UnhandledException:
java.lang.NoClassDefFoundError:
org/ovirt/api/metamodel/server/ValidationException
at 
io.undertow.servlet.spec.RequestDispatcherImpl.forwardImpl(RequestDispatcherImpl.java:245)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
io.undertow.servlet.spec.RequestDispatcherImpl.forwardImplSetup(RequestDispatcherImpl.java:147)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:111)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
org.ovirt.engine.api.restapi.invocation.VersionFilter.doFilter(VersionFilter.java:180)
[restapi-jaxrs.jar:]
at 
org.ovirt.engine.api.restapi.invocation.VersionFilter.doFilter(VersionFilter.java:98)
[restapi-jaxrs.jar:]
at 
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
org.ovirt.engine.api.restapi.invocation.CurrentFilter.doFilter(CurrentFilter.java:117)
[restapi-jaxrs.jar:]
at 
org.ovirt.engine.api.restapi.invocation.CurrentFilter.doFilter(CurrentFilter.java:72)
[restapi-jaxrs.jar:]
at 
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
org.ovirt.engine.core.aaa.filters.RestApiSessionMgmtFilter.doFilter(RestApiSessionMgmtFilter.java:78)
[aaa.jar:]
at 
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
org.ovirt.engine.core.aaa.filters.EnforceAuthFilter.doFilter(EnforceAuthFilter.java:42)
[aaa.jar:]
at 
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
org.ovirt.engine.core.aaa.filters.SsoRestApiNegotiationFilter.doFilter(SsoRestApiNegotiationFilter.java:84)
[aaa.jar:]
at 
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
org.ovirt.engine.core.aaa.filters.SsoRestApiAuthFilter.doFilter(SsoRestApiAuthFilter.java:47)
[aaa.jar:]
at 
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 
org.ovirt.engine.core.aaa.filters.SessionValidationFilter.doFilter(SessionValidationFilter.java:59)
[aaa.jar:]
at 
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
[undertow-servlet-1.4.18.Final.jar:1.4.18.Final]
at 

Re: [ovirt-devel] Memory stats in VDSM

[Juan Hernández]

On 08/28/2017 02:05 PM, Michal Skrivanek wrote:



On 28 Aug 2017, at 14:02, Juan Hernández <jhern...@redhat.com> wrote:

On 08/28/2017 01:57 PM, Juan Hernández wrote:

On 08/28/2017 01:42 PM, Michal Skrivanek wrote:



On 28 Aug 2017, at 13:37, Juan Hernández <jhern...@redhat.com> wrote:

On 08/28/2017 01:11 PM, Tomáš Golembiovský wrote:

Hi,
there is ongoing effort to change how VDSM collects information about
memory usage from guests. We used to use oVirt guest agent to get the
statistics about free memory, swap usage, etc. This is going to change
and we will use stats provided by VirtIO Balloon driver. [1] This should
not break MOM nor Engine (current or previous versions).
There is however small downside to this change. We will not be able to
fetch information about buffers and caches on Linux guests anymore
(mem_cached and mem_buffers in memoryStats). The corollary of this is
that free memory reported by Engine will also no longer include those
statistics and reported free memory will be really (only) free memory.
I now there will be mixed feelings about this and we would like to get
the information about buffers and caches back to the VDSM. Correctly via
balloon driver statistics. [2] This effort will however take some time.
 Tomas
[1] https://gerrit.ovirt.org/#/q/topic:memory-stats
[2] https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg05239.html


Note that this information is currently reported by the engine REST API, so it 
is part of its contract. Removing it breaks backwards compatibility and causes 
a regression in this RFE:


we can either declare it deprecated or temporarily report 0 until the support 
propagates into qemu-ga


So there will be an interval of time where it will not be reported? Will that 
affect released versions of the system or it is just something that we will 
re-add before the next release? It is released versions of the system that I am 
concerned about. We should not do a release that breaks backwards 
compatibility. It is completely OK if we break it in between releases.

I think best way forward is to just make it optionally available when 
ovirt-guest-agent reports it.
I.e. users will get only part of the information when they run only qemu-ga, 
and that’s fine…



Not sure I understand this. Currently, if I understand correctly, these values 
are only populated if the ovirt-guest-agent is installed? That is OK (may be 
worth documenting it). We plan to replace ovirt-guest-agent with qemu-ga in a 
mandatory way? Or will the user be able to use one or the other?


both are mandatory today, though not really enforced, there’s just a “!” next 
to the VM in the VMs grid.
The plan is to switch data retrieval to qemu-ga and make ovirt-ga optional 
(it’s going to be mandatory for specific purposes, like SSO)


If the user decides to use the ovirt-guest-agent, will we continue to report 
these statistics?


yes, I expect so



OK, in that case I think there is no problem in doing this change, from 
the API point of view. I'd just suggest to explicitly document in the 
specification of the API that these statistics will only be available if 
the ovirt-guest-agent is installed. I mean here:



https://github.com/oVirt/ovirt-engine-api-model/blob/4b85ea1305d43ce9ec4221955c8fa2c8e099cd69/src/main/java/types/Vm.java#L412-L419


Thanks,
michal





  [RFE] Report guests Buffered/Cached memory
  https://bugzilla.redhat.com/1024010






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

Re: [ovirt-devel] Memory stats in VDSM

[Juan Hernández]

On 08/28/2017 01:57 PM, Juan Hernández wrote:

On 08/28/2017 01:42 PM, Michal Skrivanek wrote:



On 28 Aug 2017, at 13:37, Juan Hernández <jhern...@redhat.com> wrote:

On 08/28/2017 01:11 PM, Tomáš Golembiovský wrote:

Hi,
there is ongoing effort to change how VDSM collects information about
memory usage from guests. We used to use oVirt guest agent to get the
statistics about free memory, swap usage, etc. This is going to change
and we will use stats provided by VirtIO Balloon driver. [1] This 
should

not break MOM nor Engine (current or previous versions).
There is however small downside to this change. We will not be able to
fetch information about buffers and caches on Linux guests anymore
(mem_cached and mem_buffers in memoryStats). The corollary of this is
that free memory reported by Engine will also no longer include those
statistics and reported free memory will be really (only) free memory.
I now there will be mixed feelings about this and we would like to get
the information about buffers and caches back to the VDSM. Correctly 
via

balloon driver statistics. [2] This effort will however take some time.
 Tomas
[1] https://gerrit.ovirt.org/#/q/topic:memory-stats
[2] 
https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg05239.html


Note that this information is currently reported by the engine REST 
API, so it is part of its contract. Removing it breaks backwards 
compatibility and causes a regression in this RFE:


we can either declare it deprecated or temporarily report 0 until the 
support propagates into qemu-ga




So there will be an interval of time where it will not be reported? Will 
that affect released versions of the system or it is just something that 
we will re-add before the next release? It is released versions of the 
system that I am concerned about. We should not do a release that breaks 
backwards compatibility. It is completely OK if we break it in between 
releases.


I think best way forward is to just make it optionally available when 
ovirt-guest-agent reports it.
I.e. users will get only part of the information when they run only 
qemu-ga, and that’s fine…




Not sure I understand this. Currently, if I understand correctly, these 
values are only populated if the ovirt-guest-agent is installed? That is 
OK (may be worth documenting it). We plan to replace ovirt-guest-agent 
with qemu-ga in a mandatory way? Or will the user be able to use one or 
the other? If the user decides to use the ovirt-guest-agent, will we 
continue to report these statistics?




  [RFE] Report guests Buffered/Cached memory
  https://bugzilla.redhat.com/1024010





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

Re: [ovirt-devel] Memory stats in VDSM

[Juan Hernández]

On 08/28/2017 01:42 PM, Michal Skrivanek wrote:



On 28 Aug 2017, at 13:37, Juan Hernández <jhern...@redhat.com> wrote:

On 08/28/2017 01:11 PM, Tomáš Golembiovský wrote:

Hi,
there is ongoing effort to change how VDSM collects information about
memory usage from guests. We used to use oVirt guest agent to get the
statistics about free memory, swap usage, etc. This is going to change
and we will use stats provided by VirtIO Balloon driver. [1] This should
not break MOM nor Engine (current or previous versions).
There is however small downside to this change. We will not be able to
fetch information about buffers and caches on Linux guests anymore
(mem_cached and mem_buffers in memoryStats). The corollary of this is
that free memory reported by Engine will also no longer include those
statistics and reported free memory will be really (only) free memory.
I now there will be mixed feelings about this and we would like to get
the information about buffers and caches back to the VDSM. Correctly via
balloon driver statistics. [2] This effort will however take some time.
 Tomas
[1] https://gerrit.ovirt.org/#/q/topic:memory-stats
[2] https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg05239.html


Note that this information is currently reported by the engine REST API, so it 
is part of its contract. Removing it breaks backwards compatibility and causes 
a regression in this RFE:


we can either declare it deprecated or temporarily report 0 until the support 
propagates into qemu-ga



So there will be an interval of time where it will not be reported? Will 
that affect released versions of the system or it is just something that 
we will re-add before the next release? It is released versions of the 
system that I am concerned about. We should not do a release that breaks 
backwards compatibility. It is completely OK if we break it in between 
releases.



I think best way forward is to just make it optionally available when 
ovirt-guest-agent reports it.
I.e. users will get only part of the information when they run only qemu-ga, 
and that’s fine…



  [RFE] Report guests Buffered/Cached memory
  https://bugzilla.redhat.com/1024010



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

Re: [ovirt-devel] Memory stats in VDSM

[Juan Hernández]

On 08/28/2017 01:11 PM, Tomáš Golembiovský wrote:

Hi,

there is ongoing effort to change how VDSM collects information about
memory usage from guests. We used to use oVirt guest agent to get the
statistics about free memory, swap usage, etc. This is going to change
and we will use stats provided by VirtIO Balloon driver. [1] This should
not break MOM nor Engine (current or previous versions).

There is however small downside to this change. We will not be able to
fetch information about buffers and caches on Linux guests anymore
(mem_cached and mem_buffers in memoryStats). The corollary of this is
that free memory reported by Engine will also no longer include those
statistics and reported free memory will be really (only) free memory.

I now there will be mixed feelings about this and we would like to get
the information about buffers and caches back to the VDSM. Correctly via
balloon driver statistics. [2] This effort will however take some time.

 Tomas


[1] https://gerrit.ovirt.org/#/q/topic:memory-stats
[2] https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg05239.html



Note that this information is currently reported by the engine REST API, 
so it is part of its contract. Removing it breaks backwards 
compatibility and causes a regression in this RFE:


  [RFE] Report guests Buffered/Cached memory
  https://bugzilla.redhat.com/1024010
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] OST failing in 004_basic_sanity add_filter_parameter

[Juan Hernández]

On 06/28/2017 11:14 AM, Milan Zamazal wrote:
> Daniel Belenky  writes:
> 
>> Can you please provide more logs? lago.log and the test_logs dir will
>> assist to get down to the issue
> 
> Hi, I've hit the problem too.  It seems to be as simple as that the
> given method is not defined, we don't know what's missing.  Here is the
> traceback:
> 
>   File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
> testMethod()
>   File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 129, in 
> wrapped_test
> test()
>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in 
> wrapper
> return func(get_test_prefix(), *args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 78, in 
> wrapper
> prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs
>   File 
> "/home/pdm/ovirt/lago/ovirt-system-tests/basic-suite-master/test-scenarios/004_basic_sanity.py",
>  line 414, in add_filter_parameter
> ovirt_api4.system_service())
>   File 
> "/home/pdm/ovirt/lago/ovirt-system-tests/basic-suite-master/test-scenarios/004_basic_sanity.py",
>  line 74, in _get_network_fiter_parameters_service
> return nics_service.nic_service(id=nic.id)\
> AttributeError: 'VmNicService' object has no attribute 
> 'network_filter_parameters_service'
> 
> I'm attaching lago.log, I'll send you test_logs privately not to pollute
> the mailing list.
> 

The network filter parameters concept was added in version 4.2.9 of the
specification of the API. The python SDK is currently using version
4.2.6 of that specification, so that method will simply not be there. We
need to update the SDK to use the newer version of the model, and then
you need to use that new version of the SDK.

> 
> 
> 
>> On Tue, Jun 27, 2017 at 6:16 PM, Valentina Makarova 
>> wrote:
>>
>>> Hello!
>>>
>>> After pull last master branch of ovirt_system_tests 004 test fails
>>> in add_filter_parameter  in basic-suite-master with error:
>>>
>>> AttributeError: 'VmNicService' object has no attribute
>>> 'network_filter_parameters_service'
>>>
>>> After first running fail I updated all yum packages using yum upgrade,
>>> updated lago, lago-ovirt, ovirt-sdk-python
>>> using pip install --upgrade. And I have next version of this packages:
>>> lago (0.39.0), lago-ovirt (0.41.0)
>>> ovirt-engine-sdk-python (4.1.5)
>>> But error is still open. (I run ./run_suilte without -s. and it should
>>> update internal repo)
>>>
>>> Do I forget to update something else?
>>>
>>> Sincerely, Valentina Makarova
>>>
>>> ___
>>> 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] UnboundID LDAP SDK for Java 4.0.0 has been released upstream

[Juan Hernández]

On 06/15/2017 08:36 AM, Sandro Bonazzola wrote:
> Hi,
> just an heads up that a new release of UnboundID LDAP SDK for Java is
> available upstream.
> I'm going to build it for Fedora Rawhide, please let me know if we need
> it for 4.2, requiring a backport to Fedora 25 / 26 and EL7 or if it can
> just stay in Rawhide for ovirt >= 4.3 consumption.
> 
> Here the release
> notes: https://github.com/pingidentity/ldapsdk/releases/tag/4.0.0
> 
> Fedora tracking bug: Bug 1461604
>  - 
> unboundid-ldapsdk-4.0.0
> is available
> 
> Thanks,

Is 4.0 backwards compatible with 3.y.z? Should it be a new whatever4
package?
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Making event types backwards compatible?

[Juan Hernández]

On 05/30/2017 12:11 PM, Oved Ourfali wrote:
> 
> 
> On May 30, 2017 11:28, "Juan Hernández" <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 05/30/2017 09:38 AM, Tomas Jelinek wrote:
> >
>     >
> > On Tue, May 30, 2017 at 9:16 AM, Juan Hernández
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>> wrote:
> >
> > On 05/30/2017 08:55 AM, Tomas Jelinek wrote:
> > >
> > >
> > > On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek
> <mskri...@redhat.com <mailto:mskri...@redhat.com>
> <mailto:mskri...@redhat.com <mailto:mskri...@redhat.com>>
> > > <mailto:mskri...@redhat.com <mailto:mskri...@redhat.com>
> <mailto:mskri...@redhat.com <mailto:mskri...@redhat.com>>>> wrote:
> > >
> > > > On 29 May 2017, at 11:44, Juan Hernández
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>> wrote:
> > > >
> > > >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> > > >>
> > > >>> On 29 May 2017, at 10:39, Juan Hernández
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>> wrote:
> > > >>>
> > > >>> Hello,
> > > >>>
> > > >>> It has been recently requested that the API provides
> event
> > types:
> > > >>>
> > > >>> [RFE] Expose event types to API
> > > >>> https://bugzilla.redhat.com/1453170
> <https://bugzilla.redhat.com/1453170>
> > <https://bugzilla.redhat.com/1453170
> <https://bugzilla.redhat.com/1453170>>
> > > <https://bugzilla.redhat.com/1453170
> <https://bugzilla.redhat.com/1453170>
> > <https://bugzilla.redhat.com/1453170
> <https://bugzilla.redhat.com/1453170>>>
> > > >>>
> > > >>> Currently the API provides the event code and
> description, for
> > > example:
> > > >>>
> > > >>> 
> > > >>>   19
> > > >>>   Host myhost failed to
> recover. > > >>>   ...
> > > >>> 
> > > >>>
> > > >>> There is no documentation of what is the meaning of
> codes,
> > > except the
> > > >>> source code of the engine itself. This forces some
> > applications
> > > to add
> > > >>> their own code to name mapping. For example, the
> 'ovirt' Ruby
> > > gem used
> > > >>> by older versions of ManageIQ to interact with oVirt
> contains
> > > the following:
> > > >>>
> > > >>>
> > >
> > 
> https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485
> 
> <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485>
> >   
>  
> <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485
> 
> <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485>>
> > >
> > 
> 
> <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485
> 
> <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485>
> >   
>  
> <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485
> 
> <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485>>>
> > > >>>

Re: [ovirt-devel] Making event types backwards compatible?

[Juan Hernández]

On 05/30/2017 08:55 AM, Tomas Jelinek wrote:
> 
> 
> On Tue, May 30, 2017 at 7:20 AM, Michal Skrivanek <mskri...@redhat.com
> <mailto:mskri...@redhat.com>> wrote:
> 
>     > On 29 May 2017, at 11:44, Juan Hernández <jhern...@redhat.com 
> <mailto:jhern...@redhat.com>> wrote:
> >
> >> On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> >>
> >>> On 29 May 2017, at 10:39, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> >>>
> >>> Hello,
> >>>
> >>> It has been recently requested that the API provides event types:
> >>>
> >>> [RFE] Expose event types to API
> >>> https://bugzilla.redhat.com/1453170
> <https://bugzilla.redhat.com/1453170>
> >>>
> >>> Currently the API provides the event code and description, for
> example:
> >>>
> >>> 
> >>>   19
> >>>   Host myhost failed to recover. >>>   ...
> >>> 
> >>>
> >>> There is no documentation of what is the meaning of codes,
> except the
> >>> source code of the engine itself. This forces some applications
> to add
> >>> their own code to name mapping. For example, the 'ovirt' Ruby
> gem used
> >>> by older versions of ManageIQ to interact with oVirt contains
> the following:
> >>>
> >>>
> https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485
> 
> <https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485>
> >>>
> >>> We could avoid this by adding to the API a new event attribute that
> >>> indicates the type:
> >>>
> >>> 
> >>>   19
> >>>   host_recover_failure
> >>>   Host myhost failed to recover.
> >>>   ...
> >>> 
> >>>
> >>> Ideally this should be defined as an enum, so that it will be
> >>> represented as an enum in the SDKs. Alternatively it could just
> be an
> >>> string, and we could reuse the 'name' attribute:
> >>>
> >>> 
> >>>   19
> >>>   host_recover_failure
> >>>   Host myhost failed to recover.
> >>>   ...
> >>> 
> >>>
> >>> However, the key point to making this useful would be to keep
> the types
> >>> (or names) backwards compatible, so that users of the API can
> rely on
> >>> their values and meanings.
> >>>
> >>> So this is my question to you: can we commit to keep the names and
> >>> meanings of the backend event types backwards compatible?
> >>
> >> Do we even have to make it bw compatible?
> >> I guess it depends on the actual usage of those names…
> >> The ovirt ruby gem itself doesn’t do much with it
> >
> > We need to make keep it backwards compatible or else tell users "don't
> > rely on these values, as they may change without notice".
> >
> > The 'ovirt' gem doesn't do anything special, it just creates its own
> > code to name mapping. But the users of the 'ovirt' gem (the ManageIQ
> > oVirt provider) do rely on the name. For example:
> >
> >
> > 
> https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models/manageiq/providers/redhat/infra_manager/event_parser.rb#L80-L92
> 
> <https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models/manageiq/providers/redhat/infra_manager/event_parser.rb#L80-L92>
> 
> 
> hmmm, while we are on topic, this pretty much looks like that manageiq
> does not only rely on the code but also on the actual value of it since
> it is parsing it:
> 
> # sample message: "Interface nic1 (VirtIO) was added to VM v5. (User:
> admin@internal-authz)" message.split(/\s/)[7][0...-1]
> 
> Is this something we commit to maintain? Or should we commit to maintain it?
>

That is a good point, that isn't very future proof. We should also find
a way to make less fragile. Any suggestion?

> 
> >
> > That means that if we ever change the meaning of a code the ManageIQ
> > provider, for example, will break.
> 
> Right,then it indeed needs to stay stable.
> But how is mainta

Re: [ovirt-devel] Making event types backwards compatible?

[Juan Hernández]

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

It is true that we could commit to keep the meanings of numeric codes
backwards compatible, and document them somehow. If we commit to do that
then I'd say the issue is mostly solved.

However, if we use an enum we have the additional advantage it is more
readable (in the SDKs in particular) and that the Java compiler would
help us to detect potential backwards compatibility breaking changes. In
addition changes to the enum would need to be done and reviewed in the
specification of the API, which would give us (us == the API
maintainers) the opportunity to review/discuss/document/decide about
them explicitly.

> Perhaps deprecate the code and keep the name fixed?

Yes, that is the idea, if we commit to keep them stable, see the bug.

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

Re: [ovirt-devel] Making event types backwards compatible?

[Juan Hernández]

On 05/29/2017 11:27 AM, Michal Skrivanek wrote:
> 
>> On 29 May 2017, at 10:39, Juan Hernández <jhern...@redhat.com> wrote:
>>
>> Hello,
>>
>> It has been recently requested that the API provides event types:
>>
>>  [RFE] Expose event types to API
>>  https://bugzilla.redhat.com/1453170
>>
>> Currently the API provides the event code and description, for example:
>>
>>  
>>19
>>Host myhost failed to recover.>...
>>  
>>
>> There is no documentation of what is the meaning of codes, except the
>> source code of the engine itself. This forces some applications to add
>> their own code to name mapping. For example, the 'ovirt' Ruby gem used
>> by older versions of ManageIQ to interact with oVirt contains the following:
>>
>>  https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485
>>
>> We could avoid this by adding to the API a new event attribute that
>> indicates the type:
>>
>>  
>>19
>>host_recover_failure
>>Host myhost failed to recover.
>>...
>>  
>>
>> Ideally this should be defined as an enum, so that it will be
>> represented as an enum in the SDKs. Alternatively it could just be an
>> string, and we could reuse the 'name' attribute:
>>
>>  
>>19
>>host_recover_failure
>>Host myhost failed to recover.
>>...
>>  
>>
>> However, the key point to making this useful would be to keep the types
>> (or names) backwards compatible, so that users of the API can rely on
>> their values and meanings.
>>
>> So this is my question to you: can we commit to keep the names and
>> meanings of the backend event types backwards compatible?
> 
> Do we even have to make it bw compatible?
> I guess it depends on the actual usage of those names…
> The ovirt ruby gem itself doesn’t do much with it
>

We need to make keep it backwards compatible or else tell users "don't
rely on these values, as they may change without notice".

The 'ovirt' gem doesn't do anything special, it just creates its own
code to name mapping. But the users of the 'ovirt' gem (the ManageIQ
oVirt provider) do rely on the name. For example:


https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models/manageiq/providers/redhat/infra_manager/event_parser.rb#L80-L92

That means that if we ever change the meaning of a code the ManageIQ
provider, for example, will break.

>>
>> Regards,
>> Juan Hernandez
>>
>>
>> ___
>> 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] Making event types backwards compatible?

[Juan Hernández]

Hello,

It has been recently requested that the API provides event types:

  [RFE] Expose event types to API
  https://bugzilla.redhat.com/1453170

Currently the API provides the event code and description, for example:

  
19
Host myhost failed to recover.

There is no documentation of what is the meaning of codes, except the
source code of the engine itself. This forces some applications to add
their own code to name mapping. For example, the 'ovirt' Ruby gem used
by older versions of ManageIQ to interact with oVirt contains the following:

  https://github.com/ManageIQ/ovirt/blob/v0.17.0/lib/ovirt/event.rb#L25-L485

We could avoid this by adding to the API a new event attribute that
indicates the type:

  
19
host_recover_failure
Host myhost failed to recover.
...
  

Ideally this should be defined as an enum, so that it will be
represented as an enum in the SDKs. Alternatively it could just be an
string, and we could reuse the 'name' attribute:

  
19
host_recover_failure
Host myhost failed to recover.
...
  

However, the key point to making this useful would be to keep the types
(or names) backwards compatible, so that users of the API can rely on
their values and meanings.

So this is my question to you: can we commit to keep the names and
meanings of the backend event types backwards compatible?

Regards,
Juan Hernandez


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

Re: [ovirt-devel] [missing_subjectAltName] in engine ca certificate?

[Juan Hernández]

On 05/10/2017 09:07 AM, Yaniv Kaul wrote:
> 
> 
> On Wed, May 10, 2017 at 9:35 AM, Martin Perina  > wrote:
> 
> Does this mean that we need to create new CA for all existing oVirt
> installations which are not using custom HTTPS certificate signed by
> external CA?
> 
> 
> No, just a new certificate for Engine, I believe.
> Y.
> 

Probably not even for the engine, but just for the web server.

> 
> On Sun, May 7, 2017 at 7:37 PM, Nir Soffer  > wrote:
> 
> On Sun, May 7, 2017 at 8:27 PM Dan Kenigsberg  > wrote:
> 
> On Sun, May 7, 2017 at 8:22 PM, Nir Soffer
> > wrote:
> > I imported the certificate from my engine into chrome[1],
> but Chrome
> > refuses to use it because:
> >
> > This server could not prove that it is ...; its security
> > certificate is from [missing_subjectAltName].
> >
> > Same certificate used to work 2 weeks ago, looks like new
> Chrome
> > version changed the rules.
> >
> > Without importing engine CA, there is no way to upload images
> > via engine.
> >
> > Tested on engine 4.1.1 and 4.1.2 on Centos 7.3.
> >
> > Is this  known issue?
> >
> > [1] from
> >
> 
> http:///ovirt-engine/services/pki-resource?resource=ca-certificate=X509-PEM-CA
> >
> > Nir
> 
> https://gerrit.ovirt.org/#/c/74614/
> 
> 
> "This patch is not yet working, but can be used for discussion."
> 
> 
> Thanks!
> 
> Do you know how to manually fix engine certificates until we
> have a working
> patch?
> 
> Nir
> 
> ___
> 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] REST API data aggregation

[Juan Hernández]

On 03/27/2017 01:03 PM, Tomas Jelinek wrote:
> 
> 
> On Mon, Mar 27, 2017 at 11:21 AM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> Top posting, sorry.
> 
> There are a few things I'd like to clarify, regarding this subject:
> 
> 1. Data aggregation, as requested now by Tomas, and by other people in
> the past.
> 
> We used to have that 'detail' parameter, to aggregate certain very
> specific types of data, in particular to aggregate VM disks and NICs. We
> removed that in version 4 of the API because the implementation was
> extremely inefficient, from the engine point of view. An innocent
> request like this:
> 
>   GET /ovirt-engine/api/vms?detail=+disks,+nics
> 
> Would generate, with the implementation we used to have, 1 query for the
> VMs and then as many queries for disks and NICs as VMs in the system. In
> our scale test environments, for example, with approx 4000 VMs and 1
> disks, that would take more than 20 hours to execute.
> 
> In addition, we didn't have in the past any mechanism to make this
> available in a generic one, because there was no knowledge in the API of
> what are 'details'.
> 
> In version 4 of the API we introduced a formal (kind of) specification
> of the API (a.k.a. the model), and int includes knowledge about what are
> 'links'. For example, the specification of the VM type contains this:
> 
>   @Link DiskAttachment[] diskAttachments();
>   @Link Nic[] nics();
> 
> With this information we are now in a position where we can implement
> this in a generic way.
> 
> We intend to implement this using a mechanism similar to the existing
> 'detail' parameter:
> 
>   GET /ovirt-engine/api/vms/123?follow=disk_attachments,nics
> 
> The naive implementation of this is to let the API call itself. For
> example, when the user requests to follow the 'disk_attachments' detail
> the API can just call itself to get that:
> 
>   GET /ovirt-engine/api/vms/123/disk_attachments
> 
> However, we can't use that naive approach, if we do we end with the
> 1+C*N query problem described before. We need to use specific
> implementations for certain frequent use cases, like VMs+disks+nics, and
> that needs work in the API and in the backend.
> 
> Tomas, if you want to help moving this forward, please open a RFE and
> makes sure it gets attention.
> 
> 
> This sounds pretty good! I will open, but since we are talking already
> here I'll just use the opportunity to clarify the topic more and than
> I'll open the BZ.
> 
> What I can imagine is the GetAllVmsQuery will accept in params also the
> list of details it should provide. Than, the GetAllVmsQuery will
> implement the efficient way of retrieving this info as well.
> 
> So, from the API perspective, it will be about taking the
> ?follow= part and passing it to the backend query params.
> 
> What you think?
>  

Exactly, that is the point! The API by itself can't optimize database
queries, all it can do is call the backend. It is the backend that has
the opportunity and possibility to send optimized queries to the database.

For other less common things we can use the naive approach, and
implement the aggregation in the API itself. But for common use cases,
like VM+disks+nics, we need to do it in an efficient way.

> 
> 
> 2. Reuse of TLS sessions.
> 
> The part of creating TLS sessions that is expensive is the generation of
> the shared session key. That can be avoided if both the server and the
> client are careful and reuse the session, using the session cache
> mechanism built-in into TLS itself. The web servers that we use (Apache
> and Undertow) do implement this mechanism, and so do most of our
> clients. Make sure that your client uses it as well. In Java this is
> achieved re-using the SSLContext. We already do that for the engine to
> VDSM communciation for example. In JavaScript the browser already takes
> care of this.
> 
> 3. Parallelism and latency.
> 
> A typical problem that we have is that we send many request to the
> server. For example, to retrieve user sessions for a set of VMs we tend
> to send many requests like this:
> 
>   GET /ovirt-engine/api/vms/1/sessions
>   GET /ovirt/engine/api/vms/2/sessions
>   GET /ovirt-engine/api/vms/3/sessions
>   ...
> 
> And we do that in a synchronous way: send one, wait for the result, send
> another one, wait for the result, etc. This means that we don't take
> advantage of the parallelism of the server and that we ad

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

[Juan Hernández]

On 03/23/2017 11:05 AM, Roy Golan 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
> 

Very interesting Roy, thanks.

What was the root cause of the host edit taking minutes?

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

Re: [ovirt-devel] Error while installing ovirt-engine (Error: Requires: classpathx-mail)

[Juan Hernández]

On 03/09/2017 02:23 PM, Tasdik Rahman wrote:
> Hey everyone, 
> 
> I was trying to get ovirt up and running on my local F19(64bit) VM box
> following
> the http://www.ovirt.org/documentation/quickstart/quickstart-guide/ blog
> post. 
> 
> The installation stops abruptly when I try to do a `yum -y install
> ovirt-engine`. Here is what I tried.
> 
> +++
> [root@localhost ~]# yum install
> http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm
> Loaded plugins: langpacks, refresh-packagekit
> ovirt-release36.rpm
>
>  |  10 kB  00:00:00
> Examining /var/tmp/yum-root-9p0rub/ovirt-release36.rpm:
> 1:ovirt-release36-3.6.7-1.noarch
> /var/tmp/yum-root-9p0rub/ovirt-release36.rpm: does not update installed
> package.
> Error: Nothing to do
> [root@localhost ~]# yum -y install ovirt-engine
> ….
> ….
> ---> Package stringtemplate.noarch 0:3.2.1-5.fc19 will be installed
> --> Finished Dependency Resolution
> Error: Package: ovirt-engine-notification-service-3.1.0-1.fc19.noarch
> (fedora)
>Requires: classpathx-mail
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> [root@localhost ~]#
> +++
> 
> I read thought some bug zilla issues[1] which state that this package
> has been retired. But no solution was provided for it. My aim is to just
> test it on a single host. How should I go about this?
> 
> Thanks for your time, 
> Tasdik
> 
> 1: https://bugzilla.redhat.com/show_bug.cgi?id=1001137
> 

Fedora 19 isn't a supported oVirt platform (and quite old, out of
support itself). Try CentOS 7 or Fedora 24.

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

Re: [ovirt-devel] Strange concurrency error on VM creation

[Juan Hernández]

On 03/07/2017 05:42 PM, Marc Young wrote:
> I've been fighting this for roughly two days and I'm starting to think
> that possibly it's not my code but an interaction with the server.
> 
> I'm using test-kitchen[1] with the kitchen-vagrant[2] driver to spin up
> vagrant machines and run tests against them. I'm using Jenkins to run
> kitchen in containers in parallel.
> 
> Basically Jenkins runs a docker container with ruby + vagrant 1.9.2 and
> runs kitchen test all at the same time as another container with ruby +
> vagrant 1.9.1.
> 
> If I run these in parallel, on some occasions the server seems to
> respond with the wrong creation information. If you look at the logs
> here: 
> http://home.blindrage.us:8080/job/myoung34/job/vagrant-ovirt4/view/change-requests/job/PR-79/41/console
> 
> 
> 
> the container for vagrant 1.9.1 created a VM `vagrant-dynamic-1.9.1:
> 
> [vagrant-1.9.1]Bringing machine 'default' up with 'ovirt4' 
> provider...
> 
> [vagrant-1.9.1]==> default: Creating VM with the following 
> settings...
> 
> [vagrant-1.9.1]==> default:  -- Name:  dynamic-1.9.1
> 
> 
> And the container for vagrant 1.9.2 (nearly the same time) created a VM
> `vagrant-dynamic-1.9.2`:
> 
> [vagrant-1.9.2]==> default: Creating VM with the following 
> settings...
> 
> [vagrant-1.9.2]==> default:  -- Name:  dynamic-1.9.2
> 
> [vagrant-1.9.2]==> default:  -- Cluster:   Default
> 
> 
> If you look at the ss:
> 
> the container 1.9.1 will wait for dynamic-1.9.1 and try to contact it at
> 192.168.2.54
> 
> the container 1.9.2 will wait for dynamic-1.9.2 and try to contact it at
> 192.168.2.55
> 
> But if you look at the logs, the 1.9.1 container started trying to work
> with 192.168.2.55 by creating a new key then talking to it:
> 
>  [vagrant-1.9.1]default: Key inserted! Disconnecting and 
> reconnecting using new SSH key...
> 
> [vagrant-1.9.1]Waiting for SSH service on 192.168.2.55:22 
> , retrying in 3 seconds
> 
> 
> Because 1.9.1 inserted a generated key into that box, the 1.9.2
> container which _should_ be talking to it cannot now:
> 
> [vagrant-1.9.2]==> default: Rsyncing folder: 
> /home/jenkins/.kitchen/cache/ => /tmp/omnibus/cache
> [vagrant-1.9.2]SSH authentication failed! This is typically 
> caused by the public/private
> [vagrant-1.9.2]keypair for the SSH user not being properly set on 
> the guest VM. Please
> [vagrant-1.9.2]verify that the guest VM is setup with the proper 
> public key, and that
> [vagrant-1.9.2]the private key path for Vagrant is setup properly 
> as well.
> 
> 
> 
> Via the ruby sdk I create the VM and store the ID it responded with.
> Then to get the IP:
> 
> server = env[:vms_service].vm_service(env[:machine].id)
> nics_service = server.nics_service
> nics = nics_service.list
> ip_addr = nics.collect { |nic_attachment|
> env[:connection].follow_link(nic_attachment).reported_devices.collect {
> |dev| dev.ips.collect { |ip| ip.address if ip.version == 'v4' } }
> }.flatten.reject {   |ip| ip.nil? }.first rescue nil
> 

Is this code running inside the same Ruby process for both virtual
machines? In multiple threads?

> Given this code I can't think of any way that I would get the wrong IP
> unless somehow the server responded incorrectly, since the NIC's i've
> scanned and compiled across are tied directly to the server I created.
> 
> Any thoughts? This only happpens randomly and it seems to happen if I
> bombard the server with a bunch of VM creations simultaneously
> 
> [1] https://github.com/test-kitchen/test-kitchen
> [2] https://github.com/test-kitchen/kitchen-vagrant
> 
> 
> ___
> 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] cloud-init metadata service

[Juan Hernández]

On 03/01/2017 04:53 PM, Marc Young wrote:
> What feels hacky is that I have so little information about the VM i'm
> running from within that I'd have a hard time crawling the API enough to
> know the information I got was about the VM I'm testing against. Per my
> later email the ID in /var/lib/cloud/data/instance-id is not the same
> that I'd need to hit the REST API to describe
> 

I'd suggest you create the virtual machines assigning them a BIOS serial
number that helps you find them via the API. Easiest is to create them
so that the BIOS serial number is the id of the VM in ovirt. You have an
exmaple of how to set the serial number policy here:


https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/sdk/examples/set_vm_serial_number.rb

In your case you probably want to do this:

  vm_service.update(
serial_number: {
  policy: OvirtSDK4::SerialNumberPolicy::VM
}
  )

> On Wed, Mar 1, 2017 at 9:45 AM, Yaniv Kaul  > wrote:
> 
> 
> 
> On Wed, Mar 1, 2017 at 4:53 PM Marc Young <3vilpeng...@gmail.com
> > wrote:
> 
> Ive looked through what documentation I can find and i only come
> up on bug reports from years ago, but: is there anyway to get
> metadata about a oVirt server metadata from the context of a VM
> ? cloud-init supports a metadata service that sits
> on 169.254.169.254 to retrieve info like instance-id etc. This
> is very useful in AWS which I'm familiar with.
> 
> 
> We support cloud-init via config drive, not over the network.
>  
> 
> 
> My context is that I'd like to run some assertions against a VM
> and the test framework I'm using runs all assertions from within
> the VM itself. So If i wanted to assert that the host running my
> VM is "x.foo.com " I'd have to be able to
> retrieve that from within the VM. I can do that via the REST API
> but that requires me to get a REST user/pass inside the vm and
> feels hacky. The common way of doing this at openstack/aws is to
> curl the metadata service which replies with information only
> relevant to the machine asking.
> 
> 
> Feels OK to me - doesn't sound too hacky to me.
> You can do it via Ansible, but still need creds.
> I don't remember if anything in the VM BIOS (dmidecode) will help
> you there - I think not.
> Y.
>  
> 
> ___
> 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 Cloud-init

[Juan Hernández]

8.2.200
> GATEWAY=192.168.2.1
> ONBOOT=yes
> 
> [vagrant@test ~]$ sudo cat /var/log/cloud-init* | grep -i dns
> [vagrant@test ~]$ sudo cat /var/log/cloud-init* | grep -i local
> Feb 14 23:16:45 vagrant cloud-init: Cloud-init v. 0.7.5 running
> 'init-local' at Wed, 15 Feb 2017 05:16:45 +. Up 11.00 seconds.
> Feb 16 23:03:35 test cloud-init: Cloud-init v. 0.7.5 running
> 'init-local' at Fri, 17 Feb 2017 05:03:35 +. Up 5.23 seconds.
> Cloud-init v. 0.7.5 running 'init-local' at Thu, 09 Feb 2017
> 03:45:01 +. Up 1310.61 seconds.
> Cloud-init v. 0.7.5 running 'init-local' at Wed, 15 Feb 2017
> 05:16:45 +. Up 11.00 seconds.
> Cloud-init v. 0.7.5 running 'init-local' at Fri, 17 Feb 2017
> 05:03:35 +. Up 5.23 seconds.
> Cloud-init v. 0.7.5 finished at Fri, 17 Feb 2017 05:03:45 +.
> Datasource DataSourceConfigDrive [local,ver=2][source=/dev/sr1].  Up
> 15.37 seconds
> 
> 
> 
> On the vm host running that VM:
> 
> 
> [myoung@ovirt ~]$ sudo ps -ef | grep qemu-kvm | grep test
> qemu 12456 1  9 05:03 ?00:00:19
> /usr/libexec/qemu-kvm -name ...snipped
> [myoung@ovirt ~]$ sudo cp
> 
> /var/run/vdsm/payload/c65751c3-431d-44e4-836c-963b81b1f846.20fc2db0517e8c06579d7719d8f3fb35.img
> .
> [myoung@ovirt ~]$ sudo mount -o loop,ro
> c65751c3-431d-44e4-836c-963b81b1f846.20fc2db0517e8c06579d7719d8f3fb35.img
> /mnt
> [myoung@ovirt ~]$ find /mnt -type f
> find: ‘/mnt’: Permission denied
> [myoung@ovirt ~]$ sudo find /mnt -type f
> /mnt/openstack/content/
> /mnt/openstack/latest/meta_data.json
> /mnt/openstack/latest/user_data
> [myoung@ovirt ~]$ sudo cat /mnt/openstack/content/
> auto eth0
> iface eth0 inet static
>   address 192.168.2.200
>   netmask 255.255.255.0
>   gateway 192.168.2.1
>   dns-nameservers 192.168.2.1
>   dns-search test.local
> [myoung@ovirt ~]$ sudo umount
> c65751c3-431d-44e4-836c-963b81b1f846.20fc2db0517e8c06579d7719d8f3fb35.img
> 
> Cloud-init definitely isn't working right away with resolv.conf, but I'm
> definitely passing it correctly to the API, it shows up on the floppy as
> you described but it's not making its way to
> /etc/sysconfig/network-scripts/ifcfg-eth0 even though the other settings
> for sure are (such as address, netmask,)
> 
> If i add that information to /etc/sysconfig/network-scripts/ifcfg-eth0
> and bounce network it all works:
> 
> [vagrant@test ~]$ ping -c 3 www.google.com <http://www.google.com>
> ping: www.google.com <http://www.google.com>: Name or service not known
> [vagrant@test ~]$ echo $'DNS1=192.168.2.113\nDNS2=192.168.2.1' |
> sudo tee -a /etc/sysconfig/network-scripts/ifcfg-eth0 >/dev/null
> [vagrant@test ~]$ ping -c 3 www.google.com <http://www.google.com>
> ping: www.google.com <http://www.google.com>: Name or service not known
> [vagrant@test ~]$ sudo service network restart
> Restarting network (via systemctl):[  OK  ]
> [vagrant@test ~]$ ping -c 3 www.google.com <http://www.google.com>
>     PING www.google.com <http://www.google.com> (216.58.217.4) 56(84)
> bytes of data.
> 64 bytes from den03s09-in-f4.1e100.net
> <http://den03s09-in-f4.1e100.net> (216.58.217.4): icmp_seq=1 ttl=54
> time=55.8 ms
> 64 bytes from den03s09-in-f4.1e100.net
> <http://den03s09-in-f4.1e100.net> (216.58.217.4): icmp_seq=2 ttl=54
> time=43.9 ms
> ^C
> --- www.google.com <http://www.google.com> ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 43.939/49.916/55.894/5.981 ms
> [vagrant@test ~]$ sudo cat /etc/resolv.conf
> # Generated by NetworkManager
> search localdomain
> nameserver 192.168.2.113
> nameserver 192.168.2.1
> 
> 
> 
> 
> On Fri, Feb 17, 2017 at 2:21 AM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 02/17/2017 06:00 AM, Marc Young wrote:
> > I'm apparently really bad at email, I replied only to Shahar, not the
> > whole thread.
> >
> > Vinzenz your email slipped first, so to answer your question:
> >
> > It's the latest Centos 7 with these installed:
> >
> > cloud-init-0.7.5-10.el7.centos.1
> > kernel-3.10.0-514   >.el7
> > ovirt-guest-agent-common-1.0.13-1.20161220085008.git165fff1.el7.centos
> >
> > The setup script I use to create a template is here:
> > 
>

Re: [ovirt-devel] oVirt Cloud-init

[Juan Hernández]

On 02/17/2017 06:00 AM, Marc Young wrote:
> I'm apparently really bad at email, I replied only to Shahar, not the
> whole thread.
> 
> Vinzenz your email slipped first, so to answer your question:
> 
> It's the latest Centos 7 with these installed:
> 
> cloud-init-0.7.5-10.el7.centos.1
> kernel-3.10.0-514 .el7
> ovirt-guest-agent-common-1.0.13-1.20161220085008.git165fff1.el7.centos
> 
> The setup script I use to create a template is here:
> https://github.com/myoung34/vagrant-ovirt4/blob/master/tools/prepare_redhat_for_box.sh
> 
> 

In that script you run "chkconfig cloud-init on" *before* installing the
cloud-init package. That is irrelevant, as the cloud-init services are
enabled by default when the package is installed. But worth changing.

> The engine-host is oVirt Engine Version: 4.1.0.4-1.el7.centos
> The ruby SDK i'm working with is 4.1.2
> 
> Halfway through I realized that it's actually supported in the API:
> 
> custom_script String
> dns_search String
> dns_servers String
> 
> 
> It also shows usage here:
> https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/sdk/examples/start_vm_with_cloud_init.rb
> 
> 
> Here's some verification:
> 
> 66:   vm_configuration[:initialization][:dns_servers] =
> iface_options[:dns_servers] unless iface_options[:dns_servers].nil?
> 67:   vm_configuration[:initialization][:dns_search] =
> iface_options[:dns_search] unless iface_options[:dns_search].nil?
> 68:   require 'pry'
> 69:   binding.pry
> 70:
>  => 71:   machine.start(
> 72: use_cloud_init: true,
> 73: vm: vm_configuration
> 74:   )
> 75:
> 76:   @app.call(env)
> 
> [1] pry(#)>
> vm_configuration
> => {:initialization=>
>   {:host_name=>"test",
>:nic_configurations=>[{:name=>"eth0", :on_boot=>true,
> :boot_protocol=>"static", :ip=>{:version=>"v4",
> :address=>"192.168.2.200", :gateway=>"192.168.2.1",
> :netmask=>"255.255.255.0"}}],
>:custom_script=>nil,
>:dns_servers=>"192.168.2.1",
>:dns_search=>"test.local"}}
> 
> 
> But it didn't do anything:
> 
> [vagrant@test ~]$ cat /etc/resolv.conf
> # Generated by NetworkManager
> search localdomain
> 
> [vagrant@test ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
> NM_CONTROLLED=no
> NETMASK=255.255.255.0
> BOOTPROTO=static
> DEVICE=eth0
> IPADDR=192.168.2.200
> GATEWAY=192.168.2.1
> ONBOOT=yes
> 
> 
> The same is also true using cloud_init:
> 
> ovirt.cloud_init =< write_files:
>   - content: |
>   wat
> path: /tmp/something.txt
> permissions: '0644'
> network-interfaces: |
>   auto eth0
>   iface eth0 inet static
> address 192.168.2.201
> network 192.168.2.0
> netmask 255.255.255.0
> gateway 192.168.2.1
> dns-nameservers 192.168.2.113 192.168.2.1
> EOF
> 

Is this ^ supposed to work in cloud-init? I didn't find it in the
documentation. I thought that the only way to provide network interface
configuration is via the 'openstack/content/whatever' file within the
generated floppy.

> 
> and inspection:
> 
> 66:   vm_configuration[:initialization][:dns_servers] =
> iface_options[:dns_servers] unless iface_options[:dns_servers].nil?
> 67:   vm_configuration[:initialization][:dns_search] =
> iface_options[:dns_search] unless iface_options[:dns_search].nil?
> 68:   require 'pry'
> 69:   binding.pry
> 70:
>  => 71:   machine.start(
> 72: use_cloud_init: true,
> 73: vm: vm_configuration
> 74:   )
> 75:
> 76:   @app.call(env)
> [1] pry(#)>
> vm_configuration
> => {:initialization=>
>   {:host_name=>"test",
>:nic_configurations=>[{:name=>"eth0", :on_boot=>true,
> :boot_protocol=>"static", :ip=>{:version=>"v4",
> :address=>"192.168.2.200", :gateway=>"192.168.2.1",
> :netmask=>"255.255.255.0"}}],
>:custom_script=>
> "write_files:\n  - content: |\n  wat\npath:
> /tmp/something.txt\npermissions: '0644'\nnetwork-interfaces: |\n
> auto eth0\n  iface eth0 inet static\naddress 192.168.2.201\n
> network 192.168.2.0\nnetmask 255.255.255.0\ngateway
> 192.168.2.1\ndns-nameservers 192.168.2.113 192.168.2.1\n",
>:dns_servers=>"192.168.2.1",
>:dns_search=>"test.local"}}
> 
> 
> And here's my debugging after it comes up:
> 
> [vagrant@test ~]$ cat /etc/resolv.conf
> # Generated by NetworkManager
> search localdomain
> 

Re: [ovirt-devel] Unable to start vm on specific host via ruby sdk

[Juan Hernández]

On 02/17/2017 05:53 AM, Marc Young wrote:
> Using the ruby sdk I'm unable to start a VM on a specific host.
> 
> According to the API docs at api/v4/model#types/vm_placement_policy :
> 
> 
> Name Type
> 
> hosts Host[]
> 
> 
> No matter what I specify, I run into this same bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1249521
> 
> 65:   require 'pry'
> 66:   binding.pry
> 67:
>  => 68:   machine.start(
> 69: use_cloud_init: true,
> 70: vm: vm_configuration
> 71:   )
> 72:
> 73:   @app.call(env)
> [1] pry(#)>
> vm_configuration[:placement_policy] = { :hosts => [{ :host =>
> 'server.test.local' }], :affinity => 'pinned' }
> [2] pry(#)>
> vm_configuration
> => {:initialization=>
>   {:host_name=>"test",
>:nic_configurations=>[{:name=>"eth0", :on_boot=>true,
> :boot_protocol=>"static", :ip=>{:version=>"v4",
> :address=>"192.168.2.200", :gateway=>"192.168.2.1"}}],
>:custom_script=>
> "write_files:\n  - content: |\n  wat\npath:
> /tmp/something.txt\npermissions: '0644'\nnetwork-interfaces: |\n
>  auto eth0\n  iface eth0 inet static\naddress 192.168.2.201\n  
>  network 192.168.2.0\nnetmask 255.255.255.0\ngateway
> 192.168.2.1\ndns-nameservers 192.168.2.113 192.168.2.1\n"},
>  :placement_policy=>{:hosts=>[{:host=>"server.test.local"}],
> :affinity=>"pinned"}}
> ==> default: An error occured. Recovering..
> ==> default: Halting VM...
> ==> default: Waiting for VM to shutdown...
> ==> default: Removing VM...
> 
> /home/myoung/.rvm/gems/ruby-2.2.3/gems/ovirt-engine-sdk-4.1.2/lib/ovirtsdk4/service.rb:52:in
> `raise_error': Fault reason is "Incomplete parameters". Fault detail
> is "Host [id|name] required for
> validateAndUpdateHostsInPlacementPolicy". HTTP response code is 400.
> (OvirtSDK4::Error)
> 
> 
> 
> The same goes with giving an object instead of a hash object
> 
> => 68:   machine.start(
>69: use_cloud_init: true,
>70: vm: vm_configuration
>71:   )
>72:
>73:   @app.call(env)
> [1] pry(#)>
> hosts_service = env[:connection].system_service.hosts_service
> [2] pry(#)> host =
> hosts_service.list(search: 'name=server.test.local')[0]
> [3] pry(#)> host.status
> => "up"
> [4] pry(#)>
> vm_configuration[:placement_policy] = { :hosts => [{ :host => host }]}
> ==> default: An error occured. Recovering..
> ==> default: Halting VM...
> ==> default: Waiting for VM to shutdown...
> ==> default: Removing VM...
> 
> /home/myoung/.rvm/gems/ruby-2.2.3/gems/ovirt-engine-sdk-4.1.2/lib/ovirtsdk4/service.rb:52:in
> `raise_error': Fault reason is "Incomplete parameters". Fault detail
> is "Host [id|name] required for
> validateAndUpdateHostsInPlacementPolicy". HTTP response code is 400.
> (OvirtSDK4::Error)
> from
> 
> /home/myoung/.rvm/gems/ruby-2.2.3/gems/ovirt-engine-sdk-4.1.2/lib/ovirtsdk4/service.rb:85:in
> `check_action'
> from
> 
> /home/myoung/.rvm/gems/ruby-2.2.3/gems/ovirt-engine-sdk-4.1.2/lib/ovirtsdk4/services.rb:29460:in
> `start'
> 

The host is indicated using an object of type 'OvirtSDK4::Host', with
the 'name' attribute set to the host name or the 'id' attribute set to
the host id. So you need to create the 'vm_configuration' like this:

  vm_configuration = OvirtSDK4::Vm.new(
placement_policy: {
  hosts: [
{
  name: 'myhost'
}
  ]
}
  )

Unfortunately the Ruby doesn't provide a good mechanism to check the
types of arguments, so the error message generated isn't very helpful.
We are working on improving that. See this bug:

  https://bugzilla.redhat.com/1378113
  sdk should raise an exception when unknown parameter is used

When that is fixed you will receive an exception with a message like this:

  The type of the 'host' attribute should be 'OvirtSDK4::Host'
  but it is 'String'.

Remember that you have the Ruby SDK reference available here:

  http://www.rubydoc.info/gems/ovirt-engine-sdk

The expected types of parameters and attributes is documented there. For
example, the definition of the 'VmPlacementPolicy.hosts' attribute is here:


http://www.rubydoc.info/gems/ovirt-engine-sdk/OvirtSDK4/VmPlacementPolicy#hosts-instance_method

There you can see that the expected type is Array.


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

Re: [ovirt-devel] API model documentation is broken?

[Juan Hernández]

On 01/24/2017 05:20 PM, Yaniv Kaul wrote:
> Just below [1], something is a bit messed up.
> 
> TIA,
> Y.
> 
> [1]
> http://ovirt.github.io/ovirt-engine-api-model/master/#services/attached_storage_domain_disks
> 

Thanks for the heads up. This should fix it:

  Add missing code block closings
  https://gerrit.ovirt.org/71120

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

Re: [ovirt-devel] Publicly available REST documentation

[Juan Hernández]

On 01/04/2017 05:08 PM, Petr Horacek wrote:
> Hello again, built master documentation is available on [1], latest
> 4.1 and 4.0 tags on [2] and [3] (these two were created manually,
> automated build will be triggered by a next tag).
> 
> [1] http://ovirt.github.io/ovirt-engine-api-model/master/
> [2] http://ovirt.github.io/ovirt-engine-api-model/4.1/
> [3] http://ovirt.github.io/ovirt-engine-api-model/4.0/
> 

Thank you very much Petr, awesome job!

> 2017-01-03 15:22 GMT+01:00 Juan Hernández <jhern...@redhat.com>:
>> On 01/03/2017 03:20 PM, Petr Horacek wrote:
>>> Hi, I've been hacking public API docs yesterday, and I think it will
>>> work in GitHub-Travis combination. Now I am waiting if Gerrit-GitHub
>>> mirroring will remove branch created directly on GitHub, if not, then
>>> my approach would be following:
>>>
>>> Both 4.0 and 4.1 branches will have .travis.yml in them that will run
>>> the build and then push generated pages to gh-pages branch (authorized
>>> via GitHub deploy key). For now I have a working demo on my fork
>>> (https://github.com/phoracek/ovirt-engine-api-model/blob/master/.travis.yml),
>>> this one does not use deploy keys, but token instead.
>>>
>>> Hope I'm not breaking your work.
>>>
>>
>> Excellent! Please go ahead.
>>
>>> 2017-01-03 14:49 GMT+01:00 Vojtech Szocs <vsz...@redhat.com>:
>>>>
>>>>
>>>> - Original Message -
>>>>> From: "Rafael Martins" <rmart...@redhat.com>
>>>>> To: "Vojtech Szocs" <vsz...@redhat.com>
>>>>> Cc: "Juan Hernández" <jhern...@redhat.com>, "Michal Skrivanek" 
>>>>> <mskri...@redhat.com>, "devel" <devel@ovirt.org>
>>>>> Sent: Tuesday, January 3, 2017 2:28:30 PM
>>>>> Subject: Re: [ovirt-devel] Publicly available REST documentation
>>>>>
>>>>>
>>>>>
>>>>> - Original Message -
>>>>>> From: "Vojtech Szocs" <vsz...@redhat.com>
>>>>>> To: "Rafael Martins" <rmart...@redhat.com>
>>>>>> Cc: "Juan Hernández" <jhern...@redhat.com>, "Michal Skrivanek"
>>>>>> <mskri...@redhat.com>, "devel" <devel@ovirt.org>
>>>>>> Sent: Tuesday, January 3, 2017 2:24:22 PM
>>>>>> Subject: Re: [ovirt-devel] Publicly available REST documentation
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Original Message -
>>>>>>> From: "Rafael Martins" <rmart...@redhat.com>
>>>>>>> To: "Vojtech Szocs" <vsz...@redhat.com>
>>>>>>> Cc: "Juan Hernández" <jhern...@redhat.com>, "Michal Skrivanek"
>>>>>>> <mskri...@redhat.com>, "devel" <devel@ovirt.org>
>>>>>>> Sent: Tuesday, January 3, 2017 2:17:49 PM
>>>>>>> Subject: Re: [ovirt-devel] Publicly available REST documentation
>>>>>>>
>>>>>>> - Original Message -
>>>>>>>> From: "Vojtech Szocs" <vsz...@redhat.com>
>>>>>>>> To: "Juan Hernández" <jhern...@redhat.com>
>>>>>>>> Cc: "Michal Skrivanek" <mskri...@redhat.com>, "devel" <devel@ovirt.org>
>>>>>>>> Sent: Tuesday, January 3, 2017 2:11:06 PM
>>>>>>>> Subject: Re: [ovirt-devel] Publicly available REST documentation
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> - Original Message -
>>>>>>>>> From: "Juan Hernández" <jhern...@redhat.com>
>>>>>>>>> To: "Jakub Niedermertl" <jnied...@redhat.com>
>>>>>>>>> Cc: "devel" <devel@ovirt.org>, "Michal Skrivanek"
>>>>>>>>> <mskri...@redhat.com>
>>>>>>>>> Sent: Monday, January 2, 2017 10:48:53 PM
>>>>>>>>> Subject: Re: [ovirt-devel] Publicly available REST documentation
>>>>>>>>>
>>>>>>>>> On 01/02/2017 10:13 PM, Jakub Niedermertl wrote:
>>>>>>>>>> Hi Juan,
>>>>>>>>>>
>>>>>>>>>&

Re: [ovirt-devel] Can't find relative path for class "org.ovirt.engine.api.resource.VmDisksResource", will return null

[Juan Hernández]

On 01/04/2017 10:09 AM, Pavel Zhukov wrote:
> 
> Hello,
> 
> In ovirt-system-tests results I can see engine log is flooded with messages 
> like:
> 147:  40147:2017-01-03 21:45:13,837-05 ERROR 
> [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-22) [] Can't 
> find relative path for class "org.ovirt.engine.api.resource.VmDisksResource", 
> will return null
> 
> There're 123 messages like (logging time is 15 mins).
> 
> Is it expected to have too many ERROR messages?
> 
> [1] 
> http://jenkins.ovirt.org/job/ovirt_4.1_system-tests/28/artifact/exported-artifacts/test_logs/basic-suite-4.1/post-004_basic_sanity.py/lago-basic-suite-4-1-engine/_var_log_ovirt-engine/engine.log
> 

No, it isn't expected. It isn't very serious either. It means that the
system isn't able to calculate a link for something. That needs to be
fixed anyhow. Can you open a BZ?
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Publicly available REST documentation

[Juan Hernández]

On 01/03/2017 03:20 PM, Petr Horacek wrote:
> Hi, I've been hacking public API docs yesterday, and I think it will
> work in GitHub-Travis combination. Now I am waiting if Gerrit-GitHub
> mirroring will remove branch created directly on GitHub, if not, then
> my approach would be following:
> 
> Both 4.0 and 4.1 branches will have .travis.yml in them that will run
> the build and then push generated pages to gh-pages branch (authorized
> via GitHub deploy key). For now I have a working demo on my fork
> (https://github.com/phoracek/ovirt-engine-api-model/blob/master/.travis.yml),
> this one does not use deploy keys, but token instead.
> 
> Hope I'm not breaking your work.
> 

Excellent! Please go ahead.

> 2017-01-03 14:49 GMT+01:00 Vojtech Szocs <vsz...@redhat.com>:
>>
>>
>> - Original Message -
>>> From: "Rafael Martins" <rmart...@redhat.com>
>>> To: "Vojtech Szocs" <vsz...@redhat.com>
>>> Cc: "Juan Hernández" <jhern...@redhat.com>, "Michal Skrivanek" 
>>> <mskri...@redhat.com>, "devel" <devel@ovirt.org>
>>> Sent: Tuesday, January 3, 2017 2:28:30 PM
>>> Subject: Re: [ovirt-devel] Publicly available REST documentation
>>>
>>>
>>>
>>> - Original Message -
>>>> From: "Vojtech Szocs" <vsz...@redhat.com>
>>>> To: "Rafael Martins" <rmart...@redhat.com>
>>>> Cc: "Juan Hernández" <jhern...@redhat.com>, "Michal Skrivanek"
>>>> <mskri...@redhat.com>, "devel" <devel@ovirt.org>
>>>> Sent: Tuesday, January 3, 2017 2:24:22 PM
>>>> Subject: Re: [ovirt-devel] Publicly available REST documentation
>>>>
>>>>
>>>>
>>>> - Original Message -
>>>>> From: "Rafael Martins" <rmart...@redhat.com>
>>>>> To: "Vojtech Szocs" <vsz...@redhat.com>
>>>>> Cc: "Juan Hernández" <jhern...@redhat.com>, "Michal Skrivanek"
>>>>> <mskri...@redhat.com>, "devel" <devel@ovirt.org>
>>>>> Sent: Tuesday, January 3, 2017 2:17:49 PM
>>>>> Subject: Re: [ovirt-devel] Publicly available REST documentation
>>>>>
>>>>> - Original Message -
>>>>>> From: "Vojtech Szocs" <vsz...@redhat.com>
>>>>>> To: "Juan Hernández" <jhern...@redhat.com>
>>>>>> Cc: "Michal Skrivanek" <mskri...@redhat.com>, "devel" <devel@ovirt.org>
>>>>>> Sent: Tuesday, January 3, 2017 2:11:06 PM
>>>>>> Subject: Re: [ovirt-devel] Publicly available REST documentation
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Original Message -
>>>>>>> From: "Juan Hernández" <jhern...@redhat.com>
>>>>>>> To: "Jakub Niedermertl" <jnied...@redhat.com>
>>>>>>> Cc: "devel" <devel@ovirt.org>, "Michal Skrivanek"
>>>>>>> <mskri...@redhat.com>
>>>>>>> Sent: Monday, January 2, 2017 10:48:53 PM
>>>>>>> Subject: Re: [ovirt-devel] Publicly available REST documentation
>>>>>>>
>>>>>>> On 01/02/2017 10:13 PM, Jakub Niedermertl wrote:
>>>>>>>> Hi Juan,
>>>>>>>>
>>>>>>>> from time to time I'd like the REST doc to be available on some
>>>>>>>> public
>>>>>>>> site. It would allow us to
>>>>>>>> * check the documentation without searching for running engine
>>>>>>>> * be able to easily link documentations in irc/mails
>>>>>>>> * link rest doc from ovirt.org site doc
>>>>>>>> Recently I've also heard similar request from other guys (cc-ed).
>>>>>>>> Would it be possible to for example publish generated doc of merged
>>>>>>>> patches of ovirt-engine-api-model project? Maybe github project
>>>>>>>> pages
>>>>>>>> [1] of project mirror [2] could be used for hosting.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Jakub
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://help.github.com/articles/user-organi

Re: [ovirt-devel] Publicly available REST documentation

[Juan Hernández]

On 01/02/2017 10:13 PM, Jakub Niedermertl wrote:
> Hi Juan,
> 
> from time to time I'd like the REST doc to be available on some public
> site. It would allow us to
> * check the documentation without searching for running engine
> * be able to easily link documentations in irc/mails
> * link rest doc from ovirt.org site doc
> Recently I've also heard similar request from other guys (cc-ed).
> Would it be possible to for example publish generated doc of merged
> patches of ovirt-engine-api-model project? Maybe github project pages
> [1] of project mirror [2] could be used for hosting.
> 
> Regards
> Jakub
> 
> [1] 
> https://help.github.com/articles/user-organization-and-project-pages/#project-pages
> [2] https://github.com/oVirt/ovirt-engine-api-model
> 

Yes, we can publish the documentation using gh-pages. I just created and
populated the 'gh-branch' with some initial content, and requested the
activation of the feature in Github. I will inform you when it is ready.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] SSO/CORS for remote non-Java apps

[Juan Hernández]

On 12/12/2016 08:03 AM, Marek Libra wrote:
> The proposed way is:
> - use CORS filter for enginesso.war (https://gerrit.ovirt.org/68062)
> - at host installation, add the host to CORSAllowedOrigins
>- on engine host: # engine-config -s 'CORSAllowedOrigins=[host IPs]'
> 
> So if Cockpit's plugin accesses the oVirt REST API, CORS will work.'
> 

Note that adding the host with 'engine-config' isn't ideal, as it would
require to restart the engine whenever a host is installed. In addition
you would also need to find a way to update the configuration when a
host is removed.

I think that it would be better to change the CORS filter so that it
gets the list of allowed origins running a query that returns the list
of hosts. That needs to be done with care, probably caching it somehow,
as otherwise that query would run once for each API request, killing
performance. I suggest something like this:

1. Store in the backend, in memory, the list of allowed origins.

2. During startup populate that with the list of hosts.

3. Whenever a host is added or removed (with the corresponding backend
command) update that list.

4. Add a new backend query that returns that list stored in memory
(without database access).

5. Modify the CORS filter so that it executes that query to get the list
of allowed hosts. Runing this query should be avoided for non-CORS requests.

> On Fri, Dec 9, 2016 at 3:42 PM, Marek Libra <mli...@redhat.com
> <mailto:mli...@redhat.com>> wrote:
> 
> Hi,
> 
> How can external, purely JavaScript application, running in a
> browser and served from non-engine host access the oVirt REST API?
> 
> Recent SSO implementation does not provide CORS support. It can be
> fixed by https://gerrit.ovirt.org/68062 .
> 
> How shall this support for external application look like?
> 
> More details are in our so far discussion with Juan bellow.
> 
> For completeness, there's already another patch providing SSO for
> non-GWT applications, but deployed along with the ovirt-engine and
> packaged in .war, no matter if the application itself is non-Java one.
> See https://gerrit.ovirt.org/#/c/67206/
> <https://gerrit.ovirt.org/#/c/67206/> .
> 
> -- Forwarded message --
> From: *Juan Hernández* <jhern...@redhat.com
> <mailto:jhern...@redhat.com>>
> Date: Fri, Dec 9, 2016 at 2:40 PM
> Subject: Re: CORSSuport
> To: Marek Libra <mli...@redhat.com <mailto:mli...@redhat.com>>
> 
> 
> On 12/09/2016 02:26 PM, Marek Libra wrote:
> > Thanks for your quick response and fast action :-)
> >
> > I'm working on integration of oVirt to Cockpit, ideally purely JS
> > application (Cockpit's plugin) will access oVirt REST API without using
> > any proxy.
> > The Cockpit is running on an oVirt host.
> >
> > IIUC, the OAuth token is *required* to access the REST API.
> >
> 
> The OAuth token isn't strictly required at the moment: the API also
> supports HTTP basic authentication. The OAuth token will be required
> when support for version 3 of the API and support for basic
> authentication are removed. We intend to remove those two things in
> version 4.2 of oVirt.
> 
> > If so, there are just two options for external javascript application
> > willing to access the API:
> > [1] either reuse "externaly given Bearer token'' - some oVirt web
> > application served from engine node would need to provide it to the JS
> > application running elsewhere
> > [2] or call the /ovirt-engine/sso service to get one
> >
> > Regarding [1], I havn't tried it yet, but from checking the SSO filters
> > in ovirt-engine, this might work since it's retrieving session based on
> > token. What do you think?
> >
> > Regarding [2], the patch you posted would be needed.
> >
> > Do I miss something?
> >
> 
> There is option 3: use HTTP basic authentication. But that won't work
> with oVirt 4.2 or newer, so doesn't look like a reasonable thing.
> 
> I think that the only reasonable option is [2]. However, we can't (or
> should not) just configure the existing CORS support to accept any
> origin (CORSAllowedOrigins=*) as that isn't secure. We will probably
> need to have a dynamic list of allowed origins: the list of hosts. That
> would need extensive changes to the CORS filter.
> 
> So, for your experiments, you can just move the current filter so that
> it can be used by the SSO application. But for real use we need to think
> a bit deeper on 

Re: [ovirt-devel] ovirt-engine-api-explorer - webpack, command not found

[Juan Hernández]

On 11/29/2016 11:52 AM, Sandro Bonazzola wrote:
> The following job is failing on missing webpack:
> http://jenkins.ovirt.org/job/ovirt-engine-api-explorer_master_build-artifacts-el7-x86_64/10/console
> 
> can you please fix?
> 

This patch should address the issue:

  Use Node.js setup-env.sh
  https://gerrit.ovirt.org/67500

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Project ovirt-engine-api-model_4.0_build-artifacts-fc24-x86_64 is failing

[Juan Hernández]

On 11/23/2016 09:16 AM, Eyal Edri wrote:
> Maybe worth adding the build artifacts to check-patch.sh so you'll see
> it before merge? 
> 

The check-patch.sh script already runs the build of the artifacts. The
problem is that in this case the "bug" was in the automation
build-artifacts.sh script itself, and it only runs when the patch is
merged. The reason for running the build-artifacts.sh script only when
the patch is merged is that it runs a heavy process: generation of
documentation using Publican. I didn't want to do that for every patch,
as it consumes a lot of resources and doesn't add anything in terms of
patch verification.

Actually I am currently using the build-artifacts.sh script where I
should probably use the check-merged.sh script. I think I need to
reorganize the jobs and the automation scripts to make this clearer. I
am working on that.

> On Wed, Nov 23, 2016 at 10:10 AM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 11/23/2016 08:29 AM, Sandro Bonazzola wrote:
> >
> 
> http://jenkins.ovirt.org/job/ovirt-engine-api-model_4.0_build-artifacts-fc24-x86_64/30/console
> 
> <http://jenkins.ovirt.org/job/ovirt-engine-api-model_4.0_build-artifacts-fc24-x86_64/30/console>
> >
> > *
> > *
> >
> > *
> > *
> >
> > *00:04:35.993* + mv target/model.json exported-artifacts
> > *00:04:35.993* mv: cannot stat 'target/model.json': No such file
> or directory
> > *00:04:35.993* Took 93 seconds
> >
> >
> > Can you please have a look?
> >
> 
> 
> That should be addressed by the following patch:
> 
>   Fix automation scripts after removing 'describe' profile
>   https://gerrit.ovirt.org/67208
> 
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat
> S.L.
> ___
> Infra mailing list
> in...@ovirt.org <mailto:in...@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/infra
> <http://lists.ovirt.org/mailman/listinfo/infra>
> 
> 
> 
> 
> 
> -- 
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Project ovirt-engine-api-model_4.0_build-artifacts-fc24-x86_64 is failing

[Juan Hernández]

On 11/23/2016 08:29 AM, Sandro Bonazzola wrote:
> http://jenkins.ovirt.org/job/ovirt-engine-api-model_4.0_build-artifacts-fc24-x86_64/30/console
> 
> *
> *
> 
> *
> *
> 
> *00:04:35.993* + mv target/model.json exported-artifacts
> *00:04:35.993* mv: cannot stat 'target/model.json': No such file or directory
> *00:04:35.993* Took 93 seconds
> 
> 
> Can you please have a look?
> 


That should be addressed by the following patch:

  Fix automation scripts after removing 'describe' profile
  https://gerrit.ovirt.org/67208

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Fedora 25 and ovirt-engine-sdk-python

[Juan Hernández]

On 11/15/2016 08:36 AM, Juan Hernández wrote:
> On 11/15/2016 08:21 AM, Sandro Bonazzola wrote:
>> Il 15/Nov/2016 09:17, "Yaniv Kaul" <yk...@redhat.com
>> <mailto:yk...@redhat.com>> ha scritto:
>>>
>>>
>>>
>>> On Tue, Nov 15, 2016 at 9:03 AM, Sandro Bonazzola <sbona...@redhat.com
>> <mailto:sbona...@redhat.com>> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Nov 15, 2016 at 8:59 AM, Yaniv Kaul <yk...@redhat.com
>> <mailto:yk...@redhat.com>> wrote:
>>>>>
>>>>> As I try to upgrade to FC25, it is actually suggest to downgrade
>> my ovirt-engine-sdk-python to 3.6.3.0-2.fc25 - while I am happily
>> running with ovirt-engine-sdk-python-3.6.9.1-1.fc24.noarch
>>>>>
>>>>> Do we need to rebuild for F25?
>>>>
>>>>
>>>> You can keep fc24 repos but you need to explicitly set 24 instead of
>> $releasever in your .repo file.
>>>
>>>
>>> Yes, I know, but I don't see why I'd do that (I usually install
>> whatever I need directly from ovirt.org <http://ovirt.org>). 
>>> My question is if we need to rebuild.
>>> Y.
>>>  
>>
>> If we want to add support for fc25 yes we should.
>>
> 
> Actually I think that what happens here is that the package is part of
> Fedora, but I haven't updated it recently. That is why it is asking you
> to downgrade: the version in Fedora is older than the version in the
> oVirt repos. I will update the Fedora packages today, that should solve
> your problem, but it will take some time because the packages have to
> get positive Karma, or wait several days before they can be published.
> 

I have just submitted the update for Fedora 25:

  https://bodhi.fedoraproject.org/updates/FEDORA-2016-a013213177

You can get the package there, test it, and give some Karma.

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Fedora 25 and ovirt-engine-sdk-python

[Juan Hernández]

On 11/15/2016 08:21 AM, Sandro Bonazzola wrote:
> Il 15/Nov/2016 09:17, "Yaniv Kaul"  > ha scritto:
>>
>>
>>
>> On Tue, Nov 15, 2016 at 9:03 AM, Sandro Bonazzola  > wrote:
>>>
>>>
>>>
>>> On Tue, Nov 15, 2016 at 8:59 AM, Yaniv Kaul  > wrote:

 As I try to upgrade to FC25, it is actually suggest to downgrade
> my ovirt-engine-sdk-python to 3.6.3.0-2.fc25 - while I am happily
> running with ovirt-engine-sdk-python-3.6.9.1-1.fc24.noarch

 Do we need to rebuild for F25?
>>>
>>>
>>> You can keep fc24 repos but you need to explicitly set 24 instead of
> $releasever in your .repo file.
>>
>>
>> Yes, I know, but I don't see why I'd do that (I usually install
> whatever I need directly from ovirt.org ). 
>> My question is if we need to rebuild.
>> Y.
>>  
> 
> If we want to add support for fc25 yes we should.
> 

Actually I think that what happens here is that the package is part of
Fedora, but I haven't updated it recently. That is why it is asking you
to downgrade: the version in Fedora is older than the version in the
oVirt repos. I will update the Fedora packages today, that should solve
your problem, but it will take some time because the packages have to
get positive Karma, or wait several days before they can be published.

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Can't add DC with API v4 - client issue

[Juan Hernández]

On 11/10/2016 09:33 AM, Yaniv Kaul wrote:
> 
> 
> On Wed, Nov 9, 2016 at 8:05 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 11/09/2016 11:12 AM, Yaniv Kaul wrote:
> >
> >
> > On Sat, Oct 15, 2016 at 1:04 AM, Ravi Nori <rn...@redhat.com 
> <mailto:rn...@redhat.com>
> > <mailto:rn...@redhat.com <mailto:rn...@redhat.com>>> wrote:
> >
> > Also can you please try following command to directly obtain token
> > from SSO. Can replace engine with FQDN and IP to see if both work
> >
> > curl -v -k -H "Accept: application/json"
> > 
> 'https://:443/ovirt-engine/sso/oauth/token?grant_type=password=admin@internal=123=ovirt-app-api'
> >
> > You should see output similar to the one below
> >
> > 
> {"access_token":"K0sBa0D3rLtmNTdMJ-Q4FzOgCtGGY2cSFSCwbLkG94te9nDdmEzHSizsFaOeNMdwOziIv3l2-Uqm8bxWkMpwMA","scope":"ovirt-app-api
> > ovirt-ext=token-info:authz-search
> > ovirt-ext=token-info:public-authz-search
> > 
> ovirt-ext=token-info:validate","exp":-381399824,"token_type":"bearer"}
> >
> >
> > Sorry it took me so long to get back to it, but here it is:
> > 
> {"access_token":"eA8w0DaapkKAQ8tfHakzA-R0l-mjD_CsTlAqBaH4iVVjXxQN33poXzt9UhPJLxMU8YOvVNX6LICcxL1EeAiAlw","scope":"ovirt-app-api
> > ovirt-ext=token-info:authz-search
> > ovirt-ext=token-info:public-authz-search
> > 
> ovirt-ext=token-info:validate","exp":["java.lang.Long",1479290132000],"token_type":"bearer"}
> >
> 
> That "java.lang.Long" there is an error, but not related to this
> problem, as the SDK doesn't use the "exp" attribute. I guess it is a
> side effect of the recent change to use "long" instead of "int", looks
> like the JSON library used in the engine doesn't like longs.
> 
> > And here's the difference between the SDK and the manual curl command in
> > ssl_access log:
> > 192.168.201.1 - - [09/Nov/2016:04:52:19 -0500] "POST
> > /ovirt-engine/sso/oauth/token HTTP/1.1" 404 74
> > 192.168.201.1 - - [09/Nov/2016:04:55:32 -0500] "GET
> > 
> /ovirt-engine/sso/oauth/token?grant_type=password=admin@internal=123=ovirt-app-api
> > HTTP/1.1" 200 295
> >
> 
> That difference is by design. The SDK uses POST to avoid sending the
> credentials (specially the password) as a query parameter, as that is
> most probably logged and archived.
> 
> We discovered recently an issue with the Python SDK, due to a bug in the
> "pycurl" library:
> 
>   Debug mode raises UnicodeDecodeError: 'utf8' codec can't decode byte
> 0x8d in position 7: invalid start byte
>   https://bugzilla.redhat.com/1392878
> <https://bugzilla.redhat.com/1392878>
> 
> It isn't exactly the same problem, but as the cause of that bug is a
> pointer that is used after releasing, it can cause all kinds of strange
> effects.
> 
> Please try the latest build of the SDK.
> 
> 
> I thought I was:
> python-ovirt-engine-sdk4-4.1.0-0.1.a0.20161108gitaad5627.fc24.x86_64
>  

Yes, that build contains the fix, so we can discard it as the source of
your problem.

> 
> 
> >
> >
> > Thanks
> >
> > Ravi
> >
> > On Fri, Oct 14, 2016 at 4:00 PM, Yaniv Kaul <yk...@redhat.com 
> <mailto:yk...@redhat.com>
> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>> wrote:
> >
> > On Oct 14, 2016 7:13 PM, "Ravi Nori" <rn...@redhat.com 
> <mailto:rn...@redhat.com>
> > <mailto:rn...@redhat.com <mailto:rn...@redhat.com>>> wrote:
> > >
> > > SSO configuration looks good.
> > >
> > > Can you please share any additional httpd configuration in 
> /etc/httpd/conf.d. Anything to do with LocationMatch for ovirt-engine urls.
> >
> > This is a standard ovirt-system-tests on Lago installation,
> > nothing out of the ordinary,  but I'll check.
> > Y.
> >
> > >
> > > On Fri, Oct 14, 2016 at 12:52 PM, Yaniv Kaul 
> <yk...@redhat.com <mailto:yk...@redhat.com>
>   

Re: [ovirt-devel] Can't add DC with API v4 - client issue

[Juan Hernández]

ersion 0' means?)
> >>  
> >>>
> >>>
> >>> Please share the content of
> /etc/ovirt-engine/engine.conf.d/11-setup-sso.conf
> >>
> >>
> >> [root@lago-basic-suite-master-engine ~]# cat
> /etc/ovirt-engine/engine.conf.d/11-setup-sso.conf
> >> ENGINE_SSO_CLIENT_ID="ovirt-engine-core"
> >> ENGINE_SSO_CLIENT_SECRET="bsOabtD7gE2McwLe80P109UV800XLx4O"
> >> ENGINE_SSO_AUTH_URL="https://${ENGINE_FQDN}:443/ovirt-engine/sso;
> >>
> ENGINE_SSO_SERVICE_URL="https://localhost:443/ovirt-engine/sso
> <https://localhost:443/ovirt-engine/sso>"
> >> ENGINE_SSO_SERVICE_SSL_VERIFY_HOST=false
> >> ENGINE_SSO_SERVICE_SSL_VERIFY_CHAIN=true
> >> SSO_ALTERNATE_ENGINE_FQDNS=""
> >> SSO_ENGINE_URL="https://${ENGINE_FQDN}:443/ovirt-engine/;
> >>
> >>
> >> Thanks,
> >> Y.
> >>
> >>  
> >>>
> >>>
> >>> Thanks
> >>>
> >>> Ravi
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Oct 14, 2016 at 7:57 AM, Juan Hernández
> <jhern...@redhat.com <mailto:jhern...@redhat.com>> wrote:
> >>>>
> >>>> On 10/14/2016 01:45 PM, Yaniv Kaul wrote:
> >>>> >
> >>>> >
> >>>> > On Thu, Oct 13, 2016 at 11:13 AM, Juan Hernández
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> >>>> > <mailto:jhern...@redhat.com
> <mailto:jhern...@redhat.com>>> wrote:
> >>>> >
> >>>> > On 10/13/2016 12:04 AM, Yaniv Kaul wrote:
> >>>> > > On Fri, Oct 7, 2016 at 10:44 PM, Yaniv Kaul
> <yk...@redhat.com <mailto:yk...@redhat.com>
> <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>
> >>>> > > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>
> <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>>> wrote:
> >>>> > >
> >>>> > > I'm trying on FC24, using
> >>>> > >
> >>>> > 
> python-ovirt-engine-sdk4-4.1.0-0.0.20161003git056315d.fc24.x86_64 to
> >>>> > > add a DC, and failing - against master. The
> client is unhappy:
> >>>> > > File
> >>>> > >
> >>>> > 
> 
> "/home/ykaul/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
> >>>> > > line 98, in add_dc4
> >>>> > >   
>  version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
> >>>> > >   File
> "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py",
> >>>> > > line 4347, in add
> >>>> > > response = self._connection.send(request)
> >>>> > >   File
> "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> >>>> > > line 276, in send
> >>>> > > return self.__send(request)
> >>>> > >   File
> "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> >>>> > > line 298, in __send
> >>>> > > self._sso_token = self._get_access_token()
> >>>> > >   File
> "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> >>>> > > line 460, in _get_access_token
> >>>> > > sso_response =
> self._get_sso_response(self._sso_url,
> >>>> > post_data)
> >>>> > >   File
> "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> >>>> > > line 498, in _get_sso_response
&

Re: [ovirt-devel] Can't add DC with API v4 - client issue

[Juan Hernández]

On 10/14/2016 01:45 PM, Yaniv Kaul wrote:
> 
> 
> On Thu, Oct 13, 2016 at 11:13 AM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 10/13/2016 12:04 AM, Yaniv Kaul wrote:
> > On Fri, Oct 7, 2016 at 10:44 PM, Yaniv Kaul <yk...@redhat.com 
> <mailto:yk...@redhat.com>
> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>> wrote:
> >
> > I'm trying on FC24, using
> >   
>  python-ovirt-engine-sdk4-4.1.0-0.0.20161003git056315d.fc24.x86_64 to
> > add a DC, and failing - against master. The client is unhappy:
> > File
> >   
>  
> "/home/ykaul/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
> > line 98, in add_dc4
> > version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py",
> > line 4347, in add
> > response = self._connection.send(request)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> > line 276, in send
> > return self.__send(request)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> > line 298, in __send
> > self._sso_token = self._get_access_token()
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> > line 460, in _get_access_token
> > sso_response = self._get_sso_response(self._sso_url,
> post_data)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> > line 498, in _get_sso_response
> > return json.loads(body_buf.getvalue().decode('utf-8'))
> >   File "/usr/lib64/python2.7/json/__init__.py", line 339, in loads
> > return _default_decoder.decode(s)
> >   File "/usr/lib64/python2.7/json/decoder.py", line 364, in decode
> > obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> >   File "/usr/lib64/python2.7/json/decoder.py", line 382, in
> raw_decode
> > raise ValueError("No JSON object could be decoded")
> > ValueError: No JSON object could be decoded
> >
> >
> > Surprisingly, I now can't find that RPM of this SDK in
> > resources.ovirt.org <http://resources.ovirt.org>
> <http://resources.ovirt.org> now.
> >
> > I've tried
> > with
> 
> http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/python-ovirt-engine-sdk4-4.0.0-0.1.20161004gitf94eeb5.fc24.x86_64.rpm
> 
> <http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/python-ovirt-engine-sdk4-4.0.0-0.1.20161004gitf94eeb5.fc24.x86_64.rpm>
> >   
>  
> <http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/python-ovirt-engine-sdk4-4.0.0-0.1.20161004gitf94eeb5.fc24.x86_64.rpm
> 
> <http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/python-ovirt-engine-sdk4-4.0.0-0.1.20161004gitf94eeb5.fc24.x86_64.rpm>>
> >
> > - same result.
> >
> > Did not see anything obvious on server or engine logs.
> > The code:
> > def add_dc4(api):
> > nt.assert_true(api != None)
> > dcs_service = api.system_service().data_centers_service()
> > nt.assert_true(
> > dc = dcs_service.add(
> > sdk4.types.DataCenter(
> > name=DC_NAME4,
> > description='APIv4 DC',
> > local=False,
> >
> > version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
> > ),
> > )
> > )
> >
> >
> > And the api object is from:
> > return sdk4.Connection(
> > url=url,
> > username=constants.ENGINE_USER,
> >   
>  password=str(self.metadata['ovirt-engine-password']),
> > insecure=True,
> > debug=True,
> > )
> >
> >
> > The clue is actually on the HTTPd logs:
> > 192.168.203.1 - - [12/Oct/2016:17:56:27 -0400] "POST
> > /ovirt-engine/sso/oauth/token HTTP/1.1" 404 74
>

Re: [ovirt-devel] Can't add DC with API v4 - client issue

[Juan Hernández]

On 10/13/2016 12:04 AM, Yaniv Kaul wrote:
> On Fri, Oct 7, 2016 at 10:44 PM, Yaniv Kaul  > wrote:
> 
> I'm trying on FC24, using
> python-ovirt-engine-sdk4-4.1.0-0.0.20161003git056315d.fc24.x86_64 to
> add a DC, and failing - against master. The client is unhappy:
> File
> 
> "/home/ykaul/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
> line 98, in add_dc4
> version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py",
> line 4347, in add
> response = self._connection.send(request)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> line 276, in send
> return self.__send(request)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> line 298, in __send
> self._sso_token = self._get_access_token()
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> line 460, in _get_access_token
> sso_response = self._get_sso_response(self._sso_url, post_data)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py",
> line 498, in _get_sso_response
> return json.loads(body_buf.getvalue().decode('utf-8'))
>   File "/usr/lib64/python2.7/json/__init__.py", line 339, in loads
> return _default_decoder.decode(s)
>   File "/usr/lib64/python2.7/json/decoder.py", line 364, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>   File "/usr/lib64/python2.7/json/decoder.py", line 382, in raw_decode
> raise ValueError("No JSON object could be decoded")
> ValueError: No JSON object could be decoded
> 
> 
> Surprisingly, I now can't find that RPM of this SDK in
> resources.ovirt.org  now.
> 
> I've tried
> with 
> http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/python-ovirt-engine-sdk4-4.0.0-0.1.20161004gitf94eeb5.fc24.x86_64.rpm
> 
> 
>  
> 
> - same result.
> 
> Did not see anything obvious on server or engine logs.
> The code:
> def add_dc4(api):
> nt.assert_true(api != None)
> dcs_service = api.system_service().data_centers_service()
> nt.assert_true(
> dc = dcs_service.add(
> sdk4.types.DataCenter(
> name=DC_NAME4,
> description='APIv4 DC',
> local=False,
>
> version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
> ),
> )
> )
> 
> 
> And the api object is from:
> return sdk4.Connection(
> url=url,
> username=constants.ENGINE_USER,
> password=str(self.metadata['ovirt-engine-password']),
> insecure=True,
> debug=True,
> )
> 
> 
> The clue is actually on the HTTPd logs:
> 192.168.203.1 - - [12/Oct/2016:17:56:27 -0400] "POST
> /ovirt-engine/sso/oauth/token HTTP/1.1" 404 74
> 
> And indeed, from the deubg log:
> begin captured logging << \n
> root: DEBUG: Trying 192.168.203.3...\n
> root: DEBUG: Connected to 192.168.203.3 (192.168.203.3) port 443 (#0)\n
> root: DEBUG: Initializing NSS with certpath: sql:/etc/pki/nssdb\n
> root: DEBUG: skipping SSL peer certificate verification\n
> root: DEBUG: ALPN/NPN, server did not agree to a protocol\n
> root: DEBUG: SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256\n
> root: DEBUG: Server certificate:\n
> root: DEBUG: subject: CN=engine,O=Test,C=US\n
> root: DEBUG: start date: Oct 11 21:55:29 2016 GMT\n
> root: DEBUG: expire date: Sep 16 21:55:29 2021 GMT\n
> root: DEBUG: common name: engine\nroot: DEBUG: issuer:
> CN=engine.38998,O=Test,C=US\n
> *root: DEBUG: POST /ovirt-engine/sso/oauth/token HTTP/1.1\n*
> *root: DEBUG: Host: 192.168.203.3\n*
> *root: DEBUG: User-Agent: PythonSDK/4.1.0a0\n*
> *root: DEBUG: Accept: application/json\n*
> *root: DEBUG: Content-Length: 78\n*
> *root: DEBUG: Content-Type: application/x-www-form-urlencoded\nroot:
> DEBUG:
> username=admin%40internal=ovirt-app-api=123_type=password\n*
> *root: DEBUG: upload completely sent off: 78 out of 78 bytes\n*
> *root: DEBUG: HTTP/1.1 404 Not Found\n*
> *root: DEBUG: Date: Wed, 12 Oct 2016 21:56:27 GMT\n*
> *root: DEBUG: Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips\n*
> *root: DEBUG: Content-Length: 74\n*
> *root: DEBUG: Content-Type: text/html; charset=UTF-8\n*
> *root: DEBUG: \n*
> *root: DEBUG: Error404 - Not
> Found\n*
> root: DEBUG: Connection #0 to host 192.168.203.3 left intact\n
> - >> end captured logging
> 

That definitively looks like version 3 of the engine. Either that or

Re: [ovirt-devel] Can't add DC with API v4 - client issue

[Juan Hernández]

On 10/07/2016 09:44 PM, Yaniv Kaul wrote:
> I'm trying on FC24, using
> python-ovirt-engine-sdk4-4.1.0-0.0.20161003git056315d.fc24.x86_64 to add
> a DC, and failing - against master. The client is unhappy:
> File
> "/home/ykaul/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
> line 98, in add_dc4
> version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line
> 4347, in add
> response = self._connection.send(request)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
> 276, in send
> return self.__send(request)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
> 298, in __send
> self._sso_token = self._get_access_token()
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
> 460, in _get_access_token
> sso_response = self._get_sso_response(self._sso_url, post_data)
>   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/__init__.py", line
> 498, in _get_sso_response
> return json.loads(body_buf.getvalue().decode('utf-8'))
>   File "/usr/lib64/python2.7/json/__init__.py", line 339, in loads
> return _default_decoder.decode(s)
>   File "/usr/lib64/python2.7/json/decoder.py", line 364, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>   File "/usr/lib64/python2.7/json/decoder.py", line 382, in raw_decode
> raise ValueError("No JSON object could be decoded")
> ValueError: No JSON object could be decoded
> 

That is what happens when you try to connect version 3 of the server
with version 4 of the SDK: OAuth authentication fails with this
unexpected error. Are you sure you are using version 4 of the engine?
Can you try a simpler request? For example, try this example:


https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/test_connection.py

That will generate an "example.log" file. Can you share it? Take into
account that the log will contain your password, so make sure to remove
it or share it privately.

> 
> Surprisingly, I now can't find that RPM of this SDK in
> resources.ovirt.org  now.
> 
> I've tried
> with 
> http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/python-ovirt-engine-sdk4-4.0.0-0.1.20161004gitf94eeb5.fc24.x86_64.rpm
> 
>  
> 
> - same result.
> 
> Did not see anything obvious on server or engine logs.
> The code:
> def add_dc4(api):
> nt.assert_true(api != None)
> dcs_service = api.system_service().data_centers_service()
> nt.assert_true(
> dc = dcs_service.add(
> sdk4.types.DataCenter(
> name=DC_NAME4,
> description='APIv4 DC',
> local=False,
>
> version=sdk4.types.Version(major=DC_VER_MAJ,minor=DC_VER_MIN),
> ),
> )
> )
> 
> 
> And the api object is from:
> return sdk4.Connection(
> url=url,
> username=constants.ENGINE_USER,
> password=str(self.metadata['ovirt-engine-password']),
> insecure=True,
> debug=True,
> )
> 
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] backend jar dependencies that should probably be symlinks

[Juan Hernández]

On 10/04/2016 04:33 PM, Sandro Bonazzola wrote:
> 
> 
> On Tue, Oct 4, 2016 at 3:27 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 10/04/2016 03:16 PM, Sandro Bonazzola wrote:
> > Hi, I'm checking the packaging of ovirt-engine for 4.1 and I've
> some doubts:
> >
> > $ LC_ALL=C rpm -qlvp
> >
> 
> http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/noarch/ovirt-engine-backend-4.1.0-0.0.master.20161003221921.git2653cbc.fc24.noarch.rpm|grep
> 
> <http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/noarch/ovirt-engine-backend-4.1.0-0.0.master.20161003221921.git2653cbc.fc24.noarch.rpm|grep>
> > jar |grep -v ^l |grep common
> > -rw-r--r--1 rootroot77761 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/com/netflix/config/main/archaius-core.jar
> > -rw-r--r--1 rootroot16442 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/com/netflix/hystrix/contrib/main/hystrix-metrics-event-stream.jar
> > -rw-r--r--1 rootroot   290223 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/com/netflix/hystrix/main/hystrix-core.jar
> > -rw-r--r--1 rootroot   738300 Oct  4 00:20
> >
> /usr/share/ovirt-engine/modules/common/io/reactivex/rxjava/main/rxjava.jar
> > -rw-r--r--1 rootroot 6073 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/org/ovirt/engine/api/metamodel-server/main/metamodel-server.jar
> > -rw-r--r--1 rootroot 8224 Oct  4 00:21
> >
> 
> /usr/share/ovirt-engine/modules/common/org/ovirt/engine/core/auth-plugin/main/auth-plugin.jar
> > -rw-r--r--1 rootroot 4010 Oct  4 00:22
> >
> 
> /usr/share/ovirt-engine/modules/common/org/ovirt/engine/core/logger/main/logger.jar
> > -rw-r--r--1 rootroot   370051 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-aop.jar
> > -rw-r--r--1 rootroot   731512 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-beans.jar
> > -rw-r--r--1 rootroot  1097552 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-context.jar
> > -rw-r--r--1 rootroot  1078737 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-core.jar
> > -rw-r--r--1 rootroot   262990 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-expression.jar
> > -rw-r--r--1 rootroot 7243 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-instrument.jar
> > -rw-r--r--1 rootroot   423369 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-jdbc.jar
> > -rw-r--r--1 rootroot   265523 Oct  4 00:20
> >
> 
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-tx.jar
> >
> > $ dnf provides "*/archaius-core.jar" ->
> archaius-core-0.7.3-4.fc24.noarch
> > $ dnf provides "*/hystrix-metrics-event-stream.jar"
> > -> hystrix-metrics-event-stream-1.4.21-5.fc24.noarch
> > and so on with the other jar files.
> >
> > Any chance we can just reuse system libs and symlink them?
> >
> > Please note that the question is for el7 as well:
> >
> > $ LC_ALL=C rpm -qlvp
> >
> 
> http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-engine-backend-4.1.0-0.0.master.20161003211313.git2653cbc.el7.centos.noarch.rpm
> 
> <http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-engine-backend-4.1.0-0.0.master.20161003211313.git2653cbc.el7.centos.noarch.rpm>
> > |grep jar |grep -v ^l |grep common
> > -rw-r--r--1 rootroot   608376 Oct  3 23:14
> > /usr/share/ovirt-engine/modules/common/com/mchange/c3p0/main/c3p0.jar
> > -rw-r--r--1 rootroot77761 Oct  3 23:14
> >
> 
> /usr/share/ovirt-engine/modules/common/com/netflix/confi

Re: [ovirt-devel] backend jar dependencies that should probably be symlinks

[Juan Hernández]

On 10/04/2016 03:16 PM, Sandro Bonazzola wrote:
> Hi, I'm checking the packaging of ovirt-engine for 4.1 and I've some doubts:
> 
> $ LC_ALL=C rpm -qlvp
> http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/noarch/ovirt-engine-backend-4.1.0-0.0.master.20161003221921.git2653cbc.fc24.noarch.rpm|grep
> jar |grep -v ^l |grep common
> -rw-r--r--1 rootroot77761 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/com/netflix/config/main/archaius-core.jar
> -rw-r--r--1 rootroot16442 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/com/netflix/hystrix/contrib/main/hystrix-metrics-event-stream.jar
> -rw-r--r--1 rootroot   290223 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/com/netflix/hystrix/main/hystrix-core.jar
> -rw-r--r--1 rootroot   738300 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/io/reactivex/rxjava/main/rxjava.jar
> -rw-r--r--1 rootroot 6073 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/org/ovirt/engine/api/metamodel-server/main/metamodel-server.jar
> -rw-r--r--1 rootroot 8224 Oct  4 00:21
> /usr/share/ovirt-engine/modules/common/org/ovirt/engine/core/auth-plugin/main/auth-plugin.jar
> -rw-r--r--1 rootroot 4010 Oct  4 00:22
> /usr/share/ovirt-engine/modules/common/org/ovirt/engine/core/logger/main/logger.jar
> -rw-r--r--1 rootroot   370051 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-aop.jar
> -rw-r--r--1 rootroot   731512 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-beans.jar
> -rw-r--r--1 rootroot  1097552 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-context.jar
> -rw-r--r--1 rootroot  1078737 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-core.jar
> -rw-r--r--1 rootroot   262990 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-expression.jar
> -rw-r--r--1 rootroot 7243 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-instrument.jar
> -rw-r--r--1 rootroot   423369 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-jdbc.jar
> -rw-r--r--1 rootroot   265523 Oct  4 00:20
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-tx.jar
> 
> $ dnf provides "*/archaius-core.jar" -> archaius-core-0.7.3-4.fc24.noarch
> $ dnf provides "*/hystrix-metrics-event-stream.jar"
> -> hystrix-metrics-event-stream-1.4.21-5.fc24.noarch
> and so on with the other jar files.
> 
> Any chance we can just reuse system libs and symlink them?
> 
> Please note that the question is for el7 as well:
> 
> $ LC_ALL=C rpm -qlvp
> http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-engine-backend-4.1.0-0.0.master.20161003211313.git2653cbc.el7.centos.noarch.rpm
> |grep jar |grep -v ^l |grep common
> -rw-r--r--1 rootroot   608376 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/mchange/c3p0/main/c3p0.jar
> -rw-r--r--1 rootroot77761 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/netflix/config/main/archaius-core.jar
> -rw-r--r--1 rootroot16442 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/netflix/hystrix/contrib/main/hystrix-metrics-event-stream.jar
> -rw-r--r--1 rootroot   290223 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/netflix/hystrix/main/hystrix-core.jar
> -rw-r--r--1 rootroot23234 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/woorea/openstack/sdk/main/cinder-client.jar
> -rw-r--r--1 rootroot20755 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/woorea/openstack/sdk/main/cinder-model.jar
> -rw-r--r--1 rootroot18277 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/woorea/openstack/sdk/main/glance-client.jar
> -rw-r--r--1 rootroot 8780 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/woorea/openstack/sdk/main/glance-model.jar
> -rw-r--r--1 rootroot34756 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/woorea/openstack/sdk/main/keystone-client.jar
> -rw-r--r--1 rootroot23183 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/woorea/openstack/sdk/main/keystone-model.jar
> -rw-r--r--1 rootroot10861 Oct  3 23:14
> /usr/share/ovirt-engine/modules/common/com/woorea/openstack/sdk/main/openstack-client.jar
> -rw-r--r--1 root 

Re: [ovirt-devel] Failure in log collector on master: Failure fetching information about hypervisors from API. Error (ValueError): legacy is not a valid RngSource

[Juan Hernández]

On 09/06/2016 10:37 AM, Eyal Edri wrote:
> Glad to hear you found the issue!
> Let me know when it's merged so we can publish it to the nightlies and
> rerun the tests.
> 

The fix for the master branch was merged. The artifacts (including RPMs)
are available in the output of the following jobs:


http://jenkins.ovirt.org/job/ovirt-engine-sdk_master_build-artifacts-el7-x86_64/61
  http://jenkins.ovirt.org/job/ovirt-engine-sdk_master_build-artifacts-
fc24-x86_64/36

> On Tue, Sep 6, 2016 at 11:34 AM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 09/05/2016 08:43 PM, Rafael Martins wrote:
> > ----- Original Message -
> >> From: "Juan Hernández" <jhern...@redhat.com
> <mailto:jhern...@redhat.com>>
> >> To: "Yaniv Kaul" <yk...@redhat.com <mailto:yk...@redhat.com>>
> >> Cc: "Sandro Bonazzola" <sbona...@redhat.com
> <mailto:sbona...@redhat.com>>, "Rafael Martins" <rmart...@redhat.com
> <mailto:rmart...@redhat.com>>, "Ondra Machacek"
> >> <omach...@redhat.com <mailto:omach...@redhat.com>>, "devel"
> <devel@ovirt.org <mailto:devel@ovirt.org>>
> >> Sent: Friday, September 2, 2016 2:31:42 PM
> >> Subject: Re: [ovirt-devel] Failure in log collector on master:
> Failure fetching information about hypervisors from
> >> API. Error (ValueError): legacy is not a valid RngSource
> >>
> >> On 09/02/2016 02:24 PM, Yaniv Kaul wrote:
> >>> On Fri, Sep 2, 2016 at 3:14 PM, Juan Hernández
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> >>> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>> wrote:
> >>>
> >>> On 09/02/2016 02:00 PM, Sandro Bonazzola wrote:
> >>> >
> >>> >
> >>> > On Fri, Sep 2, 2016 at 1:38 PM, Yaniv Kaul
> <yk...@redhat.com <mailto:yk...@redhat.com>
> >>> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>
> >>> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>
> <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>>> wrote:
> >>> >
> >>> > Log:
> >>> >
> >>> > 2016-09-02 07:26:52::ERROR::hypervisors::197::root::
> Failure
> >>> > fetching information about hypervisors from API.
> >>> > Error (ValueError): legacy is not a valid RngSource
> >>> > 2016-09-02 07:26:52::ERROR::__main__::1147::root::
> >>> > _get_hypervisors_from_api: legacy is not a valid RngSource
> >>> > 2016-09-02 07:26:52::INFO::__main__::1424::root::
> Gathering oVirt
> >>> > Engine information...
> >>> > 2016-09-02 07:27:03::INFO::__main__::1398::root::
> Gathering
> >>> > PostgreSQL the oVirt Engine database and log files from
> >>> > localhost...
> >>> > 2016-09-02 07:27:05::INFO::__main__::1859::root:: No
> hypervisors
> >>> > were selected, therefore no hypervisor data will be
> collected.
> >>> > 2016-09-02 07:27:08::INFO::__main__::1862::root:: Log
> files have
> >>> > been collected and placed in
> >>> > /tmp/sosreport-LogCollector-20160902072705.tar.xz.
> >>> >
> >>> >
> >>> > I am not familiar with this error - first time I've
> seen it,
> >>> > while
> >>> > running on Master, on Lago (with a patch I'm working
> on - that
> >>> > adds
> >>> > DNS and IPv6 support to Lago, nothing more - doesn't seem
> >>> > relevant).
> >>> > Any idea?
> >>> >
> >>> >
> >>> >
> >>> > Probably a change in the API.
> >>> > Rafael can you reproduce?
> >>> >
> >>> > Juan, Ondra, any insight?
> >>> >
> >>>
> >>> That means that the API is returning "legacy" as the value for
> >>> something
> &

Re: [ovirt-devel] Failure in log collector on master: Failure fetching information about hypervisors from API. Error (ValueError): legacy is not a valid RngSource

[Juan Hernández]

On 09/06/2016 11:49 AM, Yaniv Kaul wrote:
> Interesting that we don't see it on 4.0, saw it's a regression
> introduced somewhere, or a test case we have not seen before?
> Y.
> 

It is a regression that was introduced recently in the master branch of
version 4 of the SDK. The patch that caused the issue wasn't backported
to the 4.0 branch of the SDK, thus you don't see it in 4.0.

> On Tue, Sep 6, 2016 at 11:37 AM, Eyal Edri <ee...@redhat.com
> <mailto:ee...@redhat.com>> wrote:
> 
> Glad to hear you found the issue!
> Let me know when it's merged so we can publish it to the nightlies
> and rerun the tests.
> 
> On Tue, Sep 6, 2016 at 11:34 AM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 09/05/2016 08:43 PM, Rafael Martins wrote:
>     > - Original Message -
> >> From: "Juan Hernández" <jhern...@redhat.com
> <mailto:jhern...@redhat.com>>
> >> To: "Yaniv Kaul" <yk...@redhat.com <mailto:yk...@redhat.com>>
> >> Cc: "Sandro Bonazzola" <sbona...@redhat.com
> <mailto:sbona...@redhat.com>>, "Rafael Martins"
> <rmart...@redhat.com <mailto:rmart...@redhat.com>>, "Ondra Machacek"
> >> <omach...@redhat.com <mailto:omach...@redhat.com>>, "devel"
> <devel@ovirt.org <mailto:devel@ovirt.org>>
> >> Sent: Friday, September 2, 2016 2:31:42 PM
> >> Subject: Re: [ovirt-devel] Failure in log collector on
> master: Failure fetching information about hypervisors from
> >> API. Error (ValueError): legacy is not a valid RngSource
> >>
> >> On 09/02/2016 02:24 PM, Yaniv Kaul wrote:
> >>> On Fri, Sep 2, 2016 at 3:14 PM, Juan Hernández
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> >>> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>
> wrote:
> >>>
> >>> On 09/02/2016 02:00 PM, Sandro Bonazzola wrote:
> >>> >
> >>> >
> >>> > On Fri, Sep 2, 2016 at 1:38 PM, Yaniv Kaul
> <yk...@redhat.com <mailto:yk...@redhat.com>
> >>> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>
> >>> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>
> <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>>> wrote:
> >>> >
> >>> > Log:
> >>> >
> >>> > 2016-09-02
> 07:26:52::ERROR::hypervisors::197::root:: Failure
> >>> > fetching information about hypervisors from API.
> >>> > Error (ValueError): legacy is not a valid RngSource
> >>> > 2016-09-02 07:26:52::ERROR::__main__::1147::root::
> >>> > _get_hypervisors_from_api: legacy is not a valid
> RngSource
> >>> > 2016-09-02 07:26:52::INFO::__main__::1424::root::
> Gathering oVirt
> >>> > Engine information...
> >>> > 2016-09-02 07:27:03::INFO::__main__::1398::root::
> Gathering
> >>> > PostgreSQL the oVirt Engine database and log files
> from
> >>> > localhost...
> >>> > 2016-09-02 07:27:05::INFO::__main__::1859::root::
> No hypervisors
> >>> > were selected, therefore no hypervisor data will
> be collected.
> >>> > 2016-09-02 07:27:08::INFO::__main__::1862::root::
> Log files have
> >>> > been collected and placed in
> >>> > /tmp/sosreport-LogCollector-20160902072705.tar.xz.
> >>> >
> >>> >
> >>> > I am not familiar with this error - first time
> I've seen it,
> >>> > while
> >>> > running on Master, on Lago (with a patch I'm
> working on - that
> >>> > adds
> >>> > DNS and IPv6 support to Lago, nothing more -
> doesn't seem
> >>> > relevant).
> >>>

Re: [ovirt-devel] Failure in log collector on master: Failure fetching information about hypervisors from API. Error (ValueError): legacy is not a valid RngSource

[Juan Hernández]

On 09/05/2016 08:43 PM, Rafael Martins wrote:
> - Original Message -
>> From: "Juan Hernández" <jhern...@redhat.com>
>> To: "Yaniv Kaul" <yk...@redhat.com>
>> Cc: "Sandro Bonazzola" <sbona...@redhat.com>, "Rafael Martins" 
>> <rmart...@redhat.com>, "Ondra Machacek"
>> <omach...@redhat.com>, "devel" <devel@ovirt.org>
>> Sent: Friday, September 2, 2016 2:31:42 PM
>> Subject: Re: [ovirt-devel] Failure in log collector on master: Failure 
>> fetching information about hypervisors from
>> API. Error (ValueError): legacy is not a valid RngSource
>>
>> On 09/02/2016 02:24 PM, Yaniv Kaul wrote:
>>> On Fri, Sep 2, 2016 at 3:14 PM, Juan Hernández <jhern...@redhat.com
>>> <mailto:jhern...@redhat.com>> wrote:
>>>
>>> On 09/02/2016 02:00 PM, Sandro Bonazzola wrote:
>>> >
>>> >
>>> > On Fri, Sep 2, 2016 at 1:38 PM, Yaniv Kaul <yk...@redhat.com
>>> > <mailto:yk...@redhat.com>
>>> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>> wrote:
>>> >
>>> > Log:
>>> >
>>> > 2016-09-02 07:26:52::ERROR::hypervisors::197::root:: Failure
>>> > fetching information about hypervisors from API.
>>> > Error (ValueError): legacy is not a valid RngSource
>>> > 2016-09-02 07:26:52::ERROR::__main__::1147::root::
>>> > _get_hypervisors_from_api: legacy is not a valid RngSource
>>> > 2016-09-02 07:26:52::INFO::__main__::1424::root:: Gathering oVirt
>>> > Engine information...
>>> > 2016-09-02 07:27:03::INFO::__main__::1398::root:: Gathering
>>> > PostgreSQL the oVirt Engine database and log files from
>>> > localhost...
>>> > 2016-09-02 07:27:05::INFO::__main__::1859::root:: No hypervisors
>>> > were selected, therefore no hypervisor data will be collected.
>>> > 2016-09-02 07:27:08::INFO::__main__::1862::root:: Log files have
>>> > been collected and placed in
>>> > /tmp/sosreport-LogCollector-20160902072705.tar.xz.
>>> >
>>> >
>>> > I am not familiar with this error - first time I've seen it,
>>> > while
>>> > running on Master, on Lago (with a patch I'm working on - that
>>> > adds
>>> > DNS and IPv6 support to Lago, nothing more - doesn't seem
>>> > relevant).
>>> > Any idea?
>>> >
>>> >
>>> >
>>> > Probably a change in the API.
>>> > Rafael can you reproduce?
>>> >
>>> > Juan, Ondra, any insight?
>>> >
>>>
>>> That means that the API is returning "legacy" as the value for
>>> something
>>> that is declared of type "RngSource", and the valid values for that are
>>> "random" and "hwrng". But the API can't return that, at least not
>>> version 4 of the API. Are you using engine 4? Can you share the output
>>> of the clusters resource?
>>>
>>>   https://.../ovirt-engine/api/clusters
>>>
>>>
>>> Lago is still using the v3 API.
>>> I'm not sure what the log collector is using. I assume[1] it's v4.
>>>
>>> Y.
>>> [1]
>>> https://github.com/oVirt/ovirt-log-collector/blob/dfaf35675bee3da1c53b4fd74b816efafa13d070/src/helper/hypervisors.py#L8
>>>
>>
>> But the version of the engine should be 4, if I understand correctly,
>> and SDK 4 should work correctly with that version of the engine. In
>> addition, if it the engine is version 3 the SDK connection should have
>> failed much earlier, during authentication.
> 
> Hi Juan,
> 
> I managed to reproduce this with "basic_suite_master" test from 
> ovirt-system-tests, that uses everything from master branch. This means that 
> engine version is 4, not 3. It seems to be an issue with engine/sdk, as the 
> value is actually stored on engine as "legacy". Here you can find the xml 
> output of the endpoints you asked: 
> https://gist.github.com/rafaelmartins/60c21e158a9e6453c14a673f77693d61
> 
> Please let me know if you need anything else.
> 
> Thanks,
> Rafael
> 

This is a bug in the Python SDK. Should be fixed by the f

Re: [ovirt-devel] Failure in log collector on master: Failure fetching information about hypervisors from API. Error (ValueError): legacy is not a valid RngSource

[Juan Hernández]

On 09/02/2016 02:24 PM, Yaniv Kaul wrote:
> On Fri, Sep 2, 2016 at 3:14 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 09/02/2016 02:00 PM, Sandro Bonazzola wrote:
> >
> >
> > On Fri, Sep 2, 2016 at 1:38 PM, Yaniv Kaul <yk...@redhat.com 
> <mailto:yk...@redhat.com>
> > <mailto:yk...@redhat.com <mailto:yk...@redhat.com>>> wrote:
> >
> > Log:
> >
> > 2016-09-02 07:26:52::ERROR::hypervisors::197::root:: Failure
> > fetching information about hypervisors from API.
> > Error (ValueError): legacy is not a valid RngSource
> > 2016-09-02 07:26:52::ERROR::__main__::1147::root::
> > _get_hypervisors_from_api: legacy is not a valid RngSource
> > 2016-09-02 07:26:52::INFO::__main__::1424::root:: Gathering oVirt
> > Engine information...
> > 2016-09-02 07:27:03::INFO::__main__::1398::root:: Gathering
> > PostgreSQL the oVirt Engine database and log files from localhost...
> > 2016-09-02 07:27:05::INFO::__main__::1859::root:: No hypervisors
> > were selected, therefore no hypervisor data will be collected.
> > 2016-09-02 07:27:08::INFO::__main__::1862::root:: Log files have
> > been collected and placed in
> > /tmp/sosreport-LogCollector-20160902072705.tar.xz.
> >
> >
> > I am not familiar with this error - first time I've seen it, while
> > running on Master, on Lago (with a patch I'm working on - that adds
> > DNS and IPv6 support to Lago, nothing more - doesn't seem relevant).
> > Any idea?
> >
> >
> >
> > Probably a change in the API.
> > Rafael can you reproduce?
> >
> > Juan, Ondra, any insight?
> >
> 
> That means that the API is returning "legacy" as the value for something
> that is declared of type "RngSource", and the valid values for that are
> "random" and "hwrng". But the API can't return that, at least not
> version 4 of the API. Are you using engine 4? Can you share the output
> of the clusters resource?
> 
>   https://.../ovirt-engine/api/clusters
> 
> 
> Lago is still using the v3 API.
> I'm not sure what the log collector is using. I assume[1] it's v4.
> 
> Y.
> [1]
> https://github.com/oVirt/ovirt-log-collector/blob/dfaf35675bee3da1c53b4fd74b816efafa13d070/src/helper/hypervisors.py#L8
> 

But the version of the engine should be 4, if I understand correctly,
and SDK 4 should work correctly with that version of the engine. In
addition, if it the engine is version 3 the SDK connection should have
failed much earlier, during authentication.

> 
> 
> >
> >
> >
> >
> > Y.
> >
> >
> >
> >
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community 
> collaboration.
> > See how it works at redhat.com <http://redhat.com> <http://redhat.com>
> >
> <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016
> <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>>
> >
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org <mailto:Devel@ovirt.org>
> > http://lists.ovirt.org/mailman/listinfo/devel
> <http://lists.ovirt.org/mailman/listinfo/devel>
> >
> 
> 
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat
> S.L.
> 
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failure in log collector on master: Failure fetching information about hypervisors from API. Error (ValueError): legacy is not a valid RngSource

[Juan Hernández]

On 09/02/2016 02:14 PM, Juan Hernández wrote:
> On 09/02/2016 02:00 PM, Sandro Bonazzola wrote:
>>
>>
>> On Fri, Sep 2, 2016 at 1:38 PM, Yaniv Kaul <yk...@redhat.com
>> <mailto:yk...@redhat.com>> wrote:
>>
>> Log:
>>
>> 2016-09-02 07:26:52::ERROR::hypervisors::197::root:: Failure
>> fetching information about hypervisors from API.
>> Error (ValueError): legacy is not a valid RngSource
>> 2016-09-02 07:26:52::ERROR::__main__::1147::root::
>> _get_hypervisors_from_api: legacy is not a valid RngSource
>> 2016-09-02 07:26:52::INFO::__main__::1424::root:: Gathering oVirt
>> Engine information...
>> 2016-09-02 07:27:03::INFO::__main__::1398::root:: Gathering
>> PostgreSQL the oVirt Engine database and log files from localhost...
>> 2016-09-02 07:27:05::INFO::__main__::1859::root:: No hypervisors
>> were selected, therefore no hypervisor data will be collected.
>> 2016-09-02 07:27:08::INFO::__main__::1862::root:: Log files have
>> been collected and placed in
>> /tmp/sosreport-LogCollector-20160902072705.tar.xz.
>>
>>
>> I am not familiar with this error - first time I've seen it, while
>> running on Master, on Lago (with a patch I'm working on - that adds
>> DNS and IPv6 support to Lago, nothing more - doesn't seem relevant).
>> Any idea?
>>
>>
>>
>> Probably a change in the API.
>> Rafael can you reproduce?
>>
>> Juan, Ondra, any insight?
>>
> 
> That means that the API is returning "legacy" as the value for something
> that is declared of type "RngSource", and the valid values for that are
> "random" and "hwrng". But the API can't return that, at least not
> version 4 of the API. Are you using engine 4? Can you share the output
> of the clusters resource?
> 
>   https://.../ovirt-engine/api/clusters
> 

And hosts as well, please:

  https://../ovirt-engine/api/hosts

>>  
>>
>>
>>
>> Y.
>>
>>
>>
>>
>> -- 
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com <http://redhat.com>
>> <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
> 
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Failure in log collector on master: Failure fetching information about hypervisors from API. Error (ValueError): legacy is not a valid RngSource

[Juan Hernández]

On 09/02/2016 02:00 PM, Sandro Bonazzola wrote:
> 
> 
> On Fri, Sep 2, 2016 at 1:38 PM, Yaniv Kaul  > wrote:
> 
> Log:
> 
> 2016-09-02 07:26:52::ERROR::hypervisors::197::root:: Failure
> fetching information about hypervisors from API.
> Error (ValueError): legacy is not a valid RngSource
> 2016-09-02 07:26:52::ERROR::__main__::1147::root::
> _get_hypervisors_from_api: legacy is not a valid RngSource
> 2016-09-02 07:26:52::INFO::__main__::1424::root:: Gathering oVirt
> Engine information...
> 2016-09-02 07:27:03::INFO::__main__::1398::root:: Gathering
> PostgreSQL the oVirt Engine database and log files from localhost...
> 2016-09-02 07:27:05::INFO::__main__::1859::root:: No hypervisors
> were selected, therefore no hypervisor data will be collected.
> 2016-09-02 07:27:08::INFO::__main__::1862::root:: Log files have
> been collected and placed in
> /tmp/sosreport-LogCollector-20160902072705.tar.xz.
> 
> 
> I am not familiar with this error - first time I've seen it, while
> running on Master, on Lago (with a patch I'm working on - that adds
> DNS and IPv6 support to Lago, nothing more - doesn't seem relevant).
> Any idea?
> 
> 
> 
> Probably a change in the API.
> Rafael can you reproduce?
> 
> Juan, Ondra, any insight?
> 

That means that the API is returning "legacy" as the value for something
that is declared of type "RngSource", and the valid values for that are
"random" and "hwrng". But the API can't return that, at least not
version 4 of the API. Are you using engine 4? Can you share the output
of the clusters resource?

  https://.../ovirt-engine/api/clusters

>  
> 
> 
> 
> Y.
> 
> 
> 
> 
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com 
> 
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Problems in engine pom files

[Juan Hernández]

On 08/20/2016 11:52 AM, Sandro Bonazzola wrote:
> It's a rainy Saturday and I'm getting annoyed so I'm looking at future
> and looks like at least in terms of maven future we have bad weather as
> well:
> 

What version of Maven is using rawhide? I use latest, 3.3.9, and it
doesn't generate those errors. Anyhow, I believe those errors can be
avoided:

  https://gerrit.ovirt.org/#/q/topic:fix_maven_errors

Hope your day gets sunnier :-) .

> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.(groupId:artifactId:type:classifier)'
> must be unique: ${engine.groupId}:common:test-jar -> duplicate
> declaration of version ${engine.version} @
> org.ovirt.engine.core:utils:[unknown-version],
> /builddir/build/BUILD/ovirt-engine-4.1.0/backend/manager/modules/utils/pom.xml,
> line 155, column 17
> [ERROR] 'build.plugins.plugin.(groupId:artifactId)' must be unique but
> found duplicate declaration of plugin
> org.codehaus.mojo:exec-maven-plugin @
> org.ovirt.engine.api:restapi-definition:[unknown-version],
> /builddir/build/BUILD/ovirt-engine-4.1.0/backend/manager/modules/restapi/interface/definition/pom.xml,
> line 213, column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-dependency-plugin is missing. @
> org.ovirt.engine.api:restapi-definition:[unknown-version],
> /builddir/build/BUILD/ovirt-engine-4.1.0/backend/manager/modules/restapi/interface/definition/pom.xml,
> line 72, column 15
>  @ 
> [ERROR] The build could not read 2 projects -> [Help 1]
> [ERROR]   
> [ERROR]   The project org.ovirt.engine.core:utils:4.1.0-SNAPSHOT
> (/builddir/build/BUILD/ovirt-engine-4.1.0/backend/manager/modules/utils/pom.xml)
> has 1 error
> [ERROR]
> 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be
> unique: ${engine.groupId}:common:test-jar -> duplicate declaration of
> version ${engine.version} @
> org.ovirt.engine.core:utils:[unknown-version],
> /builddir/build/BUILD/ovirt-engine-4.1.0/backend/manager/modules/utils/pom.xml,
> line 155, column 17
> [ERROR]   
> [ERROR]   The project
> org.ovirt.engine.api:restapi-definition:4.1.0-SNAPSHOT
> (/builddir/build/BUILD/ovirt-engine-4.1.0/backend/manager/modules/restapi/interface/definition/pom.xml)
> has 1 error
> [ERROR] 'build.plugins.plugin.(groupId:artifactId)' must be unique
> but found duplicate declaration of plugin
> org.codehaus.mojo:exec-maven-plugin @
> org.ovirt.engine.api:restapi-definition:[unknown-version],
> /builddir/build/BUILD/ovirt-engine-4.1.0/backend/manager/modules/restapi/interface/definition/pom.xml,
> line 213, column 15
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> 
> (got building engine on fedora rawhide aka fc26)
> 

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Bundled jar files in backend subpackage

[Juan Hernández]

On 08/18/2016 01:56 PM, Sandro Bonazzola wrote:
> Hi,
> looking at $ LC_ALL=C rpm -qlvp
> http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/noarch/ovirt-engine-backend-4.1.0-0.0.master.20160817221906.git75736af.fc24.noarch.rpm|grep
> jar |grep -v ^l |grep common
> 
> I see:
> 
> -rw-r--r--1 rootroot77761 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/com/netflix/config/main/archaius-core.jar
> -rw-r--r--1 rootroot16442 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/com/netflix/hystrix/contrib/main/hystrix-metrics-event-stream.jar
> -rw-r--r--1 rootroot   290223 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/com/netflix/hystrix/main/hystrix-core.jar
> -rw-r--r--1 rootroot   738300 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/io/reactivex/rxjava/main/rxjava.jar
> -rw-r--r--1 rootroot33218 Aug 18 00:19

I think these ^ are all related to the use of Hystrix, Roman will know.

> /usr/share/ovirt-engine/modules/common/org/apache/avalon/framework/main/avalon-framework-api.jar
> -rw-r--r--1 rootroot61021 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/avalon/framework/main/avalon-framework-impl.jar
> -rw-r--r--1 rootroot   401858 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/batik/main/batik-awt-util.jar
> -rw-r--r--1 rootroot   558892 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/batik/main/batik-bridge.jar
> -rw-r--r--1 rootroot   310919 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/batik/main/batik-css.jar
> -rw-r--r--1 rootroot10257 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/batik/main/batik-ext.jar
> -rw-r--r--1 rootroot67900 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/batik/main/batik-extension.jar
> -rw-r--r--1 rootroot   242866 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/batik/main/batik-gvt.jar
> -rw-r--r--1 rootroot   601098 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/batik/main/batik-svg-dom.jar
> -rw-r--r--1 rootroot   121997 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/batik/main/batik-transcoder.jar
> -rw-r--r--1 rootroot   128286 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/batik/main/batik-util.jar
> -rw-r--r--1 rootroot   569113 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/commons/main/xmlgraphics-commons.jar
> -rw-r--r--1 rootroot  3079811 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/apache/xmlgraphics/fop/main/fop.jar

Avalon framework, Batik, xmlgraphics and FOP can't be replaced by links,
because the versions included in Fedora are newer than what we need, and
they don't work correctly for us.

> -rw-r--r--1 rootroot 6071 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/ovirt/engine/api/metamodel-server/main/metamodel-server.jar

This ^ is an oVirt project, but not distributed as RPM, only via Maven
Central, so it can't be replaced with a link.

> -rw-r--r--1 rootroot 8225 Aug 18 00:20
> /usr/share/ovirt-engine/modules/common/org/ovirt/engine/core/auth-plugin/main/auth-plugin.jar
> -rw-r--r--1 rootroot 4012 Aug 18 00:22
> /usr/share/ovirt-engine/modules/common/org/ovirt/engine/core/logger/main/logger.jar

These ^ are part of the engine, they should go in
/usr/share/java/ovirt-engine, and should be replaced by links.

> -rw-r--r--1 rootroot   370051 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-aop.jar
> -rw-r--r--1 rootroot   731512 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-beans.jar
> -rw-r--r--1 rootroot  1097552 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-context.jar
> -rw-r--r--1 rootroot  1078737 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-core.jar
> -rw-r--r--1 rootroot   262990 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-expression.jar
> -rw-r--r--1 rootroot 7243 Aug 18 00:19
> /usr/share/ovirt-engine/modules/common/org/springframework/main/spring-instrument.jar
> -rw-r--r--1 rootroot   423369 Aug 18 00:19
> 

Re: [ovirt-devel] uuid_generate_v1 not random enough (was: Change in ovirt-engine[ovirt-engine-4.0.2]: build: ovirt-engine-4.0.2.3)

[Juan Hernández]

On 08/01/2016 11:02 AM, Yedidyah Bar David wrote:
> On Sun, Jul 31, 2016 at 6:35 PM, Jenkins CI  wrote:
>> Jenkins CI has posted comments on this change.
>>
>> Change subject: build: ovirt-engine-4.0.2.3
>> ..
>>
>>
>> Patch Set 2:
>>
>> Build Failed
>>
>> http://jenkins.ovirt.org/job/ovirt-engine_4.0.2_check-merged-el7-x86_64/64/ 
>> : FAILURE
> 
> 15:07:43 Running upgrade sql script
> './packaging/dbscripts/upgrade/03_05_0580_add_default_instance_types.sql'...
> 15:07:43 
> psql:./packaging/dbscripts/upgrade/03_05_0580_add_default_instance_types.sql:131:
> ERROR:  duplicate key value violates unique constraint
> "pk_permissions_id"
> 15:07:43 DETAIL:  Key (id)=() already exists.
> 
> Didn't try reproducing, but my best guess is that above uuid
> was generated by a call to uuid_generate_v1() in above file after it
> was already inserted to the table in
> dbscripts/data/00600_insert_permissions.sql.
> 
> Perhaps we should be using something more random.
> 
> [1] https://www.postgresql.org/docs/9.5/static/uuid-ossp.html
> 

Note that we did use that long time ago, and we decided to stop using it
because enabling that extension required an additional RPM package
(postgrersql-contrib) and different mechanisms to enable it in
PostgreSQL 8 and PostgreSQL 9, which was cumbersome. As we should now
support only PostgreSQL 9.2 or newer, this may be no longer a problem.
In that case you can just remove our "uuid_generate_v1" function and
enable the extension, the name of the function is the same.

However, it would be better, in general, to generate the identifiers
outside of the database, and pass them as parameters to the stored
procedures or SQL statements, that way we have less dependencies.

See bug 870056 for additional information.

>>
>> http://jenkins.ovirt.org/job/ovirt-engine_4.0.2_check-merged-fc23-x86_64/64/ 
>> : SUCCESS
>>
>> --
>> To view, visit https://gerrit.ovirt.org/61733
>> To unsubscribe, visit https://gerrit.ovirt.org/settings
>>
>> Gerrit-MessageType: comment
>> Gerrit-Change-Id: Ice9518eea22dfa19126e04e49f3a76ee86f3e3c0
>> Gerrit-PatchSet: 2
>> Gerrit-Project: ovirt-engine
>> Gerrit-Branch: ovirt-engine-4.0.2
>> Gerrit-Owner: Yedidyah Bar David 
>> Gerrit-Reviewer: Eyal Edri 
>> Gerrit-Reviewer: Jenkins CI
>> Gerrit-Reviewer: Oved Ourfali 
>> Gerrit-Reviewer: Yedidyah Bar David 
>> Gerrit-Reviewer: gerrit-hooks 
>> Gerrit-HasComments: No
> 
> 
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Ondra Machacek is now the main maintainer of the Python and Java SDK

[Juan Hernández]

Hello,

Ondra Machacek has been doing an excellent work in the new versions of
the Java and Python SDKs for version 4 of the engine. As a result we
have decided to appoint him as the main maintainer of these two
components. Starting intermediately he will take full responsibility and
ownership of version 4 of these SDKs.

Regards,
Juan Hernandez

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] No RPMs under http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/ ?

[Juan Hernández]

On 04/11/2016 02:07 PM, Gil Shinar wrote:
> Hi,
> 
> Now it should be OK till Juan will permanently fix that.
> 
> Gil
> 

What do I need to fix?

> On Mon, Apr 11, 2016 at 3:02 PM, Sandro Bonazzola  > wrote:
> 
> 
> 
> On Mon, Apr 11, 2016 at 11:34 AM, Yaniv Kaul  > wrote:
> 
> I can't find EL7 RPMs under the above path. 
> They used to be there...
> 
> 
> 
> There have been an issue in nighlty publisher, Gil was on it this
> morning, didn't have time yet to check the current status
> 
>  
> 
> TIA,
> Y.
> 
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> 
> 
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community
> collaboration.
> See how it works at redhat.com 
> 
> 
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] How to debug NullPointerException for project restapi-def inition of version 3.6.4.1?

[Juan Hernández]

On 04/07/2016 10:50 AM, Kai Kang wrote:
> 
> 
> On Thu, Apr 7, 2016 at 3:55 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 04/07/2016 08:34 AM, Martin Mucha wrote:
> >
> >
> > - Original Message -
> >>
>     >>
> >> On Wed, Apr 6, 2016 at 6:03 PM, Juan Hernández <
> jhern...@redhat.com <mailto:jhern...@redhat.com> > wrote:
> >>
> >>
> >>
> >> On 04/06/2016 11:51 AM, Kai Kang wrote:
> >>> Hi,
> >>>
> >>> I am building ovirt-engine 3.6.4.1 and failed with
> NullPointerException.
> >>> I build for cross compile with commands:
> >>>
> >>>
> >>>
> >>>
> 
> tmp_repo=/buildarea3/kkang/builds/Mar31-ovrit-engine/bitbake_build/tmp/work/corei7-64-wrs-linux/ovirt-engine/3.6.4.1-r0/repo
> >>> export MAVEN_OPTS="-Dmaven.repo.local=$tmp_repo"
> >>>
> >>> make EXTRA_BUILD_FLAGS="-s
> >>>
> 
> /buildarea3/kkang/builds/Mar31-ovrit-engine/bitbake_build/tmp/work/corei7-64-wrs-linux/ovirt-engine/3.6.4.1-r0/settings.xml
> >>> --debug --offline" -j1 BUILD_GWT=1 BUILD_LOCALES=0
> >>> BUILD_UT=1 BUILD_VALIDATION=0
> >>> JAVA_DIR=/usr/share/ovirt-engine/java LOCALSTATE_DIR=/var
> >>> MAVENPOM_DIR=/usr/share/ovirt-engine/maven-poms PREFIX=/usr
> >>> SYSCONF_DIR=/etc PKG_SYSCONF_DIR=/etc/ovirt-engine
> >>> PKG_DOC_DIR=/usr/doc/ovirt-engine
> >>> PKG_EAR_DIR=/usr/share/ovirt-engine/engine.ear
> >>> PKG_PKI_DIR=/etc/pki/ovirt-engine
> >>> PKG_JBOSS_MODULES=/usr/share/ovirt-engine/modules
> >>> PKG_CACHE_DIR=/var/cache/ovirt-engine
> >>> PKG_LOG_DIR=/var/log/ovirt-engine
> >>> PKG_TMP_DIR=/var/tmp/ovirt-engine
> >>> PKG_STATE_DIR=/var/lib/ovirt-engine PKG_USER=ovirt PKG_GROUP=ovirt
> >>> all
> >>>
> >>>
> >>> The error messages show:
> >>>
> >>> [INFO] oVirt Engine API Definition ...
> FAILURE [1.476s]
> >>> ...
> >>> [INFO]
> >>>
> 
> >>> [ERROR] Failed to execute goal
> >>> org.codehaus.mojo:exec-maven-plugin:1.2:java (default) on project
> >>> restapi-definition: An exception occured while executing the
> Java class.
> >>> null: InvocationTargetException: NullPointerException -> [Help 1]
> >>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> >>> execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java
> (default) on
> >>> project restapi-definition: An exception occured while executing the
> >>> Java class. null
> >>> at
> >>>
> 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> >>> ...
> >>> at javax.xml.bind.JAXB.marshal(JAXB.java:332)
> >>> at
> >>>
> org.ovirt.engine.api.rsdl.RsdlManager.serializeRsdl(RsdlManager.java:134)
> >>> at
> >>>
> 
> org.ovirt.engine.api.rsdl.RsdlManager.generateRsdlFile(RsdlManager.java:84)
> >>> at org.ovirt.engine.api.rsdl.RsdlManager.main(RsdlManager.java:58)
> >>> ... 6 more
> >>>
> >>>
> >>> My questions are:
> >>>
> >>> 1 I know the error occurs in
> >>> file
> >>>
> 
> backend/manager/modules/restapi/interface/definition/src/main/java/org/ovirt/engine/api/rsdl/RsdlManager.java,
> >>> but how to debug it?
> >>>
> >>> 2 When I remove pom and jar files of javax.xml.bind.JAXB in mave
> repo
> >>> with offline mode, it still could find the class.
> >>> Which javax.xml.bind.JAXB is used? I searched the ovirt engine
> repo but
> >>> didn't find it either.
> >>>
> >>
> >> The version of JAXB used by that area of the code is the version
> of JAXB
> >> included in the JDK that you are using for the build. So the
> question is
> >> what version of the JDK are you using?
> >>
> >> Hi Juan,
>

Re: [ovirt-devel] How to debug NullPointerException for project restapi-def inition of version 3.6.4.1?

[Juan Hernández]

On 04/07/2016 08:34 AM, Martin Mucha wrote:
> 
> 
> - Original Message -
>>
>>
>> On Wed, Apr 6, 2016 at 6:03 PM, Juan Hernández < jhern...@redhat.com > wrote:
>>
>>
>>
>> On 04/06/2016 11:51 AM, Kai Kang wrote:
>>> Hi,
>>>
>>> I am building ovirt-engine 3.6.4.1 and failed with NullPointerException.
>>> I build for cross compile with commands:
>>>
>>>
>>>
>>> tmp_repo=/buildarea3/kkang/builds/Mar31-ovrit-engine/bitbake_build/tmp/work/corei7-64-wrs-linux/ovirt-engine/3.6.4.1-r0/repo
>>> export MAVEN_OPTS="-Dmaven.repo.local=$tmp_repo"
>>>
>>> make EXTRA_BUILD_FLAGS="-s
>>> /buildarea3/kkang/builds/Mar31-ovrit-engine/bitbake_build/tmp/work/corei7-64-wrs-linux/ovirt-engine/3.6.4.1-r0/settings.xml
>>> --debug --offline" -j1 BUILD_GWT=1 BUILD_LOCALES=0
>>> BUILD_UT=1 BUILD_VALIDATION=0
>>> JAVA_DIR=/usr/share/ovirt-engine/java LOCALSTATE_DIR=/var
>>> MAVENPOM_DIR=/usr/share/ovirt-engine/maven-poms PREFIX=/usr
>>> SYSCONF_DIR=/etc PKG_SYSCONF_DIR=/etc/ovirt-engine
>>> PKG_DOC_DIR=/usr/doc/ovirt-engine
>>> PKG_EAR_DIR=/usr/share/ovirt-engine/engine.ear
>>> PKG_PKI_DIR=/etc/pki/ovirt-engine
>>> PKG_JBOSS_MODULES=/usr/share/ovirt-engine/modules
>>> PKG_CACHE_DIR=/var/cache/ovirt-engine
>>> PKG_LOG_DIR=/var/log/ovirt-engine
>>> PKG_TMP_DIR=/var/tmp/ovirt-engine
>>> PKG_STATE_DIR=/var/lib/ovirt-engine PKG_USER=ovirt PKG_GROUP=ovirt
>>> all
>>>
>>>
>>> The error messages show:
>>>
>>> [INFO] oVirt Engine API Definition ... FAILURE [1.476s]
>>> ...
>>> [INFO]
>>> 
>>> [ERROR] Failed to execute goal
>>> org.codehaus.mojo:exec-maven-plugin:1.2:java (default) on project
>>> restapi-definition: An exception occured while executing the Java class.
>>> null: InvocationTargetException: NullPointerException -> [Help 1]
>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
>>> execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java (default) on
>>> project restapi-definition: An exception occured while executing the
>>> Java class. null
>>> at
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
>>> ...
>>> at javax.xml.bind.JAXB.marshal(JAXB.java:332)
>>> at
>>> org.ovirt.engine.api.rsdl.RsdlManager.serializeRsdl(RsdlManager.java:134)
>>> at
>>> org.ovirt.engine.api.rsdl.RsdlManager.generateRsdlFile(RsdlManager.java:84)
>>> at org.ovirt.engine.api.rsdl.RsdlManager.main(RsdlManager.java:58)
>>> ... 6 more
>>>
>>>
>>> My questions are:
>>>
>>> 1 I know the error occurs in
>>> file
>>> backend/manager/modules/restapi/interface/definition/src/main/java/org/ovirt/engine/api/rsdl/RsdlManager.java,
>>> but how to debug it?
>>>
>>> 2 When I remove pom and jar files of javax.xml.bind.JAXB in mave repo
>>> with offline mode, it still could find the class.
>>> Which javax.xml.bind.JAXB is used? I searched the ovirt engine repo but
>>> didn't find it either.
>>>
>>
>> The version of JAXB used by that area of the code is the version of JAXB
>> included in the JDK that you are using for the build. So the question is
>> what version of the JDK are you using?
>>
>> Hi Juan,
>>
>> I am using icedtea7 to build openjdk-7. And I found the JAXB file.
> 
> note: I saw same line using java-1.8.0-openjdk installed from repo. 
> 

The build of the master branch (what will eventually be oVirt 4)
requires Java 8, but Kai Kang is trying to build 3.6.4.1, which should
build correctly with Java 7. I just tried that, with the version of
OpenJDK 7 included in CentOS 7:

  $ java -version
  java version "1.7.0_85"
  OpenJDK Runtime Environment (rhel-2.6.1.2.el7_1-x86_64 u85-b01)
  OpenJDK 64-Bit Server VM (build 24.85-b03, mixed mode

Kai Kang, from the "icedtea7" and "openjdk-7" names I assume that you
aren't using CentOS or Fedora, which are the typical distributions used
for oVirt. What distribution are you using exactly? And what version of
openjdk-7 exactly? If you share that information we may be able to
reproduce.

>>
>> Would you like to give some advice how to debug this issue? Does jdb could
>> debug such code?
>>

The easiest way to debug this to have an IDE, like IntelliJ Idea, or
Eclipse, set a breakpoint in the relevant li

Re: [ovirt-devel] How to debug NullPointerException for project restapi-def inition of version 3.6.4.1?

[Juan Hernández]

On 04/06/2016 11:51 AM, Kai Kang wrote:
> Hi,
> 
> I am building ovirt-engine 3.6.4.1 and failed with NullPointerException.
> I build for cross compile with commands:
> 
> 
>
> tmp_repo=/buildarea3/kkang/builds/Mar31-ovrit-engine/bitbake_build/tmp/work/corei7-64-wrs-linux/ovirt-engine/3.6.4.1-r0/repo
> export MAVEN_OPTS="-Dmaven.repo.local=$tmp_repo"
> 
> makeEXTRA_BUILD_FLAGS="-s
> /buildarea3/kkang/builds/Mar31-ovrit-engine/bitbake_build/tmp/work/corei7-64-wrs-linux/ovirt-engine/3.6.4.1-r0/settings.xml
> --debug --offline"-j1 BUILD_GWT=1 BUILD_LOCALES=0
> BUILD_UT=1  BUILD_VALIDATION=0
>  JAVA_DIR=/usr/share/ovirt-engine/java   LOCALSTATE_DIR=/var
> MAVENPOM_DIR=/usr/share/ovirt-engine/maven-poms PREFIX=/usr
> SYSCONF_DIR=/etcPKG_SYSCONF_DIR=/etc/ovirt-engine  
> PKG_DOC_DIR=/usr/doc/ovirt-engine  
> PKG_EAR_DIR=/usr/share/ovirt-engine/engine.ear
>  PKG_PKI_DIR=/etc/pki/ovirt-engine  
> PKG_JBOSS_MODULES=/usr/share/ovirt-engine/modules  
> PKG_CACHE_DIR=/var/cache/ovirt-engine  
> PKG_LOG_DIR=/var/log/ovirt-engine  
> PKG_TMP_DIR=/var/tmp/ovirt-engine  
> PKG_STATE_DIR=/var/lib/ovirt-engine PKG_USER=ovirt  PKG_GROUP=ovirt
>  all
> 
> 
> The error messages show:
> 
> [INFO] oVirt Engine API Definition ... FAILURE [1.476s]
> ...
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.codehaus.mojo:exec-maven-plugin:1.2:java (default) on project
> restapi-definition: An exception occured while executing the Java class.
> null: InvocationTargetException: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> execute goal org.codehaus.mojo:exec-maven-plugin:1.2:java (default) on
> project restapi-definition: An exception occured while executing the
> Java class. null
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> ...
> at javax.xml.bind.JAXB.marshal(JAXB.java:332)
> at
> org.ovirt.engine.api.rsdl.RsdlManager.serializeRsdl(RsdlManager.java:134)
> at
> org.ovirt.engine.api.rsdl.RsdlManager.generateRsdlFile(RsdlManager.java:84)
> at org.ovirt.engine.api.rsdl.RsdlManager.main(RsdlManager.java:58)
> ... 6 more
> 
> 
> My questions are:
> 
> 1 I know the error occurs in
> file 
> backend/manager/modules/restapi/interface/definition/src/main/java/org/ovirt/engine/api/rsdl/RsdlManager.java,
> but how to debug it?
> 
> 2 When I remove pom and jar files of javax.xml.bind.JAXB in mave repo
> with offline mode, it still could find the class.
> Which javax.xml.bind.JAXB is used? I searched the ovirt engine repo but
> didn't find it either.
> 

The version of JAXB used by that area of the code is the version of JAXB
included in the JDK that you are using for the build. So the question is
what version of the JDK are you using?

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] How can users use oVirtCli to complete "run once"?

[Juan Hernández]

On 03/08/2016 10:14 AM, Sandro Bonazzola wrote:
> 
> 
> On Mon, Feb 29, 2016 at 8:21 AM, zhukaijie  > wrote:
> 
> As you know. In web, users can use "RUN ONCE" button to run a VM
> with some params (such as certain custom properties). But can
> oVirtCli be used to complete "RUN ONCE"? Thank you.
> 
> 
> Juan?
> 

In the API the "run once" mode is enabled adding a "vm" element to the
action, something like this:

  POST /vms/{vm:id}/start
  

  ...

  

Unfortunately the CLI doesn't have any mechanism to say that you want to
send an empty element. To do it you will need to pass some option that
forces the inclusion of that "vm" element. If you don't want to actually
change anything in the VM then you can just pass the name, which will be
ignored:

  action vm myvm start --vm-name myvm

If you want to do something more complicated, like passing other boot
options, or using cloud-init or sysprep, I'd suggest you consider using
one of the SDKs instead of the CLI.

>  
> 
> ___
> Devel mailing list
> Devel@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> 
> 
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com 
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] master ovirt-engine requires ovirt-engine-sdk-python >= 4.0.0.0

[Juan Hernández]

On 03/07/2016 10:59 AM, Yedidyah Bar David wrote:
> On Mon, Mar 7, 2016 at 11:44 AM, Juan Hernández <jhern...@redhat.com> wrote:
>> On 03/07/2016 10:37 AM, Rafael Martins wrote:
>>> - Original Message -
>>>> From: "Juan Hernández" <jhern...@redhat.com>
>>>> To: "Sandro Bonazzola" <sbona...@redhat.com>, "Yedidyah Bar David" 
>>>> <d...@redhat.com>
>>>> Cc: "devel" <devel@ovirt.org>
>>>> Sent: Monday, March 7, 2016 10:21:25 AM
>>>> Subject: Re: [ovirt-devel] master ovirt-engine requires 
>>>> ovirt-engine-sdk-python >= 4.0.0.0
>>>>
>>>> On 03/07/2016 09:19 AM, Sandro Bonazzola wrote:
>>>>>
>>>>>
>>>>> On Sun, Mar 6, 2016 at 4:31 PM, Yedidyah Bar David <d...@redhat.com
>>>>> <mailto:d...@redhat.com>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I am trying, on a rhel7 vm:
>>>>>
>>>>> yum install -y
>>>>> http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm
>>>>>
>>>>> yum install ovirt-engine
>>>>>
>>>>> Fails with:
>>>>>
>>>>> --> Finished Dependency Resolution
>>>>> Error: Package:
>>>>> 
>>>>> ovirt-iso-uploader-4.0.0-0.0.master.20160208072812.gita433ce3.el7.centos.noarch
>>>>> (ovirt-master-snapshot)
>>>>>Requires: ovirt-engine-sdk-python >= 4.0.0.0
>>>>>
>>>>>
>>>>>
>>>>> Starting Friday night, jenkins suffered major issues resulting in
>>>>> publisher not working at all.
>>>>> I re-triggered the publishers this morning but looks that
>>>>>
>>>>> ovirt-engine-sdk-python >= 0:4.0.0.0 can't be satisfied by
>>>>> python-ovirt-engine-sdk4-4.0.0-0.0.20160303gita6aee01.el7.centos.x86_64.rpm
>>>>> due to name change.
>>>>>
>>>>> We need to fix the spec files requiring the new package.
>>>>>
>>>>
>>>> Fixing the spec files isn't enough, as the new
>>>> "python-ovirt-engine-sdk4" package isn't backwards compatible with the
>>>> previous "ovirt-engine-sdk-python" package.
>>>>
>>>> You have three alternatives:
>>>>
>>>> 1. Work with version 3.6 of the SDK. At the moment this is what I 
>>>> recommend.
>>>>
>>>> 2. Work with the new "python-ovirt-engine-sdk4" package. This is what we
>>>> should eventually do, but it requires important changes to the code. If
>>>> you want to go this way, please let me know and I'll help you do the
>>>> migration.
> 
> Is it considered stable already?
> 

It can't be considered stable. It is in alpha status at the moment.

> Among the repos I checked, I found:
> 
> ovirt-engine-cli/ovirt-engine-cli.spec.in:Requires:
> ovirt-engine-sdk-python >= 3.6.0.0
> ovirt-hosted-engine-setup/ovirt-hosted-engine-setup.spec.in:Requires:
>  ovirt-engine-sdk-python >= 4.0.0.0
> ovirt-image-uploader/ovirt-image-uploader.spec.in:Requires:
> ovirt-engine-sdk-python >= 4.0.0.0
> ovirt-iso-uploader/ovirt-iso-uploader.spec.in:Requires:
> ovirt-engine-sdk-python >= 4.0.0.0
> ovirt-log-collector/ovirt-log-collector.spec.in:Requires:
> ovirt-engine-sdk-python3 >= 4.0.0.0
> ovirt-log-collector/ovirt-log-collector.spec.in:Requires:
> ovirt-engine-sdk-python >= 4.0.0.0
> 
> I guess -cli, the uploaders, and -collector can be considered
> "not-urgent" and can simply wait until we fix them.
> 
> Main issue is that currently the engine requires the uploaders. We
> recently re-removed log-collector req upstream, perhaps we can do that
> with the uploaders too. Personally I do not think they are that
> important, especially since 4.0 should have a web ui uploader at some
> point.
> 
> hosted-engine-setup might be a bit more urgent, not sure.
> 
> All of them, I guess, use very little functionality of the engine/sdk
> and can probably be ported to the new sdk quite easily, if it's
> considered stable.
> 
> Not sure how to use 3.6 sdk - we can patch all of them to require >=
> 3.6 and add it to the -snapshot-static repo, and/or tell people to add
> the 3.6 repos when they want master (not healthy imo, because we do
> want to know if someone has to use something from 3.6 f

Re: [ovirt-devel] master ovirt-engine requires ovirt-engine-sdk-python >= 4.0.0.0

[Juan Hernández]

On 03/07/2016 10:37 AM, Rafael Martins wrote:
> - Original Message -
>> From: "Juan Hernández" <jhern...@redhat.com>
>> To: "Sandro Bonazzola" <sbona...@redhat.com>, "Yedidyah Bar David" 
>> <d...@redhat.com>
>> Cc: "devel" <devel@ovirt.org>
>> Sent: Monday, March 7, 2016 10:21:25 AM
>> Subject: Re: [ovirt-devel] master ovirt-engine requires 
>> ovirt-engine-sdk-python >= 4.0.0.0
>>
>> On 03/07/2016 09:19 AM, Sandro Bonazzola wrote:
>>>
>>>
>>> On Sun, Mar 6, 2016 at 4:31 PM, Yedidyah Bar David <d...@redhat.com
>>> <mailto:d...@redhat.com>> wrote:
>>>
>>> Hi all,
>>>
>>> I am trying, on a rhel7 vm:
>>>
>>> yum install -y
>>> http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm
>>>
>>> yum install ovirt-engine
>>>
>>> Fails with:
>>>
>>> --> Finished Dependency Resolution
>>> Error: Package:
>>> 
>>> ovirt-iso-uploader-4.0.0-0.0.master.20160208072812.gita433ce3.el7.centos.noarch
>>> (ovirt-master-snapshot)
>>>Requires: ovirt-engine-sdk-python >= 4.0.0.0
>>>
>>>
>>>
>>> Starting Friday night, jenkins suffered major issues resulting in
>>> publisher not working at all.
>>> I re-triggered the publishers this morning but looks that
>>>
>>> ovirt-engine-sdk-python >= 0:4.0.0.0 can't be satisfied by
>>> python-ovirt-engine-sdk4-4.0.0-0.0.20160303gita6aee01.el7.centos.x86_64.rpm
>>> due to name change.
>>>
>>> We need to fix the spec files requiring the new package.
>>>
>>
>> Fixing the spec files isn't enough, as the new
>> "python-ovirt-engine-sdk4" package isn't backwards compatible with the
>> previous "ovirt-engine-sdk-python" package.
>>
>> You have three alternatives:
>>
>> 1. Work with version 3.6 of the SDK. At the moment this is what I recommend.
>>
>> 2. Work with the new "python-ovirt-engine-sdk4" package. This is what we
>> should eventually do, but it requires important changes to the code. If
>> you want to go this way, please let me know and I'll help you do the
>> migration.
>>
>> 3. Work with some of the "ovirt-engine-sdk-python-4.0.0" RPM files that
>> were produced in the transition from the old SDK to the new one. I don't
>> recommend this.
> 
> Hi Juan,
> 
> do you have a summary of API changes in the version 4 of the SDK, compared 
> with version 3? I tried find it in git, but it seems that you deleted all the 
> code of version 3 in one commit, and added all the code of version 4 in 
> other, making it hard to try to see the changes.
> 
> Thanks
> 
> Rafael
> 

The new SDK is completely different from the old one, that is why I
deleted everything and added the new one. A diff won't help you find the
differences.

The main difference is that in the new SDK types and services are
separate things. In the previous version of the SDK methods like "start"
used to be part of the "VM" class. This doesn't reflect the actual
design of the API, as you may get a VM from places where "start" doesn't
make sense, for example, a VM to be imported from an export storage
domain. This caused many issues in the previous SDK. In the new SDK
types are just containers for data. Operations, like "start" are part of
services.

I suggest you look at the examples:

  https://github.com/oVirt/ovirt-engine-sdk/tree/master/sdk/examples

>>>
>>>  
>>>
>>>Available:
>>> ovirt-engine-sdk-python-3.6.0.3-1.el7.centos.noarch (centos-ovirt36)
>>>ovirt-engine-sdk-python = 3.6.0.3-1.el7.centos
>>>Available: ovirt-engine-sdk-python-3.6.2.1-1.el7.noarch
>>> (centos-ovirt36)
>>>ovirt-engine-sdk-python = 3.6.2.1-1.el7
>>>Installing: ovirt-engine-sdk-python-3.6.3.0-1.el7.noarch
>>> (centos-ovirt36)
>>>ovirt-engine-sdk-python = 3.6.3.0-1.el7
>>> Error: Package:
>>> 
>>> ovirt-image-uploader-4.0.0-0.0.master.20160211135948.git43cc942.el7.centos.noarch
>>> (ovirt-master-snapshot)
>>>Requires: ovirt-engine-sdk-python >= 4.0.0.0
>>>Available:
>>> ovirt-engine-sdk-python-3.6.0.3-1.el7.centos.noarch (centos-ovirt36)
>>>ovirt-engin

Re: [ovirt-devel] master ovirt-engine requires ovirt-engine-sdk-python >= 4.0.0.0

[Juan Hernández]

On 03/07/2016 09:19 AM, Sandro Bonazzola wrote:
> 
> 
> On Sun, Mar 6, 2016 at 4:31 PM, Yedidyah Bar David  > wrote:
> 
> Hi all,
> 
> I am trying, on a rhel7 vm:
> 
> yum install -y
> http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm
> 
> yum install ovirt-engine
> 
> Fails with:
> 
> --> Finished Dependency Resolution
> Error: Package:
> 
> ovirt-iso-uploader-4.0.0-0.0.master.20160208072812.gita433ce3.el7.centos.noarch
> (ovirt-master-snapshot)
>Requires: ovirt-engine-sdk-python >= 4.0.0.0
> 
> 
> 
> Starting Friday night, jenkins suffered major issues resulting in
> publisher not working at all.
> I re-triggered the publishers this morning but looks that
> 
> ovirt-engine-sdk-python >= 0:4.0.0.0 can't be satisfied by
> python-ovirt-engine-sdk4-4.0.0-0.0.20160303gita6aee01.el7.centos.x86_64.rpm
> due to name change.
> 
> We need to fix the spec files requiring the new package.
> 

Fixing the spec files isn't enough, as the new
"python-ovirt-engine-sdk4" package isn't backwards compatible with the
previous "ovirt-engine-sdk-python" package.

You have three alternatives:

1. Work with version 3.6 of the SDK. At the moment this is what I recommend.

2. Work with the new "python-ovirt-engine-sdk4" package. This is what we
should eventually do, but it requires important changes to the code. If
you want to go this way, please let me know and I'll help you do the
migration.

3. Work with some of the "ovirt-engine-sdk-python-4.0.0" RPM files that
were produced in the transition from the old SDK to the new one. I don't
recommend this.

> 
>  
> 
>Available:
> ovirt-engine-sdk-python-3.6.0.3-1.el7.centos.noarch (centos-ovirt36)
>ovirt-engine-sdk-python = 3.6.0.3-1.el7.centos
>Available: ovirt-engine-sdk-python-3.6.2.1-1.el7.noarch
> (centos-ovirt36)
>ovirt-engine-sdk-python = 3.6.2.1-1.el7
>Installing: ovirt-engine-sdk-python-3.6.3.0-1.el7.noarch
> (centos-ovirt36)
>ovirt-engine-sdk-python = 3.6.3.0-1.el7
> Error: Package:
> 
> ovirt-image-uploader-4.0.0-0.0.master.20160211135948.git43cc942.el7.centos.noarch
> (ovirt-master-snapshot)
>Requires: ovirt-engine-sdk-python >= 4.0.0.0
>Available:
> ovirt-engine-sdk-python-3.6.0.3-1.el7.centos.noarch (centos-ovirt36)
>ovirt-engine-sdk-python = 3.6.0.3-1.el7.centos
>Available: ovirt-engine-sdk-python-3.6.2.1-1.el7.noarch
> (centos-ovirt36)
>ovirt-engine-sdk-python = 3.6.2.1-1.el7
>Installing: ovirt-engine-sdk-python-3.6.3.0-1.el7.noarch
> (centos-ovirt36)
>ovirt-engine-sdk-python = 3.6.3.0-1.el7
> 
> Tried also:
> 
> yum install
> 
> http://jenkins.ovirt.org/job/ovirt-engine-sdk_master_build-artifacts-el7-x86_64/lastSuccessfulBuild/artifact/exported-artifacts/python-ovirt-engine-sdk4-4.0.0-0.0.20160303gita6aee01.el7.centos.x86_64.rpm
> 
> 
> which works, but does not satisfy the above dep. Should it? Any other
> place to find 4.0 python sdk?
> 
> Thanks,
> --
> Didi
> 
> 
> 
> 
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com 
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ATN] RESTAPI specification moving to a separate git repository

[Juan Hernández]

On 01/20/2016 08:06 PM, Yevgeny Zaspitsky wrote:
> Juan,
> 
> Well done!
> 
> But, there is a mismatch between gerrit and gitub links in your e-mail.
> 
> Regards,
> Yevgeny
> 

You are right, I'm fixing inline. The names of the gerrit projects are
as follows:

  ovirt-engine-api-model
  ovirt-engine-api-metamodel

I included the github URLs because they are a easy an nice way to see
the content:

  https://github.com/oVirt/ovirt-engine-api-model
  https://github.com/oVirt/ovirt-engine-api-metamodel

> On Thu, Jan 7, 2016 at 5:15 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> Hello,
> 
> The specification of the RESTAPI (a.k.a. the model) and the tools that
> process it (a.k.a. the metamodel) have been moved to separate git
> repositories:
> 
>   Model:
>   git clone https://gerrit.ovirt.org/ovirt-engine-api-model
>   https://github.com/oVirt/ovirt-engine-api-metamodel

This ^ should be https://github.com/oVirt/ovirt-engine-api-model.

> 
>   Metamodel:
>   git clone https://gerrit.ovirt.org/ovirt-engine-api-metamodel
>   https://github.com/oVirt/ovirt-engine-api-model

This ^ should be https://github.com/oVirt/ovirt-engine-api-model.

> 
> Currently I'm manually keeping these repositories in sync with the
> ovirt-engine repository, but I will very soon remove all this code from
> the ovirt-engine repository:
> 
>   restapi: Move model to separate repository
>   https://gerrit.ovirt.org/51519
> 
> This means that once the above patch is merged, which will be very soon,
> probably this week, when you need to do changes to the specification of
> the RESTAPI, you will need first to prepare a patch for the
> ovirt-engine-api-model, submit it, review it, etc. Once that patch is
> merged I will do a new release of the model. Then you will need to
> update the root POM of the engine to use the new version of the model,
> for example:
> 
>   - 4.0.1
>   + 4.0.2
> 
> And adjust the engine to work with the new version of the model.
> 
> As you will probably want to do these changes and test them before
> publishing anything, or asking for any review, I'd suggest the following
> process:
> 
> 1. Checkout the model project:
> 
>   $ git clone git://gerrit.ovirt.org/ovirt-engine-api-model
> <http://gerrit.ovirt.org/ovirt-engine-api-model>
> 
> 2. Check the version number in the root POM. It should be a SNAPSHOT
> version, unless you explicitly checkout from a tag. For example,
> currently it is 4.0.2-SNAPSHOT.
> 
> 3. Make your changes to the model, and then install it to your local
> Maven repository:
> 
>   $ mvn clean install
> 
> 4. Add to your $HOME/.m2/settings.xml a profile that is activated
> automatically and that changes the value of the "model.version" property
> used by the engine:
> 
>   
> myprofile
>   
> 
>   
> 
>   myprofile
>   
> 4.0.2-SNAPSHOT
>   
> 
>   
> 
> 5. Make your changes to the engine, and build it as usual, it will your
> modified version of the model.
> 
> 6. Publish/review the changes to the model.
> 
> 7. Wait for the new model release.
> 
> 8. Publish/review the changes to the engine, including the change of the
> model version in the root POM. Note that you can publish/review these
> changes without waiting for the new model release, but the Jenkins test
> will fail.
> 
> Note also that changes to the model will need to be properly documented
> in order to be accepted. There are some instructions on how to document
> the model here:
> 
>   https://github.com/oVirt/ovirt-engine-api-model/blob/master/README.md
> 
> All these changes affect only the master branch, nothing changed in
> these regards in the 3.6 branch.
> 
> Regards,
> Juan Hernandez
> 

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Alpha version of the Ruby SDK ready for use

[Juan Hernández]

Hello,

Version 4 of oVirt will include a new Ruby SDK. It is currently in
"alpha" status, but I think it is already usable. It is available from
"rubygems.org":

  https://rubygems.org/gems/ovirt-engine-sdk

You can install it as usual:

  $ gem install ovirt-engine-sdk

There are examples of how to use it in the source code itself:

  https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/sdk/README.md
  https://github.com/oVirt/ovirt-engine-sdk-ruby/tree/master/sdk/examples

Any feedback is welcome, via this list, reporting bugs:

  https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-engine-sdk-ruby

Or sending patches to gerrit:

  $ git clone git://gerrit.ovirt.org/ovirt-engine-sdk-ruby.git

Regards,
Juan Hernandez

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] New git repositories ovirt-engine-api-model, ovirt-engine-api-metamodel and ovirt-engine-api-explorer

[Juan Hernández]

Hello,

As part of the changes of the engine REST API for 4.0 two now components
have been introduced:

- The API model. This is the specification of the API, and it is
currently part of the engine repository, in the
backend/manager/modules/restapi/model directory.

- The API metamodel. This is a set of tools that read the model and
generate different artifacts from it, like the XML schema, the the
JAX-RS interfaces, etc. It is also currently part of the engine
repository, in the backend/manager/modules/restapi/metamodel.

In order to support multiple versions of the specification inside the
same engine the API model needs to be separated to a different git
repository, its releases managed independently of the engine, and the
artifacts uploaded to Maven central.

The metamodel also needs to be separated to a different repository, and
have its own relase cycle, and the artifacts uploaded to Maven central,
as they will be required by the engine and by the generators of the SDKs.

Thus I'm requesting the creation of two new git repositories in
gerrit.ovirt.org to hold these components:

  ovirt-engine-api-model
  ovirt-engine-api-metamodel

In addition version 4.0 will also include a web application used to
explore the automatically generated reference documentation. This
application is currently hosted here:

  https://github.com/jhernand/ovirt-api-explorer

But I think it should be hosted in gerrit.ovirt.org, thus I'm also
requesting the creation of another git repository:

  ovirt-engine-api-explorer

All in call, can you please create these three git repositories and add
me as maintainer, please?

Thanks in advance,
Juan Hernandez

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Slides for the Java 8 presentation yesterday

[Juan Hernández]

Hello all,

The slides for the Java 8 new features that I delivered yesterday are
available here:

https://jhernand.fedorapeople.org/java8/slides.html

There is no recording, as hangout failed and I forgot to record the
BlueJeans call, sorry.

Regards,
Juan Hernandez
-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Slides for the Java 8 presentation yesterday

[Juan Hernández]

On 12/02/2015 10:53 AM, Martin Mucha wrote:
> Thanks Juan, I've read your slides and learn something new from them.
> 
> And I'd like to ask one small thing about how lambdas are represented. It 
> seems that from early draft there were 'some changes' — from inner class 
> representation, to runtime generated inner class representation, to no 
> classes in the end. So if spec says, that [quote]:
> 
> The value of a lambda expression is a reference to an instance of a class 
> with the following properties:
> • The class implements the targeted functional interface type and, if the 
> target type is an intersection type, every other interface type mentioned in 
> the intersection.
> …
> 
> and in current implementation class type of lambda is now it's enclosing 
> class type, it means, that lambda is represented by instance of class its 
> defined in(this instanceof  in lambda returns true). Then it 
> seems that enclosing type has to implement functional interface to fulfill 
> spec. Which seems wild, provided, that with two 'Runnable-representing' 
> lambdas enclosing class has to implement Runnable twice, with two different 
> implementations, which is usually impossible.
> 
> as you know more about this subject, can I ask you to confirm this statements 
> / explain where I'm wrong and how it works internally / or explain what kind 
> of sorcery is going on here?
> 
> thanks,
> Mar.
> 

I'm not an expert in the subject, but as far as I understand there are
two mechanisms used to implement the lambda expressions. First is that
the body of the lambda expression is implemented as a method within the
class were it is used. For example, if you write a class like this:

  public class Test {
public go() {
  Runnable my = () -> System.out.println("Hello!");
  my.run();
}
  }

The compiler will ad a new synthetic method to the class, named
"lambda$main$0", containing the body of the expression:

  private static void labmda$main$0() {
System.out.println("Hello!");
  }

In this case the method is static, because the expression doesn't need
to access members of the containing class, and it doesn't receive
parameters because it doesn't use variables or parameters from its
environment. If it used members it wouldn't have been static, and would
have parameters, one for each local variable or parameter used. For
example, if you change the class to this:

 public class Test {
   String member;

   public void go(String parameter) {
 String local = "local";
 Runnable my = () -> {
   System.out.println(member);
   System.out.println(parameter);
   System.out.println(local);
 };
 my.run();
   }
}

Then the generated method looks like this:

  private void labmda$main$0(String parameter, String local) {
System.out.println(member);
System.out.println(parameter);
System.out.println(local);
  }

Note that the method isn't now static, that is why it can access
members, and why "this" doesn't mean the same that it means in anonymous
inner classes. Note that this doesn't mean that the type of the
expression is the enclosing class, just that "this" has a different meaning.

The second mechanism is the "invokedynamic" instruction, introduced in
Java 7. This is used to instantiate the the object that wraps the
expression. In the above example, the following line:

  Runnable my = () -> { ... }

Is translated by the compiler in a "invokedynamic" instruction like this:

  invokedynamic #3, 0 // InvokeDynamic
#0:run:(LTest;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Runnable;

I won't go into the details here (and I don't know them very well
either), but more or less this is telling the Java virtual machine that
during run time, the first time that this instruction is executed, it
should use the lambda expressions bootstrap method to find (maybe
create, "linking" is the term) an object that implements the "Runnable"
interface such that the "run" method class the "lambda$run$0" method. I
guess that these classes are generated with a mechanism similar to
java.lang.reflect.Proxy, but not exactly the same.

> - Original Message -
>> Thanks Juan for the great presentation !!
>>
>> On Wed, Dec 2, 2015 at 10:50 AM, Juan Hernández < jhern...@redhat.com >
>> wrote:
>>
>>
>> Hello all,
>>
>> The slides for the Java 8 new features that I delivered yesterday are
>> available here:
>>
>> https://jhernand.fedorapeople.org/java8/slides.html
>>
>> There is no recording, as hangout failed and I forgot to record the
>> BlueJeans call, sorry.
>>
>> Regards,
>> Juan Hernandez
>> --

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] ovirt-engine-sdk-python too slow

[Juan Hernández]

On 11/29/2015 09:57 AM, John Hunter wrote:
> So is this a bug or something?
> 
> Can I do something to fix the bug?
> 
> btw, adding Michael Pasternak
> 

It is this bug:

  [RFE][performance] - generate large scale list running to slow.
  https://bugzilla.redhat.com/1221238

We don't have any concrete plans to fix it.

You can try to fix it yourself, but it is in a very fragile part of the
SDK, chances of causing regressions are very high. I'd rather suggest
you to avoid calling the SDK multiple times, or just avoid the SDK and
use some other solution.

> On Thu, Nov 26, 2015 at 7:52 PM, Nir Soffer <nsof...@redhat.com
> <mailto:nsof...@redhat.com>> wrote:
> 
> Thanks John, very interesting results.
> 
> On Thu, Nov 26, 2015 at 3:17 AM, John Hunter <zhjw...@gmail.com
> <mailto:zhjw...@gmail.com>> wrote:
> 
> Hi Juan,
> 
> On Thu, Nov 26, 2015 at 2:15 AM, Juan Hernández
> <jhern...@redhat.com <mailto:jhern...@redhat.com>> wrote:
> 
> On 11/25/2015 06:45 PM, Nir Soffer wrote:
> > $ ./profile-stats -c myscript.prof
> >
> > Wed Nov 25 10:40:11 2015myscript.prof
> >
> >  7892315 function calls (7891054 primitive calls)
> in 7.940 seconds
> >
> >Ordered by: internal time
> >List reduced from 1518 to 20 due to restriction <20>
> >
> >ncalls  tottime  percall  cumtime  percall
> filename:lineno(function)
> >  90862.6930.0006.7060.001
> inspect.py:247(getmembers)
> >   19524941.3940.0001.8800.000
> inspect.py:59(isclass)
> >  90921.0300.0001.0300.000 {dir}
> >   19526420.6000.0000.6000.000 {getattr}
> >   19727650.5040.0000.5040.000 {isinstance}
> > 30.3340.1110.3340.111 {method
> 'perform' of
> > 'pycurl.Curl' objects}
> >   18839180.2840.0000.2840.000 {method
> 'append' of 'list'
> > objects}
> >  90870.2210.0000.2210.000 {method
> 'sort' of 'list'
> > objects}
> >  90510.1720.0006.9110.001
> > reflectionhelper.py:51(isModuleMember)
> > 10.1240.1240.3540.354
> errors.py:17()
> > 10.0880.0880.2300.230
> params.py:8()
> >  88790.0700.0006.9980.001
> params.py:367(__setattr__)
> > 10.0470.0475.1825.182
> api.py:23()
> > 10.0250.0254.7434.743
> brokers.py:22()
> > 10.0230.0230.0300.030
> > connectionspool.py:17()
> > 10.0220.0220.0530.053
> > lxml.etree.pyx:1(PyMODINIT_FUNC PyInit_etree(void))
> >   1180.0190.0004.6840.040
> params.py:45277(__init__)
> > 50.0150.0030.0240.005 {built-in
> method strptime}
> > 10.0120.0120.0130.013
> socket.py:45()
> >100.0110.0010.0150.002
> collections.py:288(namedtuple)
> >
> > So it is not the classes, it is the code inspecting them
> on import.
> >
> 
> The script doesn't contain only the imports, it is also
> calling the
> server, and we know parsing the result is slow, due to the
> excesive use
> of "inspect", as I mentioned before:
> 
>   [RFE][performance] - generate large scale list running to
> slow.
>   https://bugzilla.redhat.com/show_bug.cgi?id=1221238#c2
> 
> In the profiling information seems to corresponds to the
> script before
> commenting out the part that lists all the VMs, as it looks
> like the
> constructor of the VM class was called 21 times (you
> probably have 21 VMs):
> 
>   21 0.004 1.308
> 
> build/bdist.linux-x86_64/egg/ovirtsdk/infrastructure/brokers

Re: [ovirt-devel] ovirt-engine-sdk-python too slow

[Juan Hernández]

On 11/25/2015 06:45 PM, Nir Soffer wrote:
> $ ./profile-stats -c myscript.prof
> 
> Wed Nov 25 10:40:11 2015myscript.prof
> 
>  7892315 function calls (7891054 primitive calls) in 7.940 seconds
> 
>Ordered by: internal time
>List reduced from 1518 to 20 due to restriction <20>
> 
>ncalls  tottime  percall  cumtime  percall filename:lineno(function)
>  90862.6930.0006.7060.001 inspect.py:247(getmembers)
>   19524941.3940.0001.8800.000 inspect.py:59(isclass)
>  90921.0300.0001.0300.000 {dir}
>   19526420.6000.0000.6000.000 {getattr}
>   19727650.5040.0000.5040.000 {isinstance}
> 30.3340.1110.3340.111 {method 'perform' of
> 'pycurl.Curl' objects}
>   18839180.2840.0000.2840.000 {method 'append' of 'list'
> objects}
>  90870.2210.0000.2210.000 {method 'sort' of 'list'
> objects}
>  90510.1720.0006.9110.001
> reflectionhelper.py:51(isModuleMember)
> 10.1240.1240.3540.354 errors.py:17()
> 10.0880.0880.2300.230 params.py:8()
>  88790.0700.0006.9980.001 params.py:367(__setattr__)
> 10.0470.0475.1825.182 api.py:23()
> 10.0250.0254.7434.743 brokers.py:22()
> 10.0230.0230.0300.030
> connectionspool.py:17()
> 10.0220.0220.0530.053
> lxml.etree.pyx:1(PyMODINIT_FUNC PyInit_etree(void))
>   1180.0190.0004.6840.040 params.py:45277(__init__)
> 50.0150.0030.0240.005 {built-in method strptime}
> 10.0120.0120.0130.013 socket.py:45()
>100.0110.0010.0150.002 collections.py:288(namedtuple)
> 
> So it is not the classes, it is the code inspecting them on import.
> 

The script doesn't contain only the imports, it is also calling the
server, and we know parsing the result is slow, due to the excesive use
of "inspect", as I mentioned before:

  [RFE][performance] - generate large scale list running to slow.
  https://bugzilla.redhat.com/show_bug.cgi?id=1221238#c2

In the profiling information seems to corresponds to the script before
commenting out the part that lists all the VMs, as it looks like the
constructor of the VM class was called 21 times (you probably have 21 VMs):

  21 0.004 1.308
build/bdist.linux-x86_64/egg/ovirtsdk/infrastructure/brokers.py:29139(VM)

> Nir
> 
> On Wed, Nov 25, 2015 at 7:49 AM, John Hunter <zhjw...@gmail.com
> <mailto:zhjw...@gmail.com>> wrote:
> 
> Hi Nir,
> 
> Attachment is my script and its profile.
> Thanks a lot about your help!
> 
> On Wed, Nov 25, 2015 at 5:49 AM, Nir Soffer <nsof...@redhat.com
> <mailto:nsof...@redhat.com>> wrote:
> 
> On Tue, Nov 24, 2015 at 3:49 PM, John Hunter <zhjw...@gmail.com
> <mailto:zhjw...@gmail.com>> wrote:
> 
> 
> 
> On Tue, Nov 24, 2015 at 9:15 PM, Juan Hernández
> <jhern...@redhat.com <mailto:jhern...@redhat.com>> wrote:
> 
> On 11/24/2015 01:40 PM, John Hunter wrote:
> > Hi,
> >
> > On Tue, Nov 24, 2015 at 5:18 PM, Oved Ourfali 
> <oourf...@redhat.com <mailto:oourf...@redhat.com>
> > <mailto:oourf...@redhat.com <mailto:oourf...@redhat.com>>> 
> wrote:
> >
> > Hi
> >
> > I discussed it with Juan (cc-ed).
> >
> > There used to be a bug in the JDBC authenticion 
> extension that
> > artificially delayed RESTAPI responses by 5 seconds:
> >
> >   brute force prevention login delay should not be 
> applied to successful
> > login requests
> >   https://bugzilla.redhat.com/1255814
> >
> > That matches the description of the issue, but in 
> theory it has been
> > fixed. I would suggest him to check that he is using 
> the right version
> > of the extension.
> >
> > I did not use the extension 
> ovirt-engine-extension-aaa-jdbc, and I don't
> > think this bug matches my problem, because even there is 
> only one line
> > in the python script, it still cost like 3 seconds, I don't 
> think this is a
>  

Re: [ovirt-devel] ovirt-engine-sdk-python too slow

[Juan Hernández]

On 11/24/2015 01:40 PM, John Hunter wrote:
> Hi,
> 
> On Tue, Nov 24, 2015 at 5:18 PM, Oved Ourfali  > wrote:
> 
> Hi
> 
> I discussed it with Juan (cc-ed).
> 
> There used to be a bug in the JDBC authenticion extension that
> artificially delayed RESTAPI responses by 5 seconds:
> 
>   brute force prevention login delay should not be applied to successful
> login requests
>   https://bugzilla.redhat.com/1255814
> 
> That matches the description of the issue, but in theory it has been
> fixed. I would suggest him to check that he is using the right version
> of the extension.
> 
> I did not use the extension ovirt-engine-extension-aaa-jdbc, and I don't 
> think this bug matches my problem, because even there is only one line
> in the python script, it still cost like 3 seconds, I don't think this is a
> reasonable time as when I import other package, it cost almost no time.
> 
> Can you explain why this import line costs so much time?
> 

If you are using 3.6 then you are using ovirt-engine-extension-aaa-jdbc,
as it is enabled by default, but looks like it isn't related to your
problem.

That line takes a long time to execute because it has to process two
large Python modules: the "params" module that contains a class per each
type used by the API (393 classes) and the "brokers" module that
contains a class per each resource used by the API (358 classes). That
makes a total of 751 classes. In my environment it takes 0.9 seconds,
approx. You may want to use the python profile in your environment and
share the results:

$ cat > profile.py <<.
import cProfile
cProfile.run("from ovirtsdk.api import API")
.

$ python profile.py

I won't be surprised to see this taking those 3 seconds in a slower
environment.

But even if this takes those 3 seconds it shouldn't be a big problem,
because you shouldn't be running that "from ... import ..." line
frequently. Your program should do this once only, when it starts.

> 
> In addition we also know that retrieving large lists of objects with the
> SDK is slow:
> 
>[RFE][performance] - generate large scale list running to slow.
>https://bugzilla.redhat.com/1221238
> 
> We don't have a solution for that yet.
> 
> CC-ing Juan in case you have additional questions.
> 
> 
> On Mon, Nov 23, 2015 at 11:27 AM, John Hunter  > wrote:
> 
> Hi guys,
> 
> I am using the ovirt-engine-sdk-python to communicate with the
> ovirt-engine,
> I am ok to list the vms but the processing time is too long,
> like 4.5 seconds,
> and this line:
> from ovirtsdk.api import API
> take almost 3 seconds.
> 
> This seems a little bit longer than I expected it to be, so I am
> asking is there
> a quicker way to communicate with the ovirt-engine? 
> 

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] ovirt-engine-sdk-python too slow

[Juan Hernández]

On 11/24/2015 02:49 PM, John Hunter wrote:
> 
> 
> On Tue, Nov 24, 2015 at 9:15 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 11/24/2015 01:40 PM, John Hunter wrote:
> > Hi,
> >
> > On Tue, Nov 24, 2015 at 5:18 PM, Oved Ourfali <oourf...@redhat.com 
> <mailto:oourf...@redhat.com>
> > <mailto:oourf...@redhat.com <mailto:oourf...@redhat.com>>> wrote:
> >
> > Hi
> >
> > I discussed it with Juan (cc-ed).
> >
> > There used to be a bug in the JDBC authenticion extension that
> > artificially delayed RESTAPI responses by 5 seconds:
> >
> >   brute force prevention login delay should not be applied to 
> successful
> > login requests
> >   https://bugzilla.redhat.com/1255814
> >
> > That matches the description of the issue, but in theory it has been
> > fixed. I would suggest him to check that he is using the right 
> version
> > of the extension.
> >
> > I did not use the extension ovirt-engine-extension-aaa-jdbc, and I don't
> > think this bug matches my problem, because even there is only one line
> > in the python script, it still cost like 3 seconds, I don't think this 
> is a
> > reasonable time as when I import other package, it cost almost no time.
> >
> > Can you explain why this import line costs so much time?
> >
> 
> If you are using 3.6 then you are using ovirt-engine-extension-aaa-jdbc,
> as it is enabled by default, but looks like it isn't related to your
> problem.
> 
> That line takes a long time to execute because it has to process two
> large Python modules: the "params" module that contains a class per each
> type used by the API (393 classes) and the "brokers" module that
> contains a class per each resource used by the API (358 classes). That
> makes a total of 751 classes. In my environment it takes 0.9 seconds,
> approx. You may want to use the python profile in your environment and
> share the results:
> 
> $ cat > profile.py <<.
> import cProfile
> cProfile.run("from ovirtsdk.api import API")
> .
> 
> $ python profile.py
> 
> I won't be surprised to see this taking those 3 seconds in a slower
> environment.
> 
> But even if this takes those 3 seconds it shouldn't be a big problem,
> because you shouldn't be running that "from ... import ..." line
> frequently. Your program should do this once only, when it starts.
> 
> Assume that I have two functions to implement, one is to list all the
> vms belong
> to the user, and the other is to retrieve one vm's virt-viewer
> connection file, as 
> far as I can see, I have to write two python scripts and import the
> ovirtsdk.api in both
> scripts, each script has to take the 3 seconds :(
> 
> How can I run the "from ... import ..." just once ?
>  

I don't know what technology or tools are you using to write that
program, but if you are using Python then you don't need to import it twice.

If for whatever the reason you decide to call external python scripts
from another program then you will have to pay the price of the startup
of the Python SDK. If that is unacceptable because of performance then
you should look for a different way to access the RESTAPI, like sending
XML or JSON directly, or using the Java SDK, or rbovirt, it all depends
on the technology that you are using for your application.

> 
> >
> > In addition we also know that retrieving large lists of objects 
> with the
> > SDK is slow:
> >
> >[RFE][performance] - generate large scale list running to slow.
> >https://bugzilla.redhat.com/1221238
> >
> > We don't have a solution for that yet.
> >
> > CC-ing Juan in case you have additional questions.
> >
> >
> > On Mon, Nov 23, 2015 at 11:27 AM, John Hunter <zhjw...@gmail.com 
> <mailto:zhjw...@gmail.com>
> > <mailto:zhjw...@gmail.com <mailto:zhjw...@gmail.com>>> wrote:
> >
> > Hi guys,
> >
> > I am using the ovirt-engine-sdk-python to communicate with the
> > ovirt-engine,
> > I am ok to list the vms but the processing time is too long,
> > like 4.5 seconds,
> > and this line:
> > from ovirtsdk.api import API
> > take almost 3 seconds.
> >
> > This seems a little bit longer than I expected it to be, so I am
> > asking is there
> > a quicker way to communicate with the ovirt-engine?
> >
> 

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Requiring Java 8 during runtime

[Juan Hernández]

On 10/27/2015 04:04 PM, Tal Nisan wrote:
> I agree with Allon, there's no reason to have different version
> throughout the modules (again, not including GWT for obvious reasons),
> there is practically no harm I can think of in raising the version for
> all modules at once

I have updated the patch to raise the level in all the projects except
the ones that require Java 7 because of GWT:

  core: Use Java 8 as source and target
  https://gerrit.ovirt.org/46288

Please review.

> 
> On Tue, Oct 27, 2015 at 10:36 AM, Allon Mureinik <amure...@redhat.com
> <mailto:amure...@redhat.com>> wrote:
> 
> I think it's a really bad practice to have different modules in the
> same project with different language versions.
> 
> For GWT it seems to be required, but for the rest of the backend, I
> think we should have one patch that moves the entire project in one go.
> We can have the various maintainers ack it to show their consent.
> 
> On Mon, Oct 26, 2015 at 1:17 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 10/26/2015 12:05 PM, Martin Mucha wrote:
> > not strictly related question: are we going to raise language level 
> as well? So we can start using JDK8 features like lambdas etc?
> >
> > M.
> >
> 
> Shortly after merging that patch I'll merge another one to raise the
> language level in the RESTAPI:
> 
>   restapi: Use Java 8 as source and target
>   https://gerrit.ovirt.org/46288
> 
> Doing the same in other components is up to their maintainers. I
> think
> that should be done everywhere, except where the use of GWT doesn't
> allow to do it.
> 
> > - Original Message -
> >> Hello,
> >>
> >> As you probably know oVirt Engine 4 will use WildFly 10, and that
> >> requires Java 8. The version of WildFly that we currently use
> is 8.2.1,
> >> and it can work with both Java 7 and Java 8. In order to ease the
> >> transition I'm about to merge the following patch, that will
> require
> >> Java 8 during runtime:
> >>
> >>   core: Require Java 8 during runtime
> >>   https://gerrit.ovirt.org/46872
> >>
> >> The implication of this for you is that you must make sure
> that you have
> >> Java 8 installed in the machine where you run your the
> engine. Fedora 22
> >> only supports Java 8, so that isn't a problem. EL6 supports
> both Java 7
> >> and Java 8, so make sure that you have Java 8 installed:
> >>
> >>   yum -y install java-1.8.0-openjdk-devel
> >>
> >> If you have objections please speak now, otherwise I will
> merge the
> >> patch tomorrow.
> >>
> >> Regards,
> >> Juan Hernandez
> >>
> >> --
> >> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea
> 3, planta
> >> 3ºD, 28016 Madrid, Spain
> >> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 -
> Red Hat S.L.
> >> ___
> >> Devel mailing list
> >> Devel@ovirt.org <mailto:Devel@ovirt.org>
> >> http://lists.ovirt.org/mailman/listinfo/devel
> > ___
> > Devel mailing list
> > Devel@ovirt.org <mailto:Devel@ovirt.org>
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
> 
> 
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
> planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red
> Hat S.L.
> ___
> Devel mailing list
> Devel@ovirt.org <mailto:Devel@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org <mailto:Devel@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

[Juan Hernández]

On 10/27/2015 10:16 AM, Roman Mohr wrote:
> 
> 
> On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > Hi Juan,
> >
> > The way to specify the contract look pretty clean and nice.
> > I would love to read a few words about the big picture. What is the
> > final scenario?
> >
> 
> The motivation for this change is that currently we don't have a central
> place where the RESTAPI is specified, rather we have several different
> places, using several different technologies:
> 
> * XML schema for the data model.
> * JAX-RS for part of the operational model (without the parameters).
> * rsdl_metadata.yaml for the parameters of the operational model.
> 
> This makes it difficult to infer information about the model. For
> example, the generators of the SDKs have to download the XML schema, and
> the RSDL (which is generated from the JAX-RS interfaces using reflection
> and combining it with the information from the rsdl_metadata.yaml file)
> and then they have to do their own computations to extract what they
> need.
> 
> Same happens with the CLI: it has to extract the information it needs
> from the Python code generated for the Python SDK, yet another level of
> indirection.
> 
> 
> You are right, that definitely needs to be cleaned up. I just want to
> discuss a few points below with you.
>  
> 
> 
> We are also lacking a comprehensive reference documentation of the
> RESTAPI. What we currently have has been written by hand, and gets out
> of sync very quickly, and we don't even notice.
> 
> 
> Did you also consider swagger? It is made for exactly that purpose.
> I created a demo in [1] which uses resteasy, weld, hibernate-validator
> and swagger to demonstrate how to do DRY with jaxrs.
> Would be great to hear you thoughts on that.
> 
> And there is the great swagger-ui [8] to display the documentation in a
> more human readable way.
>  

Yes, I considered Swagger, and rejected it because it is JSON centric,
and I think JSON isn't as good as Java to represent the contracts of our
RESTAPI.

In addition we need to do these changes in a smooth way, without causing
big changes in the middle. For example, in the first step we need to
preserve the JAX-RS interfaces as they are today, to avoid massive
changes to all the resource implementations. This could be done with
Swagger, but would require custom code generators. With less effort we
can do our own.

Swagger UI is certainly great. I did test it and it is really good. We
may be able to copy some concepts.

> 
> 
> To solve these issues I intend to have the specification of the RESTAPI
> only in one place, and using only one technology. I decided to use Java
> interfaces for that. Note however that they are just the support for the
> information, like paper is the support for ink. I decided to use Java
> because it is easy to create, modify and re-factor using tools familiar
> to most of us.
> 
> These source of these interfaces is analysed (using QDox, currently) and
> a "model" of the RESTAPI is generated in memory. This model is
> independent of the supporting Java source, and easy to consume. For
> example, imagine that you want to list all the types available in the
> model and for each one display its documentation:
> 
>   Model model = ...;
>   for (Type type : model.getTypes()) {
> Name name = type.getName();
> String doc = type.getDoc();
> System.out.println(name + ": " + doc);
>   }
> 
> Something like this, but more elaborate, will be part of a web
> application that provides comprehensive reference documentation,
> assuming that we dedicate the time to write documentation comments in
> the specification.
> 
> I intend to use this model also to do simplify the generators of the
> SDKs and the CLI.
> 
> In addition these are some of the things that I would like to change in
> the near future (for 4.0):
> 
> * Move the specification of the parameters of operations out of the
> rsdl_metadata.yaml file and into the model. For example:
> 
>   @Service
>   public VmService {
> /**
>  * The operation to add a virtual machine.
>  */
> interface Add {
>   /**
>* The representation of the virtual machine is received
>* as parameter, and the representation of the created
>* virtual machine is returned as result.
>   

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

[Juan Hernández]

On 10/27/2015 01:59 PM, Martin Betak wrote:
> 
> 
> 
> 
> - Original Message -
>> From: "Juan Hernández" <jhern...@redhat.com>
>> To: "Roman Mohr" <rm...@redhat.com>
>> Cc: devel@ovirt.org
>> Sent: Tuesday, October 27, 2015 1:45:58 PM
>> Subject: Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel
>>
>> On 10/27/2015 12:55 PM, Roman Mohr wrote:
>>>
>>>
>>> On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández <jhern...@redhat.com
>>> <mailto:jhern...@redhat.com>> wrote:
>>>
>>> On 10/27/2015 11:28 AM, Roman Mohr wrote:
>>> >
>>> >
>>> > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández <jhern...@redhat.com
>>> > <mailto:jhern...@redhat.com>
>>>     > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>> wrote:
>>> >
>>> > On 10/27/2015 10:16 AM, Roman Mohr wrote:
>>> > >
>>> > >
>>> > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández
>>> > > <jhern...@redhat.com <mailto:jhern...@redhat.com>
>>> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
>>> > > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
>>> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>> wrote:
>>> > >
>>> > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
>>> > > > Hi Juan,
>>> > > >
>>> > > > The way to specify the contract look pretty clean and
>>> nice.
>>> > > > I would love to read a few words about the big
>>> picture. What
>>> > is the
>>> > > > final scenario?
>>> > > >
>>> > >
>>> > > The motivation for this change is that currently we
>>> don't have
>>> > a central
>>> > > place where the RESTAPI is specified, rather we have
>>> > > several
>>> > different
>>> > > places, using several different technologies:
>>> > >
>>> > > * XML schema for the data model.
>>> > > * JAX-RS for part of the operational model (without the
>>> > parameters).
>>> > > * rsdl_metadata.yaml for the parameters of the
>>> operational model.
>>> > >
>>> > > This makes it difficult to infer information about the
>>> model. For
>>> > > example, the generators of the SDKs have to download the
>>> > > XML
>>> > schema, and
>>> > > the RSDL (which is generated from the JAX-RS interfaces
>>> using
>>> > reflection
>>> > > and combining it with the information from the
>>> > rsdl_metadata.yaml file)
>>> > > and then they have to do their own computations to extract
>>> > what they
>>> > > need.
>>> > >
>>> > > Same happens with the CLI: it has to extract the
>>> > > information
>>> > it needs
>>> > > from the Python code generated for the Python SDK, yet
>>> another
>>> > level of
>>> > > indirection.
>>> > >
>>> > >
>>> > > You are right, that definitely needs to be cleaned up. I
>>> just want to
>>> > > discuss a few points below with you.
>>> > >
>>> > >
>>> > >
>>> > > We are also lacking a comprehensive reference
>>> documentation of the
>>> > > RESTAPI. What we currently have has been written by
>>> hand, and
>>> > gets out
>>> > > of sync very quickly, and we don't even notice.
>>> > >
>>> > >
>>> > > Did you also consider swagger? It is made for exactly that
>>> purpose.
>>>   

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

[Juan Hernández]

On 10/27/2015 11:28 AM, Roman Mohr wrote:
> 
> 
> On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 10/27/2015 10:16 AM, Roman Mohr wrote:
> >
> >
> > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández <jhern...@redhat.com 
> <mailto:jhern...@redhat.com>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>> wrote:
> >
> > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > Hi Juan,
> > >
> > > The way to specify the contract look pretty clean and nice.
> > > I would love to read a few words about the big picture. What
> is the
> > > final scenario?
> > >
> >
> > The motivation for this change is that currently we don't have
> a central
> > place where the RESTAPI is specified, rather we have several
> different
> > places, using several different technologies:
> >
> > * XML schema for the data model.
> > * JAX-RS for part of the operational model (without the
> parameters).
> > * rsdl_metadata.yaml for the parameters of the operational model.
> >
> > This makes it difficult to infer information about the model. For
> > example, the generators of the SDKs have to download the XML
> schema, and
> > the RSDL (which is generated from the JAX-RS interfaces using
> reflection
> > and combining it with the information from the
> rsdl_metadata.yaml file)
> > and then they have to do their own computations to extract
> what they
> > need.
> >
> > Same happens with the CLI: it has to extract the information
> it needs
> > from the Python code generated for the Python SDK, yet another
> level of
> > indirection.
> >
> >
> > You are right, that definitely needs to be cleaned up. I just want to
> > discuss a few points below with you.
> >
> >
> >
> > We are also lacking a comprehensive reference documentation of the
> > RESTAPI. What we currently have has been written by hand, and
> gets out
> > of sync very quickly, and we don't even notice.
> >
> >
> > Did you also consider swagger? It is made for exactly that purpose.
> > I created a demo in [1] which uses resteasy, weld, hibernate-validator
> > and swagger to demonstrate how to do DRY with jaxrs.
> > Would be great to hear you thoughts on that.
> >
> > And there is the great swagger-ui [8] to display the documentation
> in a
> > more human readable way.
> >
> 
> Yes, I considered Swagger, and rejected it because it is JSON centric,
> and I think JSON isn't as good as Java to represent the contracts of our
> RESTAPI.
> 
> 
> You just write plain jax-rs, swagger just creates a description out of
> it. So  the source defining the contract is pure java (jax-rs with some
> swagger annotations for description, etc.).
> Or am I missing the point here?
>  

If I understand correctly the Swagger core is a JSON (or YAML)
specification of the API. From that you can generate JAX-RS annotated
code, not the other way around. So the specification document that you
write is a JSON document.

Alternatively, you can use the Swagger annotations to decorate your
implementation, both the entity classes and the JAX-RS resource
implementations, and then extract the model from that. But this is
putting the implementation before the specification. That is where we
are today, and it causes multiple problems. I think it is better to have
the specification and the implementation separate. Swagger does that
well when using JSON directly, our metamodel also does it well, but
using a better language.

> 
> 
> In addition we need to do these changes in a smooth way, without causing
> big changes in the middle. For example, in the first step we need to
> preserve the JAX-RS interfaces as they are today, to avoid massive
> changes to all the resource implementations. This could be done with
> 
> Swagger, but would require custom code generators. With less effort we
> can do our own.
> 
> 
> This is of course generally a difficult task. But I do not know why it
> would be more difficult to write a custom swagger reader (if we even
> have to, it can read the interfaces as well) .
> They are pretty streight forward. Just look at [9], this contains the
> w

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

[Juan Hernández]

On 10/27/2015 03:05 PM, Roman Mohr wrote:
> 
> 
> On Tue, Oct 27, 2015 at 2:41 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 10/27/2015 02:10 PM, Roman Mohr wrote:
> >
> >
> > On Tue, Oct 27, 2015 at 1:45 PM, Juan Hernández <jhern...@redhat.com 
> <mailto:jhern...@redhat.com>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>> wrote:
> >
> > On 10/27/2015 12:55 PM, Roman Mohr wrote:
> > >
> > >
> > > On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández 
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>> wrote:
> > >
> > > On 10/27/2015 11:28 AM, Roman Mohr wrote:
> > > >
> > > >
> > > > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández 
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>
> > > > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>>> wrote:
> > > >
> > > > On 10/27/2015 10:16 AM, Roman Mohr wrote:
> > > > >
> > > > >
> > > > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández 
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>
> > > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>>
> > > > > <mailto:jhern...@redhat.com 
> <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>
> > > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>>>> wrote:
> > > > >
> > > > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > > > > Hi Juan,
> > > > > >
> > > > > > The way to specify the contract look pretty
> > clean and
> > > nice.
> > > > > > I would love to read a few words about the big
> > > picture. What
> > > > is the
> > > > > > final scenario?
> > > > > >
> > > > >
> > > > > The motivation for this change is that
> currently we
> > > don't have
> > > > a central
> > > > > place where the RESTAPI is specified, rather we
> > have several
> > > > different
> > > > > places, using several different technologies:
> > > > >
> > > > > * XML schema for the data model.
> > > > > * JAX-RS for part of the operational model
> > (without the
>   

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

[Juan Hernández]

On 10/27/2015 02:10 PM, Roman Mohr wrote:
> 
> 
> On Tue, Oct 27, 2015 at 1:45 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> On 10/27/2015 12:55 PM, Roman Mohr wrote:
> >
> >
> > On Tue, Oct 27, 2015 at 12:16 PM, Juan Hernández <jhern...@redhat.com 
> <mailto:jhern...@redhat.com>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>> wrote:
> >
> > On 10/27/2015 11:28 AM, Roman Mohr wrote:
> > >
> > >
> > > On Tue, Oct 27, 2015 at 10:47 AM, Juan Hernández 
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>> wrote:
> > >
> > > On 10/27/2015 10:16 AM, Roman Mohr wrote:
> > > >
> > > >
> > > > On Mon, Oct 26, 2015 at 5:32 PM, Juan Hernández 
> <jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>
> > > > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>
> > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>
> <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>>>> wrote:
> > > >
> > > > On 10/26/2015 04:56 PM, Roman Mohr wrote:
> > > > > Hi Juan,
> > > > >
> > > > > The way to specify the contract look pretty
> clean and
> > nice.
> > > > > I would love to read a few words about the big
> > picture. What
> > > is the
> > > > > final scenario?
> > > > >
> > > >
> > > > The motivation for this change is that currently we
> > don't have
> > > a central
> > > > place where the RESTAPI is specified, rather we
> have several
> > > different
> > > > places, using several different technologies:
> > > >
> > > > * XML schema for the data model.
> > > > * JAX-RS for part of the operational model
> (without the
> > > parameters).
> > > > * rsdl_metadata.yaml for the parameters of the
> > operational model.
> > > >
> > > > This makes it difficult to infer information about the
> > model. For
> > > > example, the generators of the SDKs have to
> download the XML
> > > schema, and
> > > > the RSDL (which is generated from the JAX-RS
> interfaces
> > using
> > > reflection
> > > > and combining it with the information from the
> > > rsdl_metadata.yaml file)
> > > > and then they have to do their own computations to
> extract
> > > what they
> > > > need.
> > > >
> > > > Same happens with the CLI: it has to extract the
> information
> > > it needs
> > > > from the Python code generated for the Python SDK, yet
> > another
> > > level of
> > > > indirection.
> > > >
> > > >
> > > > You are right, that definitely needs to be cleaned up. I
> > just want to
> > > > discuss a few points below with you.
> > > >
> > > >
> > > >
> > > > We are also lacking a comprehensive reference
> > documentation of the
> > > > RESTAPI. What we currently have has been written by
> >  

[ovirt-devel] Requiring Java 8 during runtime

[Juan Hernández]

Hello,

As you probably know oVirt Engine 4 will use WildFly 10, and that
requires Java 8. The version of WildFly that we currently use is 8.2.1,
and it can work with both Java 7 and Java 8. In order to ease the
transition I'm about to merge the following patch, that will require
Java 8 during runtime:

  core: Require Java 8 during runtime
  https://gerrit.ovirt.org/46872

The implication of this for you is that you must make sure that you have
Java 8 installed in the machine where you run your the engine. Fedora 22
only supports Java 8, so that isn't a problem. EL6 supports both Java 7
and Java 8, so make sure that you have Java 8 installed:

  yum -y install java-1.8.0-openjdk-devel

If you have objections please speak now, otherwise I will merge the
patch tomorrow.

Regards,
Juan Hernandez

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Requiring Java 8 during runtime

[Juan Hernández]

On 10/26/2015 12:05 PM, Martin Mucha wrote:
> not strictly related question: are we going to raise language level as well? 
> So we can start using JDK8 features like lambdas etc?
> 
> M.
> 

Shortly after merging that patch I'll merge another one to raise the
language level in the RESTAPI:

  restapi: Use Java 8 as source and target
  https://gerrit.ovirt.org/46288

Doing the same in other components is up to their maintainers. I think
that should be done everywhere, except where the use of GWT doesn't
allow to do it.

> - Original Message -
>> Hello,
>>
>> As you probably know oVirt Engine 4 will use WildFly 10, and that
>> requires Java 8. The version of WildFly that we currently use is 8.2.1,
>> and it can work with both Java 7 and Java 8. In order to ease the
>> transition I'm about to merge the following patch, that will require
>> Java 8 during runtime:
>>
>>   core: Require Java 8 during runtime
>>   https://gerrit.ovirt.org/46872
>>
>> The implication of this for you is that you must make sure that you have
>> Java 8 installed in the machine where you run your the engine. Fedora 22
>> only supports Java 8, so that isn't a problem. EL6 supports both Java 7
>> and Java 8, so make sure that you have Java 8 installed:
>>
>>   yum -y install java-1.8.0-openjdk-devel
>>
>> If you have objections please speak now, otherwise I will merge the
>> patch tomorrow.
>>
>> Regards,
>> Juan Hernandez
>>
>> --
>> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
>> 3ºD, 28016 Madrid, Spain
>> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
>> ___
>> 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
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [ATN] Introduction of RESTAPI metamodel

[Juan Hernández]

Hello,

I will soon merge the following patches that introduce a new way to
specify the contracts of the RESTAPI:

  restapi: Introduce metamodel
  https://gerrit.ovirt.org/45852

  restapi: Use metamodel
  https://gerrit.ovirt.org/46478

  restapi: Generate JAX-RS interfaces from model
  https://gerrit.ovirt.org/47337

These patches introduce a new "metamodel" concept, and move the current
specification of the RESTAPI based on XML schema and JAX-RS interfaces
to a new "model" built on the new metamodel.

What does this mean for you in practical terms? Currently when you want
to introduce or modify one of the data types used by the RESTAPI you
start by modifying the XML schema. Once the patches are merged the XML
schema will never be touched, as it will be automatically generated from
the "model". For example, imagine that you need to add a new "color"
attribute to the "VM" entity. To do so with the new model you will have
to modify the following file, which is the specification of the "Vm"
entity, written as a Java interface:


https://gerrit.ovirt.org/#/c/46478/16/backend/manager/modules/restapi/model/src/main/java/types/Vm.java

In that interface you will have to add a line like this:

  String color();

Note that this Java interface is just the specification of the entity,
it won't be used at all during runtime. Instead of that the XML schema
will be generated from it, and then Java will be generated from the XML
schema, as we do today (this will change in the future, but not yet).

Same for the services. If you want to add a new "paint" action to the
"Vm" resource then you won't modify the JAX-RS interfaces, instead of
that you will modify the following file, which is the specification of
the "Vm" service, written as a Java interface:


https://gerrit.ovirt.org/#/c/47337/6/backend/manager/modules/restapi/model/src/main/java/services/VmService.java

In that interface you will need to add a sub-interface representing the
action:

  interface Paint {
  }

The JAX-RS interface will be generated from that. Currently these
sub-interfaces are empty. In the future they will contain the
specifications of the parameters (currently in the rsdl_metadata.yml file).

These changes will currently affect only the specification of the
RESTAPI, not the implementation, so in in the "Backend*Resource" classes
things won't change yet.

If you have doubts, please let me know.

Regards,
Juan Hernandez

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ATN] Introduction of RESTAPI metamodel

[Juan Hernández]

On 10/26/2015 04:56 PM, Roman Mohr wrote:
> Hi Juan,
> 
> The way to specify the contract look pretty clean and nice.
> I would love to read a few words about the big picture. What is the
> final scenario?
> 

The motivation for this change is that currently we don't have a central
place where the RESTAPI is specified, rather we have several different
places, using several different technologies:

* XML schema for the data model.
* JAX-RS for part of the operational model (without the parameters).
* rsdl_metadata.yaml for the parameters of the operational model.

This makes it difficult to infer information about the model. For
example, the generators of the SDKs have to download the XML schema, and
the RSDL (which is generated from the JAX-RS interfaces using reflection
and combining it with the information from the rsdl_metadata.yaml file)
and then they have to do their own computations to extract what they need.

Same happens with the CLI: it has to extract the information it needs
from the Python code generated for the Python SDK, yet another level of
indirection.

We are also lacking a comprehensive reference documentation of the
RESTAPI. What we currently have has been written by hand, and gets out
of sync very quickly, and we don't even notice.

To solve these issues I intend to have the specification of the RESTAPI
only in one place, and using only one technology. I decided to use Java
interfaces for that. Note however that they are just the support for the
information, like paper is the support for ink. I decided to use Java
because it is easy to create, modify and re-factor using tools familiar
to most of us.

These source of these interfaces is analysed (using QDox, currently) and
a "model" of the RESTAPI is generated in memory. This model is
independent of the supporting Java source, and easy to consume. For
example, imagine that you want to list all the types available in the
model and for each one display its documentation:

  Model model = ...;
  for (Type type : model.getTypes()) {
Name name = type.getName();
String doc = type.getDoc();
System.out.println(name + ": " + doc);
  }

Something like this, but more elaborate, will be part of a web
application that provides comprehensive reference documentation,
assuming that we dedicate the time to write documentation comments in
the specification.

I intend to use this model also to do simplify the generators of the
SDKs and the CLI.

In addition these are some of the things that I would like to change in
the near future (for 4.0):

* Move the specification of the parameters of operations out of the
rsdl_metadata.yaml file and into the model. For example:

  @Service
  public VmService {
/**
 * The operation to add a virtual machine.
 */
interface Add {
  /**
   * The representation of the virtual machine is received
   * as parameter, and the representation of the created
   * virtual machine is returned as result.
   */
   @In @Out Vm vm();

   /**
* In the future, we will be able to specify other
* parameters here.
*/
   @In Boolean force();

   /**
* Even with default values.
*/
   @In default Boolean force() { return true; }

   /**
* And we will be able to specify constraints, which
* will replace the rsdl_metadata.yaml file.
*/
   @Constraint
   default boolean vmNameMustNotBeNull() {
 return vm().name() != null;
   }
 }
  }

* Enforce the constraints automatically. If the constraints are in the
model, then we can just check them and reject requests before delivering
them to the application. Currently we do this manually (and often
forget) with calls to "validate(...)" methods.

* Generate the Java classes directly from the model. Instead of Model ->
XML Schema -> Java, we can do Model -> Java. This will allow us to solve
some of the XJC compiler limitations, like the horrible way we handle
arrays today.

* Replace JAX-RS with a simpler infrastructure that supports better
streaming and CDI injection.

* Add support for multiple versions of the API, using the "Version"
header, and generating different Java classes for entities and services.
For example, if we have versions 4 and 5 of the model as separate
artifacts, then we can generate "V4Vm" and "V5Vm" entity classes, and
"V4VmService" and "V5VmService" service classes. These can be used
simultaneously in the server, so we can have in the same engine
implementations for multiple versions.

The final picture isn't completely defined yet.

Regards,
Juan Hernandez

> On Mon, Oct 26, 2015 at 4:03 PM, Juan Hernández <jhern...@redhat.com
> <mailto:jhern...@redhat.com>> wrote:
> 
> Hello,
> 
> I will soon merge the following patches that introduce a new way to
> specify the contracts of

Re: [ovirt-devel] Dependencies not packaged on Fedora

[Juan Hernández]

On 09/30/2015 12:20 PM, Sandro Bonazzola wrote:
> Hi,
> The following dependencies are not available in Fedora 22 as RPM package
> and are bundled within ovirt-engine:
> 
> BuildRequires:mvn(org.springframework:spring-asm) >= 3.1.1
> ^^^ *Bug 1191592*
>  - drop spring-asm
> dependency
> 
> these are known to be hard to package:
> BuildRequires:mvn(com.google.gwt.inject:gin) >= 2.1.2
> BuildRequires:mvn(com.google.gwt:gwt-dev)
> BuildRequires:mvn(com.google.gwt:gwt-servlet)
> BuildRequires:mvn(com.google.gwt:gwt-user)
> BuildRequires:mvn(com.gwtplatform:gwtp-mvp-client) >= 1.3.1
> BuildRequires:mvn(com.gwtplatform:gwtp-processors) >= 1.3.1
> BuildRequires:mvn(org.gwtbootstrap3:gwtbootstrap3) >= 0.8.1
> BuildRequires:mvn(org.gwtbootstrap3:gwtbootstrap3-extras) >= 0.8.1
> 
> 
> Can we do something about the following?
> BuildRequires:mvn(com.sun.xml.bind:jaxb-core) >= 2.2.7

This is dependency is in the "test" scope, it is only needed to run the
tests, not even to compile them. As you won't probably be running tests
as part of the RPM build (using the "-f" option of "%mvn_build") in
Fedora 22 you can just remove the dependency:

  %pom_remove_dep -r com.sun.xml.bind:jaxb-core

If you will be running tests then you can try to replace it with the
equivalent artifact supplied by Fedora 22:

  %pom_change_dep -r com.sun.xml.bind:jaxb-core org.glassfish.jaxb:jaxb-core

However tests may not work correctly with this change.

It looks like that list of dependencies was automatically generated by
Xmvn, so disabling the tests may not be enough. In that case you will
need to use a patch (Patch: ..., %patch0, etc) to remove all references
to this dependency.

> BuildRequires:mvn(org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1)
>>= 1.0.0.CR8

This is also a test dependency, and can be removed like the previous one.

> BuildRequires:mvn(org.jboss.as:jboss-as-domain-management) >= 7.2.0

This is required by the JBoss plugin that delegates authentication to
the management interface of JBoss to our own authentication system. I
think that the only way to remove this is a patch.

> BuildRequires:mvn(org.jboss.spec:jboss-javaee-6.0)
> 

This is a requirement of arquillian. It should be in the "test" scope,
and then you can remove it like the previous ones.

> Thanks,
> -- 
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com 
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ACTION REQUIRED] 3.5.5 - Find Bugs detected possibly ignored exception

[Juan Hernández]

On 09/14/2015 05:06 PM, Sandro Bonazzola wrote:
> http://jenkins.ovirt.org/job/ovirt-engine_3.5_find-bugs_merged/1391/findbugsResult/new/
> 
> BackendApiResource.java:264
> ,
> DE_MIGHT_IGNORE, Priority: Low
> 
> *org.ovirt.engine.api.restapi.resource.BackendApiResource.getSchema()
> might ignore java.io.IOException*
> 
> This method might ignore an exception.  In general, exceptions should be
> handled or reported in some way, or they should be thrown out of the method.
> 
> 
> 
> Please review / fix ASAP since 3.5.5 RC1 build is scheduled for Sep 16th.
> 

This is harmless, however, if we want to fix it we need this patch:

  rest: Catch IOExcetpion BackendApiResource
  https://gerrit.ovirt.org/46131

It is already merged in the master and 3.6 branches.

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] error starting engine on wildfly 8.2 fedora 22

[Juan Hernández]

On 06/24/2015 07:40 PM, Greg Sheremeta wrote:
 Hey,
 
 Can't seem to get engine started. Any ideas? Did I miss a step?
 
 I'm on latest master (4dd3093d42fd2c5826c941b7e19176a0e657a43f). Fresh engine 
 directory,
 fresh database. Fedora 22.
 

You need to make sure that the ovirt-engine-wildfly-overly contents
are put on the front of the module path of the application server. There
is a detailed explanation here:

http://lists.ovirt.org/pipermail/devel/2015-June/010832.html

 
 greg@dauntless:~/projects/ovirt-engine(master2|✔) % ovirt_run
 OpenJDK 64-Bit Server VM warning: ignoring option PermSize=256m; support was 
 removed in 8.0
 OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support 
 was removed in 8.0
 Listening for transport dt_socket at address: 8787
 
 
 
 
 
 
 2015-06-24 13:31:01,719 ERROR [org.jboss.msc.service.fail] (MSC service 
 thread 1-5) MSC01: Failed to start service jboss.deploym
 ent.unit.engine.ear.WeldStartService: org.jboss.msc.service.StartException 
 in service jboss.deployment.unit.engine.ear.WeldStart
 Service: Failed to start service
 at 
 org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
  [jboss-msc-1.2.2.Final.jar:1.2
 .2.Final]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
  [rt.jar:1.8.0_45]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  [rt.jar:1.8.0_45]
 at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_45]
 Caused by: org.jboss.weld.exceptions.DefinitionException: 0
 at 
 org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:182)
 at 
 org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:166)
 at 
 org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:158)
 at 
 org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:230)
 at 
 org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:373)
 at 
 org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
 at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:91)
 at 
 org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
  [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
 at 
 org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
  [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
 ... 3 more
 Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
 at 
 org.hibernate.validator.internal.util.ExecutableHelper.instanceMethodParametersResolveToSameTypes(ExecutableHelper.java:141)
 at 
 org.hibernate.validator.internal.util.ExecutableHelper.overrides(ExecutableHelper.java:101)
 at 
 org.hibernate.validator.internal.cdi.ValidationExtension.replaceWithOverriddenOrInterfaceMethod(ValidationExtension.java:425)
 at 
 org.hibernate.validator.internal.cdi.ValidationExtension.determineConstrainedMethod(ValidationExtension.java:275)
 at 
 org.hibernate.validator.internal.cdi.ValidationExtension.determineConstrainedCallables(ValidationExtension.java:262)
 at 
 org.hibernate.validator.internal.cdi.ValidationExtension.processAnnotatedType(ValidationExtension.java:242)
 at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source) 
 [:1.8.0_45]
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  [rt.jar:1.8.0_45]
 at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_45]
 at 
 org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
 at 
 org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
 at 
 org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
 at 
 org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
 at 
 org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
 at 
 org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:174)
 at 
 org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:133)
 at 
 org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:112)
 at 
 org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:180)
 ... 11 more
 
 2015-06-24 13:31:01,729 ERROR [org.jboss.as.controller.management-operation] 
 (Controller Boot Thread) JBAS014613: Operation (deploy) failed - address: 
 ([(deployment = engine.ear)]) - failure description: {JBAS014671: 
 Failed services = 

Re: [ovirt-devel] Select storage domain when creating VM from template with python-SDK

[Juan Hernández]

On 06/09/2015 05:41 PM, Philip Strömbäck wrote:
 Hi,
 
 I have a question about python-SDK for Ovirt Engine API. When creating a
 new VM from a template in Clone/Independent-mode, I'm not unable to
 select storage domain for the new disk. It seems like it always get
 created on the same disk at the template. I can move the disk after
 creation but it's a little bit time consuming.
 
 Example:
 
 vm_params = params.VM ( name = vm_name, cluster = api.clusters.get (
 Cluster-1 ), template = api.templates.get ( RHEL7 ), storage_domain
 = api.storagedomains.get ( iscsi1 ), disks = params.Disks ( clone =
 True ) )
 
 try:
api.vms.add ( vm_params )
 except Exception, e:
raise SystemExit ( Could not create VM from template: %s % (  e ) )
 
 The VM is added correctly but the disk is located on iscsi0 ( the same
 as the template ). 
 
 Have anybody an idea how to get this sorted out? 
 
 Best regards, 
 Philip
 

To do this you need to specify the target storage domain for each of the
disks of the template that you want in an different storage domain. In
plain XML that would look like this:

  POST /vms
  vm
namemynewvm/name
cluster
  namemycluster/name
/cluster
template
  namemytemplate/name
/template
disks
  clonetrue/clone
  disk id=the-id-of-the-disk-of-the-template
storage_domains
  storage_domain id=the-id-of-the-target-storage-domain/
/storage_domains
  /disk
/disks
  /vm

To do the same with the Python SDK you need something like this:

  api.vms.add(
params.VM(
  name=mynewvm,
  template=params.Template(
name=mytemplate
  ),
  cluster=params.Cluster(
name=mycluster
  ),
  disks=params.Disks(
clone=True,
disk=[
  params.Disk(
id=the-id-of-the-disk-of-the-template,
storage_domains=params.StorageDomains(
  storage_domain=[
params.StorageDomain(
  id=the-id-of-the-storage-domain
)
  ]
)
  )
]
  )
)
  )


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Engine rpm build fails

[Juan Hernández]

On 06/01/2015 04:12 PM, Tolik Litvosky wrote:
 Hi 
 Can someone hit the submit button on it ? 
 I see +1 in code review.
 
 We need the engine being build.
 Delay a bunch of other work :-(
 
 Tolik.

It is merged now.

 On Mon, 2015-06-01 at 09:04 -0400, Martin Perina wrote:
 Hi,

 here's patch [1] that fixes below mentioned issue. But the
 issue was introduced in different patch [2].

 Martin


 [1] https://gerrit.ovirt.org/41788
 [2] https://gerrit.ovirt.org/41035

 - Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: tlito...@redhat.com
 Cc: devel@ovirt.org
 Sent: Monday, June 1, 2015 2:18:10 PM
 Subject: Re: [ovirt-devel] Engine rpm build fails



 - Original Message -
 From: Tolik Litvosky tlito...@redhat.com
 To: devel@ovirt.org
 Cc: Vojtech Szocs vsz...@redhat.com
 Sent: Monday, June 1, 2015 10:58:16 AM
 Subject: Engine rpm build fails

 Hi

 The jenkins fails to build it RPM packages
 http://jenkins.ovirt.org/job/ovirt-engine_master_create
 -rpms_merged/label=el7/3536/
 The probable cause is:
 https://gerrit.ovirt.org/#/c/41405/

 That ^^ patch just fixes a couple of FindBugs warnings.

 From build log:

 21:07:26 __main__.PackagingTypeMissingFile: Packaging type is not 
 'pom' and
 no artifact path has been provided for POM
 /home/jenkins/workspace/ovirt-engine_master_create
 -rpms_merged/label/el7/rpmbuild/BUILDROOT/ovirt-engine-3.6.0
 -0.0.master.20150529172310.gitf9a7fe2.el7.centos.x86_64/usr/share/m
 aven-poms/JPP.ovirt-engine-scheduler.pom
 21:07:26 error: Bad exit status from /var/tmp/rpm-tmp.hkKcGG 
 (%install)
 21:07:26
 21:07:26
 21:07:26 RPM build errors:
 21:07:26 Bad exit status from /var/tmp/rpm-tmp.hkKcGG 
 (%install)


 Can you please assist on fixing this.

 --
 Best regards
 Tolik Litovsky
 RHEV-H Team
 Red Hat

 Red Hat: trustworthy, transformative technology. Powered by the
 community.
 Connect at redhat.com

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



-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] REST api and template creation

[Juan Hernández]

On 05/09/2015 09:08 AM, Christopher Pereira wrote:
 Template creation is failing, because Engine is not receiving the alias
 which apparently is required since 3.5.
 This is the XML sent to engine. Alias is there.
 API bug?
 

Yes, this is a bug in the API. It is fixed already in 3.6:

  SDK and REST ignore template's disk attributes
  https://bugzilla.redhat.com/1110798

It didn't happen before 3.5 because the backend didn't check the content
of the alias. That changed in 3.5 as part of the fix for a different bug:

  Create template from vm with empty disk alias should block with
canDoAction
  https://bugzilla.redhat.com/1110304

As far as I know there is no workaround, so you will have to wait for a
release containing the fix. Currently it is targeted for 3.6, but we
could retarget for 3.5.

Allon, Amit, can we retarget bug 1110798 to the next 3.5.z?

 template
 nameUDSP_ovirt-22/name
 descriptionUDS pub for ovirt at 2015-05-09 08:36:58/description
 vm id=3774dcd0-9e1a-47af-9560-fde85f46bfa1
 disks
 disk id=f96b3718-3ccf-42f4-8537-e20dc5dd7bc3
 nametest/name
 *aliastest/alias *
 storage_domains
 storage_domain
 id=07326302-2c80-4d55-a7a2-ea79c55855e3/
 /storage_domains
 /disk
 /disks
 /vm
 cluster id=0001-0001-0001-0001-019d/
 /template
 
 On 09-05-2015 3:34, Adolfo wrote:
 Hello all,

 My name is Adolfo, i'm in charge of developing of UDS (you can see
 something about it on ovirt home page, the case study
 http://www.ovirt.org/Universidad_de_Sevilla_Case_Study. ).

 Recently (a couple of days ago), i started to test UDS against ovirt
 3.5, and sudenlty Template creation as was supported previously does
 not works. :(

 The idea is allow to create the template in the storage that the
 administrator of UDS selects.

 The process is simple and was working perfectly before to 3.5 release
 (on 3.4, 3.3, 3.2 as long as i can remember). After getting all the
 data we need, we do the following (code follows):

 vm is the origin vm:

 # Create disks description to be created in specified
 storage domain, one for each disk
 sd =
 params.StorageDomains(storage_domain=[params.StorageDomain(id=storageId)])

 dsks = []
 for dsk in vm.disks.list():
 dks.append(params.Disk(id=dsk.get_id(),
 storage_domains=sd, name='test', alias='test'))

 disks = params.Disks(disk=dsks)

 template = params.Template(
 name=name,
 vm=params.VM(id=vm.get_id(), disks=disks),
 cluster=params.Cluster(id=cluster.get_id()),
 description=comments
 )

 return api.templates.add(template).get_id()

 This is the debug output of the request:

 POST /api/templates HTTP/1.1
 Host: ovirt.dkmon.com
 Accept-Encoding: identity
 Content-Length: 2656
 Filter: False
 cookie: JSESSIONID=2Ihu3uUWFhvl2xbsi5i7yBip.undefined
 Prefer: persistent-auth
 Content-type: application/xml
 Accept: application/xml

 template
 nameUDSP_ovirt-21/name
 descriptionUDS pub for ovirt at 2015-05-09 08:27:06/description
 vm id=3774dcd0-9e1a-47af-9560-fde85f46bfa1
 disks
 disk
 href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3
 id=f96b3718-3ccf-42f4-8537-e20dc5dd7bc3
 actions
 link
 href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/deactivate
 rel=deactivate/
 link
 href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/activate
 rel=activate/
 link
 href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/export
 rel=export/
 link
 href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/move
 rel=move/
 /actions
 nameno-os_Dsk1/name
 descriptionSmall empty disk/description
 link
 href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/permissions
 rel=permissions/
 link
 href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/statistics
 rel=statistics/
 vm
 href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1
 id=3774dcd0-9e1a-47af-9560-fde85f46bfa1/
 aliasno-os_Dsk1/alias
 image_ida79f7fe7-bcae-4cc3-8b11-d60702a46147/image_id
 storage_domains
 storage_domain
 id=a893809b-2ba9-4910-a7f3-9bfdde2efbb8/
 /storage_domains
 size1073741824/size
 provisioned_size1073741824/provisioned_size
 actual_size0/actual_size
 status
 

Re: [ovirt-devel] VM Parameters in REST API for Vm Pools

[Juan Hernández]

On 03/12/2015 12:52 PM, Omer Frenkel wrote:
 
 
 - Original Message -
 From: Juan Hernández jhern...@redhat.com
 To: Shmuel Melamud smela...@redhat.com, devel@ovirt.org
 Sent: Wednesday, March 11, 2015 7:14:19 PM
 Subject: Re: [ovirt-devel] VM Parameters in REST API for Vm Pools

 On 03/11/2015 05:47 PM, Shmuel Melamud wrote:
 Hi!

 I'm currently working on adding VM parameters to VmPool collection in REST
 API. This will make possible to configure VMs on per pool basics like in
 the UI.

 The proposal is here:
 http://www.ovirt.org/Features/Vm_Parameters_in_REST_API_for_Vm_Pools

 Do anybody have any comments/suggestions?


 In your proposal you suggest to reuse the template element that
 appears inside the vmpool element. That template element is
 currently used as a link to the template that the pool is based on. If
 you add attributes to it it will look like they are attributes of the
 template itself, but still the link will point to the original template.
 For example:

   GET /vmpools/mypool
   vmpool ...
 ...
 template id=mytemplate href=/templates/mytemplate
   typedesktop/type  -- This is the type of the pool, not of the
 template
 /template
   /vmpool

   GET /templates/mytemplate
   template ...
 typeserver/type -- This is the type of the template, not of the
 pool
 ...
   /template

 This difference may be confusing, at least.

 Also, users tend to take a resource representation from one URI and pass
 it to another URL (specially if using the Python or Java SDKs), for example:

   template = api.templates.get(name=mytemplate)
   api.vmpools.add(
 VMPool(
   template=mytemplate
 )
   )

 This would result in unexpectedly overriding all the properties of the
 pool with those of the template, so later changes to the template itself
 won't be reflected in the pool.

 To avoid these two issues I'd suggest to not use the existing template
 element, but add to the vmpool element all the required attributes:

   POST /vmpools
   vmpool
 typedesktop/type
 display.../display
 ...
   /vmpool

 
 what about embedding vm inside the pool?
 then it will have also template inside, and also correlate to the real 
 implementation of the pool in the backend
 

That doesn't have any of the two adverse effects that I described, so
looks good.

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] VM Parameters in REST API for Vm Pools

[Juan Hernández]

On 03/11/2015 05:47 PM, Shmuel Melamud wrote:
 Hi!
 
 I'm currently working on adding VM parameters to VmPool collection in REST 
 API. This will make possible to configure VMs on per pool basics like in the 
 UI.
 
 The proposal is here: 
 http://www.ovirt.org/Features/Vm_Parameters_in_REST_API_for_Vm_Pools
 
 Do anybody have any comments/suggestions?
 

In your proposal you suggest to reuse the template element that
appears inside the vmpool element. That template element is
currently used as a link to the template that the pool is based on. If
you add attributes to it it will look like they are attributes of the
template itself, but still the link will point to the original template.
For example:

  GET /vmpools/mypool
  vmpool ...
...
template id=mytemplate href=/templates/mytemplate
  typedesktop/type  -- This is the type of the pool, not of the
template
/template
  /vmpool

  GET /templates/mytemplate
  template ...
typeserver/type -- This is the type of the template, not of the
pool
...
  /template

This difference may be confusing, at least.

Also, users tend to take a resource representation from one URI and pass
it to another URL (specially if using the Python or Java SDKs), for example:

  template = api.templates.get(name=mytemplate)
  api.vmpools.add(
VMPool(
  template=mytemplate
)
  )

This would result in unexpectedly overriding all the properties of the
pool with those of the template, so later changes to the template itself
won't be reflected in the pool.

To avoid these two issues I'd suggest to not use the existing template
element, but add to the vmpool element all the required attributes:

  POST /vmpools
  vmpool
typedesktop/type
display.../display
...
  /vmpool

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Issues with the VM display type value(s)

[Juan Hernández]

On 02/18/2015 11:10 PM, Einav Cohen wrote:
 Hi, 
 
 This is about the changes introduced by patch 
 http://gerrit.ovirt.org/#/c/35281 (restapi: adjust api to new 
 graphics representation). 
 
 There are a couple of issues with the VM's display type value:
 
 (1) the display - type value of the VM in the REST API seem to 
 map to different properties based on the VM status. 
 see http://i.imgur.com/Mn1RITW.png: 
 When the VM is Up, the display - type value in the REST API 
 matches the 'Display' value in the GUI. 
 But when the VM is Down, the display - type value in the REST 
 API matches the 'Graphics Protocol' value in the GUI and does not 
 necessarily match the 'Display' value (e.g. in case we invoked 
 'Run Once' on the VM with a different Console value). 
 
 Is there a reason for the values in the REST API to not match the 
 ones in the GUI? it's a bit confusing. 
 Maybe need to have two properties in the REST API to match the two 
 displayed values in the GUI: 'Display' (which, IIUC, is the 'run-
 time' value) and 'Graphics Protocol' (which, IIUC, is the 
 'configured'/persisted value)? 
 I understand that there may be backward-compatibility issues with 
 naming/terminology, but perhaps we can come up with a solution that 
 will not break the backward compatibility?
 

This behavior wasn't introduced by that patch, rather the patch was
carefully crafted to preserve it, for backwards compatibility.

My understanding is that the virt team plans to do larger changes to
this area of the RESTAPI to reflect the new separation of the video
device and graphics device concepts. I think that your concerns can
be handled in the context of those larger changes.

 (2) in patch http://gerrit.ovirt.org/#/c/35281, it seems that the 
 REST API is calling a query *per VM* in order to re-populate the 
 display-related values. 
 This will potentially overload the engine, especially if we are 
 planning to move the GUI to work over the REST API and request 
 VMs every 5 seconds (by default) per client, as we are doing today. 
 
 Are there any plans to optimize this behavior (e.g. populate the 
 correct display-related values on the db-side, rather than re-
 populating them on the REST-API side using a per-VM query)?
 

Currently there are no plans to change this because the backend doesn't
have a mechanism to provide all the related display information using
only one query. I'd suggest to implement at least a query that takes
multiple VM identifiers and returns the graphics devices of those
multiple VMs. This would allow for a 1+1 queries scenario, instead of
1+N. Once the backend provides this the RESTAPI can be changed to use
it. This is for the virt team to decide, I'd suggest you open a bug.

 Many thanks in advance. 
 
 
 Regards, 
 Einav

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Request for new git repos: ovirt-engine-sdk-python-specs, ovirt-engine-sdk-java-specs, ovirt-engine-cli-specs

[Juan Hernández]

Hello,

Please create the following new git repositories:

  ovirt-engine-sdk-python-specs
  ovirt-engine-sdk-java-specs
  ovirt-engine-cli-specs

They will be used to manage the RPM spec files (also scripts, patches,
and in general anything needed for building RPMs) of the Python SDK, the
Java SDK, and the CLI. Each repository will have branches for each pair
of oVirt major release and supported distribution:

  ovirt-3.5-el6
  ovirt-3.5-el7
  ovirt-3.5-fc20
  ovirt-3.5-fc21
  ovirt-3.6-el6
  ...

Initially I will be the maintainer of these repositories.

Once these repos are created the specs will be added to them and
eventually removed completely from the main repositories of the SDKs and
the CLI.

Thanks in advance,
Juan Hernández

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Request for new git repos: ovirt-engine-sdk-python-specs, ovirt-engine-sdk-java-specs, ovirt-engine-cli-specs

[Juan Hernández]

On 01/09/2015 03:22 PM, Sandro Bonazzola wrote:
 Il 09/01/2015 15:13, Juan Hernández ha scritto:
 Hello,

 Please create the following new git repositories:

   ovirt-engine-sdk-python-specs
   ovirt-engine-sdk-java-specs
   ovirt-engine-cli-specs

 They will be used to manage the RPM spec files (also scripts, patches,
 and in general anything needed for building RPMs) of the Python SDK, the
 Java SDK, and the CLI. Each repository will have branches for each pair
 of oVirt major release and supported distribution:

 
 Any reason for not having something like ovirt-specs
 with suggested branches:
 
 
   ovirt-3.5-el6
   ovirt-3.5-el7
   ovirt-3.5-fc20
   ovirt-3.5-fc21
   ovirt-3.6-el6
   ...
 
 
 and having there
 
 ovirt-engine-sdk-python/ovirt-engine-sdk-python.spec
 ovirt-engine-sdk-python/0001-your-friendly-patch.patch
 ovirt-engine-sdk-java/ovirt-engine-sdk-java.spec
 ovirt-engine-cli/ovirt-engine-cli.spec
 ...
 

I don't have any objection to that, as long as we can have the above
mentioned branches and commit permissions.


 Initially I will be the maintainer of these repositories.

 Once these repos are created the specs will be added to them and
 eventually removed completely from the main repositories of the SDKs and
 the CLI.

 Thanks in advance,
 Juan Hernández

 
 


-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt-engine-sdk session authentication

[Juan Hernández]

On 01/04/2015 05:12 AM, Tony James wrote:
 Does ovirt-engine-sdk support session authentication to avoid using a 
 username and password?  It appears this functionality was added to 
 ovirt-engine-sdk-java [1].
 
 [1] http://gerrit.ovirt.org/#/c/12818/

No, the Python SDK doesn't currently support that, and there are no
plans to add support for it.

Note that what the Java SDK supports is taking the session identifier
from somewhere and re-using it. That isn't very useful, as most clients
will close their session when they finish, potentially and unexpectedly
rendering the the re-used session invalid.

If you aren't trying to re-use a session then having this capability
won't help you, as you will anyhow need to authenticate at least once
using the user name and password.

Version 3.6 of the SDKs (Python and Java) will support Kerberos
authentication:

  http://www.ovirt.org/Features/Kerberos_Support_in_SDKs_and_CLI#Python_SDK

Depending on your actual requirements this may be a better fit.

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt desktopLogin using ovirtsdk for python

[Juan Hernández]

On 12/16/2014 11:01 AM, Pavel Zelensky wrote:
 Hi
 
 What version of the engine are you using exactly? And what is your
 authentication configuration?
 
 [root@ovirt ~]# rpm -qa|grep ovirt-eng
 ovirt-engine-3.5.0.1-1.el6.noarch
 
 # engine-manage-domains list
 Domain: ov.jetlab.local
 User name: pzelensky@OV.JETLAB.LOCAL
 Manage Domains completed successfully
 
 # cat engine-manage-domains.conf
 jaasFile=/usr/share/ovirt-engine/conf/jaas.conf
 krb5confFile=/etc/ovirt-engine/krb5.conf
 engineConfigExecutable=/usr/share/ovirt-engine/bin/engine-config.sh
 localHostEntry=localhost
 useDnsLookup=true
 [root@ovirt engine-manage-domains]# cat /etc/ovirt-engine/krb5.conf
 
 [libdefaults]
 
 default_realm = OV.JETLAB.LOCAL
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 10h
 renew_lifetime = 7d
 forwardable = no
 default_tkt_enctypes = arcfour-hmac-md5
 udp_preference_limit = 1
 
 #realms
 
 And also SDK version: ovirt_engine_sdk_python-3.5.0.8-py2.7
 So oVirt authenticates users using connection to MS AD which is based on
 Windows 2012R2
 
 --
 Pavel
 

I reproduced this in my environment. Apparently the password is lost
somewhere in the authentication process. Yair, can you please take a look?

  
 
 
 On Tue, Dec 16, 2014 at 12:04 PM, Juan Hernández jhern...@redhat.com
 mailto:jhern...@redhat.com wrote:
 
 On 12/15/2014 08:37 PM, Pavel Zelensky wrote:
  Hi
 
  I think it's not good idea, but I've done it:
 
  2014-12-15 22:21:37,485 INFO  [org.ovirt.engine.core.bll.VmLogonCommand]
  (ajp--127.0.0.1-8702-6) [None] Running command: VmLogonCommand internal:
  false. Entities affected :  ID: 202ca21f-5167-4107-b1dd-2a7a5d64b32a
  Type: VMAction group CONNECT_TO_VM with role type USER
  2014-12-15 22:21:37,495 INFO
   [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand]
  (ajp--127.0.0.1-8702-6) [None] START, VmLogonVDSCommand(HostName =
  ceph2, HostId = c7a7c873-b68a-44f8-bebf-37ca3aa1caa8,
  vmId=202ca21f-5167-4107-b1dd-2a7a5d64b32a, domain=internal,
  password=null, userName=admin), log id: 776ac4b1
  2014-12-15 22:21:37,514 INFO
   [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand]
  (ajp--127.0.0.1-8702-6) [None] FINISH, VmLogonVDSCommand, log id: 
 776ac4b1
  2014-12-15 22:21:41,155 INFO
   [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
  (DefaultQuartzScheduler_Worker-47) Correlation ID: null, Call Stack:
  null, Custom Event ID: -1, Message: User admin is connected to VM 
 w7ent-01.
 
  Looks pretty the same, also trying to login as admin@internal into Win7
  workstation assigned to MS domain shouldn't work.
 
 
 I just wanted to check if with admin@internal you still get
 password=null (they use different authentication mechanisms).
 
  BTW, when I'm connecting to the same VM using the same domain user
  account through user portal - everything is Ok, and SSO works pretty
  good. In that case in logfile I'm getting this (password=[asterisks]):
  2014-12-14 22:45:21,010 INFO
   [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand]
  (ajp--127.0.0.1-8702-4) [6f5a076f] START, VmLogonVDSCommand(HostName =
  ceph2, HostId = c7a7c873-b68a-44f8-bebf-37ca3aa1caa8,
  vmId=202ca21f-5167-4107-b1dd-2a7a5d64b32a, domain=ov.jetlab.local,
  password=**, userName=test4), log id: 7cc2d16a
 
  that's why I think that problem is in python sdk. It uses JSESSIONID and
  not sending password every time it executing command through REST API.
  May be with api.vm.logon() method It should send password again? But how
  I can do it?
 
  Pavel
 
 
 No, you shouldn't (and can't) sent the password again. This isn't a
 problem in the Python SDK, but in the backend or the RESTAPI.
 
 
 
  On Mon, Dec 15, 2014 at 8:41 PM, Juan Hernández jhern...@redhat.com 
 mailto:jhern...@redhat.com
  mailto:jhern...@redhat.com mailto:jhern...@redhat.com wrote:
 
  On 12/15/2014 05:57 PM, Pavel Zelensky wrote:
  
   Hi guys,
  
   I'm expiriencing some problems trying to invoke
 api.vm.logon() method
   which I believe will call for desktopLogin on the VM and
 provide vm
   console with user logged in for remote-viewer.
  
   But it results in the following records in logfile:
   2014-12-12 16:07:01,314 INFO
  [org.ovirt.engine.core.bll.VmLogonCommand]
   (ajp--127.0.0.1-8702-3) [7cfe61d3] Running command:
 VmLogonCommand
   internal: false. Entities affected :  ID:
   a7c151a4-2d63-4172-a840-190748a3dbc1 Type: VMAction group
  CONNECT_TO_VM
   with role type USER
   2014-12-12 16:07:01,320 INFO
   [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand]
   (ajp--127.0.0.1-8702-3) [7cfe61d3] START