From gang.wei at intel.com  Fri Feb  1 08:25:16 2013
From: gang.wei at intel.com (Wei, Gang)
Date: Fri, 1 Feb 2013 08:25:16 +0000
Subject: [Engine-devel] Trusted Compute Pools
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BE3FCDA2@SHSMSX101.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BE3FCDA2@SHSMSX101.ccr.corp.intel.com>
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE4DF9EC@SHSMSX101.ccr.corp.intel.com>

Design page updated according to in process Patchset 2.
http://wiki.ovirt.org/wiki/Trusted_compute_pools.

Jimmy

Wei, Gang wrote on?2012-11-20:
> Hi,
> 
> I am an engineer working in Intel Open Source Technology Center,
interested
> in integrating Intel initiated OpenAttestation(OAT) project
> (https://github.com/OpenAttestation/OpenAttestation.git) into oVirt to
> provide a way for Administrator to deploy VMs on trusted hosts hardened
with
> H/W-based security features, such as Intel TXT.
> 
> I made a draft feature page for this:
> http://wiki.ovirt.org/wiki/Trusted_compute_pools
> 
> My draft idea is to provide trust_level requirement while doing vm
creation
> like below:
> 
> curl -v -u "vdcadmin at qa.lab.tlv.redhat.com"
>     -H "Content-type: application/xml"
>     -d '<vm><name>my_new_vm</name>
> <cluster id="99408929-82cf-4dc7-a532-9d998063fa95" />
> <template id="00000000-0000-0000-0000-000000000000"/>
> <trust_level>trusted</trust_level></vm>'
>     'http://10.35.1.1/rhevm-api/vms'
> Then oVirt Engine should query attestation server built with OAT via
RESTful
> API to get all trusted hosts and select one to create the VM.
> 
> Attestation server performs host verification through following steps:
> 1. Hosts boot with Intel TXT technology enabled
> 2. The hosts' BIOS, hypervisor and OS are measured
> 3. These measured data is sent to Attestation server when challenged by
> attestation server
> 4. Attestation server verifies those measurements against good/known
> database to determine hosts' trustworthiness
> 
> Hosts need to be installed with OAT host agent to report host integrity to
> attestation server.
> 
> By far, I am still in process of getting familiar with oVirt code and not
> get solid idea yet on how the oVirt Engine should be modified to support
> this feature.
> 
> Any kind of comments or suggestions will be highly appreciated.
> 
> Thanks
> Gang (Jimmy) Wei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8586 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130201/e3098a71/attachment.p7s>

From wei.d.chen at intel.com  Fri Feb  1 09:31:28 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Fri, 1 Feb 2013 09:31:28 +0000
Subject: [Engine-devel] How to show our VM template from web protal?
Message-ID: <C5A0092C63E939488005F15F736A811209787689@SHSMSX101.ccr.corp.intel.com>

Hi, 

We are trying to create a VM template which is similar with "blank template" and hope to display this template on web portal, our consideration is simple, that is, just execute "InsertVmTemplate"
procedure manually and expect our template would be showed from web portal. Unfortunately, there is no changes seen from portal even after restarting engine service. 
Definitely, we must miss something, would you anyone input any suggestion, any feedback is great appreciated. thanks in advance!

Best Regards,
Dave Chen




From navinp1281 at gmail.com  Fri Feb  1 10:56:34 2013
From: navinp1281 at gmail.com (navin p)
Date: Fri, 1 Feb 2013 16:26:34 +0530
Subject: [Engine-devel] java SDK question
Message-ID: <CAKVd3pUFpHrELsWjanMKE6PY+y1_O79uyiuJNoH10nuhebyZGw@mail.gmail.com>

Hi,
 When i do the api call for events from , i only get 100 events. Can
someone tell me how to get all the events ?

List<Event> evlst=api.getEvents().list();
for(Event obj:evlst) {
 System.out.println(obj.getDescription() + ":" +obj.getSeverity()
+":"+obj.getTime().toString()+":"+k.toString());
}

Regards,
Navin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130201/ca2b5052/attachment.html>

From masayag at redhat.com  Fri Feb  1 13:17:34 2013
From: masayag at redhat.com (Moti Asayag)
Date: Fri, 01 Feb 2013 15:17:34 +0200
Subject: [Engine-devel] java SDK question
In-Reply-To: <CAKVd3pUFpHrELsWjanMKE6PY+y1_O79uyiuJNoH10nuhebyZGw@mail.gmail.com>
References: <CAKVd3pUFpHrELsWjanMKE6PY+y1_O79uyiuJNoH10nuhebyZGw@mail.gmail.com>
Message-ID: <510BC06E.2010209@redhat.com>

On 02/01/2013 12:56 PM, navin p wrote:
> Hi,
>  When i do the api call for events from , i only get 100 events. Can
> someone tell me how to get all the events ?
> 

There are 2 options:
1. Use the overloaded Event.list method and specify the amount of result
you wish to get. In the next example you'll get 1000 entries.

Events events = api.getEvents();
events.list("", false, "", 1000);

You can use this method to retrieve events by extents.

2. Increase the value of the configuration value 'SearchResultsLimit' to
the desired reasonable value.

> List<Event> evlst=api.getEvents().list();
> for(Event obj:evlst) {
> System.out.println(obj.getDescription() + ":" +obj.getSeverity()
> +":"+obj.getTime().toString()+":"+k.toString());
> }
> 
> Regards,
> Navin
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From eedri at redhat.com  Fri Feb  1 20:09:40 2013
From: eedri at redhat.com (Eyal Edri)
Date: Fri, 1 Feb 2013 15:09:40 -0500 (EST)
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build #
 3413 - Unstable!
In-Reply-To: <1946573716.4502.1359726056107.JavaMail.jenkins@jenkins.ovirt.org>
Message-ID: <41954855.8153805.1359749380926.JavaMail.root@redhat.com>

fyi,

new HIGH priority bug has been detected via findbugs in Managedomains.java file:

http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3413/findbugsResult/HIGH/?

it was inserted in one of the commits since jan 29:

(git blames this commit ..http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git&a=commit&h=35722c064f876ab9ead4b62105f7031623ec4471) 


> ------------------------------------
> Changes Since Last Success:
> -------------------------------------

> [alkaplan] webadmin: Showing more than one canDoMessage for action in
> multiple action
> [alkaplan] engine: Extended error for pinned host missing non
> required network
> [alkaplan] webadmin: Add default description to multiple action
> result
> [gerrit2] engine: Moving Duplicate Code to Base Class
> [juan.hernandez] packaging: Bump version number to 3.3.0-SNAPSHOT
> [gerrit2] frontend: force admin-console only on AdminPortal
> [mkublin] engine: Stop flood a logs by Autorecovering 0 ....
> [rgolan] core: cancel migration better error handling
> [amureini] core: Remove dead JPA implementation
> [gerrit2] gluster: fixed NPE in GlusterAuditLogUtil
> [gerrit2] packaging: suggest path for local storage during AIO setup
> [ofrenkel] core: add support for tunnel migration
> [ofrenkel] restapi: Add support for tunnel migration
> [gerrit2] core: cleanup Handler classes
> [amureini] packaging: Complete removal of Hibernate
> [gerrit2] core: prevent changing display settings when vm isn't down
> [ahadas] webadmin: replace 'VM' with 'Virtual Machine'
> [alonbl] packaging: set both PGPASSFILE and ENGINE_PGPASS
> [alonbl] packaging: substitute engineVersion.js in target that
> actually create it
> [amureini] core,ui: test duplicate keys in appErrors 
> [gerrit2] core: Make dependency on commons-collections explicit
> [gerrit2] compat: convert to base64 without line feed
> [gerrit2] pki: process template files not in-place
> [gerrit2] pki: install private directories not world readable
> [gerrit2] pki: encryptpasswd: remove unneeded pushd/popd
> [gerrit2] cleanup: update .gitignore
> 


----- Original Message -----
> From: "Jenkins oVirt Server" <jenkins at ovirt.org>
> To: eedri at redhat.com, engine-patches at ovirt.org, oliel at redhat.com, yzaslavs at redhat.com, dcaro at redhat.com
> Sent: Friday, February 1, 2013 3:40:56 PM
> Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3413 - Unstable!
> 
> Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/
> Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3413/
> Build Number: 3413
> Build Status:  Unstable
> Triggered By: Started by user David Caro Estevez
> 
> -------------------------------------
> Changes Since Last Success:
> -------------------------------------
> Changes for Build #3402
> [alkaplan] webadmin: Showing more than one canDoMessage for action in
> multiple action
> 
> [alkaplan] engine: Extended error for pinned host missing non
> required network
> 
> [alkaplan] webadmin: Add default description to multiple action
> result
> 
> [gerrit2] engine: Moving Duplicate Code to Base Class
> 
> [juan.hernandez] packaging: Bump version number to 3.3.0-SNAPSHOT
> 
> 
> Changes for Build #3403
> 
> Changes for Build #3404
> [gerrit2] frontend: force admin-console only on AdminPortal
> 
> 
> Changes for Build #3405
> [mkublin] engine: Stop flood a logs by Autorecovering 0 ....
> 
> [rgolan] core: cancel migration better error handling
> 
> 
> Changes for Build #3406
> 
> Changes for Build #3407
> [amureini] core: Remove dead JPA implementation
> 
> [gerrit2] gluster: fixed NPE in GlusterAuditLogUtil
> 
> 
> Changes for Build #3408
> 
> Changes for Build #3409
> [gerrit2] packaging: suggest path for local storage during AIO setup
> 
> [ofrenkel] core: add support for tunnel migration
> 
> [ofrenkel] restapi: Add support for tunnel migration
> 
> [gerrit2] core: cleanup Handler classes
> 
> [amureini] packaging: Complete removal of Hibernate
> 
> [gerrit2] core: prevent changing display settings when vm isn't down
> 
> [ahadas] webadmin: replace 'VM' with 'Virtual Machine'
> 
> [alonbl] packaging: set both PGPASSFILE and ENGINE_PGPASS
> 
> [alonbl] packaging: substitute engineVersion.js in target that
> actually create it
> 
> [amureini] core,ui: test duplicate keys in appErrors
> 
> [gerrit2] core: Make dependency on commons-collections explicit
> 
> 
> Changes for Build #3410
> [gerrit2] compat: convert to base64 without line feed
> 
> [gerrit2] pki: process template files not in-place
> 
> [gerrit2] pki: install private directories not world readable
> 
> [gerrit2] pki: encryptpasswd: remove unneeded pushd/popd
> 
> 
> Changes for Build #3411
> 
> Changes for Build #3412
> [gerrit2] cleanup: update .gitignore
> 
> 
> Changes for Build #3413
> 
> 
> 
> -----------------
> Failed Tests:
> -----------------
> No tests ran.
> 
> ------------------
> Build Log:
> ------------------
> [...truncated 32804 lines...]
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.jar
>                                    
> Downloaded:
> http://repo1.maven.org/maven2/velocity/velocity/1.4/velocity-1.4.jar
> (353 KB at 6298.4 KB/sec)
> 4 KB   159 KB   27 KB
> 8 KB   159 KB   27 KB
> 12 KB   159 KB   27 KB
> 16 KB   159 KB   27 KB
> 20 KB   159 KB   27 KB
> 24 KB   159 KB   27 KB
> 28 KB   159 KB   27 KB
> 32 KB   159 KB   27 KB
> 36 KB   159 KB   27 KB
> 38 KB   159 KB   27 KB
> 38 KB   163 KB   27 KB
> 38 KB   167 KB   27 KB
> 38 KB   171 KB   27 KB
> 38 KB   175 KB   27 KB
> 38 KB   179 KB   27 KB
> 38 KB   183 KB   27 KB
> 38 KB   187 KB   27 KB
> 38 KB   191 KB   27 KB
> 38 KB   195 KB   27 KB
> 38 KB   199 KB   27 KB
> 38 KB   203 KB   27 KB
> 38 KB   207 KB   27 KB
> 38 KB   211 KB   27 KB
> 38 KB   215 KB   27 KB
> 38 KB   219 KB   27 KB
> 38 KB   223 KB   27 KB
> 38 KB   227 KB   27 KB
> 38 KB   231 KB   27 KB
> 38 KB   234 KB   27 KB
> 38 KB   238 KB   27 KB
> 38 KB   242 KB   27 KB
> 38 KB   246 KB   27 KB
> 38 KB   250 KB   27 KB
> 38 KB   254 KB   27 KB
> 38 KB   258 KB   27 KB
> 38 KB   262 KB   27 KB
> 38 KB   266 KB   27 KB
> 38 KB   270 KB   27 KB
> 38 KB   274 KB   27 KB
> 38 KB   278 KB   27 KB
> 38 KB   282 KB   27 KB
> 38 KB   286 KB   27 KB
> 38 KB   290 KB   27 KB
> 38 KB   294 KB   27 KB
> 38 KB   298 KB   27 KB
> 38 KB   302 KB   27 KB
> 38 KB   306 KB   27 KB
>                          
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.0-alpha-7/doxia-decoration-model-1.0-alpha-7.jar
> (38 KB at 1433.9 KB/sec)
> 310 KB   27 KB
> 314 KB   27 KB
> 318 KB   27 KB
> 322 KB   27 KB
> 326 KB   27 KB
> 330 KB   27 KB
> 334 KB   27 KB
> 338 KB   27 KB
> 342 KB   27 KB
> 346 KB   27 KB
> 350 KB   27 KB
> 354 KB   27 KB
> 358 KB   27 KB
> 362 KB   27 KB
> 366 KB   27 KB
> 370 KB   27 KB
> 374 KB   27 KB
> 378 KB   27 KB
> 382 KB   27 KB
> 386 KB   27 KB
> 390 KB   27 KB
> 394 KB   27 KB
> 398 KB   27 KB
> 402 KB   27 KB
> 406 KB   27 KB
> 410 KB   27 KB
> 414 KB   27 KB
> 418 KB   27 KB
> 422 KB   27 KB
> 426 KB   27 KB
> 430 KB   27 KB
> 434 KB   27 KB
> 438 KB   27 KB
> 442 KB   27 KB
> 446 KB   27 KB
> 450 KB   27 KB
> 454 KB   27 KB
> 458 KB   27 KB
> 462 KB   27 KB
> 466 KB   27 KB
> 470 KB   27 KB
> 474 KB   27 KB
> 478 KB   27 KB
> 482 KB   27 KB
> 486 KB   27 KB
> 490 KB   27 KB
> 494 KB   27 KB
> 498 KB   27 KB
> 502 KB   27 KB
> 506 KB   27 KB
> 506 KB   27 KB
>                  
> Downloaded:
> http://repo1.maven.org/maven2/velocity/velocity-dep/1.4/velocity-dep-1.4.jar
> (506 KB at 4770.1 KB/sec)
>                  
> Downloaded:
> http://repo1.maven.org/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0/maven-common-artifact-filters-1.0.jar
> (27 KB at 48.8 KB/sec)
> 4 KB
> 8 KB
> 12 KB
> 15 KB
> 17 KB
> 21 KB
> 25 KB
> 29 KB
> 33 KB
> 36 KB
> 40 KB
> 44 KB
> 48 KB
> 52 KB
> 56 KB
> 60 KB
> 64 KB
> 66 KB
> 70 KB
> 74 KB
> 78 KB
> 82 KB
> 86 KB
> 90 KB
> 94 KB
> 98 KB
> 102 KB
> 106 KB
> 110 KB
> 114 KB
> 118 KB
> 122 KB
> 126 KB
> 130 KB
> 134 KB
> 138 KB
> 142 KB
> 146 KB
> 150 KB
> 154 KB
> 157 KB
>          
> Downloaded:
> http://repo1.maven.org/maven2/plexus/plexus-utils/1.0.2/plexus-utils-1.0.2.jar
> (157 KB at 166.1 KB/sec)
> [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
> [INFO] Copying quartz-2.1.2.jar to
> /ephemeral0/ovirt_engine_find_bugs/ear/target/quartz/quartz-2.1.2.jar
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> engine-server-ear ---
> [INFO] Installing
> /ephemeral0/ovirt_engine_find_bugs/ear/target/engine.ear to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear
> [INFO] Installing /ephemeral0/ovirt_engine_find_bugs/ear/pom.xml to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @
> engine-server-ear ---
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] ovirt-root ........................................ SUCCESS
> [4.746s]
> [INFO] oVirt Build Tools root ............................ SUCCESS
> [0.053s]
> [INFO] oVirt checkstyle .................................. SUCCESS
> [3.136s]
> [INFO] oVirt Checkstyle Checks ........................... SUCCESS
> [19.792s]
> [INFO] oVirt Modules - backend ........................... SUCCESS
> [0.094s]
> [INFO] oVirt Manager ..................................... SUCCESS
> [0.068s]
> [INFO] oVirt DB Scripts .................................. SUCCESS
> [0.421s]
> [INFO] oVirt Modules - manager ........................... SUCCESS
> [1.471s]
> [INFO] CSharp Compatibility .............................. SUCCESS
> [33.383s]
> [INFO] Encryption Libraries .............................. SUCCESS
> [19.692s]
> [INFO] oVirt Tools ....................................... SUCCESS
> [0.141s]
> [INFO] oVirt Tools Common Library ........................ SUCCESS
> [16.808s]
> [INFO] Common Code ....................................... SUCCESS
> [1:36.328s]
> [INFO] Common utilities .................................. SUCCESS
> [1:32.875s]
> [INFO] Data Access Layer ................................. SUCCESS
> [1:10.370s]
> [INFO] engine beans ...................................... SUCCESS
> [0.136s]
> [INFO] engine scheduler bean ............................. SUCCESS
> [22.034s]
> [INFO] Vds broker ........................................ SUCCESS
> [1:13.278s]
> [INFO] Search Backend .................................... SUCCESS
> [36.539s]
> [INFO] Backend Logic @Service bean ....................... SUCCESS
> [2:41.427s]
> [INFO] oVirt RESTful API Backend Integration ............. SUCCESS
> [6.955s]
> [INFO] oVirt RESTful API interface ....................... SUCCESS
> [0.274s]
> [INFO] oVirt Engine API Definition ....................... SUCCESS
> [1:03.362s]
> [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
> [0.179s]
> [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
> [34.356s]
> [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
> [39.349s]
> [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
>  SUCCESS [1:26.921s]
> [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
> [1.273s]
> [INFO] oVirt Engine Web Root ............................. SUCCESS
> [17.907s]
> [INFO] oVirt Configuration Tool .......................... SUCCESS
> [27.626s]
> [INFO] Notifier Service package .......................... SUCCESS
> [0.033s]
> [INFO] Notifier Service .................................. SUCCESS
> [28.639s]
> [INFO] Notifier Service Resources ........................ SUCCESS
> [2.673s]
> [INFO] oVirt Modules :: Frontend ......................... SUCCESS
> [0.037s]
> [INFO] oVirt Modules :: Webadmin ......................... SUCCESS
> [0.059s]
> [INFO] oVirt Modules - ui ................................ SUCCESS
> [0.366s]
> [INFO] Extensions for GWT ................................ SUCCESS
> [23.554s]
> [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
> [28.727s]
> [INFO] Frontend for GWT UI Projects ...................... SUCCESS
> [34.302s]
> [INFO] UICommonWeb ....................................... SUCCESS
> [2:06.210s]
> [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
> [1:29.750s]
> [INFO] WebAdmin .......................................... SUCCESS
> [1:46.479s]
> [INFO] UserPortal ........................................ SUCCESS
> [53.177s]
> [INFO] oVirt WARs ........................................ SUCCESS
> [0.021s]
> [INFO] oVirt Web Application Module ...................... SUCCESS
> [19.788s]
> [INFO] oVirt Server EAR .................................. SUCCESS
> [8.156s]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 24:16.123s
> [INFO] Finished at: Fri Feb 01 08:41:09 EST 2013
> [INFO] Final Memory: 310M/665M
> [INFO]
> ------------------------------------------------------------------------
> [FINDBUGS] Collecting findbugs analysis files...
> [FINDBUGS] Finding all files that match the pattern
> **/findbugsXml.xml
> [FINDBUGS] Parsing 26 files in
> /home/jenkins/workspace/ovirt_engine_find_bugs
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/scheduler/target/findbugsXml.xml
> of module  with 0 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/bll/target/findbugsXml.xml
> of module  with 263 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/common/target/findbugsXml.xml
> of module  with 260 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/compat/target/findbugsXml.xml
> of module  with 56 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/dal/target/findbugsXml.xml
> of module  with 28 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/engineencryptutils/target/findbugsXml.xml
> of module  with 6 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml
> of module  with 16 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml
> of module  with 1 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml
> of module  with 28 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/types/target/findbugsXml.xml
> of module  with 13 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/root/target/findbugsXml.xml
> of module  with 1 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/searchbackend/target/findbugsXml.xml
> of module  with 12 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/utils/target/findbugsXml.xml
> of module  with 82 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/vdsbroker/target/findbugsXml.xml
> of module  with 241 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/engine-config/target/findbugsXml.xml
> of module  with 8 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/engine-notifier/engine-notifier-service/target/findbugsXml.xml
> of module  with 11 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/engine-tools-common/target/findbugsXml.xml
> of module  with 2 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/build-tools-root/ovirt-checkstyle-extension/target/findbugsXml.xml
> of module  with 1 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/findbugsXml.xml
> of module  with 0 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/frontend/target/findbugsXml.xml
> of module  with 41 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml
> of module  with 83 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml
> of module  with 2 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommonweb/target/findbugsXml.xml
> of module  with 668 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicompat/target/findbugsXml.xml
> of module  with 34 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/findbugsXml.xml
> of module  with 14 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/findbugsXml.xml
> of module  with 69 warnings.
> [FINDBUGS] Computing warning deltas based on reference build #3401
> Build step 'Publish FindBugs analysis results' changed build result
> to UNSTABLE
> IRC notifier plugin: Sending notification to: #ovirt-jenkins
> IRC notifier plugin: [ERROR] not connected. Cannot send message to
> '#ovirt-jenkins'
> Email was triggered for: Unstable
> Sending email for trigger: Unstable
> 


From mpastern at redhat.com  Sat Feb  2 17:48:52 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sat, 02 Feb 2013 19:48:52 +0200
Subject: [Engine-devel] java SDK question
In-Reply-To: <510BC06E.2010209@redhat.com>
References: <CAKVd3pUFpHrELsWjanMKE6PY+y1_O79uyiuJNoH10nuhebyZGw@mail.gmail.com>
	<510BC06E.2010209@redhat.com>
Message-ID: <510D5184.2020606@redhat.com>

On 02/01/2013 03:17 PM, Moti Asayag wrote:
> On 02/01/2013 12:56 PM, navin p wrote:
>> Hi,
>>  When i do the api call for events from , i only get 100 events. Can
>> someone tell me how to get all the events ?
>>
> 
> There are 2 options:
> 1. Use the overloaded Event.list method and specify the amount of result
> you wish to get. In the next example you'll get 1000 entries.
> 
> Events events = api.getEvents();
> events.list("", false, "", 1000);
> 
> You can use this method to retrieve events by extents.
> 
> 2. Increase the value of the configuration value 'SearchResultsLimit' to
> the desired reasonable value.

There is a third option, you can use pagination via engine search interface,
just append to your query string "page N".

> 
>> List<Event> evlst=api.getEvents().list();
>> for(Event obj:evlst) {
>> System.out.println(obj.getDescription() + ":" +obj.getSeverity()
>> +":"+obj.getTime().toString()+":"+k.toString());
>> }
>>
>> Regards,
>> Navin
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Sun Feb  3 08:56:07 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 03 Feb 2013 10:56:07 +0200
Subject: [Engine-devel] Java process increasing resident memory
In-Reply-To: <5109A3A5.3080309@redhat.com>
References: <CAKVd3pX+PYi5WZccz01uudFEU3K_Y=xshOfJtaisHHE3cqXbww@mail.gmail.com>
	<5109A3A5.3080309@redhat.com>
Message-ID: <510E2627.1060707@redhat.com>

On 01/31/2013 12:50 AM, Moti Asayag wrote:
> On 01/29/2013 10:27 AM, navin p wrote:
>> > Hi,
>> >   I wrote this sample code and the resident memory of the process is
>> > increasing gradually over time. What could be the reason ? I don't see
>> > any obvious leaks in my program. Could it be that the API is not
>> > freeing/deleting memory ?
> By monitoring the program, it seems that the failure is due to constant
> threads creation by invoking the "new API()" call:
> 
> Exception in thread "main" java.lang.OutOfMemoryError: unable to create
> new native thread
>         at java.lang.Thread.start0(Native Method)
>         at java.lang.Thread.start(Thread.java:691)
>         at
> org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.createPoolingClientConnectionManager(ConnectionsPoolBuilder.java:182)
>         at
> org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.createDefaultHttpClient(ConnectionsPoolBuilder.java:160)
>         at
> org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.build(ConnectionsPoolBuilder.java:234)
>         at org.ovirt.engine.sdk.Api.<init>(Api.java:82)
>         at collectHosts.main(collectHosts.java:102)
> 
> 
> By pulling the API instantiation outside of the loop, problem solved,
> since only a single thread is created to monitor the idle/expired
> connections.

Thanks Moti,

I already suggested navin to take SDK proxy initiation out of his while loop.

> 
> 
> Michael, wouldn't you suggest adding some sort of API.shutdown() method
> in order to release resources used by it including the connection
> monitor and any other live connections if exists?

no need for that, in SDK i have dedicated thread (watchdog) for that.

> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From masayag at redhat.com  Sun Feb  3 09:30:07 2013
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 03 Feb 2013 11:30:07 +0200
Subject: [Engine-devel] Java process increasing resident memory
In-Reply-To: <510E2627.1060707@redhat.com>
References: <CAKVd3pX+PYi5WZccz01uudFEU3K_Y=xshOfJtaisHHE3cqXbww@mail.gmail.com>
	<5109A3A5.3080309@redhat.com> <510E2627.1060707@redhat.com>
Message-ID: <510E2E1F.3050403@redhat.com>

On 02/03/2013 10:56 AM, Michael Pasternak wrote:
> On 01/31/2013 12:50 AM, Moti Asayag wrote:
>> On 01/29/2013 10:27 AM, navin p wrote:
>>>> Hi,
>>>>   I wrote this sample code and the resident memory of the process is
>>>> increasing gradually over time. What could be the reason ? I don't see
>>>> any obvious leaks in my program. Could it be that the API is not
>>>> freeing/deleting memory ?
>> By monitoring the program, it seems that the failure is due to constant
>> threads creation by invoking the "new API()" call:
>>
>> Exception in thread "main" java.lang.OutOfMemoryError: unable to create
>> new native thread
>>         at java.lang.Thread.start0(Native Method)
>>         at java.lang.Thread.start(Thread.java:691)
>>         at
>> org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.createPoolingClientConnectionManager(ConnectionsPoolBuilder.java:182)
>>         at
>> org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.createDefaultHttpClient(ConnectionsPoolBuilder.java:160)
>>         at
>> org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.build(ConnectionsPoolBuilder.java:234)
>>         at org.ovirt.engine.sdk.Api.<init>(Api.java:82)
>>         at collectHosts.main(collectHosts.java:102)
>>
>>
>> By pulling the API instantiation outside of the loop, problem solved,
>> since only a single thread is created to monitor the idle/expired
>> connections.
> 
> Thanks Moti,
> 
> I already suggested navin to take SDK proxy initiation out of his while loop.
> 
>>
>>
>> Michael, wouldn't you suggest adding some sort of API.shutdown() method
>> in order to release resources used by it including the connection
>> monitor and any other live connections if exists?
> 
> no need for that, in SDK i have dedicated thread (watchdog) for that.
> 

But what if you wish to instantiate several API classes? each of them
will leave a detached (daemon) thread for monitoring the connections.

I suggested to perform inside the API.shutdown() release of any resource
used by it, including the watchdog thread. Else there is a sort of
thread-leak: when you have no longer reference to the API object, yet
the thread used to clean connections open by it is still running.

>>
> 
> 



From mpastern at redhat.com  Sun Feb  3 09:56:33 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 03 Feb 2013 11:56:33 +0200
Subject: [Engine-devel] Java process increasing resident memory
In-Reply-To: <510E2E1F.3050403@redhat.com>
References: <CAKVd3pX+PYi5WZccz01uudFEU3K_Y=xshOfJtaisHHE3cqXbww@mail.gmail.com>
	<5109A3A5.3080309@redhat.com> <510E2627.1060707@redhat.com>
	<510E2E1F.3050403@redhat.com>
Message-ID: <510E3451.4010209@redhat.com>

On 02/03/2013 11:30 AM, Moti Asayag wrote:
> On 02/03/2013 10:56 AM, Michael Pasternak wrote:
>> On 01/31/2013 12:50 AM, Moti Asayag wrote:
>>> On 01/29/2013 10:27 AM, navin p wrote:
>>>>> Hi,
>>>>>   I wrote this sample code and the resident memory of the process is
>>>>> increasing gradually over time. What could be the reason ? I don't see
>>>>> any obvious leaks in my program. Could it be that the API is not
>>>>> freeing/deleting memory ?
>>> By monitoring the program, it seems that the failure is due to constant
>>> threads creation by invoking the "new API()" call:
>>>
>>> Exception in thread "main" java.lang.OutOfMemoryError: unable to create
>>> new native thread
>>>         at java.lang.Thread.start0(Native Method)
>>>         at java.lang.Thread.start(Thread.java:691)
>>>         at
>>> org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.createPoolingClientConnectionManager(ConnectionsPoolBuilder.java:182)
>>>         at
>>> org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.createDefaultHttpClient(ConnectionsPoolBuilder.java:160)
>>>         at
>>> org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.build(ConnectionsPoolBuilder.java:234)
>>>         at org.ovirt.engine.sdk.Api.<init>(Api.java:82)
>>>         at collectHosts.main(collectHosts.java:102)
>>>
>>>
>>> By pulling the API instantiation outside of the loop, problem solved,
>>> since only a single thread is created to monitor the idle/expired
>>> connections.
>>
>> Thanks Moti,
>>
>> I already suggested navin to take SDK proxy initiation out of his while loop.
>>
>>>
>>>
>>> Michael, wouldn't you suggest adding some sort of API.shutdown() method
>>> in order to release resources used by it including the connection
>>> monitor and any other live connections if exists?
>>
>> no need for that, in SDK i have dedicated thread (watchdog) for that.
>>
> 
> But what if you wish to instantiate several API classes? each of them
> will leave a detached (daemon) thread for monitoring the connections.
> 
> I suggested to perform inside the API.shutdown() release of any resource
> used by it, including the watchdog thread. Else there is a sort of
> thread-leak: when you have no longer reference to the API object, yet
> the thread used to clean connections open by it is still running.

Good point Moti (in terms of self cleanup), but since SDK is used as infrastructure
and not re-initiated/closed during consuming application lifetime, i'm not concerned
about this,

but again this is definitely something that can be implemented in the one
of next releases.

> 
>>>
>>
>>
> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mkublin at redhat.com  Sun Feb  3 12:01:20 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Sun, 3 Feb 2013 07:01:20 -0500 (EST)
Subject: [Engine-devel] Improving of exist memory lock
	infrastructure	in	ovirt-engine
In-Reply-To: <1945390828.20043547.1359878491321.JavaMail.root@redhat.com>
Message-ID: <1299292423.12631575.1359892880204.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Allon Mureinik" <amureini at redhat.com>
> Cc: "Michael Kublin" <mkublin at redhat.com>
> Sent: Sunday, February 3, 2013 10:01:31 AM
> Subject: Re: [Engine-devel] Improving of exist memory lock infrastructure	in	ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Allon Mureinik" <amureini at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Sent: Sunday, February 3, 2013 9:58:58 AM
> > Subject: Re: [Engine-devel] Improving of exist memory lock
> > infrastructure	in	ovirt-engine
> > 
> > Basically, looks good to me.
> > 
> > My only consideration is the coupling of locks with async tasks.
> > We have flows (LSM, and much more to come) that are a series of
> > async
> > tasks, and we want to persist the lock throughout the logical flow.
> > As long as we have a way to do this (override endAction()?), the
> > design seems fine.
> > 
> > -Allon
You can persist a status of object (locked, shared lock, etc...) for presentation purpose, it is your internal logic.
But, canDoAction, races will be prevent by lock infrastructure, your responsibility is to choose a lock correctly (according to your use case)
and clean them when you need

> We would like to keep the lock until endAction.
> Regarding override - It will be the responsibility of all groups
> (currently virt and storage) to use the mechanism properly.

> 
> > 
> > ----- Original Message -----
> > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > To: "Michael Kublin" <mkublin at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, January 29, 2013 7:15:51 PM
> > > Subject: Re: [Engine-devel] Improving of exist memory lock
> > > infrastructure	in	ovirt-engine
> > > 
> > > Hi,
> > > I fixed some minor typos + have some comments on things need to
> > > be
> > > clarified.
> > > My comments are based on the sections + numbers inside the
> > > sections
> > > 
> > > Detailed Description
> > > 
> > > 3.  I think you should add:
> > > However, this behavior can be controlled as explained later on
> > > and
> > > a
> > > lock may be released after the end of "endAction".
> > > 
> > > 
> > > User-work-flows
> > > 
> > > 2. "If needed additional treatment the appropriate command will
> > > override getReadLocks() and getWriteLocks() methods of
> > > CommandBase
> > > <BR>"
> > > 
> > > 
> > > Don't you mean here the exclusive and shared locks?
> > > 
> > > 
> > > Failures -
> > > 4. In case task is found at DB, but not in SPM - will we want to
> > > clean it immediately at the first detection this issue occurs?
> > > (We
> > > talked about it today, and we think we should do that, giving
> > > other
> > > people a chance to comment)
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, January 29, 2013 12:01:33 PM
> > > > Subject: [Engine-devel] Improving of exist memory lock
> > > > infrastructure in	ovirt-engine
> > > > 
> > > > The following link
> > > > http://www.ovirt.org/Features/DetailedLockMechanism contains
> > > > description and design of in memory lock infrastructure.
> > > > The design is describing already existing infrastructure with
> > > > additional changes that should be done in order to improve it.
> > > > The idea is to allow using of in memory locks with commands
> > > > that
> > > > can
> > > > create asynchronous tasks.
> > > > 
> > > > Regards Michael
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 


From mkublin at redhat.com  Sun Feb  3 13:10:14 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Sun, 3 Feb 2013 08:10:14 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
Message-ID: <603841728.12634324.1359897014323.JavaMail.root@redhat.com>

Hi,

In ovirt-engine code we have Guid and NGuid objects.
Guid is extends NGuid and also NGuid class has method getValue() which should return Guid.
As for me these two classes are look like the same and I don't see to much differences between them.
My proposal is to remove NGuid and move it functionality to Guid (Because of Guid is much more common)

Regards Michael


From ofrenkel at redhat.com  Sun Feb  3 13:12:19 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 3 Feb 2013 08:12:19 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <603841728.12634324.1359897014323.JavaMail.root@redhat.com>
Message-ID: <410584819.15892729.1359897139638.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, February 3, 2013 3:10:14 PM
> Subject: [Engine-devel] Guid & NGuid
> 
> Hi,
> 
> In ovirt-engine code we have Guid and NGuid objects.
> Guid is extends NGuid and also NGuid class has method getValue()
> which should return Guid.
> As for me these two classes are look like the same and I don't see to
> much differences between them.
> My proposal is to remove NGuid and move it functionality to Guid
> (Because of Guid is much more common)
> 

i agree, but we need to take another step forward and allow Guid to be null (as it should)
and not assume its EMPTY or have a value (i'm pretty sure we have this assumption in many places)

> Regards Michael
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Sun Feb  3 13:17:29 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 3 Feb 2013 08:17:29 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <410584819.15892729.1359897139638.JavaMail.root@redhat.com>
Message-ID: <356258382.20054404.1359897449197.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, February 3, 2013 3:12:19 PM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, February 3, 2013 3:10:14 PM
> > Subject: [Engine-devel] Guid & NGuid
> > 
> > Hi,
> > 
> > In ovirt-engine code we have Guid and NGuid objects.
> > Guid is extends NGuid and also NGuid class has method getValue()
> > which should return Guid.
> > As for me these two classes are look like the same and I don't see
> > to
> > much differences between them.
> > My proposal is to remove NGuid and move it functionality to Guid
> > (Because of Guid is much more common)
> > 
> 
> i agree, but we need to take another step forward and allow Guid to
> be null (as it should)
> and not assume its EMPTY or have a value (i'm pretty sure we have
> this assumption in many places)

+1
NGuid IIRC was introduced for nullable GUID (i.e - Integer vs int )
I guess this was created back at the porting days, and now we don't need it, as non primitives can always be nullable.

> 
> > Regards Michael
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Sun Feb  3 13:19:09 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 3 Feb 2013 08:19:09 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <410584819.15892729.1359897139638.JavaMail.root@redhat.com>
Message-ID: <168595615.5754036.1359897549876.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, February 3, 2013 3:12:19 PM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, February 3, 2013 3:10:14 PM
> > Subject: [Engine-devel] Guid & NGuid
> > 
> > Hi,
> > 
> > In ovirt-engine code we have Guid and NGuid objects.
> > Guid is extends NGuid and also NGuid class has method getValue()
> > which should return Guid.
> > As for me these two classes are look like the same and I don't see
> > to
> > much differences between them.
> > My proposal is to remove NGuid and move it functionality to Guid
> > (Because of Guid is much more common)
> > 
> 
> i agree, but we need to take another step forward and allow Guid to
> be null (as it should)
> and not assume its EMPTY or have a value (i'm pretty sure we have
> this assumption in many places)

Hi,

And for the new people out here... why not kill both and use plain standard java UUID[1]?

I think we should kill compat, I don't see any value in fixing anything about it while leaving it intact.

Regards,
Alon Bar-Lev.

[1] http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html


From tnisan at redhat.com  Sun Feb  3 13:37:53 2013
From: tnisan at redhat.com (Tal Nisan)
Date: Sun, 03 Feb 2013 15:37:53 +0200
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <168595615.5754036.1359897549876.JavaMail.root@redhat.com>
References: <168595615.5754036.1359897549876.JavaMail.root@redhat.com>
Message-ID: <510E6831.1020408@redhat.com>

Alon has a point here, both classes wrap UUID anyway, it's time to get 
rid of this legacy and move to using the standard implementation directly


On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> And for the new people out here... why not kill both and use plain standard java UUID[1]?
>


From mgoldboi at redhat.com  Sun Feb  3 14:33:30 2013
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Sun, 03 Feb 2013 16:33:30 +0200
Subject: [Engine-devel] [Users] oVirt 3.2 testday
In-Reply-To: <510E6835.9050306@redhat.com>
References: <510E6835.9050306@redhat.com>
Message-ID: <510E753A.4050307@redhat.com>

removing non-relevant list.

On 02/03/2013 03:37 PM, Moran Goldboim wrote:
> Thanks for all the ones participating this day.
> we would like to get some feedback from you after testing this beta 
> version.
> how do you feel with respect to:
> -stability - basic flows
> -new features
> -blocker bugs (should be added to this version tracker [1])
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=881006
>
>
> Thanks,
> Moran.
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users



From eedri at redhat.com  Sun Feb  3 17:37:59 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 3 Feb 2013 12:37:59 -0500 (EST)
Subject: [Engine-devel] [oVirt Jenkins] ovirt-engine_create_rpms - Build
 # 2851 - Still Failing!
In-Reply-To: <373897843.4877.1359907828920.JavaMail.jenkins@jenkins.ovirt.org>
Message-ID: <1183577484.8409006.1359913079209.JavaMail.root@redhat.com>

fyi,

i see ovirt-engine fails to create rpms since build #2846.

something in manage domains man target maybe? 


"install -m 644 packaging/engine-manage-domains.8 /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/man/man8/
install: target `/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/man/man8/' is not a directory: No such file or directory"

suspected commit: 

Commit 9171c833e04f486889f7dea8d5e2e3b2dead128b by gerrit2
engine-manage-domains: Adding man page

Adding engine-manage-domains.8

Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=742421
Change-Id: I26e69ce1410ce1ffd0c8ce242ea519ff3c5daee6
Signed-off-by: Douglas Schilling Landgraf <dougsland at redhat.com>



----- Original Message -----
> From: "Jenkins oVirt Server" <jenkins at ovirt.org>
> To: infra at redhat.com, eedri at redhat.com, engine-patches at ovirt.org, oschreib at redhat.com
> Sent: Sunday, February 3, 2013 6:10:28 PM
> Subject: [oVirt Jenkins] ovirt-engine_create_rpms - Build # 2851 - Still Failing!
> 
> Project: http://jenkins.ovirt.org/job/ovirt-engine_create_rpms/
> Build: http://jenkins.ovirt.org/job/ovirt-engine_create_rpms/2851/
> Build Number: 2851
> Build Status:  Still Failing
> Triggered By: Started by an SCM change
> 
> -------------------------------------
> Changes Since Last Success:
> -------------------------------------
> Changes for Build #2847
> [gerrit2] db: support absolute log files
> 
> [gerrit2] db: do not override log file
> 
> 
> Changes for Build #2848
> [gerrit2] db: do not override ENGINE_PGPASS if exists
> 
> [gerrit2] db: make backup.sh respenct ENGINE_PGPASS
> 
> [ahadas] core: minor cleanup
> 
> [omasad] core: Fix sql grammar for calculateallstorageusage
> 
> [mkublin] engine: Replacing use of Quartz scheduler by ThreadPool
> during SPM election
> 
> [gerrit2] core: handle error when iso domain in maintenance
> 
> [gerrit2] core: Enable remove quota when quota is not enforced
> 
> [gerrit2] engine-manage-domains: Adding man page
> 
> [mkublin] engine: Disable global transaction at
> ExtendSANStorageDomain
> 
> [gerrit2] webadmin: Cleanup of Frontend class
> 
> [gerrit2] webadmin: Frontend class formatting
> 
> 
> Changes for Build #2849
> [mkublin] core: executing squartz job immediately
> 
> [mkublin] core: start 'prestarted VMs' immediately after update
> 
> [gerrit2] core: Find bugs fix at manage-domains
> 
> [gerrit2] core: Fix multiple domains to support useDnsLookup flag
> 
> 
> Changes for Build #2850
> 
> Changes for Build #2851
> [gerrit2] core: use return value instead of a shared boolean in
> recovery
> 
> [gerrit2] core: removal unneeded boolean and finally block from
> recovery command.
> 
> 
> 
> 
> -----------------
> Failed Tests:
> -----------------
> No tests ran.
> 
> ------------------
> Build Log:
> ------------------
> [...truncated 34812 lines...]
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/23.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/13.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/27.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/6.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/5.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/15.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/22.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/11.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/4.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/1.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/2.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/7.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/17.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/12.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/19.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/16.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/9.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/20.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/3.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/14.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/24.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/18.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/21.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/26.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/8.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/25.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/10.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/23.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/13.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/27.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/6.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/5.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/15.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/22.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/11.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/4.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/1.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/2.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/7.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/17.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/12.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/19.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/16.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/9.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/20.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/3.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/14.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/24.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/18.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/21.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/26.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/8.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/25.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/10.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/23.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/13.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/27.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/6.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/5.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/15.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/22.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/11.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/4.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/1.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/2.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/7.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/17.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/12.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/19.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/16.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/9.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/20.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/3.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/14.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/24.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/18.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/21.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/26.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/8.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/25.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/10.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/23.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/13.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/27.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/6.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/5.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/15.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/22.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/11.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/4.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/1.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/2.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/7.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/17.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/12.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/19.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/16.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/9.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/20.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/3.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/14.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/24.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/18.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/21.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/26.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/8.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/25.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/10.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/23.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/13.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/27.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/6.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/5.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/15.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/22.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/11.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/4.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/1.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/2.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/7.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/17.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/12.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/19.cache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/0F89659FF3F324AE4116F700257E32BD.cache.gif
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/560FD90F4DE504399017754A2BE9C471.cache.html
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_L.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_TL.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_T.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_BL.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_B.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_BR_resize.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_BR.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_TR.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_R.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/tab_middle_selected.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/login_header_background_repetitive.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/main_tab_middle.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/triangle_down_gray.gif
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/bg_head.gif
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/main_tab_left.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/user_portal_logo.gif
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/tab_arrow_selected.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/main_tab_right.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/tab_left_selected.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog_header_background_repetitive.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console_edit_Disabled.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console_Over.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console_Disabled.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console_edit_Over.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console_edit.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/general/tvlayout_doubleclick_to_console.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/tab_right_selected.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/UserPortal.css
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/13D2931874E71D07F248A0CDF051CC85.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/B32D4EC411D433442835DA919C331C98.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/223E04DC70F69BC559571D1C0E0667E5.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/2533B933CFFB78B592DBDBCE0536FE2D.cache.jpg
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/3C3D8436D91E322D6DA78347F7A6E8A9.cache.gif
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/D24C635030533A63087F7BC81DFBF0D8.cache.jpg
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/84A84DD674CFFCED19BA0EA45B9912D4.cache.html
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/396F806CD63ABD414BFBB9D57429F05B.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/ED39A5380F625072E8B00EB7E6F9C7E3.cache.jpg
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/DF7764EEC1903CD03C9545B354D8D8E4.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E5E3853BCBD97BD21376DF0B1A0D5D7D.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/3E13412DD77AE068AAF96B6978824A75.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/B5AB975C42AA317A66ABE9D0272BBF23.cache.jpg
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/560FD90F4DE504399017754A2BE9C471.gwt.rpc
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/EDC7827FEEA59EE44AD790B1C6430C45.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/876FCB92702D44A392A186EF42C34D5F.gwt.rpc
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/84A84DD674CFFCED19BA0EA45B9912D4.gwt.rpc
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/ECF0F0A105CE4C7FB1DC3E0A806964A7.gwt.rpc
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/2C0E07F73941ECCC3120A2B0311A6773.gwt.rpc
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E44767377485D18D6B6864F65BA8EF73.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/AB196D9D7834625802449A82C5811B43.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/98ED4A36A545561A7B5352F5A5AD1417.cache.jpg
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/2C0E07F73941ECCC3120A2B0311A6773.cache.html
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/C197E274BC03E8EBA72807BD177E913E.cache.jpg
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E0B86FF05CF8354CDDF99499CA94AECB.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E672328A3FCA83D2A2C68082504A351E.gwt.rpc
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/70074615010286B1C1909D4F706884AB.cache.jpg
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E672328A3FCA83D2A2C68082504A351E.cache.html
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/0A9476898799A150D840F0B1C3672921.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E0CB3A52C74FCDDCDFEB44A221AC3B22.gwt.rpc
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/A893DA4A583734DFC92F6933D2D429EF.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/ECF0F0A105CE4C7FB1DC3E0A806964A7.cache.html
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/clear.cache.gif
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/18E92EC55E78E20DE386EF783EE2E27D.cache.jpg
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/0326AF455425F6065C00E0361659A798.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/8DF1DD9438FB53F1D57718A906429D27.cache.png
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/4CE9178D7E588008F8DAD97784792101.cache.jpg
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/org.ovirt.engine.ui.userportal.UserPortal.nocache.js
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/hosted.html
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/META-INF/MANIFEST.MF
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/META-INF/maven/org.ovirt.engine.ui/userportal/pom.xml
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/META-INF/maven/org.ovirt.engine.ui/userportal/pom.properties
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/gwt-extension-3.3.0-SNAPSHOT.jar
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/gwt-servlet-2.3.0.jar
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/frontend-3.3.0-SNAPSHOT.jar
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/web.xml
>   inflating:
>   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/index.html
> for artifact_id in  backend bll common compat dal engine-config
> engine-notifier engine-notifier-resources engine-notifier-service
> engine-tools-common engineencryptutils interface-common-jaxrs
> manager manager-modules manager-tools restapi-definition
> restapi-jaxrs restapi-parent restapi-types root scheduler
> searchbackend utils vdsbroker ; do \
> 	POM=`find
> 	"/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILD/ovirt-engine-3.3.0/tmp.repos"
> 	-name "${artifact_id}-3.3.0*.pom"`; \
> 	if ! [ -f "${POM}" ]; then \
> 		echo "ERROR: Cannot find artifact ${artifact_id}"; \
> 		exit 1; \
> 	fi; \
> 	JAR=`echo "${POM}" | sed 's/\.pom/.jar/'`; \
> 	install -p -m 644 "${POM}"
> 	"/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/maven-poms/ovirt-engine-${artifact_id}.pom";
> 	\
> 	[ -f "${JAR}" ] && install -p -m 644 "${JAR}"
> 	"/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/java/ovirt-engine/${artifact_id}.jar";
> 	\
> done
> # Replace jar files in the ear with links to their actuals
> # locations
> for jar_line in /usr/share/ovirt-engine/engine.ear/engine-bll,bll
> /usr/share/ovirt-engine/engine.ear/engine-scheduler,scheduler
> /usr/share/ovirt-engine/engine.ear/lib/engine-common,common
> /usr/share/ovirt-engine/engine.ear/lib/engine-compat,compat
> /usr/share/ovirt-engine/engine.ear/lib/engine-dal,dal
> /usr/share/ovirt-engine/engine.ear/lib/engine-encryptutils,engineencryptutils
> /usr/share/ovirt-engine/engine.ear/lib/engine-tools-common,engine-tools-common
> /usr/share/ovirt-engine/engine.ear/lib/engine-utils,utils
> /usr/share/ovirt-engine/engine.ear/lib/engine-vdsbroker,vdsbroker
> /usr/share/ovirt-engine/engine.ear/lib/searchbackend,searchbackend ;
> do \
> 	path=`echo ${jar_line} | sed 's/,.*//'`; \
> 	jar=`echo ${jar_line} | sed 's/.*,//'`; \
> 	rm -rf
> 	"/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64${path}"*.jar;
> 	\
> 	ln -s "/usr/share/java/ovirt-engine/${jar}.jar"
> 	"/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64${path}.jar";
> 	\
> done
> sed -i
> "s/MYVERSION/3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17/"
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/root.war/engineVersion.js
> *** Deploying engine-config & engine-manage-domains
> # Configuration files for the configuration tool:
> install -m 644
> backend/manager/tools/engine-config/src/main/resources/engine-config.conf
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/etc/ovirt-engine/engine-config/
> install -m 644
> backend/manager/tools/engine-config/src/main/resources/engine-config.*properties
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/etc/ovirt-engine/engine-config/
> install -m 644
> backend/manager/tools/engine-config/src/main/resources/log4j.xml
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/etc/ovirt-engine/engine-config/
> # Main program for the configuration tool:
> install -m 750
> backend/manager/tools/engine-config/src/main/resources/engine-config
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/bin/engine-config.sh
> ln -s /usr/share/ovirt-engine/bin/engine-config.sh
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/bin/engine-config
> # Configuration files for the domain management tool:
> install -m 644
> backend/manager/modules/utils/src/main/resources/engine-manage-domains.conf
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/etc/ovirt-engine/engine-manage-domains/
> install -m 644
> backend/manager/modules/utils/src/main/resources/engine-manage-domains/log4j.xml
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/etc/ovirt-engine/engine-manage-domains/
> # Main program for the domain management tool:
> install -m 750 backend/manager/conf/kerberos/engine-manage-domains
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/bin/engine-manage-domains.sh
> ln -s /usr/share/ovirt-engine/bin/engine-manage-domains.sh
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/bin/engine-manage-domains
> # Install man pages
> install -m 644 packaging/engine-manage-domains.8
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/man/man8/
> install: target
> `/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/man/man8/'
> is not a directory: No such file or directory
> make: *** [install_config] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.ZLaY0H (%install)
> 
> 
> RPM build errors:
>     Bad exit status from /var/tmp/rpm-tmp.ZLaY0H (%install)
> Build step 'Execute shell' marked build as failure
> Archiving artifacts
> IRC notifier plugin: Sending notification to: #ovirt-jenkins
> IRC notifier plugin: [ERROR] not connected. Cannot send message to
> '#ovirt-jenkins'
> Email was triggered for: Failure
> Sending email for trigger: Failure
> 


From alonbl at redhat.com  Sun Feb  3 19:14:05 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Sun, 3 Feb 2013 14:14:05 -0500 (EST)
Subject: [Engine-devel] [oVirt Jenkins] ovirt-engine_create_rpms - Build
 # 2851 - Still Failing!
In-Reply-To: <1183577484.8409006.1359913079209.JavaMail.root@redhat.com>
Message-ID: <731395842.5766002.1359918845656.JavaMail.root@redhat.com>

Yes.

http://gerrit.ovirt.org/11665

----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>, "Roy Golan" <rgolan at redhat.com>,
> "Yair Zaslavsky" <yzaslavs at redhat.com>, dougsland at redhat.com
> Cc: infra at redhat.com, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, February 3, 2013 7:37:59 PM
> Subject: Re: [oVirt Jenkins] ovirt-engine_create_rpms - Build # 2851 - Still Failing!
> 
> fyi,
> 
> i see ovirt-engine fails to create rpms since build #2846.
> 
> something in manage domains man target maybe?
> 
> 
> "install -m 644 packaging/engine-manage-domains.8
> /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/man/man8/
> install: target
> `/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/man/man8/'
> is not a directory: No such file or directory"
> 
> suspected commit:
> 
> Commit 9171c833e04f486889f7dea8d5e2e3b2dead128b by gerrit2
> engine-manage-domains: Adding man page
> 
> Adding engine-manage-domains.8
> 
> Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=742421
> Change-Id: I26e69ce1410ce1ffd0c8ce242ea519ff3c5daee6
> Signed-off-by: Douglas Schilling Landgraf <dougsland at redhat.com>
> 
> 
> 
> ----- Original Message -----
> > From: "Jenkins oVirt Server" <jenkins at ovirt.org>
> > To: infra at redhat.com, eedri at redhat.com, engine-patches at ovirt.org,
> > oschreib at redhat.com
> > Sent: Sunday, February 3, 2013 6:10:28 PM
> > Subject: [oVirt Jenkins] ovirt-engine_create_rpms - Build # 2851 -
> > Still Failing!
> > 
> > Project: http://jenkins.ovirt.org/job/ovirt-engine_create_rpms/
> > Build: http://jenkins.ovirt.org/job/ovirt-engine_create_rpms/2851/
> > Build Number: 2851
> > Build Status:  Still Failing
> > Triggered By: Started by an SCM change
> > 
> > -------------------------------------
> > Changes Since Last Success:
> > -------------------------------------
> > Changes for Build #2847
> > [gerrit2] db: support absolute log files
> > 
> > [gerrit2] db: do not override log file
> > 
> > 
> > Changes for Build #2848
> > [gerrit2] db: do not override ENGINE_PGPASS if exists
> > 
> > [gerrit2] db: make backup.sh respenct ENGINE_PGPASS
> > 
> > [ahadas] core: minor cleanup
> > 
> > [omasad] core: Fix sql grammar for calculateallstorageusage
> > 
> > [mkublin] engine: Replacing use of Quartz scheduler by ThreadPool
> > during SPM election
> > 
> > [gerrit2] core: handle error when iso domain in maintenance
> > 
> > [gerrit2] core: Enable remove quota when quota is not enforced
> > 
> > [gerrit2] engine-manage-domains: Adding man page
> > 
> > [mkublin] engine: Disable global transaction at
> > ExtendSANStorageDomain
> > 
> > [gerrit2] webadmin: Cleanup of Frontend class
> > 
> > [gerrit2] webadmin: Frontend class formatting
> > 
> > 
> > Changes for Build #2849
> > [mkublin] core: executing squartz job immediately
> > 
> > [mkublin] core: start 'prestarted VMs' immediately after update
> > 
> > [gerrit2] core: Find bugs fix at manage-domains
> > 
> > [gerrit2] core: Fix multiple domains to support useDnsLookup flag
> > 
> > 
> > Changes for Build #2850
> > 
> > Changes for Build #2851
> > [gerrit2] core: use return value instead of a shared boolean in
> > recovery
> > 
> > [gerrit2] core: removal unneeded boolean and finally block from
> > recovery command.
> > 
> > 
> > 
> > 
> > -----------------
> > Failed Tests:
> > -----------------
> > No tests ran.
> > 
> > ------------------
> > Build Log:
> > ------------------
> > [...truncated 34812 lines...]
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/23.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/13.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/27.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/6.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/5.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/15.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/22.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/11.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/4.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/1.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/2.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/7.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/17.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/12.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/ECF0F0A105CE4C7FB1DC3E0A806964A7/19.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/16.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/9.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/20.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/3.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/14.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/24.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/18.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/21.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/26.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/8.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/25.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/10.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/23.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/13.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/27.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/6.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/5.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/15.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/22.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/11.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/4.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/1.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/2.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/7.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/17.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/12.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/876FCB92702D44A392A186EF42C34D5F/19.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/16.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/9.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/20.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/3.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/14.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/24.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/18.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/21.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/26.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/8.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/25.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/10.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/23.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/13.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/27.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/6.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/5.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/15.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/22.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/11.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/4.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/1.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/2.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/7.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/17.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/12.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/560FD90F4DE504399017754A2BE9C471/19.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/16.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/9.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/20.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/3.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/14.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/24.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/18.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/21.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/26.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/8.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/25.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/10.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/23.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/13.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/27.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/6.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/5.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/15.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/22.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/11.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/4.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/1.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/2.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/7.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/17.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/12.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/84A84DD674CFFCED19BA0EA45B9912D4/19.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/16.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/9.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/20.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/3.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/14.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/24.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/18.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/21.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/26.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/8.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/25.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/10.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/23.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/13.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/27.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/6.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/5.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/15.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/22.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/11.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/4.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/1.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/2.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/7.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/17.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/12.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/deferredjs/E672328A3FCA83D2A2C68082504A351E/19.cache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/0F89659FF3F324AE4116F700257E32BD.cache.gif
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/560FD90F4DE504399017754A2BE9C471.cache.html
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_L.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_TL.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_T.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_BL.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_B.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_BR_resize.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_BR.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_TR.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog/panel_edge_R.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/tab_middle_selected.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/login_header_background_repetitive.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/main_tab_middle.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/triangle_down_gray.gif
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/bg_head.gif
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/main_tab_left.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/user_portal_logo.gif
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/tab_arrow_selected.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/main_tab_right.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/tab_left_selected.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/dialog_header_background_repetitive.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console_edit_Disabled.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console_Over.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console_Disabled.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console_edit_Over.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/actions/console_edit.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/general/tvlayout_doubleclick_to_console.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/images/tab_right_selected.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/UserPortal.css
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/13D2931874E71D07F248A0CDF051CC85.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/B32D4EC411D433442835DA919C331C98.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/223E04DC70F69BC559571D1C0E0667E5.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/2533B933CFFB78B592DBDBCE0536FE2D.cache.jpg
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/3C3D8436D91E322D6DA78347F7A6E8A9.cache.gif
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/D24C635030533A63087F7BC81DFBF0D8.cache.jpg
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/84A84DD674CFFCED19BA0EA45B9912D4.cache.html
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/396F806CD63ABD414BFBB9D57429F05B.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/ED39A5380F625072E8B00EB7E6F9C7E3.cache.jpg
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/DF7764EEC1903CD03C9545B354D8D8E4.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E5E3853BCBD97BD21376DF0B1A0D5D7D.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/3E13412DD77AE068AAF96B6978824A75.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/B5AB975C42AA317A66ABE9D0272BBF23.cache.jpg
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/560FD90F4DE504399017754A2BE9C471.gwt.rpc
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/EDC7827FEEA59EE44AD790B1C6430C45.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/876FCB92702D44A392A186EF42C34D5F.gwt.rpc
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/84A84DD674CFFCED19BA0EA45B9912D4.gwt.rpc
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/ECF0F0A105CE4C7FB1DC3E0A806964A7.gwt.rpc
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/2C0E07F73941ECCC3120A2B0311A6773.gwt.rpc
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E44767377485D18D6B6864F65BA8EF73.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/AB196D9D7834625802449A82C5811B43.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/98ED4A36A545561A7B5352F5A5AD1417.cache.jpg
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/2C0E07F73941ECCC3120A2B0311A6773.cache.html
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/C197E274BC03E8EBA72807BD177E913E.cache.jpg
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E0B86FF05CF8354CDDF99499CA94AECB.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E672328A3FCA83D2A2C68082504A351E.gwt.rpc
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/70074615010286B1C1909D4F706884AB.cache.jpg
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E672328A3FCA83D2A2C68082504A351E.cache.html
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/0A9476898799A150D840F0B1C3672921.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/E0CB3A52C74FCDDCDFEB44A221AC3B22.gwt.rpc
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/A893DA4A583734DFC92F6933D2D429EF.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/ECF0F0A105CE4C7FB1DC3E0A806964A7.cache.html
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/clear.cache.gif
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/18E92EC55E78E20DE386EF783EE2E27D.cache.jpg
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/0326AF455425F6065C00E0361659A798.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/8DF1DD9438FB53F1D57718A906429D27.cache.png
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/4CE9178D7E588008F8DAD97784792101.cache.jpg
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/org.ovirt.engine.ui.userportal.UserPortal.nocache.js
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/org.ovirt.engine.ui.userportal.UserPortal/hosted.html
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/META-INF/MANIFEST.MF
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/META-INF/maven/org.ovirt.engine.ui/userportal/pom.xml
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/META-INF/maven/org.ovirt.engine.ui/userportal/pom.properties
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/gwt-extension-3.3.0-SNAPSHOT.jar
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/gwt-servlet-2.3.0.jar
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/lib/frontend-3.3.0-SNAPSHOT.jar
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/WEB-INF/web.xml
> >   inflating:
> >   /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/userportal.war/index.html
> > for artifact_id in  backend bll common compat dal engine-config
> > engine-notifier engine-notifier-resources engine-notifier-service
> > engine-tools-common engineencryptutils interface-common-jaxrs
> > manager manager-modules manager-tools restapi-definition
> > restapi-jaxrs restapi-parent restapi-types root scheduler
> > searchbackend utils vdsbroker ; do \
> > 	POM=`find
> > 	"/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILD/ovirt-engine-3.3.0/tmp.repos"
> > 	-name "${artifact_id}-3.3.0*.pom"`; \
> > 	if ! [ -f "${POM}" ]; then \
> > 		echo "ERROR: Cannot find artifact ${artifact_id}"; \
> > 		exit 1; \
> > 	fi; \
> > 	JAR=`echo "${POM}" | sed 's/\.pom/.jar/'`; \
> > 	install -p -m 644 "${POM}"
> > 	"/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/maven-poms/ovirt-engine-${artifact_id}.pom";
> > 	\
> > 	[ -f "${JAR}" ] && install -p -m 644 "${JAR}"
> > 	"/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/java/ovirt-engine/${artifact_id}.jar";
> > 	\
> > done
> > # Replace jar files in the ear with links to their actuals
> > # locations
> > for jar_line in /usr/share/ovirt-engine/engine.ear/engine-bll,bll
> > /usr/share/ovirt-engine/engine.ear/engine-scheduler,scheduler
> > /usr/share/ovirt-engine/engine.ear/lib/engine-common,common
> > /usr/share/ovirt-engine/engine.ear/lib/engine-compat,compat
> > /usr/share/ovirt-engine/engine.ear/lib/engine-dal,dal
> > /usr/share/ovirt-engine/engine.ear/lib/engine-encryptutils,engineencryptutils
> > /usr/share/ovirt-engine/engine.ear/lib/engine-tools-common,engine-tools-common
> > /usr/share/ovirt-engine/engine.ear/lib/engine-utils,utils
> > /usr/share/ovirt-engine/engine.ear/lib/engine-vdsbroker,vdsbroker
> > /usr/share/ovirt-engine/engine.ear/lib/searchbackend,searchbackend
> > ;
> > do \
> > 	path=`echo ${jar_line} | sed 's/,.*//'`; \
> > 	jar=`echo ${jar_line} | sed 's/.*,//'`; \
> > 	rm -rf
> > 	"/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64${path}"*.jar;
> > 	\
> > 	ln -s "/usr/share/java/ovirt-engine/${jar}.jar"
> > 	"/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64${path}.jar";
> > 	\
> > done
> > sed -i
> > "s/MYVERSION/3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17/"
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/engine.ear/root.war/engineVersion.js
> > *** Deploying engine-config & engine-manage-domains
> > # Configuration files for the configuration tool:
> > install -m 644
> > backend/manager/tools/engine-config/src/main/resources/engine-config.conf
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/etc/ovirt-engine/engine-config/
> > install -m 644
> > backend/manager/tools/engine-config/src/main/resources/engine-config.*properties
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/etc/ovirt-engine/engine-config/
> > install -m 644
> > backend/manager/tools/engine-config/src/main/resources/log4j.xml
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/etc/ovirt-engine/engine-config/
> > # Main program for the configuration tool:
> > install -m 750
> > backend/manager/tools/engine-config/src/main/resources/engine-config
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/bin/engine-config.sh
> > ln -s /usr/share/ovirt-engine/bin/engine-config.sh
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/bin/engine-config
> > # Configuration files for the domain management tool:
> > install -m 644
> > backend/manager/modules/utils/src/main/resources/engine-manage-domains.conf
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/etc/ovirt-engine/engine-manage-domains/
> > install -m 644
> > backend/manager/modules/utils/src/main/resources/engine-manage-domains/log4j.xml
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/etc/ovirt-engine/engine-manage-domains/
> > # Main program for the domain management tool:
> > install -m 750 backend/manager/conf/kerberos/engine-manage-domains
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/ovirt-engine/bin/engine-manage-domains.sh
> > ln -s /usr/share/ovirt-engine/bin/engine-manage-domains.sh
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/bin/engine-manage-domains
> > # Install man pages
> > install -m 644 packaging/engine-manage-domains.8
> > /home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/man/man8/
> > install: target
> > `/home/jenkins/workspace/ovirt-engine_create_rpms/rpmbuild/BUILDROOT/ovirt-engine-3.3.0-0.1.20130203103618.20130203.gitc58bd71.fc17.x86_64/usr/share/man/man8/'
> > is not a directory: No such file or directory
> > make: *** [install_config] Error 1
> > error: Bad exit status from /var/tmp/rpm-tmp.ZLaY0H (%install)
> > 
> > 
> > RPM build errors:
> >     Bad exit status from /var/tmp/rpm-tmp.ZLaY0H (%install)
> > Build step 'Execute shell' marked build as failure
> > Archiving artifacts
> > IRC notifier plugin: Sending notification to: #ovirt-jenkins
> > IRC notifier plugin: [ERROR] not connected. Cannot send message to
> > '#ovirt-jenkins'
> > Email was triggered for: Failure
> > Sending email for trigger: Failure
> > 
> 


From rgolan at redhat.com  Mon Feb  4 07:18:21 2013
From: rgolan at redhat.com (Roy Golan)
Date: Mon, 04 Feb 2013 09:18:21 +0200
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <168595615.5754036.1359897549876.JavaMail.root@redhat.com>
References: <168595615.5754036.1359897549876.JavaMail.root@redhat.com>
Message-ID: <510F60BD.1070609@redhat.com>

On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
>
> ----- Original Message -----
>> From: "Omer Frenkel" <ofrenkel at redhat.com>
>> To: "Michael Kublin" <mkublin at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, February 3, 2013 3:12:19 PM
>> Subject: Re: [Engine-devel] Guid & NGuid
>>
>>
>>
>> ----- Original Message -----
>>> From: "Michael Kublin" <mkublin at redhat.com>
>>> To: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Sunday, February 3, 2013 3:10:14 PM
>>> Subject: [Engine-devel] Guid & NGuid
>>>
>>> Hi,
>>>
>>> In ovirt-engine code we have Guid and NGuid objects.
>>> Guid is extends NGuid and also NGuid class has method getValue()
>>> which should return Guid.
>>> As for me these two classes are look like the same and I don't see
>>> to
>>> much differences between them.
>>> My proposal is to remove NGuid and move it functionality to Guid
>>> (Because of Guid is much more common)
>>>
>> i agree, but we need to take another step forward and allow Guid to
>> be null (as it should)
>> and not assume its EMPTY or have a value (i'm pretty sure we have
>> this assumption in many places)
> Hi,
>
> And for the new people out here... why not kill both and use plain standard java UUID[1]?
+1 for using java.util.UUID

NGuid functionality that should be extracted during the refactor is -
1. refactor DB and Java so empty or null return values are null and not 
EMPTY_GUID
2. the special constructor of NGuid for UUID return by Microsoft AD 
should be extracted to a factory/utility
> I think we should kill compat, I don't see any value in fixing anything about it while leaving it intact.
>
> Regards,
> Alon Bar-Lev.
>
> [1] http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From mkublin at redhat.com  Mon Feb  4 07:47:29 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Mon, 4 Feb 2013 02:47:29 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <510F60BD.1070609@redhat.com>
Message-ID: <130496987.12821082.1359964049330.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Roy Golan" <rgolan at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, February 4, 2013 9:18:21 AM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> >
> > ----- Original Message -----
> >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> >> To: "Michael Kublin" <mkublin at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Sunday, February 3, 2013 3:12:19 PM
> >> Subject: Re: [Engine-devel] Guid & NGuid
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Michael Kublin" <mkublin at redhat.com>
> >>> To: "engine-devel" <engine-devel at ovirt.org>
> >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> >>> Subject: [Engine-devel] Guid & NGuid
> >>>
> >>> Hi,
> >>>
> >>> In ovirt-engine code we have Guid and NGuid objects.
> >>> Guid is extends NGuid and also NGuid class has method getValue()
> >>> which should return Guid.
> >>> As for me these two classes are look like the same and I don't
> >>> see
> >>> to
> >>> much differences between them.
> >>> My proposal is to remove NGuid and move it functionality to Guid
> >>> (Because of Guid is much more common)
> >>>
> >> i agree, but we need to take another step forward and allow Guid
> >> to
> >> be null (as it should)
> >> and not assume its EMPTY or have a value (i'm pretty sure we have
> >> this assumption in many places)
> > Hi,
> >
> > And for the new people out here... why not kill both and use plain
> > standard java UUID[1]?
> +1 for using java.util.UUID
> 
> NGuid functionality that should be extracted during the refactor is -
> 1. refactor DB and Java so empty or null return values are null and
> not
> EMPTY_GUID
> 2. the special constructor of NGuid for UUID return by Microsoft AD
> should be extracted to a factory/utility
> > I think we should kill compat, I don't see any value in fixing
> > anything about it while leaving it intact.
> >
> > Regards,
> > Alon Bar-Lev.
> >
> > [1] http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
Actually there is exists one reason not to use directly UUID at server side.
The main operations on Guid today it is to convert object to Guid or Guid to string.
Guid it is immutable object, number of Guids is limited and almost never changed,
These sound like classical case for object that can be cached. 
Benefit - reduced number of string manipulations, reduced number of created instances, less work 
for garbage collection






From yzaslavs at redhat.com  Mon Feb  4 07:50:28 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 4 Feb 2013 02:50:28 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <510F60BD.1070609@redhat.com>
Message-ID: <1875955634.20193541.1359964228745.JavaMail.root@redhat.com>

Bare in mind there is some functionality about "byte reordering" of the GUID - if NGUID and GUID are to be removed,
we should move this functionality to a utils class.


----- Original Message -----
> From: "Roy Golan" <rgolan at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, February 4, 2013 9:18:21 AM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> >
> > ----- Original Message -----
> >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> >> To: "Michael Kublin" <mkublin at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Sunday, February 3, 2013 3:12:19 PM
> >> Subject: Re: [Engine-devel] Guid & NGuid
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Michael Kublin" <mkublin at redhat.com>
> >>> To: "engine-devel" <engine-devel at ovirt.org>
> >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> >>> Subject: [Engine-devel] Guid & NGuid
> >>>
> >>> Hi,
> >>>
> >>> In ovirt-engine code we have Guid and NGuid objects.
> >>> Guid is extends NGuid and also NGuid class has method getValue()
> >>> which should return Guid.
> >>> As for me these two classes are look like the same and I don't
> >>> see
> >>> to
> >>> much differences between them.
> >>> My proposal is to remove NGuid and move it functionality to Guid
> >>> (Because of Guid is much more common)
> >>>
> >> i agree, but we need to take another step forward and allow Guid
> >> to
> >> be null (as it should)
> >> and not assume its EMPTY or have a value (i'm pretty sure we have
> >> this assumption in many places)
> > Hi,
> >
> > And for the new people out here... why not kill both and use plain
> > standard java UUID[1]?
> +1 for using java.util.UUID
> 
> NGuid functionality that should be extracted during the refactor is -
> 1. refactor DB and Java so empty or null return values are null and
> not
> EMPTY_GUID
> 2. the special constructor of NGuid for UUID return by Microsoft AD
> should be extracted to a factory/utility
> > I think we should kill compat, I don't see any value in fixing
> > anything about it while leaving it intact.
> >
> > Regards,
> > Alon Bar-Lev.
> >
> > [1] http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Mon Feb  4 07:51:39 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Mon, 4 Feb 2013 02:51:39 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <130496987.12821082.1359964049330.JavaMail.root@redhat.com>
Message-ID: <1134778599.20193825.1359964299198.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, February 4, 2013 9:47:29 AM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> 
> 
> ----- Original Message -----
> > From: "Roy Golan" <rgolan at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, February 4, 2013 9:18:21 AM
> > Subject: Re: [Engine-devel] Guid & NGuid
> > 
> > On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> > >
> > > ----- Original Message -----
> > >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > >> To: "Michael Kublin" <mkublin at redhat.com>
> > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > >> Subject: Re: [Engine-devel] Guid & NGuid
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Michael Kublin" <mkublin at redhat.com>
> > >>> To: "engine-devel" <engine-devel at ovirt.org>
> > >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> > >>> Subject: [Engine-devel] Guid & NGuid
> > >>>
> > >>> Hi,
> > >>>
> > >>> In ovirt-engine code we have Guid and NGuid objects.
> > >>> Guid is extends NGuid and also NGuid class has method
> > >>> getValue()
> > >>> which should return Guid.
> > >>> As for me these two classes are look like the same and I don't
> > >>> see
> > >>> to
> > >>> much differences between them.
> > >>> My proposal is to remove NGuid and move it functionality to
> > >>> Guid
> > >>> (Because of Guid is much more common)
> > >>>
> > >> i agree, but we need to take another step forward and allow Guid
> > >> to
> > >> be null (as it should)
> > >> and not assume its EMPTY or have a value (i'm pretty sure we
> > >> have
> > >> this assumption in many places)
> > > Hi,
> > >
> > > And for the new people out here... why not kill both and use
> > > plain
> > > standard java UUID[1]?
> > +1 for using java.util.UUID
> > 
> > NGuid functionality that should be extracted during the refactor is
> > -
> > 1. refactor DB and Java so empty or null return values are null and
> > not
> > EMPTY_GUID
> > 2. the special constructor of NGuid for UUID return by Microsoft AD
> > should be extracted to a factory/utility
> > > I think we should kill compat, I don't see any value in fixing
> > > anything about it while leaving it intact.
> > >
> > > Regards,
> > > Alon Bar-Lev.
> > >
> > > [1] http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> Actually there is exists one reason not to use directly UUID at
> server side.
> The main operations on Guid today it is to convert object to Guid or
> Guid to string.
> Guid it is immutable object, number of Guids is limited and almost
> never changed,
> These sound like classical case for object that can be cached.
> Benefit - reduced number of string manipulations, reduced number of
> created instances, less work
> for garbage collection
Ok, but this functionality does not exist (yet :) )

> 
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lhornyak at redhat.com  Mon Feb  4 07:56:28 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 4 Feb 2013 02:56:28 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <130496987.12821082.1359964049330.JavaMail.root@redhat.com>
Message-ID: <925438760.9020537.1359964588315.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, February 4, 2013 8:47:29 AM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> 
> 
> ----- Original Message -----
> > From: "Roy Golan" <rgolan at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, February 4, 2013 9:18:21 AM
> > Subject: Re: [Engine-devel] Guid & NGuid
> > 
> > On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> > >
> > > ----- Original Message -----
> > >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > >> To: "Michael Kublin" <mkublin at redhat.com>
> > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > >> Subject: Re: [Engine-devel] Guid & NGuid
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Michael Kublin" <mkublin at redhat.com>
> > >>> To: "engine-devel" <engine-devel at ovirt.org>
> > >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> > >>> Subject: [Engine-devel] Guid & NGuid
> > >>>
> > >>> Hi,
> > >>>
> > >>> In ovirt-engine code we have Guid and NGuid objects.
> > >>> Guid is extends NGuid and also NGuid class has method
> > >>> getValue()
> > >>> which should return Guid.
> > >>> As for me these two classes are look like the same and I don't
> > >>> see
> > >>> to
> > >>> much differences between them.
> > >>> My proposal is to remove NGuid and move it functionality to
> > >>> Guid
> > >>> (Because of Guid is much more common)
> > >>>
> > >> i agree, but we need to take another step forward and allow Guid
> > >> to
> > >> be null (as it should)
> > >> and not assume its EMPTY or have a value (i'm pretty sure we
> > >> have
> > >> this assumption in many places)
> > > Hi,
> > >
> > > And for the new people out here... why not kill both and use
> > > plain
> > > standard java UUID[1]?
> > +1 for using java.util.UUID
> > 
> > NGuid functionality that should be extracted during the refactor is
> > -
> > 1. refactor DB and Java so empty or null return values are null and
> > not
> > EMPTY_GUID
> > 2. the special constructor of NGuid for UUID return by Microsoft AD
> > should be extracted to a factory/utility
> > > I think we should kill compat, I don't see any value in fixing
> > > anything about it while leaving it intact.
> > >
> > > Regards,
> > > Alon Bar-Lev.
> > >
> > > [1] http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> Actually there is exists one reason not to use directly UUID at
> server side.
> The main operations on Guid today it is to convert object to Guid or
> Guid to string.
> Guid it is immutable object, number of Guids is limited and almost
> never changed,
> These sound like classical case for object that can be cached.
> Benefit - reduced number of string manipulations, reduced number of
> created instances, less work
> for garbage collection

UUID has the same properties, it is immutable. So you could do the same with UUID, but I am not sure you could effectively cache these objects and prove that you are saving either CPU, heap, or GC time.

> 
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkublin at redhat.com  Mon Feb  4 08:15:41 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Mon, 4 Feb 2013 03:15:41 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <925438760.9020537.1359964588315.JavaMail.root@redhat.com>
Message-ID: <1495460570.12828431.1359965741637.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, February 4, 2013 9:56:28 AM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, February 4, 2013 8:47:29 AM
> > Subject: Re: [Engine-devel] Guid & NGuid
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Roy Golan" <rgolan at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Monday, February 4, 2013 9:18:21 AM
> > > Subject: Re: [Engine-devel] Guid & NGuid
> > > 
> > > On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> > > >
> > > > ----- Original Message -----
> > > >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > >> To: "Michael Kublin" <mkublin at redhat.com>
> > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > >>
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Michael Kublin" <mkublin at redhat.com>
> > > >>> To: "engine-devel" <engine-devel at ovirt.org>
> > > >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> > > >>> Subject: [Engine-devel] Guid & NGuid
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> In ovirt-engine code we have Guid and NGuid objects.
> > > >>> Guid is extends NGuid and also NGuid class has method
> > > >>> getValue()
> > > >>> which should return Guid.
> > > >>> As for me these two classes are look like the same and I
> > > >>> don't
> > > >>> see
> > > >>> to
> > > >>> much differences between them.
> > > >>> My proposal is to remove NGuid and move it functionality to
> > > >>> Guid
> > > >>> (Because of Guid is much more common)
> > > >>>
> > > >> i agree, but we need to take another step forward and allow
> > > >> Guid
> > > >> to
> > > >> be null (as it should)
> > > >> and not assume its EMPTY or have a value (i'm pretty sure we
> > > >> have
> > > >> this assumption in many places)
> > > > Hi,
> > > >
> > > > And for the new people out here... why not kill both and use
> > > > plain
> > > > standard java UUID[1]?
> > > +1 for using java.util.UUID
> > > 
> > > NGuid functionality that should be extracted during the refactor
> > > is
> > > -
> > > 1. refactor DB and Java so empty or null return values are null
> > > and
> > > not
> > > EMPTY_GUID
> > > 2. the special constructor of NGuid for UUID return by Microsoft
> > > AD
> > > should be extracted to a factory/utility
> > > > I think we should kill compat, I don't see any value in fixing
> > > > anything about it while leaving it intact.
> > > >
> > > > Regards,
> > > > Alon Bar-Lev.
> > > >
> > > > [1]
> > > > http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> > Actually there is exists one reason not to use directly UUID at
> > server side.
> > The main operations on Guid today it is to convert object to Guid
> > or
> > Guid to string.
> > Guid it is immutable object, number of Guids is limited and almost
> > never changed,
> > These sound like classical case for object that can be cached.
> > Benefit - reduced number of string manipulations, reduced number of
> > created instances, less work
> > for garbage collection
> 
> UUID has the same properties, it is immutable. So you could do the
> same with UUID, but I am not sure you could effectively cache these
> objects and prove that you are saving either CPU, heap, or GC time.
These is a very common pattern: 
1) implementation of valueOf() for most classes like Integer, Double, etc... has some kind of cache.
2) JVM has cache for strings that can be used and that cache can be tweaked by some JVM opts.
3) Most of our operations is perform query on DB, send request to host or parse response from host and Guid
   is very common object that is immutable.
I am agree that these will not solve all our performance problems but can provide some benefit, especially when it is very easy 
to implement. 




From iheim at redhat.com  Mon Feb  4 08:51:10 2013
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 04 Feb 2013 10:51:10 +0200
Subject: [Engine-devel] How to show our VM template from web protal?
In-Reply-To: <C5A0092C63E939488005F15F736A811209787689@SHSMSX101.ccr.corp.intel.com>
References: <C5A0092C63E939488005F15F736A811209787689@SHSMSX101.ccr.corp.intel.com>
Message-ID: <510F767E.9090104@redhat.com>

On 01/02/2013 11:31, Chen, Wei D wrote:
> Hi,
>
> We are trying to create a VM template which is similar with "blank template" and hope to display this template on web portal, our consideration is simple, that is, just execute "InsertVmTemplate"
> procedure manually and expect our template would be showed from web portal. Unfortunately, there is no changes seen from portal even after restarting engine service.
> Definitely, we must miss something, would you anyone input any suggestion, any feedback is great appreciated. thanks in advance!

the supported way of creating a template is to stand on a VM and click 
'make template'.
(as normally, templates have disks in them, though not mandatory).



From mkolesni at redhat.com  Mon Feb  4 09:48:45 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Mon, 4 Feb 2013 04:48:45 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <1495460570.12828431.1359965741637.JavaMail.root@redhat.com>
Message-ID: <661228268.12906383.1359971325271.JavaMail.root@redhat.com>

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, February 4, 2013 9:56:28 AM
> > Subject: Re: [Engine-devel] Guid & NGuid
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Michael Kublin" <mkublin at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > Subject: Re: [Engine-devel] Guid & NGuid
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Roy Golan" <rgolan at redhat.com>
> > > > To: engine-devel at ovirt.org
> > > > Sent: Monday, February 4, 2013 9:18:21 AM
> > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > 
> > > > On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> > > > >
> > > > > ----- Original Message -----
> > > > >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > >> To: "Michael Kublin" <mkublin at redhat.com>
> > > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > > >>
> > > > >>
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>> From: "Michael Kublin" <mkublin at redhat.com>
> > > > >>> To: "engine-devel" <engine-devel at ovirt.org>
> > > > >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> > > > >>> Subject: [Engine-devel] Guid & NGuid
> > > > >>>
> > > > >>> Hi,
> > > > >>>
> > > > >>> In ovirt-engine code we have Guid and NGuid objects.
> > > > >>> Guid is extends NGuid and also NGuid class has method
> > > > >>> getValue()
> > > > >>> which should return Guid.
> > > > >>> As for me these two classes are look like the same and I
> > > > >>> don't
> > > > >>> see
> > > > >>> to
> > > > >>> much differences between them.
> > > > >>> My proposal is to remove NGuid and move it functionality to
> > > > >>> Guid
> > > > >>> (Because of Guid is much more common)
> > > > >>>
> > > > >> i agree, but we need to take another step forward and allow
> > > > >> Guid
> > > > >> to
> > > > >> be null (as it should)
> > > > >> and not assume its EMPTY or have a value (i'm pretty sure we
> > > > >> have
> > > > >> this assumption in many places)
> > > > > Hi,
> > > > >
> > > > > And for the new people out here... why not kill both and use
> > > > > plain
> > > > > standard java UUID[1]?
> > > > +1 for using java.util.UUID
> > > > 
> > > > NGuid functionality that should be extracted during the
> > > > refactor
> > > > is
> > > > -
> > > > 1. refactor DB and Java so empty or null return values are null
> > > > and
> > > > not
> > > > EMPTY_GUID
> > > > 2. the special constructor of NGuid for UUID return by
> > > > Microsoft
> > > > AD
> > > > should be extracted to a factory/utility
> > > > > I think we should kill compat, I don't see any value in
> > > > > fixing
> > > > > anything about it while leaving it intact.
> > > > >
> > > > > Regards,
> > > > > Alon Bar-Lev.
> > > > >
> > > > > [1]
> > > > > http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> > > Actually there is exists one reason not to use directly UUID at
> > > server side.
> > > The main operations on Guid today it is to convert object to Guid
> > > or
> > > Guid to string.
> > > Guid it is immutable object, number of Guids is limited and
> > > almost
> > > never changed,
> > > These sound like classical case for object that can be cached.
> > > Benefit - reduced number of string manipulations, reduced number
> > > of
> > > created instances, less work
> > > for garbage collection
> > 
> > UUID has the same properties, it is immutable. So you could do the
> > same with UUID, but I am not sure you could effectively cache these
> > objects and prove that you are saving either CPU, heap, or GC time.
> These is a very common pattern:
> 1) implementation of valueOf() for most classes like Integer, Double,
> etc... has some kind of cache.
> 2) JVM has cache for strings that can be used and that cache can be
> tweaked by some JVM opts.
> 3) Most of our operations is perform query on DB, send request to
> host or parse response from host and Guid
>    is very common object that is immutable.
> I am agree that these will not solve all our performance problems but
> can provide some benefit, especially when it is very easy
> to implement.

We could still achieve that using a UUIDCreator class and call it instead of Guid.fromString("")..

Whether this is cached or not is another question which can be solved later and checked to see if the cache improves performance or not.

> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From wei.d.chen at intel.com  Mon Feb  4 09:49:33 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Mon, 4 Feb 2013 09:49:33 +0000
Subject: [Engine-devel] How to show our VM template from web protal?
In-Reply-To: <510F767E.9090104@redhat.com>
References: <C5A0092C63E939488005F15F736A811209787689@SHSMSX101.ccr.corp.intel.com>
	<510F767E.9090104@redhat.com>
Message-ID: <C5A0092C63E939488005F15F736A81120978A933@SHSMSX101.ccr.corp.intel.com>

Thanks Itamar. Of course, we can create a VM template by clicking 'make template' button. What we want to do is create a VM template contains some customized parameters which are not currently supported by web portal, so, we expect to create the template by executing some DB procedure, like " InsertVmTemplate ". The result is this template could be created in DB but cannot be showed from web portal. Thanks.


Best Regards,
Dave Chen


> -----Original Message-----
> From: Itamar Heim [mailto:iheim at redhat.com]
> Sent: Monday, February 04, 2013 4:51 PM
> To: Chen, Wei D
> Cc: engine-devel; Liu, DanqingX
> Subject: Re: [Engine-devel] How to show our VM template from web protal?
> 
> On 01/02/2013 11:31, Chen, Wei D wrote:
> > Hi,
> >
> > We are trying to create a VM template which is similar with "blank template"
> and hope to display this template on web portal, our consideration is simple,
> that is, just execute "InsertVmTemplate"
> > procedure manually and expect our template would be showed from web
> portal. Unfortunately, there is no changes seen from portal even after
> restarting engine service.
> > Definitely, we must miss something, would you anyone input any suggestion,
> any feedback is great appreciated. thanks in advance!
> 
> the supported way of creating a template is to stand on a VM and click 'make
> template'.
> (as normally, templates have disks in them, though not mandatory).



From ofrenkel at redhat.com  Mon Feb  4 09:57:02 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Mon, 4 Feb 2013 04:57:02 -0500 (EST)
Subject: [Engine-devel] How to show our VM template from web protal?
In-Reply-To: <C5A0092C63E939488005F15F736A81120978A933@SHSMSX101.ccr.corp.intel.com>
Message-ID: <773333104.16254455.1359971822934.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Wei D Chen" <wei.d.chen at intel.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, February 4, 2013 11:49:33 AM
> Subject: Re: [Engine-devel] How to show our VM template from web protal?
> 
> Thanks Itamar. Of course, we can create a VM template by clicking
> 'make template' button. What we want to do is create a VM template
> contains some customized parameters which are not currently
> supported by web portal, so, we expect to create the template by
> executing some DB procedure, like " InsertVmTemplate ". The result
> is this template could be created in DB but cannot be showed from
> web portal. Thanks.
> 

you can't see it also in the web admin portal or just user portal?
my guess is that you are missing a permission for it (check permissions table - object id is the template id, object type for template is 4)

> 
> Best Regards,
> Dave Chen
> 
> 
> > -----Original Message-----
> > From: Itamar Heim [mailto:iheim at redhat.com]
> > Sent: Monday, February 04, 2013 4:51 PM
> > To: Chen, Wei D
> > Cc: engine-devel; Liu, DanqingX
> > Subject: Re: [Engine-devel] How to show our VM template from web
> > protal?
> > 
> > On 01/02/2013 11:31, Chen, Wei D wrote:
> > > Hi,
> > >
> > > We are trying to create a VM template which is similar with
> > > "blank template"
> > and hope to display this template on web portal, our consideration
> > is simple,
> > that is, just execute "InsertVmTemplate"
> > > procedure manually and expect our template would be showed from
> > > web
> > portal. Unfortunately, there is no changes seen from portal even
> > after
> > restarting engine service.
> > > Definitely, we must miss something, would you anyone input any
> > > suggestion,
> > any feedback is great appreciated. thanks in advance!
> > 
> > the supported way of creating a template is to stand on a VM and
> > click 'make
> > template'.
> > (as normally, templates have disks in them, though not mandatory).
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From tjelinek at redhat.com  Mon Feb  4 11:08:37 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Mon, 4 Feb 2013 06:08:37 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <1626736553.8334443.1359556002148.JavaMail.root@redhat.com>
Message-ID: <1480221331.10050512.1359976117465.JavaMail.root@redhat.com>

So, I had a discussion with Laszlo. Long story short, the question is:
@Andrew: Is the more basic use case to select the Template or to select the Instance Type + Image? Why?

We need to decide it because the more basic UC should be in basic view and the less one in advanced (after clicking "show advanced options" button).

The concern is, that the HW is anyhow configured to serve the SW so it, in most cases of private cloud, does not make sense to
split them. So the user will have to select two combo boxes instead of one with no added value (e.g. RHEL63-instance + RHEL64-image).

I understand that the advantage of having the HW and SW profile separated is that you can update the HW of all VMs created from it. 
But is this the basic UC or the advanced one?

Thank you,
Tomas

----- Original Message -----
From: "Tomas Jelinek" <tjelinek at redhat.com>
To: "Laszlo Hornyak" <lhornyak at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Wednesday, January 30, 2013 3:26:42 PM
Subject: Re: [Engine-devel] Instance Types Feature

> A hidden feature is a not existing feature :)
Well, the "hide" was not a correct term :) 

But where would you put it? I see the following options:
1: To the basic screen (but a bit confusing as there will be instance type and image and this dialog should be as simple as possible)
2: To the advanced screen (let's not call it hide but make it an advanced option:) )
3: Do not add it at all (worst case)

I suppose that add it to simple screen and put the Instance type and Image to the advanced one is not really an option as the main point of
this feature is to actually introduce the instance types as a more convenient way of configuring the VM's HW decoupled from SW.

What do you think? Do you see any other ways? I would say that the second possibility is not bad...

Thank you,
Tomas

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Wednesday, January 30, 2013 11:24:52 AM
Subject: Re: [Engine-devel]  Instance Types Feature

A hidden feature is a not existing feature :)

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 8:30:26 AM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> > Of course after introducing the instance type in ovirt, you will
> > still have control over the instance types and create any instance
> > type you like beyond the pre-defined types you have in public
> > cloud, but you
> > will have two things to set: the instance type and the image, which
> > is more administration...
> You will still have the templates - you will be able to choose a
> template which defines both. But it will be "hidden" in advanced
> part of the dialog.
> You are right, the simple way is pretty much inspired by public
> clouds, because they do great job in making the things easy. You
> basically just say you want a small machine and attach a rhel image
> to it.
> Other advantage of separating the HW and SW configuration is that you
> can just change the HW profile (instance type) on which you are
> running, or, if the instance type changes, it gets reflected in all
> machines using this instance type.
> 
> > This is why I think keeping the template as an entity composed out
> > of an image and a instance type would be great.
> yep, it seems we will keep it :) It just will be hidden in the
> advanced options (e.g. one more click). Sounds reasonable?
> 
> ----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, January 28, 2013 12:16:00 PM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> hi,
> 
> This is what I thought of:
> 
> In public clouds it is common to have pre-defined instance types e.g.
> amazon small/medium/large/x-large instance, and this is what
> customers get even if they don't like it. I guess this helps Amazon
> a lot to simplify the decision logic for vm scheduling and pricing.
> 
> In a private cloud, you choose the resources your application needs,
> therefore you can choose just as much as you need.
> 
> Of course after introducing the instance type in ovirt, you will
> still have control over the instance types and create any instance
> type you like beyond the pre-defined types you have in public cloud,
> but you will have two things to set: the instance type and the
> image, which is more administration than just working with
> templates, while most of the cases the templates were enough: you
> created both the OS image and the virtual hardware profile it is
> running on. For another image and another workload, I would most
> likely want to create another one that just fits the needs.
> 
> This is why I think keeping the template as an entity composed out of
> an image and a instance type would be great.
> 
> Laszlo
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Friday, January 25, 2013 1:32:20 PM
> > Subject: Re: [Engine-devel]  Instance Types Feature
> > 
> > Hi Laszlo,
> > 
> > it is not useful just for public clouds - it can be pretty useful
> > for
> > private as well. But to keep the previous way, it could be done
> > this
> > way:
> > - on the advanced screen (after clicking "show advanced options"
> > you
> > can specify the template)
> > - by default you pick on basic view the instance type (e.g. HW
> > profile) and the Image (e.g. disk with some metadata such as OS
> > type). But, you can select custom instance type (equivalent to
> >  blank template) and no Image. In this case the template appears
> > also on basic view and you can select it.
> > 
> > What do you think?
> > 
> > Tomas
> > 
> > ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, January 22, 2013 7:16:32 PM
> > Subject: Re: [Engine-devel]  Instance Types Feature
> > 
> > Hi Tomas,
> > 
> > I like the idea in general, but for me the instance types looks
> > like
> > a feature that is typical in public clouds, while in private clouds
> > it looks more like a cool extra feature for special cases.
> > Therefore
> > in my opinion it would be great to keep the old template solution
> > as
> > well to keep it simple for most users. A template could be an
> > instance type and an image together. Only the description overlap,
> > and that could be solved.
> > 
> > Thanks,
> > Laszlo
> > 
> > ----- Original Message -----
> > > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Tuesday, January 22, 2013 3:09:51 PM
> > > Subject: [Engine-devel]  Instance Types Feature
> > > 
> > > Hi All,
> > > 
> > > this is the proposed new feature called instance types:
> > > http://www.ovirt.org/Features/Instance_Types
> > > 
> > > Long story short - it should basically split the VM template
> > > into:
> > > - "hardware profile" called instance types
> > > - "software profile" called image
> > > 
> > > This should enable to do something like: Create a new "small" VM
> > > and
> > > attach a disk with "RHEL + Postgres" installed.
> > > 
> > > Any comments are more than welcome!
> > > 
> > > Tomas
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From mkublin at redhat.com  Mon Feb  4 12:15:40 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Mon, 4 Feb 2013 07:15:40 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <661228268.12906383.1359971325271.JavaMail.root@redhat.com>
Message-ID: <1125599488.12957748.1359980140387.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, February 4, 2013 11:48:45 AM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > To: "Michael Kublin" <mkublin at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, February 4, 2013 9:56:28 AM
> > > Subject: Re: [Engine-devel] Guid & NGuid
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > To: engine-devel at ovirt.org
> > > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Roy Golan" <rgolan at redhat.com>
> > > > > To: engine-devel at ovirt.org
> > > > > Sent: Monday, February 4, 2013 9:18:21 AM
> > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > 
> > > > > On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> > > > > >
> > > > > > ----- Original Message -----
> > > > > >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > >> To: "Michael Kublin" <mkublin at redhat.com>
> > > > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> ----- Original Message -----
> > > > > >>> From: "Michael Kublin" <mkublin at redhat.com>
> > > > > >>> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> > > > > >>> Subject: [Engine-devel] Guid & NGuid
> > > > > >>>
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>> In ovirt-engine code we have Guid and NGuid objects.
> > > > > >>> Guid is extends NGuid and also NGuid class has method
> > > > > >>> getValue()
> > > > > >>> which should return Guid.
> > > > > >>> As for me these two classes are look like the same and I
> > > > > >>> don't
> > > > > >>> see
> > > > > >>> to
> > > > > >>> much differences between them.
> > > > > >>> My proposal is to remove NGuid and move it functionality
> > > > > >>> to
> > > > > >>> Guid
> > > > > >>> (Because of Guid is much more common)
> > > > > >>>
> > > > > >> i agree, but we need to take another step forward and
> > > > > >> allow
> > > > > >> Guid
> > > > > >> to
> > > > > >> be null (as it should)
> > > > > >> and not assume its EMPTY or have a value (i'm pretty sure
> > > > > >> we
> > > > > >> have
> > > > > >> this assumption in many places)
> > > > > > Hi,
> > > > > >
> > > > > > And for the new people out here... why not kill both and
> > > > > > use
> > > > > > plain
> > > > > > standard java UUID[1]?
> > > > > +1 for using java.util.UUID
> > > > > 
> > > > > NGuid functionality that should be extracted during the
> > > > > refactor
> > > > > is
> > > > > -
> > > > > 1. refactor DB and Java so empty or null return values are
> > > > > null
> > > > > and
> > > > > not
> > > > > EMPTY_GUID
> > > > > 2. the special constructor of NGuid for UUID return by
> > > > > Microsoft
> > > > > AD
> > > > > should be extracted to a factory/utility
> > > > > > I think we should kill compat, I don't see any value in
> > > > > > fixing
> > > > > > anything about it while leaving it intact.
> > > > > >
> > > > > > Regards,
> > > > > > Alon Bar-Lev.
> > > > > >
> > > > > > [1]
> > > > > > http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> > > > Actually there is exists one reason not to use directly UUID at
> > > > server side.
> > > > The main operations on Guid today it is to convert object to
> > > > Guid
> > > > or
> > > > Guid to string.
> > > > Guid it is immutable object, number of Guids is limited and
> > > > almost
> > > > never changed,
> > > > These sound like classical case for object that can be cached.
> > > > Benefit - reduced number of string manipulations, reduced
> > > > number
> > > > of
> > > > created instances, less work
> > > > for garbage collection
> > > 
> > > UUID has the same properties, it is immutable. So you could do
> > > the
> > > same with UUID, but I am not sure you could effectively cache
> > > these
> > > objects and prove that you are saving either CPU, heap, or GC
> > > time.
> > These is a very common pattern:
> > 1) implementation of valueOf() for most classes like Integer,
> > Double,
> > etc... has some kind of cache.
> > 2) JVM has cache for strings that can be used and that cache can be
> > tweaked by some JVM opts.
> > 3) Most of our operations is perform query on DB, send request to
> > host or parse response from host and Guid
> >    is very common object that is immutable.
> > I am agree that these will not solve all our performance problems
> > but
> > can provide some benefit, especially when it is very easy
> > to implement.
> 
> We could still achieve that using a UUIDCreator class and call it
> instead of Guid.fromString("")..
> 
> Whether this is cached or not is another question which can be solved
> later and checked to see if the cache improves performance or not.
These is already implementation, if it will be Guid.fromString("") or 
UUIDCreator.
The issue is if we want to use cache, it should be implemented together
with deleting/replacing of Guid/NGuid , because of it much more easilly


From lhornyak at redhat.com  Mon Feb  4 13:07:03 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 4 Feb 2013 08:07:03 -0500 (EST)
Subject: [Engine-devel] Time for Spring?
In-Reply-To: <5107A79B.4070708@redhat.com>
Message-ID: <2066633252.9094534.1359983223438.JavaMail.root@redhat.com>

I have seen a CDI patch from Roy that may be related to the topic.

I do not know what the general direction is. CDI is "more standard", while it's implementations for me look heavy weight and difficult to port to small containers like tomcat or jetty.

In general, now we only inject the Backend deathstar bean to wherever it is needed and then it is used as registry for other service objects and DAOs.

With spring dependency injection, we could be more independent from the container, since the ioC container is comming with us to the app container. But at the other hand, ovirt is a nice big ear app, so how would you put it together as a spring app? What changes would this need?

Laszlo

----- Original Message -----
> From: "Libor Spevak" <lspevak at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, January 29, 2013 11:42:35 AM
> Subject: [Engine-devel] Time for Spring?
> 
> Hi,
> 
> it is rather cold in Europe, but can I ask, what's the current
> opinion
> or plans about "full" integration of Spring Framework into oVirt
> engine
> (Backend)?
> 
> This is a commonly accepted integration framework among Java
> programmers
> and industry standard, which
> solves many pains from small to large projects. And can lead to a
> better
> understanding of the program.
> 
> There are several Spring dependencies inside oVirt project, but
> mostly
> for LDAP and database communication (JDBC template).
> 
> Still missing (sorry, looks like marketing, but..):
> 
> - dependency injection
> - aspect-oriented programming (AOP)
> - enterprise integration patterns
> 
> Is something true? :-)
> 
> 1. We tried, but it is too large and overcomplicated, it can be
> solved
> better way for the project purpose
> 2. We tried, but we think, we need just e.g. JDBC, LDAP layer covered
> now
> 3. We would like to integrate with e.g. Hibernate soon, EJB,
> remoting,
> unit tests, integration tests, ... , probably we will need it soon
> 4. We understand and need dependency injection, but there are other
> light DI containers (Pico, Guice, JBoss Seam).
> etc.
> 
> Still, I think there is strong potential, probably not clear today.
> We
> cannot avoid Guice on frontend side because of GWTP, but the backend
> lacks something.
> Or not?
> 
> Thanks.
> 
> Regards,
> Libor
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From alonbl at redhat.com  Mon Feb  4 14:17:39 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Mon, 4 Feb 2013 09:17:39 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <1125599488.12957748.1359980140387.JavaMail.root@redhat.com>
Message-ID: <1138738443.5890952.1359987459619.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Monday, February 4, 2013 2:15:40 PM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> 
> 
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, February 4, 2013 11:48:45 AM
> > Subject: Re: [Engine-devel] Guid & NGuid
> > 
> > ----- Original Message -----
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Monday, February 4, 2013 9:56:28 AM
> > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > > To: engine-devel at ovirt.org
> > > > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Roy Golan" <rgolan at redhat.com>
> > > > > > To: engine-devel at ovirt.org
> > > > > > Sent: Monday, February 4, 2013 9:18:21 AM
> > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > 
> > > > > > On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > > >> To: "Michael Kublin" <mkublin at redhat.com>
> > > > > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > > > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> ----- Original Message -----
> > > > > > >>> From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > >>> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> > > > > > >>> Subject: [Engine-devel] Guid & NGuid
> > > > > > >>>
> > > > > > >>> Hi,
> > > > > > >>>
> > > > > > >>> In ovirt-engine code we have Guid and NGuid objects.
> > > > > > >>> Guid is extends NGuid and also NGuid class has method
> > > > > > >>> getValue()
> > > > > > >>> which should return Guid.
> > > > > > >>> As for me these two classes are look like the same and
> > > > > > >>> I
> > > > > > >>> don't
> > > > > > >>> see
> > > > > > >>> to
> > > > > > >>> much differences between them.
> > > > > > >>> My proposal is to remove NGuid and move it
> > > > > > >>> functionality
> > > > > > >>> to
> > > > > > >>> Guid
> > > > > > >>> (Because of Guid is much more common)
> > > > > > >>>
> > > > > > >> i agree, but we need to take another step forward and
> > > > > > >> allow
> > > > > > >> Guid
> > > > > > >> to
> > > > > > >> be null (as it should)
> > > > > > >> and not assume its EMPTY or have a value (i'm pretty
> > > > > > >> sure
> > > > > > >> we
> > > > > > >> have
> > > > > > >> this assumption in many places)
> > > > > > > Hi,
> > > > > > >
> > > > > > > And for the new people out here... why not kill both and
> > > > > > > use
> > > > > > > plain
> > > > > > > standard java UUID[1]?
> > > > > > +1 for using java.util.UUID
> > > > > > 
> > > > > > NGuid functionality that should be extracted during the
> > > > > > refactor
> > > > > > is
> > > > > > -
> > > > > > 1. refactor DB and Java so empty or null return values are
> > > > > > null
> > > > > > and
> > > > > > not
> > > > > > EMPTY_GUID
> > > > > > 2. the special constructor of NGuid for UUID return by
> > > > > > Microsoft
> > > > > > AD
> > > > > > should be extracted to a factory/utility
> > > > > > > I think we should kill compat, I don't see any value in
> > > > > > > fixing
> > > > > > > anything about it while leaving it intact.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Alon Bar-Lev.
> > > > > > >
> > > > > > > [1]
> > > > > > > http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> > > > > Actually there is exists one reason not to use directly UUID
> > > > > at
> > > > > server side.
> > > > > The main operations on Guid today it is to convert object to
> > > > > Guid
> > > > > or
> > > > > Guid to string.
> > > > > Guid it is immutable object, number of Guids is limited and
> > > > > almost
> > > > > never changed,
> > > > > These sound like classical case for object that can be
> > > > > cached.
> > > > > Benefit - reduced number of string manipulations, reduced
> > > > > number
> > > > > of
> > > > > created instances, less work
> > > > > for garbage collection
> > > > 
> > > > UUID has the same properties, it is immutable. So you could do
> > > > the
> > > > same with UUID, but I am not sure you could effectively cache
> > > > these
> > > > objects and prove that you are saving either CPU, heap, or GC
> > > > time.
> > > These is a very common pattern:
> > > 1) implementation of valueOf() for most classes like Integer,
> > > Double,
> > > etc... has some kind of cache.
> > > 2) JVM has cache for strings that can be used and that cache can
> > > be
> > > tweaked by some JVM opts.
> > > 3) Most of our operations is perform query on DB, send request to
> > > host or parse response from host and Guid
> > >    is very common object that is immutable.
> > > I am agree that these will not solve all our performance problems
> > > but
> > > can provide some benefit, especially when it is very easy
> > > to implement.
> > 
> > We could still achieve that using a UUIDCreator class and call it
> > instead of Guid.fromString("")..
> > 
> > Whether this is cached or not is another question which can be
> > solved
> > later and checked to see if the cache improves performance or not.
> These is already implementation, if it will be Guid.fromString("") or
> UUIDCreator.
> The issue is if we want to use cache, it should be implemented
> together
> with deleting/replacing of Guid/NGuid , because of it much more
> easilly

I think the value of using standard java classes is higher than the tuning of the engine at this regard. Dropping the compat thing is important activity.

After doing this conversion, use profiler to determine where major bottle necks are and fix these, I am not sure the above optimization will be first in list. If we invest resources in optimization better to invest in these that we suffer most.

Regards,
Alon


From snmishra at linux.vnet.ibm.com  Mon Feb  4 19:12:23 2013
From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com)
Date: Mon, 04 Feb 2013 11:12:23 -0800
Subject: [Engine-devel] webadmin: How to make a text box readonly.
Message-ID: <20130204111223.Horde.bX6MsJir309REAgXZQNl-CA@imap.linux.ibm.com>

Hi,

    I am trying to populate a text box (EntityModelTextBoxOnlyEditor)  
with a default value that is read only (can't be changed by user). Can  
someone help me with how I can do that?

Thanks
Sharad Mishra



From wei.d.chen at intel.com  Tue Feb  5 01:40:15 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Tue, 5 Feb 2013 01:40:15 +0000
Subject: [Engine-devel] How to show our VM template from web protal?
In-Reply-To: <773333104.16254455.1359971822934.JavaMail.root@redhat.com>
References: <C5A0092C63E939488005F15F736A81120978A933@SHSMSX101.ccr.corp.intel.com>
	<773333104.16254455.1359971822934.JavaMail.root@redhat.com>
Message-ID: <C5A0092C63E939488005F15F736A81120978A9B5@SHSMSX101.ccr.corp.intel.com>

Cannot see it either admin or use portal. I agree with you, let's try to resolve the permission issue at first. Thanks so much.

Best Regards,
Dave Chen


> -----Original Message-----
> From: Omer Frenkel [mailto:ofrenkel at redhat.com]
> Sent: Monday, February 04, 2013 5:57 PM
> To: Chen, Wei D
> Cc: engine-devel; Itamar Heim
> Subject: Re: [Engine-devel] How to show our VM template from web protal?
> 
> 
> 
> ----- Original Message -----
> > From: "Wei D Chen" <wei.d.chen at intel.com>
> > To: "Itamar Heim" <iheim at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, February 4, 2013 11:49:33 AM
> > Subject: Re: [Engine-devel] How to show our VM template from web protal?
> >
> > Thanks Itamar. Of course, we can create a VM template by clicking
> > 'make template' button. What we want to do is create a VM template
> > contains some customized parameters which are not currently supported
> > by web portal, so, we expect to create the template by executing some
> > DB procedure, like " InsertVmTemplate ". The result is this template
> > could be created in DB but cannot be showed from web portal. Thanks.
> >
> 
> you can't see it also in the web admin portal or just user portal?
> my guess is that you are missing a permission for it (check permissions table -
> object id is the template id, object type for template is 4)
> 
> >
> > Best Regards,
> > Dave Chen
> >
> >
> > > -----Original Message-----
> > > From: Itamar Heim [mailto:iheim at redhat.com]
> > > Sent: Monday, February 04, 2013 4:51 PM
> > > To: Chen, Wei D
> > > Cc: engine-devel; Liu, DanqingX
> > > Subject: Re: [Engine-devel] How to show our VM template from web
> > > protal?
> > >
> > > On 01/02/2013 11:31, Chen, Wei D wrote:
> > > > Hi,
> > > >
> > > > We are trying to create a VM template which is similar with "blank
> > > > template"
> > > and hope to display this template on web portal, our consideration
> > > is simple, that is, just execute "InsertVmTemplate"
> > > > procedure manually and expect our template would be showed from
> > > > web
> > > portal. Unfortunately, there is no changes seen from portal even
> > > after restarting engine service.
> > > > Definitely, we must miss something, would you anyone input any
> > > > suggestion,
> > > any feedback is great appreciated. thanks in advance!
> > >
> > > the supported way of creating a template is to stand on a VM and
> > > click 'make template'.
> > > (as normally, templates have disks in them, though not mandatory).
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >

From kmayilsa at redhat.com  Tue Feb  5 04:36:28 2013
From: kmayilsa at redhat.com (Kanagaraj)
Date: Tue, 05 Feb 2013 10:06:28 +0530
Subject: [Engine-devel] webadmin: How to make a text box readonly.
In-Reply-To: <20130204111223.Horde.bX6MsJir309REAgXZQNl-CA@imap.linux.ibm.com>
References: <20130204111223.Horde.bX6MsJir309REAgXZQNl-CA@imap.linux.ibm.com>
Message-ID: <51108C4C.6020206@redhat.com>

Hi,

  If you have a corresponding EnityModel for that Editor, you could use 
entityModel.setIsChangable(false). Now the textbox will be grayed out 
and the user will not be able to edit the value.
  For setting a default value, you can use entityModel.setEntity("XYZ").

Thanks,
Kanagaraj

On 02/05/2013 12:42 AM, snmishra at linux.vnet.ibm.com wrote:
> Hi,
>
>    I am trying to populate a text box (EntityModelTextBoxOnlyEditor) 
> with a default value that is read only (can't be changed by user). Can 
> someone help me with how I can do that?
>
> Thanks
> Sharad Mishra
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From derez at redhat.com  Tue Feb  5 06:55:31 2013
From: derez at redhat.com (Daniel Erez)
Date: Tue, 5 Feb 2013 01:55:31 -0500 (EST)
Subject: [Engine-devel] webadmin: How to make a text box readonly.
In-Reply-To: <51108C4C.6020206@redhat.com>
Message-ID: <1612187706.13504293.1360047331891.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Kanagaraj" <kmayilsa at redhat.com>
> To: snmishra at linux.vnet.ibm.com
> Cc: ovedo at redhat.com, engine-devel at ovirt.org
> Sent: Tuesday, February 5, 2013 6:36:28 AM
> Subject: Re: [Engine-devel] webadmin: How to make a text box readonly.
> 
> Hi,
> 
>   If you have a corresponding EnityModel for that Editor, you could
>   use
> entityModel.setIsChangable(false). Now the textbox will be grayed out
> and the user will not be able to edit the value.
>   For setting a default value, you can use
>   entityModel.setEntity("XYZ").
> 
> Thanks,
> Kanagaraj
> 
> On 02/05/2013 12:42 AM, snmishra at linux.vnet.ibm.com wrote:
> > Hi,
> >
> >    I am trying to populate a text box
> >    (EntityModelTextBoxOnlyEditor)
> > with a default value that is read only (can't be changed by user).
> > Can
> > someone help me with how I can do that?

For a read-only text editor you can also use EntityModelLabelEditor.

> >
> > Thanks
> > Sharad Mishra
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkublin at redhat.com  Tue Feb  5 07:28:26 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Tue, 5 Feb 2013 02:28:26 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <1138738443.5890952.1359987459619.JavaMail.root@redhat.com>
Message-ID: <1466065842.13513476.1360049306156.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, February 4, 2013 4:17:39 PM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Monday, February 4, 2013 2:15:40 PM
> > Subject: Re: [Engine-devel] Guid & NGuid
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > To: "Michael Kublin" <mkublin at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, February 4, 2013 11:48:45 AM
> > > Subject: Re: [Engine-devel] Guid & NGuid
> > > 
> > > ----- Original Message -----
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > > Cc: engine-devel at ovirt.org
> > > > > Sent: Monday, February 4, 2013 9:56:28 AM
> > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > To: engine-devel at ovirt.org
> > > > > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Roy Golan" <rgolan at redhat.com>
> > > > > > > To: engine-devel at ovirt.org
> > > > > > > Sent: Monday, February 4, 2013 9:18:21 AM
> > > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > > 
> > > > > > > On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> > > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > > > >> To: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > > > > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> ----- Original Message -----
> > > > > > > >>> From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > >>> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> > > > > > > >>> Subject: [Engine-devel] Guid & NGuid
> > > > > > > >>>
> > > > > > > >>> Hi,
> > > > > > > >>>
> > > > > > > >>> In ovirt-engine code we have Guid and NGuid objects.
> > > > > > > >>> Guid is extends NGuid and also NGuid class has method
> > > > > > > >>> getValue()
> > > > > > > >>> which should return Guid.
> > > > > > > >>> As for me these two classes are look like the same
> > > > > > > >>> and
> > > > > > > >>> I
> > > > > > > >>> don't
> > > > > > > >>> see
> > > > > > > >>> to
> > > > > > > >>> much differences between them.
> > > > > > > >>> My proposal is to remove NGuid and move it
> > > > > > > >>> functionality
> > > > > > > >>> to
> > > > > > > >>> Guid
> > > > > > > >>> (Because of Guid is much more common)
> > > > > > > >>>
> > > > > > > >> i agree, but we need to take another step forward and
> > > > > > > >> allow
> > > > > > > >> Guid
> > > > > > > >> to
> > > > > > > >> be null (as it should)
> > > > > > > >> and not assume its EMPTY or have a value (i'm pretty
> > > > > > > >> sure
> > > > > > > >> we
> > > > > > > >> have
> > > > > > > >> this assumption in many places)
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > And for the new people out here... why not kill both
> > > > > > > > and
> > > > > > > > use
> > > > > > > > plain
> > > > > > > > standard java UUID[1]?
> > > > > > > +1 for using java.util.UUID
> > > > > > > 
> > > > > > > NGuid functionality that should be extracted during the
> > > > > > > refactor
> > > > > > > is
> > > > > > > -
> > > > > > > 1. refactor DB and Java so empty or null return values
> > > > > > > are
> > > > > > > null
> > > > > > > and
> > > > > > > not
> > > > > > > EMPTY_GUID
> > > > > > > 2. the special constructor of NGuid for UUID return by
> > > > > > > Microsoft
> > > > > > > AD
> > > > > > > should be extracted to a factory/utility
> > > > > > > > I think we should kill compat, I don't see any value in
> > > > > > > > fixing
> > > > > > > > anything about it while leaving it intact.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Alon Bar-Lev.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > > http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> > > > > > Actually there is exists one reason not to use directly
> > > > > > UUID
> > > > > > at
> > > > > > server side.
> > > > > > The main operations on Guid today it is to convert object
> > > > > > to
> > > > > > Guid
> > > > > > or
> > > > > > Guid to string.
> > > > > > Guid it is immutable object, number of Guids is limited and
> > > > > > almost
> > > > > > never changed,
> > > > > > These sound like classical case for object that can be
> > > > > > cached.
> > > > > > Benefit - reduced number of string manipulations, reduced
> > > > > > number
> > > > > > of
> > > > > > created instances, less work
> > > > > > for garbage collection
> > > > > 
> > > > > UUID has the same properties, it is immutable. So you could
> > > > > do
> > > > > the
> > > > > same with UUID, but I am not sure you could effectively cache
> > > > > these
> > > > > objects and prove that you are saving either CPU, heap, or GC
> > > > > time.
> > > > These is a very common pattern:
> > > > 1) implementation of valueOf() for most classes like Integer,
> > > > Double,
> > > > etc... has some kind of cache.
> > > > 2) JVM has cache for strings that can be used and that cache
> > > > can
> > > > be
> > > > tweaked by some JVM opts.
> > > > 3) Most of our operations is perform query on DB, send request
> > > > to
> > > > host or parse response from host and Guid
> > > >    is very common object that is immutable.
> > > > I am agree that these will not solve all our performance
> > > > problems
> > > > but
> > > > can provide some benefit, especially when it is very easy
> > > > to implement.
> > > 
> > > We could still achieve that using a UUIDCreator class and call it
> > > instead of Guid.fromString("")..
> > > 
> > > Whether this is cached or not is another question which can be
> > > solved
> > > later and checked to see if the cache improves performance or
> > > not.
> > These is already implementation, if it will be Guid.fromString("")
> > or
> > UUIDCreator.
> > The issue is if we want to use cache, it should be implemented
> > together
> > with deleting/replacing of Guid/NGuid , because of it much more
> > easilly
> 
> I think the value of using standard java classes is higher than the
> tuning of the engine at this regard. Dropping the compat thing is
> important activity.
Immutable object it is a common java design pattern
> After doing this conversion, use profiler to determine where major
Already was done, and already tested a cache solution (Simple POC solution took to implement less 
than hour)
> bottle necks are and fix these, I am not sure the above optimization
> will be first in list.
Any optimization can not be first in the list, the best optimization is architecture change 
> If we invest resources in optimization better
> to invest in these that we suffer most.
Most of the issues are well known.

> 
> Regards,
> Alon
> 


From alonbl at redhat.com  Tue Feb  5 07:29:20 2013
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Tue, 5 Feb 2013 02:29:20 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <1466065842.13513476.1360049306156.JavaMail.root@redhat.com>
Message-ID: <441020136.6063702.1360049360391.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, February 5, 2013 9:28:26 AM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> 
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Monday, February 4, 2013 4:17:39 PM
> > Subject: Re: [Engine-devel] Guid & NGuid
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Michael Kublin" <mkublin at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Monday, February 4, 2013 2:15:40 PM
> > > Subject: Re: [Engine-devel] Guid & NGuid
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Monday, February 4, 2013 11:48:45 AM
> > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > 
> > > > ----- Original Message -----
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > > > Cc: engine-devel at ovirt.org
> > > > > > Sent: Monday, February 4, 2013 9:56:28 AM
> > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > To: engine-devel at ovirt.org
> > > > > > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Roy Golan" <rgolan at redhat.com>
> > > > > > > > To: engine-devel at ovirt.org
> > > > > > > > Sent: Monday, February 4, 2013 9:18:21 AM
> > > > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > > > 
> > > > > > > > On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> > > > > > > > >
> > > > > > > > > ----- Original Message -----
> > > > > > > > >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > > > > >> To: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > > > > > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> ----- Original Message -----
> > > > > > > > >>> From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > > >>> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> > > > > > > > >>> Subject: [Engine-devel] Guid & NGuid
> > > > > > > > >>>
> > > > > > > > >>> Hi,
> > > > > > > > >>>
> > > > > > > > >>> In ovirt-engine code we have Guid and NGuid
> > > > > > > > >>> objects.
> > > > > > > > >>> Guid is extends NGuid and also NGuid class has
> > > > > > > > >>> method
> > > > > > > > >>> getValue()
> > > > > > > > >>> which should return Guid.
> > > > > > > > >>> As for me these two classes are look like the same
> > > > > > > > >>> and
> > > > > > > > >>> I
> > > > > > > > >>> don't
> > > > > > > > >>> see
> > > > > > > > >>> to
> > > > > > > > >>> much differences between them.
> > > > > > > > >>> My proposal is to remove NGuid and move it
> > > > > > > > >>> functionality
> > > > > > > > >>> to
> > > > > > > > >>> Guid
> > > > > > > > >>> (Because of Guid is much more common)
> > > > > > > > >>>
> > > > > > > > >> i agree, but we need to take another step forward
> > > > > > > > >> and
> > > > > > > > >> allow
> > > > > > > > >> Guid
> > > > > > > > >> to
> > > > > > > > >> be null (as it should)
> > > > > > > > >> and not assume its EMPTY or have a value (i'm pretty
> > > > > > > > >> sure
> > > > > > > > >> we
> > > > > > > > >> have
> > > > > > > > >> this assumption in many places)
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > And for the new people out here... why not kill both
> > > > > > > > > and
> > > > > > > > > use
> > > > > > > > > plain
> > > > > > > > > standard java UUID[1]?
> > > > > > > > +1 for using java.util.UUID
> > > > > > > > 
> > > > > > > > NGuid functionality that should be extracted during the
> > > > > > > > refactor
> > > > > > > > is
> > > > > > > > -
> > > > > > > > 1. refactor DB and Java so empty or null return values
> > > > > > > > are
> > > > > > > > null
> > > > > > > > and
> > > > > > > > not
> > > > > > > > EMPTY_GUID
> > > > > > > > 2. the special constructor of NGuid for UUID return by
> > > > > > > > Microsoft
> > > > > > > > AD
> > > > > > > > should be extracted to a factory/utility
> > > > > > > > > I think we should kill compat, I don't see any value
> > > > > > > > > in
> > > > > > > > > fixing
> > > > > > > > > anything about it while leaving it intact.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Alon Bar-Lev.
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > > http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> > > > > > > Actually there is exists one reason not to use directly
> > > > > > > UUID
> > > > > > > at
> > > > > > > server side.
> > > > > > > The main operations on Guid today it is to convert object
> > > > > > > to
> > > > > > > Guid
> > > > > > > or
> > > > > > > Guid to string.
> > > > > > > Guid it is immutable object, number of Guids is limited
> > > > > > > and
> > > > > > > almost
> > > > > > > never changed,
> > > > > > > These sound like classical case for object that can be
> > > > > > > cached.
> > > > > > > Benefit - reduced number of string manipulations, reduced
> > > > > > > number
> > > > > > > of
> > > > > > > created instances, less work
> > > > > > > for garbage collection
> > > > > > 
> > > > > > UUID has the same properties, it is immutable. So you could
> > > > > > do
> > > > > > the
> > > > > > same with UUID, but I am not sure you could effectively
> > > > > > cache
> > > > > > these
> > > > > > objects and prove that you are saving either CPU, heap, or
> > > > > > GC
> > > > > > time.
> > > > > These is a very common pattern:
> > > > > 1) implementation of valueOf() for most classes like Integer,
> > > > > Double,
> > > > > etc... has some kind of cache.
> > > > > 2) JVM has cache for strings that can be used and that cache
> > > > > can
> > > > > be
> > > > > tweaked by some JVM opts.
> > > > > 3) Most of our operations is perform query on DB, send
> > > > > request
> > > > > to
> > > > > host or parse response from host and Guid
> > > > >    is very common object that is immutable.
> > > > > I am agree that these will not solve all our performance
> > > > > problems
> > > > > but
> > > > > can provide some benefit, especially when it is very easy
> > > > > to implement.
> > > > 
> > > > We could still achieve that using a UUIDCreator class and call
> > > > it
> > > > instead of Guid.fromString("")..
> > > > 
> > > > Whether this is cached or not is another question which can be
> > > > solved
> > > > later and checked to see if the cache improves performance or
> > > > not.
> > > These is already implementation, if it will be
> > > Guid.fromString("")
> > > or
> > > UUIDCreator.
> > > The issue is if we want to use cache, it should be implemented
> > > together
> > > with deleting/replacing of Guid/NGuid , because of it much more
> > > easilly
> > 
> > I think the value of using standard java classes is higher than the
> > tuning of the engine at this regard. Dropping the compat thing is
> > important activity.
> Immutable object it is a common java design pattern
> > After doing this conversion, use profiler to determine where major
> Already was done, and already tested a cache solution (Simple POC
> solution took to implement less
> than hour)
> > bottle necks are and fix these, I am not sure the above
> > optimization
> > will be first in list.
> Any optimization can not be first in the list, the best optimization
> is architecture change
> > If we invest resources in optimization better
> > to invest in these that we suffer most.
> Most of the issues are well known.

Please try to be less cryptic... Is this one of them?

> 
> > 
> > Regards,
> > Alon
> > 
> 


From tjelinek at redhat.com  Tue Feb  5 08:34:17 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Tue, 5 Feb 2013 03:34:17 -0500 (EST)
Subject: [Engine-devel] webadmin: How to make a text box readonly.
In-Reply-To: <1612187706.13504293.1360047331891.JavaMail.root@redhat.com>
Message-ID: <833750465.10626300.1360053257498.JavaMail.root@redhat.com>



----- Original Message -----
From: "Daniel Erez" <derez at redhat.com>
To: snmishra at linux.vnet.ibm.com
Cc: ovedo at redhat.com, engine-devel at ovirt.org
Sent: Tuesday, February 5, 2013 7:55:31 AM
Subject: Re: [Engine-devel] webadmin: How to make a text box readonly.



----- Original Message -----
> From: "Kanagaraj" <kmayilsa at redhat.com>
> To: snmishra at linux.vnet.ibm.com
> Cc: ovedo at redhat.com, engine-devel at ovirt.org
> Sent: Tuesday, February 5, 2013 6:36:28 AM
> Subject: Re: [Engine-devel] webadmin: How to make a text box readonly.
> 
> Hi,
> 
>   If you have a corresponding EnityModel for that Editor, you could
>   use
> entityModel.setIsChangable(false). Now the textbox will be grayed out
> and the user will not be able to edit the value.
>   For setting a default value, you can use
>   entityModel.setEntity("XYZ").
> 
Or if you do not have the corresponding EntityModel, you can use 
yourEntityModelTextBoxOnlyEditorInstance.setEnabled(false) 
and set the value as 
yourEntityModelTextBoxOnlyEditorInstance.asEditor().getSubEditor().setValue("")

Tomas

> Thanks,
> Kanagaraj
> 
> On 02/05/2013 12:42 AM, snmishra at linux.vnet.ibm.com wrote:
> > Hi,
> >
> >    I am trying to populate a text box
> >    (EntityModelTextBoxOnlyEditor)
> > with a default value that is read only (can't be changed by user).
> > Can
> > someone help me with how I can do that?

For a read-only text editor you can also use EntityModelLabelEditor.

> >
> > Thanks
> > Sharad Mishra
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From lspevak at redhat.com  Tue Feb  5 12:13:12 2013
From: lspevak at redhat.com (Libor Spevak)
Date: Tue, 05 Feb 2013 13:13:12 +0100
Subject: [Engine-devel] Time for Spring?
In-Reply-To: <2066633252.9094534.1359983223438.JavaMail.root@redhat.com>
References: <2066633252.9094534.1359983223438.JavaMail.root@redhat.com>
Message-ID: <5110F758.60304@redhat.com>

Thanks for the info, I just wanted to know, if there are fans of Spring 
Framework. If we concentrate just on dependency injection (CDI), 
probably "standard" JEE technology would be the best way.

But, if we want to integrate with e.g. Hibernate/JPA, memory cache (e.g. 
EhCache) because of DB performance, weave transparently 
logging,monitoring and/or caching code to current classes (using 
aspects) without changing any line of current code (if we had services 
based on Spring beans), there are not many options. JEE container 
independence is here not an issue and I am not sure, if development on 
light container like Jetty would be quicker, but for integration tests 
the framework support is strong (e.g. "simulates" services of "real" JEE 
container).

Libor

On 4.2.2013 14:07, Laszlo Hornyak wrote:
> I have seen a CDI patch from Roy that may be related to the topic.
>
> I do not know what the general direction is. CDI is "more standard", while it's implementations for me look heavy weight and difficult to port to small containers like tomcat or jetty.
>
> In general, now we only inject the Backend deathstar bean to wherever it is needed and then it is used as registry for other service objects and DAOs.
>
> With spring dependency injection, we could be more independent from the container, since the ioC container is comming with us to the app container. But at the other hand, ovirt is a nice big ear app, so how would you put it together as a spring app? What changes would this need?
>
> Laszlo
>
> ----- Original Message -----
>> From: "Libor Spevak" <lspevak at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, January 29, 2013 11:42:35 AM
>> Subject: [Engine-devel] Time for Spring?
>>
>> Hi,
>>
>> it is rather cold in Europe, but can I ask, what's the current
>> opinion
>> or plans about "full" integration of Spring Framework into oVirt
>> engine
>> (Backend)?
>>
>> This is a commonly accepted integration framework among Java
>> programmers
>> and industry standard, which
>> solves many pains from small to large projects. And can lead to a
>> better
>> understanding of the program.
>>
>> There are several Spring dependencies inside oVirt project, but
>> mostly
>> for LDAP and database communication (JDBC template).
>>
>> Still missing (sorry, looks like marketing, but..):
>>
>> - dependency injection
>> - aspect-oriented programming (AOP)
>> - enterprise integration patterns
>>
>> Is something true? :-)
>>
>> 1. We tried, but it is too large and overcomplicated, it can be
>> solved
>> better way for the project purpose
>> 2. We tried, but we think, we need just e.g. JDBC, LDAP layer covered
>> now
>> 3. We would like to integrate with e.g. Hibernate soon, EJB,
>> remoting,
>> unit tests, integration tests, ... , probably we will need it soon
>> 4. We understand and need dependency injection, but there are other
>> light DI containers (Pico, Guice, JBoss Seam).
>> etc.
>>
>> Still, I think there is strong potential, probably not clear today.
>> We
>> cannot avoid Guice on frontend side because of GWTP, but the backend
>> lacks something.
>> Or not?
>>
>> Thanks.
>>
>> Regards,
>> Libor
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From lhornyak at redhat.com  Tue Feb  5 13:29:38 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 5 Feb 2013 08:29:38 -0500 (EST)
Subject: [Engine-devel] cleanup patch review needed
In-Reply-To: <402894579.9567932.1360070919362.JavaMail.root@redhat.com>
Message-ID: <126697683.9568655.1360070978357.JavaMail.root@redhat.com>

Hi,

I need someone to review this patch
http://gerrit.ovirt.org/#/c/11351/

Thx,
Laszlo


From tjelinek at redhat.com  Tue Feb  5 15:16:49 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Tue, 5 Feb 2013 10:16:49 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <1480221331.10050512.1359976117465.JavaMail.root@redhat.com>
Message-ID: <535855015.10837104.1360077409100.JavaMail.root@redhat.com>

> So, I had a discussion with Laszlo. Long story short, the question is:
> @Andrew: Is the more basic use case to select the Template or to select the Instance Type + Image? Why?
> 
> We need to decide it because the more basic UC should be in basic view and the less one in advanced (after clicking "show advanced options" button).
>
> The concern is, that the HW is anyhow configured to serve the SW so it, in most cases of private cloud, does not make sense to
> split them. So the user will have to select two combo boxes instead of one with no added value (e.g. RHEL63-instance + RHEL64-image).
>
> I understand that the advantage of having the HW and SW profile separated is that you can update the HW of all VMs created from it. 
> But is this the basic UC or the advanced one?

I have checked with Andy, it seems like this:
the users complains that the "new VM dialog" has far too many options and it is hard to start using it.
After this change, the oVirt will be shipped with preconfigured instance types (e.g. something like small, medium, large etc)
which will pre-fill the dialog, and unless you press the "show advanced options" you won't even know how. It should enhance the 
learning curve of new users. 

----- Original Message -----
From: "Tomas Jelinek" <tjelinek at redhat.com>
To: "Laszlo Hornyak" <lhornyak at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Monday, February 4, 2013 12:08:37 PM
Subject: Re: [Engine-devel] Instance Types Feature

So, I had a discussion with Laszlo. Long story short, the question is:
@Andrew: Is the more basic use case to select the Template or to select the Instance Type + Image? Why?

We need to decide it because the more basic UC should be in basic view and the less one in advanced (after clicking "show advanced options" button).

The concern is, that the HW is anyhow configured to serve the SW so it, in most cases of private cloud, does not make sense to
split them. So the user will have to select two combo boxes instead of one with no added value (e.g. RHEL63-instance + RHEL64-image).

I understand that the advantage of having the HW and SW profile separated is that you can update the HW of all VMs created from it. 
But is this the basic UC or the advanced one?

Thank you,
Tomas

----- Original Message -----
From: "Tomas Jelinek" <tjelinek at redhat.com>
To: "Laszlo Hornyak" <lhornyak at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Wednesday, January 30, 2013 3:26:42 PM
Subject: Re: [Engine-devel] Instance Types Feature

> A hidden feature is a not existing feature :)
Well, the "hide" was not a correct term :) 

But where would you put it? I see the following options:
1: To the basic screen (but a bit confusing as there will be instance type and image and this dialog should be as simple as possible)
2: To the advanced screen (let's not call it hide but make it an advanced option:) )
3: Do not add it at all (worst case)

I suppose that add it to simple screen and put the Instance type and Image to the advanced one is not really an option as the main point of
this feature is to actually introduce the instance types as a more convenient way of configuring the VM's HW decoupled from SW.

What do you think? Do you see any other ways? I would say that the second possibility is not bad...

Thank you,
Tomas

----- Original Message -----
From: "Laszlo Hornyak" <lhornyak at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Wednesday, January 30, 2013 11:24:52 AM
Subject: Re: [Engine-devel]  Instance Types Feature

A hidden feature is a not existing feature :)

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, January 30, 2013 8:30:26 AM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> > Of course after introducing the instance type in ovirt, you will
> > still have control over the instance types and create any instance
> > type you like beyond the pre-defined types you have in public
> > cloud, but you
> > will have two things to set: the instance type and the image, which
> > is more administration...
> You will still have the templates - you will be able to choose a
> template which defines both. But it will be "hidden" in advanced
> part of the dialog.
> You are right, the simple way is pretty much inspired by public
> clouds, because they do great job in making the things easy. You
> basically just say you want a small machine and attach a rhel image
> to it.
> Other advantage of separating the HW and SW configuration is that you
> can just change the HW profile (instance type) on which you are
> running, or, if the instance type changes, it gets reflected in all
> machines using this instance type.
> 
> > This is why I think keeping the template as an entity composed out
> > of an image and a instance type would be great.
> yep, it seems we will keep it :) It just will be hidden in the
> advanced options (e.g. one more click). Sounds reasonable?
> 
> ----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Monday, January 28, 2013 12:16:00 PM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> hi,
> 
> This is what I thought of:
> 
> In public clouds it is common to have pre-defined instance types e.g.
> amazon small/medium/large/x-large instance, and this is what
> customers get even if they don't like it. I guess this helps Amazon
> a lot to simplify the decision logic for vm scheduling and pricing.
> 
> In a private cloud, you choose the resources your application needs,
> therefore you can choose just as much as you need.
> 
> Of course after introducing the instance type in ovirt, you will
> still have control over the instance types and create any instance
> type you like beyond the pre-defined types you have in public cloud,
> but you will have two things to set: the instance type and the
> image, which is more administration than just working with
> templates, while most of the cases the templates were enough: you
> created both the OS image and the virtual hardware profile it is
> running on. For another image and another workload, I would most
> likely want to create another one that just fits the needs.
> 
> This is why I think keeping the template as an entity composed out of
> an image and a instance type would be great.
> 
> Laszlo
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Friday, January 25, 2013 1:32:20 PM
> > Subject: Re: [Engine-devel]  Instance Types Feature
> > 
> > Hi Laszlo,
> > 
> > it is not useful just for public clouds - it can be pretty useful
> > for
> > private as well. But to keep the previous way, it could be done
> > this
> > way:
> > - on the advanced screen (after clicking "show advanced options"
> > you
> > can specify the template)
> > - by default you pick on basic view the instance type (e.g. HW
> > profile) and the Image (e.g. disk with some metadata such as OS
> > type). But, you can select custom instance type (equivalent to
> >  blank template) and no Image. In this case the template appears
> > also on basic view and you can select it.
> > 
> > What do you think?
> > 
> > Tomas
> > 
> > ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Tomas Jelinek" <tjelinek at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, January 22, 2013 7:16:32 PM
> > Subject: Re: [Engine-devel]  Instance Types Feature
> > 
> > Hi Tomas,
> > 
> > I like the idea in general, but for me the instance types looks
> > like
> > a feature that is typical in public clouds, while in private clouds
> > it looks more like a cool extra feature for special cases.
> > Therefore
> > in my opinion it would be great to keep the old template solution
> > as
> > well to keep it simple for most users. A template could be an
> > instance type and an image together. Only the description overlap,
> > and that could be solved.
> > 
> > Thanks,
> > Laszlo
> > 
> > ----- Original Message -----
> > > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Tuesday, January 22, 2013 3:09:51 PM
> > > Subject: [Engine-devel]  Instance Types Feature
> > > 
> > > Hi All,
> > > 
> > > this is the proposed new feature called instance types:
> > > http://www.ovirt.org/Features/Instance_Types
> > > 
> > > Long story short - it should basically split the VM template
> > > into:
> > > - "hardware profile" called instance types
> > > - "software profile" called image
> > > 
> > > This should enable to do something like: Create a new "small" VM
> > > and
> > > attach a disk with "RHEL + Postgres" installed.
> > > 
> > > Any comments are more than welcome!
> > > 
> > > Tomas
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From tjelinek at redhat.com  Tue Feb  5 16:14:00 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Tue, 5 Feb 2013 11:14:00 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <1290421199.15072642.1359467653790.JavaMail.root@redhat.com>
Message-ID: <1678216043.10869309.1360080840294.JavaMail.root@redhat.com>

> 1. Why do we need a new set of permissions for "Create Instance" and "Instance Owner"? Aren't the VmCreator role and the UserVmManager role enough in these use-cases?
so checked this with Andy:
- Create Instance: it is a permission to actually see the instance types in the list of instance types when creating the VM and to be able to create a VM from that instance type
- Instance Owner: if the user has this permission, he can edit the fields marked as "Basic User" in the table in the wiki (but not the others)

----- Original Message -----
From: "Oved Ourfalli" <ovedo at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Tuesday, January 29, 2013 2:54:13 PM
Subject: Re: [Engine-devel]  Instance Types Feature

Some questions:
1. Why do we need a new set of permissions for "Create Instance" and "Instance Owner"? Aren't the VmCreator role and the UserVmManager role enough in these use-cases?
2. iiuc, the internal implementation of instance types and images will be done using templates. However, I guess we plan to expose instance types and images as REST resources, right?

Thank you,
Oved

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, January 22, 2013 3:09:51 PM
> Subject: [Engine-devel]  Instance Types Feature
> 
> Hi All,
> 
> this is the proposed new feature called instance types:
> http://www.ovirt.org/Features/Instance_Types
> 
> Long story short - it should basically split the VM template into:
> - "hardware profile" called instance types
> - "software profile" called image
> 
> This should enable to do something like: Create a new "small" VM and
> attach a disk with "RHEL + Postgres" installed.
> 
> Any comments are more than welcome!
> 
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From vszocs at redhat.com  Tue Feb  5 16:54:01 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 5 Feb 2013 11:54:01 -0500 (EST)
Subject: [Engine-devel] Update on UI Plugins: what's coming in near future
In-Reply-To: <435198187.10844730.1360078187299.JavaMail.root@redhat.com>
Message-ID: <497218626.10890814.1360083241065.JavaMail.root@redhat.com>

Hello everyone, 

it's been a while since I posted an update on UI Plugins so I thought I'd share some updates and plans for near future. 

First of all, I apologize to Chris and other NetApp folks for not being able to attend oVirt Workshop in Sunnyvale. I've caught a terrible flu just one day before flying to the conference, which is most unfortunate :( I've attached both presentations I prepared for the workshop to this email for reference. Once again, sorry for my absence at the workshop. 

The UI Plugins feature wiki [http://www.ovirt.org/Features/UIPlugins] has been updated in the mean time, you can check it out and let me know what you think. There are still some TODOs like documenting supported functions/events, I'll take care of this in the upcoming days. 

I'm currently working on improving showDialog API, moving away from native browser popups and using WebAdmin dialog infrastructure. You can find the first (work-in-progress) version of the patch at [http://gerrit.ovirt.org/#/c/11717/]. Besides showDialog API, roadmap for near future is following: 

    * allow adding action buttons ( api.addMainTabActionButton ) to main tabs that are currently not supported 


        * currently supported main tabs: Cluster, DataCenter, Disk, Host, Storage, Template, VirtualMachine 
        * remaining main tabs to support: Event, Network, Pool, Quota, User, Volume 


    * 
improve addMainTabActionButton API to allow different action button representations 


        * add both context-sensitive button (toolbar) and corresponding context-menu item (menu) 
        * add only context-sensitive button (toolbar) 
        * add only context-menu item (menu) 


    * 
improve addMainTab/addSubTab API to allow tab widget alignment (left or right) 

        * initial patch submitted by Spenser Shumaker [http://gerrit.ovirt.org/#/c/11273/] 

I've been also thinking about UI Plugins infrastructure and development in general, and came up with some ideas I'm planning to try out: 

    * invert control with regard to obtaining pluginApi instance 


        * currently, WebAdmin exposes pluginApi object in top-level context, and plugins obtain pluginApi via parent.pluginApi(pluginName) 
        * in future, WebAdmin will evaluate pluginApi(pluginName) within top-level context, and assign pluginApi object to iframe window 
        * plugins will obtain pluginApi simply via "api" object that has been assigned to iframe window by WebAdmin (no more parent.pluginApi) 
        * this inversion of control allows more simple and secure way for plugins to interact with plugin API 


    * 
provide sandbox for plugin code running within an iframe 

        * use HTML5 iframe sandbox attribute [http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox] 
        * more specifically, disallow plugins to directly navigate to top-level document/window (e.g. parent) 
        * reason: UI plugins are not meant to integrate with WebAdmin by directly manipulating top-level UI 
        * instead, UI plugins are meant to integrate with WebAdmin via plugin API and events 
        * if a plugin wants to extend UI, it should do it via plugin API and not by "hacking" top-level UI on its own 



    * remove resourcePath from plugin descriptor, use <descriptorFileName>-files naming convention for static plugin resource directory 

Let me know what you think! 

Vojtech 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130205/09b47665/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ovirt2013-UI-Plugins-Introduction.pdf
Type: application/pdf
Size: 577663 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130205/09b47665/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ovirt2013-Hello-World-UI-Plugin.pdf
Type: application/pdf
Size: 374068 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130205/09b47665/attachment-0001.pdf>

From vszocs at redhat.com  Tue Feb  5 17:31:42 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 5 Feb 2013 12:31:42 -0500 (EST)
Subject: [Engine-devel] UI Plugins: HTML5 Window.postMessage communication
	scheme proposal
In-Reply-To: <1376919071.10902248.1360085049574.JavaMail.root@redhat.com>
Message-ID: <431826008.10903928.1360085502755.JavaMail.root@redhat.com>

Hi guys,

showDialog API improvement patch [http://gerrit.ovirt.org/#/c/11717/] is planned to include new feature that allows custom content contributed by UI plugins to invoke arbitrary plugin API function.

For example, imagine you have a custom modal dialog created via showDialog API:
showDialog('Dialog Title', 'dialog-token', 'http://www.example.com/', '800px', '600px')

Alternatively, you could also have a custom main tab created via addMainTab API:
addMainTab('Tab Label', 'tab-token', 'http://www.example.com/')

WebAdmin uses HTML iframe element to render custom content at http://www.example.com/ from within the dialog/tab UI.

Now imagine the custom content shows a button that should invoke some plugin API function. For example, imagine a custom "Close" button rendered within the modal dialog content.

For this purpose, we're planning to use following HTML5 Window.postMessage communication scheme:
* custom content iframe (attached to top-level DOM) does postMessage <pluginName>:<apiExpression>, e.g. foo-plugin:closeDialog('my-dialog')
* WebAdmin receives the message, obtains pluginApi for <pluginName> and invokes <apiExpression> on it, e.g. fooPluginApi.closeDialog('my-dialog')

The above scheme allows *any* custom content iframe (showDialog, addMainTab, etc.) to invoke arbitrary plugin API function (expression). This means that custom content contributed by UI plugins can interact directly with plugin API on its own. In other words, this gives plugin authors the possibility to call plugin API without having to notify the plugin (JavaScript) in one way or another.

Let me know what you think.

Vojtech


From vszocs at redhat.com  Tue Feb  5 20:28:57 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 5 Feb 2013 15:28:57 -0500 (EST)
Subject: [Engine-devel] UI Plugin API: Introducing optional arguments object
In-Reply-To: <90969698.10976678.1360095009693.JavaMail.root@redhat.com>
Message-ID: <1436095852.10981678.1360096137048.JavaMail.root@redhat.com>

Hi guys,

as we're planning to improve some plugin API functions [1,2] I'd like to introduce the concept of optional arguments ('options') object, very similar to jQuery 'settings' object [3].

Each API function will declare only mandatory (required) arguments as part of its signature, with any optional arguments embedded within the 'options' object. The 'options' object itself will be optional (can be omitted) and will always be the last argument of each API function.

For example:

// Without 'options' object, all optional arguments fall back to their default values
showDialog('My Dialog', 'my-dialog', 'http://www.example.com/', '800px', '600px')

// With empty 'options' object, all optional arguments fall back to their default values
showDialog('My Dialog', 'my-dialog', 'http://www.example.com/', '800px', '600px', {})

// With non-empty 'options' object, overriding default 'resizeEnabled' optional argument value
showDialog('My Dialog', 'my-dialog', 'http://www.example.com/', '800px', '600px', { resizeEnabled: true })

Support for this concept should be part of [1].

Vojtech

[1] http://gerrit.ovirt.org/#/c/11717/
[2] http://gerrit.ovirt.org/#/c/11273/
[3] http://api.jquery.com/jQuery.ajax/


From yzaslavs at redhat.com  Wed Feb  6 06:05:26 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 6 Feb 2013 01:05:26 -0500 (EST)
Subject: [Engine-devel] Time for Spring?
In-Reply-To: <5110F758.60304@redhat.com>
Message-ID: <712037089.21733773.1360130726077.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Libor Spevak" <lspevak at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, February 5, 2013 2:13:12 PM
> Subject: Re: [Engine-devel] Time for Spring?
> 
> Thanks for the info, I just wanted to know, if there are fans of
> Spring
> Framework. If we concentrate just on dependency injection (CDI),
> probably "standard" JEE technology would be the best way.
> 
> But, if we want to integrate with e.g. Hibernate/JPA, memory cache
> (e.g.
> EhCache) because of DB performance, weave transparently
> logging,monitoring and/or caching code to current classes (using
> aspects) without changing any line of current code (if we had
> services

* Not sure when we will go to Hibernate/JPA integration -> our current data model is quite complex and we might need to have additional layer of "data objects" if we want to work with Hibernate/JPA .
For example - when VM object is loaded from DB, the hibernate session should be "notified" that the corresponding VmStatic and VmDynamic objects were loaded as well.
And I can think of more examples like this.
* Not sure also about caching - this should be done with care. IMHO the safest approach is to cache static entities. Bare in mind this will require to
change the search engine project , which relies on DB queries , and serves the UI.
* Regarding DB performance - we have issues to deal with it.
* Regarding Aspects - where do you want to use it in the code? any concrete example. In general I would prefer to know where we need "cool features" of frameworks, before trying to adapt our code to support "future cool features of framework".


> based on Spring beans), there are not many options. JEE container
> independence is here not an issue and I am not sure, if development
> on
> light container like Jetty would be quicker, but for integration
> tests
> the framework support is strong (e.g. "simulates" services of "real"
> JEE
> container).

* I would also consider to look into TomEE - Java EE over tomcat. 
> 
> Libor
> 
> On 4.2.2013 14:07, Laszlo Hornyak wrote:
> > I have seen a CDI patch from Roy that may be related to the topic.
> >
> > I do not know what the general direction is. CDI is "more
> > standard", while it's implementations for me look heavy weight and
> > difficult to port to small containers like tomcat or jetty.
> >
> > In general, now we only inject the Backend deathstar bean to
> > wherever it is needed and then it is used as registry for other
> > service objects and DAOs.
> >
> > With spring dependency injection, we could be more independent from
> > the container, since the ioC container is comming with us to the
> > app container. But at the other hand, ovirt is a nice big ear app,
> > so how would you put it together as a spring app? What changes
> > would this need?
> >
> > Laszlo


> >
> > ----- Original Message -----
> >> From: "Libor Spevak" <lspevak at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Tuesday, January 29, 2013 11:42:35 AM
> >> Subject: [Engine-devel] Time for Spring?
> >>
> >> Hi,
> >>
> >> it is rather cold in Europe, but can I ask, what's the current
> >> opinion
> >> or plans about "full" integration of Spring Framework into oVirt
> >> engine
> >> (Backend)?
> >>
> >> This is a commonly accepted integration framework among Java
> >> programmers
> >> and industry standard, which
> >> solves many pains from small to large projects. And can lead to a
> >> better
> >> understanding of the program.
> >>
> >> There are several Spring dependencies inside oVirt project, but
> >> mostly
> >> for LDAP and database communication (JDBC template).
> >>
> >> Still missing (sorry, looks like marketing, but..):
> >>
> >> - dependency injection
> >> - aspect-oriented programming (AOP)
> >> - enterprise integration patterns
> >>
> >> Is something true? :-)
> >>
> >> 1. We tried, but it is too large and overcomplicated, it can be
> >> solved
> >> better way for the project purpose
> >> 2. We tried, but we think, we need just e.g. JDBC, LDAP layer
> >> covered
> >> now
> >> 3. We would like to integrate with e.g. Hibernate soon, EJB,
> >> remoting,
> >> unit tests, integration tests, ... , probably we will need it soon
> >> 4. We understand and need dependency injection, but there are
> >> other
> >> light DI containers (Pico, Guice, JBoss Seam).
> >> etc.
> >>
> >> Still, I think there is strong potential, probably not clear
> >> today.
> >> We
> >> cannot avoid Guice on frontend side because of GWTP, but the
> >> backend
> >> lacks something.
> >> Or not?
> >>
> >> Thanks.
> >>
> >> Regards,
> >> Libor
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkolesni at redhat.com  Wed Feb  6 06:13:11 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Wed, 6 Feb 2013 01:13:11 -0500 (EST)
Subject: [Engine-devel] Import/snapshots duplicate MAC support
In-Reply-To: <1254116832.14221314.1360130333346.JavaMail.root@redhat.com>
Message-ID: <812483959.14223210.1360131191449.JavaMail.root@redhat.com>

Hi, 

The current situation dictates that if the configuration value AllowDuplicateMacAddresses 
is set to false (this is the default setting), then we block import or switching snapshots where 
a MAC address in one or more of the snapshot/ovf's virtual NICs is already used. 

Given that we don't currently give the admin any option to select otherwise, I'm not sure 
that's a very robust behaviour.. 
First of all the MAC address should be unique per network and not in the whole system (like 
it is currently). 
Furthermore, as long as in the same network there are no two virtual NIC s running with the 
same address, it is not such a bad situation. 

Therefore, I would like to propose a couple of solutions (from backend perspective): 
1. Keep blocking. 
2. Keep blocking but fix the mac pools to be per network basis. 
3. Don't block, and allow duplicate MACs in these scenarios, but block on activating a NIC 
with duplicate MAC address. Warn the user that the NIC is with duplicate MAC, and 
perhaps even unplug or unwire it so that it would be obvious that it's using someone else's 
MAC. 
4. Don't block, and give the problematic NIC a new MAC from the pool. 

Solution 1 is obviously not the greatest (hence this email). 
In my opinion, 4 is sort of a cat in a bag, since I'm not sure changing the HWADDR for the 
guest OS is really a good idea. 
Solution 2 would be nice going forward, but it just reduces the chances of an admin to come 
across this situation and doesn't solve it entirely. 
Hence, I would favour solution 3 which seems to solve the problem and allow the admin to 
choose what to do. 

Please voice your opinion, or propose an alternate solution. 


Regards, 
Mike 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130206/77f36c87/attachment.html>

From rgolan at redhat.com  Wed Feb  6 07:43:34 2013
From: rgolan at redhat.com (Roy Golan)
Date: Wed, 06 Feb 2013 09:43:34 +0200
Subject: [Engine-devel] Time for Spring?
In-Reply-To: <5110F758.60304@redhat.com>
References: <2066633252.9094534.1359983223438.JavaMail.root@redhat.com>
	<5110F758.60304@redhat.com>
Message-ID: <511209A6.80700@redhat.com>

On 02/05/2013 02:13 PM, Libor Spevak wrote:
> Thanks for the info, I just wanted to know, if there are fans of 
> Spring Framework. If we concentrate just on dependency injection 
> (CDI), probably "standard" JEE technology would be the best way.
>
> But, if we want to integrate with e.g. Hibernate/JPA, memory cache 
> (e.g. EhCache) because of DB performance, weave transparently 
> logging,monitoring and/or caching code to current classes (using 
> aspects) without changing any line of current code (if we had services 
> based on Spring beans), there are not many options. JEE container 
> independence is here not an issue and I am not sure, if development on 
> light container like Jetty would be quicker, but for integration tests 
> the framework support is strong (e.g. "simulates" services of "real" 
> JEE container).
>
> Libor
>
> On 4.2.2013 14:07, Laszlo Hornyak wrote:
>> I have seen a CDI patch from Roy that may be related to the topic.
>>
>> I do not know what the general direction is. CDI is "more standard", 
>> while it's implementations for me look heavy weight and difficult to 
>> port to small containers like tomcat or jetty.
>>
>> In general, now we only inject the Backend deathstar bean to wherever 
>> it is needed and then it is used as registry for other service 
>> objects and DAOs.
>>
>> With spring dependency injection, we could be more independent from 
>> the container, since the ioC container is comming with us to the app 
>> container. But at the other hand, ovirt is a nice big ear app, so how 
>> would you put it together as a spring app? What changes would this need?
>>
>> Laszlo
>>
>> ----- Original Message -----
>>> From: "Libor Spevak" <lspevak at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Tuesday, January 29, 2013 11:42:35 AM
>>> Subject: [Engine-devel] Time for Spring?
>>>
>>> Hi,
>>>
>>> it is rather cold in Europe, but can I ask, what's the current
>>> opinion
>>> or plans about "full" integration of Spring Framework into oVirt
>>> engine
>>> (Backend)?
>>>
>>> This is a commonly accepted integration framework among Java
>>> programmers
>>> and industry standard, which
>>> solves many pains from small to large projects. And can lead to a
>>> better
>>> understanding of the program.
>>>
>>> There are several Spring dependencies inside oVirt project, but
>>> mostly
>>> for LDAP and database communication (JDBC template).
>>>
>>> Still missing (sorry, looks like marketing, but..):
>>>
>>> - dependency injection
>>> - aspect-oriented programming (AOP)
>>> - enterprise integration patterns
>>>
>>> Is something true? :-)
>>>
>>> 1. We tried, but it is too large and overcomplicated, it can be
>>> solved
>>> better way for the project purpose
>>> 2. We tried, but we think, we need just e.g. JDBC, LDAP layer covered
>>> now
>>> 3. We would like to integrate with e.g. Hibernate soon, EJB,
>>> remoting,
>>> unit tests, integration tests, ... , probably we will need it soon
>>> 4. We understand and need dependency injection, but there are other
>>> light DI containers (Pico, Guice, JBoss Seam).
>>> etc.
>>>
Jboss weld an implementation reference the CDI JSR 299 and this is what 
is used in my CDI refactor patches.http://gerrit.ovirt.org/#/c/5575/

What we strive to achieve by using it is the separation of behavior from 
dependency resolution so its easy to
1. replace run time object with mock objects
2. dynamically switch implementation objects in runtime or
3. dynamically load plugins

>>> Still, I think there is strong potential, probably not clear today.
>>> We
>>> cannot avoid Guice on frontend side because of GWTP, but the backend
>>> lacks something.
>>> Or not?
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Libor
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lhornyak at redhat.com  Wed Feb  6 09:25:03 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 6 Feb 2013 04:25:03 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <1570564188.5808831.1359037197536.JavaMail.root@redhat.com>
Message-ID: <484301786.9968603.1360142703338.JavaMail.root@redhat.com>

Hi everyone,

I hope everyone is satisfied with the spec, please read it through for the last time and I will move it to implementation phase soon.

Thx,
Laszlo

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, January 24, 2013 3:19:57 PM
> Subject: Watchdog support Feature
> 
> Hi,
> 
> Watchdog support in engine will add watchdog to the ovirt UI and REST
> API. Watchdog cards will be mainly used in HA vm's.
> 
> http://www.ovirt.org/Features/Watchdog_engine_support
> 
> Your feedback is welcome!
> 
> Thank you,
> Laszlo


From dcaroest at redhat.com  Tue Feb  5 16:04:25 2013
From: dcaroest at redhat.com (David Caro)
Date: Tue, 05 Feb 2013 17:04:25 +0100
Subject: [Engine-devel] ovirt_engine_find_bugs failing
Message-ID: <51112D89.5050009@redhat.com>

Hi,

the ovirt_engine_find_bugs job is failing very likely to a commit you
made:
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commitdiff;h=1bf0e9f59e2208215f729cde32b0829152fef219;hp=6f238e7ee3d25fa28e85a55646bbbf739b49ef1f

Can you please take a look at it?

Thanks!

-- 
David Caro

Red Hat Czech s.r.o.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyn(ova 99/71, 612 45, Brno, Czech Republic
RHT Global #: 82-62605

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130205/13612bfe/attachment.html>

From deepakcs at linux.vnet.ibm.com  Wed Feb  6 11:12:46 2013
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Wed, 06 Feb 2013 16:42:46 +0530
Subject: [Engine-devel] NPE during addStorageServer command
Message-ID: <51123AAE.5060101@linux.vnet.ibm.com>

Hi All,
    I am trying to compile ovirt engine after applying sharad's 
glusterfs domain support patches @
http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:glusterfs,n,z

After compiling, deploying the engine ( by following the steps in 
wiki.ovirt.org/Building_Ovirt_Engine )
I connect to the weadmin GUI, add a VDSM host ( this is my own vdsm host 
with VDSM glsuter domain support ) and the host is "Up" state.

Then I select New SD->None in DC -> select my vdsm host->provide the 
args (remote path = volfileserver:volume, vfstype=glusterfs, mount => 
left blank) and click on OK

I see NPE in the engine side during addStorageServer cmd ( IIUC ) and 
then engine tries to send disconnectStorageServer, which reaches my VDSM 
host and it throws a excp, since the domain is not mounted at all.

I have captured the logs on the engien and vdsm side and attached here.

I am looking for some help on why the NPE is being seen on the engien 
side during adding a new SD ?

thanx,
deepak

-------------- next part --------------
A non-text attachment was scrubbed...
Name: oe-debug.gz
Type: application/x-gzip
Size: 2956 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130206/5d8f7e8e/attachment.gz>

From sabose at redhat.com  Wed Feb  6 11:25:05 2013
From: sabose at redhat.com (Sahina Bose)
Date: Wed, 06 Feb 2013 16:55:05 +0530
Subject: [Engine-devel] NPE during addStorageServer command
In-Reply-To: <51123AAE.5060101@linux.vnet.ibm.com>
References: <51123AAE.5060101@linux.vnet.ibm.com>
Message-ID: <51123D91.30205@redhat.com>

Looking at the code, it looks like you need a Storage helper called 
GLUSTERFSStorageHelper in package org.ovirt.engine.core.bll.storage. The 
NPE seems to be because the Storage helper is null for the storage type.

On 02/06/2013 04:42 PM, Deepak C Shetty wrote:
> Hi All,
>    I am trying to compile ovirt engine after applying sharad's 
> glusterfs domain support patches @
> http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:glusterfs,n,z 
>
>
> After compiling, deploying the engine ( by following the steps in 
> wiki.ovirt.org/Building_Ovirt_Engine )
> I connect to the weadmin GUI, add a VDSM host ( this is my own vdsm 
> host with VDSM glsuter domain support ) and the host is "Up" state.
>
> Then I select New SD->None in DC -> select my vdsm host->provide the 
> args (remote path = volfileserver:volume, vfstype=glusterfs, mount => 
> left blank) and click on OK
>
> I see NPE in the engine side during addStorageServer cmd ( IIUC ) and 
> then engine tries to send disconnectStorageServer, which reaches my 
> VDSM host and it throws a excp, since the domain is not mounted at all.
>
> I have captured the logs on the engien and vdsm side and attached here.
>
> I am looking for some help on why the NPE is being seen on the engien 
> side during adding a new SD ?
>
> thanx,
> deepak
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130206/99d2318e/attachment.html>

From yzaslavs at redhat.com  Wed Feb  6 11:52:55 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 6 Feb 2013 06:52:55 -0500 (EST)
Subject: [Engine-devel] NPE during addStorageServer command
In-Reply-To: <51123D91.30205@redhat.com>
Message-ID: <52294670.21870892.1360151575418.JavaMail.root@redhat.com>

----- Original Message -----

> From: "Sahina Bose" <sabose at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, February 6, 2013 1:25:05 PM
> Subject: Re: [Engine-devel] NPE during addStorageServer command

> Looking at the code, it looks like you need a Storage helper called
> GLUSTERFSStorageHelper in package org.ovirt.engine.core.bll.storage.
> The NPE seems to be because the Storage helper is null for the
> storage type.
> Corret, this is based on reflection - if you have an enum literal of
> X then you must have an XStorageHelper, even if it has no meaningful
> functionality of its own (as in the case of POSIXFSStorageHelper). I
> assume such class can extend BaseFsStorageHelper
> I

> 9
> On 02/06/2013 04:42 PM, Deepak C Shetty wrote:

> > Hi All,
> 
> > I am trying to compile ovirt engine after applying sharad's
> > glusterfs
> > domain support patches @
> 
> > http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:glusterfs,n,z
> 

> > After compiling, deploying the engine ( by following the steps in
> > wiki.ovirt.org/Building_Ovirt_Engine )
> 
> > I connect to the weadmin GUI, add a VDSM host ( this is my own vdsm
> > host with VDSM glsuter domain support ) and the host is "Up" state.
> 

> > Then I select New SD->None in DC -> select my vdsm host->provide
> > the
> > args (remote path = volfileserver:volume, vfstype=glusterfs, mount
> > => left blank) and click on OK
> 

> > I see NPE in the engine side during addStorageServer cmd ( IIUC )
> > and
> > then engine tries to send disconnectStorageServer, which reaches my
> > VDSM host and it throws a excp, since the domain is not mounted at
> > all.
> 

> > I have captured the logs on the engien and vdsm side and attached
> > here.
> 

> > I am looking for some help on why the NPE is being seen on the
> > engien
> > side during adding a new SD ?
> 

> > thanx,
> 
> > deepak
> 

> > _______________________________________________
> 
> > Engine-devel mailing list Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130206/a87f6186/attachment.html>

From sanjal at redhat.com  Wed Feb  6 12:06:35 2013
From: sanjal at redhat.com (Shireesh Anjal)
Date: Wed, 06 Feb 2013 17:36:35 +0530
Subject: [Engine-devel] NPE during addStorageServer command
In-Reply-To: <51123D91.30205@redhat.com>
References: <51123AAE.5060101@linux.vnet.ibm.com> <51123D91.30205@redhat.com>
Message-ID: <5112474B.1090909@redhat.com>

On 02/06/2013 04:55 PM, Sahina Bose wrote:
> Looking at the code, it looks like you need a Storage helper called 
> GLUSTERFSStorageHelper in package org.ovirt.engine.core.bll.storage. 

Which is introduced by Sharad's this patch: http://gerrit.ovirt.org/8834
I guess you don't have this patch in your local repository.

> The NPE seems to be because the Storage helper is null for the storage 
> type.
>
> On 02/06/2013 04:42 PM, Deepak C Shetty wrote:
>> Hi All,
>>    I am trying to compile ovirt engine after applying sharad's 
>> glusterfs domain support patches @
>> http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:glusterfs,n,z 
>>
>>
>> After compiling, deploying the engine ( by following the steps in 
>> wiki.ovirt.org/Building_Ovirt_Engine )
>> I connect to the weadmin GUI, add a VDSM host ( this is my own vdsm 
>> host with VDSM glsuter domain support ) and the host is "Up" state.
>>
>> Then I select New SD->None in DC -> select my vdsm host->provide the 
>> args (remote path = volfileserver:volume, vfstype=glusterfs, mount => 
>> left blank) and click on OK
>>
>> I see NPE in the engine side during addStorageServer cmd ( IIUC ) and 
>> then engine tries to send disconnectStorageServer, which reaches my 
>> VDSM host and it throws a excp, since the domain is not mounted at all.
>>
>> I have captured the logs on the engien and vdsm side and attached here.
>>
>> I am looking for some help on why the NPE is being seen on the engien 
>> side during adding a new SD ?
>>
>> thanx,
>> deepak
>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130206/05593e13/attachment.html>

From mgoldboi at redhat.com  Wed Feb  6 12:17:04 2013
From: mgoldboi at redhat.com (Moran Goldboim)
Date: Wed, 06 Feb 2013 14:17:04 +0200
Subject: [Engine-devel] Current oVirt 3.2 blockers
Message-ID: <511249C0.8020606@redhat.com>

attached is the list of current blockers as appears on version tracker 
bug [1]
maintainers please see that the below issues are fixed (unless not 
really blockers).
users, if there are any additional blockers you are facing - let's 
discuss it in the meeting today.

network
=======
Bug ID    Product    Whiteboard    Component    Assignee Status    
Resolution    Summary
906289    oVirt    network    ovirt-engine-webadmin 
alkaplan at redhat.com    POST    ---    [oVirt-webadmin] [network] Non-VM 
networks shown as VM networks on cluster attachment dialog
906291    oVirt    network    ovirt-engine-webadmin lpeer at redhat.com    
POST    ---    [oVirt-webadmin] [network] Non-VM networks not being 
detached from cluster
906383    oVirt    network    vdsm    danken at redhat.com    POST ---    
[vdsm] [setupNetworks] Error while attaching non-VM network to interface 
on Fedora 18

DWH/integration
=============
oVirt    integration    ovirt-dwh    ydary at redhat.com    POST ---    dwh 
setup fails to create db on fedora18

Gluster
======
oVirt    gluster    ovirt-engine-core    shireesh at redhat.com MODIFIED    
---    Deleting one gluster volume from gluster cli triggers deletion of 
all volumes in engine
oVirt    gluster    ovirt-engine-installer    avishwan at redhat.com 
MODIFIED    ---    engine-setup should prompt for application mode

oVirt-node
========
oVirt        ovirt-node    fdeutsch at redhat.com    ASSIGNED    --- 
configure kdump fail
oVirt        ovirt-node    mburns at redhat.com    POST    --- problem to 
make /etc/hosts persistent
oVirt        ovirt-node    fdeutsch at redhat.com    NEW    ---    DNS info 
is missed after reboot rhev-h
oVirt        ovirt-node    mburns at redhat.com    NEW    --- Migrate Node 
to Fedora 18
oVirt        ovirt-node    jboggs at redhat.com    POST    ---    [F18] 
Firewalld problem
oVirt        ovirt-node    jboggs at redhat.com    POST    ---    [F18] 
Failed to copy EFI files, no EFI Support will be included.
oVirt        ovirt-node    mburns at redhat.com    POST    ---    [F18] 
snmpd.conf wasn't found
oVirt        ovirt-node    jboggs at redhat.com    POST    ---    [F18] 
useradd: group 'sfcb' does not exist
oVirt        ovirt-node    jboggs at redhat.com    POST    ---    [F18] 
SELinux problems
oVirt        ovirt-node    fdeutsch at redhat.com    POST    --- [F18] All 
qemu architectures are pulled in and increase the size of the image / 
What arches are required?
oVirt        ovirt-node    mburns at redhat.com    NEW    ---    [F18] 
journal is full of collectd messages


please be ready with it's status for today's weekly meeting, packages 
should be built by the end of this week fixing the above bugs

I'm still missing some packages on the beta repo:
-dwh/reports
-docs
-engine-sdk-java

please let us know it's status with respect to 3.2 release.


[1] 
https://bugzilla.redhat.com/showdependencytree.cgi?id=881006&hide_resolved=1

thanks,
Moran.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130206/aac72304/attachment.html>

From awels at redhat.com  Wed Feb  6 13:40:01 2013
From: awels at redhat.com (Alexander Wels)
Date: Wed, 06 Feb 2013 08:40:01 -0500
Subject: [Engine-devel] Latest open jdk and JBOSS
Message-ID: <20004307.Zh14upPkLs@awels>

Just an FYI there is an issue with the latest openjdk and JBOSS which causes 
JBOSS to NOT start.

Details can be found here:
https://community.jboss.org/message/796347#796347

I did upgrade yesterday and I am having the exact same issue.
For now do not upgrade your open jdk to the latest version.

Alexander.


From danken at redhat.com  Wed Feb  6 14:49:02 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Wed, 6 Feb 2013 16:49:02 +0200
Subject: [Engine-devel] Current oVirt 3.2 blockers
In-Reply-To: <511249C0.8020606@redhat.com>
References: <511249C0.8020606@redhat.com>
Message-ID: <20130206144902.GD32289@redhat.com>

On Wed, Feb 06, 2013 at 02:17:04PM +0200, Moran Goldboim wrote:
> attached is the list of current blockers as appears on version
> tracker bug [1]
> maintainers please see that the below issues are fixed (unless not
> really blockers).
> users, if there are any additional blockers you are facing - let's
> discuss it in the meeting today.
> 
> network
> =======
> Bug ID    Product    Whiteboard    Component    Assignee Status
> Resolution    Summary
> 906289    oVirt    network    ovirt-engine-webadmin
> alkaplan at redhat.com    POST    ---    [oVirt-webadmin] [network]
> Non-VM networks shown as VM networks on cluster attachment dialog
> 906291    oVirt    network    ovirt-engine-webadmin lpeer at redhat.com
> POST    ---    [oVirt-webadmin] [network] Non-VM networks not being
> detached from cluster

These two bugs have patches, needing only merge to master (and later to
ovirt-3.2). Alona, could you take care of them asap?

> 906383    oVirt    network    vdsm    danken at redhat.com    POST ---
> [vdsm] [setupNetworks] Error while attaching non-VM network to
> interface on Fedora 18

Already pushed to ovirt-3.2 branch, would be in next vdsm build.



From sabose at redhat.com  Thu Feb  7 04:32:39 2013
From: sabose at redhat.com (Sahina Bose)
Date: Thu, 07 Feb 2013 10:02:39 +0530
Subject: [Engine-devel] NPE during addStorageServer command
In-Reply-To: <5112474B.1090909@redhat.com>
References: <51123AAE.5060101@linux.vnet.ibm.com> <51123D91.30205@redhat.com>
	<5112474B.1090909@redhat.com>
Message-ID: <51132E67.4030707@redhat.com>


On 02/06/2013 05:36 PM, Shireesh Anjal wrote:
> On 02/06/2013 04:55 PM, Sahina Bose wrote:
>> Looking at the code, it looks like you need a Storage helper called 
>> GLUSTERFSStorageHelper in package org.ovirt.engine.core.bll.storage. 
>
> Which is introduced by Sharad's this patch: http://gerrit.ovirt.org/8834
> I guess you don't have this patch in your local repository.
In this patch, you will need to rename the file as it's case sensitive 
on linux- GlusterFsStorageHelper should be GLUSTERFSStorageHelper.

Hope this helps,
cheers
sahina
>
>> The NPE seems to be because the Storage helper is null for the 
>> storage type.
>>
>> On 02/06/2013 04:42 PM, Deepak C Shetty wrote:
>>> Hi All,
>>>    I am trying to compile ovirt engine after applying sharad's 
>>> glusterfs domain support patches @
>>> http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:glusterfs,n,z 
>>>
>>>
>>> After compiling, deploying the engine ( by following the steps in 
>>> wiki.ovirt.org/Building_Ovirt_Engine )
>>> I connect to the weadmin GUI, add a VDSM host ( this is my own vdsm 
>>> host with VDSM glsuter domain support ) and the host is "Up" state.
>>>
>>> Then I select New SD->None in DC -> select my vdsm host->provide the 
>>> args (remote path = volfileserver:volume, vfstype=glusterfs, mount 
>>> => left blank) and click on OK
>>>
>>> I see NPE in the engine side during addStorageServer cmd ( IIUC ) 
>>> and then engine tries to send disconnectStorageServer, which reaches 
>>> my VDSM host and it throws a excp, since the domain is not mounted 
>>> at all.
>>>
>>> I have captured the logs on the engien and vdsm side and attached here.
>>>
>>> I am looking for some help on why the NPE is being seen on the 
>>> engien side during adding a new SD ?
>>>
>>> thanx,
>>> deepak
>>>
>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130207/8a740270/attachment.html>

From yzaslavs at redhat.com  Thu Feb  7 04:38:58 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 6 Feb 2013 23:38:58 -0500 (EST)
Subject: [Engine-devel] NPE during addStorageServer command
In-Reply-To: <51132E67.4030707@redhat.com>
Message-ID: <2023670801.22446381.1360211938643.JavaMail.root@redhat.com>

----- Original Message -----

> From: "Sahina Bose" <sabose at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, February 7, 2013 6:32:39 AM
> Subject: Re: [Engine-devel] NPE during addStorageServer command

> On 02/06/2013 05:36 PM, Shireesh Anjal wrote:

> > On 02/06/2013 04:55 PM, Sahina Bose wrote:
> 

> > > Looking at the code, it looks like you need a Storage helper
> > > called
> > > GLUSTERFSStorageHelper in package
> > > org.ovirt.engine.core.bll.storage.
> > 
> 
> > Which is introduced by Sharad's this patch:
> > http://gerrit.ovirt.org/8834
> 
> > I guess you don't have this patch in your local repository.
> 

> In this patch, you will need to rename the file as it's case
> sensitive on linux- GlusterFsStorageHelper should be
> GLUSTERFSStorageHelper.ks Sa
> Thanks Sahina

> Good Comment, I added it to the patch review

> Hope this helps,
> cheers
> sahina

> > > The NPE seems to be because the Storage helper is null for the
> > > storage type.
> > 
> 

> > > On 02/06/2013 04:42 PM, Deepak C Shetty wrote:
> > 
> 

> > > > Hi All,
> > > 
> > 
> 
> > > > I am trying to compile ovirt engine after applying sharad's
> > > > glusterfs
> > > > domain support patches @
> > > 
> > 
> 
> > > > http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:glusterfs,n,z
> > > 
> > 
> 

> > > > After compiling, deploying the engine ( by following the steps
> > > > in
> > > > wiki.ovirt.org/Building_Ovirt_Engine )
> > > 
> > 
> 
> > > > I connect to the weadmin GUI, add a VDSM host ( this is my own
> > > > vdsm
> > > > host with VDSM glsuter domain support ) and the host is "Up"
> > > > state.
> > > 
> > 
> 

> > > > Then I select New SD->None in DC -> select my vdsm
> > > > host->provide
> > > > the
> > > > args (remote path = volfileserver:volume, vfstype=glusterfs,
> > > > mount
> > > > => left blank) and click on OK
> > > 
> > 
> 

> > > > I see NPE in the engine side during addStorageServer cmd ( IIUC
> > > > )
> > > > and
> > > > then engine tries to send disconnectStorageServer, which
> > > > reaches
> > > > my
> > > > VDSM host and it throws a excp, since the domain is not mounted
> > > > at
> > > > all.
> > > 
> > 
> 

> > > > I have captured the logs on the engien and vdsm side and
> > > > attached
> > > > here.
> > > 
> > 
> 

> > > > I am looking for some help on why the NPE is being seen on the
> > > > engien
> > > > side during adding a new SD ?
> > > 
> > 
> 

> > > > thanx,
> > > 
> > 
> 
> > > > deepak
> > > 
> > 
> 

> > > > _______________________________________________
> > > 
> > 
> 
> > > > Engine-devel mailing list Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> 
> > > _______________________________________________
> > 
> 
> > > Engine-devel mailing list Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> > _______________________________________________
> 
> > Engine-devel mailing list Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130206/706bf96c/attachment.html>

From eedri at redhat.com  Thu Feb  7 08:39:47 2013
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 7 Feb 2013 03:39:47 -0500 (EST)
Subject: [Engine-devel] Proposing Kiril nesenko as power user for "ovirt
	engine tools"
Message-ID: <879569406.1742577.1360226387957.JavaMail.root@redhat.com>

Hi,

I would like to propose kiril nesenko as 'jenkins power user' for ovirt engine tools.
These tools indlude iso uploader, log collector, image uploader and others. 

Kiril is very involved in building and running Jenkins jobs on the rhevm product,
and maintains & package the ovirt tools currently.
As part of being power user on jenkins.ovirt.org, he will create new jobs to build and release tools for the various OS supported.

I vote +1 as i personally know kiril and he's experience. 

Thansk,

Eyal.


From deepakcs at linux.vnet.ibm.com  Thu Feb  7 09:11:10 2013
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Thu, 07 Feb 2013 14:41:10 +0530
Subject: [Engine-devel] NPE during addStorageServer command
In-Reply-To: <51132E67.4030707@redhat.com>
References: <51123AAE.5060101@linux.vnet.ibm.com> <51123D91.30205@redhat.com>
	<5112474B.1090909@redhat.com> <51132E67.4030707@redhat.com>
Message-ID: <51136FAE.3050609@linux.vnet.ibm.com>

On 02/07/2013 10:02 AM, Sahina Bose wrote:
>
> On 02/06/2013 05:36 PM, Shireesh Anjal wrote:
>> On 02/06/2013 04:55 PM, Sahina Bose wrote:
>>> Looking at the code, it looks like you need a Storage helper called 
>>> GLUSTERFSStorageHelper in package org.ovirt.engine.core.bll.storage. 
>>
>> Which is introduced by Sharad's this patch: http://gerrit.ovirt.org/8834
>> I guess you don't have this patch in your local repository.
> In this patch, you will need to rename the file as it's case sensitive 
> on linux- GlusterFsStorageHelper should be GLUSTERFSStorageHelper.


Thanks Sahina, i will give that a try.

Shireesh, i have this patch in my local repo, but 'guess it won't 
matter, due to the issue pointed by Sahina.

I will try the fix proposed and get back.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130207/2123c599/attachment.html>

From tjelinek at redhat.com  Thu Feb  7 09:18:36 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Thu, 7 Feb 2013 04:18:36 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <1678216043.10869309.1360080840294.JavaMail.root@redhat.com>
Message-ID: <207221396.11726861.1360228716061.JavaMail.root@redhat.com>

I have completed the "User Interface" part (e.g. where the Images, Instance Types and Templates main tabs will be).
http://www.ovirt.org/Features/Instance_Types#User_Interface

Your comments are welcome,
Tomas

----- Original Message -----
From: "Tomas Jelinek" <tjelinek at redhat.com>
To: "Oved Ourfalli" <ovedo at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Tuesday, February 5, 2013 5:14:00 PM
Subject: Re: [Engine-devel] Instance Types Feature

> 1. Why do we need a new set of permissions for "Create Instance" and "Instance Owner"? Aren't the VmCreator role and the UserVmManager role enough in these use-cases?
so checked this with Andy:
- Create Instance: it is a permission to actually see the instance types in the list of instance types when creating the VM and to be able to create a VM from that instance type
- Instance Owner: if the user has this permission, he can edit the fields marked as "Basic User" in the table in the wiki (but not the others)

----- Original Message -----
From: "Oved Ourfalli" <ovedo at redhat.com>
To: "Tomas Jelinek" <tjelinek at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Tuesday, January 29, 2013 2:54:13 PM
Subject: Re: [Engine-devel]  Instance Types Feature

Some questions:
1. Why do we need a new set of permissions for "Create Instance" and "Instance Owner"? Aren't the VmCreator role and the UserVmManager role enough in these use-cases?
2. iiuc, the internal implementation of instance types and images will be done using templates. However, I guess we plan to expose instance types and images as REST resources, right?

Thank you,
Oved

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, January 22, 2013 3:09:51 PM
> Subject: [Engine-devel]  Instance Types Feature
> 
> Hi All,
> 
> this is the proposed new feature called instance types:
> http://www.ovirt.org/Features/Instance_Types
> 
> Long story short - it should basically split the VM template into:
> - "hardware profile" called instance types
> - "software profile" called image
> 
> This should enable to do something like: Create a new "small" VM and
> attach a disk with "RHEL + Postgres" installed.
> 
> Any comments are more than welcome!
> 
> Tomas
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From ovedo at redhat.com  Thu Feb  7 09:27:33 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Thu, 7 Feb 2013 04:27:33 -0500 (EST)
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <1678216043.10869309.1360080840294.JavaMail.root@redhat.com>
Message-ID: <1455770328.22014228.1360229253222.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, February 5, 2013 6:14:00 PM
> Subject: Re: [Engine-devel] Instance Types Feature
> 
> > 1. Why do we need a new set of permissions for "Create Instance"
> > and "Instance Owner"? Aren't the VmCreator role and the
> > UserVmManager role enough in these use-cases?
> so checked this with Andy:
> - Create Instance: it is a permission to actually see the instance
> types in the list of instance types when creating the VM and to be
> able to create a VM from that instance type
Wouldn't we want the instance types to be public, limiting the user on resources according to his Quota?
What worries me is that you currently need VmCreator role on a DC in order to be able to create VMs there, add disks, and etc.
So, now you would also need to have a CreateInstance permission.
And, in addition, you also need the right Quota.

Why not simplifying things, saying all instance types are public, and you only need VmCreator role, and the Quota for your new resources?

> - Instance Owner: if the user has this permission, he can edit the
> fields marked as "Basic User" in the table in the wiki (but not the
> others)
> 
> ----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, January 29, 2013 2:54:13 PM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> Some questions:
> 1. Why do we need a new set of permissions for "Create Instance" and
> "Instance Owner"? Aren't the VmCreator role and the UserVmManager
> role enough in these use-cases?
> 2. iiuc, the internal implementation of instance types and images
> will be done using templates. However, I guess we plan to expose
> instance types and images as REST resources, right?
> 
> Thank you,
> Oved
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, January 22, 2013 3:09:51 PM
> > Subject: [Engine-devel]  Instance Types Feature
> > 
> > Hi All,
> > 
> > this is the proposed new feature called instance types:
> > http://www.ovirt.org/Features/Instance_Types
> > 
> > Long story short - it should basically split the VM template into:
> > - "hardware profile" called instance types
> > - "software profile" called image
> > 
> > This should enable to do something like: Create a new "small" VM
> > and
> > attach a disk with "RHEL + Postgres" installed.
> > 
> > Any comments are more than welcome!
> > 
> > Tomas
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From pstehlik at redhat.com  Thu Feb  7 09:54:07 2013
From: pstehlik at redhat.com (pstehlik)
Date: Thu, 07 Feb 2013 10:54:07 +0100
Subject: [Engine-devel] Instance Types Feature
In-Reply-To: <207221396.11726861.1360228716061.JavaMail.root@redhat.com>
References: <207221396.11726861.1360228716061.JavaMail.root@redhat.com>
Message-ID: <1577375.nJuUsRfaSd@ps-x230.brq.redhat.com>

 Hi Tomas,
I've couple of comments, mainly from User POV.
 Currently:
  - we've many useful information, but only on Template tab. Once user 
(administrator) wants create new VM, he HAVE TO go to template tab, 
remember/write down name of template & then went back to VM tab & create Vm 
from desired template. 
 New after this change:
 - Administrator will go to tree - clicks few times (or just once in case is 
expanded by default), then to DC then to Template tab.

Overall at lest +1 click => almost EACH time someone needs to create VM?

 What if we bring these changes?
 - Create VM window will show as much info about template as possible 
  - Description, NICs, list pf apps!  (there is plenty useless space in gray 
area on top of this window above/top/between {DC & CLUSTER})
 - as much info as possible (VM subtab on Hosts/Templates main tabs)
 - links between entities which are leading to different entities - once I'm in 
template VM subtab, why I can't click to button & be transferred to VM tab to 
see all info about this VM?

After mentioned changes I don't really care in which layer or how deep tabs 
are. Currently we're adding/deleting tabs in each release in a loop.
P.



On Thursday 07 of February 2013 04:18:36 Tomas Jelinek wrote:
> I have completed the "User Interface" part (e.g. where the Images, Instance
> Types and Templates main tabs will be).
> http://www.ovirt.org/Features/Instance_Types#User_Interface
> 
> Your comments are welcome,
> Tomas
> 
> ----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, February 5, 2013 5:14:00 PM
> Subject: Re: [Engine-devel] Instance Types Feature
> 
> > 1. Why do we need a new set of permissions for "Create Instance" and
> > "Instance Owner"? Aren't the VmCreator role and the UserVmManager role
> > enough in these use-cases?
> so checked this with Andy:
> - Create Instance: it is a permission to actually see the instance types in
> the list of instance types when creating the VM and to be able to create a
> VM from that instance type - Instance Owner: if the user has this
> permission, he can edit the fields marked as "Basic User" in the table in
> the wiki (but not the others)
> 
> ----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, January 29, 2013 2:54:13 PM
> Subject: Re: [Engine-devel]  Instance Types Feature
> 
> Some questions:
> 1. Why do we need a new set of permissions for "Create Instance" and
> "Instance Owner"? Aren't the VmCreator role and the UserVmManager role
> enough in these use-cases? 2. iiuc, the internal implementation of instance
> types and images will be done using templates. However, I guess we plan to
> expose instance types and images as REST resources, right?
> 
> Thank you,
> Oved
> 
> ----- Original Message -----
> 
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, January 22, 2013 3:09:51 PM
> > Subject: [Engine-devel]  Instance Types Feature
> > 
> > Hi All,
> > 
> > this is the proposed new feature called instance types:
> > http://www.ovirt.org/Features/Instance_Types
> > 
> > Long story short - it should basically split the VM template into:
> > - "hardware profile" called instance types
> > - "software profile" called image
> > 
> > This should enable to do something like: Create a new "small" VM and
> > attach a disk with "RHEL + Postgres" installed.
> > 
> > Any comments are more than welcome!
> > 
> > Tomas
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From mbetak at redhat.com  Thu Feb  7 10:08:40 2013
From: mbetak at redhat.com (Martin Betak)
Date: Thu, 7 Feb 2013 05:08:40 -0500 (EST)
Subject: [Engine-devel] engine-config behaviour on -g by alternateKey
In-Reply-To: <652314201.22562888.1360230591246.JavaMail.root@redhat.com>
Message-ID: <1444598951.22571818.1360231720597.JavaMail.root@redhat.com>

Hi All,

I've been working on the ability to set keyboard layout for VNC server as per each individual VM. Currently the only option is to use engine-config to set the value globally, e.g. engine-config -s VncKeyboardLayout=en-us. After adding this option to database and respective entities there were raised valid concerns about why is this option called VncKeyboardLayout and not just KeyboardLayout as it applies to SPICE equally (note that also VDSM calls this config value as 'keyboardLayout'). 
So to achieve consistency I also renamed it in engine-config.properties and set KeyboardLayout.alternateKey=VncKeyboardLayout. This indeed works for setting (engine-config -s VncKeyboardLayout=en-us sets KeyboardLayout and engine-config -g KeyboardLayout works but it is unable to read the value by the alternateKey) 
engine-config -g VncKeyboardLayout fails with "no such entry with default version" in the method EngineConfigLogic.printAllValuesForKey as it is passing the user given key name directly to database which returns zero results. Setter methods such as EngineConfigLogic.persistValue use the entity ConfigKey constructed from the user given key-name which correctly constructs appropriate ConfigKey even when given alternateKey name. 

So I wanted to ask whether this is the desired behaviour (set by alternateKey name but get only by the primary) or is this a bug? I have also simple patch that fixes this and enables also getting the config value by alternateKey.

Thank you


From ilvovsky at redhat.com  Thu Feb  7 10:24:53 2013
From: ilvovsky at redhat.com (Igor Lvovsky)
Date: Thu, 7 Feb 2013 05:24:53 -0500 (EST)
Subject: [Engine-devel] Proposing Kiril nesenko as power user for
	"ovirt	engine tools"
In-Reply-To: <879569406.1742577.1360226387957.JavaMail.root@redhat.com>
Message-ID: <187864670.24028.1360232693230.JavaMail.root@redhat.com>

definitely +1


----- Original Message -----
From: "Eyal Edri" <eedri at redhat.com>
To: "infra" <infra at ovirt.org>
Cc: "knesenko" <knesenko at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
Sent: Thursday, February 7, 2013 10:39:47 AM
Subject: [Engine-devel] Proposing Kiril nesenko as power user for "ovirt	engine tools"

Hi,

I would like to propose kiril nesenko as 'jenkins power user' for ovirt engine tools.
These tools indlude iso uploader, log collector, image uploader and others. 

Kiril is very involved in building and running Jenkins jobs on the rhevm product,
and maintains & package the ovirt tools currently.
As part of being power user on jenkins.ovirt.org, he will create new jobs to build and release tools for the various OS supported.

I vote +1 as i personally know kiril and he's experience. 

Thansk,

Eyal.
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From amureini at redhat.com  Thu Feb  7 10:49:06 2013
From: amureini at redhat.com (Allon Mureinik)
Date: Thu, 7 Feb 2013 05:49:06 -0500 (EST)
Subject: [Engine-devel] Proposing Kiril nesenko as power user for
	"ovirt	engine tools"
In-Reply-To: <879569406.1742577.1360226387957.JavaMail.root@redhat.com>
Message-ID: <368063679.1815696.1360234146475.JavaMail.root@redhat.com>

+1

----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "infra" <infra at ovirt.org>
> Cc: "knesenko" <knesenko at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, February 7, 2013 10:39:47 AM
> Subject: [Engine-devel] Proposing Kiril nesenko as power user for "ovirt	engine tools"
> 
> Hi,
> 
> I would like to propose kiril nesenko as 'jenkins power user' for
> ovirt engine tools.
> These tools indlude iso uploader, log collector, image uploader and
> others.
> 
> Kiril is very involved in building and running Jenkins jobs on the
> rhevm product,
> and maintains & package the ovirt tools currently.
> As part of being power user on jenkins.ovirt.org, he will create new
> jobs to build and release tools for the various OS supported.
> 
> I vote +1 as i personally know kiril and he's experience.
> 
> Thansk,
> 
> Eyal.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Thu Feb  7 12:12:03 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 07 Feb 2013 14:12:03 +0200
Subject: [Engine-devel] engine-config behaviour on -g by alternateKey
In-Reply-To: <1444598951.22571818.1360231720597.JavaMail.root@redhat.com>
References: <1444598951.22571818.1360231720597.JavaMail.root@redhat.com>
Message-ID: <51139A13.9050209@redhat.com>

On 07/02/2013 12:08, Martin Betak wrote:
> Hi All,
>
> I've been working on the ability to set keyboard layout for VNC server as per each individual VM. Currently the only option is to use engine-config to set the value globally, e.g. engine-config -s VncKeyboardLayout=en-us. After adding this option to database and respective entities there were raised valid concerns about why is this option called VncKeyboardLayout and not just KeyboardLayout as it applies to SPICE equally (note that also VDSM calls this config value as 'keyboardLayout').
> So to achieve consistency I also renamed it in engine-config.properties and set KeyboardLayout.alternateKey=VncKeyboardLayout. This indeed works for setting (engine-config -s VncKeyboardLayout=en-us sets KeyboardLayout and engine-config -g KeyboardLayout works but it is unable to read the value by the alternateKey)
> engine-config -g VncKeyboardLayout fails with "no such entry with default version" in the method EngineConfigLogic.printAllValuesForKey as it is passing the user given key name directly to database which returns zero results. Setter methods such as EngineConfigLogic.persistValue use the entity ConfigKey constructed from the user given key-name which correctly constructs appropriate ConfigKey even when given alternateKey name.
>
> So I wanted to ask whether this is the desired behaviour (set by alternateKey name but get only by the primary) or is this a bug? I have also simple patch that fixes this and enables also getting the config value by alternateKey.
>
> Thank you
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

Make sense that if we allow alternate names for backward 
compatibility/etc., -g will work for them as well, so my view is worth 
fixing in the config tool.

but, are you sure it affects spice? i thought spice has its own handling 
for this.


From msalem at redhat.com  Thu Feb  7 12:21:24 2013
From: msalem at redhat.com (Muli Salem)
Date: Thu, 7 Feb 2013 07:21:24 -0500 (EST)
Subject: [Engine-devel] Import/snapshots duplicate MAC support
In-Reply-To: <812483959.14223210.1360131191449.JavaMail.root@redhat.com>
Message-ID: <11476663.121.1360239611966.JavaMail.msalem@dhcp-1-23.tlv.redhat.com>



----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, 6 February, 2013 8:13:11 AM
> Subject: [Engine-devel] Import/snapshots duplicate MAC support
> 
> 
> 
> Hi,
> 
> The current situation dictates that if the configuration value
> AllowDuplicateMacAddresses
> is set to false (this is the default setting), then we block import
> or switching snapshots where
> a MAC address in one or more of the snapshot/ovf's virtual NICs is
> already used.
> 
> Given that we don't currently give the admin any option to select
> otherwise, I'm not sure
> that's a very robust behaviour..
> First of all the MAC address should be unique per network and not in
> the whole system (like
> it is currently).
> Furthermore, as long as in the same network there are no two virtual
> NICs running with the
> same address, it is not such a bad situation.
> 
> Therefore, I would like to propose a couple of solutions (from
> backend perspective):
> 1. Keep blocking.
> 2. Keep blocking but fix the mac pools to be per network basis.
> 3. Don't block, and allow duplicate MACs in these scenarios, but
> block on activating a NIC
> with duplicate MAC address. Warn the user that the NIC is with
> duplicate MAC, and
> perhaps even unplug or unwire it so that it would be obvious that
> it's using someone else's
> MAC.
> 4. Don't block, and give the problematic NIC a new MAC from the pool.
> 
> Solution 1 is obviously not the greatest (hence this email).
> In my opinion, 4 is sort of a cat in a bag, since I'm not sure
> changing the HWADDR for the
> guest OS is really a good idea.
> Solution 2 would be nice going forward, but it just reduces the
> chances of an admin to come
> across this situation and doesn't solve it entirely.
> Hence, I would favour solution 3 which seems to solve the problem and
> allow the admin to
> choose what to do.
> 
> Please voice your opinion, or propose an alternate solution.

Another solution would be to perform the action without adding the problematic vNic, and notify the user about it.

Overall, I am in favor of solution 3 as well.

> 
> 
> Regards,
> Mike
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mbetak at redhat.com  Thu Feb  7 12:59:31 2013
From: mbetak at redhat.com (Martin Betak)
Date: Thu, 7 Feb 2013 07:59:31 -0500 (EST)
Subject: [Engine-devel] engine-config behaviour on -g by alternateKey
In-Reply-To: <51139A13.9050209@redhat.com>
Message-ID: <554674004.22870672.1360241971070.JavaMail.root@redhat.com>



----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: "Martin Betak" <mbetak at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Thursday, February 7, 2013 1:12:03 PM
Subject: Re: [Engine-devel] engine-config behaviour on -g by alternateKey

On 07/02/2013 12:08, Martin Betak wrote:
> Hi All,
>
> I've been working on the ability to set keyboard layout for VNC server as per each individual VM. Currently the only option is to use engine-config to set the value globally, e.g. engine-config -s VncKeyboardLayout=en-us. After adding this option to database and respective entities there were raised valid concerns about why is this option called VncKeyboardLayout and not just KeyboardLayout as it applies to SPICE equally (note that also VDSM calls this config value as 'keyboardLayout').
> So to achieve consistency I also renamed it in engine-config.properties and set KeyboardLayout.alternateKey=VncKeyboardLayout. This indeed works for setting (engine-config -s VncKeyboardLayout=en-us sets KeyboardLayout and engine-config -g KeyboardLayout works but it is unable to read the value by the alternateKey)
> engine-config -g VncKeyboardLayout fails with "no such entry with default version" in the method EngineConfigLogic.printAllValuesForKey as it is passing the user given key name directly to database which returns zero results. Setter methods such as EngineConfigLogic.persistValue use the entity ConfigKey constructed from the user given key-name which correctly constructs appropriate ConfigKey even when given alternateKey name.
>
> So I wanted to ask whether this is the desired behaviour (set by alternateKey name but get only by the primary) or is this a bug? I have also simple patch that fixes this and enables also getting the config value by alternateKey.
>
> Thank you
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

Make sense that if we allow alternate names for backward 
compatibility/etc., -g will work for them as well, so my view is worth 
fixing in the config tool.

but, are you sure it affects spice? i thought spice has its own handling 
for this.



I traced the appropriate setting to VDSM code which builds the libvirt xml configuration and it seems that the option VNC/spice is orthogonal to the keyboard layout - i.e. you chooose your connection type VNC/spice and then you choose your keyboard layout independently - you can see this exact behaviour in virt-manager for example in the Display Spice panel. Also the only place where ConfigValues.VncKeyboardLayout is used is in VmInfoBuilderBase to set a config property called VdsProperties.KeyboardLayout :-)

So should I include the patch for engine-config (very small local change - only 3 lines) in my current patch http://gerrit.ovirt.org/#/c/11314/ ?

Thanks


From iheim at redhat.com  Thu Feb  7 13:07:29 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 07 Feb 2013 15:07:29 +0200
Subject: [Engine-devel] engine-config behaviour on -g by alternateKey
In-Reply-To: <554674004.22870672.1360241971070.JavaMail.root@redhat.com>
References: <554674004.22870672.1360241971070.JavaMail.root@redhat.com>
Message-ID: <5113A711.6000502@redhat.com>

On 07/02/2013 14:59, Martin Betak wrote:
>
>
> ----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Martin Betak" <mbetak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, February 7, 2013 1:12:03 PM
> Subject: Re: [Engine-devel] engine-config behaviour on -g by alternateKey
>
> On 07/02/2013 12:08, Martin Betak wrote:
>> Hi All,
>>
>> I've been working on the ability to set keyboard layout for VNC server as per each individual VM. Currently the only option is to use engine-config to set the value globally, e.g. engine-config -s VncKeyboardLayout=en-us. After adding this option to database and respective entities there were raised valid concerns about why is this option called VncKeyboardLayout and not just KeyboardLayout as it applies to SPICE equally (note that also VDSM calls this config value as 'keyboardLayout').
>> So to achieve consistency I also renamed it in engine-config.properties and set KeyboardLayout.alternateKey=VncKeyboardLayout. This indeed works for setting (engine-config -s VncKeyboardLayout=en-us sets KeyboardLayout and engine-config -g KeyboardLayout works but it is unable to read the value by the alternateKey)
>> engine-config -g VncKeyboardLayout fails with "no such entry with default version" in the method EngineConfigLogic.printAllValuesForKey as it is passing the user given key name directly to database which returns zero results. Setter methods such as EngineConfigLogic.persistValue use the entity ConfigKey constructed from the user given key-name which correctly constructs appropriate ConfigKey even when given alternateKey name.
>>
>> So I wanted to ask whether this is the desired behaviour (set by alternateKey name but get only by the primary) or is this a bug? I have also simple patch that fixes this and enables also getting the config value by alternateKey.
>>
>> Thank you
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
> Make sense that if we allow alternate names for backward
> compatibility/etc., -g will work for them as well, so my view is worth
> fixing in the config tool.
>
> but, are you sure it affects spice? i thought spice has its own handling
> for this.
>
>
>
> I traced the appropriate setting to VDSM code which builds the libvirt xml configuration and it seems that the option VNC/spice is orthogonal to the keyboard layout - i.e. you chooose your connection type VNC/spice and then you choose your keyboard layout independently - you can see this exact behaviour in virt-manager for example in the Display Spice panel. Also the only place where ConfigValues.VncKeyboardLayout is used is in VmInfoBuilderBase to set a config property called VdsProperties.KeyboardLayout :-)
>
> So should I include the patch for engine-config (very small local change - only 3 lines) in my current patch http://gerrit.ovirt.org/#/c/11314/ ?
>
> Thanks
>

please indent your replies to be easier to see what your reply is.
please check with spice developers, i remember something about in spice 
the keyboard layout is handled by spice based on client keyboard layout, 
regardless of the qemu parameter.
btw, iirc, qemu now supports enabling both spice an vnc. i think we 
should consider enabling both.

and yes, seems like a reasonable patch, but should be a separate one to 
yours (yours should depend on it i guess)


From masayag at redhat.com  Thu Feb  7 17:00:39 2013
From: masayag at redhat.com (Moti Asayag)
Date: Thu, 07 Feb 2013 19:00:39 +0200
Subject: [Engine-devel] Proposing Kiril nesenko as power user for "ovirt
 engine tools"
In-Reply-To: <879569406.1742577.1360226387957.JavaMail.root@redhat.com>
References: <879569406.1742577.1360226387957.JavaMail.root@redhat.com>
Message-ID: <5113DDB7.6020809@redhat.com>

On 02/07/2013 10:39 AM, Eyal Edri wrote:
> Hi,
> 
> I would like to propose kiril nesenko as 'jenkins power user' for ovirt engine tools.
> These tools indlude iso uploader, log collector, image uploader and others. 
> 
> Kiril is very involved in building and running Jenkins jobs on the rhevm product,
> and maintains & package the ovirt tools currently.
> As part of being power user on jenkins.ovirt.org, he will create new jobs to build and release tools for the various OS supported.
> 
> I vote +1 as i personally know kiril and he's experience. 
> 

+1 as well.

> Thansk,
> 
> Eyal.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From eedri at redhat.com  Thu Feb  7 21:47:08 2013
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 7 Feb 2013 16:47:08 -0500 (EST)
Subject: [Engine-devel] Proposing Kiril nesenko as power user for "ovirt
 engine tools"
In-Reply-To: <5113DDB7.6020809@redhat.com>
Message-ID: <934637753.487116.1360273628361.JavaMail.root@redhat.com>

Seems like enough +1 and not objections,

Kiril, i will send you credentials in private.

thanks,

eyal.

----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Eyal Edri" <eedri at redhat.com>
> Cc: "infra" <infra at ovirt.org>, "knesenko" <knesenko at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, February 7, 2013 7:00:39 PM
> Subject: Re: [Engine-devel] Proposing Kiril nesenko as power user for "ovirt engine tools"
> 
> On 02/07/2013 10:39 AM, Eyal Edri wrote:
> > Hi,
> > 
> > I would like to propose kiril nesenko as 'jenkins power user' for
> > ovirt engine tools.
> > These tools indlude iso uploader, log collector, image uploader and
> > others.
> > 
> > Kiril is very involved in building and running Jenkins jobs on the
> > rhevm product,
> > and maintains & package the ovirt tools currently.
> > As part of being power user on jenkins.ovirt.org, he will create
> > new jobs to build and release tools for the various OS supported.
> > 
> > I vote +1 as i personally know kiril and he's experience.
> > 
> 
> +1 as well.
> 
> > Thansk,
> > 
> > Eyal.
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> 


From deepakcs at linux.vnet.ibm.com  Fri Feb  8 17:17:54 2013
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Fri, 08 Feb 2013 22:47:54 +0530
Subject: [Engine-devel] NPE during addStorageServer command [SOLVED}
In-Reply-To: <51136FAE.3050609@linux.vnet.ibm.com>
References: <51123AAE.5060101@linux.vnet.ibm.com> <51123D91.30205@redhat.com>
	<5112474B.1090909@redhat.com> <51132E67.4030707@redhat.com>
	<51136FAE.3050609@linux.vnet.ibm.com>
Message-ID: <51153342.9050703@linux.vnet.ibm.com>

On 02/07/2013 02:41 PM, Deepak C Shetty wrote:
> On 02/07/2013 10:02 AM, Sahina Bose wrote:
>>
>> On 02/06/2013 05:36 PM, Shireesh Anjal wrote:
>>> On 02/06/2013 04:55 PM, Sahina Bose wrote:
>>>> Looking at the code, it looks like you need a Storage helper called 
>>>> GLUSTERFSStorageHelper in package org.ovirt.engine.core.bll.storage. 
>>>
>>> Which is introduced by Sharad's this patch: http://gerrit.ovirt.org/8834
>>> I guess you don't have this patch in your local repository.
>> In this patch, you will need to rename the file as it's case 
>> sensitive on linux- GlusterFsStorageHelper should be 
>> GLUSTERFSStorageHelper.
>
>
> Thanks Sahina, i will give that a try.
>
> Shireesh, i have this patch in my local repo, but 'guess it won't 
> matter, due to the issue pointed by Sahina.
>
> I will try the fix proposed and get back.

That works.. NPE is gone with the above change. thanks all !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130208/4b759f64/attachment.html>

From jhernand at redhat.com  Fri Feb  8 17:50:36 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 08 Feb 2013 18:50:36 +0100
Subject: [Engine-devel] Local Authentication Feature
Message-ID: <51153AEC.60007@redhat.com>

Hello,

I would like to propose a new feature that allows authentication using 
the local user database. The details are here:

http://www.ovirt.org/Features/Local_Authentication

And the proposed change is available for review here:

http://gerrit.ovirt.org/11863

I appreciate feedback.

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.


From iheim at redhat.com  Fri Feb  8 12:02:41 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 08 Feb 2013 14:02:41 +0200
Subject: [Engine-devel] Trusted Compute Pools
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BE4DF9EC@SHSMSX101.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BE3FCDA2@SHSMSX101.ccr.corp.intel.com>
	<D0B11485C64D4B47B66902F8A4E901BE4DF9EC@SHSMSX101.ccr.corp.intel.com>
Message-ID: <5114E961.701@redhat.com>

On 01/02/2013 10:25, Wei, Gang wrote:
> Design page updated according to in process Patchset 2.
> http://wiki.ovirt.org/wiki/Trusted_compute_pools.


Hi Wei,

in general, looks good.

currently, user who creates the VM can choose the value for this field. 
i wonder if it should be limited to web admin, and not exposed to power 
users (user portal)
another way to think about this is do you want to set it at cluster 
policy level, and/or if you want to give a specific permission which is 
required to edit this field (then users with this permission can 
override the cluster policy maybe.
all this can wait of course, and is not blocking the patch for basic 
functionality to get community feedback (but may be worth documenting as 
"open question / future thoughts" in the wiki.

two other thoughts/question
1. may be worth allowing to override the setting for this field in 
run-once dialog.
2. currently, the dialog allows to choose "run on trusted node"
aren't the various values in TrustLevel enum relevant here for the user?

(nit: should probably s/node/Host/)

Thanks,
    Itamar

>
> Jimmy
>
> Wei, Gang wrote on 2012-11-20:
>> Hi,
>>
>> I am an engineer working in Intel Open Source Technology Center,
> interested
>> in integrating Intel initiated OpenAttestation(OAT) project
>> (https://github.com/OpenAttestation/OpenAttestation.git) into oVirt to
>> provide a way for Administrator to deploy VMs on trusted hosts hardened
> with
>> H/W-based security features, such as Intel TXT.
>>
>> I made a draft feature page for this:
>> http://wiki.ovirt.org/wiki/Trusted_compute_pools
>>
>> My draft idea is to provide trust_level requirement while doing vm
> creation
>> like below:
>>
>> curl -v -u "vdcadmin at qa.lab.tlv.redhat.com"
>>      -H "Content-type: application/xml"
>>      -d '<vm><name>my_new_vm</name>
>> <cluster id="99408929-82cf-4dc7-a532-9d998063fa95" />
>> <template id="00000000-0000-0000-0000-000000000000"/>
>> <trust_level>trusted</trust_level></vm>'
>>      'http://10.35.1.1/rhevm-api/vms'
>> Then oVirt Engine should query attestation server built with OAT via
> RESTful
>> API to get all trusted hosts and select one to create the VM.
>>
>> Attestation server performs host verification through following steps:
>> 1. Hosts boot with Intel TXT technology enabled
>> 2. The hosts' BIOS, hypervisor and OS are measured
>> 3. These measured data is sent to Attestation server when challenged by
>> attestation server
>> 4. Attestation server verifies those measurements against good/known
>> database to determine hosts' trustworthiness
>>
>> Hosts need to be installed with OAT host agent to report host integrity to
>> attestation server.
>>
>> By far, I am still in process of getting familiar with oVirt code and not
>> get solid idea yet on how the oVirt Engine should be modified to support
>> this feature.
>>
>> Any kind of comments or suggestions will be highly appreciated.
>>
>> Thanks
>> Gang (Jimmy) Wei
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel



From iheim at redhat.com  Fri Feb  8 12:19:31 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 08 Feb 2013 14:19:31 +0200
Subject: [Engine-devel] Import/snapshots duplicate MAC support
In-Reply-To: <11476663.121.1360239611966.JavaMail.msalem@dhcp-1-23.tlv.redhat.com>
References: <11476663.121.1360239611966.JavaMail.msalem@dhcp-1-23.tlv.redhat.com>
Message-ID: <5114ED53.9010900@redhat.com>

On 07/02/2013 14:21, Muli Salem wrote:
>
>
> ----- Original Message -----
>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, 6 February, 2013 8:13:11 AM
>> Subject: [Engine-devel] Import/snapshots duplicate MAC support
>>
>>
>>
>> Hi,
>>
>> The current situation dictates that if the configuration value
>> AllowDuplicateMacAddresses
>> is set to false (this is the default setting), then we block import
>> or switching snapshots where
>> a MAC address in one or more of the snapshot/ovf's virtual NICs is
>> already used.
>>
>> Given that we don't currently give the admin any option to select
>> otherwise, I'm not sure
>> that's a very robust behaviour..
>> First of all the MAC address should be unique per network and not in
>> the whole system (like
>> it is currently).
>> Furthermore, as long as in the same network there are no two virtual
>> NICs running with the
>> same address, it is not such a bad situation.
>>
>> Therefore, I would like to propose a couple of solutions (from
>> backend perspective):
>> 1. Keep blocking.
>> 2. Keep blocking but fix the mac pools to be per network basis.

mac pools per network are a good feature, but i would still warn on 
duplicates. mac's in general are supposed to be unique in a DC, not only 
in a single layer 2 network (i.e., one checking a switch mac table isn't 
expecting to find different sources for the same mac address).

so +1 for the feature, but -1 as solution for this problem.

>> 3. Don't block, and allow duplicate MACs in these scenarios, but
>> block on activating a NIC
>> with duplicate MAC address. Warn the user that the NIC is with
>> duplicate MAC, and
>> perhaps even unplug or unwire it so that it would be obvious that
>> it's using someone else's
>> MAC.

+1 on importing in unplug mode and enabling this check on plugging
even better if we could detect at import time with candoaction and let 
user choose if to 'generate new mac'.

>> 4. Don't block, and give the problematic NIC a new MAC from the pool.
>>
>> Solution 1 is obviously not the greatest (hence this email).
>> In my opinion, 4 is sort of a cat in a bag, since I'm not sure
>> changing the HWADDR for the
>> guest OS is really a good idea.
>> Solution 2 would be nice going forward, but it just reduces the
>> chances of an admin to come
>> across this situation and doesn't solve it entirely.
>> Hence, I would favour solution 3 which seems to solve the problem and
>> allow the admin to
>> choose what to do.
>>
>> Please voice your opinion, or propose an alternate solution.
>
> Another solution would be to perform the action without adding the problematic vNic, and notify the user about it.
>
> Overall, I am in favor of solution 3 as well.
>
>>
>>
>> Regards,
>> Mike
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From snmishra at linux.vnet.ibm.com  Sat Feb  9 01:59:32 2013
From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com)
Date: Fri, 08 Feb 2013 17:59:32 -0800
Subject: [Engine-devel] Error building ovirt engine rpm.
Message-ID: <20130208175932.Horde.QxAfrZir309RFa2E3yNy4xA@imap.linux.ibm.com>


Hi,

  I tried building an ovirt engine RPM for the first time on my  
Fedora17 machine using the wiki instructions. I get the following  
error -

# make rpm
sed -e 's/@PACKAGE_VERSION@/3.3.0/g' \
             -e 's/@PACKAGE_RELEASE@/0.1.20130208174746/g'  
packaging/fedora/spec/                                                  
                                                                        
                                       ovirt-engine.spec.in >  
ovirt-engine.spec
git ls-files | tar --files-from /proc/self/fd/0 -czf  
ovirt-engine-3.3.0.tar.gz o                                             
                                                                        
                                            virt-engine.spec
rm -f ovirt-engine.spec

You can use rpmbuild -tb ovirt-engine-3.3.0.tar.gz to produce rpms

rm -rf /home/guest/ovirt-engine/tmp.rpmbuild
mkdir -p  
/home/guest/ovirt-engine/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,B         
                                                                        
                                                                        
          UILDROOT}
mkdir -p output
rpmbuild -ts --define="_topdir /home/guest/ovirt-engine/tmp.rpmbuild"  
ovirt-engi                                                              
                                                                        
                           ne-3.3.0.tar.gz
Wrote:  
/home/guest/ovirt-engine/tmp.rpmbuild/SRPMS/ovirt-engine-3.3.0-0.1.201302       
                                                                        
                                                                        
            08174746.fc17.src.rpm
mv /home/guest/ovirt-engine/tmp.rpmbuild/SRPMS/*.rpm output
rm -rf /home/guest/ovirt-engine/tmp.rpmbuild

srpm is ready at output

rm -rf /home/guest/ovirt-engine/tmp.rpmbuild
mkdir -p  
/home/guest/ovirt-engine/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,B         
                                                                        
                                                                        
          UILDROOT}
mkdir -p output
rpmbuild --define="_topdir /home/guest/ovirt-engine/tmp.rpmbuild"   
--rebuild out                                                           
                                                                        
                              put/ovirt-engine-3.3.0*.src.rpm
Installing output/ovirt-engine-3.3.0-0.1.20130208172931.fc17.src.rpm
error: Failed build dependencies:
         ovirt-host-deploy-java is needed by  
ovirt-engine-3.3.0-0.1.2013020817293                                    
                                                                        
                                                     1.fc17.noarch
make: *** [rpm] Error 1


-Sharad



From mbetak at redhat.com  Sat Feb  9 19:07:36 2013
From: mbetak at redhat.com (Martin Betak)
Date: Sat, 9 Feb 2013 14:07:36 -0500 (EST)
Subject: [Engine-devel] Error building ovirt engine rpm.
In-Reply-To: <20130208175932.Horde.QxAfrZir309RFa2E3yNy4xA@imap.linux.ibm.com>
Message-ID: <526270495.116400.1360436856168.JavaMail.root@redhat.com>



----- Original Message -----
> From: snmishra at linux.vnet.ibm.com
> To: engine-devel at ovirt.org
> Sent: Saturday, February 9, 2013 2:59:32 AM
> Subject: [Engine-devel] Error building ovirt engine rpm.
> 
> 
> Hi,
> 
>   I tried building an ovirt engine RPM for the first time on my
> Fedora17 machine using the wiki instructions. I get the following
> error -
> 
> # make rpm
> sed -e 's/@PACKAGE_VERSION@/3.3.0/g' \
>              -e 's/@PACKAGE_RELEASE@/0.1.20130208174746/g'
> packaging/fedora/spec/
>                                                                         
>                                        ovirt-engine.spec.in >
> ovirt-engine.spec
> git ls-files | tar --files-from /proc/self/fd/0 -czf
> ovirt-engine-3.3.0.tar.gz o
>                                                                         
>                                             virt-engine.spec
> rm -f ovirt-engine.spec
> 
> You can use rpmbuild -tb ovirt-engine-3.3.0.tar.gz to produce rpms
> 
> rm -rf /home/guest/ovirt-engine/tmp.rpmbuild
> mkdir -p
> /home/guest/ovirt-engine/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,B
>                                                                         
>                                                                         
>           UILDROOT}
> mkdir -p output
> rpmbuild -ts --define="_topdir /home/guest/ovirt-engine/tmp.rpmbuild"
> ovirt-engi
>                                                                         
>                            ne-3.3.0.tar.gz
> Wrote:
> /home/guest/ovirt-engine/tmp.rpmbuild/SRPMS/ovirt-engine-3.3.0-0.1.201302
>                                                                         
>                                                                         
>             08174746.fc17.src.rpm
> mv /home/guest/ovirt-engine/tmp.rpmbuild/SRPMS/*.rpm output
> rm -rf /home/guest/ovirt-engine/tmp.rpmbuild
> 
> srpm is ready at output
> 
> rm -rf /home/guest/ovirt-engine/tmp.rpmbuild
> mkdir -p
> /home/guest/ovirt-engine/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,B
>                                                                         
>                                                                         
>           UILDROOT}
> mkdir -p output
> rpmbuild --define="_topdir /home/guest/ovirt-engine/tmp.rpmbuild"
> --rebuild out
>                                                                         
>                               put/ovirt-engine-3.3.0*.src.rpm
> Installing output/ovirt-engine-3.3.0-0.1.20130208172931.fc17.src.rpm
> error: Failed build dependencies:
>          ovirt-host-deploy-java is needed by
> ovirt-engine-3.3.0-0.1.2013020817293
>                                                                         
>                                                      1.fc17.noarch
> make: *** [rpm] Error 1
> 
> 
> -Sharad
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

Hi Sharad

I have recently run into the same problem trying to create engine rpm. 
After long search I have been finally able to install the missing ovirt-host-deploy-java 
dependency by enabling the ovirt-nightly repo. Hope that helps.

Martin


From masayag at redhat.com  Sat Feb  9 22:15:05 2013
From: masayag at redhat.com (Moti Asayag)
Date: Sun, 10 Feb 2013 00:15:05 +0200
Subject: [Engine-devel] Import/snapshots duplicate MAC support
In-Reply-To: <5114ED53.9010900@redhat.com>
References: <11476663.121.1360239611966.JavaMail.msalem@dhcp-1-23.tlv.redhat.com>
	<5114ED53.9010900@redhat.com>
Message-ID: <5116CA69.3040405@redhat.com>

On 02/08/2013 02:19 PM, Itamar Heim wrote:
> On 07/02/2013 14:21, Muli Salem wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>>> To: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Wednesday, 6 February, 2013 8:13:11 AM
>>> Subject: [Engine-devel] Import/snapshots duplicate MAC support
>>>
>>>
>>>
>>> Hi,
>>>
>>> The current situation dictates that if the configuration value
>>> AllowDuplicateMacAddresses
>>> is set to false (this is the default setting), then we block import
>>> or switching snapshots where
>>> a MAC address in one or more of the snapshot/ovf's virtual NICs is
>>> already used.
>>>
>>> Given that we don't currently give the admin any option to select
>>> otherwise, I'm not sure
>>> that's a very robust behaviour..
>>> First of all the MAC address should be unique per network and not in
>>> the whole system (like
>>> it is currently).
>>> Furthermore, as long as in the same network there are no two virtual
>>> NICs running with the
>>> same address, it is not such a bad situation.
>>>
>>> Therefore, I would like to propose a couple of solutions (from
>>> backend perspective):
>>> 1. Keep blocking.
>>> 2. Keep blocking but fix the mac pools to be per network basis.
> 
> mac pools per network are a good feature, but i would still warn on
> duplicates. mac's in general are supposed to be unique in a DC, not only
> in a single layer 2 network (i.e., one checking a switch mac table isn't
> expecting to find different sources for the same mac address).
> 
> so +1 for the feature, but -1 as solution for this problem.
> 
>>> 3. Don't block, and allow duplicate MACs in these scenarios, but
>>> block on activating a NIC
>>> with duplicate MAC address. Warn the user that the NIC is with
>>> duplicate MAC, and
>>> perhaps even unplug or unwire it so that it would be obvious that
>>> it's using someone else's
>>> MAC.
> 
> +1 on importing in unplug mode and enabling this check on plugging
> even better if we could detect at import time with candoaction and let
> user choose if to 'generate new mac'.
> 

I would go for introducing a new parameter to import vm action for
allocating a new mac address if it is in use. Its default value should
be set to false, so the user is aware of his intention to replace the
vm's mac addresses. Else (if user decided vm should be imported with the
exact mac addresses) block the operation on can-do-action with the list
of mac addresses and the vm names which own them so the user can take
different actions (e,g, free/replace these mac addresses).

The user should be aware the change of import behaviour when the allow
duplicate mac addresses is enabled. In which case even if the user asked
not allocate new mac addresses for the taken one, the action will succeed.

>>> 4. Don't block, and give the problematic NIC a new MAC from the pool.
>>>
>>> Solution 1 is obviously not the greatest (hence this email).
>>> In my opinion, 4 is sort of a cat in a bag, since I'm not sure
>>> changing the HWADDR for the
>>> guest OS is really a good idea.
>>> Solution 2 would be nice going forward, but it just reduces the
>>> chances of an admin to come
>>> across this situation and doesn't solve it entirely.
>>> Hence, I would favour solution 3 which seems to solve the problem and
>>> allow the admin to
>>> choose what to do.
>>>
>>> Please voice your opinion, or propose an alternate solution.
>>
>> Another solution would be to perform the action without adding the
>> problematic vNic, and notify the user about it.
>>
>> Overall, I am in favor of solution 3 as well.
>>
>>>
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From mkolesni at redhat.com  Sun Feb 10 06:24:30 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Sun, 10 Feb 2013 01:24:30 -0500 (EST)
Subject: [Engine-devel] Import/snapshots duplicate MAC support
In-Reply-To: <5116CA69.3040405@redhat.com>
Message-ID: <463090889.64926.1360477470932.JavaMail.root@redhat.com>

----- Original Message -----
> On 02/08/2013 02:19 PM, Itamar Heim wrote:
> > On 07/02/2013 14:21, Muli Salem wrote:
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Mike Kolesnik" <mkolesni at redhat.com>
> >>> To: "engine-devel" <engine-devel at ovirt.org>
> >>> Sent: Wednesday, 6 February, 2013 8:13:11 AM
> >>> Subject: [Engine-devel] Import/snapshots duplicate MAC support
> >>>
> >>>
> >>>
> >>> Hi,
> >>>
> >>> The current situation dictates that if the configuration value
> >>> AllowDuplicateMacAddresses
> >>> is set to false (this is the default setting), then we block
> >>> import
> >>> or switching snapshots where
> >>> a MAC address in one or more of the snapshot/ovf's virtual NICs
> >>> is
> >>> already used.
> >>>
> >>> Given that we don't currently give the admin any option to select
> >>> otherwise, I'm not sure
> >>> that's a very robust behaviour..
> >>> First of all the MAC address should be unique per network and not
> >>> in
> >>> the whole system (like
> >>> it is currently).
> >>> Furthermore, as long as in the same network there are no two
> >>> virtual
> >>> NICs running with the
> >>> same address, it is not such a bad situation.
> >>>
> >>> Therefore, I would like to propose a couple of solutions (from
> >>> backend perspective):
> >>> 1. Keep blocking.
> >>> 2. Keep blocking but fix the mac pools to be per network basis.
> > 
> > mac pools per network are a good feature, but i would still warn on
> > duplicates. mac's in general are supposed to be unique in a DC, not
> > only
> > in a single layer 2 network (i.e., one checking a switch mac table
> > isn't
> > expecting to find different sources for the same mac address).
> > 
> > so +1 for the feature, but -1 as solution for this problem.
> > 
> >>> 3. Don't block, and allow duplicate MACs in these scenarios, but
> >>> block on activating a NIC
> >>> with duplicate MAC address. Warn the user that the NIC is with
> >>> duplicate MAC, and
> >>> perhaps even unplug or unwire it so that it would be obvious that
> >>> it's using someone else's
> >>> MAC.
> > 
> > +1 on importing in unplug mode and enabling this check on plugging
> > even better if we could detect at import time with candoaction and
> > let
> > user choose if to 'generate new mac'.
> > 
> 
> I would go for introducing a new parameter to import vm action for
> allocating a new mac address if it is in use. Its default value
> should
> be set to false, so the user is aware of his intention to replace the
> vm's mac addresses. Else (if user decided vm should be imported with
> the
> exact mac addresses) block the operation on can-do-action with the
> list
> of mac addresses and the vm names which own them so the user can take
> different actions (e,g, free/replace these mac addresses).
> 
> The user should be aware the change of import behaviour when the
> allow
> duplicate mac addresses is enabled. In which case even if the user
> asked
> not allocate new mac addresses for the taken one, the action will
> succeed.

In this case, I would say that the default value should be the same as the
"allow duplicate macs" option.
If the user chose to override the default, then we should act according to
his will..

This however solves only the import problem but not the snapshot switching
problem, and in that case it's a bit more complicated to add a parameter..
It is the reason I initially opted for a "backend only" solution which can
solve both cases.

> 
> >>> 4. Don't block, and give the problematic NIC a new MAC from the
> >>> pool.
> >>>
> >>> Solution 1 is obviously not the greatest (hence this email).
> >>> In my opinion, 4 is sort of a cat in a bag, since I'm not sure
> >>> changing the HWADDR for the
> >>> guest OS is really a good idea.
> >>> Solution 2 would be nice going forward, but it just reduces the
> >>> chances of an admin to come
> >>> across this situation and doesn't solve it entirely.
> >>> Hence, I would favour solution 3 which seems to solve the problem
> >>> and
> >>> allow the admin to
> >>> choose what to do.
> >>>
> >>> Please voice your opinion, or propose an alternate solution.
> >>
> >> Another solution would be to perform the action without adding the
> >> problematic vNic, and notify the user about it.
> >>
> >> Overall, I am in favor of solution 3 as well.
> >>
> >>>
> >>>
> >>> Regards,
> >>> Mike
> >>>
> >>>


From iheim at redhat.com  Sun Feb 10 06:42:39 2013
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 10 Feb 2013 08:42:39 +0200
Subject: [Engine-devel] Import/snapshots duplicate MAC support
In-Reply-To: <463090889.64926.1360477470932.JavaMail.root@redhat.com>
References: <463090889.64926.1360477470932.JavaMail.root@redhat.com>
Message-ID: <5117415F.90003@redhat.com>

On 10/02/2013 08:24, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 02/08/2013 02:19 PM, Itamar Heim wrote:
>>> On 07/02/2013 14:21, Muli Salem wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Mike Kolesnik" <mkolesni at redhat.com>
>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>> Sent: Wednesday, 6 February, 2013 8:13:11 AM
>>>>> Subject: [Engine-devel] Import/snapshots duplicate MAC support
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> The current situation dictates that if the configuration value
>>>>> AllowDuplicateMacAddresses
>>>>> is set to false (this is the default setting), then we block
>>>>> import
>>>>> or switching snapshots where
>>>>> a MAC address in one or more of the snapshot/ovf's virtual NICs
>>>>> is
>>>>> already used.
>>>>>
>>>>> Given that we don't currently give the admin any option to select
>>>>> otherwise, I'm not sure
>>>>> that's a very robust behaviour..
>>>>> First of all the MAC address should be unique per network and not
>>>>> in
>>>>> the whole system (like
>>>>> it is currently).
>>>>> Furthermore, as long as in the same network there are no two
>>>>> virtual
>>>>> NICs running with the
>>>>> same address, it is not such a bad situation.
>>>>>
>>>>> Therefore, I would like to propose a couple of solutions (from
>>>>> backend perspective):
>>>>> 1. Keep blocking.
>>>>> 2. Keep blocking but fix the mac pools to be per network basis.
>>>
>>> mac pools per network are a good feature, but i would still warn on
>>> duplicates. mac's in general are supposed to be unique in a DC, not
>>> only
>>> in a single layer 2 network (i.e., one checking a switch mac table
>>> isn't
>>> expecting to find different sources for the same mac address).
>>>
>>> so +1 for the feature, but -1 as solution for this problem.
>>>
>>>>> 3. Don't block, and allow duplicate MACs in these scenarios, but
>>>>> block on activating a NIC
>>>>> with duplicate MAC address. Warn the user that the NIC is with
>>>>> duplicate MAC, and
>>>>> perhaps even unplug or unwire it so that it would be obvious that
>>>>> it's using someone else's
>>>>> MAC.
>>>
>>> +1 on importing in unplug mode and enabling this check on plugging
>>> even better if we could detect at import time with candoaction and
>>> let
>>> user choose if to 'generate new mac'.
>>>
>>
>> I would go for introducing a new parameter to import vm action for
>> allocating a new mac address if it is in use. Its default value
>> should
>> be set to false, so the user is aware of his intention to replace the
>> vm's mac addresses. Else (if user decided vm should be imported with
>> the
>> exact mac addresses) block the operation on can-do-action with the
>> list
>> of mac addresses and the vm names which own them so the user can take
>> different actions (e,g, free/replace these mac addresses).
>>
>> The user should be aware the change of import behaviour when the
>> allow
>> duplicate mac addresses is enabled. In which case even if the user
>> asked
>> not allocate new mac addresses for the taken one, the action will
>> succeed.
>
> In this case, I would say that the default value should be the same as the
> "allow duplicate macs" option.
> If the user chose to override the default, then we should act according to
> his will..

I wouldn't make a default value change based on the config for this. 
even for an environment that allows duplicate macs, it would be the 
exception, not the rule.

>
> This however solves only the import problem but not the snapshot switching
> problem, and in that case it's a bit more complicated to add a parameter..
> It is the reason I initially opted for a "backend only" solution which can
> solve both cases.
>
>>
>>>>> 4. Don't block, and give the problematic NIC a new MAC from the
>>>>> pool.
>>>>>
>>>>> Solution 1 is obviously not the greatest (hence this email).
>>>>> In my opinion, 4 is sort of a cat in a bag, since I'm not sure
>>>>> changing the HWADDR for the
>>>>> guest OS is really a good idea.
>>>>> Solution 2 would be nice going forward, but it just reduces the
>>>>> chances of an admin to come
>>>>> across this situation and doesn't solve it entirely.
>>>>> Hence, I would favour solution 3 which seems to solve the problem
>>>>> and
>>>>> allow the admin to
>>>>> choose what to do.
>>>>>
>>>>> Please voice your opinion, or propose an alternate solution.
>>>>
>>>> Another solution would be to perform the action without adding the
>>>> problematic vNic, and notify the user about it.
>>>>
>>>> Overall, I am in favor of solution 3 as well.
>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>>



From snmishra at linux.vnet.ibm.com  Sun Feb 10 09:15:02 2013
From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com)
Date: Sun, 10 Feb 2013 01:15:02 -0800
Subject: [Engine-devel] Error building ovirt engine rpm.
In-Reply-To: <526270495.116400.1360436856168.JavaMail.root@redhat.com>
References: <526270495.116400.1360436856168.JavaMail.root@redhat.com>
Message-ID: <20130210011502.Horde.N2A5DJir309RF2UWsq-gVQA@imap.linux.ibm.com>


Quoting Martin Betak <mbetak at redhat.com>:

> ----- Original Message -----
>> From: snmishra at linux.vnet.ibm.com
>> To: engine-devel at ovirt.org
>> Sent: Saturday, February 9, 2013 2:59:32 AM
>> Subject: [Engine-devel] Error building ovirt engine rpm.
>>
>>
>> Hi,
>>
>>   I tried building an ovirt engine RPM for the first time on my
>> Fedora17 machine using the wiki instructions. I get the following
>> error -
>>
>> # make rpm
>> sed -e 's/@PACKAGE_VERSION@/3.3.0/g' \
>>              -e 's/@PACKAGE_RELEASE@/0.1.20130208174746/g'
>> packaging/fedora/spec/
>>
>>                                        ovirt-engine.spec.in >
>> ovirt-engine.spec
>> git ls-files | tar --files-from /proc/self/fd/0 -czf
>> ovirt-engine-3.3.0.tar.gz o
>>
>>                                             virt-engine.spec
>> rm -f ovirt-engine.spec
>>
>> You can use rpmbuild -tb ovirt-engine-3.3.0.tar.gz to produce rpms
>>
>> rm -rf /home/guest/ovirt-engine/tmp.rpmbuild
>> mkdir -p
>> /home/guest/ovirt-engine/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,B
>>
>>
>>           UILDROOT}
>> mkdir -p output
>> rpmbuild -ts --define="_topdir /home/guest/ovirt-engine/tmp.rpmbuild"
>> ovirt-engi
>>
>>                            ne-3.3.0.tar.gz
>> Wrote:
>> /home/guest/ovirt-engine/tmp.rpmbuild/SRPMS/ovirt-engine-3.3.0-0.1.201302
>>
>>
>>             08174746.fc17.src.rpm
>> mv /home/guest/ovirt-engine/tmp.rpmbuild/SRPMS/*.rpm output
>> rm -rf /home/guest/ovirt-engine/tmp.rpmbuild
>>
>> srpm is ready at output
>>
>> rm -rf /home/guest/ovirt-engine/tmp.rpmbuild
>> mkdir -p
>> /home/guest/ovirt-engine/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,B
>>
>>
>>           UILDROOT}
>> mkdir -p output
>> rpmbuild --define="_topdir /home/guest/ovirt-engine/tmp.rpmbuild"
>> --rebuild out
>>
>>                               put/ovirt-engine-3.3.0*.src.rpm
>> Installing output/ovirt-engine-3.3.0-0.1.20130208172931.fc17.src.rpm
>> error: Failed build dependencies:
>>          ovirt-host-deploy-java is needed by
>> ovirt-engine-3.3.0-0.1.2013020817293
>>
>>                                                      1.fc17.noarch
>> make: *** [rpm] Error 1
>>
>>
>> -Sharad
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>
> Hi Sharad
>
> I have recently run into the same problem trying to create engine rpm.
> After long search I have been finally able to install the missing  
> ovirt-host-deploy-java
> dependency by enabling the ovirt-nightly repo. Hope that helps.
>
> Martin

Thanks Martin, it worked.

-Sharad





From gchaplik at redhat.com  Sun Feb 10 12:26:21 2013
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Sun, 10 Feb 2013 07:26:21 -0500 (EST)
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <441020136.6063702.1360049360391.JavaMail.root@redhat.com>
Message-ID: <1139963911.78133.1360499181797.JavaMail.root@redhat.com>

----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, February 5, 2013 9:29:20 AM
> Subject: Re: [Engine-devel] Guid & NGuid
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Tuesday, February 5, 2013 9:28:26 AM
> > Subject: Re: [Engine-devel] Guid & NGuid
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > To: "Michael Kublin" <mkublin at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Monday, February 4, 2013 4:17:39 PM
> > > Subject: Re: [Engine-devel] Guid & NGuid
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > To: engine-devel at ovirt.org
> > > > Sent: Monday, February 4, 2013 2:15:40 PM
> > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > > Cc: engine-devel at ovirt.org
> > > > > Sent: Monday, February 4, 2013 11:48:45 AM
> > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > 
> > > > > ----- Original Message -----
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > > > To: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > Cc: engine-devel at ovirt.org
> > > > > > > Sent: Monday, February 4, 2013 9:56:28 AM
> > > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ----- Original Message -----
> > > > > > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > > To: engine-devel at ovirt.org
> > > > > > > > Sent: Monday, February 4, 2013 8:47:29 AM
> > > > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- Original Message -----
> > > > > > > > > From: "Roy Golan" <rgolan at redhat.com>
> > > > > > > > > To: engine-devel at ovirt.org
> > > > > > > > > Sent: Monday, February 4, 2013 9:18:21 AM
> > > > > > > > > Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > > > > 
> > > > > > > > > On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
> > > > > > > > > >
> > > > > > > > > > ----- Original Message -----
> > > > > > > > > >> From: "Omer Frenkel" <ofrenkel at redhat.com>
> > > > > > > > > >> To: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > > > >> Cc: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > > >> Sent: Sunday, February 3, 2013 3:12:19 PM
> > > > > > > > > >> Subject: Re: [Engine-devel] Guid & NGuid
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> ----- Original Message -----
> > > > > > > > > >>> From: "Michael Kublin" <mkublin at redhat.com>
> > > > > > > > > >>> To: "engine-devel" <engine-devel at ovirt.org>
> > > > > > > > > >>> Sent: Sunday, February 3, 2013 3:10:14 PM
> > > > > > > > > >>> Subject: [Engine-devel] Guid & NGuid
> > > > > > > > > >>>
> > > > > > > > > >>> Hi,
> > > > > > > > > >>>
> > > > > > > > > >>> In ovirt-engine code we have Guid and NGuid
> > > > > > > > > >>> objects.
> > > > > > > > > >>> Guid is extends NGuid and also NGuid class has
> > > > > > > > > >>> method
> > > > > > > > > >>> getValue()
> > > > > > > > > >>> which should return Guid.
> > > > > > > > > >>> As for me these two classes are look like the
> > > > > > > > > >>> same
> > > > > > > > > >>> and
> > > > > > > > > >>> I
> > > > > > > > > >>> don't
> > > > > > > > > >>> see
> > > > > > > > > >>> to
> > > > > > > > > >>> much differences between them.
> > > > > > > > > >>> My proposal is to remove NGuid and move it
> > > > > > > > > >>> functionality
> > > > > > > > > >>> to
> > > > > > > > > >>> Guid
> > > > > > > > > >>> (Because of Guid is much more common)
> > > > > > > > > >>>
> > > > > > > > > >> i agree, but we need to take another step forward
> > > > > > > > > >> and
> > > > > > > > > >> allow
> > > > > > > > > >> Guid
> > > > > > > > > >> to
> > > > > > > > > >> be null (as it should)
> > > > > > > > > >> and not assume its EMPTY or have a value (i'm
> > > > > > > > > >> pretty
> > > > > > > > > >> sure
> > > > > > > > > >> we
> > > > > > > > > >> have
> > > > > > > > > >> this assumption in many places)
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > And for the new people out here... why not kill
> > > > > > > > > > both
> > > > > > > > > > and
> > > > > > > > > > use
> > > > > > > > > > plain
> > > > > > > > > > standard java UUID[1]?
> > > > > > > > > +1 for using java.util.UUID
> > > > > > > > > 
> > > > > > > > > NGuid functionality that should be extracted during
> > > > > > > > > the
> > > > > > > > > refactor
> > > > > > > > > is
> > > > > > > > > -
> > > > > > > > > 1. refactor DB and Java so empty or null return
> > > > > > > > > values
> > > > > > > > > are
> > > > > > > > > null
> > > > > > > > > and
> > > > > > > > > not
> > > > > > > > > EMPTY_GUID
> > > > > > > > > 2. the special constructor of NGuid for UUID return
> > > > > > > > > by
> > > > > > > > > Microsoft
> > > > > > > > > AD
> > > > > > > > > should be extracted to a factory/utility
> > > > > > > > > > I think we should kill compat, I don't see any
> > > > > > > > > > value
> > > > > > > > > > in
> > > > > > > > > > fixing
> > > > > > > > > > anything about it while leaving it intact.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Alon Bar-Lev.
> > > > > > > > > >
> > > > > > > > > > [1]
> > > > > > > > > > http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
> > > > > > > > Actually there is exists one reason not to use directly
> > > > > > > > UUID
> > > > > > > > at
> > > > > > > > server side.
> > > > > > > > The main operations on Guid today it is to convert
> > > > > > > > object
> > > > > > > > to
> > > > > > > > Guid
> > > > > > > > or
> > > > > > > > Guid to string.
> > > > > > > > Guid it is immutable object, number of Guids is limited
> > > > > > > > and
> > > > > > > > almost
> > > > > > > > never changed,
> > > > > > > > These sound like classical case for object that can be
> > > > > > > > cached.
> > > > > > > > Benefit - reduced number of string manipulations,
> > > > > > > > reduced
> > > > > > > > number
> > > > > > > > of
> > > > > > > > created instances, less work
> > > > > > > > for garbage collection
> > > > > > > 
> > > > > > > UUID has the same properties, it is immutable. So you
> > > > > > > could
> > > > > > > do
> > > > > > > the
> > > > > > > same with UUID, but I am not sure you could effectively
> > > > > > > cache
> > > > > > > these
> > > > > > > objects and prove that you are saving either CPU, heap,
> > > > > > > or
> > > > > > > GC
> > > > > > > time.
> > > > > > These is a very common pattern:
> > > > > > 1) implementation of valueOf() for most classes like
> > > > > > Integer,
> > > > > > Double,
> > > > > > etc... has some kind of cache.
> > > > > > 2) JVM has cache for strings that can be used and that
> > > > > > cache
> > > > > > can
> > > > > > be
> > > > > > tweaked by some JVM opts.
> > > > > > 3) Most of our operations is perform query on DB, send
> > > > > > request
> > > > > > to
> > > > > > host or parse response from host and Guid
> > > > > >    is very common object that is immutable.
> > > > > > I am agree that these will not solve all our performance
> > > > > > problems
> > > > > > but
> > > > > > can provide some benefit, especially when it is very easy
> > > > > > to implement.
> > > > > 
> > > > > We could still achieve that using a UUIDCreator class and
> > > > > call
> > > > > it
> > > > > instead of Guid.fromString("")..
> > > > > 
> > > > > Whether this is cached or not is another question which can
> > > > > be
> > > > > solved
> > > > > later and checked to see if the cache improves performance or
> > > > > not.
> > > > These is already implementation, if it will be
> > > > Guid.fromString("")
> > > > or
> > > > UUIDCreator.
> > > > The issue is if we want to use cache, it should be implemented
> > > > together
> > > > with deleting/replacing of Guid/NGuid , because of it much more
> > > > easilly
> > > 
> > > I think the value of using standard java classes is higher than
> > > the
> > > tuning of the engine at this regard. Dropping the compat thing is
> > > important activity.
> > Immutable object it is a common java design pattern
> > > After doing this conversion, use profiler to determine where
> > > major
> > Already was done, and already tested a cache solution (Simple POC
> > solution took to implement less
> > than hour)
> > > bottle necks are and fix these, I am not sure the above
> > > optimization
> > > will be first in list.
> > Any optimization can not be first in the list, the best
> > optimization
> > is architecture change
> > > If we invest resources in optimization better
> > > to invest in these that we suffer most.
> > Most of the issues are well known.
> 
> Please try to be less cryptic... Is this one of them?

Another issue, look at:
http://www.2ality.com/2009/01/uuids-for-gwt.html
GWT must have a wrapper for uuid, if removing Guid, we must override UUID in GWT.

I'm +1 on leaving Guid for now.

IMHO the bigger problem we have in the Guid area is
the ambiguous use of Guid.Empty/null; for me Guid.Empty is BLANK_TEMPLTAE_UUID.

> 
> > 
> > > 
> > > Regards,
> > > Alon
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Sun Feb 10 15:19:05 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 10 Feb 2013 10:19:05 -0500 (EST)
Subject: [Engine-devel] Trusted Compute Pools
In-Reply-To: <5114E961.701@redhat.com>
Message-ID: <1223325852.293900.1360509545606.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Gang Wei" <gang.wei at intel.com>
> Cc: engine-devel at ovirt.org
> Sent: Friday, February 8, 2013 2:02:41 PM
> Subject: Re: [Engine-devel] Trusted Compute Pools
> 
> On 01/02/2013 10:25, Wei, Gang wrote:
> > Design page updated according to in process Patchset 2.
> > http://wiki.ovirt.org/wiki/Trusted_compute_pools.
> 
> 
> Hi Wei,
> 
> in general, looks good.
> 
> currently, user who creates the VM can choose the value for this
> field.
> i wonder if it should be limited to web admin, and not exposed to
> power
> users (user portal)
> another way to think about this is do you want to set it at cluster
> policy level, and/or if you want to give a specific permission which
> is
> required to edit this field (then users with this permission can
> override the cluster policy maybe.
> all this can wait of course, and is not blocking the patch for basic
> functionality to get community feedback (but may be worth documenting
> as
> "open question / future thoughts" in the wiki.
> 
> two other thoughts/question
> 1. may be worth allowing to override the setting for this field in
> run-once dialog.
> 2. currently, the dialog allows to choose "run on trusted node"
> aren't the various values in TrustLevel enum relevant here for the
> user?
> 
> (nit: should probably s/node/Host/)
> 
> Thanks,
>     Itamar
> 

Agree on the cluster level use-case. Actually it may be more effective
to move attestation decision to cluster level in general, so you will
have an attested-cluster. Otherwise, you may have issues during migration
and load balancing which may fail other functionalities in the system.
Think of a use case where you want to upgrade the current hosts. If you
have a mixture of attested on non-attested hosts you may have to take down
a trusted VM since there's no suitable host for it. This will be easy
when working in attested-cluster where all VMs are free to migrate as
needed based on capacity only.

If you choose to keep attestation in VM-level, please explain how do you
plan to handle the cases I mentioned (migration, etc).

Additionally I'll be glad to see a more detailed design with reference
to the various parts- RESTful API, Engine and UI. 

Thanks!
Doron
> >
> > Jimmy
> >
> > Wei, Gang wrote on 2012-11-20:
> >> Hi,
> >>
> >> I am an engineer working in Intel Open Source Technology Center,
> > interested
> >> in integrating Intel initiated OpenAttestation(OAT) project
> >> (https://github.com/OpenAttestation/OpenAttestation.git) into
> >> oVirt to
> >> provide a way for Administrator to deploy VMs on trusted hosts
> >> hardened
> > with
> >> H/W-based security features, such as Intel TXT.
> >>
> >> I made a draft feature page for this:
> >> http://wiki.ovirt.org/wiki/Trusted_compute_pools
> >>
> >> My draft idea is to provide trust_level requirement while doing vm
> > creation
> >> like below:
> >>
> >> curl -v -u "vdcadmin at qa.lab.tlv.redhat.com"
> >>      -H "Content-type: application/xml"
> >>      -d '<vm><name>my_new_vm</name>
> >> <cluster id="99408929-82cf-4dc7-a532-9d998063fa95" />
> >> <template id="00000000-0000-0000-0000-000000000000"/>
> >> <trust_level>trusted</trust_level></vm>'
> >>      'http://10.35.1.1/rhevm-api/vms'
> >> Then oVirt Engine should query attestation server built with OAT
> >> via
> > RESTful
> >> API to get all trusted hosts and select one to create the VM.
> >>
> >> Attestation server performs host verification through following
> >> steps:
> >> 1. Hosts boot with Intel TXT technology enabled
> >> 2. The hosts' BIOS, hypervisor and OS are measured
> >> 3. These measured data is sent to Attestation server when
> >> challenged by
> >> attestation server
> >> 4. Attestation server verifies those measurements against
> >> good/known
> >> database to determine hosts' trustworthiness
> >>
> >> Hosts need to be installed with OAT host agent to report host
> >> integrity to
> >> attestation server.
> >>
> >> By far, I am still in process of getting familiar with oVirt code
> >> and not
> >> get solid idea yet on how the oVirt Engine should be modified to
> >> support
> >> this feature.
> >>
> >> Any kind of comments or suggestions will be highly appreciated.
> >>
> >> Thanks
> >> Gang (Jimmy) Wei
> >>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Sun Feb 10 15:26:52 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 10 Feb 2013 10:26:52 -0500 (EST)
Subject: [Engine-devel] Local Authentication Feature
In-Reply-To: <51153AEC.60007@redhat.com>
Message-ID: <1858456507.294577.1360510012335.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Friday, February 8, 2013 7:50:36 PM
> Subject: [Engine-devel] Local Authentication Feature
> 
> Hello,
> 
> I would like to propose a new feature that allows authentication
> using
> the local user database. The details are here:
> 
> http://www.ovirt.org/Features/Local_Authentication
> 
> And the proposed change is available for review here:
> 
> http://gerrit.ovirt.org/11863
> 
> I appreciate feedback.
> 
> 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.

Hi Juan,
Very happy to see this one which actually closes an annoying gap!
One thing which is missing is user management- add/remove/change
users and groups. If we do not plan to handle it within ovirt, the
design should state it and explain how user management should work.
Also, what happens when a user is removed from the local DB- will
all references to him be removed? Groups?

Thanks for a very important contribution!
Doron


From yzaslavs at redhat.com  Sun Feb 10 15:37:10 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 10 Feb 2013 10:37:10 -0500 (EST)
Subject: [Engine-devel] Local Authentication Feature
In-Reply-To: <1858456507.294577.1360510012335.JavaMail.root@redhat.com>
Message-ID: <958193695.168162.1360510630149.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Juan Hernandez" <jhernand at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Sunday, February 10, 2013 5:26:52 PM
> Subject: Re: [Engine-devel] Local Authentication Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Juan Hernandez" <jhernand at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Friday, February 8, 2013 7:50:36 PM
> > Subject: [Engine-devel] Local Authentication Feature
> > 
> > Hello,
> > 
> > I would like to propose a new feature that allows authentication
> > using
> > the local user database. The details are here:
> > 
> > http://www.ovirt.org/Features/Local_Authentication
> > 
> > And the proposed change is available for review here:
> > 
> > http://gerrit.ovirt.org/11863
> > 
> > I appreciate feedback.
> > 
> > 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.
> 
> Hi Juan,
> Very happy to see this one which actually closes an annoying gap!
> One thing which is missing is user management- add/remove/change
> users and groups. If we do not plan to handle it within ovirt, the
> design should state it and explain how user management should work.

Shouldn't this be the same as in case of external directory service? i.e - you manage user/group at the directory service, and then you "populate" engine with it (by adding permissions to users/groups or adding explicitly new users/groups to engine?)

> Also, what happens when a user is removed from the local DB- will
> all references to him be removed? Groups?

IMHO the behavior in this case should be as in case of current LdapBroker.

> 
> Thanks for a very important contribution!
> Doron
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Sun Feb 10 15:40:29 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 10 Feb 2013 10:40:29 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <484301786.9968603.1360142703338.JavaMail.root@redhat.com>
Message-ID: <1047441680.297314.1360510829231.JavaMail.root@redhat.com>

Hi Laszlo,
Looks very useful. Any thoughts on what engine will do while
if the VM is defined as HA while the watchdog is resetting it?


----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, February 6, 2013 11:25:03 AM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> Hi everyone,
> 
> I hope everyone is satisfied with the spec, please read it through
> for the last time and I will move it to implementation phase soon.
> 
> Thx,
> Laszlo
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, January 24, 2013 3:19:57 PM
> > Subject: Watchdog support Feature
> > 
> > Hi,
> > 
> > Watchdog support in engine will add watchdog to the ovirt UI and
> > REST
> > API. Watchdog cards will be mainly used in HA vm's.
> > 
> > http://www.ovirt.org/Features/Watchdog_engine_support
> > 
> > Your feedback is welcome!
> > 
> > Thank you,
> > Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Sun Feb 10 15:41:25 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 10 Feb 2013 10:41:25 -0500 (EST)
Subject: [Engine-devel] cleanup patch review needed
In-Reply-To: <126697683.9568655.1360070978357.JavaMail.root@redhat.com>
Message-ID: <709642558.297376.1360510885273.JavaMail.root@redhat.com>

PING?

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, February 5, 2013 3:29:38 PM
> Subject: [Engine-devel] cleanup patch review needed
> 
> Hi,
> 
> I need someone to review this patch
> http://gerrit.ovirt.org/#/c/11351/
> 
> Thx,
> Laszlo
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Sun Feb 10 16:02:39 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 10 Feb 2013 11:02:39 -0500 (EST)
Subject: [Engine-devel] Local Authentication Feature
In-Reply-To: <958193695.168162.1360510630149.JavaMail.root@redhat.com>
Message-ID: <1907553793.301381.1360512159753.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, February 10, 2013 5:37:10 PM
> Subject: Re: [Engine-devel] Local Authentication Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Juan Hernandez" <jhernand at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Sunday, February 10, 2013 5:26:52 PM
> > Subject: Re: [Engine-devel] Local Authentication Feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Friday, February 8, 2013 7:50:36 PM
> > > Subject: [Engine-devel] Local Authentication Feature
> > > 
> > > Hello,
> > > 
> > > I would like to propose a new feature that allows authentication
> > > using
> > > the local user database. The details are here:
> > > 
> > > http://www.ovirt.org/Features/Local_Authentication
> > > 
> > > And the proposed change is available for review here:
> > > 
> > > http://gerrit.ovirt.org/11863
> > > 
> > > I appreciate feedback.
> > > 
> > > 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.
> > 
> > Hi Juan,
> > Very happy to see this one which actually closes an annoying gap!
> > One thing which is missing is user management- add/remove/change
> > users and groups. If we do not plan to handle it within ovirt, the
> > design should state it and explain how user management should work.
> 
> Shouldn't this be the same as in case of external directory service?
> i.e - you manage user/group at the directory service, and then you
> "populate" engine with it (by adding permissions to users/groups or
> adding explicitly new users/groups to engine?)
> 
> > Also, what happens when a user is removed from the local DB- will
> > all references to him be removed? Groups?
> 
> IMHO the behavior in this case should be as in case of current
> LdapBroker.
> 

This could be a decision but it's missing from the design.
The diff I see from current supported directory servers are that
they actually have their own management tools, which is not the
case for local DB. Again, you may state that the various userXXX
and groupXXX commandline utilities are the way to manage it, but
this is lacking from the design.



From dfediuck at redhat.com  Sun Feb 10 16:07:57 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 10 Feb 2013 11:07:57 -0500 (EST)
Subject: [Engine-devel] Open Attestation integration with oVirt engine
 proposal, how to improve engine's performance?
In-Reply-To: <C5A0092C63E939488005F15F736A8112116403@SHSMSX101.ccr.corp.intel.com>
Message-ID: <748206108.302017.1360512477043.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Wei D Chen" <wei.d.chen at intel.com>
> To: "engine-devel at ovirt.org" <engine-devel at ovirt.org>
> Cc: "Lijuan Zhang" <lijuan.zhang at intel.com>
> Sent: Monday, January 28, 2013 10:42:19 AM
> Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal, how to improve engine's performance?
> 
> Open Attestation is a project aim to enable basic open sourced SDK
> with Intel TXT technology to get node's trustworthiness in a cloud
> usage environment. Integration Open Attestation with Ovirt will
> definitely provide a more secure cloud ecosystem which will give end
> user a choice of whether guest virtual machine need launch on a
> trusted host server or not.
> 
> Initially, we want to attest the host's trustworthiness every time
> when every guest virtual machine launch on the host, thanks to Doron
> Fediuck's reminding, we just need attest the host at the first
> request and cache the result for subsequent requests is enough,
> further, we want to bring down server's response time in case of
> large concurrence request. To resolve/improve engine's performance,
> we decide to tackle this issue by caching all of node's
> trustworthiness while the first guest virtual machine's launching,
> this will take a little longer before its running. Node's
> trustworthiness would be stored in database or just in system
> memory, the value will be effective within one hour or so, of
> course, the period of validity could be configured, node's status
> need to be updated in the case of end user reboot the virtual
> machine and the duration exceed valid time.
> 
> Does this acceptable and any good suggestion?
> 
> Some details can be found in this link:
> http://wiki.ovirt.org/Trusted_compute_pools
> 
> 
> Best Regards,
> Dave Chen
> 

Hi Dave,
As already commented in a different thread, I think moving the trust
constraint from VM level to cluster level may do you good. Current
design suggests that VMs may fail to migrate because there's no trusted
host in the current cluster. However, if you decide that all hosts in the
cluster must be trusted, than this will remove the need to check it for
each VM. You will need a quartz job running to perform the attestation
verification for every host one in a given (configurable) time. If attestation
fail you may choose to move this host into a different status until its
attestation level is handled.


From acathrow at redhat.com  Sun Feb 10 17:21:32 2013
From: acathrow at redhat.com (Andrew Cathrow)
Date: Sun, 10 Feb 2013 12:21:32 -0500 (EST)
Subject: [Engine-devel] Local Authentication Feature
In-Reply-To: <1907553793.301381.1360512159753.JavaMail.root@redhat.com>
Message-ID: <2029655774.316299.1360516892757.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, February 10, 2013 11:02:39 AM
> Subject: Re: [Engine-devel] Local Authentication Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> > Sent: Sunday, February 10, 2013 5:37:10 PM
> > Subject: Re: [Engine-devel] Local Authentication Feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > Cc: engine-devel at ovirt.org
> > > Sent: Sunday, February 10, 2013 5:26:52 PM
> > > Subject: Re: [Engine-devel] Local Authentication Feature
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > To: engine-devel at ovirt.org
> > > > Sent: Friday, February 8, 2013 7:50:36 PM
> > > > Subject: [Engine-devel] Local Authentication Feature
> > > > 
> > > > Hello,
> > > > 
> > > > I would like to propose a new feature that allows
> > > > authentication
> > > > using
> > > > the local user database. The details are here:
> > > > 
> > > > http://www.ovirt.org/Features/Local_Authentication
> > > > 
> > > > And the proposed change is available for review here:
> > > > 
> > > > http://gerrit.ovirt.org/11863
> > > > 
> > > > I appreciate feedback.
> > > > 
> > > > 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.
> > > 
> > > Hi Juan,
> > > Very happy to see this one which actually closes an annoying gap!
> > > One thing which is missing is user management- add/remove/change
> > > users and groups. If we do not plan to handle it within ovirt,
> > > the
> > > design should state it and explain how user management should
> > > work.
> > 
> > Shouldn't this be the same as in case of external directory
> > service?
> > i.e - you manage user/group at the directory service, and then you
> > "populate" engine with it (by adding permissions to users/groups or
> > adding explicitly new users/groups to engine?)
> > 
> > > Also, what happens when a user is removed from the local DB- will
> > > all references to him be removed? Groups?
> > 
> > IMHO the behavior in this case should be as in case of current
> > LdapBroker.
> > 
> 
> This could be a decision but it's missing from the design.
> The diff I see from current supported directory servers are that
> they actually have their own management tools, which is not the
> case for local DB. Again, you may state that the various userXXX
> and groupXXX commandline utilities are the way to manage it, but
> this is lacking from the design.

Local user support is a feature we certainly need, but somehow ssh'ing into the node feels wrong.
A local db is better than the (creative) ssh hack.


> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From tnisan at redhat.com  Sun Feb 10 20:28:06 2013
From: tnisan at redhat.com (Tal Nisan)
Date: Sun, 10 Feb 2013 22:28:06 +0200
Subject: [Engine-devel] Guid & NGuid
In-Reply-To: <1139963911.78133.1360499181797.JavaMail.root@redhat.com>
References: <1139963911.78133.1360499181797.JavaMail.root@redhat.com>
Message-ID: <511802D6.5010604@redhat.com>



On 02/10/2013 02:26 PM, Gilad Chaplik wrote:
> ----- Original Message -----
>> From: "Alon Bar-Lev"<alonbl at redhat.com>
>> To: "Michael Kublin"<mkublin at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Tuesday, February 5, 2013 9:29:20 AM
>> Subject: Re: [Engine-devel] Guid&  NGuid
>>
>>
>>
>> ----- Original Message -----
>>> From: "Michael Kublin"<mkublin at redhat.com>
>>> To: "Alon Bar-Lev"<alonbl at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Tuesday, February 5, 2013 9:28:26 AM
>>> Subject: Re: [Engine-devel] Guid&  NGuid
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Alon Bar-Lev"<alonbl at redhat.com>
>>>> To: "Michael Kublin"<mkublin at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Monday, February 4, 2013 4:17:39 PM
>>>> Subject: Re: [Engine-devel] Guid&  NGuid
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Michael Kublin"<mkublin at redhat.com>
>>>>> To: engine-devel at ovirt.org
>>>>> Sent: Monday, February 4, 2013 2:15:40 PM
>>>>> Subject: Re: [Engine-devel] Guid&  NGuid
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Mike Kolesnik"<mkolesni at redhat.com>
>>>>>> To: "Michael Kublin"<mkublin at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Sent: Monday, February 4, 2013 11:48:45 AM
>>>>>> Subject: Re: [Engine-devel] Guid&  NGuid
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Laszlo Hornyak"<lhornyak at redhat.com>
>>>>>>>> To: "Michael Kublin"<mkublin at redhat.com>
>>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>>> Sent: Monday, February 4, 2013 9:56:28 AM
>>>>>>>> Subject: Re: [Engine-devel] Guid&  NGuid
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Michael Kublin"<mkublin at redhat.com>
>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>> Sent: Monday, February 4, 2013 8:47:29 AM
>>>>>>>>> Subject: Re: [Engine-devel] Guid&  NGuid
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Roy Golan"<rgolan at redhat.com>
>>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>>> Sent: Monday, February 4, 2013 9:18:21 AM
>>>>>>>>>> Subject: Re: [Engine-devel] Guid&  NGuid
>>>>>>>>>>
>>>>>>>>>> On 02/03/2013 03:19 PM, Alon Bar-Lev wrote:
>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>> From: "Omer Frenkel"<ofrenkel at redhat.com>
>>>>>>>>>>>> To: "Michael Kublin"<mkublin at redhat.com>
>>>>>>>>>>>> Cc: "engine-devel"<engine-devel at ovirt.org>
>>>>>>>>>>>> Sent: Sunday, February 3, 2013 3:12:19 PM
>>>>>>>>>>>> Subject: Re: [Engine-devel] Guid&  NGuid
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>> From: "Michael Kublin"<mkublin at redhat.com>
>>>>>>>>>>>>> To: "engine-devel"<engine-devel at ovirt.org>
>>>>>>>>>>>>> Sent: Sunday, February 3, 2013 3:10:14 PM
>>>>>>>>>>>>> Subject: [Engine-devel] Guid&  NGuid
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> In ovirt-engine code we have Guid and NGuid
>>>>>>>>>>>>> objects.
>>>>>>>>>>>>> Guid is extends NGuid and also NGuid class has
>>>>>>>>>>>>> method
>>>>>>>>>>>>> getValue()
>>>>>>>>>>>>> which should return Guid.
>>>>>>>>>>>>> As for me these two classes are look like the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> and
>>>>>>>>>>>>> I
>>>>>>>>>>>>> don't
>>>>>>>>>>>>> see
>>>>>>>>>>>>> to
>>>>>>>>>>>>> much differences between them.
>>>>>>>>>>>>> My proposal is to remove NGuid and move it
>>>>>>>>>>>>> functionality
>>>>>>>>>>>>> to
>>>>>>>>>>>>> Guid
>>>>>>>>>>>>> (Because of Guid is much more common)
>>>>>>>>>>>>>
>>>>>>>>>>>> i agree, but we need to take another step forward
>>>>>>>>>>>> and
>>>>>>>>>>>> allow
>>>>>>>>>>>> Guid
>>>>>>>>>>>> to
>>>>>>>>>>>> be null (as it should)
>>>>>>>>>>>> and not assume its EMPTY or have a value (i'm
>>>>>>>>>>>> pretty
>>>>>>>>>>>> sure
>>>>>>>>>>>> we
>>>>>>>>>>>> have
>>>>>>>>>>>> this assumption in many places)
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> And for the new people out here... why not kill
>>>>>>>>>>> both
>>>>>>>>>>> and
>>>>>>>>>>> use
>>>>>>>>>>> plain
>>>>>>>>>>> standard java UUID[1]?
>>>>>>>>>> +1 for using java.util.UUID
>>>>>>>>>>
>>>>>>>>>> NGuid functionality that should be extracted during
>>>>>>>>>> the
>>>>>>>>>> refactor
>>>>>>>>>> is
>>>>>>>>>> -
>>>>>>>>>> 1. refactor DB and Java so empty or null return
>>>>>>>>>> values
>>>>>>>>>> are
>>>>>>>>>> null
>>>>>>>>>> and
>>>>>>>>>> not
>>>>>>>>>> EMPTY_GUID
>>>>>>>>>> 2. the special constructor of NGuid for UUID return
>>>>>>>>>> by
>>>>>>>>>> Microsoft
>>>>>>>>>> AD
>>>>>>>>>> should be extracted to a factory/utility
>>>>>>>>>>> I think we should kill compat, I don't see any
>>>>>>>>>>> value
>>>>>>>>>>> in
>>>>>>>>>>> fixing
>>>>>>>>>>> anything about it while leaving it intact.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alon Bar-Lev.
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>> http://docs.oracle.com/javase/6/docs/api/java/util/UUID.html
>>>>>>>>> Actually there is exists one reason not to use directly
>>>>>>>>> UUID
>>>>>>>>> at
>>>>>>>>> server side.
>>>>>>>>> The main operations on Guid today it is to convert
>>>>>>>>> object
>>>>>>>>> to
>>>>>>>>> Guid
>>>>>>>>> or
>>>>>>>>> Guid to string.
>>>>>>>>> Guid it is immutable object, number of Guids is limited
>>>>>>>>> and
>>>>>>>>> almost
>>>>>>>>> never changed,
>>>>>>>>> These sound like classical case for object that can be
>>>>>>>>> cached.
>>>>>>>>> Benefit - reduced number of string manipulations,
>>>>>>>>> reduced
>>>>>>>>> number
>>>>>>>>> of
>>>>>>>>> created instances, less work
>>>>>>>>> for garbage collection
>>>>>>>> UUID has the same properties, it is immutable. So you
>>>>>>>> could
>>>>>>>> do
>>>>>>>> the
>>>>>>>> same with UUID, but I am not sure you could effectively
>>>>>>>> cache
>>>>>>>> these
>>>>>>>> objects and prove that you are saving either CPU, heap,
>>>>>>>> or
>>>>>>>> GC
>>>>>>>> time.
>>>>>>> These is a very common pattern:
>>>>>>> 1) implementation of valueOf() for most classes like
>>>>>>> Integer,
>>>>>>> Double,
>>>>>>> etc... has some kind of cache.
>>>>>>> 2) JVM has cache for strings that can be used and that
>>>>>>> cache
>>>>>>> can
>>>>>>> be
>>>>>>> tweaked by some JVM opts.
>>>>>>> 3) Most of our operations is perform query on DB, send
>>>>>>> request
>>>>>>> to
>>>>>>> host or parse response from host and Guid
>>>>>>>     is very common object that is immutable.
>>>>>>> I am agree that these will not solve all our performance
>>>>>>> problems
>>>>>>> but
>>>>>>> can provide some benefit, especially when it is very easy
>>>>>>> to implement.
>>>>>> We could still achieve that using a UUIDCreator class and
>>>>>> call
>>>>>> it
>>>>>> instead of Guid.fromString("")..
>>>>>>
>>>>>> Whether this is cached or not is another question which can
>>>>>> be
>>>>>> solved
>>>>>> later and checked to see if the cache improves performance or
>>>>>> not.
>>>>> These is already implementation, if it will be
>>>>> Guid.fromString("")
>>>>> or
>>>>> UUIDCreator.
>>>>> The issue is if we want to use cache, it should be implemented
>>>>> together
>>>>> with deleting/replacing of Guid/NGuid , because of it much more
>>>>> easilly
>>>> I think the value of using standard java classes is higher than
>>>> the
>>>> tuning of the engine at this regard. Dropping the compat thing is
>>>> important activity.
>>> Immutable object it is a common java design pattern
>>>> After doing this conversion, use profiler to determine where
>>>> major
>>> Already was done, and already tested a cache solution (Simple POC
>>> solution took to implement less
>>> than hour)
>>>> bottle necks are and fix these, I am not sure the above
>>>> optimization
>>>> will be first in list.
>>> Any optimization can not be first in the list, the best
>>> optimization
>>> is architecture change
>>>> If we invest resources in optimization better
>>>> to invest in these that we suffer most.
>>> Most of the issues are well known.
>> Please try to be less cryptic... Is this one of them?
> Another issue, look at:
> http://www.2ality.com/2009/01/uuids-for-gwt.html
> GWT must have a wrapper for uuid, if removing Guid, we must override UUID in GWT.
Not a serious issue, we have a uioverrides package anyway, we can make a 
wrapper in GWT
> I'm +1 on leaving Guid for now.
>
> IMHO the bigger problem we have in the Guid area is
> the ambiguous use of Guid.Empty/null; for me Guid.Empty is BLANK_TEMPLTAE_UUID.
That can indeed be an issue, there are thousands of references in the 
project to the wrapper classes, changing it at once might cause us NPEs 
from here to eternity
>>>> Regards,
>>>> Alon
>>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From dfediuck at redhat.com  Mon Feb 11 07:27:32 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 11 Feb 2013 02:27:32 -0500 (EST)
Subject: [Engine-devel] Local Authentication Feature
In-Reply-To: <2029655774.316299.1360516892757.JavaMail.root@redhat.com>
Message-ID: <1176042765.452819.1360567652508.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Andrew Cathrow" <acathrow at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, February 10, 2013 7:21:32 PM
> Subject: Re: [Engine-devel] Local Authentication Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> > Sent: Sunday, February 10, 2013 11:02:39 AM
> > Subject: Re: [Engine-devel] Local Authentication Feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > engine-devel at ovirt.org
> > > Sent: Sunday, February 10, 2013 5:37:10 PM
> > > Subject: Re: [Engine-devel] Local Authentication Feature
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > Cc: engine-devel at ovirt.org
> > > > Sent: Sunday, February 10, 2013 5:26:52 PM
> > > > Subject: Re: [Engine-devel] Local Authentication Feature
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > To: engine-devel at ovirt.org
> > > > > Sent: Friday, February 8, 2013 7:50:36 PM
> > > > > Subject: [Engine-devel] Local Authentication Feature
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > I would like to propose a new feature that allows
> > > > > authentication
> > > > > using
> > > > > the local user database. The details are here:
> > > > > 
> > > > > http://www.ovirt.org/Features/Local_Authentication
> > > > > 
> > > > > And the proposed change is available for review here:
> > > > > 
> > > > > http://gerrit.ovirt.org/11863
> > > > > 
> > > > > I appreciate feedback.
> > > > > 
> > > > > 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.
> > > > 
> > > > Hi Juan,
> > > > Very happy to see this one which actually closes an annoying
> > > > gap!
> > > > One thing which is missing is user management-
> > > > add/remove/change
> > > > users and groups. If we do not plan to handle it within ovirt,
> > > > the
> > > > design should state it and explain how user management should
> > > > work.
> > > 
> > > Shouldn't this be the same as in case of external directory
> > > service?
> > > i.e - you manage user/group at the directory service, and then
> > > you
> > > "populate" engine with it (by adding permissions to users/groups
> > > or
> > > adding explicitly new users/groups to engine?)
> > > 
> > > > Also, what happens when a user is removed from the local DB-
> > > > will
> > > > all references to him be removed? Groups?
> > > 
> > > IMHO the behavior in this case should be as in case of current
> > > LdapBroker.
> > > 
> > 
> > This could be a decision but it's missing from the design.
> > The diff I see from current supported directory servers are that
> > they actually have their own management tools, which is not the
> > case for local DB. Again, you may state that the various userXXX
> > and groupXXX commandline utilities are the way to manage it, but
> > this is lacking from the design.
> 
> Local user support is a feature we certainly need, but somehow
> ssh'ing into the node feels wrong.
> A local db is better than the (creative) ssh hack.
> 
> 
IIUC it's an internal SSH just for the authentication part.
If it succeeds the user is authenticated. Otherwise the user
will fail to login. That's the only use of the ssh. everything
else should work as it used to so far.



From lhornyak at redhat.com  Mon Feb 11 07:56:42 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 11 Feb 2013 02:56:42 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <1047441680.297314.1360510829231.JavaMail.root@redhat.com>
Message-ID: <1524582047.284330.1360569402865.JavaMail.root@redhat.com>

Hi Doron,

If the watchdog is set to action="reset" and you break the kernel, the VM will stay in UP state while waiting for the watchdog to reset the VM, and will still be in UP state while rebooting. So in theory engine will not be notified about a crash.
This behavior is different when the action="poweroff" because the watchdog will really put the VM in a Down state and it is engine's job to restart it if HA as soon as it receives the notification from VDSM.


----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, February 10, 2013 4:40:29 PM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> Hi Laszlo,
> Looks very useful. Any thoughts on what engine will do while
> if the VM is defined as HA while the watchdog is resetting it?
> 
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Wednesday, February 6, 2013 11:25:03 AM
> > Subject: Re: [Engine-devel] Watchdog support Feature
> > 
> > Hi everyone,
> > 
> > I hope everyone is satisfied with the spec, please read it through
> > for the last time and I will move it to implementation phase soon.
> > 
> > Thx,
> > Laszlo
> > 
> > ----- Original Message -----
> > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Thursday, January 24, 2013 3:19:57 PM
> > > Subject: Watchdog support Feature
> > > 
> > > Hi,
> > > 
> > > Watchdog support in engine will add watchdog to the ovirt UI and
> > > REST
> > > API. Watchdog cards will be mainly used in HA vm's.
> > > 
> > > http://www.ovirt.org/Features/Watchdog_engine_support
> > > 
> > > Your feedback is welcome!
> > > 
> > > Thank you,
> > > Laszlo
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From ovedo at redhat.com  Mon Feb 11 08:18:25 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Mon, 11 Feb 2013 03:18:25 -0500 (EST)
Subject: [Engine-devel] Local Authentication Feature
In-Reply-To: <1176042765.452819.1360567652508.JavaMail.root@redhat.com>
Message-ID: <158623421.406310.1360570705028.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Andrew Cathrow" <acathrow at redhat.com>
> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> Sent: Monday, February 11, 2013 9:27:32 AM
> Subject: Re: [Engine-devel] Local Authentication Feature
> 
> 
> 
> ----- Original Message -----
> > From: "Andrew Cathrow" <acathrow at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
> > Sent: Sunday, February 10, 2013 7:21:32 PM
> > Subject: Re: [Engine-devel] Local Authentication Feature
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > engine-devel at ovirt.org
> > > Sent: Sunday, February 10, 2013 11:02:39 AM
> > > Subject: Re: [Engine-devel] Local Authentication Feature
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > Cc: "Juan Hernandez" <jhernand at redhat.com>,
> > > > engine-devel at ovirt.org
> > > > Sent: Sunday, February 10, 2013 5:37:10 PM
> > > > Subject: Re: [Engine-devel] Local Authentication Feature
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > To: "Juan Hernandez" <jhernand at redhat.com>
> > > > > Cc: engine-devel at ovirt.org
> > > > > Sent: Sunday, February 10, 2013 5:26:52 PM
> > > > > Subject: Re: [Engine-devel] Local Authentication Feature
> > > > > 
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > > > From: "Juan Hernandez" <jhernand at redhat.com>
> > > > > > To: engine-devel at ovirt.org
> > > > > > Sent: Friday, February 8, 2013 7:50:36 PM
> > > > > > Subject: [Engine-devel] Local Authentication Feature
> > > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > I would like to propose a new feature that allows
> > > > > > authentication
> > > > > > using
> > > > > > the local user database. The details are here:
> > > > > > 
> > > > > > http://www.ovirt.org/Features/Local_Authentication
> > > > > > 
> > > > > > And the proposed change is available for review here:
> > > > > > 
> > > > > > http://gerrit.ovirt.org/11863
> > > > > > 
> > > > > > I appreciate feedback.
> > > > > > 
> > > > > > 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.
> > > > > 
> > > > > Hi Juan,
> > > > > Very happy to see this one which actually closes an annoying
> > > > > gap!
> > > > > One thing which is missing is user management-
> > > > > add/remove/change
> > > > > users and groups. If we do not plan to handle it within
> > > > > ovirt,
> > > > > the
> > > > > design should state it and explain how user management should
> > > > > work.
> > > > 
> > > > Shouldn't this be the same as in case of external directory
> > > > service?
> > > > i.e - you manage user/group at the directory service, and then
> > > > you
> > > > "populate" engine with it (by adding permissions to
> > > > users/groups
> > > > or
> > > > adding explicitly new users/groups to engine?)
> > > > 
> > > > > Also, what happens when a user is removed from the local DB-
> > > > > will
> > > > > all references to him be removed? Groups?
> > > > 
> > > > IMHO the behavior in this case should be as in case of current
> > > > LdapBroker.
> > > > 
> > > 
> > > This could be a decision but it's missing from the design.
> > > The diff I see from current supported directory servers are that
> > > they actually have their own management tools, which is not the
> > > case for local DB. Again, you may state that the various userXXX
> > > and groupXXX commandline utilities are the way to manage it, but
> > > this is lacking from the design.
> > 
> > Local user support is a feature we certainly need, but somehow
> > ssh'ing into the node feels wrong.
> > A local db is better than the (creative) ssh hack.
> > 
> > 
> IIUC it's an internal SSH just for the authentication part.
> If it succeeds the user is authenticated. Otherwise the user
> will fail to login. That's the only use of the ssh. everything
> else should work as it used to so far.
> 

I also wouldn't say it is a hack, but on the other hand requiring it for such a feature feels wrong to me as well.
Some sysadmins also choose to disable SSH for security reasons, so it won't work for them.
Isn't there an option to use PAM instead? Something similar?

As for using local DB, I think it is a different feature than this one, so they can both co-exist.

Oved

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Mon Feb 11 09:17:01 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 11 Feb 2013 10:17:01 +0100
Subject: [Engine-devel] Local Authentication Feature
In-Reply-To: <158623421.406310.1360570705028.JavaMail.root@redhat.com>
References: <158623421.406310.1360570705028.JavaMail.root@redhat.com>
Message-ID: <5118B70D.8050703@redhat.com>

On 02/11/2013 09:18 AM, Oved Ourfalli wrote:
>
>
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck at redhat.com>
>> To: "Andrew Cathrow" <acathrow at redhat.com>
>> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
>> Sent: Monday, February 11, 2013 9:27:32 AM
>> Subject: Re: [Engine-devel] Local Authentication Feature
>>
>>
>>
>> ----- Original Message -----
>>> From: "Andrew Cathrow" <acathrow at redhat.com>
>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>> Cc: "Juan Hernandez" <jhernand at redhat.com>, engine-devel at ovirt.org
>>> Sent: Sunday, February 10, 2013 7:21:32 PM
>>> Subject: Re: [Engine-devel] Local Authentication Feature
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>,
>>>> engine-devel at ovirt.org
>>>> Sent: Sunday, February 10, 2013 11:02:39 AM
>>>> Subject: Re: [Engine-devel] Local Authentication Feature
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
>>>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>>>> Cc: "Juan Hernandez" <jhernand at redhat.com>,
>>>>> engine-devel at ovirt.org
>>>>> Sent: Sunday, February 10, 2013 5:37:10 PM
>>>>> Subject: Re: [Engine-devel] Local Authentication Feature
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>>>> To: "Juan Hernandez" <jhernand at redhat.com>
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Sent: Sunday, February 10, 2013 5:26:52 PM
>>>>>> Subject: Re: [Engine-devel] Local Authentication Feature
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Juan Hernandez" <jhernand at redhat.com>
>>>>>>> To: engine-devel at ovirt.org
>>>>>>> Sent: Friday, February 8, 2013 7:50:36 PM
>>>>>>> Subject: [Engine-devel] Local Authentication Feature
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I would like to propose a new feature that allows
>>>>>>> authentication
>>>>>>> using
>>>>>>> the local user database. The details are here:
>>>>>>>
>>>>>>> http://www.ovirt.org/Features/Local_Authentication
>>>>>>>
>>>>>>> And the proposed change is available for review here:
>>>>>>>
>>>>>>> http://gerrit.ovirt.org/11863
>>>>>>>
>>>>>>> I appreciate feedback.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Juan Hernandez
>>>>>>
>>>>>> Hi Juan,
>>>>>> Very happy to see this one which actually closes an annoying
>>>>>> gap!
>>>>>> One thing which is missing is user management-
>>>>>> add/remove/change
>>>>>> users and groups. If we do not plan to handle it within
>>>>>> ovirt,
>>>>>> the
>>>>>> design should state it and explain how user management should
>>>>>> work.

User management is not included in the feature, like it isn't currently 
with LDAP. The administrator has to use external tools to manage that 
database, then use the GUI to add the users and give them permissions. I 
updated the description accordingly.

>>>>>
>>>>> Shouldn't this be the same as in case of external directory
>>>>> service?
>>>>> i.e - you manage user/group at the directory service, and then
>>>>> you
>>>>> "populate" engine with it (by adding permissions to
>>>>> users/groups
>>>>> or
>>>>> adding explicitly new users/groups to engine?)
>>>>>
>>>>>> Also, what happens when a user is removed from the local DB-
>>>>>> will
>>>>>> all references to him be removed? Groups?
>>>>>
>>>>> IMHO the behavior in this case should be as in case of current
>>>>> LdapBroker.

Yes, the behavior is the same, the engine refreshes its database from 
the external system (I need to test this).

>>>>>
>>>>
>>>> This could be a decision but it's missing from the design.
>>>> The diff I see from current supported directory servers are that
>>>> they actually have their own management tools, which is not the
>>>> case for local DB. Again, you may state that the various userXXX
>>>> and groupXXX commandline utilities are the way to manage it, but
>>>> this is lacking from the design.
>>>
>>> Local user support is a feature we certainly need, but somehow
>>> ssh'ing into the node feels wrong.
>>> A local db is better than the (creative) ssh hack.
>>>

An additional database is better in some scenarios (probably in most 
scenarios) but there are scenarios where using the local database is 
still better. For example if already using NIS or if you just need a few 
users that are already users (or will be) of the system where you are 
installing the engine.

>>>
>> IIUC it's an internal SSH just for the authentication part.
>> If it succeeds the user is authenticated. Otherwise the user
>> will fail to login. That's the only use of the ssh. everything
>> else should work as it used to so far.
>>

SSH is used only for authentication. Users don't need a home directory 
or permission to use a shell. A typical user would be added like this:

useradd -M -s /sbin/nologin -c 'Whatever' whatever

In addition the SSH used for authentication is completely local, so 
external SSH access could be blocked by the firewall and authentication 
will still work.

>
> I also wouldn't say it is a hack, but on the other hand requiring it for such a feature feels wrong to me as well.
> Some sysadmins also choose to disable SSH for security reasons, so it won't work for them.
> Isn't there an option to use PAM instead? Something similar?
>

This feature doesn't use PAM at all, it only uses NSS. Using PAM for 
authentication requires a component with root permissions (be it the 
program itself or an external binary with SUID permissions). We don't 
have such thing. You can think of the SSH server as that external binary.

> As for using local DB, I think it is a different feature than this one, so they can both co-exist.
>
> Oved

-- 
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.


From dfediuck at redhat.com  Mon Feb 11 16:43:20 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 11 Feb 2013 11:43:20 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <1524582047.284330.1360569402865.JavaMail.root@redhat.com>
Message-ID: <2088134066.728079.1360601000873.JavaMail.root@redhat.com>


----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, February 11, 2013 9:56:42 AM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> Hi Doron,
> 
> If the watchdog is set to action="reset" and you break the kernel,
> the VM will stay in UP state while waiting for the watchdog to reset
> the VM, and will still be in UP state while rebooting. So in theory
> engine will not be notified about a crash.
> This behavior is different when the action="poweroff" because the
> watchdog will really put the VM in a Down state and it is engine's
> job to restart it if HA as soon as it receives the notification from
> VDSM.
> 
Thanks. Just note that poweroff requires guest co-operation
which we loose when kernel crashes. That's why it's not recommended.

> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Sunday, February 10, 2013 4:40:29 PM
> > Subject: Re: [Engine-devel] Watchdog support Feature
> > 
> > Hi Laszlo,
> > Looks very useful. Any thoughts on what engine will do while
> > if the VM is defined as HA while the watchdog is resetting it?
> > 
> > 
> > ----- Original Message -----
> > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Wednesday, February 6, 2013 11:25:03 AM
> > > Subject: Re: [Engine-devel] Watchdog support Feature
> > > 
> > > Hi everyone,
> > > 
> > > I hope everyone is satisfied with the spec, please read it
> > > through
> > > for the last time and I will move it to implementation phase
> > > soon.
> > > 
> > > Thx,
> > > Laszlo
> > > 
> > > ----- Original Message -----
> > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Thursday, January 24, 2013 3:19:57 PM
> > > > Subject: Watchdog support Feature
> > > > 
> > > > Hi,
> > > > 
> > > > Watchdog support in engine will add watchdog to the ovirt UI
> > > > and
> > > > REST
> > > > API. Watchdog cards will be mainly used in HA vm's.
> > > > 
> > > > http://www.ovirt.org/Features/Watchdog_engine_support
> > > > 
> > > > Your feedback is welcome!
> > > > 
> > > > Thank you,
> > > > Laszlo
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lhornyak at redhat.com  Mon Feb 11 16:51:23 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 11 Feb 2013 11:51:23 -0500 (EST)
Subject: [Engine-devel] Watchdog support Feature
In-Reply-To: <2088134066.728079.1360601000873.JavaMail.root@redhat.com>
Message-ID: <707660315.654577.1360601483769.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, February 11, 2013 5:43:20 PM
> Subject: Re: [Engine-devel] Watchdog support Feature
> 
> 
> ----- Original Message -----
> > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, February 11, 2013 9:56:42 AM
> > Subject: Re: [Engine-devel] Watchdog support Feature
> > 
> > Hi Doron,
> > 
> > If the watchdog is set to action="reset" and you break the kernel,
> > the VM will stay in UP state while waiting for the watchdog to
> > reset
> > the VM, and will still be in UP state while rebooting. So in theory
> > engine will not be notified about a crash.
> > This behavior is different when the action="poweroff" because the
> > watchdog will really put the VM in a Down state and it is engine's
> > job to restart it if HA as soon as it receives the notification
> > from
> > VDSM.
> > 
> Thanks. Just note that poweroff requires guest co-operation
> which we loose when kernel crashes. That's why it's not recommended.

That's the shutdown. http://libvirt.org/formatdomain.html#elementsWatchdog
I always confuse the two :) Fortunately we will only have one.

> 
> > 
> > ----- Original Message -----
> > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > To: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Sunday, February 10, 2013 4:40:29 PM
> > > Subject: Re: [Engine-devel] Watchdog support Feature
> > > 
> > > Hi Laszlo,
> > > Looks very useful. Any thoughts on what engine will do while
> > > if the VM is defined as HA while the watchdog is resetting it?
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Wednesday, February 6, 2013 11:25:03 AM
> > > > Subject: Re: [Engine-devel] Watchdog support Feature
> > > > 
> > > > Hi everyone,
> > > > 
> > > > I hope everyone is satisfied with the spec, please read it
> > > > through
> > > > for the last time and I will move it to implementation phase
> > > > soon.
> > > > 
> > > > Thx,
> > > > Laszlo
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Thursday, January 24, 2013 3:19:57 PM
> > > > > Subject: Watchdog support Feature
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Watchdog support in engine will add watchdog to the ovirt UI
> > > > > and
> > > > > REST
> > > > > API. Watchdog cards will be mainly used in HA vm's.
> > > > > 
> > > > > http://www.ovirt.org/Features/Watchdog_engine_support
> > > > > 
> > > > > Your feedback is welcome!
> > > > > 
> > > > > Thank you,
> > > > > Laszlo
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From mkublin at redhat.com  Tue Feb 12 09:38:33 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Tue, 12 Feb 2013 04:38:33 -0500 (EST)
Subject: [Engine-devel] Global transaction in ovirt-engine
In-Reply-To: <1185822216.607971.1360660591087.JavaMail.root@redhat.com>
Message-ID: <195854836.612756.1360661913087.JavaMail.root@redhat.com>

The issue is a following (I think I had raised it once),
by default when any command is invoked in ovirt-engine a transaction is opened.
Now, lets take a look on complicated command which is performing a lot of XML-RPC/HTTP calls and just simple update , 
such command is a main cause for the following problems:
1. Long transactions, each call increase a time of transaction
2. When transaction is opened a connection which is associated with it also in used, so a number of available DB connections reduced from
connection pool.
3. A errors : transaction was cancelled and operation is failed on engine side, but successes at host side.
4. Performance - "try to keep transactions as short as possible".
5. Performance - to many unneeded transactions
6. Bug debugging - it is very difficult to understand why something was committed and something not why transaction was reverted or not, 
   when we have a lot of nested transactions.

Now, what should be done by my opinion:
1. Change default behaviour - by default not to open a transaction (Today, transaction is opened and if we don't want a command should be marked
   by NonTransactiveCommandAttribute) - it is simple
2. The change described at 1 will require to rewrite and redesign some flows - more difficult, but also can be done pretty fast. 
   By the way this can be or even should be done at any case. 
3. All new commands should not be based on global transaction or keep in mind that global transaction can be disabled

Benefits,
1. Better performance
2. Cleaner code
3. Less bugs
4. Increased scale

Regards Michael


From ashakarc at redhat.com  Tue Feb 12 11:04:44 2013
From: ashakarc at redhat.com (Asaf Shakarchi)
Date: Tue, 12 Feb 2013 06:04:44 -0500 (EST)
Subject: [Engine-devel] Time for Spring?
In-Reply-To: <5107A79B.4070708@redhat.com>
Message-ID: <866539563.1114884.1360667084174.JavaMail.root@redhat.com>

----- Original Message -----
> Hi,
> 
> it is rather cold in Europe, but can I ask, what's the current
> opinion
> or plans about "full" integration of Spring Framework into oVirt
> engine
> (Backend)?
> 
> This is a commonly accepted integration framework among Java
> programmers
> and industry standard, which
> solves many pains from small to large projects. And can lead to a
> better
> understanding of the program.
> 
> There are several Spring dependencies inside oVirt project, but
> mostly
> for LDAP and database communication (JDBC template).
> 
> Still missing (sorry, looks like marketing, but..):
> 
> - dependency injection
> - aspect-oriented programming (AOP)
> - enterprise integration patterns
> 
> Is something true? :-)
> 
> 1. We tried, but it is too large and overcomplicated, it can be
> solved
> better way for the project purpose
> 2. We tried, but we think, we need just e.g. JDBC, LDAP layer covered
> now
> 3. We would like to integrate with e.g. Hibernate soon, EJB,
> remoting,
> unit tests, integration tests, ... , probably we will need it soon
> 4. We understand and need dependency injection, but there are other
> light DI containers (Pico, Guice, JBoss Seam).
> etc.
> 
> Still, I think there is strong potential, probably not clear today.
> We
> cannot avoid Guice on frontend side because of GWTP, but the backend
> lacks something.
It may be possible to avoid using Guice on frontend at some point in the future,
There's some work going on with abstracting the DI impl of GWTP, this work is mainly done to integration ERAI with GWTP,
You can follow the progress here:

http://code.google.com/p/gwt-platform/issues/detail?id=423
https://groups.google.com/forum/#!msg/gwt-platform/rHiNXJGS0jY/UGU0vHQMJq0J

> Or not?
> 
> Thanks.
> 
> Regards,
> Libor
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From laravot at redhat.com  Tue Feb 12 11:06:52 2013
From: laravot at redhat.com (Liron Aravot)
Date: Tue, 12 Feb 2013 06:06:52 -0500 (EST)
Subject: [Engine-devel] Global transaction in ovirt-engine
In-Reply-To: <195854836.612756.1360661913087.JavaMail.root@redhat.com>
Message-ID: <1765033876.330934.1360667212006.JavaMail.root@redhat.com>

+1
it will also solve the bug of can do action checks running outside transaction.

maybe we can also find a nice way to keep db only commands (without vdsm calls) to run within transaction to avoid repeat the code to open the transaction in such commands.

by the way, we should solve the same for the end methods.

----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, February 12, 2013 11:38:33 AM
> Subject: [Engine-devel] Global transaction in ovirt-engine
> 
> The issue is a following (I think I had raised it once),
> by default when any command is invoked in ovirt-engine a transaction
> is opened.
> Now, lets take a look on complicated command which is performing a
> lot of XML-RPC/HTTP calls and just simple update ,
> such command is a main cause for the following problems:
> 1. Long transactions, each call increase a time of transaction
> 2. When transaction is opened a connection which is associated with
> it also in used, so a number of available DB connections reduced
> from
> connection pool.
> 3. A errors : transaction was cancelled and operation is failed on
> engine side, but successes at host side.
> 4. Performance - "try to keep transactions as short as possible".
> 5. Performance - to many unneeded transactions
> 6. Bug debugging - it is very difficult to understand why something
> was committed and something not why transaction was reverted or not,
>    when we have a lot of nested transactions.
> 
> Now, what should be done by my opinion:
> 1. Change default behaviour - by default not to open a transaction
> (Today, transaction is opened and if we don't want a command should
> be marked
>    by NonTransactiveCommandAttribute) - it is simple
> 2. The change described at 1 will require to rewrite and redesign
> some flows - more difficult, but also can be done pretty fast.
>    By the way this can be or even should be done at any case.
> 3. All new commands should not be based on global transaction or keep
> in mind that global transaction can be disabled
> 
> Benefits,
> 1. Better performance
> 2. Cleaner code
> 3. Less bugs
> 4. Increased scale
> 
> Regards Michael
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From laravot at redhat.com  Tue Feb 12 11:08:07 2013
From: laravot at redhat.com (Liron Aravot)
Date: Tue, 12 Feb 2013 06:08:07 -0500 (EST)
Subject: [Engine-devel] Global transaction in ovirt-engine
In-Reply-To: <1765033876.330934.1360667212006.JavaMail.root@redhat.com>
Message-ID: <748884221.332125.1360667287883.JavaMail.root@redhat.com>

"it will also solve the bug of can do action checks running outside" - when not executing it from opened transaction ofcourse :-), but now it happens also by mistake.

----- Original Message -----
> From: "Liron Aravot" <laravot at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, February 12, 2013 1:06:52 PM
> Subject: Re: [Engine-devel] Global transaction in ovirt-engine
> 
> +1
> it will also solve the bug of can do action checks running outside
> transaction.
> 
> maybe we can also find a nice way to keep db only commands (without
> vdsm calls) to run within transaction to avoid repeat the code to
> open the transaction in such commands.
> 
> by the way, we should solve the same for the end methods.
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, February 12, 2013 11:38:33 AM
> > Subject: [Engine-devel] Global transaction in ovirt-engine
> > 
> > The issue is a following (I think I had raised it once),
> > by default when any command is invoked in ovirt-engine a
> > transaction
> > is opened.
> > Now, lets take a look on complicated command which is performing a
> > lot of XML-RPC/HTTP calls and just simple update ,
> > such command is a main cause for the following problems:
> > 1. Long transactions, each call increase a time of transaction
> > 2. When transaction is opened a connection which is associated with
> > it also in used, so a number of available DB connections reduced
> > from
> > connection pool.
> > 3. A errors : transaction was cancelled and operation is failed on
> > engine side, but successes at host side.
> > 4. Performance - "try to keep transactions as short as possible".
> > 5. Performance - to many unneeded transactions
> > 6. Bug debugging - it is very difficult to understand why something
> > was committed and something not why transaction was reverted or
> > not,
> >    when we have a lot of nested transactions.
> > 
> > Now, what should be done by my opinion:
> > 1. Change default behaviour - by default not to open a transaction
> > (Today, transaction is opened and if we don't want a command should
> > be marked
> >    by NonTransactiveCommandAttribute) - it is simple
> > 2. The change described at 1 will require to rewrite and redesign
> > some flows - more difficult, but also can be done pretty fast.
> >    By the way this can be or even should be done at any case.
> > 3. All new commands should not be based on global transaction or
> > keep
> > in mind that global transaction can be disabled
> > 
> > Benefits,
> > 1. Better performance
> > 2. Cleaner code
> > 3. Less bugs
> > 4. Increased scale
> > 
> > Regards Michael
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Tue Feb 12 12:22:09 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 12 Feb 2013 07:22:09 -0500 (EST)
Subject: [Engine-devel] Global transaction in ovirt-engine
In-Reply-To: <748884221.332125.1360667287883.JavaMail.root@redhat.com>
Message-ID: <1507063362.1002034.1360671729751.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Liron Aravot" <laravot at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, February 12, 2013 1:08:07 PM
> Subject: Re: [Engine-devel] Global transaction in ovirt-engine
> 
> "it will also solve the bug of can do action checks running outside"
> - when not executing it from opened transaction ofcourse :-), but
> now it happens also by mistake.
> 
> ----- Original Message -----
> > From: "Liron Aravot" <laravot at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, February 12, 2013 1:06:52 PM
> > Subject: Re: [Engine-devel] Global transaction in ovirt-engine
> > 
> > +1
> > it will also solve the bug of can do action checks running outside
> > transaction.
> > 
> > maybe we can also find a nice way to keep db only commands (without
> > vdsm calls) to run within transaction to avoid repeat the code to
> > open the transaction in such commands.
> > 
> > by the way, we should solve the same for the end methods.
> > 
> > ----- Original Message -----
> > > From: "Michael Kublin" <mkublin at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, February 12, 2013 11:38:33 AM
> > > Subject: [Engine-devel] Global transaction in ovirt-engine
> > > 
> > > The issue is a following (I think I had raised it once),
> > > by default when any command is invoked in ovirt-engine a
> > > transaction
> > > is opened.
> > > Now, lets take a look on complicated command which is performing
> > > a
> > > lot of XML-RPC/HTTP calls and just simple update ,
> > > such command is a main cause for the following problems:
> > > 1. Long transactions, each call increase a time of transaction
> > > 2. When transaction is opened a connection which is associated
> > > with
> > > it also in used, so a number of available DB connections reduced
> > > from
> > > connection pool.
> > > 3. A errors : transaction was cancelled and operation is failed
> > > on

> > > engine side, but successes at host side.
> > > 4. Performance - "try to keep transactions as short as possible".
> > > 5. Performance - to many unneeded transactions
> > > 6. Bug debugging - it is very difficult to understand why
> > > something
> > > was committed and something not why transaction was reverted or
> > > not,
> > >    when we have a lot of nested transactions.
> > > 
> > > Now, what should be done by my opinion:
> > > 1. Change default behaviour - by default not to open a
> > > transaction
> > > (Today, transaction is opened and if we don't want a command
> > > should
> > > be marked
> > >    by NonTransactiveCommandAttribute) - it is simple
> > > 2. The change described at 1 will require to rewrite and redesign
> > > some flows - more difficult, but also can be done pretty fast.
> > >    By the way this can be or even should be done at any case.
> > > 3. All new commands should not be based on global transaction or
> > > keep
> > > in mind that global transaction can be disabled

In general - I think the idea is good, we need to take into consideration what you mentioned at 2.


> > > 
> > > Benefits,
> > > 1. Better performance
> > > 2. Cleaner code
> > > 3. Less bugs
> > > 4. Increased scale
> > > 
> > > Regards Michael
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mkublin at redhat.com  Tue Feb 12 13:11:36 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Tue, 12 Feb 2013 08:11:36 -0500 (EST)
Subject: [Engine-devel] Global transaction in ovirt-engine
In-Reply-To: <1507063362.1002034.1360671729751.JavaMail.root@redhat.com>
Message-ID: <2049836953.674996.1360674696385.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Liron Aravot" <laravot at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Kublin" <mkublin at redhat.com>
> Sent: Tuesday, February 12, 2013 2:22:09 PM
> Subject: Re: [Engine-devel] Global transaction in ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Liron Aravot" <laravot at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, February 12, 2013 1:08:07 PM
> > Subject: Re: [Engine-devel] Global transaction in ovirt-engine
> > 
> > "it will also solve the bug of can do action checks running
> > outside"
> > - when not executing it from opened transaction ofcourse :-), but
> > now it happens also by mistake.
> > 
> > ----- Original Message -----
> > > From: "Liron Aravot" <laravot at redhat.com>
> > > To: "Michael Kublin" <mkublin at redhat.com>
> > > Cc: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, February 12, 2013 1:06:52 PM
> > > Subject: Re: [Engine-devel] Global transaction in ovirt-engine
> > > 
> > > +1
> > > it will also solve the bug of can do action checks running
> > > outside
> > > transaction.
> > > 
> > > maybe we can also find a nice way to keep db only commands
> > > (without
> > > vdsm calls) to run within transaction to avoid repeat the code to
> > > open the transaction in such commands.
> > > 
> > > by the way, we should solve the same for the end methods.
> > > 
> > > ----- Original Message -----
> > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, February 12, 2013 11:38:33 AM
> > > > Subject: [Engine-devel] Global transaction in ovirt-engine
> > > > 
> > > > The issue is a following (I think I had raised it once),
> > > > by default when any command is invoked in ovirt-engine a
> > > > transaction
> > > > is opened.
> > > > Now, lets take a look on complicated command which is
> > > > performing
> > > > a
> > > > lot of XML-RPC/HTTP calls and just simple update ,
> > > > such command is a main cause for the following problems:
> > > > 1. Long transactions, each call increase a time of transaction
> > > > 2. When transaction is opened a connection which is associated
> > > > with
> > > > it also in used, so a number of available DB connections
> > > > reduced
> > > > from
> > > > connection pool.
> > > > 3. A errors : transaction was cancelled and operation is failed
> > > > on
> 
> > > > engine side, but successes at host side.
> > > > 4. Performance - "try to keep transactions as short as
> > > > possible".
> > > > 5. Performance - to many unneeded transactions
> > > > 6. Bug debugging - it is very difficult to understand why
> > > > something
> > > > was committed and something not why transaction was reverted or
> > > > not,
> > > >    when we have a lot of nested transactions.
> > > > 
> > > > Now, what should be done by my opinion:
> > > > 1. Change default behaviour - by default not to open a
> > > > transaction
> > > > (Today, transaction is opened and if we don't want a command
> > > > should
> > > > be marked
> > > >    by NonTransactiveCommandAttribute) - it is simple
> > > > 2. The change described at 1 will require to rewrite and
> > > > redesign
> > > > some flows - more difficult, but also can be done pretty fast.
> > > >    By the way this can be or even should be done at any case.
> > > > 3. All new commands should not be based on global transaction
> > > > or
> > > > keep
> > > > in mind that global transaction can be disabled
> 
> In general - I think the idea is good, we need to take into
> consideration what you mentioned at 2.
> 
That's why I wrote about this, we should start at some point.
Now, we can divide it to areas of functionality and it will be great 
to get input about situation in such areas.
I know about the following areas:
1. VM related flows (run,stop,migrate,hibernate, etc..)  
2. Host flows (maintenance, activate, etc...)
3. Storage flows (activate, deactivate, reconstruct)
4. VM and templates flows (create template, remove template, etc...)
5. Network flows (set up network, add network, etc...)
6. Permissions
and so one ....
> > > > 
> > > > Benefits,
> > > > 1. Better performance
> > > > 2. Cleaner code
> > > > 3. Less bugs
> > > > 4. Increased scale
> > > > 
> > > > Regards Michael

> 


From ofrenkel at redhat.com  Tue Feb 12 14:32:44 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Tue, 12 Feb 2013 09:32:44 -0500 (EST)
Subject: [Engine-devel] Global transaction in ovirt-engine
In-Reply-To: <195854836.612756.1360661913087.JavaMail.root@redhat.com>
Message-ID: <1479907628.1208064.1360679564073.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, February 12, 2013 11:38:33 AM
> Subject: [Engine-devel] Global transaction in ovirt-engine
> 
> The issue is a following (I think I had raised it once),
> by default when any command is invoked in ovirt-engine a transaction
> is opened.
> Now, lets take a look on complicated command which is performing a
> lot of XML-RPC/HTTP calls and just simple update ,
> such command is a main cause for the following problems:
> 1. Long transactions, each call increase a time of transaction
> 2. When transaction is opened a connection which is associated with
> it also in used, so a number of available DB connections reduced
> from
> connection pool.
> 3. A errors : transaction was cancelled and operation is failed on
> engine side, but successes at host side.
> 4. Performance - "try to keep transactions as short as possible".
> 5. Performance - to many unneeded transactions
> 6. Bug debugging - it is very difficult to understand why something
> was committed and something not why transaction was reverted or not,
>    when we have a lot of nested transactions.
> 
> Now, what should be done by my opinion:
> 1. Change default behaviour - by default not to open a transaction
> (Today, transaction is opened and if we don't want a command should
> be marked
>    by NonTransactiveCommandAttribute) - it is simple
> 2. The change described at 1 will require to rewrite and redesign
> some flows - more difficult, but also can be done pretty fast.
>    By the way this can be or even should be done at any case.
> 3. All new commands should not be based on global transaction or keep
> in mind that global transaction can be disabled
> 
> Benefits,
> 1. Better performance
> 2. Cleaner code
> 3. Less bugs
> 4. Increased scale
> 
> Regards Michael
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 

need to remember that transaction also gave us 10-min limit for command execution,
not saying its good or bad, but disabling the transactions will allow commands to run forever,
this 10 min limit actually, saved us few times when commands got stuck in all kind of locks etc..


From lspevak at redhat.com  Tue Feb 12 14:52:16 2013
From: lspevak at redhat.com (Libor Spevak)
Date: Tue, 12 Feb 2013 15:52:16 +0100
Subject: [Engine-devel] Time for Spring?
In-Reply-To: <866539563.1114884.1360667084174.JavaMail.root@redhat.com>
References: <866539563.1114884.1360667084174.JavaMail.root@redhat.com>
Message-ID: <511A5720.1080809@redhat.com>

On 12.2.2013 12:04, Asaf Shakarchi wrote:
> ----- Original Message -----
>> Hi,
>>
>> it is rather cold in Europe, but can I ask, what's the current
>> opinion
>> or plans about "full" integration of Spring Framework into oVirt
>> engine
>> (Backend)?
>>
>> This is a commonly accepted integration framework among Java
>> programmers
>> and industry standard, which
>> solves many pains from small to large projects. And can lead to a
>> better
>> understanding of the program.
>>
>> There are several Spring dependencies inside oVirt project, but
>> mostly
>> for LDAP and database communication (JDBC template).
>>
>> Still missing (sorry, looks like marketing, but..):
>>
>> - dependency injection
>> - aspect-oriented programming (AOP)
>> - enterprise integration patterns
>>
>> Is something true? :-)
>>
>> 1. We tried, but it is too large and overcomplicated, it can be
>> solved
>> better way for the project purpose
>> 2. We tried, but we think, we need just e.g. JDBC, LDAP layer covered
>> now
>> 3. We would like to integrate with e.g. Hibernate soon, EJB,
>> remoting,
>> unit tests, integration tests, ... , probably we will need it soon
>> 4. We understand and need dependency injection, but there are other
>> light DI containers (Pico, Guice, JBoss Seam).
>> etc.
>>
>> Still, I think there is strong potential, probably not clear today.
>> We
>> cannot avoid Guice on frontend side because of GWTP, but the backend
>> lacks something.
> It may be possible to avoid using Guice on frontend at some point in the future,
> There's some work going on with abstracting the DI impl of GWTP, this work is mainly done to integration ERAI with GWTP,
> You can follow the progress here:
>
> http://code.google.com/p/gwt-platform/issues/detail?id=423
> https://groups.google.com/forum/#!msg/gwt-platform/rHiNXJGS0jY/UGU0vHQMJq0J
Thanks for the links. http://www.jboss.org/errai project looks 
progressive and the technologies that it integrates together would fit 
into Engine project purpose. But I am not sure, if a mature project like 
oVirt can easily replace used libraries or frameworks. Because a lot of 
frameworks nowadays define not only technologies (mostly limited set), 
but also overall architecture, which is very useful for startup 
applications, but to add +1 technology requires some effort and for 
existing applications total refactoring.

For massive changes like JPA/Hibernate integration I can imagine e.g. 
Spring support in the existing project, but I think the benefits and 
effort are questionable nowadays, although there are fans of this tool. :-)

DI is probably the topic for the Backend, so we see soon after CDI patch 
(JEE standard + JBoss implementation) is applied and some refactoring 
proves the technology. The advantage is that the dependency injection 
changes can be applied gradually.





From mkublin at redhat.com  Tue Feb 12 14:59:19 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Tue, 12 Feb 2013 09:59:19 -0500 (EST)
Subject: [Engine-devel] Global transaction in ovirt-engine
In-Reply-To: <1479907628.1208064.1360679564073.JavaMail.root@redhat.com>
Message-ID: <214021586.734102.1360681159923.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Omer Frenkel" <ofrenkel at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, February 12, 2013 4:32:44 PM
> Subject: Re: [Engine-devel] Global transaction in ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, February 12, 2013 11:38:33 AM
> > Subject: [Engine-devel] Global transaction in ovirt-engine
> > 
> > The issue is a following (I think I had raised it once),
> > by default when any command is invoked in ovirt-engine a
> > transaction
> > is opened.
> > Now, lets take a look on complicated command which is performing a
> > lot of XML-RPC/HTTP calls and just simple update ,
> > such command is a main cause for the following problems:
> > 1. Long transactions, each call increase a time of transaction
> > 2. When transaction is opened a connection which is associated with
> > it also in used, so a number of available DB connections reduced
> > from
> > connection pool.
> > 3. A errors : transaction was cancelled and operation is failed on
> > engine side, but successes at host side.
> > 4. Performance - "try to keep transactions as short as possible".
> > 5. Performance - to many unneeded transactions
> > 6. Bug debugging - it is very difficult to understand why something
> > was committed and something not why transaction was reverted or
> > not,
> >    when we have a lot of nested transactions.
> > 
> > Now, what should be done by my opinion:
> > 1. Change default behaviour - by default not to open a transaction
> > (Today, transaction is opened and if we don't want a command should
> > be marked
> >    by NonTransactiveCommandAttribute) - it is simple
> > 2. The change described at 1 will require to rewrite and redesign
> > some flows - more difficult, but also can be done pretty fast.
> >    By the way this can be or even should be done at any case.
> > 3. All new commands should not be based on global transaction or
> > keep
> > in mind that global transaction can be disabled
> > 
> > Benefits,
> > 1. Better performance
> > 2. Cleaner code
> > 3. Less bugs
> > 4. Increased scale
> > 
> > Regards Michael
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> need to remember that transaction also gave us 10-min limit for
> command execution,
> not saying its good or bad, but disabling the transactions will allow
> commands to run forever,
> this 10 min limit actually, saved us few times when commands got
> stuck in all kind of locks etc..
> 
Not exactly, if transaction has expired the JBOSS transaction framework (Arjuna)
will not stop a running thread attached to such thread.
We can configure it in such way that a running thread will be cancelled, but for now
it is not. 


From lspevak at redhat.com  Tue Feb 12 16:13:45 2013
From: lspevak at redhat.com (Libor Spevak)
Date: Tue, 12 Feb 2013 17:13:45 +0100
Subject: [Engine-devel] REST API calls from the GUI
Message-ID: <511A6A39.2090706@redhat.com>

Hi,

I would like to ask, if there have been discussions about an option to 
call REST API services directly from the Frontend (GWT layer)? GWT 
compiles Java frontend-side to Javascript, calls to backend services are 
performed "transparently" by the framework using AJAX support. But, 
there is still a need to have a special set of data objects and the 
server-side logic can duplicate.

Java REST API SDK enables to build "thick" client. The calls are 
realized using e.g. Apache HttClient and supported libraries. I think 
the requirements of GWT can be a little bit different, but something 
overlaps.

I found several links about REST API support from GWT, so there is 
something for inspiration...

- http://www.spiffyui.org/
- http://www.zackgrossbart.com/hackito/gwt-rest/
- http://code.google.com/p/gwt-rest/
- http://restygwt.fusesource.org/

But, do you think it would be useful and what drawbacks can occur 
(authentication, authorization, response times, need to support larger 
set of services, painful refactoring, ...)?

Regards,
Libor



From kroberts at redhat.com  Tue Feb 12 16:30:03 2013
From: kroberts at redhat.com (Keith Robertson)
Date: Tue, 12 Feb 2013 11:30:03 -0500
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <511A6A39.2090706@redhat.com>
References: <511A6A39.2090706@redhat.com>
Message-ID: <511A6E0B.6040703@redhat.com>

Not sure if this is possible now but, I would like the front-end to 
expose an authenticated hook to the API so that plug-ins can call 
RESTful methods.  It would enable plug-in writers to do all sorts of 
interesting things in their plug-ins with the RESTful API.

Cheers,
Keith

On 02/12/2013 11:13 AM, Libor Spevak wrote:
> Hi,
>
> I would like to ask, if there have been discussions about an option to 
> call REST API services directly from the Frontend (GWT layer)? GWT 
> compiles Java frontend-side to Javascript, calls to backend services 
> are performed "transparently" by the framework using AJAX support. 
> But, there is still a need to have a special set of data objects and 
> the server-side logic can duplicate.
>
> Java REST API SDK enables to build "thick" client. The calls are 
> realized using e.g. Apache HttClient and supported libraries. I think 
> the requirements of GWT can be a little bit different, but something 
> overlaps.
>
> I found several links about REST API support from GWT, so there is 
> something for inspiration...
>
> - http://www.spiffyui.org/
> - http://www.zackgrossbart.com/hackito/gwt-rest/
> - http://code.google.com/p/gwt-rest/
> - http://restygwt.fusesource.org/
>
> But, do you think it would be useful and what drawbacks can occur 
> (authentication, authorization, response times, need to support larger 
> set of services, painful refactoring, ...)?
>
> Regards,
> Libor
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From Christopher.Morrissey at netapp.com  Tue Feb 12 22:53:52 2013
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Tue, 12 Feb 2013 22:53:52 +0000
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <511A6E0B.6040703@redhat.com>
References: <511A6A39.2090706@redhat.com> <511A6E0B.6040703@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B31CD7D597@SACEXCMBX04-PRD.hq.netapp.com>

The UI plugin framework already makes a session ID available for REST API calls. Oved's blog gives a good description with some example code.

http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html

-Chris

> -----Original Message-----
> From: engine-devel-bounces at ovirt.org [mailto:engine-devel-
> bounces at ovirt.org] On Behalf Of Keith Robertson
> Sent: Tuesday, February 12, 2013 11:30 AM
> To: Libor Spevak
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> Not sure if this is possible now but, I would like the front-end to expose an
> authenticated hook to the API so that plug-ins can call RESTful methods.  It
> would enable plug-in writers to do all sorts of interesting things in their plug-
> ins with the RESTful API.
> 
> Cheers,
> Keith
> 
> On 02/12/2013 11:13 AM, Libor Spevak wrote:
> > Hi,
> >
> > I would like to ask, if there have been discussions about an option to
> > call REST API services directly from the Frontend (GWT layer)? GWT
> > compiles Java frontend-side to Javascript, calls to backend services
> > are performed "transparently" by the framework using AJAX support.
> > But, there is still a need to have a special set of data objects and
> > the server-side logic can duplicate.
> >
> > Java REST API SDK enables to build "thick" client. The calls are
> > realized using e.g. Apache HttClient and supported libraries. I think
> > the requirements of GWT can be a little bit different, but something
> > overlaps.
> >
> > I found several links about REST API support from GWT, so there is
> > something for inspiration...
> >
> > - http://www.spiffyui.org/
> > - http://www.zackgrossbart.com/hackito/gwt-rest/
> > - http://code.google.com/p/gwt-rest/
> > - http://restygwt.fusesource.org/
> >
> > But, do you think it would be useful and what drawbacks can occur
> > (authentication, authorization, response times, need to support larger
> > set of services, painful refactoring, ...)?
> >
> > Regards,
> > Libor
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


From mpastern at redhat.com  Wed Feb 13 10:55:36 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 13 Feb 2013 12:55:36 +0200
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <511A6A39.2090706@redhat.com>
References: <511A6A39.2090706@redhat.com>
Message-ID: <511B7128.3030703@redhat.com>


Hi Libor,

This issue came across in one of the conversations i had with UX folks, but since we didn't end
up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect
place to start this discussion,

Intuitively REST is a way to go with GWT AJAX calls
---------------------------------------------------

pros
====

- api data objects can be reused by generating java classes (using jaxb) from the rest schema [1]
- no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on
- development against api is "easy" as api describes itself in RSDL [2]

cons
====

- implementing transport layer (HTTP) under GWT
- implementing own j2xml/json/yaml/... marshalling layer
- implementing own error handling mechanism
- implementing REST callback mechanism (in GWT)
- constant maintenance of the data objects generated from the api
- painful for Java developers

Java-SDK
--------

pros
====

- abstracts transport layer (leaving developer in standard Java api)
- typesafe code (no need to mess with XML bulks)
- has own data objects to work with
- abstracts authentication/authorization (kerberos/cookie/session/etc.)
- since SDK is auto-generated, it can be easily extended with required
  features to support UI (such as callback infrastructure for instance)

cons
====

- has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.)
- probably much more cons that we're not aware of and will have to figure out with POC


thoughts?

[1] http[s]://server[:port]/api?schema
[2] http[s]://server[:port]/api?rsdl

On 02/12/2013 06:13 PM, Libor Spevak wrote:
> Hi,
> 
> I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to
> Javascript, calls to backend services are performed "transparently" by the framework using AJAX support. But, there is still a need to have a special set of data objects
> and the server-side logic can duplicate.
> 
> Java REST API SDK enables to build "thick" client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a
> little bit different, but something overlaps.
> 
> I found several links about REST API support from GWT, so there is something for inspiration...
> 
> - http://www.spiffyui.org/
> - http://www.zackgrossbart.com/hackito/gwt-rest/
> - http://code.google.com/p/gwt-rest/
> - http://restygwt.fusesource.org/
> 
> But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful
> refactoring, ...)?
> 
> Regards,
> Libor
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From kroberts at redhat.com  Wed Feb 13 15:20:59 2013
From: kroberts at redhat.com (Keith Robertson)
Date: Wed, 13 Feb 2013 10:20:59 -0500 (EST)
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <D290AD8432118048947689BA3AE8A9B31CD7D597@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <785059306.1760597.1360768859860.JavaMail.root@redhat.com>

Good to know, thanks!

----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: "Keith Robertson" <kroberts at redhat.com>, "Libor Spevak" <lspevak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, February 12, 2013 5:53:52 PM
> Subject: RE: [Engine-devel] REST API calls from the GUI
> 
> The UI plugin framework already makes a session ID available for REST
> API calls. Oved's blog gives a good description with some example
> code.
> 
> http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html
> 
> -Chris
> 
> > -----Original Message-----
> > From: engine-devel-bounces at ovirt.org [mailto:engine-devel-
> > bounces at ovirt.org] On Behalf Of Keith Robertson
> > Sent: Tuesday, February 12, 2013 11:30 AM
> > To: Libor Spevak
> > Cc: engine-devel at ovirt.org
> > Subject: Re: [Engine-devel] REST API calls from the GUI
> > 
> > Not sure if this is possible now but, I would like the front-end to
> > expose an
> > authenticated hook to the API so that plug-ins can call RESTful
> > methods.  It
> > would enable plug-in writers to do all sorts of interesting things
> > in their plug-
> > ins with the RESTful API.
> > 
> > Cheers,
> > Keith
> > 
> > On 02/12/2013 11:13 AM, Libor Spevak wrote:
> > > Hi,
> > >
> > > I would like to ask, if there have been discussions about an
> > > option to
> > > call REST API services directly from the Frontend (GWT layer)?
> > > GWT
> > > compiles Java frontend-side to Javascript, calls to backend
> > > services
> > > are performed "transparently" by the framework using AJAX
> > > support.
> > > But, there is still a need to have a special set of data objects
> > > and
> > > the server-side logic can duplicate.
> > >
> > > Java REST API SDK enables to build "thick" client. The calls are
> > > realized using e.g. Apache HttClient and supported libraries. I
> > > think
> > > the requirements of GWT can be a little bit different, but
> > > something
> > > overlaps.
> > >
> > > I found several links about REST API support from GWT, so there
> > > is
> > > something for inspiration...
> > >
> > > - http://www.spiffyui.org/
> > > - http://www.zackgrossbart.com/hackito/gwt-rest/
> > > - http://code.google.com/p/gwt-rest/
> > > - http://restygwt.fusesource.org/
> > >
> > > But, do you think it would be useful and what drawbacks can occur
> > > (authentication, authorization, response times, need to support
> > > larger
> > > set of services, painful refactoring, ...)?
> > >
> > > Regards,
> > > Libor
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From kroberts at redhat.com  Wed Feb 13 18:32:15 2013
From: kroberts at redhat.com (Keith Robertson)
Date: Wed, 13 Feb 2013 13:32:15 -0500
Subject: [Engine-devel] RESTful Methods for Log Collection and DB Dumping
Message-ID: <511BDC2F.4070909@redhat.com>

I was wondering if there was any interest in the community to add 
RESTful methods for collecting the Engine log files (ie. 
/var/log/ovirt-engine/*), config files (ie. /etc/ovirt-engine), for 
other activities like dumping the DB.

I am asking this question because it seems like it would be useful to be 
able to collect all relevant configuration, logs, etc. from the Engine 
remotely.

Cheers,
Keith


From iheim at redhat.com  Wed Feb 13 21:19:11 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 13 Feb 2013 23:19:11 +0200
Subject: [Engine-devel] ovirt-engine: patches last updated more than 30 days
Message-ID: <511C034F.7040300@redhat.com>

below folks have the largest number of patches last updated more than 30 
days ago, please refresh/abandon/ask for reviews/etc.

  preferred_email           | count
  --------------------------+------
  rgolan at redhat.com         | 10
  lhornyak at redhat.com       | 5
  juan.hernandez at redhat.com | 5
  awels at redhat.com          | 4
  sesubram at redhat.com       | 4
  yzaslavs at redhat.com       | 4
  fsimonce at redhat.com       | 4
  vszocs at redhat.com         | 3
  gchaplik at redhat.com       | 3
  laravot at redhat.com        | 3

Thanks,
    Itamar


From dfediuck at redhat.com  Thu Feb 14 09:20:00 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 14 Feb 2013 04:20:00 -0500 (EST)
Subject: [Engine-devel] REST API calls from (was: REST API calls from
	the GUI)
In-Reply-To: <511B7128.3030703@redhat.com>
Message-ID: <82414620.2634605.1360833600485.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Libor Spevak" <lspevak at redhat.com>
> Cc: engine-devel at ovirt.org, arch at ovirt.org
> Sent: Wednesday, February 13, 2013 12:55:36 PM
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> 
> Hi Libor,
> 
> This issue came across in one of the conversations i had with UX
> folks, but since we didn't end
> up with any conclusion/road map (nor discussed it properly to hear
> other thoughts), this is a perfect
> place to start this discussion,
> 
> Intuitively REST is a way to go with GWT AJAX calls
> ---------------------------------------------------
> 
> pros
> ====
> 
> - api data objects can be reused by generating java classes (using
> jaxb) from the rest schema [1]
> - no backend logic will be duplicated as api abstracts the backend
> exposing RESTful collection/resources to operate on
> - development against api is "easy" as api describes itself in RSDL
> [2]
> 
> cons
> ====
> 
> - implementing transport layer (HTTP) under GWT
> - implementing own j2xml/json/yaml/... marshalling layer
> - implementing own error handling mechanism
> - implementing REST callback mechanism (in GWT)
> - constant maintenance of the data objects generated from the api
> - painful for Java developers
> 
> Java-SDK
> --------
> 
> pros
> ====
> 
> - abstracts transport layer (leaving developer in standard Java api)
> - typesafe code (no need to mess with XML bulks)
> - has own data objects to work with
> - abstracts authentication/authorization
> (kerberos/cookie/session/etc.)
> - since SDK is auto-generated, it can be easily extended with
> required
>   features to support UI (such as callback infrastructure for
>   instance)
> 
> cons
> ====
> 
> - has to be converted in to Javascript (not sure what the impacts are
> in terms of AJAX calls/etc.)
> - probably much more cons that we're not aware of and will have to
> figure out with POC
> 
> 
> thoughts?
> 
> [1] http[s]://server[:port]/api?schema
> [2] http[s]://server[:port]/api?rsdl
> 

Although started as a UI request, there are other needs who wish
to use API calls with a different transport. For example a backend
hook which gets a REST entry point it can use to fetch for additional
data, or perform actions. In this case I'd expect an internal connection
rather than creating additional connections.
How would you resolve it generically enough in this context?

> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> > Hi,
> > 
> > I would like to ask, if there have been discussions about an option
> > to call REST API services directly from the Frontend (GWT layer)?
> > GWT compiles Java frontend-side to
> > Javascript, calls to backend services are performed "transparently"
> > by the framework using AJAX support. But, there is still a need to
> > have a special set of data objects
> > and the server-side logic can duplicate.
> > 
> > Java REST API SDK enables to build "thick" client. The calls are
> > realized using e.g. Apache HttClient and supported libraries. I
> > think the requirements of GWT can be a
> > little bit different, but something overlaps.
> > 
> > I found several links about REST API support from GWT, so there is
> > something for inspiration...
> > 
> > - http://www.spiffyui.org/
> > - http://www.zackgrossbart.com/hackito/gwt-rest/
> > - http://code.google.com/p/gwt-rest/
> > - http://restygwt.fusesource.org/
> > 
> > But, do you think it would be useful and what drawbacks can occur
> > (authentication, authorization, response times, need to support
> > larger set of services, painful
> > refactoring, ...)?
> > 
> > Regards,
> > Libor
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From yzaslavs at redhat.com  Thu Feb 14 09:43:52 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Thu, 14 Feb 2013 04:43:52 -0500 (EST)
Subject: [Engine-devel] Global transaction in ovirt-engine
In-Reply-To: <214021586.734102.1360681159923.JavaMail.root@redhat.com>
Message-ID: <219069539.2150284.1360835032850.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, February 12, 2013 4:59:19 PM
> Subject: Re: [Engine-devel] Global transaction in ovirt-engine
> 
> 
> 
> ----- Original Message -----
> > From: "Omer Frenkel" <ofrenkel at redhat.com>
> > To: "Michael Kublin" <mkublin at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Tuesday, February 12, 2013 4:32:44 PM
> > Subject: Re: [Engine-devel] Global transaction in ovirt-engine
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Michael Kublin" <mkublin at redhat.com>
> > > To: "engine-devel" <engine-devel at ovirt.org>
> > > Sent: Tuesday, February 12, 2013 11:38:33 AM
> > > Subject: [Engine-devel] Global transaction in ovirt-engine
> > > 
> > > The issue is a following (I think I had raised it once),
> > > by default when any command is invoked in ovirt-engine a
> > > transaction
> > > is opened.
> > > Now, lets take a look on complicated command which is performing
> > > a
> > > lot of XML-RPC/HTTP calls and just simple update ,
> > > such command is a main cause for the following problems:
> > > 1. Long transactions, each call increase a time of transaction
> > > 2. When transaction is opened a connection which is associated
> > > with
> > > it also in used, so a number of available DB connections reduced
> > > from
> > > connection pool.
> > > 3. A errors : transaction was cancelled and operation is failed
> > > on
> > > engine side, but successes at host side.
> > > 4. Performance - "try to keep transactions as short as possible".
> > > 5. Performance - to many unneeded transactions
> > > 6. Bug debugging - it is very difficult to understand why
> > > something
> > > was committed and something not why transaction was reverted or
> > > not,
> > >    when we have a lot of nested transactions.
> > > 
> > > Now, what should be done by my opinion:
> > > 1. Change default behaviour - by default not to open a
> > > transaction
> > > (Today, transaction is opened and if we don't want a command
> > > should
> > > be marked
> > >    by NonTransactiveCommandAttribute) - it is simple
> > > 2. The change described at 1 will require to rewrite and redesign
> > > some flows - more difficult, but also can be done pretty fast.
> > >    By the way this can be or even should be done at any case.
> > > 3. All new commands should not be based on global transaction or
> > > keep
> > > in mind that global transaction can be disabled
> > > 
> > > Benefits,
> > > 1. Better performance
> > > 2. Cleaner code
> > > 3. Less bugs
> > > 4. Increased scale
> > > 
> > > Regards Michael
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > 
> > 
> > need to remember that transaction also gave us 10-min limit for
> > command execution,
> > not saying its good or bad, but disabling the transactions will
> > allow
> > commands to run forever,
> > this 10 min limit actually, saved us few times when commands got
> > stuck in all kind of locks etc..
> > 
> Not exactly, if transaction has expired the JBOSS transaction
> framework (Arjuna)
> will not stop a running thread attached to such thread.
> We can configure it in such way that a running thread will be
> cancelled, but for now
> it is not.

So current behavior is somewhat "unexpected" - it all determines if the thread will try to use the transaction after it was "reaped off" from him.
Right?
If this is the case - I think this is bad.
Do we have a real requirement for commands to end their execution phase at 10 minutes? 

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Thu Feb 14 10:02:09 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 14 Feb 2013 05:02:09 -0500 (EST)
Subject: [Engine-devel] Forcing PG 9.x for upstream
Message-ID: <500102084.1724628.1360836129554.JavaMail.root@redhat.com>

Hi

We came to the problem when some developers took latest and failed to create the PG DB.
The problem was that those developers used PG 8.4.x with upstream code.
Currently, we can support that and fix the upstream code to run both on 8.4.x and 9.x 
the question is if we should ?

I will be happy to hear your opinion on that.

thanks

Eli Meiska


From emesika at redhat.com  Thu Feb 14 10:32:37 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 14 Feb 2013 05:32:37 -0500 (EST)
Subject: [Engine-devel] [RFE] external Task Injection Support requirements
	(for 3.3)
In-Reply-To: <1095744085.1733574.1360837947939.JavaMail.root@redhat.com>
Message-ID: <1541023180.1733594.1360837957072.JavaMail.root@redhat.com>

Hi
 Please review an initial draft for adding support for External Tasks injection requirements:
   http://www.ovirt.org/Features/ExternalTasks
 Please comment on the Talk page
   http://www.ovirt.org/Talk:ExternalTasks
Thanks


From ofrenkel at redhat.com  Thu Feb 14 11:23:20 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Thu, 14 Feb 2013 06:23:20 -0500 (EST)
Subject: [Engine-devel] Forcing PG 9.x for upstream
In-Reply-To: <500102084.1724628.1360836129554.JavaMail.root@redhat.com>
Message-ID: <303426537.2668570.1360841000671.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, February 14, 2013 12:02:09 PM
> Subject: [Engine-devel] Forcing PG 9.x for upstream
> 
> Hi
> 
> We came to the problem when some developers took latest and failed to
> create the PG DB.
> The problem was that those developers used PG 8.4.x with upstream
> code.
> Currently, we can support that and fix the upstream code to run both
> on 8.4.x and 9.x
> the question is if we should ?
> 

if its not too hard then yes, it will save aome trouble to people
also this 'breaks' what documented in the ovirt Prerequisites page:
http://www.ovirt.org/Building_oVirt_engine#Prerequisites

> I will be happy to hear your opinion on that.
> 
> thanks
> 
> Eli Meiska
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Thu Feb 14 11:39:45 2013
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 14 Feb 2013 13:39:45 +0200
Subject: [Engine-devel] Forcing PG 9.x for upstream
In-Reply-To: <303426537.2668570.1360841000671.JavaMail.root@redhat.com>
References: <303426537.2668570.1360841000671.JavaMail.root@redhat.com>
Message-ID: <511CCD01.1060606@redhat.com>

On 14/02/2013 13:23, Omer Frenkel wrote:
>
>
> ----- Original Message -----
>> From: "Eli Mesika" <emesika at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Thursday, February 14, 2013 12:02:09 PM
>> Subject: [Engine-devel] Forcing PG 9.x for upstream
>>
>> Hi
>>
>> We came to the problem when some developers took latest and failed to
>> create the PG DB.
>> The problem was that those developers used PG 8.4.x with upstream
>> code.
>> Currently, we can support that and fix the upstream code to run both
>> on 8.4.x and 9.x
>> the question is if we should ?
>>
>
> if its not too hard then yes, it will save aome trouble to people
> also this 'breaks' what documented in the ovirt Prerequisites page:
> http://www.ovirt.org/Building_oVirt_engine#Prerequisites
>
>> I will be happy to hear your opinion on that.
>>
>> thanks

we plan to release formal .el6 ovirt packages in the project, which many 
people use, so yes, need to support both.


>>
>> Eli Meiska
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From ewoud+ovirt at kohlvanwijngaarden.nl  Thu Feb 14 11:47:46 2013
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Thu, 14 Feb 2013 12:47:46 +0100
Subject: [Engine-devel] Forcing PG 9.x for upstream
In-Reply-To: <500102084.1724628.1360836129554.JavaMail.root@redhat.com>
References: <500102084.1724628.1360836129554.JavaMail.root@redhat.com>
Message-ID: <20130214114746.GU4544@bogey.xentower.nl>

On Thu, Feb 14, 2013 at 05:02:09AM -0500, Eli Mesika wrote:
> We came to the problem when some developers took latest and failed to create the PG DB.
> The problem was that those developers used PG 8.4.x with upstream code.
> Currently, we can support that and fix the upstream code to run both on 8.4.x and 9.x
> the question is if we should ?

Currently EL6 ships with 8.4 so forcing 9.x would make supporting EL6
much harder.


From mkublin at redhat.com  Thu Feb 14 13:28:46 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Thu, 14 Feb 2013 08:28:46 -0500 (EST)
Subject: [Engine-devel] Global transaction in ovirt-engine
In-Reply-To: <219069539.2150284.1360835032850.JavaMail.root@redhat.com>
Message-ID: <949406013.1683919.1360848526101.JavaMail.root@redhat.com>


> > > 
> > > ----- Original Message -----
> > > > From: "Michael Kublin" <mkublin at redhat.com>
> > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > Sent: Tuesday, February 12, 2013 11:38:33 AM
> > > > Subject: [Engine-devel] Global transaction in ovirt-engine
> > > > 
> > > > The issue is a following (I think I had raised it once),
> > > > by default when any command is invoked in ovirt-engine a
> > > > transaction
> > > > is opened.
> > > > Now, lets take a look on complicated command which is
> > > > performing
> > > > a
> > > > lot of XML-RPC/HTTP calls and just simple update ,
> > > > such command is a main cause for the following problems:
> > > > 1. Long transactions, each call increase a time of transaction
> > > > 2. When transaction is opened a connection which is associated
> > > > with
> > > > it also in used, so a number of available DB connections
> > > > reduced
> > > > from
> > > > connection pool.
> > > > 3. A errors : transaction was cancelled and operation is failed
> > > > on
> > > > engine side, but successes at host side.
> > > > 4. Performance - "try to keep transactions as short as
> > > > possible".
> > > > 5. Performance - to many unneeded transactions
> > > > 6. Bug debugging - it is very difficult to understand why
> > > > something
> > > > was committed and something not why transaction was reverted or
> > > > not,
> > > >    when we have a lot of nested transactions.
> > > > 
> > > > Now, what should be done by my opinion:
> > > > 1. Change default behaviour - by default not to open a
> > > > transaction
> > > > (Today, transaction is opened and if we don't want a command
> > > > should
> > > > be marked
> > > >    by NonTransactiveCommandAttribute) - it is simple
> > > > 2. The change described at 1 will require to rewrite and
> > > > redesign
> > > > some flows - more difficult, but also can be done pretty fast.
> > > >    By the way this can be or even should be done at any case.
> > > > 3. All new commands should not be based on global transaction
> > > > or
> > > > keep
> > > > in mind that global transaction can be disabled
> > > > 
> > > > Benefits,
> > > > 1. Better performance
> > > > 2. Cleaner code
> > > > 3. Less bugs
> > > > 4. Increased scale
> > > > 
> > > > Regards Michael
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > > 
> > > 
> > > need to remember that transaction also gave us 10-min limit for
> > > command execution,
> > > not saying its good or bad, but disabling the transactions will
> > > allow
> > > commands to run forever,
> > > this 10 min limit actually, saved us few times when commands got
> > > stuck in all kind of locks etc..
> > > 
> > Not exactly, if transaction has expired the JBOSS transaction
> > framework (Arjuna)
> > will not stop a running thread attached to such thread.
> > We can configure it in such way that a running thread will be
> > cancelled, but for now
> > it is not.
> 
> So current behavior is somewhat "unexpected" - it all determines if
> the thread will try to use the transaction after it was "reaped off"
> from him.
> Right?
> If this is the case - I think this is bad.
> Do we have a real requirement for commands to end their execution
> phase at 10 minutes?
> 
Propose patch for removing global transaction at endAction of CommandBase (this is 
a first step)
http://gerrit.ovirt.org/#/c/12010/ 


From amureini at redhat.com  Thu Feb 14 16:34:53 2013
From: amureini at redhat.com (Allon Mureinik)
Date: Thu, 14 Feb 2013 11:34:53 -0500 (EST)
Subject: [Engine-devel] Forcing PG 9.x for upstream
In-Reply-To: <511CCD01.1060606@redhat.com>
Message-ID: <255460525.3021389.1360859693041.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, February 14, 2013 1:39:45 PM
> Subject: Re: [Engine-devel] Forcing PG 9.x for upstream
> 
> On 14/02/2013 13:23, Omer Frenkel wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Eli Mesika" <emesika at redhat.com>
> >> To: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Thursday, February 14, 2013 12:02:09 PM
> >> Subject: [Engine-devel] Forcing PG 9.x for upstream
> >>
> >> Hi
> >>
> >> We came to the problem when some developers took latest and failed
> >> to
> >> create the PG DB.
> >> The problem was that those developers used PG 8.4.x with upstream
> >> code.
> >> Currently, we can support that and fix the upstream code to run
> >> both
> >> on 8.4.x and 9.x
> >> the question is if we should ?
> >>
> >
> > if its not too hard then yes, it will save aome trouble to people
> > also this 'breaks' what documented in the ovirt Prerequisites page:
> > http://www.ovirt.org/Building_oVirt_engine#Prerequisites
> >
> >> I will be happy to hear your opinion on that.
> >>
> >> thanks
> 
> we plan to release formal .el6 ovirt packages in the project, which
> many
> people use, so yes, need to support both.
Suggested solution:
http://gerrit.ovirt.org/#/c/12076

> 
> 
> >>
> >> Eli Meiska
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Thu Feb 14 16:42:04 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Thu, 14 Feb 2013 11:42:04 -0500 (EST)
Subject: [Engine-devel] Forcing PG 9.x for upstream
In-Reply-To: <255460525.3021389.1360859693041.JavaMail.root@redhat.com>
Message-ID: <738560648.2433257.1360860124744.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Allon Mureinik" <amureini at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Thursday, February 14, 2013 6:34:53 PM
> Subject: Re: [Engine-devel] Forcing PG 9.x for upstream
> 
> 
> 
> ----- Original Message -----
> > From: "Itamar Heim" <iheim at redhat.com>
> > To: "Omer Frenkel" <ofrenkel at redhat.com>
> > Cc: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Thursday, February 14, 2013 1:39:45 PM
> > Subject: Re: [Engine-devel] Forcing PG 9.x for upstream
> > 
> > On 14/02/2013 13:23, Omer Frenkel wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Eli Mesika" <emesika at redhat.com>
> > >> To: "engine-devel" <engine-devel at ovirt.org>
> > >> Sent: Thursday, February 14, 2013 12:02:09 PM
> > >> Subject: [Engine-devel] Forcing PG 9.x for upstream
> > >>
> > >> Hi
> > >>
> > >> We came to the problem when some developers took latest and
> > >> failed
> > >> to
> > >> create the PG DB.
> > >> The problem was that those developers used PG 8.4.x with
> > >> upstream
> > >> code.
> > >> Currently, we can support that and fix the upstream code to run
> > >> both
> > >> on 8.4.x and 9.x
> > >> the question is if we should ?
> > >>
> > >
> > > if its not too hard then yes, it will save aome trouble to people
> > > also this 'breaks' what documented in the ovirt Prerequisites
> > > page:
> > > http://www.ovirt.org/Building_oVirt_engine#Prerequisites
> > >
> > >> I will be happy to hear your opinion on that.
> > >>
> > >> thanks
> > 
> > we plan to release formal .el6 ovirt packages in the project, which
> > many
> > people use, so yes, need to support both.
> Suggested solution:
> http://gerrit.ovirt.org/#/c/12076

Approved, 
Allon - Many thanks for your help
> 
> > 
> > 
> > >>
> > >> Eli Meiska
> > >> _______________________________________________
> > >> Engine-devel mailing list
> > >> Engine-devel at ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From eedri at redhat.com  Thu Feb 14 19:18:19 2013
From: eedri at redhat.com (Eyal Edri)
Date: Thu, 14 Feb 2013 14:18:19 -0500 (EST)
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build #
 3528 - Still Unstable!
In-Reply-To: <1199810791.6962.1360869197168.JavaMail.jenkins@jenkins.ovirt.org>
Message-ID: <547116084.3115237.1360869499599.JavaMail.root@redhat.com>

2 new NORMAL priority bugs were introduced after this commit:

[tnisan] core: Rename storage_domains entity to StorageDomain
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git&a=commit&h=8c5e31a30b0579db46b5f29fde253ad361e24f7e

http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3524/findbugsResult/NORMAL/?

please check,

Eyal Edri.


----- Original Message -----
> From: "Jenkins oVirt Server" <jenkins at ovirt.org>
> To: eedri at redhat.com, engine-patches at ovirt.org, oliel at redhat.com, yzaslavs at redhat.com, dcaro at redhat.com
> Sent: Thursday, February 14, 2013 9:13:17 PM
> Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3528 - Still Unstable!
> 
> Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/
> Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3528/
> Build Number: 3528
> Build Status:  Still Unstable
> Triggered By: Started by upstream project "ovirt_engine" build number
> 4,315
> 
> -------------------------------------
> Changes Since Last Success:
> -------------------------------------
> Changes for Build #3524
> [tnisan] core: Rename storage_domains entity to StorageDomain
> 
> 
> Changes for Build #3525
> [gerrit2] tools: Remove some notifier dependencies
> 
> [gerrit2] webadmin: Refactored base Model class probihition reason
> option
> 
> 
> Changes for Build #3526
> [amureini] core: Fix db upgrade in PostgreSQL 8.x
> 
> 
> Changes for Build #3527
> 
> Changes for Build #3528
> 
> 
> 
> -----------------
> Failed Tests:
> -----------------
> No tests ran.
> 
> ------------------
> Build Log:
> ------------------
> [...truncated 1709 lines...]
> [INFO] javac option: -proc:only
> [INFO] javac option: -d
> [INFO] javac option:
> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.3.0-SNAPSHOT/WEB-INF/classes
> [INFO] javac option: -s
> [INFO] javac option:
> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/generated-sources/annotations
> [INFO] diagnostic warning: Supported source version 'RELEASE_6' from
> annotation processor
> 'com.gwtplatform.dispatch.annotation.processor.GenDtoProcessor' less
> than -source '1.7'
> [INFO] diagnostic warning: Supported source version 'RELEASE_6' from
> annotation processor
> 'com.gwtplatform.dispatch.annotation.processor.GenEventProcessor'
> less than -source '1.7'
> [INFO] diagnostic Note:
> com.gwtplatform.dispatch.annotation.processor.GenEventProcessor
> started.
> [INFO] diagnostic Note: Searching for @GenEvent annotations.
> [INFO] diagnostic Note: Found
> org.ovirt.engine.ui.userportal.section.main.presenter.SearchableModelActivation.
> [INFO] diagnostic Note: Generating
> 'org.ovirt.engine.ui.userportal.section.main.presenter.SearchableModelActivationEvent'
> from 'SearchableModelActivation'.
> [INFO] diagnostic Note: Found
> org.ovirt.engine.ui.userportal.section.main.presenter.tab.extended.SideTabExtendedTemplatePresenter.ExtendedTemplateSelectionChange.
> [INFO] diagnostic Note: Generating
> 'org.ovirt.engine.ui.userportal.section.main.presenter.tab.extended.ExtendedTemplateSelectionChangeEvent'
> from 'ExtendedTemplateSelectionChange'.
> [INFO] diagnostic Note: Found
> org.ovirt.engine.ui.userportal.section.main.presenter.tab.extended.SideTabExtendedVirtualMachinePresenter.ExtendedVirtualMachineSelectionChange.
> [INFO] diagnostic Note: Generating
> 'org.ovirt.engine.ui.userportal.section.main.presenter.tab.extended.ExtendedVirtualMachineSelectionChangeEvent'
> from 'ExtendedVirtualMachineSelectionChange'.
> [INFO] diagnostic Note: Found
> org.ovirt.engine.ui.userportal.section.main.presenter.popup.console.ConsolePopupPresenterWidget.ConsoleModelChanged.
> [INFO] diagnostic Note: Generating
> 'org.ovirt.engine.ui.userportal.section.main.presenter.popup.console.ConsoleModelChangedEvent'
> from 'ConsoleModelChanged'.
> [INFO] diagnostic Note: Found
> org.ovirt.engine.ui.userportal.uicommon.model.UserPortalModelInit.
> [INFO] diagnostic Note: Generating
> 'org.ovirt.engine.ui.userportal.uicommon.model.UserPortalModelInitEvent'
> from 'UserPortalModelInit'.
> [INFO] diagnostic Note: Found
> org.ovirt.engine.ui.userportal.uicommon.model.vm.VmMonitorValueChange.
> [INFO] diagnostic Note: Generating
> 'org.ovirt.engine.ui.userportal.uicommon.model.vm.VmMonitorValueChangeEvent'
> from 'VmMonitorValueChange'.
> [INFO] diagnostic Note:
> com.gwtplatform.dispatch.annotation.processor.GenEventProcessor
> finished.
> [INFO] diagnostic warning: Supported source version 'RELEASE_6' from
> annotation processor
> 'com.gwtplatform.dispatch.annotation.processor.GenDispatchProcessor'
> less than -source '1.7'
> [INFO] diagnostic Note:
> com.gwtplatform.dispatch.annotation.processor.GenEventProcessor
> started.
> [INFO] diagnostic Note: Searching for @GenEvent annotations.
> [INFO] diagnostic Note:
> com.gwtplatform.dispatch.annotation.processor.GenEventProcessor
> finished.
> [INFO]
> [INFO] --- build-helper-maven-plugin:1.5:add-source (add-apt-sources)
> @ userportal ---
> [INFO] Source directory:
> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/generated-sources/annotations
> added.
> [INFO] Source directory:
> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/generated-sources/gwt
> added.
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @
> userportal ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 1 resource to
> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/generated-sources/gwt
> [INFO] Copying 193 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
> userportal ---
> [INFO] Compiling 6 source files to
> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.3.0-SNAPSHOT/WEB-INF/classes
> [INFO]
> [INFO] --- maven-checkstyle-plugin:2.6:check (default) @ userportal
> ---
> [INFO] Starting audit...
> Audit done.
> 
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:testResources
> (default-testResources) @ userportal ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:testCompile
> (default-testCompile) @ userportal ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.7.2:test (default-test) @
> userportal ---
> [INFO] Tests are skipped.
> [INFO]
> [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ userportal ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [userportal] in
> [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.3.0-SNAPSHOT]
> [INFO] Processing war project
> [INFO] Copying webapp resources
> [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/src/main/webapp]
> [INFO] Webapp assembled in [33 msecs]
> [INFO] Building war:
> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.3.0-SNAPSHOT.war
> [INFO] WEB-INF/web.xml already added, skipping
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> userportal ---
> [INFO] Installing
> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.3.0-SNAPSHOT.war
> to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/userportal/3.3.0-SNAPSHOT/userportal-3.3.0-SNAPSHOT.war
> [INFO] Installing
> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/pom.xml
> to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/userportal/3.3.0-SNAPSHOT/userportal-3.3.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @
> userportal ---
> [INFO] Fork Value is true
>      [java] Warnings generated: 14
> [INFO] Done FindBugs Analysis....
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building oVirt WARs 3.3.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is
> missing, no dependency information available
> [WARNING] Failed to retrieve plugin descriptor for
> org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin
> org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies
> could not be resolved: Failed to read artifact descriptor for
> org.eclipse.m2e:lifecycle-mapping:jar:1.0.0
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> wars ---
> [INFO] Installing
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/pom.xml to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/wars/3.3.0-SNAPSHOT/wars-3.3.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @ wars
> ---
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building oVirt Web Application Module 3.3.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is
> missing, no dependency information available
> [WARNING] Failed to retrieve plugin descriptor for
> org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin
> org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies
> could not be resolved: Failed to read artifact descriptor for
> org.eclipse.m2e:lifecycle-mapping:jar:1.0.0
> [INFO]
> [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources)
> @ rmw-war ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO] skip non existing resourceDirectory
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
> rmw-war ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-resources-plugin:2.4.3:testResources
> (default-testResources) @ rmw-war ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:testCompile
> (default-testCompile) @ rmw-war ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.7.2:test (default-test) @ rmw-war
> ---
> [INFO] Tests are skipped.
> [INFO]
> [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ rmw-war ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [rmw-war] in
> [/ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/rmw-war-3.3.0-SNAPSHOT]
> [INFO] Processing war project
> [INFO] Copying webapp resources
> [/ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/src/main/webapp]
> [INFO] Webapp assembled in [6 msecs]
> [INFO] Building war:
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/rmw-war-3.3.0-SNAPSHOT.war
> [INFO] WEB-INF/web.xml already added, skipping
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> rmw-war ---
> [INFO] Installing
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/rmw-war-3.3.0-SNAPSHOT.war
> to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/rmw-war/3.3.0-SNAPSHOT/rmw-war-3.3.0-SNAPSHOT.war
> [INFO] Installing
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/pom.xml to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/rmw-war/3.3.0-SNAPSHOT/rmw-war-3.3.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @
> rmw-war ---
> [INFO] Fork Value is true
> [INFO] Done FindBugs Analysis....
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is
> missing, no dependency information available
> [WARNING] Failed to retrieve plugin descriptor for
> org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin
> org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies
> could not be resolved: Failed to read artifact descriptor for
> org.eclipse.m2e:lifecycle-mapping:jar:1.0.0
> [INFO]
> [INFO] --- maven-ear-plugin:2.5:generate-application-xml
> (default-generate-application-xml) @ engine-server-ear ---
> [INFO] Generating application.xml
> [INFO]
> [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources)
> @ engine-server-ear ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /ephemeral0/ovirt_engine_find_bugs/ear/src/main/java
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-ear-plugin:2.5:ear (default-ear) @ engine-server-ear
> ---
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT]
> to[lib/engine-common.jar]
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT]
> to[lib/engine-compat.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT]
> to[lib/engine-dal.jar]
> [INFO] Copying
> artifact[war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT]
> to[root.war] (unpacked)
> [INFO] Copying
> artifact[war:org.ovirt.engine.ui:rmw-war:3.3.0-SNAPSHOT]
> to[ovirtengineweb.war] (unpacked)
> [INFO] Copying
> artifact[war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT]
> to[restapi.war] (unpacked)
> [INFO] Copying
> artifact[war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT]
> to[userportal.war] (unpacked)
> [INFO] Copying
> artifact[war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT]
> to[webadmin.war] (unpacked)
> [INFO] Copying
> artifact[ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT]
> to[engine-scheduler.jar] (unpacked)
> [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT]
> to[engine-bll.jar] (unpacked)
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT]
> to[lib/searchbackend-3.3.0-SNAPSHOT.jar]
> [INFO] Copy ear sources to
> /ephemeral0/ovirt_engine_find_bugs/ear/target/engine
> [WARNING] resourcesDir is deprecated. Please use the
> earSourceDirectory property instead.
> [INFO] Copy ear resources to
> /ephemeral0/ovirt_engine_find_bugs/ear/target/engine
> [INFO] Including custom manifest
> file[/ephemeral0/ovirt_engine_find_bugs/ear/target/engine/META-INF/MANIFEST.MF]
> [INFO] Building jar:
> /ephemeral0/ovirt_engine_find_bugs/ear/target/engine.ear
> [INFO]
> [INFO] --- maven-dependency-plugin:2.1:copy (copy-quartz-jar) @
> engine-server-ear ---
> [INFO] Configured Artifact: org.quartz-scheduler:quartz:2.1.2:jar
> [INFO] Copying quartz-2.1.2.jar to
> /ephemeral0/ovirt_engine_find_bugs/ear/target/quartz/quartz-2.1.2.jar
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> engine-server-ear ---
> [INFO] Installing
> /ephemeral0/ovirt_engine_find_bugs/ear/target/engine.ear to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear
> [INFO] Installing /ephemeral0/ovirt_engine_find_bugs/ear/pom.xml to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @
> engine-server-ear ---
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] ovirt-root ........................................ SUCCESS
> [5.387s]
> [INFO] oVirt Build Tools root ............................ SUCCESS
> [0.102s]
> [INFO] oVirt checkstyle .................................. SUCCESS
> [2.684s]
> [INFO] oVirt Checkstyle Checks ........................... SUCCESS
> [28.048s]
> [INFO] oVirt Modules - backend ........................... SUCCESS
> [0.035s]
> [INFO] oVirt Manager ..................................... SUCCESS
> [0.030s]
> [INFO] oVirt DB Scripts .................................. SUCCESS
> [0.363s]
> [INFO] oVirt Modules - manager ........................... SUCCESS
> [1.466s]
> [INFO] CSharp Compatibility .............................. SUCCESS
> [58.669s]
> [INFO] Common Code ....................................... SUCCESS
> [2:23.974s]
> [INFO] Common utilities .................................. SUCCESS
> [1:22.958s]
> [INFO] Data Access Layer ................................. SUCCESS
> [1:27.539s]
> [INFO] engine beans ...................................... SUCCESS
> [0.249s]
> [INFO] engine scheduler bean ............................. SUCCESS
> [28.657s]
> [INFO] Vds broker ........................................ SUCCESS
> [1:47.138s]
> [INFO] Search Backend .................................... SUCCESS
> [1:03.541s]
> [INFO] Backend Logic @Service bean ....................... SUCCESS
> [2:43.880s]
> [INFO] oVirt RESTful API Backend Integration ............. SUCCESS
> [0.130s]
> [INFO] oVirt RESTful API interface ....................... SUCCESS
> [0.111s]
> [INFO] oVirt Engine API Definition ....................... SUCCESS
> [53.819s]
> [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
> [0.150s]
> [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
> [43.462s]
> [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
> [49.511s]
> [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
>  SUCCESS [1:17.571s]
> [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
> [1.082s]
> [INFO] oVirt Engine Web Root ............................. SUCCESS
> [23.802s]
> [INFO] oVirt Engine Tools ................................ SUCCESS
> [54.913s]
> [INFO] oVirt Modules :: Frontend ......................... SUCCESS
> [0.038s]
> [INFO] oVirt Modules :: Webadmin ......................... SUCCESS
> [0.024s]
> [INFO] oVirt Modules - ui ................................ SUCCESS
> [0.033s]
> [INFO] Extensions for GWT ................................ SUCCESS
> [24.110s]
> [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
> [26.010s]
> [INFO] Frontend for GWT UI Projects ...................... SUCCESS
> [25.023s]
> [INFO] UICommonWeb ....................................... SUCCESS
> [1:58.941s]
> [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
> [1:11.318s]
> [INFO] WebAdmin .......................................... SUCCESS
> [1:26.032s]
> [INFO] UserPortal ........................................ SUCCESS
> [44.271s]
> [INFO] oVirt WARs ........................................ SUCCESS
> [0.020s]
> [INFO] oVirt Web Application Module ...................... SUCCESS
> [20.464s]
> [INFO] oVirt Server EAR .................................. SUCCESS
> [6.298s]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 25:06.197s
> [INFO] Finished at: Thu Feb 14 14:13:27 EST 2013
> [INFO] Final Memory: 121M/623M
> [INFO]
> ------------------------------------------------------------------------
> [FINDBUGS] Collecting findbugs analysis files...
> [FINDBUGS] Finding all files that match the pattern
> **/findbugsXml.xml
> [FINDBUGS] Parsing 24 files in
> /home/jenkins/workspace/ovirt_engine_find_bugs
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/scheduler/target/findbugsXml.xml
> of module  with 0 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/bll/target/findbugsXml.xml
> of module  with 260 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/common/target/findbugsXml.xml
> of module  with 250 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/compat/target/findbugsXml.xml
> of module  with 31 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/dal/target/findbugsXml.xml
> of module  with 5 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/engineencryptutils/target/findbugsXml.xml
> of module  with 4 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml
> of module  with 15 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml
> of module  with 1 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml
> of module  with 28 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/types/target/findbugsXml.xml
> of module  with 13 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/root/target/findbugsXml.xml
> of module  with 1 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/searchbackend/target/findbugsXml.xml
> of module  with 12 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/utils/target/findbugsXml.xml
> of module  with 74 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/vdsbroker/target/findbugsXml.xml
> of module  with 240 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/target/findbugsXml.xml
> of module  with 31 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/build-tools-root/ovirt-checkstyle-extension/target/findbugsXml.xml
> of module  with 1 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/findbugsXml.xml
> of module  with 0 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/frontend/target/findbugsXml.xml
> of module  with 38 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml
> of module  with 85 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml
> of module  with 2 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommonweb/target/findbugsXml.xml
> of module  with 653 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicompat/target/findbugsXml.xml
> of module  with 52 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/findbugsXml.xml
> of module  with 14 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/findbugsXml.xml
> of module  with 69 warnings.
> [FINDBUGS] Computing warning deltas based on reference build #3523
> Build step 'Publish FindBugs analysis results' changed build result
> to UNSTABLE
> IRC notifier plugin: Sending notification to: #ovirt-jenkins
> Email was triggered for: Unstable
> Sending email for trigger: Unstable
> 


From thomas at parker.iz34.com  Fri Feb 15 07:20:06 2013
From: thomas at parker.iz34.com (thomas at parker.iz34.com)
Date: Fri, 15 Feb 2013 08:20:06 +0100
Subject: [Engine-devel] Change in ovirt-engine[master]: webadmin: Fix
	replicate bricks	confirmation not closing
In-Reply-To: <201302150716.r1F7GciB030881@gerrit.ovirt.org>
References: <201302150716.r1F7GciB030881@gerrit.ovirt.org>
Message-ID: <201302150716.r1F7GciB030881@gerrit.ovirt.org>

Shireesh Anjal has submitted this change and it was merged.

Change subject: webadmin: Fix replicate bricks confirmation not closing
.....................................................................


webadmin: Fix replicate bricks confirmation not closing

When adding bricks to a replicate volume, if the bricks of a
sub-volume resides in the same machine a confirmation will be
shown. The confirmation dialog was not getting closed after clicking yes,
this is fixed now.

Change-Id: Ib4d7e76e5e82329bac4cb0368f45caccacc2b62d
Signed-off-by: Kanagaraj M <kmayilsa at redhat.com>
---
M frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/gluster/VolumeBrickListModel.java
1 file changed, 3 insertions(+), 1 deletion(-)

Approvals:
  Shireesh Anjal: Looks good to me, approved
  Kanagaraj M: Verified


--
To view, visit http://gerrit.ovirt.org/11948
To unsubscribe, visit http://gerrit.ovirt.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Ib4d7e76e5e82329bac4cb0368f45caccacc2b62d
Gerrit-PatchSet: 2
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Kanagaraj M <kmayilsa at redhat.com>
Gerrit-Reviewer: Gilad Chaplik <gchaplik at redhat.com>
Gerrit-Reviewer: Kanagaraj M <kmayilsa at redhat.com>
Gerrit-Reviewer: Shireesh Anjal <sanjal at redhat.com>
_______________________________________________
Engine-commits mailing list
Engine-commits at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-commits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: originalBody.txt
Type: application/octet-stream
Size: 1502 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130215/b87fb304/attachment.obj>

From sbonazzo at redhat.com  Fri Feb 15 12:33:22 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Fri, 15 Feb 2013 13:33:22 +0100
Subject: [Engine-devel] oVirt on Fedora 17
Message-ID: <511E2B12.2020409@redhat.com>

Hi,
I'm testing the upgrade path from Fedora 17 with oVirt 3.1 to Fedora 18
with oVirt 3.2 now that 3.2 is released.
I've seen that ovirt-stable is not available anymore on Fedora 17:
http://resources.ovirt.org/releases/stable/rpm/Fedora/ shows only Fedora
18 and Fedora 19.

I can fix the repository url on my system pointing to
http://resources.ovirt.org/releases/3.1/rpm/Fedora/
but since Fedora 17 is still available I think that the 3.1 / F17 repo
should be still available on ovirt.org.

-- 
Sandro


From vszocs at redhat.com  Fri Feb 15 18:11:20 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 15 Feb 2013 13:11:20 -0500 (EST)
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <D290AD8432118048947689BA3AE8A9B31CD7D597@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <526301840.2128583.1360951880429.JavaMail.root@redhat.com>

Hi Libor,

> I would like to ask, if there have been discussions about an option to
> call REST API services directly from the Frontend (GWT layer)? GWT
> compiles Java frontend-side to Javascript, calls to backend services
> are performed "transparently" by the framework using AJAX support.
> But, there is still a need to have a special set of data objects and
> the server-side logic can duplicate.

Indeed, for both WebAdmin and UserPortal, we're planning to move away from GWT RPC (a.k.a Generic API) and use Engine REST API and promote loose coupling between client and server.

As Chris mentioned, for WebAdmin UI plugins, there's already support for calling Engine REST API - session ID is obtained upon WebAdmin UI login and passed to all UI plugins. It's up to plugin authors to decide if the plugin itself (JavaScript) will communicate via REST API, or if the plugin passes the session ID to some other server so that the other server does REST API communication.

> Java REST API SDK enables to build "thick" client. The calls are
> realized using e.g. Apache HttClient and supported libraries. I think
> the requirements of GWT can be a little bit different, but something
> overlaps.

Well, we can't really use Java REST API SDK directly due to restrictions imposed by GWT on client-side code, e.g. HttClient uses sockets which are (obviously) not supported in JavaScript and therefore related classes are rejected by GWT compiler.

What we're planning to do is to map REST API XML responses to generated "REST API Types" (based on api.xsd schema) and vice versa. This could be a bit of challenge, as most frameworks for GWT REST API support use JSON representation in favor of XML.

Vojtech


----- Original Message -----
From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
To: "Keith Robertson" <kroberts at redhat.com>, "Libor Spevak" <lspevak at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Tuesday, February 12, 2013 11:53:52 PM
Subject: Re: [Engine-devel] REST API calls from the GUI

The UI plugin framework already makes a session ID available for REST API calls. Oved's blog gives a good description with some example code.

http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html

-Chris

> -----Original Message-----
> From: engine-devel-bounces at ovirt.org [mailto:engine-devel-
> bounces at ovirt.org] On Behalf Of Keith Robertson
> Sent: Tuesday, February 12, 2013 11:30 AM
> To: Libor Spevak
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> Not sure if this is possible now but, I would like the front-end to expose an
> authenticated hook to the API so that plug-ins can call RESTful methods.  It
> would enable plug-in writers to do all sorts of interesting things in their plug-
> ins with the RESTful API.
> 
> Cheers,
> Keith
> 
> On 02/12/2013 11:13 AM, Libor Spevak wrote:
> > Hi,
> >
> > I would like to ask, if there have been discussions about an option to
> > call REST API services directly from the Frontend (GWT layer)? GWT
> > compiles Java frontend-side to Javascript, calls to backend services
> > are performed "transparently" by the framework using AJAX support.
> > But, there is still a need to have a special set of data objects and
> > the server-side logic can duplicate.
> >
> > Java REST API SDK enables to build "thick" client. The calls are
> > realized using e.g. Apache HttClient and supported libraries. I think
> > the requirements of GWT can be a little bit different, but something
> > overlaps.
> >
> > I found several links about REST API support from GWT, so there is
> > something for inspiration...
> >
> > - http://www.spiffyui.org/
> > - http://www.zackgrossbart.com/hackito/gwt-rest/
> > - http://code.google.com/p/gwt-rest/
> > - http://restygwt.fusesource.org/
> >
> > But, do you think it would be useful and what drawbacks can occur
> > (authentication, authorization, response times, need to support larger
> > set of services, painful refactoring, ...)?
> >
> > Regards,
> > Libor
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From derez at redhat.com  Fri Feb 15 18:17:43 2013
From: derez at redhat.com (Daniel Erez)
Date: Fri, 15 Feb 2013 13:17:43 -0500 (EST)
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <511B7128.3030703@redhat.com>
Message-ID: <470070335.2218501.1360952263800.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Libor Spevak" <lspevak at redhat.com>
> Cc: engine-devel at ovirt.org, "Daniel Erez" <derez at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>, "Einav Cohen"
> <ecohen at redhat.com>, arch at ovirt.org
> Sent: Wednesday, February 13, 2013 12:55:36 PM
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> 
> Hi Libor,
> 
> This issue came across in one of the conversations i had with UX
> folks, but since we didn't end
> up with any conclusion/road map (nor discussed it properly to hear
> other thoughts), this is a perfect
> place to start this discussion,
> 
> Intuitively REST is a way to go with GWT AJAX calls
> ---------------------------------------------------
> 
> pros
> ====
> 
> - api data objects can be reused by generating java classes (using
> jaxb) from the rest schema [1]
> - no backend logic will be duplicated as api abstracts the backend
> exposing RESTful collection/resources to operate on
> - development against api is "easy" as api describes itself in RSDL
> [2]
> 
> cons
> ====
> 
> - implementing transport layer (HTTP) under GWT
> - implementing own j2xml/json/yaml/... marshalling layer
> - implementing own error handling mechanism
> - implementing REST callback mechanism (in GWT)
> - constant maintenance of the data objects generated from the api
> - painful for Java developers
> 
> Java-SDK
> --------
> 
> pros
> ====
> 
> - abstracts transport layer (leaving developer in standard Java api)
> - typesafe code (no need to mess with XML bulks)
> - has own data objects to work with
> - abstracts authentication/authorization
> (kerberos/cookie/session/etc.)
> - since SDK is auto-generated, it can be easily extended with
> required
>   features to support UI (such as callback infrastructure for
>   instance)
> 
> cons
> ====
> 
> - has to be converted in to Javascript (not sure what the impacts are
> in terms of AJAX calls/etc.)
> - probably much more cons that we're not aware of and will have to
> figure out with POC
> 
> 
> thoughts?


The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests)
and GWT overlay types (that can be generated from java POJOs).
Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.

The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is
(can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced
with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).

A third alternative could be simply maintaining the current GWT RPC mechanism we use.
I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService.
The main drawback is an additional layer of data type conversion and round-trip:
Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).


> 
> [1] http[s]://server[:port]/api?schema
> [2] http[s]://server[:port]/api?rsdl
> 
> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> > Hi,
> > 
> > I would like to ask, if there have been discussions about an option
> > to call REST API services directly from the Frontend (GWT layer)?
> > GWT compiles Java frontend-side to
> > Javascript, calls to backend services are performed "transparently"
> > by the framework using AJAX support. But, there is still a need to
> > have a special set of data objects
> > and the server-side logic can duplicate.
> > 
> > Java REST API SDK enables to build "thick" client. The calls are
> > realized using e.g. Apache HttClient and supported libraries. I
> > think the requirements of GWT can be a
> > little bit different, but something overlaps.
> > 
> > I found several links about REST API support from GWT, so there is
> > something for inspiration...
> > 
> > - http://www.spiffyui.org/
> > - http://www.zackgrossbart.com/hackito/gwt-rest/
> > - http://code.google.com/p/gwt-rest/
> > - http://restygwt.fusesource.org/
> > 
> > But, do you think it would be useful and what drawbacks can occur
> > (authentication, authorization, response times, need to support
> > larger set of services, painful
> > refactoring, ...)?
> > 
> > Regards,
> > Libor
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From vszocs at redhat.com  Fri Feb 15 19:37:56 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Fri, 15 Feb 2013 14:37:56 -0500 (EST)
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <470070335.2218501.1360952263800.JavaMail.root@redhat.com>
Message-ID: <1894671742.2151757.1360957076451.JavaMail.root@redhat.com>

Hi Daniel,

> The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests)
> and GWT overlay types (that can be generated from java POJOs).
> Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.

Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map "restapi-types" entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema.

> The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is
> (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced
> with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).

Indeed, we can't use Java REST API SDK as it is with GWT: https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation

This means we need to implement our own transport layer (RequestBuilder) and most likely also the marshalling layer (XMLParser vs. JSONParser vs. overlay types).

> A third alternative could be simply maintaining the current GWT RPC mechanism we use.
> I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService.
> The main drawback is an additional layer of data type conversion and round-trip:
> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).

This is interesting, generic API could be used to transfer "restapi-types", along with extra information to emulate proper HTTP request, without any marshalling involved.

Vojtech


----- Original Message -----
From: "Daniel Erez" <derez at redhat.com>
To: "Michael Pasternak" <mpastern at redhat.com>
Cc: engine-devel at ovirt.org, "Einav Cohen" <ecohen at redhat.com>, arch at ovirt.org, "Libor Spevak" <lspevak at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>
Sent: Friday, February 15, 2013 7:17:43 PM
Subject: Re: [Engine-devel] REST API calls from the GUI



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Libor Spevak" <lspevak at redhat.com>
> Cc: engine-devel at ovirt.org, "Daniel Erez" <derez at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>, "Einav Cohen"
> <ecohen at redhat.com>, arch at ovirt.org
> Sent: Wednesday, February 13, 2013 12:55:36 PM
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> 
> Hi Libor,
> 
> This issue came across in one of the conversations i had with UX
> folks, but since we didn't end
> up with any conclusion/road map (nor discussed it properly to hear
> other thoughts), this is a perfect
> place to start this discussion,
> 
> Intuitively REST is a way to go with GWT AJAX calls
> ---------------------------------------------------
> 
> pros
> ====
> 
> - api data objects can be reused by generating java classes (using
> jaxb) from the rest schema [1]
> - no backend logic will be duplicated as api abstracts the backend
> exposing RESTful collection/resources to operate on
> - development against api is "easy" as api describes itself in RSDL
> [2]
> 
> cons
> ====
> 
> - implementing transport layer (HTTP) under GWT
> - implementing own j2xml/json/yaml/... marshalling layer
> - implementing own error handling mechanism
> - implementing REST callback mechanism (in GWT)
> - constant maintenance of the data objects generated from the api
> - painful for Java developers
> 
> Java-SDK
> --------
> 
> pros
> ====
> 
> - abstracts transport layer (leaving developer in standard Java api)
> - typesafe code (no need to mess with XML bulks)
> - has own data objects to work with
> - abstracts authentication/authorization
> (kerberos/cookie/session/etc.)
> - since SDK is auto-generated, it can be easily extended with
> required
>   features to support UI (such as callback infrastructure for
>   instance)
> 
> cons
> ====
> 
> - has to be converted in to Javascript (not sure what the impacts are
> in terms of AJAX calls/etc.)
> - probably much more cons that we're not aware of and will have to
> figure out with POC
> 
> 
> thoughts?


The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests)
and GWT overlay types (that can be generated from java POJOs).
Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.

The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is
(can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced
with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).

A third alternative could be simply maintaining the current GWT RPC mechanism we use.
I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService.
The main drawback is an additional layer of data type conversion and round-trip:
Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).


> 
> [1] http[s]://server[:port]/api?schema
> [2] http[s]://server[:port]/api?rsdl
> 
> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> > Hi,
> > 
> > I would like to ask, if there have been discussions about an option
> > to call REST API services directly from the Frontend (GWT layer)?
> > GWT compiles Java frontend-side to
> > Javascript, calls to backend services are performed "transparently"
> > by the framework using AJAX support. But, there is still a need to
> > have a special set of data objects
> > and the server-side logic can duplicate.
> > 
> > Java REST API SDK enables to build "thick" client. The calls are
> > realized using e.g. Apache HttClient and supported libraries. I
> > think the requirements of GWT can be a
> > little bit different, but something overlaps.
> > 
> > I found several links about REST API support from GWT, so there is
> > something for inspiration...
> > 
> > - http://www.spiffyui.org/
> > - http://www.zackgrossbart.com/hackito/gwt-rest/
> > - http://code.google.com/p/gwt-rest/
> > - http://restygwt.fusesource.org/
> > 
> > But, do you think it would be useful and what drawbacks can occur
> > (authentication, authorization, response times, need to support
> > larger set of services, painful
> > refactoring, ...)?
> > 
> > Regards,
> > Libor
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From iheim at redhat.com  Fri Feb 15 21:14:54 2013
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 15 Feb 2013 23:14:54 +0200
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <526301840.2128583.1360951880429.JavaMail.root@redhat.com>
References: <526301840.2128583.1360951880429.JavaMail.root@redhat.com>
Message-ID: <511EA54E.9000809@redhat.com>

On 15/02/2013 20:11, Vojtech Szocs wrote:
> Hi Libor,
>
>> I would like to ask, if there have been discussions about an option to
>> call REST API services directly from the Frontend (GWT layer)? GWT
>> compiles Java frontend-side to Javascript, calls to backend services
>> are performed "transparently" by the framework using AJAX support.
>> But, there is still a need to have a special set of data objects and
>> the server-side logic can duplicate.
>
> Indeed, for both WebAdmin and UserPortal, we're planning to move away from GWT RPC (a.k.a Generic API) and use Engine REST API and promote loose coupling between client and server.
>
> As Chris mentioned, for WebAdmin UI plugins, there's already support for calling Engine REST API - session ID is obtained upon WebAdmin UI login and passed to all UI plugins. It's up to plugin authors to decide if the plugin itself (JavaScript) will communicate via REST API, or if the plugin passes the session ID to some other server so that the other server does REST API communication.
>
>> Java REST API SDK enables to build "thick" client. The calls are
>> realized using e.g. Apache HttClient and supported libraries. I think
>> the requirements of GWT can be a little bit different, but something
>> overlaps.
>
> Well, we can't really use Java REST API SDK directly due to restrictions imposed by GWT on client-side code, e.g. HttClient uses sockets which are (obviously) not supported in JavaScript and therefore related classes are rejected by GWT compiler.
>
> What we're planning to do is to map REST API XML responses to generated "REST API Types" (based on api.xsd schema) and vice versa. This could be a bit of challenge, as most frameworks for GWT REST API support use JSON representation in favor of XML.

JSON is also more efficient than XML, but will take a bit of time until 
supported by the REST API.

>
> Vojtech
>
>
> ----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: "Keith Robertson" <kroberts at redhat.com>, "Libor Spevak" <lspevak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, February 12, 2013 11:53:52 PM
> Subject: Re: [Engine-devel] REST API calls from the GUI
>
> The UI plugin framework already makes a session ID available for REST API calls. Oved's blog gives a good description with some example code.
>
> http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html
>
> -Chris
>
>> -----Original Message-----
>> From: engine-devel-bounces at ovirt.org [mailto:engine-devel-
>> bounces at ovirt.org] On Behalf Of Keith Robertson
>> Sent: Tuesday, February 12, 2013 11:30 AM
>> To: Libor Spevak
>> Cc: engine-devel at ovirt.org
>> Subject: Re: [Engine-devel] REST API calls from the GUI
>>
>> Not sure if this is possible now but, I would like the front-end to expose an
>> authenticated hook to the API so that plug-ins can call RESTful methods.  It
>> would enable plug-in writers to do all sorts of interesting things in their plug-
>> ins with the RESTful API.
>>
>> Cheers,
>> Keith
>>
>> On 02/12/2013 11:13 AM, Libor Spevak wrote:
>>> Hi,
>>>
>>> I would like to ask, if there have been discussions about an option to
>>> call REST API services directly from the Frontend (GWT layer)? GWT
>>> compiles Java frontend-side to Javascript, calls to backend services
>>> are performed "transparently" by the framework using AJAX support.
>>> But, there is still a need to have a special set of data objects and
>>> the server-side logic can duplicate.
>>>
>>> Java REST API SDK enables to build "thick" client. The calls are
>>> realized using e.g. Apache HttClient and supported libraries. I think
>>> the requirements of GWT can be a little bit different, but something
>>> overlaps.
>>>
>>> I found several links about REST API support from GWT, so there is
>>> something for inspiration...
>>>
>>> - http://www.spiffyui.org/
>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
>>> - http://code.google.com/p/gwt-rest/
>>> - http://restygwt.fusesource.org/
>>>
>>> But, do you think it would be useful and what drawbacks can occur
>>> (authentication, authorization, response times, need to support larger
>>> set of services, painful refactoring, ...)?
>>>
>>> Regards,
>>> Libor
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From eedri at redhat.com  Sat Feb 16 13:39:28 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sat, 16 Feb 2013 08:39:28 -0500 (EST)
Subject: [Engine-devel] oVirt on Fedora 17
In-Reply-To: <511E2B12.2020409@redhat.com>
Message-ID: <1598642600.3977870.1361021968208.JavaMail.root@redhat.com>

Hey sandro,

Are you sure? 
i'm seeing fedora 17 rpms here: http://resources.ovirt.org/releases/stable/rpm/Fedora/17/noarch/

can you check again?

Eyal.

----- Original Message -----
> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Friday, February 15, 2013 2:33:22 PM
> Subject: [Engine-devel] oVirt on Fedora 17
> 
> Hi,
> I'm testing the upgrade path from Fedora 17 with oVirt 3.1 to Fedora
> 18
> with oVirt 3.2 now that 3.2 is released.
> I've seen that ovirt-stable is not available anymore on Fedora 17:
> http://resources.ovirt.org/releases/stable/rpm/Fedora/ shows only
> Fedora
> 18 and Fedora 19.
> 
> I can fix the repository url on my system pointing to
> http://resources.ovirt.org/releases/3.1/rpm/Fedora/
> but since Fedora 17 is still available I think that the 3.1 / F17
> repo
> should be still available on ovirt.org.
> 
> --
> Sandro
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From eedri at redhat.com  Sun Feb 17 08:08:50 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 17 Feb 2013 03:08:50 -0500 (EST)
Subject: [Engine-devel] [JENKINS] unplanned outage for jenkins.ovirt.org
Message-ID: <192988795.4018759.1361088530088.JavaMail.root@redhat.com>

Fyi,

Due to important update jenkins.ovirt.org will be unavailable for the next few min,

sorry for the inconvenience,

Eyal.
oVirt infra team 


From eedri at redhat.com  Sun Feb 17 08:49:40 2013
From: eedri at redhat.com (Eyal Edri)
Date: Sun, 17 Feb 2013 03:49:40 -0500 (EST)
Subject: [Engine-devel] [JENKINS] unplanned outage for jenkins.ovirt.org
In-Reply-To: <192988795.4018759.1361088530088.JavaMail.root@redhat.com>
Message-ID: <2019534698.4032943.1361090980261.JavaMail.root@redhat.com>

Outage is over.

jenkins.ovirt.org has been upgraded to 1.480.3 LTS.

thanks,

Eyal.
----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Cc: "infra" <infra at ovirt.org>
> Sent: Sunday, February 17, 2013 10:08:50 AM
> Subject: [Engine-devel] [JENKINS] unplanned outage for jenkins.ovirt.org
> 
> Fyi,
> 
> Due to important update jenkins.ovirt.org will be unavailable for the
> next few min,
> 
> sorry for the inconvenience,
> 
> Eyal.
> oVirt infra team
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Sun Feb 17 09:01:09 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 17 Feb 2013 11:01:09 +0200
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <1894671742.2151757.1360957076451.JavaMail.root@redhat.com>
References: <1894671742.2151757.1360957076451.JavaMail.root@redhat.com>
Message-ID: <51209C55.90400@redhat.com>

On 02/15/2013 09:37 PM, Vojtech Szocs wrote:
> Hi Daniel,
> 
>> > The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests)
>> > and GWT overlay types (that can be generated from java POJOs).
>> > Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.
> Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map "restapi-types" entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema.

REST API does not support JSON yet due to Resteasy JacksonProvider and JAXB issues.

> 


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From kmayilsa at redhat.com  Mon Feb 18 03:09:45 2013
From: kmayilsa at redhat.com (Kanagaraj Mayilsamy)
Date: Sun, 17 Feb 2013 22:09:45 -0500 (EST)
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <1894671742.2151757.1360957076451.JavaMail.root@redhat.com>
Message-ID: <100470733.1912624.1361156985822.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Daniel Erez" <derez at redhat.com>
> Cc: arch at ovirt.org, engine-devel at ovirt.org
> Sent: Saturday, February 16, 2013 1:07:56 AM
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> Hi Daniel,
> 
> > The first alternative can be implemented by using GWT
> > RequestBuilder (for sending the HTTP requests)
> > and GWT overlay types (that can be generated from java POJOs).
> > Probably best performance-wise/less data type conversions/etc;
> > However, basically means writing a JavaScript SDK.
> 
> Yes, we can use RequestBuilder for making AJAX HTTP requests, but
> using GWT overlay types is possible only if REST API fully supports
> JSON format. In case of XML format, we would have to use GWT
> XMLParser to map "restapi-types" entities/collections to/from XML
> strings, e.g. we could write GWT deferred binding generators to
> generate such mappers from current schema.

AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be useful instead of generating/writing overlay types. AutoBeans will be converted overlay types internally by GWT automatically.

> 
> > The benefit of the second alternative is currently rather vague
> > since the Java SDK can't be converted to JavaScript as is
> > (can't use apache.commons and javax packages in GWT client side).
> > Need to check how easily they can be replaced
> > with JRE libraries that GWT can emulate (for supporting both GWT
> > web and debug mode).
> 
> Indeed, we can't use Java REST API SDK as it is with GWT:
> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation
> 
> This means we need to implement our own transport layer
> (RequestBuilder) and most likely also the marshalling layer
> (XMLParser vs. JSONParser vs. overlay types).

It would be better if We can come up with a "GWT REST API SDK", which is analogous Java SDK. 

> 
> > A third alternative could be simply maintaining the current GWT RPC
> > mechanism we use.
> > I.e. integrating the Java SDK into the GWT servlet, which means
> > wrapping the API into GenericApiGWTService.
> > The main drawback is an additional layer of data type conversion
> > and round-trip:
> > Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
> 
> This is interesting, generic API could be used to transfer
> "restapi-types", along with extra information to emulate proper HTTP
> request, without any marshalling involved.
> 

We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT. 

> Vojtech
> 
> 
> ----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>
> Cc: engine-devel at ovirt.org, "Einav Cohen" <ecohen at redhat.com>,
> arch at ovirt.org, "Libor Spevak" <lspevak at redhat.com>, "Vojtech Szocs"
> <vszocs at redhat.com>
> Sent: Friday, February 15, 2013 7:17:43 PM
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Pasternak" <mpastern at redhat.com>
> > To: "Libor Spevak" <lspevak at redhat.com>
> > Cc: engine-devel at ovirt.org, "Daniel Erez" <derez at redhat.com>,
> > "Gilad Chaplik" <gchaplik at redhat.com>, "Einav Cohen"
> > <ecohen at redhat.com>, arch at ovirt.org
> > Sent: Wednesday, February 13, 2013 12:55:36 PM
> > Subject: Re: [Engine-devel] REST API calls from the GUI
> > 
> > 
> > Hi Libor,
> > 
> > This issue came across in one of the conversations i had with UX
> > folks, but since we didn't end
> > up with any conclusion/road map (nor discussed it properly to hear
> > other thoughts), this is a perfect
> > place to start this discussion,
> > 
> > Intuitively REST is a way to go with GWT AJAX calls
> > ---------------------------------------------------
> > 
> > pros
> > ====
> > 
> > - api data objects can be reused by generating java classes (using
> > jaxb) from the rest schema [1]
> > - no backend logic will be duplicated as api abstracts the backend
> > exposing RESTful collection/resources to operate on
> > - development against api is "easy" as api describes itself in RSDL
> > [2]
> > 
> > cons
> > ====
> > 
> > - implementing transport layer (HTTP) under GWT
> > - implementing own j2xml/json/yaml/... marshalling layer
> > - implementing own error handling mechanism
> > - implementing REST callback mechanism (in GWT)
> > - constant maintenance of the data objects generated from the api
> > - painful for Java developers
> > 
> > Java-SDK
> > --------
> > 
> > pros
> > ====
> > 
> > - abstracts transport layer (leaving developer in standard Java
> > api)
> > - typesafe code (no need to mess with XML bulks)
> > - has own data objects to work with
> > - abstracts authentication/authorization
> > (kerberos/cookie/session/etc.)
> > - since SDK is auto-generated, it can be easily extended with
> > required
> >   features to support UI (such as callback infrastructure for
> >   instance)
> > 
> > cons
> > ====
> > 
> > - has to be converted in to Javascript (not sure what the impacts
> > are
> > in terms of AJAX calls/etc.)
> > - probably much more cons that we're not aware of and will have to
> > figure out with POC
> > 
> > 
> > thoughts?
> 
> 
> The first alternative can be implemented by using GWT RequestBuilder
> (for sending the HTTP requests)
> and GWT overlay types (that can be generated from java POJOs).
> Probably best performance-wise/less data type conversions/etc;
> However, basically means writing a JavaScript SDK.
> 
> The benefit of the second alternative is currently rather vague since
> the Java SDK can't be converted to JavaScript as is
> (can't use apache.commons and javax packages in GWT client side).
> Need to check how easily they can be replaced
> with JRE libraries that GWT can emulate (for supporting both GWT web
> and debug mode).
> 
> A third alternative could be simply maintaining the current GWT RPC
> mechanism we use.
> I.e. integrating the Java SDK into the GWT servlet, which means
> wrapping the API into GenericApiGWTService.
> The main drawback is an additional layer of data type conversion and
> round-trip:
> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
> 
> 
> > 
> > [1] http[s]://server[:port]/api?schema
> > [2] http[s]://server[:port]/api?rsdl
> > 
> > On 02/12/2013 06:13 PM, Libor Spevak wrote:
> > > Hi,
> > > 
> > > I would like to ask, if there have been discussions about an
> > > option
> > > to call REST API services directly from the Frontend (GWT layer)?
> > > GWT compiles Java frontend-side to
> > > Javascript, calls to backend services are performed
> > > "transparently"
> > > by the framework using AJAX support. But, there is still a need
> > > to
> > > have a special set of data objects
> > > and the server-side logic can duplicate.
> > > 
> > > Java REST API SDK enables to build "thick" client. The calls are
> > > realized using e.g. Apache HttClient and supported libraries. I
> > > think the requirements of GWT can be a
> > > little bit different, but something overlaps.
> > > 
> > > I found several links about REST API support from GWT, so there
> > > is
> > > something for inspiration...
> > > 
> > > - http://www.spiffyui.org/
> > > - http://www.zackgrossbart.com/hackito/gwt-rest/
> > > - http://code.google.com/p/gwt-rest/
> > > - http://restygwt.fusesource.org/
> > > 
> > > But, do you think it would be useful and what drawbacks can occur
> > > (authentication, authorization, response times, need to support
> > > larger set of services, painful
> > > refactoring, ...)?
> > > 
> > > Regards,
> > > Libor
> > > 
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> > 
> > --
> > 
> > Michael Pasternak
> > RedHat, ENG-Virtualization R&D
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From sbonazzo at redhat.com  Mon Feb 18 07:08:59 2013
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Mon, 18 Feb 2013 08:08:59 +0100
Subject: [Engine-devel] oVirt on Fedora 17
In-Reply-To: <1598642600.3977870.1361021968208.JavaMail.root@redhat.com>
References: <1598642600.3977870.1361021968208.JavaMail.root@redhat.com>
Message-ID: <5121D38B.2070704@redhat.com>

Hi Eyal,
Checked, I can see them too. Maybe someone have fixed it, thanks.
-- 
Sandro

Il 16/02/2013 14:39, Eyal Edri ha scritto:
> Hey sandro,
>
> Are you sure? 
> i'm seeing fedora 17 rpms here: http://resources.ovirt.org/releases/stable/rpm/Fedora/17/noarch/
>
> can you check again?
>
> Eyal.
>
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbonazzo at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Friday, February 15, 2013 2:33:22 PM
>> Subject: [Engine-devel] oVirt on Fedora 17
>>
>> Hi,
>> I'm testing the upgrade path from Fedora 17 with oVirt 3.1 to Fedora
>> 18
>> with oVirt 3.2 now that 3.2 is released.
>> I've seen that ovirt-stable is not available anymore on Fedora 17:
>> http://resources.ovirt.org/releases/stable/rpm/Fedora/ shows only
>> Fedora
>> 18 and Fedora 19.
>>
>> I can fix the repository url on my system pointing to
>> http://resources.ovirt.org/releases/3.1/rpm/Fedora/
>> but since Fedora 17 is still available I think that the 3.1 / F17
>> repo
>> should be still available on ovirt.org.
>>
>> --
>> Sandro
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From vszocs at redhat.com  Mon Feb 18 12:41:21 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 18 Feb 2013 07:41:21 -0500 (EST)
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <511EA54E.9000809@redhat.com>
Message-ID: <492481975.2948932.1361191281119.JavaMail.root@redhat.com>

Hi,

> JSON is also more efficient than XML, but will take a bit of time until 
> supported by the REST API.

yes, we can either wait for REST API JSON support, or work with REST API via XML. The latter approach most likely requires more effort on client though.

Vojtech


----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: "Libor Spevak" <lspevak at redhat.com>, engine-devel at ovirt.org, "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
Sent: Friday, February 15, 2013 10:14:54 PM
Subject: Re: [Engine-devel] REST API calls from the GUI

On 15/02/2013 20:11, Vojtech Szocs wrote:
> Hi Libor,
>
>> I would like to ask, if there have been discussions about an option to
>> call REST API services directly from the Frontend (GWT layer)? GWT
>> compiles Java frontend-side to Javascript, calls to backend services
>> are performed "transparently" by the framework using AJAX support.
>> But, there is still a need to have a special set of data objects and
>> the server-side logic can duplicate.
>
> Indeed, for both WebAdmin and UserPortal, we're planning to move away from GWT RPC (a.k.a Generic API) and use Engine REST API and promote loose coupling between client and server.
>
> As Chris mentioned, for WebAdmin UI plugins, there's already support for calling Engine REST API - session ID is obtained upon WebAdmin UI login and passed to all UI plugins. It's up to plugin authors to decide if the plugin itself (JavaScript) will communicate via REST API, or if the plugin passes the session ID to some other server so that the other server does REST API communication.
>
>> Java REST API SDK enables to build "thick" client. The calls are
>> realized using e.g. Apache HttClient and supported libraries. I think
>> the requirements of GWT can be a little bit different, but something
>> overlaps.
>
> Well, we can't really use Java REST API SDK directly due to restrictions imposed by GWT on client-side code, e.g. HttClient uses sockets which are (obviously) not supported in JavaScript and therefore related classes are rejected by GWT compiler.
>
> What we're planning to do is to map REST API XML responses to generated "REST API Types" (based on api.xsd schema) and vice versa. This could be a bit of challenge, as most frameworks for GWT REST API support use JSON representation in favor of XML.

JSON is also more efficient than XML, but will take a bit of time until 
supported by the REST API.

>
> Vojtech
>
>
> ----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: "Keith Robertson" <kroberts at redhat.com>, "Libor Spevak" <lspevak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, February 12, 2013 11:53:52 PM
> Subject: Re: [Engine-devel] REST API calls from the GUI
>
> The UI plugin framework already makes a session ID available for REST API calls. Oved's blog gives a good description with some example code.
>
> http://ovedou.blogspot.co.il/2012/12/ovirt-foreman-ui-plugin.html
>
> -Chris
>
>> -----Original Message-----
>> From: engine-devel-bounces at ovirt.org [mailto:engine-devel-
>> bounces at ovirt.org] On Behalf Of Keith Robertson
>> Sent: Tuesday, February 12, 2013 11:30 AM
>> To: Libor Spevak
>> Cc: engine-devel at ovirt.org
>> Subject: Re: [Engine-devel] REST API calls from the GUI
>>
>> Not sure if this is possible now but, I would like the front-end to expose an
>> authenticated hook to the API so that plug-ins can call RESTful methods.  It
>> would enable plug-in writers to do all sorts of interesting things in their plug-
>> ins with the RESTful API.
>>
>> Cheers,
>> Keith
>>
>> On 02/12/2013 11:13 AM, Libor Spevak wrote:
>>> Hi,
>>>
>>> I would like to ask, if there have been discussions about an option to
>>> call REST API services directly from the Frontend (GWT layer)? GWT
>>> compiles Java frontend-side to Javascript, calls to backend services
>>> are performed "transparently" by the framework using AJAX support.
>>> But, there is still a need to have a special set of data objects and
>>> the server-side logic can duplicate.
>>>
>>> Java REST API SDK enables to build "thick" client. The calls are
>>> realized using e.g. Apache HttClient and supported libraries. I think
>>> the requirements of GWT can be a little bit different, but something
>>> overlaps.
>>>
>>> I found several links about REST API support from GWT, so there is
>>> something for inspiration...
>>>
>>> - http://www.spiffyui.org/
>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
>>> - http://code.google.com/p/gwt-rest/
>>> - http://restygwt.fusesource.org/
>>>
>>> But, do you think it would be useful and what drawbacks can occur
>>> (authentication, authorization, response times, need to support larger
>>> set of services, painful refactoring, ...)?
>>>
>>> Regards,
>>> Libor
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From lspevak at redhat.com  Mon Feb 18 14:29:24 2013
From: lspevak at redhat.com (Libor Spevak)
Date: Mon, 18 Feb 2013 15:29:24 +0100
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <1894671742.2151757.1360957076451.JavaMail.root@redhat.com>
References: <1894671742.2151757.1360957076451.JavaMail.root@redhat.com>
Message-ID: <51223AC4.9060806@redhat.com>

It looks like there are several frameworks trying to support GWT and/or 
XML/JSon serialization, but still there is a lot of work to do + 
compatibility problems with the latest versions of GWT, etc.

I investigated a little bit Restlet framework, which looked promising. 
The online documentation available is very limited. But good place to 
look is the book 'Restlet in Action'.

Project examples:

(size: 500M)
git clone https://github.com/restlet/restlet-framework-java.git
cd restlet-framework-java/modules/org.restlet.example.book.restlet.ch09.gwt

Info from the book:

"GWT and Restlet versions
Restlet Framework version 2.0 supports version 2.0 and 2.1 of Google Web 
Toolkit,
but not later, due to API breaking changes introduced in GWT 2.2. 
Restlet Framework
version 2.1 supports GWT 2.3 and above, but not previous versions."

but:

"At the time of writing, the deferred binding support of Restlet only 
supports the special GWT object serialization format. In future 
versions, XML and JSON-based formats could be added by leveraging the 
Piriti library. This library provides JSON and XML mappers for GWT based 
on annotations and deferred binding. Further details are available on 
Google Code at http://code.google.com/p/piriti/."

Just DomRepresentation object and "manual" parsing is probably possible now.

Still waiting for a hope, now 'piriti'? :-)

git clone https://github.com/hpehl/piriti

Has anybody seen it in action?

On 15.2.2013 20:37, Vojtech Szocs wrote:
> Hi Daniel,
>
>> The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests)
>> and GWT overlay types (that can be generated from java POJOs).
>> Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.
> Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map "restapi-types" entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema.
>
>> The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is
>> (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced
>> with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).
> Indeed, we can't use Java REST API SDK as it is with GWT: https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation
>
> This means we need to implement our own transport layer (RequestBuilder) and most likely also the marshalling layer (XMLParser vs. JSONParser vs. overlay types).
>
>> A third alternative could be simply maintaining the current GWT RPC mechanism we use.
>> I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService.
>> The main drawback is an additional layer of data type conversion and round-trip:
>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
> This is interesting, generic API could be used to transfer "restapi-types", along with extra information to emulate proper HTTP request, without any marshalling involved.
>
> Vojtech
>
>
> ----- Original Message -----
> From: "Daniel Erez" <derez at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>
> Cc: engine-devel at ovirt.org, "Einav Cohen" <ecohen at redhat.com>, arch at ovirt.org, "Libor Spevak" <lspevak at redhat.com>, "Vojtech Szocs" <vszocs at redhat.com>
> Sent: Friday, February 15, 2013 7:17:43 PM
> Subject: Re: [Engine-devel] REST API calls from the GUI
>
>
>
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Libor Spevak" <lspevak at redhat.com>
>> Cc: engine-devel at ovirt.org, "Daniel Erez" <derez at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>, "Einav Cohen"
>> <ecohen at redhat.com>, arch at ovirt.org
>> Sent: Wednesday, February 13, 2013 12:55:36 PM
>> Subject: Re: [Engine-devel] REST API calls from the GUI
>>
>>
>> Hi Libor,
>>
>> This issue came across in one of the conversations i had with UX
>> folks, but since we didn't end
>> up with any conclusion/road map (nor discussed it properly to hear
>> other thoughts), this is a perfect
>> place to start this discussion,
>>
>> Intuitively REST is a way to go with GWT AJAX calls
>> ---------------------------------------------------
>>
>> pros
>> ====
>>
>> - api data objects can be reused by generating java classes (using
>> jaxb) from the rest schema [1]
>> - no backend logic will be duplicated as api abstracts the backend
>> exposing RESTful collection/resources to operate on
>> - development against api is "easy" as api describes itself in RSDL
>> [2]
>>
>> cons
>> ====
>>
>> - implementing transport layer (HTTP) under GWT
>> - implementing own j2xml/json/yaml/... marshalling layer
>> - implementing own error handling mechanism
>> - implementing REST callback mechanism (in GWT)
>> - constant maintenance of the data objects generated from the api
>> - painful for Java developers
>>
>> Java-SDK
>> --------
>>
>> pros
>> ====
>>
>> - abstracts transport layer (leaving developer in standard Java api)
>> - typesafe code (no need to mess with XML bulks)
>> - has own data objects to work with
>> - abstracts authentication/authorization
>> (kerberos/cookie/session/etc.)
>> - since SDK is auto-generated, it can be easily extended with
>> required
>>    features to support UI (such as callback infrastructure for
>>    instance)
>>
>> cons
>> ====
>>
>> - has to be converted in to Javascript (not sure what the impacts are
>> in terms of AJAX calls/etc.)
>> - probably much more cons that we're not aware of and will have to
>> figure out with POC
>>
>>
>> thoughts?
>
> The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests)
> and GWT overlay types (that can be generated from java POJOs).
> Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK.
>
> The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is
> (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced
> with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode).
>
> A third alternative could be simply maintaining the current GWT RPC mechanism we use.
> I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService.
> The main drawback is an additional layer of data type conversion and round-trip:
> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
>
>
>> [1] http[s]://server[:port]/api?schema
>> [2] http[s]://server[:port]/api?rsdl
>>
>> On 02/12/2013 06:13 PM, Libor Spevak wrote:
>>> Hi,
>>>
>>> I would like to ask, if there have been discussions about an option
>>> to call REST API services directly from the Frontend (GWT layer)?
>>> GWT compiles Java frontend-side to
>>> Javascript, calls to backend services are performed "transparently"
>>> by the framework using AJAX support. But, there is still a need to
>>> have a special set of data objects
>>> and the server-side logic can duplicate.
>>>
>>> Java REST API SDK enables to build "thick" client. The calls are
>>> realized using e.g. Apache HttClient and supported libraries. I
>>> think the requirements of GWT can be a
>>> little bit different, but something overlaps.
>>>
>>> I found several links about REST API support from GWT, so there is
>>> something for inspiration...
>>>
>>> - http://www.spiffyui.org/
>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
>>> - http://code.google.com/p/gwt-rest/
>>> - http://restygwt.fusesource.org/
>>>
>>> But, do you think it would be useful and what drawbacks can occur
>>> (authentication, authorization, response times, need to support
>>> larger set of services, painful
>>> refactoring, ...)?
>>>
>>> Regards,
>>> Libor
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D



From deadhorseconsulting at gmail.com  Mon Feb 18 22:21:16 2013
From: deadhorseconsulting at gmail.com (Dead Horse)
Date: Mon, 18 Feb 2013 16:21:16 -0600
Subject: [Engine-devel] vdsm/zombiereaper
Message-ID: <CAEWPe=q4PE0U1Vx_9vafqOUARibx2XZnVP3HhcAM__HcDGVRtA@mail.gmail.com>

Any movement or thoughts yet on this one: http://gerrit.ovirt.org/#/c/11492/

It still has vdsm master broken.

- DHC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130218/954d4c56/attachment.html>

From oschreib at redhat.com  Tue Feb 19 09:51:15 2013
From: oschreib at redhat.com (Ofer Schreiber)
Date: Tue, 19 Feb 2013 04:51:15 -0500 (EST)
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <178866445.3078781.1361266876992.JavaMail.root@redhat.com>
Message-ID: <101223956.3085755.1361267475942.JavaMail.root@redhat.com>

I feel that the current "-1 I would prefer that you didn't submit this" message in Gerrit is pretty rude, as usually those -1 reviews are just small fix-ups in the code itself.

Any thoughts about a more suitable "-1" message?
I thought about "-1 Please fix your code" or something similar.

Thanks,
Ofer Schreiber



From ykaul at redhat.com  Tue Feb 19 09:54:56 2013
From: ykaul at redhat.com (Yaniv Kaul)
Date: Tue, 19 Feb 2013 11:54:56 +0200
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <101223956.3085755.1361267475942.JavaMail.root@redhat.com>
References: <101223956.3085755.1361267475942.JavaMail.root@redhat.com>
Message-ID: <51234BF0.6010209@redhat.com>

On 19/02/13 11:51, Ofer Schreiber wrote:
> I feel that the current "-1 I would prefer that you didn't submit this" message in Gerrit is pretty rude, as usually those -1 reviews are just small fix-ups in the code itself.

I think 'I would prefer that you didn't' is fine, I'm not sure why 
'submit this' and not 'merge this'.
Y.

>
> Any thoughts about a more suitable "-1" message?
> I thought about "-1 Please fix your code" or something similar.
>
> Thanks,
> Ofer Schreiber
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lhornyak at redhat.com  Tue Feb 19 10:06:48 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Tue, 19 Feb 2013 05:06:48 -0500 (EST)
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <101223956.3085755.1361267475942.JavaMail.root@redhat.com>
Message-ID: <1990864298.391523.1361268408731.JavaMail.root@redhat.com>

Hi,

I agree with that.

for the - messages this in my opinion would be both more clear and friendly:
-1: In my opinion it needs work.
-2: I disagree.

----- Original Message -----
> From: "Ofer Schreiber" <oschreib at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, February 19, 2013 10:51:15 AM
> Subject: [Engine-devel] Changing Gerrit -1 message
> 
> I feel that the current "-1 I would prefer that you didn't submit
> this" message in Gerrit is pretty rude, as usually those -1 reviews
> are just small fix-ups in the code itself.
> 
> Any thoughts about a more suitable "-1" message?
> I thought about "-1 Please fix your code" or something similar.
> 
> Thanks,
> Ofer Schreiber
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From danken at redhat.com  Tue Feb 19 13:33:05 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 19 Feb 2013 15:33:05 +0200
Subject: [Engine-devel] vdsm/zombiereaper
In-Reply-To: <CAEWPe=q4PE0U1Vx_9vafqOUARibx2XZnVP3HhcAM__HcDGVRtA@mail.gmail.com>
References: <CAEWPe=q4PE0U1Vx_9vafqOUARibx2XZnVP3HhcAM__HcDGVRtA@mail.gmail.com>
Message-ID: <20130219133305.GP23843@redhat.com>

On Mon, Feb 18, 2013 at 04:21:16PM -0600, Dead Horse wrote:
> Any movement or thoughts yet on this one: http://gerrit.ovirt.org/#/c/11492/
> 
> It still has vdsm master broken.

Guys, I think that DHC is right - we cannot keep deliberating forever.
Having a process leak is bad, but keeping master broken for so long is
even worse.

So unless anyone violently objects, I'll revert the offending patch.

Dan.


From danken at redhat.com  Tue Feb 19 13:38:30 2013
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 19 Feb 2013 15:38:30 +0200
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <51234BF0.6010209@redhat.com>
References: <101223956.3085755.1361267475942.JavaMail.root@redhat.com>
	<51234BF0.6010209@redhat.com>
Message-ID: <20130219133830.GQ23843@redhat.com>

On Tue, Feb 19, 2013 at 11:54:56AM +0200, Yaniv Kaul wrote:
> On 19/02/13 11:51, Ofer Schreiber wrote:
> >I feel that the current "-1 I would prefer that you didn't submit this" message in Gerrit is pretty rude, as usually those -1 reviews are just small fix-ups in the code itself.
> 
> I think 'I would prefer that you didn't' is fine, I'm not sure why
> 'submit this' and not 'merge this'.

Gerrit uses the "submit" term for "taking a change into a branch"
elsewhere, too. Maybe because "merge" is something else in gittish.

> Y.
> 
> >
> >Any thoughts about a more suitable "-1" message?
> >I thought about "-1 Please fix your code" or something similar.

I don't care much about the text, but many people told me that "I would
prefer that you didn't submit this" sounds condensding. So a change is
in place, and I do not mind your suggestion, Ofer.

Dan.


From amureini at redhat.com  Tue Feb 19 14:25:12 2013
From: amureini at redhat.com (Allon Mureinik)
Date: Tue, 19 Feb 2013 09:25:12 -0500 (EST)
Subject: [Engine-devel] Importing the engine project into Eclipse IDE
In-Reply-To: <784381954.5495586.1361283615100.JavaMail.root@redhat.com>
Message-ID: <233808020.5501221.1361283912121.JavaMail.root@redhat.com>

Hi guys,

Back in the day, we had a wiki about working on the engine code in Eclipse:
http://www.ovirt.org/Building_oVirt_Engine/IDE#Eclipse

Aside from the software installations, it basically says import the project, and then a set of manual fixes to compilation issues.

Last evening, after thoroughly foobaring my workspaces, I found myself re-importing the project, and having it compile scott-free, with no manual steps required.
I know there was some work done on that area (Don't remember by who - Juan? Asaf? Tomas?), and I want to remove this redundant section from the wiki.

This worked for me on Eclipse Juno (build id: 20120614-1722), but I'd appreciate an extra verification or two before updating the wiki.



Thanks,
Allon


From ybronhei at redhat.com  Tue Feb 19 14:25:45 2013
From: ybronhei at redhat.com (Yaniv Bronheim)
Date: Tue, 19 Feb 2013 09:25:45 -0500 (EST)
Subject: [Engine-devel] vdsm/zombiereaper
In-Reply-To: <20130219133305.GP23843@redhat.com>
Message-ID: <1725936980.1855778.1361283945507.JavaMail.root@redhat.com>

Agree.. Until we'll upload better solution for the zombies issue I prefer to merge that patch.


----- Original Message -----
From: "Dan Kenigsberg" <danken at redhat.com>
To: "Dead Horse" <deadhorseconsulting at gmail.com>
Cc: engine-devel at ovirt.org, "Yaniv Bronhaim" <ybronhei at redhat.com>, "Royce Lv" <lvroyce at linux.vnet.ibm.com>, "ShaoHe Feng" <shaohef at linux.vnet.ibm.com>, vdsm-devel at fedorahosted.org
Sent: Tuesday, February 19, 2013 3:33:05 PM
Subject: Re: [Engine-devel] vdsm/zombiereaper

On Mon, Feb 18, 2013 at 04:21:16PM -0600, Dead Horse wrote:
> Any movement or thoughts yet on this one: http://gerrit.ovirt.org/#/c/11492/
> 
> It still has vdsm master broken.

Guys, I think that DHC is right - we cannot keep deliberating forever.
Having a process leak is bad, but keeping master broken for so long is
even worse.

So unless anyone violently objects, I'll revert the offending patch.

Dan.


From iheim at redhat.com  Tue Feb 19 14:41:45 2013
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 19 Feb 2013 16:41:45 +0200
Subject: [Engine-devel] Importing the engine project into Eclipse IDE
In-Reply-To: <233808020.5501221.1361283912121.JavaMail.root@redhat.com>
References: <233808020.5501221.1361283912121.JavaMail.root@redhat.com>
Message-ID: <51238F29.4040201@redhat.com>

On 19/02/2013 16:25, Allon Mureinik wrote:
> Hi guys,
>
> Back in the day, we had a wiki about working on the engine code in Eclipse:
> http://www.ovirt.org/Building_oVirt_Engine/IDE#Eclipse
>
> Aside from the software installations, it basically says import the project, and then a set of manual fixes to compilation issues.
>
> Last evening, after thoroughly foobaring my workspaces, I found myself re-importing the project, and having it compile scott-free, with no manual steps required.
> I know there was some work done on that area (Don't remember by who - Juan? Asaf? Tomas?), and I want to remove this redundant section from the wiki.
>
> This worked for me on Eclipse Juno (build id: 20120614-1722), but I'd appreciate an extra verification or two before updating the wiki.

i had the same (good) experience after juan (iirc) cleaned most issues.


From jhernand at redhat.com  Tue Feb 19 14:48:02 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 19 Feb 2013 15:48:02 +0100
Subject: [Engine-devel] Importing the engine project into Eclipse IDE
In-Reply-To: <51238F29.4040201@redhat.com>
References: <233808020.5501221.1361283912121.JavaMail.root@redhat.com>
	<51238F29.4040201@redhat.com>
Message-ID: <512390A2.4040609@redhat.com>

On 02/19/2013 03:41 PM, Itamar Heim wrote:
> On 19/02/2013 16:25, Allon Mureinik wrote:
>> Hi guys,
>>
>> Back in the day, we had a wiki about working on the engine code in Eclipse:
>> http://www.ovirt.org/Building_oVirt_Engine/IDE#Eclipse
>>
>> Aside from the software installations, it basically says import the project, and then a set of manual fixes to compilation issues.
>>
>> Last evening, after thoroughly foobaring my workspaces, I found myself re-importing the project, and having it compile scott-free, with no manual steps required.
>> I know there was some work done on that area (Don't remember by who - Juan? Asaf? Tomas?), and I want to remove this redundant section from the wiki.
>>
>> This worked for me on Eclipse Juno (build id: 20120614-1722), but I'd appreciate an extra verification or two before updating the wiki.

If you mean removing the "Change project settings to Resolve compilation 
errors" section I think it is safe. I did check that many times, is no 
longer required with Eclipse Juno nor with JBoss developer studio.

-- 
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.


From amureini at redhat.com  Tue Feb 19 15:05:23 2013
From: amureini at redhat.com (Allon Mureinik)
Date: Tue, 19 Feb 2013 10:05:23 -0500 (EST)
Subject: [Engine-devel] Importing the engine project into Eclipse IDE
In-Reply-To: <512390A2.4040609@redhat.com>
Message-ID: <2046377690.5592073.1361286323113.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> Cc: "Allon Mureinik" <amureini at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Tuesday, February 19, 2013 4:48:02 PM
> Subject: Re: [Engine-devel] Importing the engine project into Eclipse IDE
> 
> On 02/19/2013 03:41 PM, Itamar Heim wrote:
> > On 19/02/2013 16:25, Allon Mureinik wrote:
> >> Hi guys,
> >>
> >> Back in the day, we had a wiki about working on the engine code in
> >> Eclipse:
> >> http://www.ovirt.org/Building_oVirt_Engine/IDE#Eclipse
> >>
> >> Aside from the software installations, it basically says import
> >> the project, and then a set of manual fixes to compilation
> >> issues.
> >>
> >> Last evening, after thoroughly foobaring my workspaces, I found
> >> myself re-importing the project, and having it compile
> >> scott-free, with no manual steps required.
> >> I know there was some work done on that area (Don't remember by
> >> who - Juan? Asaf? Tomas?), and I want to remove this redundant
> >> section from the wiki.
> >>
> >> This worked for me on Eclipse Juno (build id: 20120614-1722), but
> >> I'd appreciate an extra verification or two before updating the
> >> wiki.
> 
> If you mean removing the "Change project settings to Resolve
> compilation
> errors" section I think it is safe. I did check that many times, is
> no
> longer required with Eclipse Juno nor with JBoss developer studio.
Yes, that's the section I meant.
Removed it, thanks.

> 
> --
> 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.
> 


From lspevak at redhat.com  Tue Feb 19 15:44:10 2013
From: lspevak at redhat.com (Libor Spevak)
Date: Tue, 19 Feb 2013 16:44:10 +0100
Subject: [Engine-devel] DB Performance Monitoring
Message-ID: <51239DCA.40900@redhat.com>

Hi,
I just wanted to share a partial result from testing of engine db load 
during operation (SQL queries frequencies). Maybe, we can decide later, 
if some SQL queries result CACHING can boost throughput for larger 
deployments.

The caching technology can be from a simple HashMap lookup to 
deployments of something like http://ehcache.org/ (memory database).

I prepared two simple scenarios:

- oVirt engine, 2 hosts, 1 VM, running 15 minutes (Power on + Up state)
- oVirt engine, 2 hosts, 10 VMs from one pool, running 15 minutes (Power 
on + Up state)

Appending 2 spreadsheets with data about the most used SQL queries 
(generated by PostgreSQL standard pg_statements_stat module).

e.g.
- 2nd row shows number of granted connections from the db pool (e.g. can 
be used to set optimal connection pool size) (check of connection 
health: select 1)
- most of the queries are wrapped by a PLSQL function so we see a wrapper:

/select * from  getvdsgroupbyvdsgroupid($1, $2, $3)/

and near to it the 'real' query:

/SELECT vds_groups_view.*//
//      FROM vds_groups_view//
//      WHERE vds_group_id = v_vds_group_id//
//      AND (NOT v_is_filtered OR EXISTS (SELECT 1//
//                                        FROM 
user_vds_groups_permissions_view//
//                                        WHERE  user_id = v_user_id AND 
entity_id = v_vds_group_id))//
/
Just as an example, I selected in yellow color some queries, which 
probably do not change often, but are very frequent.

Other tools like 'pg_top' can provide runtime statistics of db processes 
(cpu, mem, locks, ... views).

By enabling debug level logging of PostgreSQL we can check real values 
to the queries.

Of course, it would be useful to run such tests with many hosts and VMs 
to predict scaling issues.

More info about tools configuration:
http://www.ovirt.org/Engine_database_performance_monitoring

Regards,
Libor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130219/eac53bed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sql_report20130217_1vm.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 27758 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130219/eac53bed/attachment.ods>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sql_report20130217_10vm_pool_2hosts.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 28977 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130219/eac53bed/attachment-0001.ods>

From iheim at redhat.com  Wed Feb 20 08:32:53 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 20 Feb 2013 10:32:53 +0200
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <1990864298.391523.1361268408731.JavaMail.root@redhat.com>
References: <1990864298.391523.1361268408731.JavaMail.root@redhat.com>
Message-ID: <51248A35.50006@redhat.com>

On 19/02/2013 12:06, Laszlo Hornyak wrote:
> Hi,
>
> I agree with that.
>
> for the - messages this in my opinion would be both more clear and friendly:
> -1: In my opinion it needs work.


how about
"-1: Please review my comments"

> -2: I disagree.

"-2: Please reconsider"

>
> ----- Original Message -----
>> From: "Ofer Schreiber" <oschreib at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, February 19, 2013 10:51:15 AM
>> Subject: [Engine-devel] Changing Gerrit -1 message
>>
>> I feel that the current "-1 I would prefer that you didn't submit
>> this" message in Gerrit is pretty rude, as usually those -1 reviews
>> are just small fix-ups in the code itself.
>>
>> Any thoughts about a more suitable "-1" message?
>> I thought about "-1 Please fix your code" or something similar.
>>
>> Thanks,
>> Ofer Schreiber
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From asegurap at redhat.com  Wed Feb 20 09:59:16 2013
From: asegurap at redhat.com (Antoni Segura Puimedon)
Date: Wed, 20 Feb 2013 04:59:16 -0500 (EST)
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <51248A35.50006@redhat.com>
Message-ID: <773697665.2157048.1361354356809.JavaMail.root@redhat.com>

I like most of these proposals. It'll make gerrit friendlier :-)

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, February 20, 2013 9:32:53 AM
> Subject: Re: [Engine-devel] Changing Gerrit -1 message
> 
> On 19/02/2013 12:06, Laszlo Hornyak wrote:
> > Hi,
> >
> > I agree with that.
> >
> > for the - messages this in my opinion would be both more clear and
> > friendly:
> > -1: In my opinion it needs work.
> 
> 
> how about
> "-1: Please review my comments"
> 
> > -2: I disagree.
> 
> "-2: Please reconsider"
> 
> >
> > ----- Original Message -----
> >> From: "Ofer Schreiber" <oschreib at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Tuesday, February 19, 2013 10:51:15 AM
> >> Subject: [Engine-devel] Changing Gerrit -1 message
> >>
> >> I feel that the current "-1 I would prefer that you didn't submit
> >> this" message in Gerrit is pretty rude, as usually those -1
> >> reviews
> >> are just small fix-ups in the code itself.
> >>
> >> Any thoughts about a more suitable "-1" message?
> >> I thought about "-1 Please fix your code" or something similar.
> >>
> >> Thanks,
> >> Ofer Schreiber
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Wed Feb 20 12:25:50 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 20 Feb 2013 14:25:50 +0200
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <100470733.1912624.1361156985822.JavaMail.root@redhat.com>
References: <100470733.1912624.1361156985822.JavaMail.root@redhat.com>
Message-ID: <5124C0CE.40105@redhat.com>

On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote:
> 
> 
> ----- Original Message -----
>> From: "Vojtech Szocs" <vszocs at redhat.com>
>> To: "Daniel Erez" <derez at redhat.com>
>> Cc: arch at ovirt.org, engine-devel at ovirt.org
>> Sent: Saturday, February 16, 2013 1:07:56 AM
>> Subject: Re: [Engine-devel] REST API calls from the GUI
>>
>> Hi Daniel,
>>
>>> The first alternative can be implemented by using GWT
>>> RequestBuilder (for sending the HTTP requests)
>>> and GWT overlay types (that can be generated from java POJOs).
>>> Probably best performance-wise/less data type conversions/etc;
>>> However, basically means writing a JavaScript SDK.
>>
>> Yes, we can use RequestBuilder for making AJAX HTTP requests, but
>> using GWT overlay types is possible only if REST API fully supports
>> JSON format. In case of XML format, we would have to use GWT
>> XMLParser to map "restapi-types" entities/collections to/from XML
>> strings, e.g. we could write GWT deferred binding generators to
>> generate such mappers from current schema.
> 
> AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be useful instead of generating/writing overlay types. AutoBeans will be converted overlay types internally by GWT automatically.
> 
>>
>>> The benefit of the second alternative is currently rather vague
>>> since the Java SDK can't be converted to JavaScript as is
>>> (can't use apache.commons and javax packages in GWT client side).
>>> Need to check how easily they can be replaced
>>> with JRE libraries that GWT can emulate (for supporting both GWT
>>> web and debug mode).
>>
>> Indeed, we can't use Java REST API SDK as it is with GWT:
>> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation
>>
>> This means we need to implement our own transport layer
>> (RequestBuilder) and most likely also the marshalling layer
>> (XMLParser vs. JSONParser vs. overlay types).
> 
> It would be better if We can come up with a "GWT REST API SDK", which is analogous Java SDK. 
> 
>>
>>> A third alternative could be simply maintaining the current GWT RPC
>>> mechanism we use.
>>> I.e. integrating the Java SDK into the GWT servlet, which means
>>> wrapping the API into GenericApiGWTService.
>>> The main drawback is an additional layer of data type conversion
>>> and round-trip:
>>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
>>
>> This is interesting, generic API could be used to transfer
>> "restapi-types", along with extra information to emulate proper HTTP
>> request, without any marshalling involved.
>>
> 
> We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT. 

why? they only have jaxb annotations which are 'must' for serialization & talking with api.

> 
>> Vojtech
>>
>>
>> ----- Original Message -----
>> From: "Daniel Erez" <derez at redhat.com>
>> To: "Michael Pasternak" <mpastern at redhat.com>
>> Cc: engine-devel at ovirt.org, "Einav Cohen" <ecohen at redhat.com>,
>> arch at ovirt.org, "Libor Spevak" <lspevak at redhat.com>, "Vojtech Szocs"
>> <vszocs at redhat.com>
>> Sent: Friday, February 15, 2013 7:17:43 PM
>> Subject: Re: [Engine-devel] REST API calls from the GUI
>>
>>
>>
>> ----- Original Message -----
>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>> To: "Libor Spevak" <lspevak at redhat.com>
>>> Cc: engine-devel at ovirt.org, "Daniel Erez" <derez at redhat.com>,
>>> "Gilad Chaplik" <gchaplik at redhat.com>, "Einav Cohen"
>>> <ecohen at redhat.com>, arch at ovirt.org
>>> Sent: Wednesday, February 13, 2013 12:55:36 PM
>>> Subject: Re: [Engine-devel] REST API calls from the GUI
>>>
>>>
>>> Hi Libor,
>>>
>>> This issue came across in one of the conversations i had with UX
>>> folks, but since we didn't end
>>> up with any conclusion/road map (nor discussed it properly to hear
>>> other thoughts), this is a perfect
>>> place to start this discussion,
>>>
>>> Intuitively REST is a way to go with GWT AJAX calls
>>> ---------------------------------------------------
>>>
>>> pros
>>> ====
>>>
>>> - api data objects can be reused by generating java classes (using
>>> jaxb) from the rest schema [1]
>>> - no backend logic will be duplicated as api abstracts the backend
>>> exposing RESTful collection/resources to operate on
>>> - development against api is "easy" as api describes itself in RSDL
>>> [2]
>>>
>>> cons
>>> ====
>>>
>>> - implementing transport layer (HTTP) under GWT
>>> - implementing own j2xml/json/yaml/... marshalling layer
>>> - implementing own error handling mechanism
>>> - implementing REST callback mechanism (in GWT)
>>> - constant maintenance of the data objects generated from the api
>>> - painful for Java developers
>>>
>>> Java-SDK
>>> --------
>>>
>>> pros
>>> ====
>>>
>>> - abstracts transport layer (leaving developer in standard Java
>>> api)
>>> - typesafe code (no need to mess with XML bulks)
>>> - has own data objects to work with
>>> - abstracts authentication/authorization
>>> (kerberos/cookie/session/etc.)
>>> - since SDK is auto-generated, it can be easily extended with
>>> required
>>>   features to support UI (such as callback infrastructure for
>>>   instance)
>>>
>>> cons
>>> ====
>>>
>>> - has to be converted in to Javascript (not sure what the impacts
>>> are
>>> in terms of AJAX calls/etc.)
>>> - probably much more cons that we're not aware of and will have to
>>> figure out with POC
>>>
>>>
>>> thoughts?
>>
>>
>> The first alternative can be implemented by using GWT RequestBuilder
>> (for sending the HTTP requests)
>> and GWT overlay types (that can be generated from java POJOs).
>> Probably best performance-wise/less data type conversions/etc;
>> However, basically means writing a JavaScript SDK.
>>
>> The benefit of the second alternative is currently rather vague since
>> the Java SDK can't be converted to JavaScript as is
>> (can't use apache.commons and javax packages in GWT client side).
>> Need to check how easily they can be replaced
>> with JRE libraries that GWT can emulate (for supporting both GWT web
>> and debug mode).
>>
>> A third alternative could be simply maintaining the current GWT RPC
>> mechanism we use.
>> I.e. integrating the Java SDK into the GWT servlet, which means
>> wrapping the API into GenericApiGWTService.
>> The main drawback is an additional layer of data type conversion and
>> round-trip:
>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
>>
>>
>>>
>>> [1] http[s]://server[:port]/api?schema
>>> [2] http[s]://server[:port]/api?rsdl
>>>
>>> On 02/12/2013 06:13 PM, Libor Spevak wrote:
>>>> Hi,
>>>>
>>>> I would like to ask, if there have been discussions about an
>>>> option
>>>> to call REST API services directly from the Frontend (GWT layer)?
>>>> GWT compiles Java frontend-side to
>>>> Javascript, calls to backend services are performed
>>>> "transparently"
>>>> by the framework using AJAX support. But, there is still a need
>>>> to
>>>> have a special set of data objects
>>>> and the server-side logic can duplicate.
>>>>
>>>> Java REST API SDK enables to build "thick" client. The calls are
>>>> realized using e.g. Apache HttClient and supported libraries. I
>>>> think the requirements of GWT can be a
>>>> little bit different, but something overlaps.
>>>>
>>>> I found several links about REST API support from GWT, so there
>>>> is
>>>> something for inspiration...
>>>>
>>>> - http://www.spiffyui.org/
>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
>>>> - http://code.google.com/p/gwt-rest/
>>>> - http://restygwt.fusesource.org/
>>>>
>>>> But, do you think it would be useful and what drawbacks can occur
>>>> (authentication, authorization, response times, need to support
>>>> larger set of services, painful
>>>> refactoring, ...)?
>>>>
>>>> Regards,
>>>> Libor
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From kmayilsa at redhat.com  Wed Feb 20 12:45:02 2013
From: kmayilsa at redhat.com (Kanagaraj Mayilsamy)
Date: Wed, 20 Feb 2013 07:45:02 -0500 (EST)
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <5124C0CE.40105@redhat.com>
Message-ID: <1355849725.2819461.1361364302776.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Kanagaraj Mayilsamy" <kmayilsa at redhat.com>
> Cc: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org, arch at ovirt.org
> Sent: Wednesday, February 20, 2013 5:55:50 PM
> Subject: Re: [Engine-devel] REST API calls from the GUI
> 
> On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Vojtech Szocs" <vszocs at redhat.com>
> >> To: "Daniel Erez" <derez at redhat.com>
> >> Cc: arch at ovirt.org, engine-devel at ovirt.org
> >> Sent: Saturday, February 16, 2013 1:07:56 AM
> >> Subject: Re: [Engine-devel] REST API calls from the GUI
> >>
> >> Hi Daniel,
> >>
> >>> The first alternative can be implemented by using GWT
> >>> RequestBuilder (for sending the HTTP requests)
> >>> and GWT overlay types (that can be generated from java POJOs).
> >>> Probably best performance-wise/less data type conversions/etc;
> >>> However, basically means writing a JavaScript SDK.
> >>
> >> Yes, we can use RequestBuilder for making AJAX HTTP requests, but
> >> using GWT overlay types is possible only if REST API fully
> >> supports
> >> JSON format. In case of XML format, we would have to use GWT
> >> XMLParser to map "restapi-types" entities/collections to/from XML
> >> strings, e.g. we could write GWT deferred binding generators to
> >> generate such mappers from current schema.
> > 
> > AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean)
> > could be useful instead of generating/writing overlay types.
> > AutoBeans will be converted overlay types internally by GWT
> > automatically.
> > 
> >>
> >>> The benefit of the second alternative is currently rather vague
> >>> since the Java SDK can't be converted to JavaScript as is
> >>> (can't use apache.commons and javax packages in GWT client side).
> >>> Need to check how easily they can be replaced
> >>> with JRE libraries that GWT can emulate (for supporting both GWT
> >>> web and debug mode).
> >>
> >> Indeed, we can't use Java REST API SDK as it is with GWT:
> >> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation
> >>
> >> This means we need to implement our own transport layer
> >> (RequestBuilder) and most likely also the marshalling layer
> >> (XMLParser vs. JSONParser vs. overlay types).
> > 
> > It would be better if We can come up with a "GWT REST API SDK",
> > which is analogous Java SDK.
> > 
> >>
> >>> A third alternative could be simply maintaining the current GWT
> >>> RPC
> >>> mechanism we use.
> >>> I.e. integrating the Java SDK into the GWT servlet, which means
> >>> wrapping the API into GenericApiGWTService.
> >>> The main drawback is an additional layer of data type conversion
> >>> and round-trip:
> >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
> >>
> >> This is interesting, generic API could be used to transfer
> >> "restapi-types", along with extra information to emulate proper
> >> HTTP
> >> request, without any marshalling involved.
> >>
> > 
> > We can't directly use the restapi models in the client side, as
> > they have lot of xml and annotations stuff involved which will not
> > be compatible with GWT.
> 
> why? they only have jaxb annotations which are 'must' for
> serialization & talking with api.
> 

We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation

If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by GWT. 

> > 
> >> Vojtech
> >>
> >>
> >> ----- Original Message -----
> >> From: "Daniel Erez" <derez at redhat.com>
> >> To: "Michael Pasternak" <mpastern at redhat.com>
> >> Cc: engine-devel at ovirt.org, "Einav Cohen" <ecohen at redhat.com>,
> >> arch at ovirt.org, "Libor Spevak" <lspevak at redhat.com>, "Vojtech
> >> Szocs"
> >> <vszocs at redhat.com>
> >> Sent: Friday, February 15, 2013 7:17:43 PM
> >> Subject: Re: [Engine-devel] REST API calls from the GUI
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>> To: "Libor Spevak" <lspevak at redhat.com>
> >>> Cc: engine-devel at ovirt.org, "Daniel Erez" <derez at redhat.com>,
> >>> "Gilad Chaplik" <gchaplik at redhat.com>, "Einav Cohen"
> >>> <ecohen at redhat.com>, arch at ovirt.org
> >>> Sent: Wednesday, February 13, 2013 12:55:36 PM
> >>> Subject: Re: [Engine-devel] REST API calls from the GUI
> >>>
> >>>
> >>> Hi Libor,
> >>>
> >>> This issue came across in one of the conversations i had with UX
> >>> folks, but since we didn't end
> >>> up with any conclusion/road map (nor discussed it properly to
> >>> hear
> >>> other thoughts), this is a perfect
> >>> place to start this discussion,
> >>>
> >>> Intuitively REST is a way to go with GWT AJAX calls
> >>> ---------------------------------------------------
> >>>
> >>> pros
> >>> ====
> >>>
> >>> - api data objects can be reused by generating java classes
> >>> (using
> >>> jaxb) from the rest schema [1]
> >>> - no backend logic will be duplicated as api abstracts the
> >>> backend
> >>> exposing RESTful collection/resources to operate on
> >>> - development against api is "easy" as api describes itself in
> >>> RSDL
> >>> [2]
> >>>
> >>> cons
> >>> ====
> >>>
> >>> - implementing transport layer (HTTP) under GWT
> >>> - implementing own j2xml/json/yaml/... marshalling layer
> >>> - implementing own error handling mechanism
> >>> - implementing REST callback mechanism (in GWT)
> >>> - constant maintenance of the data objects generated from the api
> >>> - painful for Java developers
> >>>
> >>> Java-SDK
> >>> --------
> >>>
> >>> pros
> >>> ====
> >>>
> >>> - abstracts transport layer (leaving developer in standard Java
> >>> api)
> >>> - typesafe code (no need to mess with XML bulks)
> >>> - has own data objects to work with
> >>> - abstracts authentication/authorization
> >>> (kerberos/cookie/session/etc.)
> >>> - since SDK is auto-generated, it can be easily extended with
> >>> required
> >>>   features to support UI (such as callback infrastructure for
> >>>   instance)
> >>>
> >>> cons
> >>> ====
> >>>
> >>> - has to be converted in to Javascript (not sure what the impacts
> >>> are
> >>> in terms of AJAX calls/etc.)
> >>> - probably much more cons that we're not aware of and will have
> >>> to
> >>> figure out with POC
> >>>
> >>>
> >>> thoughts?
> >>
> >>
> >> The first alternative can be implemented by using GWT
> >> RequestBuilder
> >> (for sending the HTTP requests)
> >> and GWT overlay types (that can be generated from java POJOs).
> >> Probably best performance-wise/less data type conversions/etc;
> >> However, basically means writing a JavaScript SDK.
> >>
> >> The benefit of the second alternative is currently rather vague
> >> since
> >> the Java SDK can't be converted to JavaScript as is
> >> (can't use apache.commons and javax packages in GWT client side).
> >> Need to check how easily they can be replaced
> >> with JRE libraries that GWT can emulate (for supporting both GWT
> >> web
> >> and debug mode).
> >>
> >> A third alternative could be simply maintaining the current GWT
> >> RPC
> >> mechanism we use.
> >> I.e. integrating the Java SDK into the GWT servlet, which means
> >> wrapping the API into GenericApiGWTService.
> >> The main drawback is an additional layer of data type conversion
> >> and
> >> round-trip:
> >> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
> >>
> >>
> >>>
> >>> [1] http[s]://server[:port]/api?schema
> >>> [2] http[s]://server[:port]/api?rsdl
> >>>
> >>> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> >>>> Hi,
> >>>>
> >>>> I would like to ask, if there have been discussions about an
> >>>> option
> >>>> to call REST API services directly from the Frontend (GWT
> >>>> layer)?
> >>>> GWT compiles Java frontend-side to
> >>>> Javascript, calls to backend services are performed
> >>>> "transparently"
> >>>> by the framework using AJAX support. But, there is still a need
> >>>> to
> >>>> have a special set of data objects
> >>>> and the server-side logic can duplicate.
> >>>>
> >>>> Java REST API SDK enables to build "thick" client. The calls are
> >>>> realized using e.g. Apache HttClient and supported libraries. I
> >>>> think the requirements of GWT can be a
> >>>> little bit different, but something overlaps.
> >>>>
> >>>> I found several links about REST API support from GWT, so there
> >>>> is
> >>>> something for inspiration...
> >>>>
> >>>> - http://www.spiffyui.org/
> >>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
> >>>> - http://code.google.com/p/gwt-rest/
> >>>> - http://restygwt.fusesource.org/
> >>>>
> >>>> But, do you think it would be useful and what drawbacks can
> >>>> occur
> >>>> (authentication, authorization, response times, need to support
> >>>> larger set of services, painful
> >>>> refactoring, ...)?
> >>>>
> >>>> Regards,
> >>>> Libor
> >>>>
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>>
> >>> --
> >>>
> >>> Michael Pasternak
> >>> RedHat, ENG-Virtualization R&D
> >>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From mpastern at redhat.com  Wed Feb 20 12:56:59 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 20 Feb 2013 14:56:59 +0200
Subject: [Engine-devel] REST API calls from
In-Reply-To: <82414620.2634605.1360833600485.JavaMail.root@redhat.com>
References: <82414620.2634605.1360833600485.JavaMail.root@redhat.com>
Message-ID: <5124C81B.4080201@redhat.com>

On 02/14/2013 11:20 AM, Doron Fediuck wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Libor Spevak" <lspevak at redhat.com>
>> Cc: engine-devel at ovirt.org, arch at ovirt.org
>> Sent: Wednesday, February 13, 2013 12:55:36 PM
>> Subject: Re: [Engine-devel] REST API calls from the GUI
>>
>>
>> Hi Libor,
>>
>> This issue came across in one of the conversations i had with UX
>> folks, but since we didn't end
>> up with any conclusion/road map (nor discussed it properly to hear
>> other thoughts), this is a perfect
>> place to start this discussion,
>>
>> Intuitively REST is a way to go with GWT AJAX calls
>> ---------------------------------------------------
>>
>> pros
>> ====
>>
>> - api data objects can be reused by generating java classes (using
>> jaxb) from the rest schema [1]
>> - no backend logic will be duplicated as api abstracts the backend
>> exposing RESTful collection/resources to operate on
>> - development against api is "easy" as api describes itself in RSDL
>> [2]
>>
>> cons
>> ====
>>
>> - implementing transport layer (HTTP) under GWT
>> - implementing own j2xml/json/yaml/... marshalling layer
>> - implementing own error handling mechanism
>> - implementing REST callback mechanism (in GWT)
>> - constant maintenance of the data objects generated from the api
>> - painful for Java developers
>>
>> Java-SDK
>> --------
>>
>> pros
>> ====
>>
>> - abstracts transport layer (leaving developer in standard Java api)
>> - typesafe code (no need to mess with XML bulks)
>> - has own data objects to work with
>> - abstracts authentication/authorization
>> (kerberos/cookie/session/etc.)
>> - since SDK is auto-generated, it can be easily extended with
>> required
>>   features to support UI (such as callback infrastructure for
>>   instance)
>>
>> cons
>> ====
>>
>> - has to be converted in to Javascript (not sure what the impacts are
>> in terms of AJAX calls/etc.)
>> - probably much more cons that we're not aware of and will have to
>> figure out with POC
>>
>>
>> thoughts?
>>
>> [1] http[s]://server[:port]/api?schema
>> [2] http[s]://server[:port]/api?rsdl
>>
> 
> Although started as a UI request, there are other needs who wish
> to use API calls with a different transport. For example a backend
> hook which gets a REST entry point it can use to fetch for additional
> data, or perform actions. In this case I'd expect an internal connection
> rather than creating additional connections.
> How would you resolve it generically enough in this context?

Doron,

I believe your approach a bit different, UX folks seeking for a convenient
way of communicating with ovirt public api, e.g closing api<->GUI gap, and
theirs alternatives where native HTTP layer or Java-SDK based framework,
while what you need is in-process channel to communicate with the engine itself,

i understanding your will of using stable api for this (RESTapi), but not
sure that doing this via JavaSDK is a good way to go simply because SDK is
designed to operate in a client-space, while what you need is a server-space
bridge for that.

> 
>> On 02/12/2013 06:13 PM, Libor Spevak wrote:
>>> Hi,
>>>
>>> I would like to ask, if there have been discussions about an option
>>> to call REST API services directly from the Frontend (GWT layer)?
>>> GWT compiles Java frontend-side to
>>> Javascript, calls to backend services are performed "transparently"
>>> by the framework using AJAX support. But, there is still a need to
>>> have a special set of data objects
>>> and the server-side logic can duplicate.
>>>
>>> Java REST API SDK enables to build "thick" client. The calls are
>>> realized using e.g. Apache HttClient and supported libraries. I
>>> think the requirements of GWT can be a
>>> little bit different, but something overlaps.
>>>
>>> I found several links about REST API support from GWT, so there is
>>> something for inspiration...
>>>
>>> - http://www.spiffyui.org/
>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
>>> - http://code.google.com/p/gwt-rest/
>>> - http://restygwt.fusesource.org/
>>>
>>> But, do you think it would be useful and what drawbacks can occur
>>> (authentication, authorization, response times, need to support
>>> larger set of services, painful
>>> refactoring, ...)?
>>>
>>> Regards,
>>> Libor
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Wed Feb 20 13:07:15 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Wed, 20 Feb 2013 15:07:15 +0200
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <1355849725.2819461.1361364302776.JavaMail.root@redhat.com>
References: <1355849725.2819461.1361364302776.JavaMail.root@redhat.com>
Message-ID: <5124CA83.1040600@redhat.com>

On 02/20/2013 02:45 PM, Kanagaraj Mayilsamy wrote:
> 
> ----- Original Message -----
>> > From: "Michael Pasternak" <mpastern at redhat.com>
>> > To: "Kanagaraj Mayilsamy" <kmayilsa at redhat.com>
>> > Cc: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org, arch at ovirt.org
>> > Sent: Wednesday, February 20, 2013 5:55:50 PM
>> > Subject: Re: [Engine-devel] REST API calls from the GUI
>> > 
>> > On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote:
>>> > > 
>>> > > 
>>> > > ----- Original Message -----
>>>> > >> From: "Vojtech Szocs" <vszocs at redhat.com>
>>>> > >> To: "Daniel Erez" <derez at redhat.com>
>>>> > >> Cc: arch at ovirt.org, engine-devel at ovirt.org
>>>> > >> Sent: Saturday, February 16, 2013 1:07:56 AM
>>>> > >> Subject: Re: [Engine-devel] REST API calls from the GUI
>>>> > >>
>>>> > >> Hi Daniel,
>>>> > >>
>>>>> > >>> The first alternative can be implemented by using GWT
>>>>> > >>> RequestBuilder (for sending the HTTP requests)
>>>>> > >>> and GWT overlay types (that can be generated from java POJOs).
>>>>> > >>> Probably best performance-wise/less data type conversions/etc;
>>>>> > >>> However, basically means writing a JavaScript SDK.
>>>> > >>
>>>> > >> Yes, we can use RequestBuilder for making AJAX HTTP requests, but
>>>> > >> using GWT overlay types is possible only if REST API fully
>>>> > >> supports
>>>> > >> JSON format. In case of XML format, we would have to use GWT
>>>> > >> XMLParser to map "restapi-types" entities/collections to/from XML
>>>> > >> strings, e.g. we could write GWT deferred binding generators to
>>>> > >> generate such mappers from current schema.
>>> > > 
>>> > > AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean)
>>> > > could be useful instead of generating/writing overlay types.
>>> > > AutoBeans will be converted overlay types internally by GWT
>>> > > automatically.
>>> > > 
>>>> > >>
>>>>> > >>> The benefit of the second alternative is currently rather vague
>>>>> > >>> since the Java SDK can't be converted to JavaScript as is
>>>>> > >>> (can't use apache.commons and javax packages in GWT client side).
>>>>> > >>> Need to check how easily they can be replaced
>>>>> > >>> with JRE libraries that GWT can emulate (for supporting both GWT
>>>>> > >>> web and debug mode).
>>>> > >>
>>>> > >> Indeed, we can't use Java REST API SDK as it is with GWT:
>>>> > >> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation
>>>> > >>
>>>> > >> This means we need to implement our own transport layer
>>>> > >> (RequestBuilder) and most likely also the marshalling layer
>>>> > >> (XMLParser vs. JSONParser vs. overlay types).
>>> > > 
>>> > > It would be better if We can come up with a "GWT REST API SDK",
>>> > > which is analogous Java SDK.
>>> > > 
>>>> > >>
>>>>> > >>> A third alternative could be simply maintaining the current GWT
>>>>> > >>> RPC
>>>>> > >>> mechanism we use.
>>>>> > >>> I.e. integrating the Java SDK into the GWT servlet, which means
>>>>> > >>> wrapping the API into GenericApiGWTService.
>>>>> > >>> The main drawback is an additional layer of data type conversion
>>>>> > >>> and round-trip:
>>>>> > >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
>>>> > >>
>>>> > >> This is interesting, generic API could be used to transfer
>>>> > >> "restapi-types", along with extra information to emulate proper
>>>> > >> HTTP
>>>> > >> request, without any marshalling involved.
>>>> > >>
>>> > > 
>>> > > We can't directly use the restapi models in the client side, as
>>> > > they have lot of xml and annotations stuff involved which will not
>>> > > be compatible with GWT.
>> > 
>> > why? they only have jaxb annotations which are 'must' for
>> > serialization & talking with api.
>> > 
> We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation
> 
> If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by GWT. 
> 

if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML
as they are defined in the api schema and not using Java naming convention (as XJC does),

if your schema->java converting tool support this, you're okay.

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From iheim at redhat.com  Wed Feb 20 15:39:16 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 20 Feb 2013 17:39:16 +0200
Subject: [Engine-devel] Engine - top 10 with patches with no activity for
	more than 30 days
Message-ID: <5124EE24.4040300@redhat.com>

thoughts on how to trim these?
(in openstack gerrit they auto-abandon patches with no activity for a 
couple of weeks - author can revive them back when they are relevant)

  preferred_email           | count
  --------------------------+------
  mkolesni at redhat.com       | 17
  rgolan at redhat.com         | 12
  sesubram at redhat.com       | 8
  lhornyak at redhat.com       | 5
  laravot at redhat.com        | 4
  juan.hernandez at redhat.com | 4
  lvernia at redhat.com        | 4
  awels at redhat.com          | 4
  mhuntxu at gmail.com         | 3
  vszocs at redhat.com         | 3


From mkolesni at redhat.com  Wed Feb 20 16:02:15 2013
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Wed, 20 Feb 2013 11:02:15 -0500 (EST)
Subject: [Engine-devel] Engine - top 10 with patches with no activity
 for	more than 30 days
In-Reply-To: <5124EE24.4040300@redhat.com>
Message-ID: <559190283.3856537.1361376135945.JavaMail.root@redhat.com>

----- Original Message -----
> thoughts on how to trim these?
> (in openstack gerrit they auto-abandon patches with no activity for a
> couple of weeks - author can revive them back when they are relevant)
> 
>   preferred_email           | count
>   --------------------------+------
>   mkolesni at redhat.com       | 17

Is the problem that they're not updated?

I am working on a topic branch, so currently no plan to push it to master but I still want it to be open to review.

>   rgolan at redhat.com         | 12
>   sesubram at redhat.com       | 8
>   lhornyak at redhat.com       | 5
>   laravot at redhat.com        | 4
>   juan.hernandez at redhat.com | 4
>   lvernia at redhat.com        | 4
>   awels at redhat.com          | 4
>   mhuntxu at gmail.com         | 3
>   vszocs at redhat.com         | 3
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Wed Feb 20 16:04:39 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 20 Feb 2013 11:04:39 -0500 (EST)
Subject: [Engine-devel] Engine - top 10 with patches with no activity
 for	more than 30 days
In-Reply-To: <5124EE24.4040300@redhat.com>
Message-ID: <1948038981.5383747.1361376279588.JavaMail.root@redhat.com>

Hi,
Why not sending this as a reminder?
But sending also the gerrit links
For example, I assume mkolesni sent an engine patch, maybe I as someone who also sends patches to engine can review (even if not ACK, share some thoughts?)

Thanks,
Yair


----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, February 20, 2013 5:39:16 PM
> Subject: [Engine-devel] Engine - top 10 with patches with no activity for	more than 30 days
> 
> thoughts on how to trim these?
> (in openstack gerrit they auto-abandon patches with no activity for a
> couple of weeks - author can revive them back when they are relevant)
> 
>   preferred_email           | count
>   --------------------------+------
>   mkolesni at redhat.com       | 17
>   rgolan at redhat.com         | 12
>   sesubram at redhat.com       | 8
>   lhornyak at redhat.com       | 5
>   laravot at redhat.com        | 4
>   juan.hernandez at redhat.com | 4
>   lvernia at redhat.com        | 4
>   awels at redhat.com          | 4
>   mhuntxu at gmail.com         | 3
>   vszocs at redhat.com         | 3
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Wed Feb 20 16:17:03 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 20 Feb 2013 18:17:03 +0200
Subject: [Engine-devel] Engine - top 10 with patches with no activity
 for	more than 30 days
In-Reply-To: <559190283.3856537.1361376135945.JavaMail.root@redhat.com>
References: <559190283.3856537.1361376135945.JavaMail.root@redhat.com>
Message-ID: <5124F6FF.4010008@redhat.com>

On 20/02/2013 18:02, Mike Kolesnik wrote:
> ----- Original Message -----
>> thoughts on how to trim these?
>> (in openstack gerrit they auto-abandon patches with no activity for a
>> couple of weeks - author can revive them back when they are relevant)
>>
>>    preferred_email           | count
>>    --------------------------+------
>>    mkolesni at redhat.com       | 17
>
> Is the problem that they're not updated?

yes. any 'touch' to them would be enough.

>
> I am working on a topic branch, so currently no plan to push it to master but I still want it to be open to review.

so not one reviewed them for a over month...

>
>>    rgolan at redhat.com         | 12
>>    sesubram at redhat.com       | 8
>>    lhornyak at redhat.com       | 5
>>    laravot at redhat.com        | 4
>>    juan.hernandez at redhat.com | 4
>>    lvernia at redhat.com        | 4
>>    awels at redhat.com          | 4
>>    mhuntxu at gmail.com         | 3
>>    vszocs at redhat.com         | 3
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From iheim at redhat.com  Wed Feb 20 16:17:43 2013
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 20 Feb 2013 18:17:43 +0200
Subject: [Engine-devel] Engine - top 10 with patches with no activity
 for	more than 30 days
In-Reply-To: <1948038981.5383747.1361376279588.JavaMail.root@redhat.com>
References: <1948038981.5383747.1361376279588.JavaMail.root@redhat.com>
Message-ID: <5124F727.10907@redhat.com>

On 20/02/2013 18:04, Yair Zaslavsky wrote:
> Hi,
> Why not sending this as a reminder?
> But sending also the gerrit links
> For example, I assume mkolesni sent an engine patch, maybe I as someone who also sends patches to engine can review (even if not ACK, share some thoughts?)
>

if you want to help and review old patches, just set your gerrit search 
to age:30d and review old patches...

> Thanks,
> Yair
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, February 20, 2013 5:39:16 PM
>> Subject: [Engine-devel] Engine - top 10 with patches with no activity for	more than 30 days
>>
>> thoughts on how to trim these?
>> (in openstack gerrit they auto-abandon patches with no activity for a
>> couple of weeks - author can revive them back when they are relevant)
>>
>>    preferred_email           | count
>>    --------------------------+------
>>    mkolesni at redhat.com       | 17
>>    rgolan at redhat.com         | 12
>>    sesubram at redhat.com       | 8
>>    lhornyak at redhat.com       | 5
>>    laravot at redhat.com        | 4
>>    juan.hernandez at redhat.com | 4
>>    lvernia at redhat.com        | 4
>>    awels at redhat.com          | 4
>>    mhuntxu at gmail.com         | 3
>>    vszocs at redhat.com         | 3
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From eedri at redhat.com  Wed Feb 20 21:08:26 2013
From: eedri at redhat.com (Eyal Edri)
Date: Wed, 20 Feb 2013 16:08:26 -0500 (EST)
Subject: [Engine-devel] Engine - top 10 with patches with no activity
 for	more than 30 days
In-Reply-To: <5124F727.10907@redhat.com>
Message-ID: <600222918.6507187.1361394506855.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, February 20, 2013 6:17:43 PM
> Subject: Re: [Engine-devel] Engine - top 10 with patches with no activity for	more than 30 days
> 
> On 20/02/2013 18:04, Yair Zaslavsky wrote:
> > Hi,
> > Why not sending this as a reminder?
> > But sending also the gerrit links
> > For example, I assume mkolesni sent an engine patch, maybe I as
> > someone who also sends patches to engine can review (even if not
> > ACK, share some thoughts?)
> >

ohad wrote a nagios plugin that send alerts on old patches for jenkins repo (currently set for 7 days),
i'm guessing it can be enhanced and generalize to handle more projects to to alert on old patches.

> 
> if you want to help and review old patches, just set your gerrit
> search
> to age:30d and review old patches...
> 
> > Thanks,
> > Yair
> >
> >
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Wednesday, February 20, 2013 5:39:16 PM
> >> Subject: [Engine-devel] Engine - top 10 with patches with no
> >> activity for	more than 30 days
> >>
> >> thoughts on how to trim these?
> >> (in openstack gerrit they auto-abandon patches with no activity
> >> for a
> >> couple of weeks - author can revive them back when they are
> >> relevant)
> >>
> >>    preferred_email           | count
> >>    --------------------------+------
> >>    mkolesni at redhat.com       | 17
> >>    rgolan at redhat.com         | 12
> >>    sesubram at redhat.com       | 8
> >>    lhornyak at redhat.com       | 5
> >>    laravot at redhat.com        | 4
> >>    juan.hernandez at redhat.com | 4
> >>    lvernia at redhat.com        | 4
> >>    awels at redhat.com          | 4
> >>    mhuntxu at gmail.com         | 3
> >>    vszocs at redhat.com         | 3
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mlipchuk at redhat.com  Wed Feb 20 22:25:57 2013
From: mlipchuk at redhat.com (Maor Lipchuk)
Date: Thu, 21 Feb 2013 00:25:57 +0200
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <773697665.2157048.1361354356809.JavaMail.root@redhat.com>
References: <773697665.2157048.1361354356809.JavaMail.root@redhat.com>
Message-ID: <51254D75.90203@redhat.com>

I tend to agree as well regarding the -1 message, although I think that
since -2 blocks your change from, merging it, it should still be strict.
Perhaps we could consider adding one more negative value?

Regards,
Maor

On 02/20/2013 11:59 AM, Antoni Segura Puimedon wrote:
> I like most of these proposals. It'll make gerrit friendlier :-)
> 
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Laszlo Hornyak" <lhornyak at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Wednesday, February 20, 2013 9:32:53 AM
>> Subject: Re: [Engine-devel] Changing Gerrit -1 message
>>
>> On 19/02/2013 12:06, Laszlo Hornyak wrote:
>>> Hi,
>>>
>>> I agree with that.
>>>
>>> for the - messages this in my opinion would be both more clear and
>>> friendly:
>>> -1: In my opinion it needs work.
>>
>>
>> how about
>> "-1: Please review my comments"
>>
>>> -2: I disagree.
>>
>> "-2: Please reconsider"
>>
>>>
>>> ----- Original Message -----
>>>> From: "Ofer Schreiber" <oschreib at redhat.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Tuesday, February 19, 2013 10:51:15 AM
>>>> Subject: [Engine-devel] Changing Gerrit -1 message
>>>>
>>>> I feel that the current "-1 I would prefer that you didn't submit
>>>> this" message in Gerrit is pretty rude, as usually those -1
>>>> reviews
>>>> are just small fix-ups in the code itself.
>>>>
>>>> Any thoughts about a more suitable "-1" message?
>>>> I thought about "-1 Please fix your code" or something similar.
>>>>
>>>> Thanks,
>>>> Ofer Schreiber
>>>>
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 




From ovedo at redhat.com  Thu Feb 21 07:46:08 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Thu, 21 Feb 2013 02:46:08 -0500 (EST)
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <51254D75.90203@redhat.com>
Message-ID: <366292290.13804641.1361432768826.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Maor Lipchuk" <mlipchuk at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, February 21, 2013 12:25:57 AM
> Subject: Re: [Engine-devel] Changing Gerrit -1 message
> 
> I tend to agree as well regarding the -1 message, although I think
> that
> since -2 blocks your change from, merging it, it should still be
> strict.
> Perhaps we could consider adding one more negative value?
> 
In my opinion, adding another negative value isn't so friendly... we should be more positive and not negative :-)
I liked the "-1: Please review my comments" proposed below.
I think the current "-2: do not submit" is pretty polite .... If you guys think it requires a change, then I'd change it to: "-2: do not submit. Please review my comments."

Oved
> Regards,
> Maor
> 
> On 02/20/2013 11:59 AM, Antoni Segura Puimedon wrote:
> > I like most of these proposals. It'll make gerrit friendlier :-)
> > 
> > ----- Original Message -----
> >> From: "Itamar Heim" <iheim at redhat.com>
> >> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> >> Cc: engine-devel at ovirt.org
> >> Sent: Wednesday, February 20, 2013 9:32:53 AM
> >> Subject: Re: [Engine-devel] Changing Gerrit -1 message
> >>
> >> On 19/02/2013 12:06, Laszlo Hornyak wrote:
> >>> Hi,
> >>>
> >>> I agree with that.
> >>>
> >>> for the - messages this in my opinion would be both more clear
> >>> and
> >>> friendly:
> >>> -1: In my opinion it needs work.
> >>
> >>
> >> how about
> >> "-1: Please review my comments"
> >>
> >>> -2: I disagree.
> >>
> >> "-2: Please reconsider"
> >>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Ofer Schreiber" <oschreib at redhat.com>
> >>>> To: engine-devel at ovirt.org
> >>>> Sent: Tuesday, February 19, 2013 10:51:15 AM
> >>>> Subject: [Engine-devel] Changing Gerrit -1 message
> >>>>
> >>>> I feel that the current "-1 I would prefer that you didn't
> >>>> submit
> >>>> this" message in Gerrit is pretty rude, as usually those -1
> >>>> reviews
> >>>> are just small fix-ups in the code itself.
> >>>>
> >>>> Any thoughts about a more suitable "-1" message?
> >>>> I thought about "-1 Please fix your code" or something similar.
> >>>>
> >>>> Thanks,
> >>>> Ofer Schreiber
> >>>>
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>> _______________________________________________
> >>> Engine-devel mailing list
> >>> Engine-devel at ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From vszocs at redhat.com  Thu Feb 21 13:30:20 2013
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 21 Feb 2013 08:30:20 -0500 (EST)
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <5124CA83.1040600@redhat.com>
Message-ID: <960012516.4950999.1361453420281.JavaMail.root@redhat.com>

Hi guys,

>>> > > We can't directly use the restapi models in the client side, as
>>> > > they have lot of xml and annotations stuff involved which will not
>>> > > be compatible with GWT.
>> > 
>> > why? they only have jaxb annotations which are 'must' for
>> > serialization & talking with api.

Actually, we *can* use JAXB-generated REST API Java types with GWT, since GWT compiler simply ignores annotations in Java sources during compilation to JavaScript.

The only problem I see is REST API Java types using stuff like javax.xml.datatype.XMLGregorianCalendar - we'd have to emulate it in GWT (shouldn't be an issue).

Other than that, I'd recommend using JAXB-generated REST API Java types, as they always match current REST API schema (api.xsd).

As for the marshalling layer, we can't use JAXB (REST API Java SDK) with GWT, but we can still write deferred binding generator to generate mappers for XML <--> Rest API Java type conversion.

> if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML
> as they are defined in the api schema and not using Java naming convention (as XJC does),

Yeah, with XML representation we would have to do this ourselves.

On the other hand, things would be much simpler if REST API supported JSON, which is something we should consider (wait for JSON support? work with XML?)

>>> > > It would be better if We can come up with a "GWT REST API SDK",
>>> > > which is analogous Java SDK.

I'd rather have JavaScript REST API SDK which we could use with GWT, this would open up new possibilities for web clients.

Vojtech


----- Original Message -----
From: "Michael Pasternak" <mpastern at redhat.com>
To: "Kanagaraj Mayilsamy" <kmayilsa at redhat.com>
Cc: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org, arch at ovirt.org
Sent: Wednesday, February 20, 2013 2:07:15 PM
Subject: Re: [Engine-devel] REST API calls from the GUI

On 02/20/2013 02:45 PM, Kanagaraj Mayilsamy wrote:
> 
> ----- Original Message -----
>> > From: "Michael Pasternak" <mpastern at redhat.com>
>> > To: "Kanagaraj Mayilsamy" <kmayilsa at redhat.com>
>> > Cc: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org, arch at ovirt.org
>> > Sent: Wednesday, February 20, 2013 5:55:50 PM
>> > Subject: Re: [Engine-devel] REST API calls from the GUI
>> > 
>> > On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote:
>>> > > 
>>> > > 
>>> > > ----- Original Message -----
>>>> > >> From: "Vojtech Szocs" <vszocs at redhat.com>
>>>> > >> To: "Daniel Erez" <derez at redhat.com>
>>>> > >> Cc: arch at ovirt.org, engine-devel at ovirt.org
>>>> > >> Sent: Saturday, February 16, 2013 1:07:56 AM
>>>> > >> Subject: Re: [Engine-devel] REST API calls from the GUI
>>>> > >>
>>>> > >> Hi Daniel,
>>>> > >>
>>>>> > >>> The first alternative can be implemented by using GWT
>>>>> > >>> RequestBuilder (for sending the HTTP requests)
>>>>> > >>> and GWT overlay types (that can be generated from java POJOs).
>>>>> > >>> Probably best performance-wise/less data type conversions/etc;
>>>>> > >>> However, basically means writing a JavaScript SDK.
>>>> > >>
>>>> > >> Yes, we can use RequestBuilder for making AJAX HTTP requests, but
>>>> > >> using GWT overlay types is possible only if REST API fully
>>>> > >> supports
>>>> > >> JSON format. In case of XML format, we would have to use GWT
>>>> > >> XMLParser to map "restapi-types" entities/collections to/from XML
>>>> > >> strings, e.g. we could write GWT deferred binding generators to
>>>> > >> generate such mappers from current schema.
>>> > > 
>>> > > AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean)
>>> > > could be useful instead of generating/writing overlay types.
>>> > > AutoBeans will be converted overlay types internally by GWT
>>> > > automatically.
>>> > > 
>>>> > >>
>>>>> > >>> The benefit of the second alternative is currently rather vague
>>>>> > >>> since the Java SDK can't be converted to JavaScript as is
>>>>> > >>> (can't use apache.commons and javax packages in GWT client side).
>>>>> > >>> Need to check how easily they can be replaced
>>>>> > >>> with JRE libraries that GWT can emulate (for supporting both GWT
>>>>> > >>> web and debug mode).
>>>> > >>
>>>> > >> Indeed, we can't use Java REST API SDK as it is with GWT:
>>>> > >> https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation
>>>> > >>
>>>> > >> This means we need to implement our own transport layer
>>>> > >> (RequestBuilder) and most likely also the marshalling layer
>>>> > >> (XMLParser vs. JSONParser vs. overlay types).
>>> > > 
>>> > > It would be better if We can come up with a "GWT REST API SDK",
>>> > > which is analogous Java SDK.
>>> > > 
>>>> > >>
>>>>> > >>> A third alternative could be simply maintaining the current GWT
>>>>> > >>> RPC
>>>>> > >>> mechanism we use.
>>>>> > >>> I.e. integrating the Java SDK into the GWT servlet, which means
>>>>> > >>> wrapping the API into GenericApiGWTService.
>>>>> > >>> The main drawback is an additional layer of data type conversion
>>>>> > >>> and round-trip:
>>>>> > >>> Backend <-> REST <-> Java SDK (servlet) <-> JavaScript (client).
>>>> > >>
>>>> > >> This is interesting, generic API could be used to transfer
>>>> > >> "restapi-types", along with extra information to emulate proper
>>>> > >> HTTP
>>>> > >> request, without any marshalling involved.
>>>> > >>
>>> > > 
>>> > > We can't directly use the restapi models in the client side, as
>>> > > they have lot of xml and annotations stuff involved which will not
>>> > > be compatible with GWT.
>> > 
>> > why? they only have jaxb annotations which are 'must' for
>> > serialization & talking with api.
>> > 
> We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation
> 
> If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by GWT. 
> 

if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML
as they are defined in the api schema and not using Java naming convention (as XJC does),

if your schema->java converting tool support this, you're okay.

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From emesika at redhat.com  Thu Feb 21 16:11:11 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 21 Feb 2013 11:11:11 -0500 (EST)
Subject: [Engine-devel] DB Performance Monitoring
In-Reply-To: <51239DCA.40900@redhat.com>
Message-ID: <1813120861.5022837.1361463071783.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Libor Spevak" <lspevak at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, February 19, 2013 5:44:10 PM
> Subject: [Engine-devel] DB Performance Monitoring
> 
> 
> Hi,
> I just wanted to share a partial result from testing of engine db
> load during operation (SQL queries frequencies). Maybe, we can
> decide later, if some SQL queries result CACHING can boost
> throughput for larger deployments.
> 
> The caching technology can be from a simple HashMap lookup to
> deployments of something like http://ehcache.org/ (memory database).
> 
> I prepared two simple scenarios:
> 
> - oVirt engine, 2 hosts, 1 VM, running 15 minutes (Power on + Up
> state)
> - oVirt engine, 2 hosts, 10 VMs from one pool, running 15 minutes
> (Power on + Up state)
> 
> Appending 2 spreadsheets with data about the most used SQL queries
> (generated by PostgreSQL standard pg_statements_stat module).
> 
> e.g.
> - 2nd row shows number of granted connections from the db pool (e.g.
> can be used to set optimal connection pool size) (check of
> connection health: select 1)
> - most of the queries are wrapped by a PLSQL function so we see a
> wrapper:
> 
> select * from getvdsgroupbyvdsgroupid($1, $2, $3)
> 
> and near to it the 'real' query:
> 
> SELECT vds_groups_view.*
> FROM vds_groups_view
> WHERE vds_group_id = v_vds_group_id
> AND (NOT v_is_filtered OR EXISTS (SELECT 1
> FROM user_vds_groups_permissions_view
> WHERE user_id = v_user_id AND entity_id = v_vds_group_id))
> 
> Just as an example, I selected in yellow color some queries, which
> probably do not change often, but are very frequent.

Thanks Libor for taking te time to do that.
The problematic queries are those that involves all kinds of *permissions* checks with the complicated & expensive permission handling views.
I believe that using Snapshot Materialized Views as defined in http://www.ovirt.org/OVirt-DB-Issues/MaterializedViews will solve the major part of those problems.
We are currently verifying this approach and my recommendation is to have all *permissions* views as Snapshot Materialized Views that are updated via a cron job.


> 
> Other tools like 'pg_top' can provide runtime statistics of db
> processes (cpu, mem, locks, ... views).
> 
> By enabling debug level logging of PostgreSQL we can check real
> values to the queries.
> 
> Of course, it would be useful to run such tests with many hosts and
> VMs to predict scaling issues.
> 
> More info about tools configuration:
> http://www.ovirt.org/Engine_database_performance_monitoring
> 
> Regards,
> Libor
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lspevak at redhat.com  Thu Feb 21 16:50:58 2013
From: lspevak at redhat.com (Libor Spevak)
Date: Thu, 21 Feb 2013 17:50:58 +0100
Subject: [Engine-devel] DB Performance Monitoring
In-Reply-To: <1813120861.5022837.1361463071783.JavaMail.root@redhat.com>
References: <1813120861.5022837.1361463071783.JavaMail.root@redhat.com>
Message-ID: <51265072.8040103@redhat.com>

On 21.2.2013 17:11, Eli Mesika wrote:
> ----- Original Message -----
>> From: "Libor Spevak" <lspevak at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, February 19, 2013 5:44:10 PM
>> Subject: [Engine-devel] DB Performance Monitoring
>>
>>
>> Hi,
>> I just wanted to share a partial result from testing of engine db
>> load during operation (SQL queries frequencies). Maybe, we can
>> decide later, if some SQL queries result CACHING can boost
>> throughput for larger deployments.
>>
>> The caching technology can be from a simple HashMap lookup to
>> deployments of something like http://ehcache.org/ (memory database).
>>
>> I prepared two simple scenarios:
>>
>> - oVirt engine, 2 hosts, 1 VM, running 15 minutes (Power on + Up
>> state)
>> - oVirt engine, 2 hosts, 10 VMs from one pool, running 15 minutes
>> (Power on + Up state)
>>
>> Appending 2 spreadsheets with data about the most used SQL queries
>> (generated by PostgreSQL standard pg_statements_stat module).
>>
>> e.g.
>> - 2nd row shows number of granted connections from the db pool (e.g.
>> can be used to set optimal connection pool size) (check of
>> connection health: select 1)
>> - most of the queries are wrapped by a PLSQL function so we see a
>> wrapper:
>>
>> select * from getvdsgroupbyvdsgroupid($1, $2, $3)
>>
>> and near to it the 'real' query:
>>
>> SELECT vds_groups_view.*
>> FROM vds_groups_view
>> WHERE vds_group_id = v_vds_group_id
>> AND (NOT v_is_filtered OR EXISTS (SELECT 1
>> FROM user_vds_groups_permissions_view
>> WHERE user_id = v_user_id AND entity_id = v_vds_group_id))
>>
>> Just as an example, I selected in yellow color some queries, which
>> probably do not change often, but are very frequent.
> Thanks Libor for taking te time to do that.
> The problematic queries are those that involves all kinds of *permissions* checks with the complicated & expensive permission handling views.
> I believe that using Snapshot Materialized Views as defined in http://www.ovirt.org/OVirt-DB-Issues/MaterializedViews will solve the major part of those problems.
> We are currently verifying this approach and my recommendation is to have all *permissions* views as Snapshot Materialized Views that are updated via a cron job.
>
I think there could be performace improvement with M-views, of course. 
There is some overhead just with their maintainance, e.g. refreshing, 
updating existing dependent objects (table name renames, ...), not sure 
about NATIVE implementation level status in PostgreSQL, according to 
e.g. Oracle db capabilities (MV-logs + M-views).

http://wiki.postgresql.org/wiki/Materialized_Views

Still, if the Engine gathers statistics nearly in real time, my question 
would be, if there is a need of round-trip to the database and back at 
all for frequent queries.

>
>> Other tools like 'pg_top' can provide runtime statistics of db
>> processes (cpu, mem, locks, ... views).
>>
>> By enabling debug level logging of PostgreSQL we can check real
>> values to the queries.
>>
>> Of course, it would be useful to run such tests with many hosts and
>> VMs to predict scaling issues.
>>
>> More info about tools configuration:
>> http://www.ovirt.org/Engine_database_performance_monitoring
>>
>> Regards,
>> Libor
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130221/29c04a6e/attachment.html>

From dfediuck at redhat.com  Thu Feb 21 16:54:59 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Thu, 21 Feb 2013 11:54:59 -0500 (EST)
Subject: [Engine-devel] REST API calls from
In-Reply-To: <5124C81B.4080201@redhat.com>
Message-ID: <1559481678.7174578.1361465699455.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: engine-devel at ovirt.org, arch at ovirt.org
> Sent: Wednesday, February 20, 2013 2:56:59 PM
> Subject: Re: [Engine-devel] REST API calls from
> 
> On 02/14/2013 11:20 AM, Doron Fediuck wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "Libor Spevak" <lspevak at redhat.com>
> >> Cc: engine-devel at ovirt.org, arch at ovirt.org
> >> Sent: Wednesday, February 13, 2013 12:55:36 PM
> >> Subject: Re: [Engine-devel] REST API calls from the GUI
> >>
> >>
> >> Hi Libor,
> >>
> >> This issue came across in one of the conversations i had with UX
> >> folks, but since we didn't end
> >> up with any conclusion/road map (nor discussed it properly to hear
> >> other thoughts), this is a perfect
> >> place to start this discussion,
> >>
> >> Intuitively REST is a way to go with GWT AJAX calls
> >> ---------------------------------------------------
> >>
> >> pros
> >> ====
> >>
> >> - api data objects can be reused by generating java classes (using
> >> jaxb) from the rest schema [1]
> >> - no backend logic will be duplicated as api abstracts the backend
> >> exposing RESTful collection/resources to operate on
> >> - development against api is "easy" as api describes itself in
> >> RSDL
> >> [2]
> >>
> >> cons
> >> ====
> >>
> >> - implementing transport layer (HTTP) under GWT
> >> - implementing own j2xml/json/yaml/... marshalling layer
> >> - implementing own error handling mechanism
> >> - implementing REST callback mechanism (in GWT)
> >> - constant maintenance of the data objects generated from the api
> >> - painful for Java developers
> >>
> >> Java-SDK
> >> --------
> >>
> >> pros
> >> ====
> >>
> >> - abstracts transport layer (leaving developer in standard Java
> >> api)
> >> - typesafe code (no need to mess with XML bulks)
> >> - has own data objects to work with
> >> - abstracts authentication/authorization
> >> (kerberos/cookie/session/etc.)
> >> - since SDK is auto-generated, it can be easily extended with
> >> required
> >>   features to support UI (such as callback infrastructure for
> >>   instance)
> >>
> >> cons
> >> ====
> >>
> >> - has to be converted in to Javascript (not sure what the impacts
> >> are
> >> in terms of AJAX calls/etc.)
> >> - probably much more cons that we're not aware of and will have to
> >> figure out with POC
> >>
> >>
> >> thoughts?
> >>
> >> [1] http[s]://server[:port]/api?schema
> >> [2] http[s]://server[:port]/api?rsdl
> >>
> > 
> > Although started as a UI request, there are other needs who wish
> > to use API calls with a different transport. For example a backend
> > hook which gets a REST entry point it can use to fetch for
> > additional
> > data, or perform actions. In this case I'd expect an internal
> > connection
> > rather than creating additional connections.
> > How would you resolve it generically enough in this context?
> 
> Doron,
> 
> I believe your approach a bit different, UX folks seeking for a
> convenient
> way of communicating with ovirt public api, e.g closing api<->GUI
> gap, and
> theirs alternatives where native HTTP layer or Java-SDK based
> framework,
> while what you need is in-process channel to communicate with the
> engine itself,
> 
> i understanding your will of using stable api for this (RESTapi), but
> not
> sure that doing this via JavaSDK is a good way to go simply because
> SDK is
> designed to operate in a client-space, while what you need is a
> server-space
> bridge for that.
> 

Michael, true but...
Thinking about it differently both UI and hooks needs a client.
The underlying protocols should be abstracted. This is something
which will serve other functions as well.

> > 
> >> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> >>> Hi,
> >>>
> >>> I would like to ask, if there have been discussions about an
> >>> option
> >>> to call REST API services directly from the Frontend (GWT layer)?
> >>> GWT compiles Java frontend-side to
> >>> Javascript, calls to backend services are performed
> >>> "transparently"
> >>> by the framework using AJAX support. But, there is still a need
> >>> to
> >>> have a special set of data objects
> >>> and the server-side logic can duplicate.
> >>>
> >>> Java REST API SDK enables to build "thick" client. The calls are
> >>> realized using e.g. Apache HttClient and supported libraries. I
> >>> think the requirements of GWT can be a
> >>> little bit different, but something overlaps.
> >>>
> >>> I found several links about REST API support from GWT, so there
> >>> is
> >>> something for inspiration...
> >>>
> >>> - http://www.spiffyui.org/
> >>> - http://www.zackgrossbart.com/hackito/gwt-rest/
> >>> - http://code.google.com/p/gwt-rest/
> >>> - http://restygwt.fusesource.org/
> >>>
> >>> But, do you think it would be useful and what drawbacks can occur
> >>> (authentication, authorization, response times, need to support
> >>> larger set of services, painful
> >>> refactoring, ...)?
> >>>
> >>> Regards,
> >>> Libor
> >>>


From dneary at redhat.com  Thu Feb 21 21:21:53 2013
From: dneary at redhat.com (Dave Neary)
Date: Thu, 21 Feb 2013 23:21:53 +0200
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <51248A35.50006@redhat.com>
References: <1990864298.391523.1361268408731.JavaMail.root@redhat.com>
	<51248A35.50006@redhat.com>
Message-ID: <51268FF1.70002@redhat.com>

Hi,

On 02/20/2013 10:32 AM, Itamar Heim wrote:
> On 19/02/2013 12:06, Laszlo Hornyak wrote:
>> Hi,
>>
>> I agree with that.
>>
>> for the - messages this in my opinion would be both more clear and
>> friendly:
>> -1: In my opinion it needs work.
>
>
> how about
> "-1: Please review my comments"

Sounds great.

>> -2: I disagree.
>
> "-2: Please reconsider"

I am trying to think under which circumstances people give a -2. Maybe 
something like "We have discussed this feature, and I disagree that it 
is good for the project." Basically, I don't think that a developer 
should ever see a -2, unless they specifically disagree with the 
maintainer, and insist that they are right, to the point of repeatedly 
submitting patches.

Cheers,
Dave.

-- 
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13


From emesika at redhat.com  Thu Feb 21 22:46:07 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 21 Feb 2013 17:46:07 -0500 (EST)
Subject: [Engine-devel] DB Performance Monitoring
In-Reply-To: <51265072.8040103@redhat.com>
Message-ID: <1928179669.5160574.1361486767327.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Libor Spevak" <lspevak at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: engine-devel at ovirt.org, "Yair Zaslavsky" <yzaslavs at redhat.com>, "Barak Azulay" <bazulay at redhat.com>
> Sent: Thursday, February 21, 2013 6:50:58 PM
> Subject: Re: [Engine-devel] DB Performance Monitoring
> 
> 
> On 21.2.2013 17:11, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
> 
> From: "Libor Spevak" <lspevak at redhat.com> To: engine-devel at ovirt.org
> Sent: Tuesday, February 19, 2013 5:44:10 PM
> Subject: [Engine-devel] DB Performance Monitoring
> 
> 
> Hi,
> I just wanted to share a partial result from testing of engine db
> load during operation (SQL queries frequencies). Maybe, we can
> decide later, if some SQL queries result CACHING can boost
> throughput for larger deployments.
> 
> The caching technology can be from a simple HashMap lookup to
> deployments of something like http://ehcache.org/ (memory database).
> 
> I prepared two simple scenarios:
> 
> - oVirt engine, 2 hosts, 1 VM, running 15 minutes (Power on + Up
> state)
> - oVirt engine, 2 hosts, 10 VMs from one pool, running 15 minutes
> (Power on + Up state)
> 
> Appending 2 spreadsheets with data about the most used SQL queries
> (generated by PostgreSQL standard pg_statements_stat module).
> 
> e.g.
> - 2nd row shows number of granted connections from the db pool (e.g.
> can be used to set optimal connection pool size) (check of
> connection health: select 1)
> - most of the queries are wrapped by a PLSQL function so we see a
> wrapper:
> 
> select * from getvdsgroupbyvdsgroupid($1, $2, $3)
> 
> and near to it the 'real' query:
> 
> SELECT vds_groups_view.*
> FROM vds_groups_view
> WHERE vds_group_id = v_vds_group_id
> AND (NOT v_is_filtered OR EXISTS (SELECT 1
> FROM user_vds_groups_permissions_view
> WHERE user_id = v_user_id AND entity_id = v_vds_group_id))
> 
> Just as an example, I selected in yellow color some queries, which
> probably do not change often, but are very frequent. Thanks Libor for
> taking te time to do that.
> The problematic queries are those that involves all kinds of
> *permissions* checks with the complicated & expensive permission
> handling views.
> I believe that using Snapshot Materialized Views as defined in
> http://www.ovirt.org/OVirt-DB-Issues/MaterializedViews will solve
> the major part of those problems.
> We are currently verifying this approach and my recommendation is to
> have all *permissions* views as Snapshot Materialized Views that are
> updated via a cron job. I think there could be performace
> improvement with M-views, of course. There is some overhead just
> with their maintainance, e.g. refreshing, updating existing
> dependent objects (table name renames, ...),

Refresh of *permission* views was tested with 2 views 160,000 records each and was about 2 sec

> not sure about NATIVE
> implementation level status in PostgreSQL, according to e.g. Oracle
> db capabilities (MV-logs + M-views).
> 
> http://wiki.postgresql.org/wiki/Materialized_Views

AFAIK Postgres is not going to implement that in the near future

> 
> Still, if the Engine gathers statistics nearly in real time, my
> question would be, if there is a need of round-trip to the database
> and back at all for frequent queries.

Depends what is the cost of this round-trip , if it is very cheep as I showed when I tested M-Views I think that DB query is still a good and natural choice

> 
> 
> 
> 
> 
> 
> Other tools like 'pg_top' can provide runtime statistics of db
> processes (cpu, mem, locks, ... views).
> 
> By enabling debug level logging of PostgreSQL we can check real
> values to the queries.
> 
> Of course, it would be useful to run such tests with many hosts and
> VMs to predict scaling issues.
> 
> More info about tools configuration:
> http://www.ovirt.org/Engine_database_performance_monitoring Regards,
> Libor
> 
> _______________________________________________
> Engine-devel mailing list Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From emesika at redhat.com  Thu Feb 21 22:53:10 2013
From: emesika at redhat.com (Eli Mesika)
Date: Thu, 21 Feb 2013 17:53:10 -0500 (EST)
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <51268FF1.70002@redhat.com>
Message-ID: <1761070827.5161544.1361487190442.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Dave Neary" <dneary at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, February 21, 2013 11:21:53 PM
> Subject: Re: [Engine-devel] Changing Gerrit -1 message
> 
> Hi,
> 
> On 02/20/2013 10:32 AM, Itamar Heim wrote:
> > On 19/02/2013 12:06, Laszlo Hornyak wrote:
> >> Hi,
> >>
> >> I agree with that.
> >>
> >> for the - messages this in my opinion would be both more clear and
> >> friendly:
> >> -1: In my opinion it needs work.
> >
> >
> > how about
> > "-1: Please review my comments"

+1

> 
> Sounds great.
> 
> >> -2: I disagree.

I prefer -2 : Do not submit!

IMHO:
-1 should be used whenever the code is OK but can be done better or has a missing part (tests for example)
-2 should be used when the code does not work, has a serious bug (possible NPE for example) , break the build

> >
> > "-2: Please reconsider"
> 
> I am trying to think under which circumstances people give a -2.
> Maybe
> something like "We have discussed this feature, and I disagree that
> it
> is good for the project." Basically, I don't think that a developer
> should ever see a -2, unless they specifically disagree with the
> maintainer, and insist that they are right, to the point of
> repeatedly
> submitting patches.
> 
> Cheers,
> Dave.
> 
> --
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From masayag at redhat.com  Fri Feb 22 07:02:08 2013
From: masayag at redhat.com (Moti Asayag)
Date: Fri, 22 Feb 2013 09:02:08 +0200
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <1761070827.5161544.1361487190442.JavaMail.root@redhat.com>
References: <1761070827.5161544.1361487190442.JavaMail.root@redhat.com>
Message-ID: <512717F0.70809@redhat.com>

On 02/22/2013 12:53 AM, Eli Mesika wrote:
> 
> 
> ----- Original Message -----
>> From: "Dave Neary" <dneary at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Thursday, February 21, 2013 11:21:53 PM
>> Subject: Re: [Engine-devel] Changing Gerrit -1 message
>>
>> Hi,
>>
>> On 02/20/2013 10:32 AM, Itamar Heim wrote:
>>> On 19/02/2013 12:06, Laszlo Hornyak wrote:
>>>> Hi,
>>>>
>>>> I agree with that.
>>>>
>>>> for the - messages this in my opinion would be both more clear and
>>>> friendly:
>>>> -1: In my opinion it needs work.
>>>
>>>
>>> how about
>>> "-1: Please review my comments"
> 
> +1

+1

> 
>>
>> Sounds great.
>>
>>>> -2: I disagree.
> 
> I prefer -2 : Do not submit!
> 
> IMHO:
> -1 should be used whenever the code is OK but can be done better or has a missing part (tests for example)
> -2 should be used when the code does not work, has a serious bug (possible NPE for example) , break the build

+1 for the -2 which to my opinion should indicate any serious flaw in
the design, even post the design discussion. I think that this should
follow with a discussion on engine-devel about the required change in
the design instead of debating over the gerrit since it is not
transparent enough.

> 
>>>
>>> "-2: Please reconsider"
>>
>> I am trying to think under which circumstances people give a -2.
>> Maybe
>> something like "We have discussed this feature, and I disagree that
>> it
>> is good for the project." Basically, I don't think that a developer
>> should ever see a -2, unless they specifically disagree with the
>> maintainer, and insist that they are right, to the point of
>> repeatedly
>> submitting patches.
>>
>> Cheers,
>> Dave.
>>
>> --
>> Dave Neary - Community Action and Impact
>> Open Source and Standards, Red Hat - http://community.redhat.com
>> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



From lspevak at redhat.com  Fri Feb 22 08:02:55 2013
From: lspevak at redhat.com (Libor Spevak)
Date: Fri, 22 Feb 2013 09:02:55 +0100
Subject: [Engine-devel] DB Schema Reports
Message-ID: <5127262F.5030503@redhat.com>

Hi,

let me announce new database schema reports based on the SchemaSpy Java 
library available.

Thanks to infra group for support, especially to David Caro, who set up 
Mr. Jenkins's jobs.

oVirt-Engine:
http://resources.ovirt.org/dbreports/latest/engine/public/index.html
oVirt-DWH:
http://resources.ovirt.org/dbreports/latest/dwh/public/index.html

Wiki:
http://www.ovirt.org/DB_model

Regards,
Libor


From emesika at redhat.com  Fri Feb 22 11:05:01 2013
From: emesika at redhat.com (Eli Mesika)
Date: Fri, 22 Feb 2013 06:05:01 -0500 (EST)
Subject: [Engine-devel] DB Schema Reports
In-Reply-To: <5127262F.5030503@redhat.com>
Message-ID: <1323890930.5311834.1361531101734.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Libor Spevak" <lspevak at redhat.com>
> To: engine-devel at ovirt.org, rhev-devel at redhat.com, infra at ovirt.org
> Sent: Friday, February 22, 2013 10:02:55 AM
> Subject: DB Schema Reports
> 
> Hi,
> 
> let me announce new database schema reports based on the SchemaSpy
> Java
> library available.
> 
> Thanks to infra group for support, especially to David Caro, who set
> up
> Mr. Jenkins's jobs.

Great job !
> 
> oVirt-Engine:
> http://resources.ovirt.org/dbreports/latest/engine/public/index.html
> oVirt-DWH:
> http://resources.ovirt.org/dbreports/latest/dwh/public/index.html
> 
> Wiki:
> http://www.ovirt.org/DB_model
> 
> Regards,
> Libor
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 


From gpadgett at redhat.com  Fri Feb 22 13:35:32 2013
From: gpadgett at redhat.com (Greg Padgett)
Date: Fri, 22 Feb 2013 08:35:32 -0500
Subject: [Engine-devel] DB Schema Reports
In-Reply-To: <1323890930.5311834.1361531101734.JavaMail.root@redhat.com>
References: <1323890930.5311834.1361531101734.JavaMail.root@redhat.com>
Message-ID: <51277424.2020307@redhat.com>

On 02/22/2013 06:05 AM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Libor Spevak" <lspevak at redhat.com>
>> To: engine-devel at ovirt.org, rhev-devel at redhat.com, infra at ovirt.org
>> Sent: Friday, February 22, 2013 10:02:55 AM
>> Subject: DB Schema Reports
>>
>> Hi,
>>
>> let me announce new database schema reports based on the SchemaSpy
>> Java
>> library available.
>>
>> Thanks to infra group for support, especially to David Caro, who set
>> up
>> Mr. Jenkins's jobs.
>
> Great job !

+1, this will be very useful!

Eli, is the great diagram you sent out in early December on the wiki as 
well?  We should add a link to it from the wiki page below.

>>
>> oVirt-Engine:
>> http://resources.ovirt.org/dbreports/latest/engine/public/index.html
>> oVirt-DWH:
>> http://resources.ovirt.org/dbreports/latest/dwh/public/index.html
>>
>> Wiki:
>> http://www.ovirt.org/DB_model
>>
>> Regards,
>> Libor
>> _______________________________________________
>> Infra mailing list
>> Infra at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>>
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>



From ovedo at redhat.com  Sun Feb 24 07:05:58 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 24 Feb 2013 02:05:58 -0500 (EST)
Subject: [Engine-devel] REST API calls from
In-Reply-To: <1559481678.7174578.1361465699455.JavaMail.root@redhat.com>
Message-ID: <2047387558.6944288.1361689558181.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>
> Cc: engine-devel at ovirt.org, arch at ovirt.org
> Sent: Thursday, February 21, 2013 6:54:59 PM
> Subject: Re: [Engine-devel] REST API calls from
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Pasternak" <mpastern at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: engine-devel at ovirt.org, arch at ovirt.org
> > Sent: Wednesday, February 20, 2013 2:56:59 PM
> > Subject: Re: [Engine-devel] REST API calls from
> > 
> > On 02/14/2013 11:20 AM, Doron Fediuck wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Michael Pasternak" <mpastern at redhat.com>
> > >> To: "Libor Spevak" <lspevak at redhat.com>
> > >> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > >> Sent: Wednesday, February 13, 2013 12:55:36 PM
> > >> Subject: Re: [Engine-devel] REST API calls from the GUI
> > >>
> > >>
> > >> Hi Libor,
> > >>
> > >> This issue came across in one of the conversations i had with UX
> > >> folks, but since we didn't end
> > >> up with any conclusion/road map (nor discussed it properly to
> > >> hear
> > >> other thoughts), this is a perfect
> > >> place to start this discussion,
> > >>
> > >> Intuitively REST is a way to go with GWT AJAX calls
> > >> ---------------------------------------------------
> > >>
> > >> pros
> > >> ====
> > >>
> > >> - api data objects can be reused by generating java classes
> > >> (using
> > >> jaxb) from the rest schema [1]
> > >> - no backend logic will be duplicated as api abstracts the
> > >> backend
> > >> exposing RESTful collection/resources to operate on
> > >> - development against api is "easy" as api describes itself in
> > >> RSDL
> > >> [2]
> > >>
> > >> cons
> > >> ====
> > >>
> > >> - implementing transport layer (HTTP) under GWT
> > >> - implementing own j2xml/json/yaml/... marshalling layer
> > >> - implementing own error handling mechanism
> > >> - implementing REST callback mechanism (in GWT)
> > >> - constant maintenance of the data objects generated from the
> > >> api
> > >> - painful for Java developers
> > >>
> > >> Java-SDK
> > >> --------
> > >>
> > >> pros
> > >> ====
> > >>
> > >> - abstracts transport layer (leaving developer in standard Java
> > >> api)
> > >> - typesafe code (no need to mess with XML bulks)
> > >> - has own data objects to work with
> > >> - abstracts authentication/authorization
> > >> (kerberos/cookie/session/etc.)
> > >> - since SDK is auto-generated, it can be easily extended with
> > >> required
> > >>   features to support UI (such as callback infrastructure for
> > >>   instance)
> > >>
> > >> cons
> > >> ====
> > >>
> > >> - has to be converted in to Javascript (not sure what the
> > >> impacts
> > >> are
> > >> in terms of AJAX calls/etc.)
> > >> - probably much more cons that we're not aware of and will have
> > >> to
> > >> figure out with POC
> > >>
> > >>
> > >> thoughts?
> > >>
> > >> [1] http[s]://server[:port]/api?schema
> > >> [2] http[s]://server[:port]/api?rsdl
> > >>
> > > 
> > > Although started as a UI request, there are other needs who wish
> > > to use API calls with a different transport. For example a
> > > backend
> > > hook which gets a REST entry point it can use to fetch for
> > > additional
> > > data, or perform actions. In this case I'd expect an internal
> > > connection
> > > rather than creating additional connections.
> > > How would you resolve it generically enough in this context?
> > 
> > Doron,
> > 
> > I believe your approach a bit different, UX folks seeking for a
> > convenient
> > way of communicating with ovirt public api, e.g closing api<->GUI
> > gap, and
> > theirs alternatives where native HTTP layer or Java-SDK based
> > framework,
> > while what you need is in-process channel to communicate with the
> > engine itself,
> > 
> > i understanding your will of using stable api for this (RESTapi),
> > but
> > not
> > sure that doing this via JavaSDK is a good way to go simply because
> > SDK is
> > designed to operate in a client-space, while what you need is a
> > server-space
> > bridge for that.
> > 
> 
> Michael, true but...
> Thinking about it differently both UI and hooks needs a client.
> The underlying protocols should be abstracted. This is something
> which will serve other functions as well.
> 

I'm not sure we would need a new abstraction here.
Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine.
In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations.
I think we should probably do the same for engine plugins, giving the basic API, and giving a REST session for more advanced operations.
The engine plugin may also have another 3rd party application it interacts with, and it would be able to share this session with it, allowing it to perform different operations on the engine. It would obviously be easy to do that using the Java SDK in the engine side, without creating a new layer of abstraction. I assume the 3rd party application will use either the Java SDK, or another one, according the platform it is built upon, and in the "worst case", will interact directly with the API.


> > > 
> > >> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> > >>> Hi,
> > >>>
> > >>> I would like to ask, if there have been discussions about an
> > >>> option
> > >>> to call REST API services directly from the Frontend (GWT
> > >>> layer)?
> > >>> GWT compiles Java frontend-side to
> > >>> Javascript, calls to backend services are performed
> > >>> "transparently"
> > >>> by the framework using AJAX support. But, there is still a need
> > >>> to
> > >>> have a special set of data objects
> > >>> and the server-side logic can duplicate.
> > >>>
> > >>> Java REST API SDK enables to build "thick" client. The calls
> > >>> are
> > >>> realized using e.g. Apache HttClient and supported libraries. I
> > >>> think the requirements of GWT can be a
> > >>> little bit different, but something overlaps.
> > >>>
> > >>> I found several links about REST API support from GWT, so there
> > >>> is
> > >>> something for inspiration...
> > >>>
> > >>> - http://www.spiffyui.org/
> > >>> - http://www.zackgrossbart.com/hackito/gwt-rest/
> > >>> - http://code.google.com/p/gwt-rest/
> > >>> - http://restygwt.fusesource.org/
> > >>>
> > >>> But, do you think it would be useful and what drawbacks can
> > >>> occur
> > >>> (authentication, authorization, response times, need to support
> > >>> larger set of services, painful
> > >>> refactoring, ...)?
> > >>>
> > >>> Regards,
> > >>> Libor
> > >>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Sun Feb 24 07:47:28 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 24 Feb 2013 09:47:28 +0200
Subject: [Engine-devel] REST API calls from
In-Reply-To: <2047387558.6944288.1361689558181.JavaMail.root@redhat.com>
References: <2047387558.6944288.1361689558181.JavaMail.root@redhat.com>
Message-ID: <5129C590.6010808@redhat.com>

On 02/24/2013 09:05 AM, Oved Ourfalli wrote:
> 
> 
> ----- Original Message -----
>> From: "Doron Fediuck" <dfediuck at redhat.com>
>> To: "Michael Pasternak" <mpastern at redhat.com>
>> Cc: engine-devel at ovirt.org, arch at ovirt.org
>> Sent: Thursday, February 21, 2013 6:54:59 PM
>> Subject: Re: [Engine-devel] REST API calls from
>>
>>
>>
>> ----- Original Message -----
>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>> Cc: engine-devel at ovirt.org, arch at ovirt.org
>>> Sent: Wednesday, February 20, 2013 2:56:59 PM
>>> Subject: Re: [Engine-devel] REST API calls from
>>>
>>> On 02/14/2013 11:20 AM, Doron Fediuck wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>> To: "Libor Spevak" <lspevak at redhat.com>
>>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org
>>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM
>>>>> Subject: Re: [Engine-devel] REST API calls from the GUI
>>>>>
>>>>>
>>>>> Hi Libor,
>>>>>
>>>>> This issue came across in one of the conversations i had with UX
>>>>> folks, but since we didn't end
>>>>> up with any conclusion/road map (nor discussed it properly to
>>>>> hear
>>>>> other thoughts), this is a perfect
>>>>> place to start this discussion,
>>>>>
>>>>> Intuitively REST is a way to go with GWT AJAX calls
>>>>> ---------------------------------------------------
>>>>>
>>>>> pros
>>>>> ====
>>>>>
>>>>> - api data objects can be reused by generating java classes
>>>>> (using
>>>>> jaxb) from the rest schema [1]
>>>>> - no backend logic will be duplicated as api abstracts the
>>>>> backend
>>>>> exposing RESTful collection/resources to operate on
>>>>> - development against api is "easy" as api describes itself in
>>>>> RSDL
>>>>> [2]
>>>>>
>>>>> cons
>>>>> ====
>>>>>
>>>>> - implementing transport layer (HTTP) under GWT
>>>>> - implementing own j2xml/json/yaml/... marshalling layer
>>>>> - implementing own error handling mechanism
>>>>> - implementing REST callback mechanism (in GWT)
>>>>> - constant maintenance of the data objects generated from the
>>>>> api
>>>>> - painful for Java developers
>>>>>
>>>>> Java-SDK
>>>>> --------
>>>>>
>>>>> pros
>>>>> ====
>>>>>
>>>>> - abstracts transport layer (leaving developer in standard Java
>>>>> api)
>>>>> - typesafe code (no need to mess with XML bulks)
>>>>> - has own data objects to work with
>>>>> - abstracts authentication/authorization
>>>>> (kerberos/cookie/session/etc.)
>>>>> - since SDK is auto-generated, it can be easily extended with
>>>>> required
>>>>>   features to support UI (such as callback infrastructure for
>>>>>   instance)
>>>>>
>>>>> cons
>>>>> ====
>>>>>
>>>>> - has to be converted in to Javascript (not sure what the
>>>>> impacts
>>>>> are
>>>>> in terms of AJAX calls/etc.)
>>>>> - probably much more cons that we're not aware of and will have
>>>>> to
>>>>> figure out with POC
>>>>>
>>>>>
>>>>> thoughts?
>>>>>
>>>>> [1] http[s]://server[:port]/api?schema
>>>>> [2] http[s]://server[:port]/api?rsdl
>>>>>
>>>>
>>>> Although started as a UI request, there are other needs who wish
>>>> to use API calls with a different transport. For example a
>>>> backend
>>>> hook which gets a REST entry point it can use to fetch for
>>>> additional
>>>> data, or perform actions. In this case I'd expect an internal
>>>> connection
>>>> rather than creating additional connections.
>>>> How would you resolve it generically enough in this context?
>>>
>>> Doron,
>>>
>>> I believe your approach a bit different, UX folks seeking for a
>>> convenient
>>> way of communicating with ovirt public api, e.g closing api<->GUI
>>> gap, and
>>> theirs alternatives where native HTTP layer or Java-SDK based
>>> framework,
>>> while what you need is in-process channel to communicate with the
>>> engine itself,
>>>
>>> i understanding your will of using stable api for this (RESTapi),
>>> but
>>> not
>>> sure that doing this via JavaSDK is a good way to go simply because
>>> SDK is
>>> designed to operate in a client-space, while what you need is a
>>> server-space
>>> bridge for that.
>>>
>>
>> Michael, true but...
>> Thinking about it differently both UI and hooks needs a client.
>> The underlying protocols should be abstracted. This is something
>> which will serve other functions as well.
>>
> 
> I'm not sure we would need a new abstraction here.
> Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine.

+1, that's exactly what i've suggested to begin with.

> In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations.
> I think we should probably do the same for engine plugins, 
> giving the basic API, and giving a REST session for more advanced operations.
> The engine plugin may also have another 3rd party application it interacts with, and it would be able to share this session with it, 
> allowing it to perform different operations on the engine. It would obviously be easy to do that using the Java SDK in the engine side,
> without creating a new layer of abstraction.

true, but the thing is that java-sdk designed to work with rest-api, and what Doron is trying to do
is saving round-trip of engine->sdk->api->engine by enabling extra layer in sdk that will work not via HTTP,
but natively with RESTeasy (REST framework we using in api), the disadvantages of such design are:

1. working with java-sdk via JNI (walking out from container to client application - sdk)
2. hacking RESTeasy by:
   2.1 working with underlying (not public/backward compatible) interfaces & using JNI as well
   2.2 most likely maintaining code working with RESTeasy on every new (RESTeasy) release by reverse
       engineering new changes/behaviour of this framework
   2.3 making assumptions on code invocations to emulate GET/POST/PUT/DELETE HTTP calls
   2.4 still having round-trip engine->sdk->RESTeasy->engine

therefore i think that having own private API in engine for that is a much better solution.

> I assume the 3rd party application will use either the Java SDK, or another one, according the platform it is built upon, and in the "worst case", will interact directly with the API.
> 
> 
>>>>
>>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I would like to ask, if there have been discussions about an
>>>>>> option
>>>>>> to call REST API services directly from the Frontend (GWT
>>>>>> layer)?
>>>>>> GWT compiles Java frontend-side to
>>>>>> Javascript, calls to backend services are performed
>>>>>> "transparently"
>>>>>> by the framework using AJAX support. But, there is still a need
>>>>>> to
>>>>>> have a special set of data objects
>>>>>> and the server-side logic can duplicate.
>>>>>>
>>>>>> Java REST API SDK enables to build "thick" client. The calls
>>>>>> are
>>>>>> realized using e.g. Apache HttClient and supported libraries. I
>>>>>> think the requirements of GWT can be a
>>>>>> little bit different, but something overlaps.
>>>>>>
>>>>>> I found several links about REST API support from GWT, so there
>>>>>> is
>>>>>> something for inspiration...
>>>>>>
>>>>>> - http://www.spiffyui.org/
>>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
>>>>>> - http://code.google.com/p/gwt-rest/
>>>>>> - http://restygwt.fusesource.org/
>>>>>>
>>>>>> But, do you think it would be useful and what drawbacks can
>>>>>> occur
>>>>>> (authentication, authorization, response times, need to support
>>>>>> larger set of services, painful
>>>>>> refactoring, ...)?
>>>>>>
>>>>>> Regards,
>>>>>> Libor
>>>>>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mpastern at redhat.com  Sun Feb 24 08:05:13 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 24 Feb 2013 10:05:13 +0200
Subject: [Engine-devel] REST API calls from the GUI
In-Reply-To: <960012516.4950999.1361453420281.JavaMail.root@redhat.com>
References: <960012516.4950999.1361453420281.JavaMail.root@redhat.com>
Message-ID: <5129C9B9.8080707@redhat.com>

On 02/21/2013 03:30 PM, Vojtech Szocs wrote:
> Hi guys,
> 
>>>>>> >>> > > We can't directly use the restapi models in the client side, as
>>>>>> >>> > > they have lot of xml and annotations stuff involved which will not
>>>>>> >>> > > be compatible with GWT.
>>>> >> > 
>>>> >> > why? they only have jaxb annotations which are 'must' for
>>>> >> > serialization & talking with api.
> Actually, we *can* use JAXB-generated REST API Java types with GWT, since GWT compiler simply ignores annotations in Java sources during compilation to JavaScript.
> 
> The only problem I see is REST API Java types using stuff like javax.xml.datatype.XMLGregorianCalendar - we'd have to emulate it in GWT (shouldn't be an issue).
> 
> Other than that, I'd recommend using JAXB-generated REST API Java types, as they always match current REST API schema (api.xsd).
> 
> As for the marshalling layer, we can't use JAXB (REST API Java SDK) with GWT, but we can still write deferred binding generator to generate mappers for XML <--> Rest API Java type conversion.
> 
>> > if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML
>> > as they are defined in the api schema and not using Java naming convention (as XJC does),
> Yeah, with XML representation we would have to do this ourselves.
> 
> On the other hand, things would be much simpler if REST API supported JSON, which is something we should consider (wait for JSON support? work with XML?)

not sure we will support JSON in near future as we're blocked by underlying provider.

> 
>>>>>> >>> > > It would be better if We can come up with a "GWT REST API SDK",
>>>>>> >>> > > which is analogous Java SDK.
> I'd rather have JavaScript REST API SDK which we could use with GWT, this would open up new possibilities for web clients.
> 
> Vojtech


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From dfediuck at redhat.com  Sun Feb 24 11:20:12 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 24 Feb 2013 06:20:12 -0500 (EST)
Subject: [Engine-devel] REST API calls from
In-Reply-To: <5129C590.6010808@redhat.com>
Message-ID: <1947542298.8405100.1361704812489.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org, arch at ovirt.org
> Sent: Sunday, February 24, 2013 9:47:28 AM
> Subject: Re: [Engine-devel] REST API calls from
> 
> On 02/24/2013 09:05 AM, Oved Ourfalli wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Doron Fediuck" <dfediuck at redhat.com>
> >> To: "Michael Pasternak" <mpastern at redhat.com>
> >> Cc: engine-devel at ovirt.org, arch at ovirt.org
> >> Sent: Thursday, February 21, 2013 6:54:59 PM
> >> Subject: Re: [Engine-devel] REST API calls from
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>> To: "Doron Fediuck" <dfediuck at redhat.com>
> >>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> >>> Sent: Wednesday, February 20, 2013 2:56:59 PM
> >>> Subject: Re: [Engine-devel] REST API calls from
> >>>
> >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>>> To: "Libor Spevak" <lspevak at redhat.com>
> >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM
> >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI
> >>>>>
> >>>>>
> >>>>> Hi Libor,
> >>>>>
> >>>>> This issue came across in one of the conversations i had with
> >>>>> UX
> >>>>> folks, but since we didn't end
> >>>>> up with any conclusion/road map (nor discussed it properly to
> >>>>> hear
> >>>>> other thoughts), this is a perfect
> >>>>> place to start this discussion,
> >>>>>
> >>>>> Intuitively REST is a way to go with GWT AJAX calls
> >>>>> ---------------------------------------------------
> >>>>>
> >>>>> pros
> >>>>> ====
> >>>>>
> >>>>> - api data objects can be reused by generating java classes
> >>>>> (using
> >>>>> jaxb) from the rest schema [1]
> >>>>> - no backend logic will be duplicated as api abstracts the
> >>>>> backend
> >>>>> exposing RESTful collection/resources to operate on
> >>>>> - development against api is "easy" as api describes itself in
> >>>>> RSDL
> >>>>> [2]
> >>>>>
> >>>>> cons
> >>>>> ====
> >>>>>
> >>>>> - implementing transport layer (HTTP) under GWT
> >>>>> - implementing own j2xml/json/yaml/... marshalling layer
> >>>>> - implementing own error handling mechanism
> >>>>> - implementing REST callback mechanism (in GWT)
> >>>>> - constant maintenance of the data objects generated from the
> >>>>> api
> >>>>> - painful for Java developers
> >>>>>
> >>>>> Java-SDK
> >>>>> --------
> >>>>>
> >>>>> pros
> >>>>> ====
> >>>>>
> >>>>> - abstracts transport layer (leaving developer in standard Java
> >>>>> api)
> >>>>> - typesafe code (no need to mess with XML bulks)
> >>>>> - has own data objects to work with
> >>>>> - abstracts authentication/authorization
> >>>>> (kerberos/cookie/session/etc.)
> >>>>> - since SDK is auto-generated, it can be easily extended with
> >>>>> required
> >>>>>   features to support UI (such as callback infrastructure for
> >>>>>   instance)
> >>>>>
> >>>>> cons
> >>>>> ====
> >>>>>
> >>>>> - has to be converted in to Javascript (not sure what the
> >>>>> impacts
> >>>>> are
> >>>>> in terms of AJAX calls/etc.)
> >>>>> - probably much more cons that we're not aware of and will have
> >>>>> to
> >>>>> figure out with POC
> >>>>>
> >>>>>
> >>>>> thoughts?
> >>>>>
> >>>>> [1] http[s]://server[:port]/api?schema
> >>>>> [2] http[s]://server[:port]/api?rsdl
> >>>>>
> >>>>
> >>>> Although started as a UI request, there are other needs who wish
> >>>> to use API calls with a different transport. For example a
> >>>> backend
> >>>> hook which gets a REST entry point it can use to fetch for
> >>>> additional
> >>>> data, or perform actions. In this case I'd expect an internal
> >>>> connection
> >>>> rather than creating additional connections.
> >>>> How would you resolve it generically enough in this context?
> >>>
> >>> Doron,
> >>>
> >>> I believe your approach a bit different, UX folks seeking for a
> >>> convenient
> >>> way of communicating with ovirt public api, e.g closing api<->GUI
> >>> gap, and
> >>> theirs alternatives where native HTTP layer or Java-SDK based
> >>> framework,
> >>> while what you need is in-process channel to communicate with the
> >>> engine itself,
> >>>
> >>> i understanding your will of using stable api for this (RESTapi),
> >>> but
> >>> not
> >>> sure that doing this via JavaSDK is a good way to go simply
> >>> because
> >>> SDK is
> >>> designed to operate in a client-space, while what you need is a
> >>> server-space
> >>> bridge for that.
> >>>
> >>
> >> Michael, true but...
> >> Thinking about it differently both UI and hooks needs a client.
> >> The underlying protocols should be abstracted. This is something
> >> which will serve other functions as well.
> >>
> > 
> > I'm not sure we would need a new abstraction here.
> > Both UI plugins and engine plugins need some API to do basic
> > operations, and have access to different properties in the engine.
> 
> +1, that's exactly what i've suggested to begin with.
> 

The only issue is that UI plugins and engine plugins shave different expectations
from performance point of view. If UI is willing to wait for a refresh that may
take too long for engine plugins, which would prefer to get the information as
soon as possible without going into various communication layers which are not
always needed. So again- a simple solution which enables transports layers to
be replaced may serve more than one functionality in a better way.

> > In the UI plguins implementation, we gave this API, and in addition
> > created a REST session to be used in order to do more
> > sophisticated operations.
> > I think we should probably do the same for engine plugins,
> > giving the basic API, and giving a REST session for more advanced
> > operations.
> > The engine plugin may also have another 3rd party application it
> > interacts with, and it would be able to share this session with
> > it,
> > allowing it to perform different operations on the engine. It would
> > obviously be easy to do that using the Java SDK in the engine
> > side,
> > without creating a new layer of abstraction.
> 
> true, but the thing is that java-sdk designed to work with rest-api,
> and what Doron is trying to do
> is saving round-trip of engine->sdk->api->engine by enabling extra
> layer in sdk that will work not via HTTP,
> but natively with RESTeasy (REST framework we using in api), the
> disadvantages of such design are:
> 
> 1. working with java-sdk via JNI (walking out from container to
> client application - sdk)
> 2. hacking RESTeasy by:
>    2.1 working with underlying (not public/backward compatible)
>    interfaces & using JNI as well
>    2.2 most likely maintaining code working with RESTeasy on every
>    new (RESTeasy) release by reverse
>        engineering new changes/behaviour of this framework
>    2.3 making assumptions on code invocations to emulate
>    GET/POST/PUT/DELETE HTTP calls
>    2.4 still having round-trip engine->sdk->RESTeasy->engine
> 
> therefore i think that having own private API in engine for that is a
> much better solution.
> 
> > I assume the 3rd party application will use either the Java SDK, or
> > another one, according the platform it is built upon, and in the
> > "worst case", will interact directly with the API.
> > 
> > 
> >>>>
> >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I would like to ask, if there have been discussions about an
> >>>>>> option
> >>>>>> to call REST API services directly from the Frontend (GWT
> >>>>>> layer)?
> >>>>>> GWT compiles Java frontend-side to
> >>>>>> Javascript, calls to backend services are performed
> >>>>>> "transparently"
> >>>>>> by the framework using AJAX support. But, there is still a
> >>>>>> need
> >>>>>> to
> >>>>>> have a special set of data objects
> >>>>>> and the server-side logic can duplicate.
> >>>>>>
> >>>>>> Java REST API SDK enables to build "thick" client. The calls
> >>>>>> are
> >>>>>> realized using e.g. Apache HttClient and supported libraries.
> >>>>>> I
> >>>>>> think the requirements of GWT can be a
> >>>>>> little bit different, but something overlaps.
> >>>>>>
> >>>>>> I found several links about REST API support from GWT, so
> >>>>>> there
> >>>>>> is
> >>>>>> something for inspiration...
> >>>>>>
> >>>>>> - http://www.spiffyui.org/
> >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
> >>>>>> - http://code.google.com/p/gwt-rest/
> >>>>>> - http://restygwt.fusesource.org/
> >>>>>>
> >>>>>> But, do you think it would be useful and what drawbacks can
> >>>>>> occur
> >>>>>> (authentication, authorization, response times, need to
> >>>>>> support
> >>>>>> larger set of services, painful
> >>>>>> refactoring, ...)?
> >>>>>>
> >>>>>> Regards,
> >>>>>> Libor
> >>>>>>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ydary at redhat.com  Sun Feb 24 11:27:27 2013
From: ydary at redhat.com (Yaniv Dary)
Date: Sun, 24 Feb 2013 06:27:27 -0500 (EST)
Subject: [Engine-devel] DB Schema Reports
In-Reply-To: <1323890930.5311834.1361531101734.JavaMail.root@redhat.com>
Message-ID: <645186570.5135813.1361705247806.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Libor Spevak" <lspevak at redhat.com>
> Cc: engine-devel at ovirt.org, rhev-devel at redhat.com, infra at ovirt.org
> Sent: Friday, February 22, 2013 1:05:01 PM
> Subject: Re: [Engine-devel] DB Schema Reports
> 
> 
> 
> ----- Original Message -----
> > From: "Libor Spevak" <lspevak at redhat.com>
> > To: engine-devel at ovirt.org, rhev-devel at redhat.com, infra at ovirt.org
> > Sent: Friday, February 22, 2013 10:02:55 AM
> > Subject: DB Schema Reports
> > 
> > Hi,
> > 
> > let me announce new database schema reports based on the SchemaSpy
> > Java
> > library available.
> > 
> > Thanks to infra group for support, especially to David Caro, who
> > set
> > up
> > Mr. Jenkins's jobs.
> 
> Great job ! 

+1

> > 
> > oVirt-Engine:
> > http://resources.ovirt.org/dbreports/latest/engine/public/index.html
> > oVirt-DWH:
> > http://resources.ovirt.org/dbreports/latest/dwh/public/index.html
> > 
> > Wiki:
> > http://www.ovirt.org/DB_model
> > 
> > Regards,
> > Libor
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From ovedo at redhat.com  Sun Feb 24 13:01:19 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 24 Feb 2013 08:01:19 -0500 (EST)
Subject: [Engine-devel] REST API calls from
In-Reply-To: <1947542298.8405100.1361704812489.JavaMail.root@redhat.com>
Message-ID: <132421718.6971303.1361710879301.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Michael Pasternak" <mpastern at redhat.com>
> Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org, arch at ovirt.org
> Sent: Sunday, February 24, 2013 1:20:12 PM
> Subject: Re: [Engine-devel] REST API calls from
> 
> 
> 
> ----- Original Message -----
> > From: "Michael Pasternak" <mpastern at redhat.com>
> > To: "Oved Ourfalli" <ovedo at redhat.com>
> > Cc: engine-devel at ovirt.org, arch at ovirt.org
> > Sent: Sunday, February 24, 2013 9:47:28 AM
> > Subject: Re: [Engine-devel] REST API calls from
> > 
> > On 02/24/2013 09:05 AM, Oved Ourfalli wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > >> From: "Doron Fediuck" <dfediuck at redhat.com>
> > >> To: "Michael Pasternak" <mpastern at redhat.com>
> > >> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > >> Sent: Thursday, February 21, 2013 6:54:59 PM
> > >> Subject: Re: [Engine-devel] REST API calls from
> > >>
> > >>
> > >>
> > >> ----- Original Message -----
> > >>> From: "Michael Pasternak" <mpastern at redhat.com>
> > >>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM
> > >>> Subject: Re: [Engine-devel] REST API calls from
> > >>>
> > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote:
> > >>>>
> > >>>>
> > >>>> ----- Original Message -----
> > >>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> > >>>>> To: "Libor Spevak" <lspevak at redhat.com>
> > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM
> > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI
> > >>>>>
> > >>>>>
> > >>>>> Hi Libor,
> > >>>>>
> > >>>>> This issue came across in one of the conversations i had with
> > >>>>> UX
> > >>>>> folks, but since we didn't end
> > >>>>> up with any conclusion/road map (nor discussed it properly to
> > >>>>> hear
> > >>>>> other thoughts), this is a perfect
> > >>>>> place to start this discussion,
> > >>>>>
> > >>>>> Intuitively REST is a way to go with GWT AJAX calls
> > >>>>> ---------------------------------------------------
> > >>>>>
> > >>>>> pros
> > >>>>> ====
> > >>>>>
> > >>>>> - api data objects can be reused by generating java classes
> > >>>>> (using
> > >>>>> jaxb) from the rest schema [1]
> > >>>>> - no backend logic will be duplicated as api abstracts the
> > >>>>> backend
> > >>>>> exposing RESTful collection/resources to operate on
> > >>>>> - development against api is "easy" as api describes itself
> > >>>>> in
> > >>>>> RSDL
> > >>>>> [2]
> > >>>>>
> > >>>>> cons
> > >>>>> ====
> > >>>>>
> > >>>>> - implementing transport layer (HTTP) under GWT
> > >>>>> - implementing own j2xml/json/yaml/... marshalling layer
> > >>>>> - implementing own error handling mechanism
> > >>>>> - implementing REST callback mechanism (in GWT)
> > >>>>> - constant maintenance of the data objects generated from the
> > >>>>> api
> > >>>>> - painful for Java developers
> > >>>>>
> > >>>>> Java-SDK
> > >>>>> --------
> > >>>>>
> > >>>>> pros
> > >>>>> ====
> > >>>>>
> > >>>>> - abstracts transport layer (leaving developer in standard
> > >>>>> Java
> > >>>>> api)
> > >>>>> - typesafe code (no need to mess with XML bulks)
> > >>>>> - has own data objects to work with
> > >>>>> - abstracts authentication/authorization
> > >>>>> (kerberos/cookie/session/etc.)
> > >>>>> - since SDK is auto-generated, it can be easily extended with
> > >>>>> required
> > >>>>>   features to support UI (such as callback infrastructure for
> > >>>>>   instance)
> > >>>>>
> > >>>>> cons
> > >>>>> ====
> > >>>>>
> > >>>>> - has to be converted in to Javascript (not sure what the
> > >>>>> impacts
> > >>>>> are
> > >>>>> in terms of AJAX calls/etc.)
> > >>>>> - probably much more cons that we're not aware of and will
> > >>>>> have
> > >>>>> to
> > >>>>> figure out with POC
> > >>>>>
> > >>>>>
> > >>>>> thoughts?
> > >>>>>
> > >>>>> [1] http[s]://server[:port]/api?schema
> > >>>>> [2] http[s]://server[:port]/api?rsdl
> > >>>>>
> > >>>>
> > >>>> Although started as a UI request, there are other needs who
> > >>>> wish
> > >>>> to use API calls with a different transport. For example a
> > >>>> backend
> > >>>> hook which gets a REST entry point it can use to fetch for
> > >>>> additional
> > >>>> data, or perform actions. In this case I'd expect an internal
> > >>>> connection
> > >>>> rather than creating additional connections.
> > >>>> How would you resolve it generically enough in this context?
> > >>>
> > >>> Doron,
> > >>>
> > >>> I believe your approach a bit different, UX folks seeking for a
> > >>> convenient
> > >>> way of communicating with ovirt public api, e.g closing
> > >>> api<->GUI
> > >>> gap, and
> > >>> theirs alternatives where native HTTP layer or Java-SDK based
> > >>> framework,
> > >>> while what you need is in-process channel to communicate with
> > >>> the
> > >>> engine itself,
> > >>>
> > >>> i understanding your will of using stable api for this
> > >>> (RESTapi),
> > >>> but
> > >>> not
> > >>> sure that doing this via JavaSDK is a good way to go simply
> > >>> because
> > >>> SDK is
> > >>> designed to operate in a client-space, while what you need is a
> > >>> server-space
> > >>> bridge for that.
> > >>>
> > >>
> > >> Michael, true but...
> > >> Thinking about it differently both UI and hooks needs a client.
> > >> The underlying protocols should be abstracted. This is something
> > >> which will serve other functions as well.
> > >>
> > > 
> > > I'm not sure we would need a new abstraction here.
> > > Both UI plugins and engine plugins need some API to do basic
> > > operations, and have access to different properties in the
> > > engine.
> > 
> > +1, that's exactly what i've suggested to begin with.
> > 
> 
> The only issue is that UI plugins and engine plugins shave different
> expectations
> from performance point of view. If UI is willing to wait for a
> refresh that may
> take too long for engine plugins, which would prefer to get the
> information as
> soon as possible without going into various communication layers
> which are not
> always needed. So again- a simple solution which enables transports
> layers to
> be replaced may serve more than one functionality in a better way.
> 

Let's start with the simple solution. We don't know yet who will the plugins, how would they be used, and whether using the SDK will be a bottleneck of any kind. If the proposed solution is to support different transport layers while still using the SDK, then it is an extension we can always do in the future, if we find it of high benefit.
(btw, regardless of that, the API/SDK is now faster than in the past, as we support REST sessions, which removes the need to re-authenticate upon each API request).

> > > In the UI plguins implementation, we gave this API, and in
> > > addition
> > > created a REST session to be used in order to do more
> > > sophisticated operations.
> > > I think we should probably do the same for engine plugins,
> > > giving the basic API, and giving a REST session for more advanced
> > > operations.
> > > The engine plugin may also have another 3rd party application it
> > > interacts with, and it would be able to share this session with
> > > it,
> > > allowing it to perform different operations on the engine. It
> > > would
> > > obviously be easy to do that using the Java SDK in the engine
> > > side,
> > > without creating a new layer of abstraction.
> > 
> > true, but the thing is that java-sdk designed to work with
> > rest-api,
> > and what Doron is trying to do
> > is saving round-trip of engine->sdk->api->engine by enabling extra
> > layer in sdk that will work not via HTTP,
> > but natively with RESTeasy (REST framework we using in api), the
> > disadvantages of such design are:
> > 
> > 1. working with java-sdk via JNI (walking out from container to
> > client application - sdk)
> > 2. hacking RESTeasy by:
> >    2.1 working with underlying (not public/backward compatible)
> >    interfaces & using JNI as well
> >    2.2 most likely maintaining code working with RESTeasy on every
> >    new (RESTeasy) release by reverse
> >        engineering new changes/behaviour of this framework
> >    2.3 making assumptions on code invocations to emulate
> >    GET/POST/PUT/DELETE HTTP calls
> >    2.4 still having round-trip engine->sdk->RESTeasy->engine
> > 
> > therefore i think that having own private API in engine for that is
> > a
> > much better solution.
> > 
> > > I assume the 3rd party application will use either the Java SDK,
> > > or
> > > another one, according the platform it is built upon, and in the
> > > "worst case", will interact directly with the API.
> > > 
> > > 
> > >>>>
> > >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> I would like to ask, if there have been discussions about an
> > >>>>>> option
> > >>>>>> to call REST API services directly from the Frontend (GWT
> > >>>>>> layer)?
> > >>>>>> GWT compiles Java frontend-side to
> > >>>>>> Javascript, calls to backend services are performed
> > >>>>>> "transparently"
> > >>>>>> by the framework using AJAX support. But, there is still a
> > >>>>>> need
> > >>>>>> to
> > >>>>>> have a special set of data objects
> > >>>>>> and the server-side logic can duplicate.
> > >>>>>>
> > >>>>>> Java REST API SDK enables to build "thick" client. The calls
> > >>>>>> are
> > >>>>>> realized using e.g. Apache HttClient and supported
> > >>>>>> libraries.
> > >>>>>> I
> > >>>>>> think the requirements of GWT can be a
> > >>>>>> little bit different, but something overlaps.
> > >>>>>>
> > >>>>>> I found several links about REST API support from GWT, so
> > >>>>>> there
> > >>>>>> is
> > >>>>>> something for inspiration...
> > >>>>>>
> > >>>>>> - http://www.spiffyui.org/
> > >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
> > >>>>>> - http://code.google.com/p/gwt-rest/
> > >>>>>> - http://restygwt.fusesource.org/
> > >>>>>>
> > >>>>>> But, do you think it would be useful and what drawbacks can
> > >>>>>> occur
> > >>>>>> (authentication, authorization, response times, need to
> > >>>>>> support
> > >>>>>> larger set of services, painful
> > >>>>>> refactoring, ...)?
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>> Libor
> > >>>>>>
> > >> _______________________________________________
> > >> Engine-devel mailing list
> > >> Engine-devel at ovirt.org
> > >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>
> > 
> > 
> > --
> > 
> > Michael Pasternak
> > RedHat, ENG-Virtualization R&D
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From dfediuck at redhat.com  Sun Feb 24 13:55:28 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Sun, 24 Feb 2013 08:55:28 -0500 (EST)
Subject: [Engine-devel] REST API calls from
In-Reply-To: <132421718.6971303.1361710879301.JavaMail.root@redhat.com>
Message-ID: <1891808602.8412695.1361714128915.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: engine-devel at ovirt.org, arch at ovirt.org
> Sent: Sunday, February 24, 2013 3:01:19 PM
> Subject: Re: [Engine-devel] REST API calls from
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Michael Pasternak" <mpastern at redhat.com>
> > Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org,
> > arch at ovirt.org
> > Sent: Sunday, February 24, 2013 1:20:12 PM
> > Subject: Re: [Engine-devel] REST API calls from
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Michael Pasternak" <mpastern at redhat.com>
> > > To: "Oved Ourfalli" <ovedo at redhat.com>
> > > Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > Sent: Sunday, February 24, 2013 9:47:28 AM
> > > Subject: Re: [Engine-devel] REST API calls from
> > > 
> > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > >> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > >> To: "Michael Pasternak" <mpastern at redhat.com>
> > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > >> Sent: Thursday, February 21, 2013 6:54:59 PM
> > > >> Subject: Re: [Engine-devel] REST API calls from
> > > >>
> > > >>
> > > >>
> > > >> ----- Original Message -----
> > > >>> From: "Michael Pasternak" <mpastern at redhat.com>
> > > >>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM
> > > >>> Subject: Re: [Engine-devel] REST API calls from
> > > >>>
> > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote:
> > > >>>>
> > > >>>>
> > > >>>> ----- Original Message -----
> > > >>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> > > >>>>> To: "Libor Spevak" <lspevak at redhat.com>
> > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM
> > > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI
> > > >>>>>
> > > >>>>>
> > > >>>>> Hi Libor,
> > > >>>>>
> > > >>>>> This issue came across in one of the conversations i had
> > > >>>>> with
> > > >>>>> UX
> > > >>>>> folks, but since we didn't end
> > > >>>>> up with any conclusion/road map (nor discussed it properly
> > > >>>>> to
> > > >>>>> hear
> > > >>>>> other thoughts), this is a perfect
> > > >>>>> place to start this discussion,
> > > >>>>>
> > > >>>>> Intuitively REST is a way to go with GWT AJAX calls
> > > >>>>> ---------------------------------------------------
> > > >>>>>
> > > >>>>> pros
> > > >>>>> ====
> > > >>>>>
> > > >>>>> - api data objects can be reused by generating java classes
> > > >>>>> (using
> > > >>>>> jaxb) from the rest schema [1]
> > > >>>>> - no backend logic will be duplicated as api abstracts the
> > > >>>>> backend
> > > >>>>> exposing RESTful collection/resources to operate on
> > > >>>>> - development against api is "easy" as api describes itself
> > > >>>>> in
> > > >>>>> RSDL
> > > >>>>> [2]
> > > >>>>>
> > > >>>>> cons
> > > >>>>> ====
> > > >>>>>
> > > >>>>> - implementing transport layer (HTTP) under GWT
> > > >>>>> - implementing own j2xml/json/yaml/... marshalling layer
> > > >>>>> - implementing own error handling mechanism
> > > >>>>> - implementing REST callback mechanism (in GWT)
> > > >>>>> - constant maintenance of the data objects generated from
> > > >>>>> the
> > > >>>>> api
> > > >>>>> - painful for Java developers
> > > >>>>>
> > > >>>>> Java-SDK
> > > >>>>> --------
> > > >>>>>
> > > >>>>> pros
> > > >>>>> ====
> > > >>>>>
> > > >>>>> - abstracts transport layer (leaving developer in standard
> > > >>>>> Java
> > > >>>>> api)
> > > >>>>> - typesafe code (no need to mess with XML bulks)
> > > >>>>> - has own data objects to work with
> > > >>>>> - abstracts authentication/authorization
> > > >>>>> (kerberos/cookie/session/etc.)
> > > >>>>> - since SDK is auto-generated, it can be easily extended
> > > >>>>> with
> > > >>>>> required
> > > >>>>>   features to support UI (such as callback infrastructure
> > > >>>>>   for
> > > >>>>>   instance)
> > > >>>>>
> > > >>>>> cons
> > > >>>>> ====
> > > >>>>>
> > > >>>>> - has to be converted in to Javascript (not sure what the
> > > >>>>> impacts
> > > >>>>> are
> > > >>>>> in terms of AJAX calls/etc.)
> > > >>>>> - probably much more cons that we're not aware of and will
> > > >>>>> have
> > > >>>>> to
> > > >>>>> figure out with POC
> > > >>>>>
> > > >>>>>
> > > >>>>> thoughts?
> > > >>>>>
> > > >>>>> [1] http[s]://server[:port]/api?schema
> > > >>>>> [2] http[s]://server[:port]/api?rsdl
> > > >>>>>
> > > >>>>
> > > >>>> Although started as a UI request, there are other needs who
> > > >>>> wish
> > > >>>> to use API calls with a different transport. For example a
> > > >>>> backend
> > > >>>> hook which gets a REST entry point it can use to fetch for
> > > >>>> additional
> > > >>>> data, or perform actions. In this case I'd expect an
> > > >>>> internal
> > > >>>> connection
> > > >>>> rather than creating additional connections.
> > > >>>> How would you resolve it generically enough in this context?
> > > >>>
> > > >>> Doron,
> > > >>>
> > > >>> I believe your approach a bit different, UX folks seeking for
> > > >>> a
> > > >>> convenient
> > > >>> way of communicating with ovirt public api, e.g closing
> > > >>> api<->GUI
> > > >>> gap, and
> > > >>> theirs alternatives where native HTTP layer or Java-SDK based
> > > >>> framework,
> > > >>> while what you need is in-process channel to communicate with
> > > >>> the
> > > >>> engine itself,
> > > >>>
> > > >>> i understanding your will of using stable api for this
> > > >>> (RESTapi),
> > > >>> but
> > > >>> not
> > > >>> sure that doing this via JavaSDK is a good way to go simply
> > > >>> because
> > > >>> SDK is
> > > >>> designed to operate in a client-space, while what you need is
> > > >>> a
> > > >>> server-space
> > > >>> bridge for that.
> > > >>>
> > > >>
> > > >> Michael, true but...
> > > >> Thinking about it differently both UI and hooks needs a
> > > >> client.
> > > >> The underlying protocols should be abstracted. This is
> > > >> something
> > > >> which will serve other functions as well.
> > > >>
> > > > 
> > > > I'm not sure we would need a new abstraction here.
> > > > Both UI plugins and engine plugins need some API to do basic
> > > > operations, and have access to different properties in the
> > > > engine.
> > > 
> > > +1, that's exactly what i've suggested to begin with.
> > > 
> > 
> > The only issue is that UI plugins and engine plugins shave
> > different
> > expectations
> > from performance point of view. If UI is willing to wait for a
> > refresh that may
> > take too long for engine plugins, which would prefer to get the
> > information as
> > soon as possible without going into various communication layers
> > which are not
> > always needed. So again- a simple solution which enables transports
> > layers to
> > be replaced may serve more than one functionality in a better way.
> > 
> 
> Let's start with the simple solution. We don't know yet who will the
> plugins, how would they be used, and whether using the SDK will be a
> bottleneck of any kind. If the proposed solution is to support
> different transport layers while still using the SDK, then it is an
> extension we can always do in the future, if we find it of high
> benefit.
> (btw, regardless of that, the API/SDK is now faster than in the past,
> as we support REST sessions, which removes the need to
> re-authenticate upon each API request).
> 

Oved, we have pretty good idea on how it will be used and what will
create performance hits. Otherwise we wouldn't have had this thread.

> > > > In the UI plguins implementation, we gave this API, and in
> > > > addition
> > > > created a REST session to be used in order to do more
> > > > sophisticated operations.
> > > > I think we should probably do the same for engine plugins,
> > > > giving the basic API, and giving a REST session for more
> > > > advanced
> > > > operations.
> > > > The engine plugin may also have another 3rd party application
> > > > it
> > > > interacts with, and it would be able to share this session with
> > > > it,
> > > > allowing it to perform different operations on the engine. It
> > > > would
> > > > obviously be easy to do that using the Java SDK in the engine
> > > > side,
> > > > without creating a new layer of abstraction.
> > > 
> > > true, but the thing is that java-sdk designed to work with
> > > rest-api,
> > > and what Doron is trying to do
> > > is saving round-trip of engine->sdk->api->engine by enabling
> > > extra
> > > layer in sdk that will work not via HTTP,
> > > but natively with RESTeasy (REST framework we using in api), the
> > > disadvantages of such design are:
> > > 
> > > 1. working with java-sdk via JNI (walking out from container to
> > > client application - sdk)
> > > 2. hacking RESTeasy by:
> > >    2.1 working with underlying (not public/backward compatible)
> > >    interfaces & using JNI as well
> > >    2.2 most likely maintaining code working with RESTeasy on
> > >    every
> > >    new (RESTeasy) release by reverse
> > >        engineering new changes/behaviour of this framework
> > >    2.3 making assumptions on code invocations to emulate
> > >    GET/POST/PUT/DELETE HTTP calls
> > >    2.4 still having round-trip engine->sdk->RESTeasy->engine
> > > 
> > > therefore i think that having own private API in engine for that
> > > is
> > > a
> > > much better solution.
> > > 
> > > > I assume the 3rd party application will use either the Java
> > > > SDK,
> > > > or
> > > > another one, according the platform it is built upon, and in
> > > > the
> > > > "worst case", will interact directly with the API.
> > > > 
> > > > 
> > > >>>>
> > > >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> > > >>>>>> Hi,
> > > >>>>>>
> > > >>>>>> I would like to ask, if there have been discussions about
> > > >>>>>> an
> > > >>>>>> option
> > > >>>>>> to call REST API services directly from the Frontend (GWT
> > > >>>>>> layer)?
> > > >>>>>> GWT compiles Java frontend-side to
> > > >>>>>> Javascript, calls to backend services are performed
> > > >>>>>> "transparently"
> > > >>>>>> by the framework using AJAX support. But, there is still a
> > > >>>>>> need
> > > >>>>>> to
> > > >>>>>> have a special set of data objects
> > > >>>>>> and the server-side logic can duplicate.
> > > >>>>>>
> > > >>>>>> Java REST API SDK enables to build "thick" client. The
> > > >>>>>> calls
> > > >>>>>> are
> > > >>>>>> realized using e.g. Apache HttClient and supported
> > > >>>>>> libraries.
> > > >>>>>> I
> > > >>>>>> think the requirements of GWT can be a
> > > >>>>>> little bit different, but something overlaps.
> > > >>>>>>
> > > >>>>>> I found several links about REST API support from GWT, so
> > > >>>>>> there
> > > >>>>>> is
> > > >>>>>> something for inspiration...
> > > >>>>>>
> > > >>>>>> - http://www.spiffyui.org/
> > > >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
> > > >>>>>> - http://code.google.com/p/gwt-rest/
> > > >>>>>> - http://restygwt.fusesource.org/
> > > >>>>>>
> > > >>>>>> But, do you think it would be useful and what drawbacks
> > > >>>>>> can
> > > >>>>>> occur
> > > >>>>>> (authentication, authorization, response times, need to
> > > >>>>>> support
> > > >>>>>> larger set of services, painful
> > > >>>>>> refactoring, ...)?
> > > >>>>>>
> > > >>>>>> Regards,
> > > >>>>>> Libor
> > > >>>>>>


From emesika at redhat.com  Sun Feb 24 19:47:54 2013
From: emesika at redhat.com (Eli Mesika)
Date: Sun, 24 Feb 2013 14:47:54 -0500 (EST)
Subject: [Engine-devel] DB Schema Reports
In-Reply-To: <51277424.2020307@redhat.com>
Message-ID: <120577015.598729.1361735274291.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Greg Padgett" <gpadgett at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: "Libor Spevak" <lspevak at redhat.com>, engine-devel at ovirt.org, infra at ovirt.org
> Sent: Friday, February 22, 2013 3:35:32 PM
> Subject: Re: DB Schema Reports
> 
> On 02/22/2013 06:05 AM, Eli Mesika wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Libor Spevak" <lspevak at redhat.com>
> >> To: engine-devel at ovirt.org, rhev-devel at redhat.com, infra at ovirt.org
> >> Sent: Friday, February 22, 2013 10:02:55 AM
> >> Subject: DB Schema Reports
> >>
> >> Hi,
> >>
> >> let me announce new database schema reports based on the SchemaSpy
> >> Java
> >> library available.
> >>
> >> Thanks to infra group for support, especially to David Caro, who
> >> set
> >> up
> >> Mr. Jenkins's jobs.
> >
> > Great job !
> 
> +1, this will be very useful!
> 
> Eli, is the great diagram you sent out in early December on the wiki
> as
> well?  We should add a link to it from the wiki page below.

I think that the current set of pages suggested here is already doing this job well
> 
> >>
> >> oVirt-Engine:
> >> http://resources.ovirt.org/dbreports/latest/engine/public/index.html
> >> oVirt-DWH:
> >> http://resources.ovirt.org/dbreports/latest/dwh/public/index.html
> >>
> >> Wiki:
> >> http://www.ovirt.org/DB_model
> >>
> >> Regards,
> >> Libor
> >> _______________________________________________
> >> Infra mailing list
> >> Infra at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/infra
> >>
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> 
> 


From ovedo at redhat.com  Sun Feb 24 21:56:49 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Sun, 24 Feb 2013 16:56:49 -0500 (EST)
Subject: [Engine-devel] REST API calls from
In-Reply-To: <1891808602.8412695.1361714128915.JavaMail.root@redhat.com>
Message-ID: <1605013790.7186572.1361743009535.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Doron Fediuck" <dfediuck at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org, arch at ovirt.org
> Sent: Sunday, February 24, 2013 3:55:28 PM
> Subject: Re: [Engine-devel] REST API calls from
> 
> 
> 
> ----- Original Message -----
> > From: "Oved Ourfalli" <ovedo at redhat.com>
> > To: "Doron Fediuck" <dfediuck at redhat.com>
> > Cc: engine-devel at ovirt.org, arch at ovirt.org
> > Sent: Sunday, February 24, 2013 3:01:19 PM
> > Subject: Re: [Engine-devel] REST API calls from
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > To: "Michael Pasternak" <mpastern at redhat.com>
> > > Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org,
> > > arch at ovirt.org
> > > Sent: Sunday, February 24, 2013 1:20:12 PM
> > > Subject: Re: [Engine-devel] REST API calls from
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Michael Pasternak" <mpastern at redhat.com>
> > > > To: "Oved Ourfalli" <ovedo at redhat.com>
> > > > Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > > Sent: Sunday, February 24, 2013 9:47:28 AM
> > > > Subject: Re: [Engine-devel] REST API calls from
> > > > 
> > > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote:
> > > > > 
> > > > > 
> > > > > ----- Original Message -----
> > > > >> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > >> To: "Michael Pasternak" <mpastern at redhat.com>
> > > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > > >> Sent: Thursday, February 21, 2013 6:54:59 PM
> > > > >> Subject: Re: [Engine-devel] REST API calls from
> > > > >>
> > > > >>
> > > > >>
> > > > >> ----- Original Message -----
> > > > >>> From: "Michael Pasternak" <mpastern at redhat.com>
> > > > >>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM
> > > > >>> Subject: Re: [Engine-devel] REST API calls from
> > > > >>>
> > > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>> ----- Original Message -----
> > > > >>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> > > > >>>>> To: "Libor Spevak" <lspevak at redhat.com>
> > > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM
> > > > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> Hi Libor,
> > > > >>>>>
> > > > >>>>> This issue came across in one of the conversations i had
> > > > >>>>> with
> > > > >>>>> UX
> > > > >>>>> folks, but since we didn't end
> > > > >>>>> up with any conclusion/road map (nor discussed it
> > > > >>>>> properly
> > > > >>>>> to
> > > > >>>>> hear
> > > > >>>>> other thoughts), this is a perfect
> > > > >>>>> place to start this discussion,
> > > > >>>>>
> > > > >>>>> Intuitively REST is a way to go with GWT AJAX calls
> > > > >>>>> ---------------------------------------------------
> > > > >>>>>
> > > > >>>>> pros
> > > > >>>>> ====
> > > > >>>>>
> > > > >>>>> - api data objects can be reused by generating java
> > > > >>>>> classes
> > > > >>>>> (using
> > > > >>>>> jaxb) from the rest schema [1]
> > > > >>>>> - no backend logic will be duplicated as api abstracts
> > > > >>>>> the
> > > > >>>>> backend
> > > > >>>>> exposing RESTful collection/resources to operate on
> > > > >>>>> - development against api is "easy" as api describes
> > > > >>>>> itself
> > > > >>>>> in
> > > > >>>>> RSDL
> > > > >>>>> [2]
> > > > >>>>>
> > > > >>>>> cons
> > > > >>>>> ====
> > > > >>>>>
> > > > >>>>> - implementing transport layer (HTTP) under GWT
> > > > >>>>> - implementing own j2xml/json/yaml/... marshalling layer
> > > > >>>>> - implementing own error handling mechanism
> > > > >>>>> - implementing REST callback mechanism (in GWT)
> > > > >>>>> - constant maintenance of the data objects generated from
> > > > >>>>> the
> > > > >>>>> api
> > > > >>>>> - painful for Java developers
> > > > >>>>>
> > > > >>>>> Java-SDK
> > > > >>>>> --------
> > > > >>>>>
> > > > >>>>> pros
> > > > >>>>> ====
> > > > >>>>>
> > > > >>>>> - abstracts transport layer (leaving developer in
> > > > >>>>> standard
> > > > >>>>> Java
> > > > >>>>> api)
> > > > >>>>> - typesafe code (no need to mess with XML bulks)
> > > > >>>>> - has own data objects to work with
> > > > >>>>> - abstracts authentication/authorization
> > > > >>>>> (kerberos/cookie/session/etc.)
> > > > >>>>> - since SDK is auto-generated, it can be easily extended
> > > > >>>>> with
> > > > >>>>> required
> > > > >>>>>   features to support UI (such as callback infrastructure
> > > > >>>>>   for
> > > > >>>>>   instance)
> > > > >>>>>
> > > > >>>>> cons
> > > > >>>>> ====
> > > > >>>>>
> > > > >>>>> - has to be converted in to Javascript (not sure what the
> > > > >>>>> impacts
> > > > >>>>> are
> > > > >>>>> in terms of AJAX calls/etc.)
> > > > >>>>> - probably much more cons that we're not aware of and
> > > > >>>>> will
> > > > >>>>> have
> > > > >>>>> to
> > > > >>>>> figure out with POC
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> thoughts?
> > > > >>>>>
> > > > >>>>> [1] http[s]://server[:port]/api?schema
> > > > >>>>> [2] http[s]://server[:port]/api?rsdl
> > > > >>>>>
> > > > >>>>
> > > > >>>> Although started as a UI request, there are other needs
> > > > >>>> who
> > > > >>>> wish
> > > > >>>> to use API calls with a different transport. For example a
> > > > >>>> backend
> > > > >>>> hook which gets a REST entry point it can use to fetch for
> > > > >>>> additional
> > > > >>>> data, or perform actions. In this case I'd expect an
> > > > >>>> internal
> > > > >>>> connection
> > > > >>>> rather than creating additional connections.
> > > > >>>> How would you resolve it generically enough in this
> > > > >>>> context?
> > > > >>>
> > > > >>> Doron,
> > > > >>>
> > > > >>> I believe your approach a bit different, UX folks seeking
> > > > >>> for
> > > > >>> a
> > > > >>> convenient
> > > > >>> way of communicating with ovirt public api, e.g closing
> > > > >>> api<->GUI
> > > > >>> gap, and
> > > > >>> theirs alternatives where native HTTP layer or Java-SDK
> > > > >>> based
> > > > >>> framework,
> > > > >>> while what you need is in-process channel to communicate
> > > > >>> with
> > > > >>> the
> > > > >>> engine itself,
> > > > >>>
> > > > >>> i understanding your will of using stable api for this
> > > > >>> (RESTapi),
> > > > >>> but
> > > > >>> not
> > > > >>> sure that doing this via JavaSDK is a good way to go simply
> > > > >>> because
> > > > >>> SDK is
> > > > >>> designed to operate in a client-space, while what you need
> > > > >>> is
> > > > >>> a
> > > > >>> server-space
> > > > >>> bridge for that.
> > > > >>>
> > > > >>
> > > > >> Michael, true but...
> > > > >> Thinking about it differently both UI and hooks needs a
> > > > >> client.
> > > > >> The underlying protocols should be abstracted. This is
> > > > >> something
> > > > >> which will serve other functions as well.
> > > > >>
> > > > > 
> > > > > I'm not sure we would need a new abstraction here.
> > > > > Both UI plugins and engine plugins need some API to do basic
> > > > > operations, and have access to different properties in the
> > > > > engine.
> > > > 
> > > > +1, that's exactly what i've suggested to begin with.
> > > > 
> > > 
> > > The only issue is that UI plugins and engine plugins shave
> > > different
> > > expectations
> > > from performance point of view. If UI is willing to wait for a
> > > refresh that may
> > > take too long for engine plugins, which would prefer to get the
> > > information as
> > > soon as possible without going into various communication layers
> > > which are not
> > > always needed. So again- a simple solution which enables
> > > transports
> > > layers to
> > > be replaced may serve more than one functionality in a better
> > > way.
> > > 
> > 
> > Let's start with the simple solution. We don't know yet who will
> > the
> > plugins, how would they be used, and whether using the SDK will be
> > a
> > bottleneck of any kind. If the proposed solution is to support
> > different transport layers while still using the SDK, then it is an
> > extension we can always do in the future, if we find it of high
> > benefit.
> > (btw, regardless of that, the API/SDK is now faster than in the
> > past,
> > as we support REST sessions, which removes the need to
> > re-authenticate upon each API request).
> > 
> 
> Oved, we have pretty good idea on how it will be used and what will
> create performance hits. Otherwise we wouldn't have had this thread.
> 
If so, it would be nice if you share this information on the thread as well... some use-cases, some statistics you may have on the current performance, and on the performance requirements, and etc.
I'm not saying that you're wrong... just saying I wasn't convinced it is really necessary.

Thank you,
Oved
> > > > > In the UI plguins implementation, we gave this API, and in
> > > > > addition
> > > > > created a REST session to be used in order to do more
> > > > > sophisticated operations.
> > > > > I think we should probably do the same for engine plugins,
> > > > > giving the basic API, and giving a REST session for more
> > > > > advanced
> > > > > operations.
> > > > > The engine plugin may also have another 3rd party application
> > > > > it
> > > > > interacts with, and it would be able to share this session
> > > > > with
> > > > > it,
> > > > > allowing it to perform different operations on the engine. It
> > > > > would
> > > > > obviously be easy to do that using the Java SDK in the engine
> > > > > side,
> > > > > without creating a new layer of abstraction.
> > > > 
> > > > true, but the thing is that java-sdk designed to work with
> > > > rest-api,
> > > > and what Doron is trying to do
> > > > is saving round-trip of engine->sdk->api->engine by enabling
> > > > extra
> > > > layer in sdk that will work not via HTTP,
> > > > but natively with RESTeasy (REST framework we using in api),
> > > > the
> > > > disadvantages of such design are:
> > > > 
> > > > 1. working with java-sdk via JNI (walking out from container to
> > > > client application - sdk)
> > > > 2. hacking RESTeasy by:
> > > >    2.1 working with underlying (not public/backward compatible)
> > > >    interfaces & using JNI as well
> > > >    2.2 most likely maintaining code working with RESTeasy on
> > > >    every
> > > >    new (RESTeasy) release by reverse
> > > >        engineering new changes/behaviour of this framework
> > > >    2.3 making assumptions on code invocations to emulate
> > > >    GET/POST/PUT/DELETE HTTP calls
> > > >    2.4 still having round-trip engine->sdk->RESTeasy->engine
> > > > 
> > > > therefore i think that having own private API in engine for
> > > > that
> > > > is
> > > > a
> > > > much better solution.
> > > > 
> > > > > I assume the 3rd party application will use either the Java
> > > > > SDK,
> > > > > or
> > > > > another one, according the platform it is built upon, and in
> > > > > the
> > > > > "worst case", will interact directly with the API.
> > > > > 
> > > > > 
> > > > >>>>
> > > > >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> > > > >>>>>> Hi,
> > > > >>>>>>
> > > > >>>>>> I would like to ask, if there have been discussions
> > > > >>>>>> about
> > > > >>>>>> an
> > > > >>>>>> option
> > > > >>>>>> to call REST API services directly from the Frontend
> > > > >>>>>> (GWT
> > > > >>>>>> layer)?
> > > > >>>>>> GWT compiles Java frontend-side to
> > > > >>>>>> Javascript, calls to backend services are performed
> > > > >>>>>> "transparently"
> > > > >>>>>> by the framework using AJAX support. But, there is still
> > > > >>>>>> a
> > > > >>>>>> need
> > > > >>>>>> to
> > > > >>>>>> have a special set of data objects
> > > > >>>>>> and the server-side logic can duplicate.
> > > > >>>>>>
> > > > >>>>>> Java REST API SDK enables to build "thick" client. The
> > > > >>>>>> calls
> > > > >>>>>> are
> > > > >>>>>> realized using e.g. Apache HttClient and supported
> > > > >>>>>> libraries.
> > > > >>>>>> I
> > > > >>>>>> think the requirements of GWT can be a
> > > > >>>>>> little bit different, but something overlaps.
> > > > >>>>>>
> > > > >>>>>> I found several links about REST API support from GWT,
> > > > >>>>>> so
> > > > >>>>>> there
> > > > >>>>>> is
> > > > >>>>>> something for inspiration...
> > > > >>>>>>
> > > > >>>>>> - http://www.spiffyui.org/
> > > > >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
> > > > >>>>>> - http://code.google.com/p/gwt-rest/
> > > > >>>>>> - http://restygwt.fusesource.org/
> > > > >>>>>>
> > > > >>>>>> But, do you think it would be useful and what drawbacks
> > > > >>>>>> can
> > > > >>>>>> occur
> > > > >>>>>> (authentication, authorization, response times, need to
> > > > >>>>>> support
> > > > >>>>>> larger set of services, painful
> > > > >>>>>> refactoring, ...)?
> > > > >>>>>>
> > > > >>>>>> Regards,
> > > > >>>>>> Libor
> > > > >>>>>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From cc272309126 at gmail.com  Mon Feb 25 10:15:24 2013
From: cc272309126 at gmail.com (=?GB2312?B?s8KzrA==?=)
Date: Mon, 25 Feb 2013 18:15:24 +0800
Subject: [Engine-devel] how to setup development env.
Message-ID: <CAKZDL5PDwu4jdNtBAn+tR6GtufzsdUJd0WHVaWPS0Bqw_EA1aQ@mail.gmail.com>

Hi, all

I have setup the project with eclipse successfully.but how should I build
the project with eclipse? And when I change the code,how should I run up
the test class? And Is there any document about the relationship among
those maven modul project ?

chenchao

thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130225/cb6dc127/attachment.html>

From mpastern at redhat.com  Mon Feb 25 10:33:01 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 25 Feb 2013 12:33:01 +0200
Subject: [Engine-devel] REST API calls from
In-Reply-To: <132421718.6971303.1361710879301.JavaMail.root@redhat.com>
References: <132421718.6971303.1361710879301.JavaMail.root@redhat.com>
Message-ID: <512B3DDD.90301@redhat.com>

On 02/24/2013 03:01 PM, Oved Ourfalli wrote:
> 
> ----- Original Message -----
>> > From: "Doron Fediuck" <dfediuck at redhat.com>
>> > To: "Michael Pasternak" <mpastern at redhat.com>
>> > Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org, arch at ovirt.org
>> > Sent: Sunday, February 24, 2013 1:20:12 PM
>> > Subject: Re: [Engine-devel] REST API calls from
>> > 
>> > 
>> > 
>> > ----- Original Message -----
>>> > > From: "Michael Pasternak" <mpastern at redhat.com>
>>> > > To: "Oved Ourfalli" <ovedo at redhat.com>
>>> > > Cc: engine-devel at ovirt.org, arch at ovirt.org
>>> > > Sent: Sunday, February 24, 2013 9:47:28 AM
>>> > > Subject: Re: [Engine-devel] REST API calls from
>>> > > 
>>> > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote:
>>>> > > > 
>>>> > > > 
>>>> > > > ----- Original Message -----
>>>>> > > >> From: "Doron Fediuck" <dfediuck at redhat.com>
>>>>> > > >> To: "Michael Pasternak" <mpastern at redhat.com>
>>>>> > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org
>>>>> > > >> Sent: Thursday, February 21, 2013 6:54:59 PM
>>>>> > > >> Subject: Re: [Engine-devel] REST API calls from
>>>>> > > >>
>>>>> > > >>
>>>>> > > >>
>>>>> > > >> ----- Original Message -----
>>>>>> > > >>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>> > > >>> To: "Doron Fediuck" <dfediuck at redhat.com>
>>>>>> > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org
>>>>>> > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM
>>>>>> > > >>> Subject: Re: [Engine-devel] REST API calls from
>>>>>> > > >>>
>>>>>> > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote:
>>>>>>> > > >>>>
>>>>>>> > > >>>>
>>>>>>> > > >>>> ----- Original Message -----
>>>>>>>> > > >>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>>> > > >>>>> To: "Libor Spevak" <lspevak at redhat.com>
>>>>>>>> > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org
>>>>>>>> > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM
>>>>>>>> > > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> Hi Libor,
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> This issue came across in one of the conversations i had with
>>>>>>>> > > >>>>> UX
>>>>>>>> > > >>>>> folks, but since we didn't end
>>>>>>>> > > >>>>> up with any conclusion/road map (nor discussed it properly to
>>>>>>>> > > >>>>> hear
>>>>>>>> > > >>>>> other thoughts), this is a perfect
>>>>>>>> > > >>>>> place to start this discussion,
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> Intuitively REST is a way to go with GWT AJAX calls
>>>>>>>> > > >>>>> ---------------------------------------------------
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> pros
>>>>>>>> > > >>>>> ====
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> - api data objects can be reused by generating java classes
>>>>>>>> > > >>>>> (using
>>>>>>>> > > >>>>> jaxb) from the rest schema [1]
>>>>>>>> > > >>>>> - no backend logic will be duplicated as api abstracts the
>>>>>>>> > > >>>>> backend
>>>>>>>> > > >>>>> exposing RESTful collection/resources to operate on
>>>>>>>> > > >>>>> - development against api is "easy" as api describes itself
>>>>>>>> > > >>>>> in
>>>>>>>> > > >>>>> RSDL
>>>>>>>> > > >>>>> [2]
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> cons
>>>>>>>> > > >>>>> ====
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> - implementing transport layer (HTTP) under GWT
>>>>>>>> > > >>>>> - implementing own j2xml/json/yaml/... marshalling layer
>>>>>>>> > > >>>>> - implementing own error handling mechanism
>>>>>>>> > > >>>>> - implementing REST callback mechanism (in GWT)
>>>>>>>> > > >>>>> - constant maintenance of the data objects generated from the
>>>>>>>> > > >>>>> api
>>>>>>>> > > >>>>> - painful for Java developers
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> Java-SDK
>>>>>>>> > > >>>>> --------
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> pros
>>>>>>>> > > >>>>> ====
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> - abstracts transport layer (leaving developer in standard
>>>>>>>> > > >>>>> Java
>>>>>>>> > > >>>>> api)
>>>>>>>> > > >>>>> - typesafe code (no need to mess with XML bulks)
>>>>>>>> > > >>>>> - has own data objects to work with
>>>>>>>> > > >>>>> - abstracts authentication/authorization
>>>>>>>> > > >>>>> (kerberos/cookie/session/etc.)
>>>>>>>> > > >>>>> - since SDK is auto-generated, it can be easily extended with
>>>>>>>> > > >>>>> required
>>>>>>>> > > >>>>>   features to support UI (such as callback infrastructure for
>>>>>>>> > > >>>>>   instance)
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> cons
>>>>>>>> > > >>>>> ====
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> - has to be converted in to Javascript (not sure what the
>>>>>>>> > > >>>>> impacts
>>>>>>>> > > >>>>> are
>>>>>>>> > > >>>>> in terms of AJAX calls/etc.)
>>>>>>>> > > >>>>> - probably much more cons that we're not aware of and will
>>>>>>>> > > >>>>> have
>>>>>>>> > > >>>>> to
>>>>>>>> > > >>>>> figure out with POC
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> thoughts?
>>>>>>>> > > >>>>>
>>>>>>>> > > >>>>> [1] http[s]://server[:port]/api?schema
>>>>>>>> > > >>>>> [2] http[s]://server[:port]/api?rsdl
>>>>>>>> > > >>>>>
>>>>>>> > > >>>>
>>>>>>> > > >>>> Although started as a UI request, there are other needs who
>>>>>>> > > >>>> wish
>>>>>>> > > >>>> to use API calls with a different transport. For example a
>>>>>>> > > >>>> backend
>>>>>>> > > >>>> hook which gets a REST entry point it can use to fetch for
>>>>>>> > > >>>> additional
>>>>>>> > > >>>> data, or perform actions. In this case I'd expect an internal
>>>>>>> > > >>>> connection
>>>>>>> > > >>>> rather than creating additional connections.
>>>>>>> > > >>>> How would you resolve it generically enough in this context?
>>>>>> > > >>>
>>>>>> > > >>> Doron,
>>>>>> > > >>>
>>>>>> > > >>> I believe your approach a bit different, UX folks seeking for a
>>>>>> > > >>> convenient
>>>>>> > > >>> way of communicating with ovirt public api, e.g closing
>>>>>> > > >>> api<->GUI
>>>>>> > > >>> gap, and
>>>>>> > > >>> theirs alternatives where native HTTP layer or Java-SDK based
>>>>>> > > >>> framework,
>>>>>> > > >>> while what you need is in-process channel to communicate with
>>>>>> > > >>> the
>>>>>> > > >>> engine itself,
>>>>>> > > >>>
>>>>>> > > >>> i understanding your will of using stable api for this
>>>>>> > > >>> (RESTapi),
>>>>>> > > >>> but
>>>>>> > > >>> not
>>>>>> > > >>> sure that doing this via JavaSDK is a good way to go simply
>>>>>> > > >>> because
>>>>>> > > >>> SDK is
>>>>>> > > >>> designed to operate in a client-space, while what you need is a
>>>>>> > > >>> server-space
>>>>>> > > >>> bridge for that.
>>>>>> > > >>>
>>>>> > > >>
>>>>> > > >> Michael, true but...
>>>>> > > >> Thinking about it differently both UI and hooks needs a client.
>>>>> > > >> The underlying protocols should be abstracted. This is something
>>>>> > > >> which will serve other functions as well.
>>>>> > > >>
>>>> > > > 
>>>> > > > I'm not sure we would need a new abstraction here.
>>>> > > > Both UI plugins and engine plugins need some API to do basic
>>>> > > > operations, and have access to different properties in the
>>>> > > > engine.
>>> > > 
>>> > > +1, that's exactly what i've suggested to begin with.
>>> > > 
>> > 
>> > The only issue is that UI plugins and engine plugins shave different
>> > expectations
>> > from performance point of view. If UI is willing to wait for a
>> > refresh that may
>> > take too long for engine plugins, which would prefer to get the
>> > information as
>> > soon as possible without going into various communication layers
>> > which are not
>> > always needed. So again- a simple solution which enables transports
>> > layers to
>> > be replaced may serve more than one functionality in a better way.
>> > 
> Let's start with the simple solution. We don't know yet who will the plugins, how would they be used, and whether using the SDK will be a bottleneck of any kind. If the proposed solution is to support different transport layers while still using the SDK, then it is an extension we can always do in the future, if we find it of high benefit.
> (btw, regardless of that, the API/SDK is now faster than in the past, as we support REST sessions, which removes the need to re-authenticate upon each API request).
> 

true, but the real bottleneck is sending XML bulks over the wire + bi-directional marshalling X 2 (engine<->api + api<->xml).

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From lhornyak at redhat.com  Mon Feb 25 10:39:39 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Mon, 25 Feb 2013 05:39:39 -0500 (EST)
Subject: [Engine-devel] how to setup development env.
In-Reply-To: <CAKZDL5PDwu4jdNtBAn+tR6GtufzsdUJd0WHVaWPS0Bqw_EA1aQ@mail.gmail.com>
Message-ID: <628328821.842544.1361788779642.JavaMail.root@redhat.com>

Hi Chenchao,

Basically with eclipse you should have the m2e plugin or you can use the `mvn eclipse:eclipse` command to generate eclipse project descriptors. I would recommend the m2e plugin, it is really good quality and it is included in most recent eclipse distributions.

You find the build instructions here:
http://www.ovirt.org/Building_oVirt_engine

If you are also working with the gwt frontend, I would also recommend this page:
http://www.ovirt.org/DebugFrontend

Best regards,
Laszlo

----- Original Message -----
> From: "??" <cc272309126 at gmail.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, February 25, 2013 11:15:24 AM
> Subject: [Engine-devel] how to setup development env.
> 
> 
> Hi, all
> 
> 
> I have setup the project with eclipse successfully.but how should I
> build the project with eclipse? And when I change the code,how
> should I run up the test class? And Is there any document about the
> relationship among those maven modul project ?
> 
> 
> chenchao
> 
> 
> thanks.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From mpastern at redhat.com  Mon Feb 25 11:28:28 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 25 Feb 2013 13:28:28 +0200
Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.3-1 released
Message-ID: <512B4ADC.1000107@redhat.com>


* Wed  Jan 30 2013 Michael Pasternak <mpastern at redhat.com> - 1.0.0.3-1
- implement SSL support (without host verification)
- implement shutdown() to deallocate system resources
- to cluster added tunnel_migration property
- to DataCenter added Clusters sub-collection
- to root collection resource Disk added Permissions sub-collectio
- to root collection resource Disk added Statistic sub-collection
- host can be attached to cluster now either by id or name
- to StorageDomainTemplate added Disks sub-collection
- to StorageDomainVM added Disks sub-collection
- to template.display added keyboard_layout property
- to template added tunnel_migration property
- to vm.display added keyboard_layout property
- to vm added tunnel_migration property
- to VMSnapshot added preview method
- to VMSnapshot added undo method
- to VMSnapshot added commit method


More details can be found at [1].

[1] http://www.ovirt.org/Java-sdk-changelog

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From eedri at redhat.com  Mon Feb 25 13:14:41 2013
From: eedri at redhat.com (Eyal Edri)
Date: Mon, 25 Feb 2013 08:14:41 -0500 (EST)
Subject: [Engine-devel] new ovirt-dwh & ovirt-reports nightly builds are
 avaliable for fedora 18
In-Reply-To: <746938583.8354658.1361797974467.JavaMail.root@redhat.com>
Message-ID: <1253361118.8356315.1361798081383.JavaMail.root@redhat.com>

fyi,

per request, ovirt-dwh & ovirt-reports are now built nightly and published on ovirt.org repos.

http://resources.ovirt.org/releases/nightly/rpm/Fedora/18/noarch/

Eyal Edri
oVirt infra team.


From dfediuck at redhat.com  Mon Feb 25 13:20:09 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 25 Feb 2013 08:20:09 -0500 (EST)
Subject: [Engine-devel] REST API calls from
In-Reply-To: <512B3DDD.90301@redhat.com>
Message-ID: <849405596.8862817.1361798409457.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org, arch at ovirt.org
> Sent: Monday, February 25, 2013 12:33:01 PM
> Subject: Re: [Engine-devel] REST API calls from
> 
> On 02/24/2013 03:01 PM, Oved Ourfalli wrote:
> > 
> > ----- Original Message -----
> >> > From: "Doron Fediuck" <dfediuck at redhat.com>
> >> > To: "Michael Pasternak" <mpastern at redhat.com>
> >> > Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org,
> >> > arch at ovirt.org
> >> > Sent: Sunday, February 24, 2013 1:20:12 PM
> >> > Subject: Re: [Engine-devel] REST API calls from
> >> > 
> >> > 
> >> > 
> >> > ----- Original Message -----
> >>> > > From: "Michael Pasternak" <mpastern at redhat.com>
> >>> > > To: "Oved Ourfalli" <ovedo at redhat.com>
> >>> > > Cc: engine-devel at ovirt.org, arch at ovirt.org
> >>> > > Sent: Sunday, February 24, 2013 9:47:28 AM
> >>> > > Subject: Re: [Engine-devel] REST API calls from
> >>> > > 
> >>> > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote:
> >>>> > > > 
> >>>> > > > 
> >>>> > > > ----- Original Message -----
> >>>>> > > >> From: "Doron Fediuck" <dfediuck at redhat.com>
> >>>>> > > >> To: "Michael Pasternak" <mpastern at redhat.com>
> >>>>> > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org
> >>>>> > > >> Sent: Thursday, February 21, 2013 6:54:59 PM
> >>>>> > > >> Subject: Re: [Engine-devel] REST API calls from
> >>>>> > > >>
> >>>>> > > >>
> >>>>> > > >>
> >>>>> > > >> ----- Original Message -----
> >>>>>> > > >>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>>>> > > >>> To: "Doron Fediuck" <dfediuck at redhat.com>
> >>>>>> > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> >>>>>> > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM
> >>>>>> > > >>> Subject: Re: [Engine-devel] REST API calls from
> >>>>>> > > >>>
> >>>>>> > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote:
> >>>>>>> > > >>>>
> >>>>>>> > > >>>>
> >>>>>>> > > >>>> ----- Original Message -----
> >>>>>>>> > > >>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>>>>>> > > >>>>> To: "Libor Spevak" <lspevak at redhat.com>
> >>>>>>>> > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> >>>>>>>> > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM
> >>>>>>>> > > >>>>> Subject: Re: [Engine-devel] REST API calls from
> >>>>>>>> > > >>>>> the GUI
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> Hi Libor,
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> This issue came across in one of the conversations
> >>>>>>>> > > >>>>> i had with
> >>>>>>>> > > >>>>> UX
> >>>>>>>> > > >>>>> folks, but since we didn't end
> >>>>>>>> > > >>>>> up with any conclusion/road map (nor discussed it
> >>>>>>>> > > >>>>> properly to
> >>>>>>>> > > >>>>> hear
> >>>>>>>> > > >>>>> other thoughts), this is a perfect
> >>>>>>>> > > >>>>> place to start this discussion,
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> Intuitively REST is a way to go with GWT AJAX
> >>>>>>>> > > >>>>> calls
> >>>>>>>> > > >>>>> ---------------------------------------------------
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> pros
> >>>>>>>> > > >>>>> ====
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> - api data objects can be reused by generating
> >>>>>>>> > > >>>>> java classes
> >>>>>>>> > > >>>>> (using
> >>>>>>>> > > >>>>> jaxb) from the rest schema [1]
> >>>>>>>> > > >>>>> - no backend logic will be duplicated as api
> >>>>>>>> > > >>>>> abstracts the
> >>>>>>>> > > >>>>> backend
> >>>>>>>> > > >>>>> exposing RESTful collection/resources to operate
> >>>>>>>> > > >>>>> on
> >>>>>>>> > > >>>>> - development against api is "easy" as api
> >>>>>>>> > > >>>>> describes itself
> >>>>>>>> > > >>>>> in
> >>>>>>>> > > >>>>> RSDL
> >>>>>>>> > > >>>>> [2]
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> cons
> >>>>>>>> > > >>>>> ====
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> - implementing transport layer (HTTP) under GWT
> >>>>>>>> > > >>>>> - implementing own j2xml/json/yaml/... marshalling
> >>>>>>>> > > >>>>> layer
> >>>>>>>> > > >>>>> - implementing own error handling mechanism
> >>>>>>>> > > >>>>> - implementing REST callback mechanism (in GWT)
> >>>>>>>> > > >>>>> - constant maintenance of the data objects
> >>>>>>>> > > >>>>> generated from the
> >>>>>>>> > > >>>>> api
> >>>>>>>> > > >>>>> - painful for Java developers
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> Java-SDK
> >>>>>>>> > > >>>>> --------
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> pros
> >>>>>>>> > > >>>>> ====
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> - abstracts transport layer (leaving developer in
> >>>>>>>> > > >>>>> standard
> >>>>>>>> > > >>>>> Java
> >>>>>>>> > > >>>>> api)
> >>>>>>>> > > >>>>> - typesafe code (no need to mess with XML bulks)
> >>>>>>>> > > >>>>> - has own data objects to work with
> >>>>>>>> > > >>>>> - abstracts authentication/authorization
> >>>>>>>> > > >>>>> (kerberos/cookie/session/etc.)
> >>>>>>>> > > >>>>> - since SDK is auto-generated, it can be easily
> >>>>>>>> > > >>>>> extended with
> >>>>>>>> > > >>>>> required
> >>>>>>>> > > >>>>>   features to support UI (such as callback
> >>>>>>>> > > >>>>>   infrastructure for
> >>>>>>>> > > >>>>>   instance)
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> cons
> >>>>>>>> > > >>>>> ====
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> - has to be converted in to Javascript (not sure
> >>>>>>>> > > >>>>> what the
> >>>>>>>> > > >>>>> impacts
> >>>>>>>> > > >>>>> are
> >>>>>>>> > > >>>>> in terms of AJAX calls/etc.)
> >>>>>>>> > > >>>>> - probably much more cons that we're not aware of
> >>>>>>>> > > >>>>> and will
> >>>>>>>> > > >>>>> have
> >>>>>>>> > > >>>>> to
> >>>>>>>> > > >>>>> figure out with POC
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> thoughts?
> >>>>>>>> > > >>>>>
> >>>>>>>> > > >>>>> [1] http[s]://server[:port]/api?schema
> >>>>>>>> > > >>>>> [2] http[s]://server[:port]/api?rsdl
> >>>>>>>> > > >>>>>
> >>>>>>> > > >>>>
> >>>>>>> > > >>>> Although started as a UI request, there are other
> >>>>>>> > > >>>> needs who
> >>>>>>> > > >>>> wish
> >>>>>>> > > >>>> to use API calls with a different transport. For
> >>>>>>> > > >>>> example a
> >>>>>>> > > >>>> backend
> >>>>>>> > > >>>> hook which gets a REST entry point it can use to
> >>>>>>> > > >>>> fetch for
> >>>>>>> > > >>>> additional
> >>>>>>> > > >>>> data, or perform actions. In this case I'd expect an
> >>>>>>> > > >>>> internal
> >>>>>>> > > >>>> connection
> >>>>>>> > > >>>> rather than creating additional connections.
> >>>>>>> > > >>>> How would you resolve it generically enough in this
> >>>>>>> > > >>>> context?
> >>>>>> > > >>>
> >>>>>> > > >>> Doron,
> >>>>>> > > >>>
> >>>>>> > > >>> I believe your approach a bit different, UX folks
> >>>>>> > > >>> seeking for a
> >>>>>> > > >>> convenient
> >>>>>> > > >>> way of communicating with ovirt public api, e.g
> >>>>>> > > >>> closing
> >>>>>> > > >>> api<->GUI
> >>>>>> > > >>> gap, and
> >>>>>> > > >>> theirs alternatives where native HTTP layer or
> >>>>>> > > >>> Java-SDK based
> >>>>>> > > >>> framework,
> >>>>>> > > >>> while what you need is in-process channel to
> >>>>>> > > >>> communicate with
> >>>>>> > > >>> the
> >>>>>> > > >>> engine itself,
> >>>>>> > > >>>
> >>>>>> > > >>> i understanding your will of using stable api for this
> >>>>>> > > >>> (RESTapi),
> >>>>>> > > >>> but
> >>>>>> > > >>> not
> >>>>>> > > >>> sure that doing this via JavaSDK is a good way to go
> >>>>>> > > >>> simply
> >>>>>> > > >>> because
> >>>>>> > > >>> SDK is
> >>>>>> > > >>> designed to operate in a client-space, while what you
> >>>>>> > > >>> need is a
> >>>>>> > > >>> server-space
> >>>>>> > > >>> bridge for that.
> >>>>>> > > >>>
> >>>>> > > >>
> >>>>> > > >> Michael, true but...
> >>>>> > > >> Thinking about it differently both UI and hooks needs a
> >>>>> > > >> client.
> >>>>> > > >> The underlying protocols should be abstracted. This is
> >>>>> > > >> something
> >>>>> > > >> which will serve other functions as well.
> >>>>> > > >>
> >>>> > > > 
> >>>> > > > I'm not sure we would need a new abstraction here.
> >>>> > > > Both UI plugins and engine plugins need some API to do
> >>>> > > > basic
> >>>> > > > operations, and have access to different properties in the
> >>>> > > > engine.
> >>> > > 
> >>> > > +1, that's exactly what i've suggested to begin with.
> >>> > > 
> >> > 
> >> > The only issue is that UI plugins and engine plugins shave
> >> > different
> >> > expectations
> >> > from performance point of view. If UI is willing to wait for a
> >> > refresh that may
> >> > take too long for engine plugins, which would prefer to get the
> >> > information as
> >> > soon as possible without going into various communication layers
> >> > which are not
> >> > always needed. So again- a simple solution which enables
> >> > transports
> >> > layers to
> >> > be replaced may serve more than one functionality in a better
> >> > way.
> >> > 
> > Let's start with the simple solution. We don't know yet who will
> > the plugins, how would they be used, and whether using the SDK
> > will be a bottleneck of any kind. If the proposed solution is to
> > support different transport layers while still using the SDK, then
> > it is an extension we can always do in the future, if we find it
> > of high benefit.
> > (btw, regardless of that, the API/SDK is now faster than in the
> > past, as we support REST sessions, which removes the need to
> > re-authenticate upon each API request).
> > 
> 
> true, but the real bottleneck is sending XML bulks over the wire +
> bi-directional marshalling X 2 (engine<->api + api<->xml).
> 
Here we're in agreement.



From dfediuck at redhat.com  Mon Feb 25 13:24:31 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 25 Feb 2013 08:24:31 -0500 (EST)
Subject: [Engine-devel] REST API calls from
In-Reply-To: <1605013790.7186572.1361743009535.JavaMail.root@redhat.com>
Message-ID: <1627541299.8876315.1361798671082.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> To: "Doron Fediuck" <dfediuck at redhat.com>
> Cc: engine-devel at ovirt.org, arch at ovirt.org
> Sent: Sunday, February 24, 2013 11:56:49 PM
> Subject: Re: [Engine-devel] REST API calls from
> 
> 
> 
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck at redhat.com>
> > To: "Oved Ourfalli" <ovedo at redhat.com>
> > Cc: engine-devel at ovirt.org, arch at ovirt.org
> > Sent: Sunday, February 24, 2013 3:55:28 PM
> > Subject: Re: [Engine-devel] REST API calls from
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Oved Ourfalli" <ovedo at redhat.com>
> > > To: "Doron Fediuck" <dfediuck at redhat.com>
> > > Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > Sent: Sunday, February 24, 2013 3:01:19 PM
> > > Subject: Re: [Engine-devel] REST API calls from
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > To: "Michael Pasternak" <mpastern at redhat.com>
> > > > Cc: "Oved Ourfalli" <ovedo at redhat.com>, engine-devel at ovirt.org,
> > > > arch at ovirt.org
> > > > Sent: Sunday, February 24, 2013 1:20:12 PM
> > > > Subject: Re: [Engine-devel] REST API calls from
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Michael Pasternak" <mpastern at redhat.com>
> > > > > To: "Oved Ourfalli" <ovedo at redhat.com>
> > > > > Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > > > Sent: Sunday, February 24, 2013 9:47:28 AM
> > > > > Subject: Re: [Engine-devel] REST API calls from
> > > > > 
> > > > > On 02/24/2013 09:05 AM, Oved Ourfalli wrote:
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message -----
> > > > > >> From: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > >> To: "Michael Pasternak" <mpastern at redhat.com>
> > > > > >> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > > > >> Sent: Thursday, February 21, 2013 6:54:59 PM
> > > > > >> Subject: Re: [Engine-devel] REST API calls from
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> ----- Original Message -----
> > > > > >>> From: "Michael Pasternak" <mpastern at redhat.com>
> > > > > >>> To: "Doron Fediuck" <dfediuck at redhat.com>
> > > > > >>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > > > >>> Sent: Wednesday, February 20, 2013 2:56:59 PM
> > > > > >>> Subject: Re: [Engine-devel] REST API calls from
> > > > > >>>
> > > > > >>> On 02/14/2013 11:20 AM, Doron Fediuck wrote:
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> ----- Original Message -----
> > > > > >>>>> From: "Michael Pasternak" <mpastern at redhat.com>
> > > > > >>>>> To: "Libor Spevak" <lspevak at redhat.com>
> > > > > >>>>> Cc: engine-devel at ovirt.org, arch at ovirt.org
> > > > > >>>>> Sent: Wednesday, February 13, 2013 12:55:36 PM
> > > > > >>>>> Subject: Re: [Engine-devel] REST API calls from the GUI
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> Hi Libor,
> > > > > >>>>>
> > > > > >>>>> This issue came across in one of the conversations i
> > > > > >>>>> had
> > > > > >>>>> with
> > > > > >>>>> UX
> > > > > >>>>> folks, but since we didn't end
> > > > > >>>>> up with any conclusion/road map (nor discussed it
> > > > > >>>>> properly
> > > > > >>>>> to
> > > > > >>>>> hear
> > > > > >>>>> other thoughts), this is a perfect
> > > > > >>>>> place to start this discussion,
> > > > > >>>>>
> > > > > >>>>> Intuitively REST is a way to go with GWT AJAX calls
> > > > > >>>>> ---------------------------------------------------
> > > > > >>>>>
> > > > > >>>>> pros
> > > > > >>>>> ====
> > > > > >>>>>
> > > > > >>>>> - api data objects can be reused by generating java
> > > > > >>>>> classes
> > > > > >>>>> (using
> > > > > >>>>> jaxb) from the rest schema [1]
> > > > > >>>>> - no backend logic will be duplicated as api abstracts
> > > > > >>>>> the
> > > > > >>>>> backend
> > > > > >>>>> exposing RESTful collection/resources to operate on
> > > > > >>>>> - development against api is "easy" as api describes
> > > > > >>>>> itself
> > > > > >>>>> in
> > > > > >>>>> RSDL
> > > > > >>>>> [2]
> > > > > >>>>>
> > > > > >>>>> cons
> > > > > >>>>> ====
> > > > > >>>>>
> > > > > >>>>> - implementing transport layer (HTTP) under GWT
> > > > > >>>>> - implementing own j2xml/json/yaml/... marshalling
> > > > > >>>>> layer
> > > > > >>>>> - implementing own error handling mechanism
> > > > > >>>>> - implementing REST callback mechanism (in GWT)
> > > > > >>>>> - constant maintenance of the data objects generated
> > > > > >>>>> from
> > > > > >>>>> the
> > > > > >>>>> api
> > > > > >>>>> - painful for Java developers
> > > > > >>>>>
> > > > > >>>>> Java-SDK
> > > > > >>>>> --------
> > > > > >>>>>
> > > > > >>>>> pros
> > > > > >>>>> ====
> > > > > >>>>>
> > > > > >>>>> - abstracts transport layer (leaving developer in
> > > > > >>>>> standard
> > > > > >>>>> Java
> > > > > >>>>> api)
> > > > > >>>>> - typesafe code (no need to mess with XML bulks)
> > > > > >>>>> - has own data objects to work with
> > > > > >>>>> - abstracts authentication/authorization
> > > > > >>>>> (kerberos/cookie/session/etc.)
> > > > > >>>>> - since SDK is auto-generated, it can be easily
> > > > > >>>>> extended
> > > > > >>>>> with
> > > > > >>>>> required
> > > > > >>>>>   features to support UI (such as callback
> > > > > >>>>>   infrastructure
> > > > > >>>>>   for
> > > > > >>>>>   instance)
> > > > > >>>>>
> > > > > >>>>> cons
> > > > > >>>>> ====
> > > > > >>>>>
> > > > > >>>>> - has to be converted in to Javascript (not sure what
> > > > > >>>>> the
> > > > > >>>>> impacts
> > > > > >>>>> are
> > > > > >>>>> in terms of AJAX calls/etc.)
> > > > > >>>>> - probably much more cons that we're not aware of and
> > > > > >>>>> will
> > > > > >>>>> have
> > > > > >>>>> to
> > > > > >>>>> figure out with POC
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> thoughts?
> > > > > >>>>>
> > > > > >>>>> [1] http[s]://server[:port]/api?schema
> > > > > >>>>> [2] http[s]://server[:port]/api?rsdl
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>> Although started as a UI request, there are other needs
> > > > > >>>> who
> > > > > >>>> wish
> > > > > >>>> to use API calls with a different transport. For example
> > > > > >>>> a
> > > > > >>>> backend
> > > > > >>>> hook which gets a REST entry point it can use to fetch
> > > > > >>>> for
> > > > > >>>> additional
> > > > > >>>> data, or perform actions. In this case I'd expect an
> > > > > >>>> internal
> > > > > >>>> connection
> > > > > >>>> rather than creating additional connections.
> > > > > >>>> How would you resolve it generically enough in this
> > > > > >>>> context?
> > > > > >>>
> > > > > >>> Doron,
> > > > > >>>
> > > > > >>> I believe your approach a bit different, UX folks seeking
> > > > > >>> for
> > > > > >>> a
> > > > > >>> convenient
> > > > > >>> way of communicating with ovirt public api, e.g closing
> > > > > >>> api<->GUI
> > > > > >>> gap, and
> > > > > >>> theirs alternatives where native HTTP layer or Java-SDK
> > > > > >>> based
> > > > > >>> framework,
> > > > > >>> while what you need is in-process channel to communicate
> > > > > >>> with
> > > > > >>> the
> > > > > >>> engine itself,
> > > > > >>>
> > > > > >>> i understanding your will of using stable api for this
> > > > > >>> (RESTapi),
> > > > > >>> but
> > > > > >>> not
> > > > > >>> sure that doing this via JavaSDK is a good way to go
> > > > > >>> simply
> > > > > >>> because
> > > > > >>> SDK is
> > > > > >>> designed to operate in a client-space, while what you
> > > > > >>> need
> > > > > >>> is
> > > > > >>> a
> > > > > >>> server-space
> > > > > >>> bridge for that.
> > > > > >>>
> > > > > >>
> > > > > >> Michael, true but...
> > > > > >> Thinking about it differently both UI and hooks needs a
> > > > > >> client.
> > > > > >> The underlying protocols should be abstracted. This is
> > > > > >> something
> > > > > >> which will serve other functions as well.
> > > > > >>
> > > > > > 
> > > > > > I'm not sure we would need a new abstraction here.
> > > > > > Both UI plugins and engine plugins need some API to do
> > > > > > basic
> > > > > > operations, and have access to different properties in the
> > > > > > engine.
> > > > > 
> > > > > +1, that's exactly what i've suggested to begin with.
> > > > > 
> > > > 
> > > > The only issue is that UI plugins and engine plugins shave
> > > > different
> > > > expectations
> > > > from performance point of view. If UI is willing to wait for a
> > > > refresh that may
> > > > take too long for engine plugins, which would prefer to get the
> > > > information as
> > > > soon as possible without going into various communication
> > > > layers
> > > > which are not
> > > > always needed. So again- a simple solution which enables
> > > > transports
> > > > layers to
> > > > be replaced may serve more than one functionality in a better
> > > > way.
> > > > 
> > > 
> > > Let's start with the simple solution. We don't know yet who will
> > > the
> > > plugins, how would they be used, and whether using the SDK will
> > > be
> > > a
> > > bottleneck of any kind. If the proposed solution is to support
> > > different transport layers while still using the SDK, then it is
> > > an
> > > extension we can always do in the future, if we find it of high
> > > benefit.
> > > (btw, regardless of that, the API/SDK is now faster than in the
> > > past,
> > > as we support REST sessions, which removes the need to
> > > re-authenticate upon each API request).
> > > 
> > 
> > Oved, we have pretty good idea on how it will be used and what will
> > create performance hits. Otherwise we wouldn't have had this
> > thread.
> > 
> If so, it would be nice if you share this information on the thread
> as well... some use-cases, some statistics you may have on the
> current performance, and on the performance requirements, and etc.
> I'm not saying that you're wrong... just saying I wasn't convinced it
> is really necessary.
> 
> Thank you,
> Oved

Think of intensive calls to an external scheduling 'hook'. We had a few
threads about it in the past, and there's a wiki (being reworked now).
Since you can never anticipate the information that hook will need, we
should allow it to use REST API to fetch the information it needs from
the backend. As Michael already answered opening a client in that hook
will not be the optimal solution if it needs to open TCP connections.

> > > > > > In the UI plguins implementation, we gave this API, and in
> > > > > > addition
> > > > > > created a REST session to be used in order to do more
> > > > > > sophisticated operations.
> > > > > > I think we should probably do the same for engine plugins,
> > > > > > giving the basic API, and giving a REST session for more
> > > > > > advanced
> > > > > > operations.
> > > > > > The engine plugin may also have another 3rd party
> > > > > > application
> > > > > > it
> > > > > > interacts with, and it would be able to share this session
> > > > > > with
> > > > > > it,
> > > > > > allowing it to perform different operations on the engine.
> > > > > > It
> > > > > > would
> > > > > > obviously be easy to do that using the Java SDK in the
> > > > > > engine
> > > > > > side,
> > > > > > without creating a new layer of abstraction.
> > > > > 
> > > > > true, but the thing is that java-sdk designed to work with
> > > > > rest-api,
> > > > > and what Doron is trying to do
> > > > > is saving round-trip of engine->sdk->api->engine by enabling
> > > > > extra
> > > > > layer in sdk that will work not via HTTP,
> > > > > but natively with RESTeasy (REST framework we using in api),
> > > > > the
> > > > > disadvantages of such design are:
> > > > > 
> > > > > 1. working with java-sdk via JNI (walking out from container
> > > > > to
> > > > > client application - sdk)
> > > > > 2. hacking RESTeasy by:
> > > > >    2.1 working with underlying (not public/backward
> > > > >    compatible)
> > > > >    interfaces & using JNI as well
> > > > >    2.2 most likely maintaining code working with RESTeasy on
> > > > >    every
> > > > >    new (RESTeasy) release by reverse
> > > > >        engineering new changes/behaviour of this framework
> > > > >    2.3 making assumptions on code invocations to emulate
> > > > >    GET/POST/PUT/DELETE HTTP calls
> > > > >    2.4 still having round-trip engine->sdk->RESTeasy->engine
> > > > > 
> > > > > therefore i think that having own private API in engine for
> > > > > that
> > > > > is
> > > > > a
> > > > > much better solution.
> > > > > 
> > > > > > I assume the 3rd party application will use either the Java
> > > > > > SDK,
> > > > > > or
> > > > > > another one, according the platform it is built upon, and
> > > > > > in
> > > > > > the
> > > > > > "worst case", will interact directly with the API.
> > > > > > 
> > > > > > 
> > > > > >>>>
> > > > > >>>>> On 02/12/2013 06:13 PM, Libor Spevak wrote:
> > > > > >>>>>> Hi,
> > > > > >>>>>>
> > > > > >>>>>> I would like to ask, if there have been discussions
> > > > > >>>>>> about
> > > > > >>>>>> an
> > > > > >>>>>> option
> > > > > >>>>>> to call REST API services directly from the Frontend
> > > > > >>>>>> (GWT
> > > > > >>>>>> layer)?
> > > > > >>>>>> GWT compiles Java frontend-side to
> > > > > >>>>>> Javascript, calls to backend services are performed
> > > > > >>>>>> "transparently"
> > > > > >>>>>> by the framework using AJAX support. But, there is
> > > > > >>>>>> still
> > > > > >>>>>> a
> > > > > >>>>>> need
> > > > > >>>>>> to
> > > > > >>>>>> have a special set of data objects
> > > > > >>>>>> and the server-side logic can duplicate.
> > > > > >>>>>>
> > > > > >>>>>> Java REST API SDK enables to build "thick" client. The
> > > > > >>>>>> calls
> > > > > >>>>>> are
> > > > > >>>>>> realized using e.g. Apache HttClient and supported
> > > > > >>>>>> libraries.
> > > > > >>>>>> I
> > > > > >>>>>> think the requirements of GWT can be a
> > > > > >>>>>> little bit different, but something overlaps.
> > > > > >>>>>>
> > > > > >>>>>> I found several links about REST API support from GWT,
> > > > > >>>>>> so
> > > > > >>>>>> there
> > > > > >>>>>> is
> > > > > >>>>>> something for inspiration...
> > > > > >>>>>>
> > > > > >>>>>> - http://www.spiffyui.org/
> > > > > >>>>>> - http://www.zackgrossbart.com/hackito/gwt-rest/
> > > > > >>>>>> - http://code.google.com/p/gwt-rest/
> > > > > >>>>>> - http://restygwt.fusesource.org/
> > > > > >>>>>>
> > > > > >>>>>> But, do you think it would be useful and what
> > > > > >>>>>> drawbacks
> > > > > >>>>>> can
> > > > > >>>>>> occur
> > > > > >>>>>> (authentication, authorization, response times, need
> > > > > >>>>>> to
> > > > > >>>>>> support
> > > > > >>>>>> larger set of services, painful
> > > > > >>>>>> refactoring, ...)?
> > > > > >>>>>>
> > > > > >>>>>> Regards,
> > > > > >>>>>> Libor
> > > > > >>>>>>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From dfediuck at redhat.com  Mon Feb 25 14:13:28 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 25 Feb 2013 09:13:28 -0500 (EST)
Subject: [Engine-devel] Secret quartz update checks
Message-ID: <529093685.8980580.1361801608275.JavaMail.root@redhat.com>

Hi,
While deploying a development setup in a new machine I noticed the following quartz line:

2013-02-25 16:10:28,546 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "engine.ear"
2013-02-25 16:10:30,143 INFO  [org.quartz.utils.UpdateChecker] (Timer-1) New Quartz update(s) found: 2.1.6 [http://www.terracotta.org/kit/reflector?kitID=default&pageID=QuartzChangeLog]

This is suggesting that quartz is reaching out to verify on new updates.
Do we really need it?
Do we really want it?


From jhernand at redhat.com  Mon Feb 25 14:14:41 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 25 Feb 2013 15:14:41 +0100
Subject: [Engine-devel] Secret quartz update checks
In-Reply-To: <529093685.8980580.1361801608275.JavaMail.root@redhat.com>
References: <529093685.8980580.1361801608275.JavaMail.root@redhat.com>
Message-ID: <512B71D1.1010706@redhat.com>

On 02/25/2013 03:13 PM, Doron Fediuck wrote:
> Hi,
> While deploying a development setup in a new machine I noticed the following quartz line:
>
> 2013-02-25 16:10:28,546 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "engine.ear"
> 2013-02-25 16:10:30,143 INFO  [org.quartz.utils.UpdateChecker] (Timer-1) New Quartz update(s) found: 2.1.6 [http://www.terracotta.org/kit/reflector?kitID=default&pageID=QuartzChangeLog]
>
> This is suggesting that quartz is reaching out to verify on new updates.
> Do we really need it?
> Do we really want it?
>

Yes, it is indeed calling home, which is bad from the security point of 
view. We must disable it.

-- 
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.


From jhernand at redhat.com  Mon Feb 25 14:39:21 2013
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 25 Feb 2013 15:39:21 +0100
Subject: [Engine-devel] Secret quartz update checks
In-Reply-To: <512B71D1.1010706@redhat.com>
References: <529093685.8980580.1361801608275.JavaMail.root@redhat.com>
	<512B71D1.1010706@redhat.com>
Message-ID: <512B7799.9070109@redhat.com>

On 02/25/2013 03:14 PM, Juan Hernandez wrote:
> On 02/25/2013 03:13 PM, Doron Fediuck wrote:
>> Hi,
>> While deploying a development setup in a new machine I noticed the following quartz line:
>>
>> 2013-02-25 16:10:28,546 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "engine.ear"
>> 2013-02-25 16:10:30,143 INFO  [org.quartz.utils.UpdateChecker] (Timer-1) New Quartz update(s) found: 2.1.6 [http://www.terracotta.org/kit/reflector?kitID=default&pageID=QuartzChangeLog]
>>
>> This is suggesting that quartz is reaching out to verify on new updates.
>> Do we really need it?
>> Do we really want it?
>>
>
> Yes, it is indeed calling home, which is bad from the security point of
> view. We must disable it.
>

The following patch should avoid that, I appreciate if you can review 
and test it:

http://gerrit.ovirt.org/12411

-- 
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.


From dfediuck at redhat.com  Mon Feb 25 17:04:14 2013
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 25 Feb 2013 12:04:14 -0500 (EST)
Subject: [Engine-devel] Changing Gerrit -1 message
In-Reply-To: <512717F0.70809@redhat.com>
Message-ID: <1197396362.9574618.1361811854318.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Moti Asayag" <masayag at redhat.com>
> To: "Eli Mesika" <emesika at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Friday, February 22, 2013 9:02:08 AM
> Subject: Re: [Engine-devel] Changing Gerrit -1 message
> 
> On 02/22/2013 12:53 AM, Eli Mesika wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Dave Neary" <dneary at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Thursday, February 21, 2013 11:21:53 PM
> >> Subject: Re: [Engine-devel] Changing Gerrit -1 message
> >>
> >> Hi,
> >>
> >> On 02/20/2013 10:32 AM, Itamar Heim wrote:
> >>> On 19/02/2013 12:06, Laszlo Hornyak wrote:
> >>>> Hi,
> >>>>
> >>>> I agree with that.
> >>>>
> >>>> for the - messages this in my opinion would be both more clear
> >>>> and
> >>>> friendly:
> >>>> -1: In my opinion it needs work.
> >>>
> >>>
> >>> how about
> >>> "-1: Please review my comments"
> > 
> > +1
> 
> +1
> 

Seems that we're in agreement on this one....

> > 
> >>
> >> Sounds great.
> >>
> >>>> -2: I disagree.
> > 
> > I prefer -2 : Do not submit!
> > 
> > IMHO:
> > -1 should be used whenever the code is OK but can be done better or
> > has a missing part (tests for example)
> > -2 should be used when the code does not work, has a serious bug
> > (possible NPE for example) , break the build
> 
> +1 for the -2 which to my opinion should indicate any serious flaw in
> the design, even post the design discussion. I think that this should
> follow with a discussion on engine-devel about the required change in
> the design instead of debating over the gerrit since it is not
> transparent enough.
> 

-2 should be given on rare occasions, as it is so blunt and meaningful.
Remember that -1 is good enough to block a patch.
So if you see an issue which may be fixed, give it -1.

If you see something which is illegal (violate project license) or
contradicts the project foundations, give it -2. This is how rare -2
should be.

In this view I'd rephrase "-2" to: "This patch can not be accepted".
Obviously this should be followed by a detailed explanation by the reviewer.

> > 
> >>>
> >>> "-2: Please reconsider"
> >>
> >> I am trying to think under which circumstances people give a -2.
> >> Maybe
> >> something like "We have discussed this feature, and I disagree
> >> that
> >> it
> >> is good for the project." Basically, I don't think that a
> >> developer
> >> should ever see a -2, unless they specifically disagree with the
> >> maintainer, and insist that they are right, to the point of
> >> repeatedly
> >> submitting patches.
> >>
> >> Cheers,
> >> Dave.
> >>


From mpastern at redhat.com  Mon Feb 25 18:24:24 2013
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 25 Feb 2013 20:24:24 +0200
Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.4-1 released
In-Reply-To: <512B4ADC.1000107@redhat.com>
References: <512B4ADC.1000107@redhat.com>
Message-ID: <512BAC58.1080003@redhat.com>

- implement SSL support (without host verification)
- implement shutdown() to deallocate system resources
- to cluster added tunnel_migration property
- to DataCenter added Clusters sub-collection
- to root collection resource Disk added Permissions sub-collectio
- to root collection resource Disk added Statistic sub-collection
- host can be attached to cluster now either by id or name
- to StorageDomainTemplate added Disks sub-collection
- to StorageDomainVM added Disks sub-collection
- to template.display added keyboard_layout property
- to template added tunnel_migration property
- to vm.display added keyboard_layout property
- to vm added tunnel_migration property
- to VMSnapshot added preview method
- to VMSnapshot added undo method
- to VMSnapshot added commit method


More details can be found at [1].

[1] http://www.ovirt.org/Java-sdk-changelog

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mkublin at redhat.com  Tue Feb 26 08:23:01 2013
From: mkublin at redhat.com (Michael Kublin)
Date: Tue, 26 Feb 2013 03:23:01 -0500 (EST)
Subject: [Engine-devel] DB Performance Monitoring
In-Reply-To: <1928179669.5160574.1361486767327.JavaMail.root@redhat.com>
Message-ID: <201401491.5878405.1361866981757.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Eli Mesika" <emesika at redhat.com>
> To: "Libor Spevak" <lspevak at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Friday, February 22, 2013 12:46:07 AM
> Subject: Re: [Engine-devel] DB Performance Monitoring
> 
> 
> 
> ----- Original Message -----
> > From: "Libor Spevak" <lspevak at redhat.com>
> > To: "Eli Mesika" <emesika at redhat.com>
> > Cc: engine-devel at ovirt.org, "Yair Zaslavsky" <yzaslavs at redhat.com>,
> > "Barak Azulay" <bazulay at redhat.com>
> > Sent: Thursday, February 21, 2013 6:50:58 PM
> > Subject: Re: [Engine-devel] DB Performance Monitoring
> > 
> > 
> > On 21.2.2013 17:11, Eli Mesika wrote:
> > 
> > 
> > ----- Original Message -----
> > 
> > From: "Libor Spevak" <lspevak at redhat.com> To:
> > engine-devel at ovirt.org
> > Sent: Tuesday, February 19, 2013 5:44:10 PM
> > Subject: [Engine-devel] DB Performance Monitoring
> > 
> > 
> > Hi,
> > I just wanted to share a partial result from testing of engine db
> > load during operation (SQL queries frequencies). Maybe, we can
> > decide later, if some SQL queries result CACHING can boost
> > throughput for larger deployments.
> > 
> > The caching technology can be from a simple HashMap lookup to
> > deployments of something like http://ehcache.org/ (memory
> > database).
> > 
> > I prepared two simple scenarios:
> > 
> > - oVirt engine, 2 hosts, 1 VM, running 15 minutes (Power on + Up
> > state)
> > - oVirt engine, 2 hosts, 10 VMs from one pool, running 15 minutes
> > (Power on + Up state)
> > 
> > Appending 2 spreadsheets with data about the most used SQL queries
> > (generated by PostgreSQL standard pg_statements_stat module).
> > 
> > e.g.
> > - 2nd row shows number of granted connections from the db pool
> > (e.g.
> > can be used to set optimal connection pool size) (check of
> > connection health: select 1)
> > - most of the queries are wrapped by a PLSQL function so we see a
> > wrapper:
> > 
> > select * from getvdsgroupbyvdsgroupid($1, $2, $3)
> > 
> > and near to it the 'real' query:
> > 
> > SELECT vds_groups_view.*
> > FROM vds_groups_view
> > WHERE vds_group_id = v_vds_group_id
> > AND (NOT v_is_filtered OR EXISTS (SELECT 1
> > FROM user_vds_groups_permissions_view
> > WHERE user_id = v_user_id AND entity_id = v_vds_group_id))
> > 
> > Just as an example, I selected in yellow color some queries, which
> > probably do not change often, but are very frequent. Thanks Libor
> > for
> > taking te time to do that.
> > The problematic queries are those that involves all kinds of
> > *permissions* checks with the complicated & expensive permission
> > handling views.
> > I believe that using Snapshot Materialized Views as defined in
> > http://www.ovirt.org/OVirt-DB-Issues/MaterializedViews will solve
> > the major part of those problems.
> > We are currently verifying this approach and my recommendation is
> > to
> > have all *permissions* views as Snapshot Materialized Views that
> > are
> > updated via a cron job. I think there could be performace
> > improvement with M-views, of course. There is some overhead just
> > with their maintainance, e.g. refreshing, updating existing
> > dependent objects (table name renames, ...),
> 
> Refresh of *permission* views was tested with 2 views 160,000 records
> each and was about 2 sec
> 
> > not sure about NATIVE
> > implementation level status in PostgreSQL, according to e.g. Oracle
> > db capabilities (MV-logs + M-views).
> > 
> > http://wiki.postgresql.org/wiki/Materialized_Views
> 
> AFAIK Postgres is not going to implement that in the near future
> 
> > 
> > Still, if the Engine gathers statistics nearly in real time, my
> > question would be, if there is a need of round-trip to the database
> > and back at all for frequent queries.
> 
> Depends what is the cost of this round-trip , if it is very cheep as
> I showed when I tested M-Views I think that DB query is still a good
> and natural choice
> 
> > 
> > 
> > 
> > 
> > 
> > 
> > Other tools like 'pg_top' can provide runtime statistics of db
> > processes (cpu, mem, locks, ... views).
> > 
> > By enabling debug level logging of PostgreSQL we can check real
> > values to the queries.
> > 
> > Of course, it would be useful to run such tests with many hosts and
> > VMs to predict scaling issues.
> > 
> > More info about tools configuration:
> > http://www.ovirt.org/Engine_database_performance_monitoring
> > Regards,
> > Libor
> > 
Due the following discussion I checked uses of "select * from getvdsgroupbyvdsgroupid($1, $2, $3)"
query and find out that we have three call for such query during monitoring and we need only one,
so the following patch should reduce a number of such queries during monitoring process 
http://gerrit.ovirt.org/#/c/12433/
The next step is, by my opinion, is start to use cache for not often changed object, VdsGroup is classical example of
such object.


From yzaslavs at redhat.com  Tue Feb 26 08:30:10 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 26 Feb 2013 03:30:10 -0500 (EST)
Subject: [Engine-devel] DB Performance Monitoring
In-Reply-To: <201401491.5878405.1361866981757.JavaMail.root@redhat.com>
Message-ID: <849230385.8462464.1361867410043.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Michael Kublin" <mkublin at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, February 26, 2013 10:23:01 AM
> Subject: Re: [Engine-devel] DB Performance Monitoring
> 
> 
> 
> ----- Original Message -----
> > From: "Eli Mesika" <emesika at redhat.com>
> > To: "Libor Spevak" <lspevak at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Friday, February 22, 2013 12:46:07 AM
> > Subject: Re: [Engine-devel] DB Performance Monitoring
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Libor Spevak" <lspevak at redhat.com>
> > > To: "Eli Mesika" <emesika at redhat.com>
> > > Cc: engine-devel at ovirt.org, "Yair Zaslavsky"
> > > <yzaslavs at redhat.com>,
> > > "Barak Azulay" <bazulay at redhat.com>
> > > Sent: Thursday, February 21, 2013 6:50:58 PM
> > > Subject: Re: [Engine-devel] DB Performance Monitoring
> > > 
> > > 
> > > On 21.2.2013 17:11, Eli Mesika wrote:
> > > 
> > > 
> > > ----- Original Message -----
> > > 
> > > From: "Libor Spevak" <lspevak at redhat.com> To:
> > > engine-devel at ovirt.org
> > > Sent: Tuesday, February 19, 2013 5:44:10 PM
> > > Subject: [Engine-devel] DB Performance Monitoring
> > > 
> > > 
> > > Hi,
> > > I just wanted to share a partial result from testing of engine db
> > > load during operation (SQL queries frequencies). Maybe, we can
> > > decide later, if some SQL queries result CACHING can boost
> > > throughput for larger deployments.
> > > 
> > > The caching technology can be from a simple HashMap lookup to
> > > deployments of something like http://ehcache.org/ (memory
> > > database).
> > > 
> > > I prepared two simple scenarios:
> > > 
> > > - oVirt engine, 2 hosts, 1 VM, running 15 minutes (Power on + Up
> > > state)
> > > - oVirt engine, 2 hosts, 10 VMs from one pool, running 15 minutes
> > > (Power on + Up state)
> > > 
> > > Appending 2 spreadsheets with data about the most used SQL
> > > queries
> > > (generated by PostgreSQL standard pg_statements_stat module).
> > > 
> > > e.g.
> > > - 2nd row shows number of granted connections from the db pool
> > > (e.g.
> > > can be used to set optimal connection pool size) (check of
> > > connection health: select 1)
> > > - most of the queries are wrapped by a PLSQL function so we see a
> > > wrapper:
> > > 
> > > select * from getvdsgroupbyvdsgroupid($1, $2, $3)
> > > 
> > > and near to it the 'real' query:
> > > 
> > > SELECT vds_groups_view.*
> > > FROM vds_groups_view
> > > WHERE vds_group_id = v_vds_group_id
> > > AND (NOT v_is_filtered OR EXISTS (SELECT 1
> > > FROM user_vds_groups_permissions_view
> > > WHERE user_id = v_user_id AND entity_id = v_vds_group_id))
> > > 
> > > Just as an example, I selected in yellow color some queries,
> > > which
> > > probably do not change often, but are very frequent. Thanks Libor
> > > for
> > > taking te time to do that.
> > > The problematic queries are those that involves all kinds of
> > > *permissions* checks with the complicated & expensive permission
> > > handling views.
> > > I believe that using Snapshot Materialized Views as defined in
> > > http://www.ovirt.org/OVirt-DB-Issues/MaterializedViews will solve
> > > the major part of those problems.
> > > We are currently verifying this approach and my recommendation is
> > > to
> > > have all *permissions* views as Snapshot Materialized Views that
> > > are
> > > updated via a cron job. I think there could be performace
> > > improvement with M-views, of course. There is some overhead just
> > > with their maintainance, e.g. refreshing, updating existing
> > > dependent objects (table name renames, ...),
> > 
> > Refresh of *permission* views was tested with 2 views 160,000
> > records
> > each and was about 2 sec
> > 
> > > not sure about NATIVE
> > > implementation level status in PostgreSQL, according to e.g.
> > > Oracle
> > > db capabilities (MV-logs + M-views).
> > > 
> > > http://wiki.postgresql.org/wiki/Materialized_Views
> > 
> > AFAIK Postgres is not going to implement that in the near future
> > 
> > > 
> > > Still, if the Engine gathers statistics nearly in real time, my
> > > question would be, if there is a need of round-trip to the
> > > database
> > > and back at all for frequent queries.
> > 
> > Depends what is the cost of this round-trip , if it is very cheep
> > as
> > I showed when I tested M-Views I think that DB query is still a
> > good
> > and natural choice
> > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Other tools like 'pg_top' can provide runtime statistics of db
> > > processes (cpu, mem, locks, ... views).
> > > 
> > > By enabling debug level logging of PostgreSQL we can check real
> > > values to the queries.
> > > 
> > > Of course, it would be useful to run such tests with many hosts
> > > and
> > > VMs to predict scaling issues.
> > > 
> > > More info about tools configuration:
> > > http://www.ovirt.org/Engine_database_performance_monitoring
> > > Regards,
> > > Libor
> > > 
> Due the following discussion I checked uses of "select * from
> getvdsgroupbyvdsgroupid($1, $2, $3)"
> query and find out that we have three call for such query during
> monitoring and we need only one,
> so the following patch should reduce a number of such queries during
> monitoring process
> http://gerrit.ovirt.org/#/c/12433/

ACK, thanks for that.

> The next step is, by my opinion, is start to use cache for not often
> changed object, VdsGroup is classical example of
> such object.

+1 - and another issue I wanted to take a look into - Please notice we have entities representing views.
I have a feeling we abuse VM (for example) too much - we use AuditLoggableBase to "cache" vm - but still - I bet that in some flows
we don't need the entire VM -> we might need only static (or dynamic part) of it.
We should take a look into this as well . Getting vm dynamic from db instead of vm means less joins.
Same applies for vds and storage_domains

Yair

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From wei.d.chen at intel.com  Tue Feb 26 09:00:57 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Tue, 26 Feb 2013 09:00:57 +0000
Subject: [Engine-devel] How to debug in frontend project
Message-ID: <C5A0092C63E939488005F15F736A811209798265@SHSMSX101.ccr.corp.intel.com>

Hi,

How to debug the code in frontend project? I mean, print out some debug message from "onSave" method in the java file of "VmListModel.java" which is located in uicommonweb project. Thanks in advance.

Best Regards,
Dave Chen




From omasad at redhat.com  Tue Feb 26 09:20:19 2013
From: omasad at redhat.com (Ofri Masad)
Date: Tue, 26 Feb 2013 04:20:19 -0500 (EST)
Subject: [Engine-devel] How to debug in frontend project
In-Reply-To: <C5A0092C63E939488005F15F736A811209798265@SHSMSX101.ccr.corp.intel.com>
Message-ID: <934551863.3516395.1361870419314.JavaMail.root@redhat.com>

Hi,

Not sure this it what you've meant, but gwt allows you to debug directly from your IDE.
Here is how:
 - compile using maven
 - go to: frontend/webadmin/modules/webadmin
 - run:   mvn clean gwt:debug -Pgwt-admin,gwtdev    
   (This will invoke a maven build which will get to the line: "[INFO] Listening for transport dt_socket at address: 8000")
 - Create a debug configuration on your IDE for remote debug on host:localhost port:8000
 - Debug using the IDE
   (The IDE debug would launch a gwt tool which would allow you to activate the webadmin on you browser)
 
* after activating the webadmin on the browser via the gwt tool, be patient - it takes few minutes to load.

Ofri

----- Original Message -----
> From: "Wei D Chen" <wei.d.chen at intel.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, February 26, 2013 11:00:57 AM
> Subject: [Engine-devel] How to debug in frontend project
> 
> Hi,
> 
> How to debug the code in frontend project? I mean, print out some
> debug message from "onSave" method in the java file of
> "VmListModel.java" which is located in uicommonweb project. Thanks
> in advance.
> 
> Best Regards,
> Dave Chen
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lspevak at redhat.com  Tue Feb 26 12:37:17 2013
From: lspevak at redhat.com (Libor Spevak)
Date: Tue, 26 Feb 2013 13:37:17 +0100
Subject: [Engine-devel] Engine table comments
Message-ID: <512CAC7D.2060900@redhat.com>

Hi,
I would like to propose to create a patch assigning sql comment to each 
Engine table.
The comments will be a part of the exported DB schema report, too.
The terminology is not always consistent across all application layers, 
so for the newcomers it would be easier to understand the model.

But, what would be general guidelines?

I recommend to use singular form of entity name as used from end-user 
point of view (if somehow visible, of course), or just used frequently 
inside code.

Examples:
storage_pool ... Data center
vds_groups ... Cluster
but:
vm_static  ... Virtual machine configuration
vm_dynamic ... Virtual machine runtime data
vm_statistics ... Virtual machine statistics data
...
etc.

This command prepares a template for the patch:

/psql engine -U postgres -c "select 'COMMENT ON TABLE ' || relname || ' 
IS ''TODO'';' sql from pg_stat_user_tables t WHERE schemaname='public' 
order by t.relname" > comments_to_do.sql//
/
or just I can prepare a page on the wiki with table containing table 
names and volunteers :-) can propose simple understandable comments for 
known tables.

Is it useful?

Thanks.

Regards,
Libor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130226/450e6cba/attachment.html>

From yzaslavs at redhat.com  Tue Feb 26 14:03:15 2013
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 26 Feb 2013 09:03:15 -0500 (EST)
Subject: [Engine-devel] Engine table comments
In-Reply-To: <512CAC7D.2060900@redhat.com>
Message-ID: <1733089166.8628739.1361887395043.JavaMail.root@redhat.com>

I think your idea is very good. 
I also think we should have it for columns as well. 
But since we already have many columns, maybe we should have an "on going effort" from various developers on this (i.e - each developer will do that for several tables). 
Thoughts? 

----- Original Message -----

> From: "Libor Spevak" <lspevak at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, February 26, 2013 2:37:17 PM
> Subject: [Engine-devel] Engine table comments

> Hi,
> I would like to propose to create a patch assigning sql comment to
> each Engine table.
> The comments will be a part of the exported DB schema report, too.
> The terminology is not always consistent across all application
> layers, so for the newcomers it would be easier to understand the
> model.

> But, what would be general guidelines?

> I recommend to use singular form of entity name as used from end-user
> point of view (if somehow visible, of course), or just used
> frequently inside code.

> Examples:
> storage_pool ... Data center
> vds_groups ... Cluster
> but:
> vm_static ... Virtual machine configuration
> vm_dynamic ... Virtual machine runtime data
> vm_statistics ... Virtual machine statistics data
> ...
> etc.

> This command prepares a template for the patch:

> psql engine -U postgres -c "select 'COMMENT ON TABLE ' || relname ||
> ' IS ''TODO'';' sql from pg_stat_user_tables t WHERE
> schemaname='public' order by t.relname" > comments_to_do.sql

> or just I can prepare a page on the wiki with table containing table
> names and volunteers :-) can propose simple understandable comments
> for known tables.

> Is it useful?

> Thanks.

> Regards,
> Libor

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130226/f5d63ca9/attachment.html>

From wei.d.chen at intel.com  Wed Feb 27 06:07:01 2013
From: wei.d.chen at intel.com (Chen, Wei D)
Date: Wed, 27 Feb 2013 06:07:01 +0000
Subject: [Engine-devel] How to debug in frontend project
In-Reply-To: <934551863.3516395.1361870419314.JavaMail.root@redhat.com>
References: <C5A0092C63E939488005F15F736A811209798265@SHSMSX101.ccr.corp.intel.com>
	<934551863.3516395.1361870419314.JavaMail.root@redhat.com>
Message-ID: <C5A0092C63E939488005F15F736A811209798369@SHSMSX101.ccr.corp.intel.com>

Hi Ofri, 

Thanks for your reply.

We follow the instructions, and we can see the similar information about the opened debug port, that is, " [INFO] Listening for transport dt_socket at address: 8000". My understanding is compiler is okay and the debug port is available.
But, when I remote access to this host via Eclipse, the connection abort immediately. Some difference after compare with the instruction is, our IDE is installed on a windows OS and build env is on a linux OS, they are different physical machine, this shouldn't be the root cause in my opinion, remote debug from a remote server is make sense always. Any good suggestion? Thanks a lot!


Here is some error message I get after the connection is aborted.

[ERROR] [AppClassLoader at 55a6c368] info AspectJ Weaver Version 1.6.11 built on Tuesday Mar 15, 2011 at 15:31:04 GMT
[ERROR] [AppClassLoader at 55a6c368] info register classloader sun.misc.Launcher$AppClassLoader at 55a6c368
[ERROR] [AppClassLoader at 55a6c368] info using configuration file:/home/ldq/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.2.0/gwt-extension-3.2.0.jar!/META-INF/aop.xml
[ERROR] [AppClassLoader at 55a6c368] info using configuration file:/home/ldq/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.2.0/gwt-extension-3.2.0-sources.jar!/META-INF/aop.xml
[ERROR] [AppClassLoader at 55a6c368] info register aspect org.ovirt.engine.ui.gwtextension.DontPrune
[ERROR] [AppClassLoader at 55a6c368] info register aspect org.ovirt.engine.ui.gwtextension.DontPrune
[ERROR] -bindAddress host "0.0.0.0" unknown
[ERROR] Google Web Toolkit 2.3.0
[ERROR] DevMode [-noserver] [-port port-number | "auto"] [-whitelist whitelist-string] [-blacklist blacklist-string] [-logdir directory] [-logLevel level] [-gen dir] [-bindAddress host-name-or-address] [-codeServerPort port-number | "auto"] [-server servletContainerLauncher[:args]] [-startupUrl url] [-war dir] [-deploy dir] [-extra dir] [-workDir dir] module[s]
[ERROR]
[ERROR] where
[ERROR]   -noserver        Prevents the embedded web server from running
[ERROR]   -port            Specifies the TCP port for the embedded web server (defaults to 8888)
[ERROR]   -whitelist       Allows the user to browse URLs that match the specified regexes (comma or space separated)
[ERROR]   -blacklist       Prevents the user browsing URLs that match the specified regexes (comma or space separated)
[ERROR]   -logdir          Logs to a file in the given directory, as well as graphically
[ERROR]   -logLevel        The level of logging detail: ERROR, WARN, INFO, TRACE, DEBUG, SPAM, or ALL
[ERROR]   -gen             Debugging: causes normally-transient generated types to be saved in the specified directory
[ERROR]   -bindAddress     Specifies the bind address for the code server and web server (defaults to 127.0.0.1)
[ERROR]   -codeServerPort  Specifies the TCP port for the code server (defaults to 9997)
[ERROR]   -server          Specify a different embedded web server to run (must implement ServletContainerLauncher)
[ERROR]   -startupUrl      Automatically launches the specified URL
[ERROR]   -war             The directory into which deployable output files will be written (defaults to 'war')
[ERROR]   -deploy          The directory into which deployable but not servable output files will be written (defaults to 'WEB-INF/deploy' under the -war directory/jar, and may be the same as the -extra directory/jar)
[ERROR]   -extra           The directory into which extra files, not intended for deployment, will be written
[ERROR]   -workDir         The compiler's working directory for internal use (must be writeable; defaults to a system temp dir)
[ERROR] and
[ERROR]   module[s]        Specifies the name(s) of the module(s) to host
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:43.341s
[INFO] Finished at: Wed Feb 27 13:44:31 CST 2013
[INFO] Final Memory: 38M/357M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:2.3.0-1:debug (default-cli) on project webadmin: Command [[
[ERROR] /bin/sh -c /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/bin/java -javaagent:/home/ldq/.m2/repository/org/aspectj/as...

[ERROR] ]] failed with status 255
[ERROR] -> [Help 1]
[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/MojoExecutionException




Best Regards,
Dave Chen


> -----Original Message-----
> From: Ofri Masad [mailto:omasad at redhat.com]
> Sent: Tuesday, February 26, 2013 5:20 PM
> To: Chen, Wei D
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] How to debug in frontend project
> 
> Hi,
> 
> Not sure this it what you've meant, but gwt allows you to debug directly from
> your IDE.
> Here is how:
>  - compile using maven
>  - go to: frontend/webadmin/modules/webadmin
>  - run:   mvn clean gwt:debug -Pgwt-admin,gwtdev
>    (This will invoke a maven build which will get to the line: "[INFO] Listening
> for transport dt_socket at address: 8000")
>  - Create a debug configuration on your IDE for remote debug on host:localhost
> port:8000
>  - Debug using the IDE
>    (The IDE debug would launch a gwt tool which would allow you to activate
> the webadmin on you browser)
> 
> * after activating the webadmin on the browser via the gwt tool, be patient - it
> takes few minutes to load.
> 
> Ofri
> 
> ----- Original Message -----
> > From: "Wei D Chen" <wei.d.chen at intel.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, February 26, 2013 11:00:57 AM
> > Subject: [Engine-devel] How to debug in frontend project
> >
> > Hi,
> >
> > How to debug the code in frontend project? I mean, print out some
> > debug message from "onSave" method in the java file of
> > "VmListModel.java" which is located in uicommonweb project. Thanks in
> > advance.
> >
> > Best Regards,
> > Dave Chen
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >

From tjelinek at redhat.com  Wed Feb 27 07:23:32 2013
From: tjelinek at redhat.com (Tomas Jelinek)
Date: Wed, 27 Feb 2013 02:23:32 -0500 (EST)
Subject: [Engine-devel] How to debug in frontend project
In-Reply-To: <C5A0092C63E939488005F15F736A811209798369@SHSMSX101.ccr.corp.intel.com>
Message-ID: <2043329392.7767345.1361949812747.JavaMail.root@redhat.com>

Hi,

this is a wiki describing the debug of frontend:
http://www.ovirt.org/DebugFrontend

Please make sure that you have set up everything according to that wiki.

thanks,
Tomas

----- Original Message -----
From: "Wei D Chen" <wei.d.chen at intel.com>
To: "Ofri Masad" <omasad at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Wednesday, February 27, 2013 7:07:01 AM
Subject: Re: [Engine-devel] How to debug in frontend project

Hi Ofri, 

Thanks for your reply.

We follow the instructions, and we can see the similar information about the opened debug port, that is, " [INFO] Listening for transport dt_socket at address: 8000". My understanding is compiler is okay and the debug port is available.
But, when I remote access to this host via Eclipse, the connection abort immediately. Some difference after compare with the instruction is, our IDE is installed on a windows OS and build env is on a linux OS, they are different physical machine, this shouldn't be the root cause in my opinion, remote debug from a remote server is make sense always. Any good suggestion? Thanks a lot!


Here is some error message I get after the connection is aborted.

[ERROR] [AppClassLoader at 55a6c368] info AspectJ Weaver Version 1.6.11 built on Tuesday Mar 15, 2011 at 15:31:04 GMT
[ERROR] [AppClassLoader at 55a6c368] info register classloader sun.misc.Launcher$AppClassLoader at 55a6c368
[ERROR] [AppClassLoader at 55a6c368] info using configuration file:/home/ldq/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.2.0/gwt-extension-3.2.0.jar!/META-INF/aop.xml
[ERROR] [AppClassLoader at 55a6c368] info using configuration file:/home/ldq/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.2.0/gwt-extension-3.2.0-sources.jar!/META-INF/aop.xml
[ERROR] [AppClassLoader at 55a6c368] info register aspect org.ovirt.engine.ui.gwtextension.DontPrune
[ERROR] [AppClassLoader at 55a6c368] info register aspect org.ovirt.engine.ui.gwtextension.DontPrune
[ERROR] -bindAddress host "0.0.0.0" unknown
[ERROR] Google Web Toolkit 2.3.0
[ERROR] DevMode [-noserver] [-port port-number | "auto"] [-whitelist whitelist-string] [-blacklist blacklist-string] [-logdir directory] [-logLevel level] [-gen dir] [-bindAddress host-name-or-address] [-codeServerPort port-number | "auto"] [-server servletContainerLauncher[:args]] [-startupUrl url] [-war dir] [-deploy dir] [-extra dir] [-workDir dir] module[s]
[ERROR]
[ERROR] where
[ERROR]   -noserver        Prevents the embedded web server from running
[ERROR]   -port            Specifies the TCP port for the embedded web server (defaults to 8888)
[ERROR]   -whitelist       Allows the user to browse URLs that match the specified regexes (comma or space separated)
[ERROR]   -blacklist       Prevents the user browsing URLs that match the specified regexes (comma or space separated)
[ERROR]   -logdir          Logs to a file in the given directory, as well as graphically
[ERROR]   -logLevel        The level of logging detail: ERROR, WARN, INFO, TRACE, DEBUG, SPAM, or ALL
[ERROR]   -gen             Debugging: causes normally-transient generated types to be saved in the specified directory
[ERROR]   -bindAddress     Specifies the bind address for the code server and web server (defaults to 127.0.0.1)
[ERROR]   -codeServerPort  Specifies the TCP port for the code server (defaults to 9997)
[ERROR]   -server          Specify a different embedded web server to run (must implement ServletContainerLauncher)
[ERROR]   -startupUrl      Automatically launches the specified URL
[ERROR]   -war             The directory into which deployable output files will be written (defaults to 'war')
[ERROR]   -deploy          The directory into which deployable but not servable output files will be written (defaults to 'WEB-INF/deploy' under the -war directory/jar, and may be the same as the -extra directory/jar)
[ERROR]   -extra           The directory into which extra files, not intended for deployment, will be written
[ERROR]   -workDir         The compiler's working directory for internal use (must be writeable; defaults to a system temp dir)
[ERROR] and
[ERROR]   module[s]        Specifies the name(s) of the module(s) to host
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:43.341s
[INFO] Finished at: Wed Feb 27 13:44:31 CST 2013
[INFO] Final Memory: 38M/357M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:2.3.0-1:debug (default-cli) on project webadmin: Command [[
[ERROR] /bin/sh -c /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/bin/java -javaagent:/home/ldq/.m2/repository/org/aspectj/as...

[ERROR] ]] failed with status 255
[ERROR] -> [Help 1]
[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/MojoExecutionException




Best Regards,
Dave Chen


> -----Original Message-----
> From: Ofri Masad [mailto:omasad at redhat.com]
> Sent: Tuesday, February 26, 2013 5:20 PM
> To: Chen, Wei D
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] How to debug in frontend project
> 
> Hi,
> 
> Not sure this it what you've meant, but gwt allows you to debug directly from
> your IDE.
> Here is how:
>  - compile using maven
>  - go to: frontend/webadmin/modules/webadmin
>  - run:   mvn clean gwt:debug -Pgwt-admin,gwtdev
>    (This will invoke a maven build which will get to the line: "[INFO] Listening
> for transport dt_socket at address: 8000")
>  - Create a debug configuration on your IDE for remote debug on host:localhost
> port:8000
>  - Debug using the IDE
>    (The IDE debug would launch a gwt tool which would allow you to activate
> the webadmin on you browser)
> 
> * after activating the webadmin on the browser via the gwt tool, be patient - it
> takes few minutes to load.
> 
> Ofri
> 
> ----- Original Message -----
> > From: "Wei D Chen" <wei.d.chen at intel.com>
> > To: engine-devel at ovirt.org
> > Sent: Tuesday, February 26, 2013 11:00:57 AM
> > Subject: [Engine-devel] How to debug in frontend project
> >
> > Hi,
> >
> > How to debug the code in frontend project? I mean, print out some
> > debug message from "onSave" method in the java file of
> > "VmListModel.java" which is located in uicommonweb project. Thanks in
> > advance.
> >
> > Best Regards,
> > Dave Chen
> >
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From lhornyak at redhat.com  Wed Feb 27 08:26:40 2013
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 27 Feb 2013 03:26:40 -0500 (EST)
Subject: [Engine-devel] How to debug in frontend project
In-Reply-To: <2043329392.7767345.1361949812747.JavaMail.root@redhat.com>
Message-ID: <1792529967.1902059.1361953600792.JavaMail.root@redhat.com>

Hi,

Dave, please also read http://wiki.ovirt.org/DebugFrontend#Troubleshooting , I added some entries there, the second entry may solve your problem, I have seen that error a few days ago.

----- Original Message -----
> From: "Tomas Jelinek" <tjelinek at redhat.com>
> To: "Wei D Chen" <wei.d.chen at intel.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, February 27, 2013 8:23:32 AM
> Subject: Re: [Engine-devel] How to debug in frontend project
> 
> Hi,
> 
> this is a wiki describing the debug of frontend:
> http://www.ovirt.org/DebugFrontend
> 
> Please make sure that you have set up everything according to that
> wiki.
> 
> thanks,
> Tomas
> 
> ----- Original Message -----
> From: "Wei D Chen" <wei.d.chen at intel.com>
> To: "Ofri Masad" <omasad at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, February 27, 2013 7:07:01 AM
> Subject: Re: [Engine-devel] How to debug in frontend project
> 
> Hi Ofri,
> 
> Thanks for your reply.
> 
> We follow the instructions, and we can see the similar information
> about the opened debug port, that is, " [INFO] Listening for
> transport dt_socket at address: 8000". My understanding is compiler
> is okay and the debug port is available.
> But, when I remote access to this host via Eclipse, the connection
> abort immediately. Some difference after compare with the
> instruction is, our IDE is installed on a windows OS and build env
> is on a linux OS, they are different physical machine, this
> shouldn't be the root cause in my opinion, remote debug from a
> remote server is make sense always. Any good suggestion? Thanks a
> lot!
> 
> 
> Here is some error message I get after the connection is aborted.
> 
> [ERROR] [AppClassLoader at 55a6c368] info AspectJ Weaver Version 1.6.11
> built on Tuesday Mar 15, 2011 at 15:31:04 GMT
> [ERROR] [AppClassLoader at 55a6c368] info register classloader
> sun.misc.Launcher$AppClassLoader at 55a6c368
> [ERROR] [AppClassLoader at 55a6c368] info using configuration
> file:/home/ldq/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.2.0/gwt-extension-3.2.0.jar!/META-INF/aop.xml
> [ERROR] [AppClassLoader at 55a6c368] info using configuration
> file:/home/ldq/.m2/repository/org/ovirt/engine/ui/gwt-extension/3.2.0/gwt-extension-3.2.0-sources.jar!/META-INF/aop.xml
> [ERROR] [AppClassLoader at 55a6c368] info register aspect
> org.ovirt.engine.ui.gwtextension.DontPrune
> [ERROR] [AppClassLoader at 55a6c368] info register aspect
> org.ovirt.engine.ui.gwtextension.DontPrune
> [ERROR] -bindAddress host "0.0.0.0" unknown
> [ERROR] Google Web Toolkit 2.3.0
> [ERROR] DevMode [-noserver] [-port port-number | "auto"] [-whitelist
> whitelist-string] [-blacklist blacklist-string] [-logdir directory]
> [-logLevel level] [-gen dir] [-bindAddress host-name-or-address]
> [-codeServerPort port-number | "auto"] [-server
> servletContainerLauncher[:args]] [-startupUrl url] [-war dir]
> [-deploy dir] [-extra dir] [-workDir dir] module[s]
> [ERROR]
> [ERROR] where
> [ERROR]   -noserver        Prevents the embedded web server from
> running
> [ERROR]   -port            Specifies the TCP port for the embedded
> web server (defaults to 8888)
> [ERROR]   -whitelist       Allows the user to browse URLs that match
> the specified regexes (comma or space separated)
> [ERROR]   -blacklist       Prevents the user browsing URLs that match
> the specified regexes (comma or space separated)
> [ERROR]   -logdir          Logs to a file in the given directory, as
> well as graphically
> [ERROR]   -logLevel        The level of logging detail: ERROR, WARN,
> INFO, TRACE, DEBUG, SPAM, or ALL
> [ERROR]   -gen             Debugging: causes normally-transient
> generated types to be saved in the specified directory
> [ERROR]   -bindAddress     Specifies the bind address for the code
> server and web server (defaults to 127.0.0.1)
> [ERROR]   -codeServerPort  Specifies the TCP port for the code server
> (defaults to 9997)
> [ERROR]   -server          Specify a different embedded web server to
> run (must implement ServletContainerLauncher)
> [ERROR]   -startupUrl      Automatically launches the specified URL
> [ERROR]   -war             The directory into which deployable output
> files will be written (defaults to 'war')
> [ERROR]   -deploy          The directory into which deployable but
> not servable output files will be written (defaults to
> 'WEB-INF/deploy' under the -war directory/jar, and may be the same
> as the -extra directory/jar)
> [ERROR]   -extra           The directory into which extra files, not
> intended for deployment, will be written
> [ERROR]   -workDir         The compiler's working directory for
> internal use (must be writeable; defaults to a system temp dir)
> [ERROR] and
> [ERROR]   module[s]        Specifies the name(s) of the module(s) to
> host
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1:43.341s
> [INFO] Finished at: Wed Feb 27 13:44:31 CST 2013
> [INFO] Final Memory: 38M/357M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.codehaus.mojo:gwt-maven-plugin:2.3.0-1:debug (default-cli) on
> project webadmin: Command [[
> [ERROR] /bin/sh -c
> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/bin/java
> -javaagent:/home/ldq/.m2/repository/org/aspectj/as...
> 
> [ERROR] ]] failed with status 255
> [ERROR] -> [Help 1]
> [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/MojoExecutionException
> 
> 
> 
> 
> Best Regards,
> Dave Chen
> 
> 
> > -----Original Message-----
> > From: Ofri Masad [mailto:omasad at redhat.com]
> > Sent: Tuesday, February 26, 2013 5:20 PM
> > To: Chen, Wei D
> > Cc: engine-devel at ovirt.org
> > Subject: Re: [Engine-devel] How to debug in frontend project
> > 
> > Hi,
> > 
> > Not sure this it what you've meant, but gwt allows you to debug
> > directly from
> > your IDE.
> > Here is how:
> >  - compile using maven
> >  - go to: frontend/webadmin/modules/webadmin
> >  - run:   mvn clean gwt:debug -Pgwt-admin,gwtdev
> >    (This will invoke a maven build which will get to the line:
> >    "[INFO] Listening
> > for transport dt_socket at address: 8000")
> >  - Create a debug configuration on your IDE for remote debug on
> >  host:localhost
> > port:8000
> >  - Debug using the IDE
> >    (The IDE debug would launch a gwt tool which would allow you to
> >    activate
> > the webadmin on you browser)
> > 
> > * after activating the webadmin on the browser via the gwt tool, be
> > patient - it
> > takes few minutes to load.
> > 
> > Ofri
> > 
> > ----- Original Message -----
> > > From: "Wei D Chen" <wei.d.chen at intel.com>
> > > To: engine-devel at ovirt.org
> > > Sent: Tuesday, February 26, 2013 11:00:57 AM
> > > Subject: [Engine-devel] How to debug in frontend project
> > >
> > > Hi,
> > >
> > > How to debug the code in frontend project? I mean, print out some
> > > debug message from "onSave" method in the java file of
> > > "VmListModel.java" which is located in uicommonweb project.
> > > Thanks in
> > > advance.
> > >
> > > Best Regards,
> > > Dave Chen
> > >
> > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lspevak at redhat.com  Wed Feb 27 08:36:16 2013
From: lspevak at redhat.com (Libor Spevak)
Date: Wed, 27 Feb 2013 09:36:16 +0100
Subject: [Engine-devel] Engine table comments
In-Reply-To: <1733089166.8628739.1361887395043.JavaMail.root@redhat.com>
References: <1733089166.8628739.1361887395043.JavaMail.root@redhat.com>
Message-ID: <512DC580.3010206@redhat.com>

Thanks for the confirmation. Appending a template for the columns :-)

/psql engine -U postgres -c "SELECT 'COMMENT ON COLUMN ' || table_name 
|| '.' || column_name || ' IS TODO;' sql FROM information_schema.columns 
where table_schema='public' order by table_name, column_name" > 
comments_columns_to_do.sql//
/
It looks like we have cca 73 tables and  2353 columns now. So probably 
better to start with the tables.


On 26.2.2013 15:03, Yair Zaslavsky wrote:
> I think your idea is very good.
> I also think we should have it for columns as well.
> But since we already have many columns, maybe we should have an "on 
> going effort" from various developers on this (i.e - each developer 
> will do that for several tables).
> Thoughts?
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Libor Spevak" <lspevak at redhat.com>
>     *To: *engine-devel at ovirt.org
>     *Sent: *Tuesday, February 26, 2013 2:37:17 PM
>     *Subject: *[Engine-devel] Engine table comments
>
>     Hi,
>     I would like to propose to create a patch assigning sql comment to
>     each Engine table.
>     The comments will be a part of the exported DB schema report, too.
>     The terminology is not always consistent across all application
>     layers, so for the newcomers it would be easier to understand the
>     model.
>
>     But, what would be general guidelines?
>
>     I recommend to use singular form of entity name as used from
>     end-user point of view (if somehow visible, of course), or just
>     used frequently inside code.
>
>     Examples:
>     storage_pool ... Data center
>     vds_groups ... Cluster
>     but:
>     vm_static  ... Virtual machine configuration
>     vm_dynamic ... Virtual machine runtime data
>     vm_statistics ... Virtual machine statistics data
>     ...
>     etc.
>
>     This command prepares a template for the patch:
>
>     /psql engine -U postgres -c "select 'COMMENT ON TABLE ' || relname
>     || ' IS ''TODO'';' sql from pg_stat_user_tables t WHERE
>     schemaname='public' order by t.relname" > comments_to_do.sql//
>     /
>     or just I can prepare a page on the wiki with table containing
>     table names and volunteers :-) can propose simple understandable
>     comments for known tables.
>
>     Is it useful?
>
>     Thanks.
>
>     Regards,
>     Libor
>
>     _______________________________________________
>     Engine-devel mailing list
>     Engine-devel at ovirt.org
>     http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130227/2e5790f1/attachment.html>

From ofrenkel at redhat.com  Wed Feb 27 09:26:40 2013
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Wed, 27 Feb 2013 04:26:40 -0500 (EST)
Subject: [Engine-devel] Engine table comments
In-Reply-To: <512DC580.3010206@redhat.com>
Message-ID: <311732669.10971948.1361957200150.JavaMail.root@redhat.com>

----- Original Message -----

> From: "Libor Spevak" <lspevak at redhat.com>
> To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Wednesday, February 27, 2013 9:36:16 AM
> Subject: Re: [Engine-devel] Engine table comments

> Thanks for the confirmation. Appending a template for the columns :-)

> psql engine -U postgres -c "SELECT 'COMMENT ON COLUMN ' || table_name
> || '.' || column_name || ' IS TODO;' sql FROM
> information_schema.columns where table_schema='public' order by
> table_name, column_name" > comments_columns_to_do.sql

> It looks like we have cca 73 tables and 2353 columns now. So probably
> better to start with the tables.

i documented some (not complete) information about columns of vm_static here: 
http://wiki.ovirt.org/Features/Templates-3.2#Design 
as part of preparation for instance types feature 
so maybe we can use it as well 

> On 26.2.2013 15:03, Yair Zaslavsky wrote:

> > I think your idea is very good.
> 
> > I also think we should have it for columns as well.
> 
> > But since we already have many columns, maybe we should have an "on
> > going effort" from various developers on this (i.e - each developer
> > will do that for several tables).
> 
> > Thoughts?
> 

> > ----- Original Message -----
> 

> > > From: "Libor Spevak" <lspevak at redhat.com>
> > 
> 
> > > To: engine-devel at ovirt.org
> > 
> 
> > > Sent: Tuesday, February 26, 2013 2:37:17 PM
> > 
> 
> > > Subject: [Engine-devel] Engine table comments
> > 
> 

> > > Hi,
> > 
> 
> > > I would like to propose to create a patch assigning sql comment
> > > to
> > > each Engine table.
> > 
> 
> > > The comments will be a part of the exported DB schema report,
> > > too.
> > 
> 
> > > The terminology is not always consistent across all application
> > > layers, so for the newcomers it would be easier to understand the
> > > model.
> > 
> 

> > > But, what would be general guidelines?
> > 
> 

> > > I recommend to use singular form of entity name as used from
> > > end-user
> > > point of view (if somehow visible, of course), or just used
> > > frequently inside code.
> > 
> 

> > > Examples:
> > 
> 
> > > storage_pool ... Data center
> > 
> 
> > > vds_groups ... Cluster
> > 
> 
> > > but:
> > 
> 
> > > vm_static ... Virtual machine configuration
> > 
> 
> > > vm_dynamic ... Virtual machine runtime data
> > 
> 
> > > vm_statistics ... Virtual machine statistics data
> > 
> 
> > > ...
> > 
> 
> > > etc.
> > 
> 

> > > This command prepares a template for the patch:
> > 
> 

> > > psql engine -U postgres -c "select 'COMMENT ON TABLE ' || relname
> > > ||
> > > ' IS ''TODO'';' sql from pg_stat_user_tables t WHERE
> > > schemaname='public' order by t.relname" > comments_to_do.sql
> > 
> 

> > > or just I can prepare a page on the wiki with table containing
> > > table
> > > names and volunteers :-) can propose simple understandable
> > > comments
> > > for known tables.
> > 
> 

> > > Is it useful?
> > 
> 

> > > Thanks.
> > 
> 

> > > Regards,
> > 
> 
> > > Libor
> > 
> 

> > > _______________________________________________
> > 
> 
> > > Engine-devel mailing list
> > 
> 
> > > Engine-devel at ovirt.org
> > 
> 
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 

> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130227/70acb4f0/attachment.html>

From Christopher.Morrissey at netapp.com  Wed Feb 27 18:38:18 2013
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Wed, 27 Feb 2013 18:38:18 +0000
Subject: [Engine-devel] Rebasing a patch on an updated dependency
Message-ID: <D290AD8432118048947689BA3AE8A9B325B800D7@SACEXCMBX02-PRD.hq.netapp.com>

Hi All,

I have a patch, http://gerrit.ovirt.org/#/c/11783/, that is dependent on another unmerged patch and the dependent patch has been updated with a new patch set. I know I need to somehow rebase my patch on the updated dependent patch set, but I'm new to git and gerrit and have not been able to figure out the right combination of git commands to accomplish this. Any ideas on what steps I need to take? Thanks!

-Chris

Chris Morrissey
Software Engineer
NetApp Inc.
919.476.4428



From ovedo at redhat.com  Wed Feb 27 20:05:08 2013
From: ovedo at redhat.com (Oved Ourfalli)
Date: Wed, 27 Feb 2013 15:05:08 -0500 (EST)
Subject: [Engine-devel] Rebasing a patch on an updated dependency
In-Reply-To: <D290AD8432118048947689BA3AE8A9B325B800D7@SACEXCMBX02-PRD.hq.netapp.com>
Message-ID: <351239374.12651932.1361995508525.JavaMail.root@redhat.com>

Hi Chris,
how are you?

You can do that using git commands, but the easiest way to rebase would be to go to the gerrit UI, and press the "rebase change" button.
Then, you can verify it using the "checkout command" that gerrit would give you (the command appears above the "rebase change" button), in your git repository.

btw, why is the patch it depends on not merged yet? do you need to verify them together before merging it? Because I saw it is acked, so if it is also verified then we can merge it.

Hope I helped,
Oved

----- Original Message -----
> From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, February 27, 2013 8:38:18 PM
> Subject: [Engine-devel] Rebasing a patch on an updated dependency
> 
> Hi All,
> 
> I have a patch, http://gerrit.ovirt.org/#/c/11783/, that is dependent
> on another unmerged patch and the dependent patch has been updated
> with a new patch set. I know I need to somehow rebase my patch on
> the updated dependent patch set, but I'm new to git and gerrit and
> have not been able to figure out the right combination of git
> commands to accomplish this. Any ideas on what steps I need to take?
> Thanks!
> 
> -Chris
> 
> Chris Morrissey
> Software Engineer
> NetApp Inc.
> 919.476.4428
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From Christopher.Morrissey at netapp.com  Wed Feb 27 21:23:24 2013
From: Christopher.Morrissey at netapp.com (Morrissey, Christopher)
Date: Wed, 27 Feb 2013 21:23:24 +0000
Subject: [Engine-devel] Rebasing a patch on an updated dependency
In-Reply-To: <351239374.12651932.1361995508525.JavaMail.root@redhat.com>
References: <D290AD8432118048947689BA3AE8A9B325B800D7@SACEXCMBX02-PRD.hq.netapp.com>
	<351239374.12651932.1361995508525.JavaMail.root@redhat.com>
Message-ID: <D290AD8432118048947689BA3AE8A9B325B80223@SACEXCMBX02-PRD.hq.netapp.com>

Thanks Oved! That's what I needed.

-Chris

> -----Original Message-----
> From: Oved Ourfalli [mailto:ovedo at redhat.com]
> Sent: Wednesday, February 27, 2013 3:05 PM
> To: Morrissey, Christopher
> Cc: engine-devel at ovirt.org
> Subject: Re: [Engine-devel] Rebasing a patch on an updated dependency
> 
> Hi Chris,
> how are you?
> 
> You can do that using git commands, but the easiest way to rebase would be
> to go to the gerrit UI, and press the "rebase change" button.
> Then, you can verify it using the "checkout command" that gerrit would give
> you (the command appears above the "rebase change" button), in your git
> repository.
> 
> btw, why is the patch it depends on not merged yet? do you need to verify
> them together before merging it? Because I saw it is acked, so if it is also
> verified then we can merge it.
> 
> Hope I helped,
> Oved
> 
> ----- Original Message -----
> > From: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
> > To: engine-devel at ovirt.org
> > Sent: Wednesday, February 27, 2013 8:38:18 PM
> > Subject: [Engine-devel] Rebasing a patch on an updated dependency
> >
> > Hi All,
> >
> > I have a patch, http://gerrit.ovirt.org/#/c/11783/, that is dependent
> > on another unmerged patch and the dependent patch has been updated
> > with a new patch set. I know I need to somehow rebase my patch on the
> > updated dependent patch set, but I'm new to git and gerrit and have
> > not been able to figure out the right combination of git commands to
> > accomplish this. Any ideas on what steps I need to take?
> > Thanks!
> >
> > -Chris
> >
> > Chris Morrissey
> > Software Engineer
> > NetApp Inc.
> > 919.476.4428
> >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >

From ecohen at redhat.com  Thu Feb 28 19:51:40 2013
From: ecohen at redhat.com (Einav Cohen)
Date: Thu, 28 Feb 2013 14:51:40 -0500 (EST)
Subject: [Engine-devel] oVirt Engine GUI: builders infrastructure feedback
 (conf: 712 886 7405#)
Message-ID: <1579993822.12312837.1362081100298.JavaMail.root@redhat.com>

The following is a new meeting request:

Subject: oVirt Engine GUI: builders infrastructure feedback (conf: 712 886 7405#) 
Organizer: "Einav Cohen" <ecohen at redhat.com> 

Location: Intercall conf code: 712 886 7405# 
Time: Tuesday, March 5, 2013, 9:30:00 AM - 11:00:00 AM GMT -05:00 US/Canada Eastern
 
Invitees: tjelinek at redhat.com; engine-devel at ovirt.org 


*~*~*~*~*~*~*~*~*~*

Following the correspondence in the builders infrastructure patch [1] and engine-devel thread [2]: 
In the first part of the meeting, Tomas Jelinek <tjelinek at redhat.com> will present his builders infrastructure solution. 
In the second part of the meeting, we will hear feedback about this solution from the other parties and try to converge to a final, unanimous decision.


conference call details:
========================
Intercall dial-in numbers:
https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405

Intercall conf code:
712 886 7405#


elluminate session:
===================
https://sas.elluminate.com/m.jnlp?sid=819&password=M.A7793C4C197B25A20229D725900B25

----

[1] http://gerrit.ovirt.org/#/c/10874/

[2] http://lists.ovirt.org/pipermail/engine-devel/2013-January/003528.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130228/09fd2283/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 4232 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20130228/09fd2283/attachment.ics>