From iheim at redhat.com  Fri Jun  1 15:32:40 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 01 Jun 2012 18:32:40 +0300
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build #
 915 - Still Unstable!
In-Reply-To: <1062332a-4565-4a8d-abe3-623208eec737@zmail17.collab.prod.int.phx2.redhat.com>
References: <1062332a-4565-4a8d-abe3-623208eec737@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4FC8E098.3040807@redhat.com>

On 05/22/2012 03:33 PM, Eyal Edri wrote:
> FYI,
>
> In order to test if your commit adds new findbugs warning (before you commit it), please run the following mvn command:
>
> #mvn install -DskipTests findbugs:findbugs.

you can also install the findbugs eclipse plugin which will show you 
them in the code, or run
mvn install -DskipTests findbugs:findbugs findbugs:gui
to open the findbugs gui

>
> the results can be checked manually in the xml files or via the findbugs plugin to jenkins.
>
> we hope to add jenkins verification jobs on gerrit patches soon, once we'll have more powerfull jenkins slaves to handle the extra load
> from multiple gerrit patches.
>
> Eyal.
>
> ----- Original Message -----
>> From: "Eyal Edri"<eedri at redhat.com>
>> To: engine-devel at ovirt.org
>> Cc: engine-patches at ovirt.org
>> Sent: Tuesday, May 22, 2012 12:49:37 PM
>> Subject: Re: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 915 - Still Unstable!
>>
>> FYI,
>>
>> These set of patches introduced new HIGH findbugs warnings:
>>
>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/913/changes:
>>
>>
>> webadmin: Gluster Volume Options - populating from help xml (details)
>> webadmin: Gluster Brick sub tab - removing columns (details)
>> webadmin: Support for mode specific Tabs and Sub Tabs (details)
>> restapi: Gluster Resources Implementation classes (details)
>> restapi: RSDL metadata for gluster related REST api (details)
>> restapi: Gluster Volumes Collection implementation (details)
>> engine: Add ID fields to gluster brick and option (details)
>> webadmin: Gluster Volume - add bricks enabling (#823284) (details)
>> webadmin: Gluster Volume - upadting actions (#823273) (details)
>> webadmin: Gluster Volume - validations fixed (#823277) (details)
>>
>> bugs appear to be in GlusterVolumeEntity.java:
>>
>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/913/findbugsResult/HIGH/source.676/#375
>> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/913/findbugsResult/HIGH/?
>>
>> Please review and handle,
>>
>> Eyal Edri
>> oVirt Infra Team
>>
>>
>> ----- 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, amureini at redhat.com,
>>> dfediuck at redhat.com
>>> Sent: Tuesday, May 22, 2012 12:11:33 PM
>>> Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 915 -
>>> Still Unstable!
>>>
>>> Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/
>>> Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/915/
>>> Build Number: 915
>>> Build Status:  Still Unstable
>>> Triggered By: Started by upstream project "ovirt_engine" build
>>> number
>>> 1,240
>>>
>>> -------------------------------------
>>> Changes Since Last Success:
>>> -------------------------------------
>>> Changes for Build #913
>>> [gchaplik] webadmin: Gluster Volume Options - populating from help
>>> xml
>>>
>>> [gchaplik] webadmin: Gluster Brick sub tab - removing columns
>>>
>>> [gchaplik] webadmin: Support for mode specific Tabs and Sub Tabs
>>>
>>> [sanjal] restapi: Gluster Resources Implementation classes
>>>
>>> [sanjal] restapi: RSDL metadata for gluster related REST api
>>>
>>> [sanjal] restapi: Gluster Volumes Collection implementation
>>>
>>> [sanjal] engine: Add ID fields to gluster brick and option
>>>
>>> [gchaplik] webadmin: Gluster Volume - add bricks enabling (#823284)
>>>
>>> [gchaplik] webadmin: Gluster Volume - upadting actions (#823273)
>>>
>>> [gchaplik] webadmin: Gluster Volume - validations fixed (#823277)
>>>
>>>
>>> Changes for Build #914
>>> [emesika] core:dbfunctions.sh script needs to be compatible with
>>> DWH
>>>
>>> [mpastern] restapi: fix rsdl regression
>>>
>>>
>>> Changes for Build #915
>>> [dfediuck] core: Use same ids for artifacts and plugins
>>>
>>> [amureini] core: Allow admin permissions in user views
>>>
>>> [amureini] core: Roles commands cleanup
>>>
>>> [amureini] core: Cleanup Permissions Commands
>>>
>>> [amureini] core: Roles commands - use the cached getRole()
>>>
>>> [amureini] core: is_inheritable property to MLA entities
>>>
>>>
>>>
>>>
>>> -----------------
>>> Failed Tests:
>>> -----------------
>>> No tests ran.
>>>
>>> ------------------
>>> Build Log:
>>> ------------------
>>> [...truncated 4148 lines...]
>>> [INFO] Assembling webapp [userportal] in
>>> [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.1.0-0001]
>>> [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 [147 msecs]
>>> [INFO] Building war:
>>> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/userportal-3.1.0-0001.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.1.0-0001.war
>>> to
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/userportal/3.1.0-0001/userportal-3.1.0-0001.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.1.0-0001/userportal-3.1.0-0001.pom
>>> [INFO]
>>> [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default-cli) @
>>> userportal ---
>>> [INFO] Fork Value is true
>>> [INFO]
>>> [INFO] --- maven-checkstyle-plugin:2.6:check (default) @ webadmin
>>> ---
>>> [INFO] Starting audit...
>>> Audit done.
>>>
>>> [INFO]
>>> [INFO] --- maven-resources-plugin:2.5:testResources
>>> (default-testResources) @ webadmin ---
>>> [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/webadmin/src/test/resources
>>> [INFO]
>>> [INFO] --- maven-compiler-plugin:2.3.2:testCompile
>>> (default-testCompile) @ webadmin ---
>>> [INFO] No sources to compile
>>> [INFO]
>>> [INFO] --- maven-surefire-plugin:2.10:test (default-test) @
>>> webadmin
>>> ---
>>> [INFO] Tests are skipped.
>>> [INFO]
>>> [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ webadmin ---
>>> [INFO] Packaging webapp
>>> [INFO] Assembling webapp [webadmin] in
>>> [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/webadmin-3.1.0-0001]
>>> [INFO] Processing war project
>>> [INFO] Copying webapp resources
>>> [/ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/src/main/webapp]
>>> [INFO] Webapp assembled in [147 msecs]
>>> OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has
>>> been disabled.
>>> OpenJDK 64-Bit Server VM warning: Try increasing the code cache
>>> size
>>> using -XX:ReservedCodeCacheSize=
>>> [INFO] Building war:
>>> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/webadmin-3.1.0-0001.war
>>> [INFO] WEB-INF/web.xml already added, skipping
>>> [INFO]
>>> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
>>> webadmin ---
>>> [INFO] Installing
>>> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/webadmin-3.1.0-0001.war
>>> to
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/webadmin/3.1.0-0001/webadmin-3.1.0-0001.war
>>> [INFO] Installing
>>> /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/pom.xml
>>> to
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/webadmin/3.1.0-0001/webadmin-3.1.0-0001.pom
>>> [INFO]
>>> [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default-cli) @
>>> webadmin ---
>>> [INFO] Fork Value is true
>>>       [java] Warnings generated: 14
>>> [INFO] Done FindBugs Analysis....
>>>       [java] Warnings generated: 56
>>> [INFO] Done FindBugs Analysis....
>>> [INFO]
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Building oVirt Server EAR 3.1.0-0001
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [WARNING] The POM for
>>> org.codehaus.mojo:gwt-maven-plugin:jar:1.3.2.google is missing, no
>>> dependency information available
>>> [WARNING] Failed to retrieve plugin descriptor for
>>> org.codehaus.mojo:gwt-maven-plugin:1.3.2.google: Plugin
>>> org.codehaus.mojo:gwt-maven-plugin:1.3.2.google or one of its
>>> dependencies could not be resolved: Failed to read artifact
>>> descriptor for org.codehaus.mojo:gwt-maven-plugin:jar:1.3.2.google
>>> [WARNING]
>>> *****************************************************************
>>> [WARNING] * Your build is requesting parallel execution, but
>>> project
>>>       *
>>> [WARNING] * contains the following plugin(s) that are not marked as
>>>        *
>>> [WARNING] * @threadSafe to support parallel building.
>>>                      *
>>> [WARNING] * While this /may/ work fine, please look for plugin
>>> updates    *
>>> [WARNING] * and/or request plugins be made thread-safe.
>>>                    *
>>> [WARNING] * If reporting an issue, report it against the plugin in
>>>         *
>>> [WARNING] * question, not against maven-core
>>>                               *
>>> [WARNING]
>>> *****************************************************************
>>> [WARNING] The following plugins are not marked @threadSafe in oVirt
>>> Server EAR:
>>> [WARNING] org.apache.maven.plugins:maven-dependency-plugin:2.1
>>> [WARNING]
>>> *****************************************************************
>>> [INFO]
>>> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
>>> engine-server-ear ---
>>> [INFO] Deleting /ephemeral0/ovirt_engine_find_bugs/ear/target
>>> [INFO]
>>> [INFO] --- maven-ear-plugin:2.6: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] skip non existing resourceDirectory
>>> /ephemeral0/ovirt_engine_find_bugs/ear/src/main/resources
>>> [INFO]
>>> [INFO] --- maven-ear-plugin:2.6:ear (default-ear) @
>>> engine-server-ear
>>> ---
>>> [INFO] Copying
>>> artifact[jar:org.ovirt.engine.core:common:3.1.0-0001]
>>> to[lib/engine-common.jar]
>>> [INFO] Copying
>>> artifact[jar:org.ovirt.engine.core:compat:3.1.0-0001]
>>> to[lib/engine-compat.jar]
>>> [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0-0001]
>>> to[lib/engine-dal.jar]
>>> [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0-0001]
>>> to[lib/engine-utils.jar]
>>> [INFO] Copying
>>> artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0-0001]
>>> to[lib/engine-encryptutils.jar]
>>> [INFO] Copying
>>> artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0-0001]
>>> to[lib/engine-vdsbroker.jar]
>>> [INFO] Copying
>>> artifact[war:org.ovirt.engine.core:root-war:3.1.0-0001]
>>> to[root.war]
>>> (unpacked)
>>> [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0-0001]
>>> to[ovirtengineweb.war] (unpacked)
>>> [INFO] Copying artifact[war:org.ovirt.engine.ui:rm-war:3.1.0-0001]
>>> to[ovirtengine.war] (unpacked)
>>> [INFO] Copying
>>> artifact[war:org.ovirt.engine.ui:components-war:3.1.0-0001]
>>> to[components.war] (unpacked)
>>> [INFO] Copying
>>> artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0-0001]
>>> to[restapi.war] (unpacked)
>>> [INFO] Copying
>>> artifact[war:org.ovirt.engine.ui:userportal:3.1.0-0001]
>>> to[userportal.war] (unpacked)
>>> [INFO] Copying
>>> artifact[war:org.ovirt.engine.ui:webadmin:3.1.0-0001]
>>> to[webadmin.war] (unpacked)
>>> [INFO] Copying
>>> artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0-0001]
>>> to[engine-genericapi.jar] (unpacked)
>>> [INFO] Copying
>>> artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0-0001]
>>> to[engine-scheduler.jar] (unpacked)
>>> [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0-0001]
>>> to[engine-bll.jar] (unpacked)
>>> [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4]
>>> to[lib/commons-codec-1.4.jar]
>>> [INFO] Copying
>>> artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA]
>>> to[lib/hibernate-validator-4.0.2.GA.jar]
>>> [INFO] Copying
>>> artifact[jar:javax.validation:validation-api:1.0.0.GA]
>>> to[lib/validation-api-1.0.0.GA.jar]
>>> [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6]
>>> to[lib/slf4j-api-1.5.6.jar]
>>> [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1]
>>> to[lib/jaxb-api-2.1.jar]
>>> [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2]
>>> to[lib/stax-api-1.0-2.jar]
>>> [INFO] Copying artifact[jar:javax.activation:activation:1.1]
>>> to[lib/activation-1.1.jar]
>>> [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3]
>>> to[lib/jaxb-impl-2.1.3.jar]
>>> [INFO] Copying
>>> artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA]
>>> to[lib/hibernate-annotations-3.4.0.GA.jar]
>>> [INFO] Copying
>>> artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA]
>>> to[lib/ejb3-persistence-1.0.2.GA.jar]
>>> [INFO] Copying
>>> artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA]
>>> to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
>>> [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1]
>>> to[lib/hibernate-core-3.3.0.SP1.jar]
>>> [INFO] Copying artifact[jar:antlr:antlr:2.7.6]
>>> to[lib/antlr-2.7.6.jar]
>>> [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1]
>>> to[lib/dom4j-1.6.1.jar]
>>> [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2]
>>> to[lib/xml-apis-1.0.b2.jar]
>>> [INFO] Copying
>>> artifact[jar:org.codehaus.jackson:jackson-mapper-asl:1.9.4]
>>> to[lib/jackson-mapper-asl-1.9.4.jar]
>>> [INFO] Copying
>>> artifact[jar:org.codehaus.jackson:jackson-core-asl:1.9.4]
>>> to[lib/jackson-core-asl-1.9.4.jar]
>>> [INFO] Copying
>>> artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final]
>>> to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
>>> [INFO] Copying
>>> artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0-0001]
>>> to[lib/engine-tools-common-3.1.0-0001.jar]
>>> [INFO] Copying
>>> artifact[jar:commons-beanutils:commons-beanutils:1.8.2]
>>> to[lib/commons-beanutils-1.8.2.jar]
>>> [INFO] Copying artifact[jar:com.jcraft:jsch:0.1.42]
>>> to[lib/jsch-0.1.42.jar]
>>> [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1]
>>> to[lib/mina-core-2.0.1.jar]
>>> [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.6.0]
>>> to[lib/sshd-core-0.6.0.jar]
>>> [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4]
>>> to[lib/commons-lang-2.4.jar]
>>> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3]
>>> to[lib/xmlrpc-client-3.1.3.jar]
>>> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3]
>>> to[lib/xmlrpc-common-3.1.3.jar]
>>> [INFO] Copying
>>> artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2]
>>> to[lib/ws-commons-util-1.0.2.jar]
>>> [INFO] Copying
>>> artifact[jar:org.springframework:spring-jdbc:2.5.6.SEC02]
>>> to[lib/spring-jdbc-2.5.6.SEC02.jar]
>>> [INFO] Copying
>>> artifact[jar:org.springframework:spring-tx:2.5.6.SEC02]
>>> to[lib/spring-tx-2.5.6.SEC02.jar]
>>> [INFO] Copying
>>> artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.0.RELEASE]
>>> to[lib/spring-ldap-core-1.3.0.RELEASE.jar]
>>> [INFO] Copying
>>> artifact[jar:commons-httpclient:commons-httpclient:3.1]
>>> to[lib/commons-httpclient-3.1.jar]
>>> [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2]
>>> to[lib/quartz-2.1.2.jar]
>>> [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1]
>>> to[lib/c3p0-0.9.1.1.jar]
>>> [INFO] Copying
>>> artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0-0001]
>>> to[lib/searchbackend-3.1.0-0001.jar]
>>> [INFO] Copying
>>> artifact[jar:commons-collections:commons-collections:3.1]
>>> to[lib/commons-collections-3.1.jar]
>>> [INFO] Copying
>>> artifact[jar:org.springframework:spring-core:2.5.6.SEC02]
>>> to[lib/spring-core-2.5.6.SEC02.jar]
>>> [INFO] Copying
>>> artifact[jar:org.springframework:spring-beans:2.5.6.SEC02]
>>> to[lib/spring-beans-2.5.6.SEC02.jar]
>>> [INFO] Copying
>>> artifact[jar:org.springframework:spring-context:2.5.6.SEC02]
>>> to[lib/spring-context-2.5.6.SEC02.jar]
>>> [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0]
>>> to[lib/aopalliance-1.0.jar]
>>> [INFO] Copying
>>> artifact[jar:org.springframework:spring-agent:2.5.6.SEC02]
>>> to[lib/spring-agent-2.5.6.SEC02.jar]
>>> [INFO] Copying
>>> artifact[jar:org.springframework:spring-aop:2.5.6.SEC02]
>>> to[lib/spring-aop-2.5.6.SEC02.jar]
>>> [INFO] Copy ear sources to
>>> /ephemeral0/ovirt_engine_find_bugs/ear/target/engine
>>> [INFO] Could not find manifest file:
>>> /ephemeral0/ovirt_engine_find_bugs/ear/target/engine/META-INF/MANIFEST.MF
>>> - Generating one
>>> [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.1.0-0001/engine-server-ear-3.1.0-0001.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.1.0-0001/engine-server-ear-3.1.0-0001.pom
>>> [INFO]
>>> [INFO] --- findbugs-maven-plugin:2.4.0:findbugs (default-cli) @
>>> engine-server-ear ---
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Reactor Summary:
>>> [INFO]
>>> [INFO] oVirt Engine Root Project ......................... SUCCESS
>>> [11.175s]
>>> [INFO] oVirt Build Tools root ............................ SUCCESS
>>> [0.154s]
>>> [INFO] oVirt checkstyle .................................. SUCCESS
>>> [2.925s]
>>> [INFO] oVirt Checkstyle Checks ........................... SUCCESS
>>> [32.541s]
>>> [INFO] oVirt Modules - backend ........................... SUCCESS
>>> [0.137s]
>>> [INFO] oVirt Manager ..................................... SUCCESS
>>> [0.633s]
>>> [INFO] oVirt Modules - manager ........................... SUCCESS
>>> [1.512s]
>>> [INFO] CSharp Compatibility .............................. SUCCESS
>>> [1:18.689s]
>>> [INFO] Encryption Libraries .............................. SUCCESS
>>> [42.599s]
>>> [INFO] oVirt Tools ....................................... SUCCESS
>>> [0.205s]
>>> [INFO] oVirt Tools Common Library ........................ SUCCESS
>>> [25.939s]
>>> [INFO] Common Code ....................................... SUCCESS
>>> [2:09.368s]
>>> [INFO] Common utilities .................................. SUCCESS
>>> [1:43.075s]
>>> [INFO] Data Access Layer ................................. SUCCESS
>>> [1:39.624s]
>>> [INFO] engine beans ...................................... SUCCESS
>>> [0.237s]
>>> [INFO] engine scheduler bean ............................. SUCCESS
>>> [40.875s]
>>> [INFO] Vds broker ........................................ SUCCESS
>>> [1:44.474s]
>>> [INFO] Search Backend .................................... SUCCESS
>>> [59.374s]
>>> [INFO] Backend Logic @Service bean ....................... SUCCESS
>>> [2:17.939s]
>>> [INFO] oVirt RESTful API Backend Integration ............. SUCCESS
>>> [0.154s]
>>> [INFO] oVirt RESTful API interface ....................... SUCCESS
>>> [0.315s]
>>> [INFO] oVirt Engine API Definition ....................... SUCCESS
>>> [1:32.846s]
>>> [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
>>> [0.328s]
>>> [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
>>> [58.151s]
>>> [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
>>> [1:29.592s]
>>> [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
>>>   SUCCESS [1:34.159s]
>>> [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
>>> [12.297s]
>>> [INFO] oVirt Engine Web Root ............................. SUCCESS
>>> [33.235s]
>>> [INFO] oVirt Configuration Tool .......................... SUCCESS
>>> [46.202s]
>>> [INFO] Notifier Service package .......................... SUCCESS
>>> [0.143s]
>>> [INFO] Notifier Service .................................. SUCCESS
>>> [56.794s]
>>> [INFO] Notifier Service Resources ........................ SUCCESS
>>> [9.712s]
>>> [INFO] oVirt Modules - frontend .......................... SUCCESS
>>> [3.064s]
>>> [INFO] oVirt APIs ........................................ SUCCESS
>>> [1.472s]
>>> [INFO] oVirt generic API ................................. SUCCESS
>>> [32.572s]
>>> [INFO] oVirt Modules - webadmin .......................... SUCCESS
>>> [0.146s]
>>> [INFO] oVirt Modules - ui ................................ SUCCESS
>>> [0.250s]
>>> [INFO] Extensions for GWT ................................ SUCCESS
>>> [1:17.416s]
>>> [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
>>> [47.857s]
>>> [INFO] Frontend for GWT UI Projects ...................... SUCCESS
>>> [47.153s]
>>> [INFO] UICommon .......................................... SUCCESS
>>> [3:17.484s]
>>> [INFO] UICommonWeb ....................................... SUCCESS
>>> [3:41.508s]
>>> [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
>>> [1:44.412s]
>>> [INFO] WebAdmin .......................................... SUCCESS
>>> [3:28.888s]
>>> [INFO] UserPortal ........................................ SUCCESS
>>> [2:12.619s]
>>> [INFO] oVirt WARs ........................................ SUCCESS
>>> [0.134s]
>>> [INFO] WPF Application Module ............................ SUCCESS
>>> [8.143s]
>>> [INFO] oVirt Web Application Module ...................... SUCCESS
>>> [32.504s]
>>> [INFO] Components Web Application Module ................. SUCCESS
>>> [6.230s]
>>> [INFO] oVirt Server EAR .................................. SUCCESS
>>> [17.227s]
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] BUILD SUCCESS
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Total time: 23:52.051s (Wall Clock)
>>> [INFO] Finished at: Tue May 22 05:10:14 EDT 2012
>>> [INFO] Final Memory: 302M/781M
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [FINDBUGS] Collecting findbugs analysis files...
>>> [FINDBUGS] Parsing 30 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 1 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/vdsbroker/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 439 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/common/target/findbugsXml.xml
>>> of module  with 335 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/compat/target/findbugsXml.xml
>>> of module  with 71 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/dal/target/findbugsXml.xml
>>> of module  with 27 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/engineencryptutils/target/findbugsXml.xml
>>> of module  with 10 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 18 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 23 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/types/target/findbugsXml.xml
>>> of module  with 10 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/root/target/findbugsXml.xml
>>> of module  with 5 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/searchbackend/target/findbugsXml.xml
>>> of module  with 13 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/utils/target/findbugsXml.xml
>>> of module  with 122 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/vdsbroker/target/findbugsXml.xml
>>> of module  with 238 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/engine-config/target/findbugsXml.xml
>>> of module  with 7 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 0 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/api/genericapi/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 21 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml
>>> of module  with 65 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml
>>> of module  with 29 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommon/target/findbugsXml.xml
>>> of module  with 420 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommonweb/target/findbugsXml.xml
>>> of module  with 602 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicompat/target/findbugsXml.xml
>>> of module  with 40 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/userportal/target/findbugsXml.xml
>>> of module  with 118 warnings.
>>> [FINDBUGS] Successfully parsed file
>>> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/findbugsXml.xml
>>> of module  with 56 warnings.
>>> [FINDBUGS] Computing warning deltas based on reference build #912
>>> [FINDBUGS] Using set difference to compute new warnings
>>> Build step 'Publish FindBugs analysis results' changed build result
>>> to UNSTABLE
>>> Email was triggered for: Unstable
>>> Sending email for trigger: Unstable
>>>
>>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From iheim at redhat.com  Fri Jun  1 15:39:40 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 01 Jun 2012 18:39:40 +0300
Subject: [Engine-devel] LOCALFS path validation
In-Reply-To: <ab65230d-5b3f-4ada-9530-b46aaef2b27b@zmail14.collab.prod.int.phx2.redhat.com>
References: <ab65230d-5b3f-4ada-9530-b46aaef2b27b@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4FC8E23C.8060901@redhat.com>

On 05/21/2012 09:37 PM, Gilad Chaplik wrote:
> Hi Pahim,
>
> Thanks for the input!
> Comments inline.
>
> Thanks,
> Gilad.
>
> ----- Original Message -----
>> From: "Amador pahim"<apahim at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Monday, May 21, 2012 5:52:34 PM
>> Subject: [Engine-devel] LOCALFS path validation
>>
>>
>> Hello,
>>
>> I'm starting to know the engine code. I chose a little unstandardized
>> behaviour to follow through the devel process. I have a patch and
>> I'd like to know if you fell relevant to correct this issue:
>>
>> - Description: Adding a LOCAL storage [1], webadmin does not validate
>> path against regex, sendind the invalid path (with final slash) to
>> vdsm [2] [3]. But, adding a NFS storage, the path is validated
>> before contacting vdsm [4] avoiding extra vdsm processing and
>> quickly/clearly informing user about what's wrong.
>>
>> - Expected result: Same behaviour to NFS and LOCALFS storage path
>> validation. Validate LOCALFS path in webadmin before send it to vdsm
>> [5].
>
> you may and should send a patch :)
>
>>
>> - Newbie doubt: Wouldn't be better to validate the both local and nfs
>> path on the backend, achieving all user interfaces/APIs?
>
> Because we have a rich client app (gwt), we can perform the validation also in the client side very easily,
> we do that to avoid unnecessary calls to the backend side, and to have a better&  responsive ui
> (client side validation is performed instantly - without the need to wait).
>
> Anyway, every validation performed in the client side needs to be performed also in backend side (for api, and other reasons (security?)).

the client side can validate the format of the path, not if it really 
exists.
do you mean local storage via the wizard, or just adding another storage 
domain?
the 'configure local storage' wizard requires the host to be in 
maintenance, which may or may not be a problem to implement this type of 
validation.


From iheim at redhat.com  Fri Jun  1 16:02:51 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 01 Jun 2012 19:02:51 +0300
Subject: [Engine-devel] compile time (was Re:  Maven 3 here we come!)
In-Reply-To: <4FBD42BC.3040808@redhat.com>
References: <4FBCB519.60606@redhat.com> <4FBD42BC.3040808@redhat.com>
Message-ID: <4FC8E7AB.5060802@redhat.com>

On 05/23/2012 11:04 PM, Yaniv Kaul wrote:
> On 05/23/2012 12:59 PM, Doron Fediuck wrote:
>> Hi all,
>> As discussed last month[1], we had to deal with some issues which
>> turned out to be a Maven bug.
>> Thanks to Juan and Asaf's work, our current sources now build properly
>> using Maven 3.
>> So you're all invited to migrate into Maven 3. Other than upgrading
>> your local maven package
>> no other action is needed.
>>
>> For now, Maven 2 will also work for you, but I expect in the future
>> we'd like to make use
>> of some advanced features, so migration to 3 is recommended.
>>
>> Talking about advanced features, an interesting challenge is feedback
>> on parallel builds [2].
>
> I'm not happy with parallel builds - it creates more java processes,
> each taking quite a bit of memory. This, in turn, causes them to swap,
> making everything crawl.
> Took me 22 minutes to compile the webadmin and additional 21 minutes for
> the user portal, with -T 4. I've had 3.5GB of swap used (and 7GB
> resident memory with 'java' processes running around).
> It usually takes me
>
> The command line I've used was:
> mvn -T 4 clean install -Pgwt-admin,gwt-user -DskipTests=true
> -Dmaven.test.skip=true
>
>
> As opposed to 7+ 3 minutes without '-T 4'.

Saggi gave me his command line, which doesn't require any change of 
settings.xml

mvn clean install -Pgwtdev,gwt-admin -DskipTests 
-Dgwt.userAgent=gecko1_8 -Dgwt.draftCompile=true 
-Dgwt.compiler.optimizationLevel=0 -Dgwt.compiler.localWorkers=2 
-Dmaven.aspectj.incremental=true -Dmaven.aspectj.time=true

I wonder if we shouldn't make something similar to this as the default.
preferably, add ./configure script to tweak different options (which is 
very common in non java projects).


From smizrahi at redhat.com  Fri Jun  1 16:14:03 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Fri, 01 Jun 2012 12:14:03 -0400 (EDT)
Subject: [Engine-devel] compile time (was Re:  Maven 3 here we come!)
In-Reply-To: <4FC8E7AB.5060802@redhat.com>
Message-ID: <b0bf52c8-34c7-426b-8f97-1803d2b01110@zmail16.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: engine-devel at ovirt.org, "<arch at ovirt.org>" <arch at ovirt.org>
> Sent: Friday, June 1, 2012 12:02:51 PM
> Subject: [Engine-devel] compile time (was Re:  Maven 3 here we come!)
> 
> On 05/23/2012 11:04 PM, Yaniv Kaul wrote:
> > On 05/23/2012 12:59 PM, Doron Fediuck wrote:
> >> Hi all,
> >> As discussed last month[1], we had to deal with some issues which
> >> turned out to be a Maven bug.
> >> Thanks to Juan and Asaf's work, our current sources now build
> >> properly
> >> using Maven 3.
> >> So you're all invited to migrate into Maven 3. Other than
> >> upgrading
> >> your local maven package
> >> no other action is needed.
> >>
> >> For now, Maven 2 will also work for you, but I expect in the
> >> future
> >> we'd like to make use
> >> of some advanced features, so migration to 3 is recommended.
> >>
> >> Talking about advanced features, an interesting challenge is
> >> feedback
> >> on parallel builds [2].
> >
> > I'm not happy with parallel builds - it creates more java
> > processes,
> > each taking quite a bit of memory. This, in turn, causes them to
> > swap,
> > making everything crawl.
> > Took me 22 minutes to compile the webadmin and additional 21
> > minutes for
> > the user portal, with -T 4. I've had 3.5GB of swap used (and 7GB
> > resident memory with 'java' processes running around).
> > It usually takes me
> >
> > The command line I've used was:
> > mvn -T 4 clean install -Pgwt-admin,gwt-user -DskipTests=true
> > -Dmaven.test.skip=true
> >
> >
> > As opposed to 7+ 3 minutes without '-T 4'.
> 
> Saggi gave me his command line, which doesn't require any change of
> settings.xml
> 
> mvn clean install -Pgwtdev,gwt-admin -DskipTests
> -Dgwt.userAgent=gecko1_8 -Dgwt.draftCompile=true
> -Dgwt.compiler.optimizationLevel=0 -Dgwt.compiler.localWorkers=2
> -Dmaven.aspectj.incremental=true -Dmaven.aspectj.time=true
It will have to be optional with configure flags like --disable-optimization --disable-extra-user-agents --local-workers=2
So people know what they are doing and can choose what is best for them as I use 2 local workers because my host as 2 cores with HT which means by default it will start 4 local workers and have all my processing threads stuck on IO stopping the machine. Other, more powerful hosts, might be able to ramp the local workers.
Also you might want to turn on debug but still check other user agents.

> 
> I wonder if we shouldn't make something similar to this as the
> default.
> preferably, add ./configure script to tweak different options (which
> is
> very common in non java projects).
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From apahim at redhat.com  Fri Jun  1 17:16:00 2012
From: apahim at redhat.com (Amador Pahim)
Date: Fri, 01 Jun 2012 14:16:00 -0300
Subject: [Engine-devel] LOCALFS path validation
In-Reply-To: <4FC8E23C.8060901@redhat.com>
References: <ab65230d-5b3f-4ada-9530-b46aaef2b27b@zmail14.collab.prod.int.phx2.redhat.com>
	<4FC8E23C.8060901@redhat.com>
Message-ID: <4FC8F8D0.5050702@redhat.com>

On 06/01/2012 12:39 PM, Itamar Heim wrote:
> On 05/21/2012 09:37 PM, Gilad Chaplik wrote:
>> Hi Pahim,
>>
>> Thanks for the input!
>> Comments inline.
>>
>> Thanks,
>> Gilad.
>>
>> ----- Original Message -----
>>> From: "Amador pahim"<apahim at redhat.com>
>>> To: engine-devel at ovirt.org
>>> Sent: Monday, May 21, 2012 5:52:34 PM
>>> Subject: [Engine-devel] LOCALFS path validation
>>>
>>>
>>> Hello,
>>>
>>> I'm starting to know the engine code. I chose a little unstandardized
>>> behaviour to follow through the devel process. I have a patch and
>>> I'd like to know if you fell relevant to correct this issue:
>>>
>>> - Description: Adding a LOCAL storage [1], webadmin does not validate
>>> path against regex, sendind the invalid path (with final slash) to
>>> vdsm [2] [3]. But, adding a NFS storage, the path is validated
>>> before contacting vdsm [4] avoiding extra vdsm processing and
>>> quickly/clearly informing user about what's wrong.
>>>
>>> - Expected result: Same behaviour to NFS and LOCALFS storage path
>>> validation. Validate LOCALFS path in webadmin before send it to vdsm
>>> [5].
>>
>> you may and should send a patch :)
>>
>>>
>>> - Newbie doubt: Wouldn't be better to validate the both local and nfs
>>> path on the backend, achieving all user interfaces/APIs?
>>
>> Because we have a rich client app (gwt), we can perform the 
>> validation also in the client side very easily,
>> we do that to avoid unnecessary calls to the backend side, and to 
>> have a better&  responsive ui
>> (client side validation is performed instantly - without the need to 
>> wait).
>>
>> Anyway, every validation performed in the client side needs to be 
>> performed also in backend side (for api, and other reasons (security?)).
>
> the client side can validate the format of the path, not if it really 
> exists.
> do you mean local storage via the wizard, or just adding another 
> storage domain?
> the 'configure local storage' wizard requires the host to be in 
> maintenance, which may or may not be a problem to implement this type 
> of validation.

I mean just adding a LOCALFS storage domain with an invalid path, like this:
https://picasaweb.google.com/lh/photo/FWNiou2Y12GZO3AjfCH6K7QAv8cs6edaj3fEcMleB60
Currently we have this:
https://picasaweb.google.com/lh/photo/Pof6Z8ohgQAkRTDpEJKG-LQAv8cs6edaj3fEcMleB60
I sent a patch...
http://gerrit.ovirt.org/4857
... in order to do this:
https://picasaweb.google.com/lh/photo/PgzYrZHkkvm-WtFk_UFZLrQAv8cs6edaj3fEcMleB60
Just like "New NFS Domain" currently does:
https://picasaweb.google.com/lh/photo/Fd3zWegWE0T5C2tDo_tPZrQAv8cs6edaj3fEcMleB60


From eedri at redhat.com  Sat Jun  2 09:00:34 2012
From: eedri at redhat.com (Eyal Edri)
Date: Sat, 02 Jun 2012 05:00:34 -0400 (EDT)
Subject: [Engine-devel] compile time (was Re:  Maven 3 here we come!)
In-Reply-To: <4FC8E7AB.5060802@redhat.com>
Message-ID: <dc9224c6-6fe2-4db0-a720-e2185f78c63b@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Yaniv Kaul" <ykaul at redhat.com>
> Cc: engine-devel at ovirt.org, "<arch at ovirt.org>" <arch at ovirt.org>
> Sent: Friday, June 1, 2012 7:02:51 PM
> Subject: compile time (was Re: [Engine-devel] Maven 3 here we come!)
> 
> On 05/23/2012 11:04 PM, Yaniv Kaul wrote:
> > On 05/23/2012 12:59 PM, Doron Fediuck wrote:
> >> Hi all,
> >> As discussed last month[1], we had to deal with some issues which
> >> turned out to be a Maven bug.
> >> Thanks to Juan and Asaf's work, our current sources now build
> >> properly
> >> using Maven 3.
> >> So you're all invited to migrate into Maven 3. Other than
> >> upgrading
> >> your local maven package
> >> no other action is needed.
> >>
> >> For now, Maven 2 will also work for you, but I expect in the
> >> future
> >> we'd like to make use
> >> of some advanced features, so migration to 3 is recommended.
> >>
> >> Talking about advanced features, an interesting challenge is
> >> feedback
> >> on parallel builds [2].
> >
> > I'm not happy with parallel builds - it creates more java
> > processes,
> > each taking quite a bit of memory. This, in turn, causes them to
> > swap,
> > making everything crawl.
> > Took me 22 minutes to compile the webadmin and additional 21
> > minutes for
> > the user portal, with -T 4. I've had 3.5GB of swap used (and 7GB
> > resident memory with 'java' processes running around).
> > It usually takes me
> >
> > The command line I've used was:
> > mvn -T 4 clean install -Pgwt-admin,gwt-user -DskipTests=true
> > -Dmaven.test.skip=true
> >
> >
> > As opposed to 7+ 3 minutes without '-T 4'.
> 
> Saggi gave me his command line, which doesn't require any change of
> settings.xml
> 
> mvn clean install -Pgwtdev,gwt-admin -DskipTests
> -Dgwt.userAgent=gecko1_8 -Dgwt.draftCompile=true
> -Dgwt.compiler.optimizationLevel=0 -Dgwt.compiler.localWorkers=2
> -Dmaven.aspectj.incremental=true -Dmaven.aspectj.time=true

how much time this command cuts from build time? 
shouldn't we use this in CI as well?

> 
> I wonder if we shouldn't make something similar to this as the
> default.
> preferably, add ./configure script to tweak different options (which
> is
> very common in non java projects).
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
> 


From iheim at redhat.com  Sun Jun  3 08:04:36 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 03 Jun 2012 11:04:36 +0300
Subject: [Engine-devel] LOCALFS path validation
In-Reply-To: <4FC8F8D0.5050702@redhat.com>
References: <ab65230d-5b3f-4ada-9530-b46aaef2b27b@zmail14.collab.prod.int.phx2.redhat.com>
	<4FC8E23C.8060901@redhat.com> <4FC8F8D0.5050702@redhat.com>
Message-ID: <4FCB1A94.8080201@redhat.com>

On 06/01/2012 08:16 PM, Amador Pahim wrote:
> On 06/01/2012 12:39 PM, Itamar Heim wrote:
>> On 05/21/2012 09:37 PM, Gilad Chaplik wrote:
>>> Hi Pahim,
>>>
>>> Thanks for the input!
>>> Comments inline.
>>>
>>> Thanks,
>>> Gilad.
>>>
>>> ----- Original Message -----
>>>> From: "Amador pahim"<apahim at redhat.com>
>>>> To: engine-devel at ovirt.org
>>>> Sent: Monday, May 21, 2012 5:52:34 PM
>>>> Subject: [Engine-devel] LOCALFS path validation
>>>>
>>>>
>>>> Hello,
>>>>
>>>> I'm starting to know the engine code. I chose a little unstandardized
>>>> behaviour to follow through the devel process. I have a patch and
>>>> I'd like to know if you fell relevant to correct this issue:
>>>>
>>>> - Description: Adding a LOCAL storage [1], webadmin does not validate
>>>> path against regex, sendind the invalid path (with final slash) to
>>>> vdsm [2] [3]. But, adding a NFS storage, the path is validated
>>>> before contacting vdsm [4] avoiding extra vdsm processing and
>>>> quickly/clearly informing user about what's wrong.
>>>>
>>>> - Expected result: Same behaviour to NFS and LOCALFS storage path
>>>> validation. Validate LOCALFS path in webadmin before send it to vdsm
>>>> [5].
>>>
>>> you may and should send a patch :)
>>>
>>>>
>>>> - Newbie doubt: Wouldn't be better to validate the both local and nfs
>>>> path on the backend, achieving all user interfaces/APIs?
>>>
>>> Because we have a rich client app (gwt), we can perform the
>>> validation also in the client side very easily,
>>> we do that to avoid unnecessary calls to the backend side, and to
>>> have a better& responsive ui
>>> (client side validation is performed instantly - without the need to
>>> wait).
>>>
>>> Anyway, every validation performed in the client side needs to be
>>> performed also in backend side (for api, and other reasons (security?)).
>>
>> the client side can validate the format of the path, not if it really
>> exists.
>> do you mean local storage via the wizard, or just adding another
>> storage domain?
>> the 'configure local storage' wizard requires the host to be in
>> maintenance, which may or may not be a problem to implement this type
>> of validation.
>
> I mean just adding a LOCALFS storage domain with an invalid path, like
> this:
> https://picasaweb.google.com/lh/photo/FWNiou2Y12GZO3AjfCH6K7QAv8cs6edaj3fEcMleB60
>
> Currently we have this:
> https://picasaweb.google.com/lh/photo/Pof6Z8ohgQAkRTDpEJKG-LQAv8cs6edaj3fEcMleB60
>
> I sent a patch...
> http://gerrit.ovirt.org/4857
> ... in order to do this:
> https://picasaweb.google.com/lh/photo/PgzYrZHkkvm-WtFk_UFZLrQAv8cs6edaj3fEcMleB60
>
> Just like "New NFS Domain" currently does:
> https://picasaweb.google.com/lh/photo/Fd3zWegWE0T5C2tDo_tPZrQAv8cs6edaj3fEcMleB60
>

ok - sounds basic enough of a change. I'd just note in the patch you are 
re-using same REGEX used for the previous validation happening in the 
backend (and actually try to re-use it, to not maintain a change in too 
many places0


From iheim at redhat.com  Sun Jun  3 08:30:13 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 03 Jun 2012 11:30:13 +0300
Subject: [Engine-devel] compile time (was Re:  Maven 3 here we come!)
In-Reply-To: <dc9224c6-6fe2-4db0-a720-e2185f78c63b@zmail17.collab.prod.int.phx2.redhat.com>
References: <dc9224c6-6fe2-4db0-a720-e2185f78c63b@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4FCB2095.9060205@redhat.com>

On 06/02/2012 12:00 PM, Eyal Edri wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim"<iheim at redhat.com>
>> To: "Yaniv Kaul"<ykaul at redhat.com>
>> Cc: engine-devel at ovirt.org, "<arch at ovirt.org>"<arch at ovirt.org>
>> Sent: Friday, June 1, 2012 7:02:51 PM
>> Subject: compile time (was Re: [Engine-devel] Maven 3 here we come!)
>>
>> On 05/23/2012 11:04 PM, Yaniv Kaul wrote:
>>> On 05/23/2012 12:59 PM, Doron Fediuck wrote:
>>>> Hi all,
>>>> As discussed last month[1], we had to deal with some issues which
>>>> turned out to be a Maven bug.
>>>> Thanks to Juan and Asaf's work, our current sources now build
>>>> properly
>>>> using Maven 3.
>>>> So you're all invited to migrate into Maven 3. Other than
>>>> upgrading
>>>> your local maven package
>>>> no other action is needed.
>>>>
>>>> For now, Maven 2 will also work for you, but I expect in the
>>>> future
>>>> we'd like to make use
>>>> of some advanced features, so migration to 3 is recommended.
>>>>
>>>> Talking about advanced features, an interesting challenge is
>>>> feedback
>>>> on parallel builds [2].
>>>
>>> I'm not happy with parallel builds - it creates more java
>>> processes,
>>> each taking quite a bit of memory. This, in turn, causes them to
>>> swap,
>>> making everything crawl.
>>> Took me 22 minutes to compile the webadmin and additional 21
>>> minutes for
>>> the user portal, with -T 4. I've had 3.5GB of swap used (and 7GB
>>> resident memory with 'java' processes running around).
>>> It usually takes me
>>>
>>> The command line I've used was:
>>> mvn -T 4 clean install -Pgwt-admin,gwt-user -DskipTests=true
>>> -Dmaven.test.skip=true
>>>
>>>
>>> As opposed to 7+ 3 minutes without '-T 4'.
>>
>> Saggi gave me his command line, which doesn't require any change of
>> settings.xml
>>
>> mvn clean install -Pgwtdev,gwt-admin -DskipTests
>> -Dgwt.userAgent=gecko1_8 -Dgwt.draftCompile=true
>> -Dgwt.compiler.optimizationLevel=0 -Dgwt.compiler.localWorkers=2
>> -Dmaven.aspectj.incremental=true -Dmaven.aspectj.time=true
>
> how much time this command cuts from build time?
> shouldn't we use this in CI as well?

i get a 3.5 minutes build with this.

with the exception of skipTests which in some jobs you want to run - 
yes. also -Pgwt-user is relevant to some jobs.
(and if this becomes more of the default compile mode, you would need to 
tweak it only when you need to)

>
>>
>> I wonder if we shouldn't make something similar to this as the
>> default.
>> preferably, add ./configure script to tweak different options (which
>> is
>> very common in non java projects).
>> _______________________________________________
>> Arch mailing list
>> Arch at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch
>>



From dfediuck at redhat.com  Mon Jun  4 06:41:26 2012
From: dfediuck at redhat.com (Doron Fediuck)
Date: Mon, 04 Jun 2012 09:41:26 +0300
Subject: [Engine-devel] gerrit 2.3
In-Reply-To: <4FCBC335.7000105@redhat.com>
References: <4FCBC335.7000105@redhat.com>
Message-ID: <4FCC5896.2040706@redhat.com>

On 03/06/12 23:04, Itamar Heim wrote:
> fyi - gerrit has been upgraded to version 2.3.
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra

Adding the devel list.
Latest gerrit started a concept of _draft_ branches, which should help all [WIP] users.
>From the notes:
" Also adds magic branches refs/drafts/ and refs/publish/ that will handle whether or not a patchset is a draft or goes straight to review. refs/for/ should be deprecated in favor of explicitly marking a patchset as a draft or directly to review. "

I strongly recommend everyone to take a look here:
http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.3.html#_drafts

(as well as the rest of the new features and updates).
-- 

/d

"Willyoupleasehelpmefixmykeyboard?Thespacebarisbroken!"


From iheim at redhat.com  Mon Jun  4 06:43:34 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 04 Jun 2012 09:43:34 +0300
Subject: [Engine-devel] gerrit 2.3
In-Reply-To: <4FCC5896.2040706@redhat.com>
References: <4FCBC335.7000105@redhat.com> <4FCC5896.2040706@redhat.com>
Message-ID: <4FCC5916.2090907@redhat.com>

On 06/04/2012 09:41 AM, Doron Fediuck wrote:
> On 03/06/12 23:04, Itamar Heim wrote:
>> fyi - gerrit has been upgraded to version 2.3.
>> _______________________________________________
>> Infra mailing list
>> Infra at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/infra
>
> Adding the devel list.
> Latest gerrit started a concept of _draft_ branches, which should help all [WIP] users.
>  From the notes:
> " Also adds magic branches refs/drafts/ and refs/publish/ that will handle whether or not a patchset is a draft or goes straight to review. refs/for/ should be deprecated in favor of explicitly marking a patchset as a draft or directly to review."
>
> I strongly recommend everyone to take a look here:
> http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.3.html#_drafts
>
> (as well as the rest of the new features and updates).

just a btw that users of latest git-review failed on this refs/publish 
since our gerrit was older and should now be better


From lpeer at redhat.com  Mon Jun  4 10:45:46 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Mon, 04 Jun 2012 06:45:46 -0400 (EDT)
Subject: [Engine-devel] oVirt - quantum integration
Message-ID: <3b2849d1-b037-462a-ba54-c4b5851bd63f@zmail14.collab.prod.int.phx2.redhat.com>

The following is a new meeting request:

Subject: oVirt - quantum integration 
Organiser: "Livnat Peer" <lpeer at redhat.com> 

Time: Wednesday, 6 June, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem
 
Invitees: engine-devel at ovirt.org; arch at ovirt.com 


*~*~*~*~*~*~*~*~*~*


Hi All,

We'll have a discussion on oVirt-Quantum integration.
In the meeting we'll discuss -
http://www.ovirt.org/wiki/Quantum_and_oVirt

Thanks, Livnat

Bridge ID: 972506565679
Dial-in information:
Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679
Reservationless-Plus International Dial-In Number: (212) 729-5016
Conference code: 972506565679

Global Access Numbers Local:
Australia, Sydney Dial-In #: 0289852326
Austria, Vienna Dial-In #: 012534978196
Belgium, Brussels Dial-In #: 027920405
China Dial-In #: 4006205013
Denmark, Copenhagen Dial-In #: 32729215
Finland, Helsinki Dial-In #: 0923194436
France, Paris Dial-In #: 0170377140
Germany, Berlin Dial-In #: 030300190579
Ireland, Dublin Dial-In #: 014367793
Italy, Milan Dial-In #: 0236269529
Netherlands, Amsterdam Dial-In #: 0207975872
Norway, Oslo Dial-In #: 21033188
Singapore Dial-In #: 64840858
Spain, Barcelona Dial-In #: 935452328
Sweden, Stockholm Dial-In #: 0850513770
Switzerland, Geneva Dial-In #: 0225927881
United Kingdom Dial-In #: 02078970515
United Kingdom Dial-In #: 08445790676
United Kingdom, LocalCall Dial-In #: 08445790678
United States Dial-In #: 2127295016


Global Access Numbers Tollfree:
Argentina Dial-In #: 8004441016
Australia Dial-In #: 1800337169
Austria Dial-In #: 0800005898
Bahamas Dial-In #: 18002054776
Bahrain Dial-In #: 80004377
Belgium Dial-In #: 080048325
Brazil Dial-In #: 08008921002
Bulgaria Dial-In #: 008001100236
Chile Dial-In #: 800370228
Colombia Dial-In #: 018009134033
Costa Rica Dial-In #: 08000131048
Cyprus Dial-In #: 80095297
Czech Republic Dial-In #: 800700318
Denmark Dial-In #: 80887114
Dominican Republic Dial-In #: 18887512313
Estonia Dial-In #: 8000100232
Finland Dial-In #: 0800117116
France Dial-In #: 0805632867
Germany Dial-In #: 8006647541
Greece Dial-In #: 00800127562
Hong Kong Dial-In #: 800930349
Hungary Dial-In #: 0680016796
Iceland Dial-In #: 8008967
India Dial-In #: 0008006501533
Indonesia Dial-In #: 0018030179162
Ireland Dial-In #: 1800932401
Israel Dial-In #: 1809462557
Italy Dial-In #: 800985897
Jamaica Dial-In #: 18002050328
Japan Dial-In #: 0120934453
Korea (South) Dial-In #: 007986517393
Latvia Dial-In #: 80003339
Lithuania Dial-In #: 880030479
Luxembourg Dial-In #: 80026595
Malaysia Dial-In #: 1800814451
Mexico Dial-In #: 0018664590915
New Zealand Dial-In #: 0800888167
Norway Dial-In #: 80012994
Panama Dial-In #: 008002269184
Philippines Dial-In #: 180011100991
Poland Dial-In #: 008001210187
Portugal Dial-In #: 800814625
Russian Federation Dial-In #: 81080028341012
Saint Kitts and Nevis Dial-In #: 18002059252
Singapore Dial-In #: 8006162235
Slovak Republic Dial-In #: 0800001441
South Africa Dial-In #: 0800981148
Spain Dial-In #: 800300524
Sweden Dial-In #: 200896860
Switzerland Dial-In #: 800650077
Taiwan Dial-In #: 00801127141
Thailand Dial-In #: 001800656966
Trinidad and Tobago Dial-In #: 18002024615
United Arab Emirates Dial-In #: 8000650591
United Kingdom Dial-In #: 08006948057
United States Dial-In #: 8004518679
Uruguay Dial-In #: 00040190315
Venezuela Dial-In #: 08001627182 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120604/9ac3b0a6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 8789 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120604/9ac3b0a6/attachment.ics>

From deepakcs at linux.vnet.ibm.com  Mon Jun  4 10:49:47 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Mon, 04 Jun 2012 16:19:47 +0530
Subject: [Engine-devel] Fwd: [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <CAGZKiBprEgibga6A115WqiJVKWofvDz7E3C--_hHce93+f3Vbg@mail.gmail.com>
References: <4FC5EAA6.3090605@linux.vnet.ibm.com>
	<20120531140152.GH4096@localhost.localdomain>
	<CAGZKiBprEgibga6A115WqiJVKWofvDz7E3C--_hHce93+f3Vbg@mail.gmail.com>
Message-ID: <4FCC92CB.7030401@linux.vnet.ibm.com>

(for some reason i never recd. Adam's note tho' I am subscribed to all 
the 3 lists Cc'ed here, strange !
  Replying off from the mail fwd.ed to me from my colleague, pls see my 
responses inline below. Thanks. )

>
>
> ---------- Forwarded message ----------
> From: *Adam Litke* <agl at us.ibm.com <mailto:agl at us.ibm.com>>
> Date: Thu, May 31, 2012 at 7:31 PM
> Subject: Re: [vdsm] RFC: Writeup on VDSM-libstoragemgmt integration
> To: Deepak C Shetty <deepakcs at linux.vnet.ibm.com 
> <mailto:deepakcs at linux.vnet.ibm.com>>
> Cc: libstoragemgmt-devel at lists.sourceforge.net 
> <mailto:libstoragemgmt-devel at lists.sourceforge.net>, 
> engine-devel at ovirt.org <mailto:engine-devel at ovirt.org>, VDSM Project 
> Development <vdsm-devel at lists.fedorahosted.org 
> <mailto:vdsm-devel at lists.fedorahosted.org>>
>
>
> On Wed, May 30, 2012 at 03:08:46PM +0530, Deepak C Shetty wrote:
> > Hello All,
> >
> >     I have a draft write-up on the VDSM-libstoragemgmt integration.
> > I wanted to run this thru' the mailing list(s) to help tune and
> > crystallize it, before putting it on the ovirt wiki.
> > I have run this once thru Ayal and Tony, so have some of their
> > comments incorporated.
> >
> > I still have few doubts/questions, which I have posted below with
> > lines ending with '?'
> >
> > Comments / Suggestions are welcome & appreciated.
> >
> > thanx,
> > deepak
> >
> > [Ccing engine-devel and libstoragemgmt lists as this stuff is
> > relevant to them too]
> >
> > 
> --------------------------------------------------------------------------------------------------------------
> >
> > 1) Background:
> >
> > VDSM provides high level API for node virtualization management. It
> > acts in response to the requests sent by oVirt Engine, which uses
> > VDSM to do all node virtualization related tasks, including but not
> > limited to storage management.
> >
> > libstoragemgmt aims to provide vendor agnostic API for managing
> > external storage array. It should help system administrators
> > utilizing open source solutions have a way to programmatically
> > manage their storage hardware in a vendor neutral way. It also aims
> > to facilitate management automation, ease of use and take advantage
> > of storage vendor supported features which improve storage
> > performance and space utilization.
> >
> > Home Page: http://sourceforge.net/apps/trac/libstoragemgmt/
> >
> > libstoragemgmt (LSM) today supports C and python plugins for talking
> > to external storage array using SMI-S as well as native interfaces
> > (eg: netapp plugin )
> > Plan is to grow the SMI-S interface as needed over time and add more
> > vendor specific plugins for exploiting features not possible via
> > SMI-S or have better alternatives than using SMI-S.
> > For eg: Many of the copy offload features require to use vendor
> > specific commands, which justifies the need for a vendor specific
> > plugin.
> >
> >
> > 2) Goals:
> >
> >     2a) Ability to plugin external storage array into oVirt/VDSM
> > virtualization stack, in a vendor neutral way.
> >
> >     2b) Ability to list features/capabilities and other statistical
> > info of the array
> >
> >     2c) Ability to utilize the storage array offload capabilities
> > from oVirt/VDSM.
> >
> >
> > 3) Details:
> >
> > LSM will sit as a new repository engine in VDSM.
> > VDSM Repository Engine WIP @ http://gerrit.ovirt.org/#change,192
> >
> > Current plan is to have LSM co-exist with VDSM on the virtualization 
> nodes.
> >
> > *Note : 'storage' used below is generic. It can be a file/nfs-export
> > for NAS targets and LUN/logical-drive for SAN targets.
> >
> > VDSM can use LSM and do the following...
> >     - Provision storage
> >     - Consume storage
> >
> > 3.1) Provisioning Storage using LSM
> >
> > Typically this will be done by a Storage administrator.
> >
> > oVirt/VDSM should provide storage admin the
> >     - ability to list the different storage arrays along with their
> > types (NAS/SAN), capabilities, free/used space.
> >     - ability to provision storage using any of the array
> > capabilities (eg: thin provisioned lun or new NFS export )
> >     - ability to manage the provisioned storage (eg: resize/delete 
> storage)
>
> I guess vdsm will need to model a new type of object (perhaps 
> StorageTarget) to
> be used for performing the above provisioning operations.  Then, to 
> consume the
> provisioned storage, we could create a StorageConnectionRef by passing 
> in a
> StorageTarget object and some additional parameters.  Sound about right?

Sounds right to me, but I am not an expert in VDSM object model, 
Saggi/Ayal/Dan can provide
more inputs here.  The (proposed) storage array entity in ovirt engine 
can use this vdsm object to
communicate and work with the storage array in doing the provisioning work.

Going ahead with the change to new Image Repository, I was envisioning 
that LSM when integrated as
a new repo engine will exhibit "Storage Provisioning" as a implicit 
feature/capability, only then it
will be picked up by the StorageTarget, else not.

>
> > Once the storage is provisioned by the storage admin, VDSM will have
> > to refresh the host(s) for them to be able to see the newly
> > provisioned storage.
>
> How would this refresh affect currently connected storage and running VMs?

I am not too sure on this... looking for more info from the experts 
here. Per ayal, getDeviceInfo
should help refresh, but by 'affect' are you referring to what happens 
if post refresh the device
IDs and/or names of the existing storage on the host changes ? What 
exactly is the concern here ?

>
> > 3.1.1) Potential flows:
> >
> > Mgmt -> vdsm -> lsm: create LUN + LUN Mapping / Zoning / whatever is
> > needed to make LUN available to list of hosts passed by mgmt
> > Mgmt -> vdsm: getDeviceList (refreshes host and gets list of devices)
> >  Repeat above for all relevant hosts (depending on list passed
> > earlier, mostly relevant when extending an existing VG)
> > Mgmt -> use LUN in normal flows.
> >
> >
> > 3.1.2) How oVirt Engine will know which LSM to use ?
> >
> > Normally the way this works today is that user can choose the host
> > to use (default today is SPM), however there are a few flows where
> > mgmt will know which host to use:
> > 1. extend storage domain (add LUN to existing VG) - Use SPM and make
> > sure *all* hosts that need access to this SD can see the new LUN
> > 2. attach new LUN to a VM which is pinned to a specific host - use 
> this host
> > 3. attach new LUN to a VM which is not pinned - use a host from the
> > cluster the VM belongs to and make sure all nodes in cluster can see
> > the new LUN
>
> You are still going to need to worry about locking the shared storage 
> resource.
> Will libstoragemgmt have storage clustering support baked in or will 
> we continue
> to rely on SPM?  If the latter is true, most/all of these operations 
> would still
> need to be done by SPM if I understand correctly.

The above scenarios were noted by me on behalf of Ayal.
I don't think LSM will worry abt storage clustering. We are just using 
LSM to 'talk' with the
storage array. I am not sure if we need locking for the above scenarios. 
We are just ensuring
that the newly provisioned LUN is visible to the relevant hosts, so not 
sure why we might need
locking?

>
> > Flows for which there is no clear candidate (Maybe we can use the
> > SPM host itself which is the default ?)
> > 1. create a new disk without attaching it to any VM
> > 2. create a LUN for a new storage domain
>
> Yes, SPM would seem correct to me.
>
> > 3.2) Consuming storage using LSM
> >
> > Typically this will be done by a virtualization administrator
> >
> > oVirt/VDSM should allow virtualization admin to
> >     - Create a new storage domain using the storage on the array.
> >     - Be able to specify whether VDSM should use the storage offload
> > capability (default) or override it to use its own internal logic.
>
> If vdsm can make the right decisions, I would prefer that vdsm decides 
> when to use
> hardware offload and when to use software algorithms without administrator
> intervention.  It's another case where oVirt can provide value-add by
> simplifying the configuration and providing optimal performance.

Per ayal, the thought was that in scenarios we know where the storage 
array implementation is
not optimal, we can override and tell VDSM to use its internal logic 
than offload.

>
> > 4) VDSM potential changes:
> >
> > 4.1) How to represent a VM disk, 1 LUN = 1 VMdisk or 1 LV = 1 VMdisk
> > ? which bring another question...1 array == 1 storage domain OR 1
> > LUN/nfs-export on the array == 1 storage domain ?
>
> Saggi has mentioned some ideas on this topic so I will encourage him 
> to explain
> his thoughts here.

Looking forward to Saggi's thoughts :)

>
> >
> > Pros & Cons of each...
> >
> > 1 array == 1 storage domain
> >     - Each new vmdisk (aka volume) will be a new lun/file on the array.
> >     - Easier to exploit offload capabilities, as they are available
> > at the LUN/File granularity
> >     - Will there be any issues where there will be too many
> > LUNs/Files ... any maxluns limit on linux hosts that we might hit ?
> >         -- VDSM has been tested with 1K LUNs and it worked fine - ayal
> >     - Storage array limitations on the number of LUNs can be a
> > downside here.
> >     - Would it be ok to share the array for hosting another storage
> > domain if need be ?
> >         -- Provided the existing domain is not utilising all of the
> > free space
> >         -- We can create new LUNs and hand it over to anyone needed ?
> >     -- Changes needed in VDSM to work with raw LUNs, today it only
> > has support for consuming LUNs via VG/LV.
> >
> > 1 LUN/nfs-export on the array == 1 storage domain
> >     - How to represent a new vmdisk (aka vdsm volume) if its a LUN
> > provisioned using SAN target ?
> >         -- Will it be VG/LV as is done today for block domains ?
> >         -- If yes, then it will be difficult to exploit offload
> > capabilities, as they are at LUN level, not at LV level.
> >     - Each new vmdisk will be a new file on the nfs-export, assuming
> > offload capability is available at the file level, so this should
> > work for NAS targets ?
> >     - Can use the storage array for hosting multiple storage domains.
> >         -- Provision one more LUN and use it for another storage
> > domain if need be.
> >     - VDSM already supports this today, as part of block storage
> > domains for LUNs case.
> >
> > Note that we will allow user to do either one of the two options
> > above, depending on need.
> >
> > 4.2) Storage domain metadata will also include the
> > features/capabilities of the storage array as reported by LSM.
> >         - Capabilities (taken via LSM) will be stored in the domain
> > metadata during storage domain create flow.
> >         - Need changes in oVirt engine as well ( see 'oVirt Engine
> > potential changes' section below )
>
> Do we want to store the exact hw capabilities or some set of vdsm 
> chosen feature
> bits that are set at create time based on the discovered hw 
> capabilities?  The
> difference would be that vdsm could choose which features to enable at 
> create
> time and update those features later if needed.

IIUC, you are saying VDSM will only look for those capabilities, whcih 
are of interest to it and
store it? That should be done by way LSM returning its capabilities as 
part of it being a Image Repo.
I am referring to how localFSRepo (def capabilities) is shown in the PoC 
Saggie posted @
http://gerrit.ovirt.org/#change,192

>
> > 4.3) VDSM to poll LSM for array capabilities on a regular basis ?
> > Per ayal:
> >     - If we have a 'storage array' entity in oVirt Engine (see
> > 'oVirt Engine potential changes' section below ) then we can have a
> > 'refresh capabilities' button/verb.
> >     - We can periodically query the storage array.
> >     - Query LSM before running operations (sounds redundant to me,
> > but if it's cheap enough it could be simplest).
> >
> >     Probably need a combination of 1+2 (query at very low frequency
> > - 1/hour or 1/day + refresh button)
>
> This problem can be aleviated by the abstraction I suggested above. 
>  Then, LSM
> can be queried only when we may want to adjust the policy connected with a
> particular storage target.

Not clear to me, can you explain more ?
LSM might need to be contacted for updating the capabilities, because 
storage admins can add/remove
capabilities over a period of time. Many storage arrays provide ability 
to enable/disable array
features on demand.

>
> > 5) oVirt Engine potential changes - as described by ayal :
> >
> >     - We will either need a new 'storage array' entity in engine to
> > keep credentials, or, in case of storage array as storage domain,
> > just keep this info as part of the domain at engine level.
> >     - Have a 'storage array' entity in oVirt Engine to support
> > 'refresh capabilities' as a button/verb.
> >     - When user during storage provisioning, selects a LUN exported
> > from a storage array (via LSM), the oVirt Engine would know from
> > then onwards that this LUN is being served via LSM.
> >       It would then  be able to query the  capabilities of the LUN
> > and show it to the virt admin during storage consumption flow.
> >
> > 6) Potential flows:
> >     - Create snapshot flow
> >         -- VDSM will check the snapshot offload capability in the
> > domain metadata
> >         -- If available, and override is not configured, it will use
> > LSM to offload LUN/File snapshot
> >         -- If override is configured or capability is not available,
> > it will use its internal logic to create
> >            snapshot (qcow2).
> >
> >     - Copy/Clone vmdisk flow
> >         -- VDSM will check the copy offload capability in the domain
> > metadata
> >         -- If available, and override is not configured, it will use
> > LSM to offload LUN/File copy
> >         -- If override is configured or capability is not available,
> > it will use its internal logic to create
> >            snapshot (eg: dd cmd in case of LUN).
> >
> > 7) LSM potential changes:
> >
> >     - list features/capabilities of the array. Eg: copy offload,
> > thin prov. etc.
> >     - list containers (aka pools) (present in LSM today)
> >     - Ability to list different types of arrays being managed, their
> > capabilities and used/free space
> >     - Ability to create/list/delete/resize volumes ( LUN or exports,
> > available in LSM as of today)
> >     - Get monitoring info with object (LUN/snapshot/volume) as
> > optional parameter for specific info. eg: container/pool free/used
> > space, raid type etc.
> >
> > Need to make sure above info is listed in a coherent way across
> > arrays (number of LUNs, raid type used? free/total per
> > container/pool, per LUN?. Also need I/O statistics wherever
> > possible.

I forgot to add this in the original mail.. adding it now.

8) Concerns/Issues

     - Per Tony of libstoragemgmt

	-- Some additional things to consider.

	-- Some of the array vendors may not allow multiple points of control at
	the same time. e.g. you may not be able to have 2 or more nodes running
	libStorageMgmt at the same time talking to the same array.  NetApp
	limits what things can be done concurrently.

	-- LibStorageMgmt currently just provides the bits to control external
	storage arrays.  The plug-in daemon and the plug-ins themselves execute
	unprivileged.

     - How does the change from SPM to SDM will affect the above discussions ?



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

From apahim at redhat.com  Mon Jun  4 11:50:18 2012
From: apahim at redhat.com (Amador Pahim)
Date: Mon, 04 Jun 2012 08:50:18 -0300
Subject: [Engine-devel] LOCALFS path validation
In-Reply-To: <4FCB1A94.8080201@redhat.com>
References: <ab65230d-5b3f-4ada-9530-b46aaef2b27b@zmail14.collab.prod.int.phx2.redhat.com>
	<4FC8E23C.8060901@redhat.com> <4FC8F8D0.5050702@redhat.com>
	<4FCB1A94.8080201@redhat.com>
Message-ID: <4FCCA0FA.9020002@redhat.com>

On 06/03/2012 05:04 AM, Itamar Heim wrote:
> On 06/01/2012 08:16 PM, Amador Pahim wrote:
>> On 06/01/2012 12:39 PM, Itamar Heim wrote:
>>> On 05/21/2012 09:37 PM, Gilad Chaplik wrote:
>>>> Hi Pahim,
>>>>
>>>> Thanks for the input!
>>>> Comments inline.
>>>>
>>>> Thanks,
>>>> Gilad.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Amador pahim"<apahim at redhat.com>
>>>>> To: engine-devel at ovirt.org
>>>>> Sent: Monday, May 21, 2012 5:52:34 PM
>>>>> Subject: [Engine-devel] LOCALFS path validation
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> I'm starting to know the engine code. I chose a little unstandardized
>>>>> behaviour to follow through the devel process. I have a patch and
>>>>> I'd like to know if you fell relevant to correct this issue:
>>>>>
>>>>> - Description: Adding a LOCAL storage [1], webadmin does not validate
>>>>> path against regex, sendind the invalid path (with final slash) to
>>>>> vdsm [2] [3]. But, adding a NFS storage, the path is validated
>>>>> before contacting vdsm [4] avoiding extra vdsm processing and
>>>>> quickly/clearly informing user about what's wrong.
>>>>>
>>>>> - Expected result: Same behaviour to NFS and LOCALFS storage path
>>>>> validation. Validate LOCALFS path in webadmin before send it to vdsm
>>>>> [5].
>>>>
>>>> you may and should send a patch :)
>>>>
>>>>>
>>>>> - Newbie doubt: Wouldn't be better to validate the both local and nfs
>>>>> path on the backend, achieving all user interfaces/APIs?
>>>>
>>>> Because we have a rich client app (gwt), we can perform the
>>>> validation also in the client side very easily,
>>>> we do that to avoid unnecessary calls to the backend side, and to
>>>> have a better& responsive ui
>>>> (client side validation is performed instantly - without the need to
>>>> wait).
>>>>
>>>> Anyway, every validation performed in the client side needs to be
>>>> performed also in backend side (for api, and other reasons 
>>>> (security?)).
>>>
>>> the client side can validate the format of the path, not if it really
>>> exists.
>>> do you mean local storage via the wizard, or just adding another
>>> storage domain?
>>> the 'configure local storage' wizard requires the host to be in
>>> maintenance, which may or may not be a problem to implement this type
>>> of validation.
>>
>> I mean just adding a LOCALFS storage domain with an invalid path, like
>> this:
>> https://picasaweb.google.com/lh/photo/FWNiou2Y12GZO3AjfCH6K7QAv8cs6edaj3fEcMleB60 
>>
>>
>> Currently we have this:
>> https://picasaweb.google.com/lh/photo/Pof6Z8ohgQAkRTDpEJKG-LQAv8cs6edaj3fEcMleB60 
>>
>>
>> I sent a patch...
>> http://gerrit.ovirt.org/4857
>> ... in order to do this:
>> https://picasaweb.google.com/lh/photo/PgzYrZHkkvm-WtFk_UFZLrQAv8cs6edaj3fEcMleB60 
>>
>>
>> Just like "New NFS Domain" currently does:
>> https://picasaweb.google.com/lh/photo/Fd3zWegWE0T5C2tDo_tPZrQAv8cs6edaj3fEcMleB60 
>>
>>
>
> ok - sounds basic enough of a change. I'd just note in the patch you 
> are re-using same REGEX used for the previous validation happening in 
> the backend (and actually try to re-use it, to not maintain a change 
> in too many places0
There is no validation in backend. I mean, the error "Error while 
executing action AddLocalStorageDomain: Remote path is illegal" is 
coming from VDSM:
https://gist.github.com/2762656
And is not caused by regex. VDSM is just comparing path /test/ with 
os.path.abspath(), /test:
https://gist.github.com/2867874
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120604/20f77306/attachment.html>

From iheim at redhat.com  Mon Jun  4 12:08:40 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 04 Jun 2012 15:08:40 +0300
Subject: [Engine-devel] LOCALFS path validation
In-Reply-To: <4FCCA0FA.9020002@redhat.com>
References: <ab65230d-5b3f-4ada-9530-b46aaef2b27b@zmail14.collab.prod.int.phx2.redhat.com>
	<4FC8E23C.8060901@redhat.com> <4FC8F8D0.5050702@redhat.com>
	<4FCB1A94.8080201@redhat.com> <4FCCA0FA.9020002@redhat.com>
Message-ID: <4FCCA548.3000609@redhat.com>

On 06/04/2012 02:50 PM, Amador Pahim wrote:
> On 06/03/2012 05:04 AM, Itamar Heim wrote:
>> On 06/01/2012 08:16 PM, Amador Pahim wrote:
>>> On 06/01/2012 12:39 PM, Itamar Heim wrote:
>>>> On 05/21/2012 09:37 PM, Gilad Chaplik wrote:
>>>>> Hi Pahim,
>>>>>
>>>>> Thanks for the input!
>>>>> Comments inline.
>>>>>
>>>>> Thanks,
>>>>> Gilad.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Amador pahim"<apahim at redhat.com>
>>>>>> To: engine-devel at ovirt.org
>>>>>> Sent: Monday, May 21, 2012 5:52:34 PM
>>>>>> Subject: [Engine-devel] LOCALFS path validation
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm starting to know the engine code. I chose a little unstandardized
>>>>>> behaviour to follow through the devel process. I have a patch and
>>>>>> I'd like to know if you fell relevant to correct this issue:
>>>>>>
>>>>>> - Description: Adding a LOCAL storage [1], webadmin does not validate
>>>>>> path against regex, sendind the invalid path (with final slash) to
>>>>>> vdsm [2] [3]. But, adding a NFS storage, the path is validated
>>>>>> before contacting vdsm [4] avoiding extra vdsm processing and
>>>>>> quickly/clearly informing user about what's wrong.
>>>>>>
>>>>>> - Expected result: Same behaviour to NFS and LOCALFS storage path
>>>>>> validation. Validate LOCALFS path in webadmin before send it to vdsm
>>>>>> [5].
>>>>>
>>>>> you may and should send a patch :)
>>>>>
>>>>>>
>>>>>> - Newbie doubt: Wouldn't be better to validate the both local and nfs
>>>>>> path on the backend, achieving all user interfaces/APIs?
>>>>>
>>>>> Because we have a rich client app (gwt), we can perform the
>>>>> validation also in the client side very easily,
>>>>> we do that to avoid unnecessary calls to the backend side, and to
>>>>> have a better& responsive ui
>>>>> (client side validation is performed instantly - without the need to
>>>>> wait).
>>>>>
>>>>> Anyway, every validation performed in the client side needs to be
>>>>> performed also in backend side (for api, and other reasons
>>>>> (security?)).
>>>>
>>>> the client side can validate the format of the path, not if it really
>>>> exists.
>>>> do you mean local storage via the wizard, or just adding another
>>>> storage domain?
>>>> the 'configure local storage' wizard requires the host to be in
>>>> maintenance, which may or may not be a problem to implement this type
>>>> of validation.
>>>
>>> I mean just adding a LOCALFS storage domain with an invalid path, like
>>> this:
>>> https://picasaweb.google.com/lh/photo/FWNiou2Y12GZO3AjfCH6K7QAv8cs6edaj3fEcMleB60
>>>
>>>
>>> Currently we have this:
>>> https://picasaweb.google.com/lh/photo/Pof6Z8ohgQAkRTDpEJKG-LQAv8cs6edaj3fEcMleB60
>>>
>>>
>>> I sent a patch...
>>> http://gerrit.ovirt.org/4857
>>> ... in order to do this:
>>> https://picasaweb.google.com/lh/photo/PgzYrZHkkvm-WtFk_UFZLrQAv8cs6edaj3fEcMleB60
>>>
>>>
>>> Just like "New NFS Domain" currently does:
>>> https://picasaweb.google.com/lh/photo/Fd3zWegWE0T5C2tDo_tPZrQAv8cs6edaj3fEcMleB60
>>>
>>>
>>
>> ok - sounds basic enough of a change. I'd just note in the patch you
>> are re-using same REGEX used for the previous validation happening in
>> the backend (and actually try to re-use it, to not maintain a change
>> in too many places0
> There is no validation in backend. I mean, the error "Error while
> executing action AddLocalStorageDomain: Remote path is illegal" is
> coming from VDSM:
> https://gist.github.com/2762656
> And is not caused by regex. VDSM is just comparing path /test/ with
> os.path.abspath(), /test:
> https://gist.github.com/2867874

sounds like a valid validation to add then


From iheim at redhat.com  Mon Jun  4 15:00:38 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 04 Jun 2012 18:00:38 +0300
Subject: [Engine-devel] Change in ovirt-engine[master]: restapi: non
 admin user api - Filtering user queries (#78308...
In-Reply-To: <201206041424.q54EOE8n027372@gerrit.ovirt.org>
References: <gerrit.1336906255772.I8e5e23cbb8e883f6005f69be46fa528ac6e7518c@gerrit.ovirt.org>
	<201206041424.q54EOE8n027372@gerrit.ovirt.org>
Message-ID: <4FCCCD96.8020005@redhat.com>

please send a status of what works, what not, and gaps to close.
thanks

On 06/04/2012 05:24 PM, asaf at redhat.com wrote:
> Asaf Shakarchi has submitted this change and it was merged.
>
> Change subject: restapi: non admin user api - Filtering user queries (#783087)
> ......................................................................
>
>
> restapi: non admin user api - Filtering user queries (#783087)
>
> https://bugzilla.redhat.com/783087
>
> - A global support for filtering content based on user permissions for all
>    query executions based on the 'filter' HTTP header.
>    Note: The 'filter' attribute header is stateless and must be specified by the client per HTTP request.
>
> - Added a unit test for BackendResourceTest currently for testing the 'filter' HTTP header.
>
> - Abstracted base test class from resource centric base test class
>
> - Changed TestHelper.getMethod to seek for 'isMethod()' if 'getMethod()' wasn't found.
>
> Change-Id: I8e5e23cbb8e883f6005f69be46fa528ac6e7518c
> Signed-off-by: Asaf Shakarchi<asaf at redhat.com>
> ---
> M backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/BackendResource.java
> M backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/BaseBackendResource.java
> A backend/manager/modules/restapi/jaxrs/src/test/java/org/ovirt/engine/api/restapi/resource/AbstractBackendBaseTest.java
> M backend/manager/modules/restapi/jaxrs/src/test/java/org/ovirt/engine/api/restapi/resource/AbstractBackendResourceTest.java
> M backend/manager/modules/restapi/jaxrs/src/test/java/org/ovirt/engine/api/restapi/resource/BackendApiResourceTest.java
> A backend/manager/modules/restapi/jaxrs/src/test/java/org/ovirt/engine/api/restapi/resource/BackendResourceTest.java
> M backend/manager/modules/restapi/jaxrs/src/test/java/org/ovirt/engine/api/restapi/resource/BackendVmResourceTest.java
> 7 files changed, 490 insertions(+), 387 deletions(-)
>
> Approvals:
>    Asaf Shakarchi: Verified; Looks good to me, approved
>
>
> --
> To view, visit http://gerrit.ovirt.org/4360
> To unsubscribe, visit http://gerrit.ovirt.org/settings
>
> Gerrit-MessageType: merged
> Gerrit-Change-Id: I8e5e23cbb8e883f6005f69be46fa528ac6e7518c
> Gerrit-PatchSet: 9
> Gerrit-Project: ovirt-engine
> Gerrit-Branch: master
> Gerrit-Owner: Asaf Shakarchi<asaf at redhat.com>
> Gerrit-Reviewer: Asaf Shakarchi<asaf at redhat.com>
> Gerrit-Reviewer: Michael Pasternak<mpastern at redhat.com>
> Gerrit-Reviewer: Ori Liel<oliel at redhat.com>
> _______________________________________________
> Engine-commits mailing list
> Engine-commits at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-commits



From abaron at redhat.com  Tue Jun  5 12:03:17 2012
From: abaron at redhat.com (Ayal Baron)
Date: Tue, 05 Jun 2012 08:03:17 -0400 (EDT)
Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup
In-Reply-To: <4FC8E327.6010702@redhat.com>
Message-ID: <705440a2-c1ad-45af-bedb-c05e746e4332@zmail13.collab.prod.int.phx2.redhat.com>

> -------- Original Message --------
> Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup
> Date: Mon, 21 May 2012 06:34:32 -0400 (EDT)
> From: Einav Cohen <ecohen at redhat.com>
> To: Ayal Baron <abaron at redhat.com>, Eldan Hildesheim
> <ehildesh at redhat.com>,        Eldan Hildesheim <info at eldanet.com>,
>    Miki Kenneth <mkenneth at redhat.com>,        Andrew Cathrow
> <acathrow at redhat.com>,        Simon Grinberg <sgrinber at redhat.com>,
> Alexey Chub <achub at redhat.com>
> CC: engine-devel at ovirt.org
> 
> Please review the mock-up on the feature page:
> http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience

Sorry, I just saw this.
The advanced features should be in an advanced tab (not easily accessible) in general I'd like to discourage users from changing these params.
not sure what mount options is as it is not supported for NFS.

> 
> Comments are welcome.
> 
> ----
> Thanks,
> Einav
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From jhernand at redhat.com  Tue Jun  5 12:53:08 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 05 Jun 2012 14:53:08 +0200
Subject: [Engine-devel] Improve classpath building
Message-ID: <4FCE0134.1040408@redhat.com>

Hello all,

I would like to propose an improvement in the way we build class-paths 
in the tools associated to the engine. At the moment we have at least 
two different ways to build classpaths:

1. Hard coded in the scripts, with maybe some variables:

CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...

This depends a lot on where we place the jar files, and we need to place 
them in different places in different environments if we want to adhere 
to common packaging practices.

2. Use the build-classpath script:

CP=`build-classpath engine-encryptutils engine-compat ...`

This depends less on the place we put them, but it doesn't work in 
development environments where some jars are not installed to the proper 
system locations.

None of these is good for all environments.

I would like to replace this classpath building logic with an script 
that performs the task in an smarter way and that works in all our 
environments (production, development, Fedora, RHEL, etc).

My proposal is to create a "engine-java" script that we should use 
always when invoking java programs. This script will receive the same 
parameters that the "java" launcher receives, but the "-cp" or 
"-classpath" options will contain not the absolute name of the jar 
files, but just a simple jar name instead, something like 
"commons-logging", "commons-codec" or "engineencryptutils". The script 
will extract the "-cp" or "-classpath" options given and use them to do 
a search of the jar files in the locations where they can be in 
different environments:

/usr/share/java
/usr/share/java/ovirt-engine
/usr/share/ovirt-engine/engine.ear
/usr/share/ovirt-engine/engine.ear/lib
<your jboss development installation>/engine.ear
<your jboss development installation>/engine.ear/lib

In addition the script will check that all the give jar files exist and 
will abort the execution if any of them is missing.

Find attached the initial version of the proposed script.

Let me know what you think.

Regards,
Juan Hernandez

-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.
-------------- next part --------------
#!/usr/bin/python

# Copyright 2012 Red Hat
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

import logging
import lxml.etree
import os
import traceback
import sys

# Flag to activate debug output (it is activated when the -d or
# -debug command line options are provided):
debugEnabled = False

# In some environments there are several versions of some of the
# most used jar files, so it is good to be explicit and state them
# here:
preferredJars = {

    # In RHEL we prefer to use the commons-codec jar file provided
    # by EAP6, as the version provided by the base operating
    # system is missing some methods that we need:
    "commons-codec": "/usr/share/java/commons-codec-eap6/commons-codec.jar",

    # XXX: I expect this dictionary to grow ...
}

def getSettingsProperty(propertyName, settingsFile):
    # Create the namespace map used when parsing settings files:
    nsmap = {
        "p": "http://maven.apache.org/POM/4.0.0",
    }

    # Parse the settings file:
    settingsDoc = lxml.etree.parse(settingsFile)

    # Get the list of active profile names:
    activeProfilesPath = (
        "/p:settings"
        "/p:activeProfiles"
        "/p:activeProfile"
        "/text()"
    )
    activeProfiles = settingsDoc.xpath(activeProfilesPath, namespaces=nsmap)

    # Try to find the value of the property in each of the active
    # profiles:
    for activeProfile in activeProfiles:
        propertyValuePath = (
            "/p:settings"
            "/p:profiles"
            "/p:profile[p:id/text()='" + activeProfile + "']"
            "/p:properties"
            "/p:" + propertyName + ""
            "/text()"
        )
        propertyValues = settingsDoc.xpath(propertyValuePath, namespaces=nsmap)
        if propertyValues:
            return propertyValues[0]

    # No luck:
    return None

def getProperty(propertyName):
    # First try with the user specific settings file, if it
    # exists:
    homeDir = os.getenv("HOME")
    if homeDir:
        settingsFile = os.path.join(homeDir, ".m2/settings.xml")
        if os.path.exists(settingsFile):
            propertyValue = getSettingsProperty(propertyName, settingsFile)
            if propertyValue:
                return propertyValue

    # Then try with the global setttings file, if it exists:
    settingsFile = "/etc/maven/settings.xml"
    if os.path.exists(settingsFile):
        propertyValue = getSettingsProperty(propertyName, settingsFile)
        if propertyValue:
            return propertyValue

    # No luck:
    return None

def resolveJar(jarName, searchPath):
    # Don't try to search the jar if it is given as an absolute
    # path, as this means that the application wants to use that
    # particular file (or maybe the application is broken):
    if os.path.isabs(jarName):
        if os.path.exists(jarName):
            return jarName
        else:
            return None

    # If we have a preferred jar for this name then try it before
    # anything else:
    preferredJar = preferredJars.get(jarName)
    if preferredJar and os.path.exists(preferredJar):
        logging.debug("Jar \"%s\" has been replaced by preferred jar \"%s\"." % (jarName, preferredJar))
        return preferredJar

    # Add the jar extension to the name if it has not been
    # provided:
    if not jarName.endswith(".jar"):
        jarName = jarName + ".jar"

    # Try to find the jar file in each of the jar directories, in
    # the order they are specified in the search path:
    for jarDirectory in searchPath:
        jarFile = os.path.join(jarDirectory, jarName)
        if os.path.exists(jarFile):
            logging.debug("Jar \"%s\" has been resolved as \"%s\"." % (jarName, jarFile))
            return jarFile

    # No luck:
    return None

def main():
    # Configure logging:
    logHandler = logging.StreamHandler(sys.stdout)
    logHandler.setLevel(logging.INFO)
    logFormatter = logging.Formatter('%(message)s')
    logHandler.setFormatter(logFormatter) 
    logging.root.addHandler(logHandler)
    logging.root.setLevel(logging.DEBUG)

    # Initially the classpath is empty:
    unresolvedJars = []

    # Parse the command line looking for the classpath options,
    # and for each of them remove it from the list of arguments
    # and add its content to the list of unresolved jar files:
    args = []
    index = 1
    while index < len(sys.argv):
        arg = sys.argv[index]
        if arg in ["-d", "-debug"]:
            logHandler.setLevel(logging.DEBUG)
        elif arg in ["-cp", "-classpath"]:
            index += 1
            if index < len(sys.argv):
                arg = sys.argv[index]
                unresolvedJars.extend(arg.split(":"))
        else:
            args.append(arg)
        index += 1

    # Build the search path for jar files that will be later used
    # to resolve them:
    searchPath = []

    # Add the system wide jars directory to the search path:
    systemJars = "/usr/share/java"
    if os.path.exists(systemJars):
        searchPath.append(systemJars)

    # Add the engine jars directory to the search path:
    engineJars = os.path.join(systemJars, "ovirt-engine")
    if os.path.exists(engineJars):
        searchPath.append(engineJars)

    # Add the ear and lib directory of the deployed engine to the
    # search path:
    engineEar = "/usr/share/ovirt-engine/engine.ear"
    if os.path.exists(engineEar):
        searchPath.append(engineEar)
        engineLib = os.path.join(engineEar, "lib")
        if os.path.exists(engineLib):
            searchPath.append(engineLib)

    # Try to find the application server installation used in
    # development environments and add the lib directory of the
    # deployed engine to the jar path:
    jbossHome = getProperty("jbossHome")
    if jbossHome:
        logging.debug("Application server home is \"%s\"." % jbossHome)
        engineEar = os.path.join(jbossHome, "standalone/deployments/engine.ear")
        if os.path.exists(engineEar):
            searchPath.append(engineEar)
            engineLib = os.path.join(engineEar, "lib")
            if os.path.exists(engineLib):
                searchPath.append(engineLib)

    # Try to find the actual path for each unresolved jar:
    resolvedJars = []
    missingJars = []
    for unresolvedJar in unresolvedJars:
        resolvedJar = resolveJar(unresolvedJar, searchPath)
        if resolvedJar:
            resolvedJars.append(resolvedJar)
        else:
            missingJars.append(unresolvedJar)

    # Don't proceed if there are unresolved paths:
    if missingJars:
        for missingJar in missingJars:
            sys.stderr.write("Can't find the actual location of jar \"%s\".\n" % missingJar)
        sys.exit(1)
    
    # Compute the class path used to invoke the java virtual
    # machine:
    classPath = ":".join(resolvedJars)
    logging.debug("Class path is \"%s\"." % classPath)

    # Execute tha java virtual machine with the given classpath
    # and arguments:
    javaArgs = ["java", "-classpath", classPath]
    javaArgs.extend(args)
    logging.debug("Running command \"%s\"." % " ".join(javaArgs))
    os.execvp("java", javaArgs)


if __name__ == "__main__":
    try:
        main()
    except SystemExit:
        raise
    except BaseException as exception:
        sys.stderr.write("%s\n" % traceback.format_exc())
        sys.exit(1)

From ovedo at redhat.com  Tue Jun  5 13:03:08 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Tue, 05 Jun 2012 09:03:08 -0400 (EDT)
Subject: [Engine-devel] Improve classpath building
In-Reply-To: <4FCE0134.1040408@redhat.com>
Message-ID: <90acdba9-e2cb-4953-8273-13c76f945ffb@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, June 5, 2012 3:53:08 PM
> Subject: [Engine-devel] Improve classpath building
> 
> Hello all,
> 
> I would like to propose an improvement in the way we build
> class-paths
> in the tools associated to the engine. At the moment we have at least
> two different ways to build classpaths:
> 
> 1. Hard coded in the scripts, with maybe some variables:
> 
> CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
> 
> This depends a lot on where we place the jar files, and we need to
> place
> them in different places in different environments if we want to
> adhere
> to common packaging practices.
> 
> 2. Use the build-classpath script:
> 
> CP=`build-classpath engine-encryptutils engine-compat ...`
> 
> This depends less on the place we put them, but it doesn't work in
> development environments where some jars are not installed to the
> proper
> system locations.
> 
> None of these is good for all environments.
> 
> I would like to replace this classpath building logic with an script
> that performs the task in an smarter way and that works in all our
> environments (production, development, Fedora, RHEL, etc).
> 

In general it looks like a very good idea.
Running the utilities in a development environment today is a real pain, so such a change will save a lot of time both when setting the development environment, and when testing changes. 

Didn't review all the whole source code, but from a quick glance I saw the preferredJars dictionary. 
IMO it is better to put this configuration in a configuration file, instead of a dictionary.
Also, I would allow to change the path to this file, to allow developers to create a custom file (if they need one).

> My proposal is to create a "engine-java" script that we should use
> always when invoking java programs. This script will receive the same
> parameters that the "java" launcher receives, but the "-cp" or
> "-classpath" options will contain not the absolute name of the jar
> files, but just a simple jar name instead, something like
> "commons-logging", "commons-codec" or "engineencryptutils". The
> script
> will extract the "-cp" or "-classpath" options given and use them to
> do
> a search of the jar files in the locations where they can be in
> different environments:
> 
> /usr/share/java
> /usr/share/java/ovirt-engine
> /usr/share/ovirt-engine/engine.ear
> /usr/share/ovirt-engine/engine.ear/lib
> <your jboss development installation>/engine.ear
> <your jboss development installation>/engine.ear/lib
> 
> In addition the script will check that all the give jar files exist
> and
> will abort the execution if any of them is missing.
> 
> Find attached the initial version of the proposed script.
> 
> Let me know what you think.
> 
> Regards,
> Juan Hernandez
> 
> --
> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3?D, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
> S.L.
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From kroberts at redhat.com  Tue Jun  5 13:06:45 2012
From: kroberts at redhat.com (Keith Robertson)
Date: Tue, 05 Jun 2012 09:06:45 -0400
Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup
In-Reply-To: <705440a2-c1ad-45af-bedb-c05e746e4332@zmail13.collab.prod.int.phx2.redhat.com>
References: <705440a2-c1ad-45af-bedb-c05e746e4332@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4FCE0465.4040506@redhat.com>

On 06/05/2012 08:03 AM, Ayal Baron wrote:
>> -------- Original Message --------
>> Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup
>> Date: Mon, 21 May 2012 06:34:32 -0400 (EDT)
>> From: Einav Cohen<ecohen at redhat.com>
>> To: Ayal Baron<abaron at redhat.com>, Eldan Hildesheim
>> <ehildesh at redhat.com>,        Eldan Hildesheim<info at eldanet.com>,
>>     Miki Kenneth<mkenneth at redhat.com>,        Andrew Cathrow
>> <acathrow at redhat.com>,        Simon Grinberg<sgrinber at redhat.com>,
>> Alexey Chub<achub at redhat.com>
>> CC: engine-devel at ovirt.org
>>
>> Please review the mock-up on the feature page:
>> http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience
> Sorry, I just saw this.
> The advanced features should be in an advanced tab (not easily accessible) in general I'd like to discourage users from changing these params.
I agree with this.  Have an "Advanced Options" button or something that 
will display these options.  Default state should be hidden.  It could 
get really ugly if the user starts mucking around with options like (r, 
hard, and sync).

The reason I say this is that the default settings for NFS should be 
sufficient in the majority of cases.  Further, you would think that the 
NFS maintainers carefully selected and tested the default option set for 
a variety of scenarios, I'd be hesitant to make it easy to override them 
unless there is a ground swell of NFS problems.

Most of the NFS problems that I've seen are related to server-side 
permissions and cannot be resolved by the client.
> not sure what mount options is as it is not supported for NFS.
>
>> Comments are welcome.
>>
>> ----
>> Thanks,
>> Einav
>> _______________________________________________
>> 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 Jun  5 14:41:24 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 05 Jun 2012 17:41:24 +0300
Subject: [Engine-devel] Improve classpath building
In-Reply-To: <4FCE0134.1040408@redhat.com>
References: <4FCE0134.1040408@redhat.com>
Message-ID: <4FCE1A94.6030206@redhat.com>

On 06/05/2012 03:53 PM, Juan Hernandez wrote:
> Hello all,
> 
> I would like to propose an improvement in the way we build class-paths
> in the tools associated to the engine. At the moment we have at least
> two different ways to build classpaths:
> 
> 1. Hard coded in the scripts, with maybe some variables:
> 
> CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
> 
> This depends a lot on where we place the jar files, and we need to place
> them in different places in different environments if we want to adhere
> to common packaging practices.
> 
> 2. Use the build-classpath script:
> 
> CP=`build-classpath engine-encryptutils engine-compat ...`
> 
> This depends less on the place we put them, but it doesn't work in
> development environments where some jars are not installed to the proper
> system locations.
> 
> None of these is good for all environments.
> 
> I would like to replace this classpath building logic with an script
> that performs the task in an smarter way and that works in all our
> environments (production, development, Fedora, RHEL, etc).
> 
> My proposal is to create a "engine-java" script that we should use
> always when invoking java programs. This script will receive the same
> parameters that the "java" launcher receives, but the "-cp" or
> "-classpath" options will contain not the absolute name of the jar
> files, but just a simple jar name instead, something like
> "commons-logging", "commons-codec" or "engineencryptutils". The script
> will extract the "-cp" or "-classpath" options given and use them to do
> a search of the jar files in the locations where they can be in
> different environments:
> 
> /usr/share/java
> /usr/share/java/ovirt-engine
> /usr/share/ovirt-engine/engine.ear
> /usr/share/ovirt-engine/engine.ear/lib
> <your jboss development installation>/engine.ear
> <your jboss development installation>/engine.ear/lib
> 
> In addition the script will check that all the give jar files exist and
> will abort the execution if any of them is missing.
> 
> Find attached the initial version of the proposed script.
> 
> Let me know what you think.

Excellent idea!
I would like to add -
I already saw the work you did on engine-manage-domains.
When we work on development machines, we might have the jars reside in
different places.
I wanted to create a script that will allow for example to use
build-classpath on spring-ldap-core, but I did not have a soft link for
that in /usr/share/java (is that what I needed to do?)
I guess we will have to differentiate between the need of dev and
production for this script.



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



From jhernand at redhat.com  Tue Jun  5 15:04:25 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 05 Jun 2012 17:04:25 +0200
Subject: [Engine-devel] Improve classpath building
In-Reply-To: <4FCE1A94.6030206@redhat.com>
References: <4FCE0134.1040408@redhat.com> <4FCE1A94.6030206@redhat.com>
Message-ID: <4FCE1FF9.3070701@redhat.com>

On 06/05/2012 04:41 PM, Yair Zaslavsky wrote:
> On 06/05/2012 03:53 PM, Juan Hernandez wrote:
>> Hello all,
>>
>> I would like to propose an improvement in the way we build class-paths
>> in the tools associated to the engine. At the moment we have at least
>> two different ways to build classpaths:
>>
>> 1. Hard coded in the scripts, with maybe some variables:
>>
>> CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
>>
>> This depends a lot on where we place the jar files, and we need to place
>> them in different places in different environments if we want to adhere
>> to common packaging practices.
>>
>> 2. Use the build-classpath script:
>>
>> CP=`build-classpath engine-encryptutils engine-compat ...`
>>
>> This depends less on the place we put them, but it doesn't work in
>> development environments where some jars are not installed to the proper
>> system locations.
>>
>> None of these is good for all environments.
>>
>> I would like to replace this classpath building logic with an script
>> that performs the task in an smarter way and that works in all our
>> environments (production, development, Fedora, RHEL, etc).
>>
>> My proposal is to create a "engine-java" script that we should use
>> always when invoking java programs. This script will receive the same
>> parameters that the "java" launcher receives, but the "-cp" or
>> "-classpath" options will contain not the absolute name of the jar
>> files, but just a simple jar name instead, something like
>> "commons-logging", "commons-codec" or "engineencryptutils". The script
>> will extract the "-cp" or "-classpath" options given and use them to do
>> a search of the jar files in the locations where they can be in
>> different environments:
>>
>> /usr/share/java
>> /usr/share/java/ovirt-engine
>> /usr/share/ovirt-engine/engine.ear
>> /usr/share/ovirt-engine/engine.ear/lib
>> <your jboss development installation>/engine.ear
>> <your jboss development installation>/engine.ear/lib
>>
>> In addition the script will check that all the give jar files exist and
>> will abort the execution if any of them is missing.
>>
>> Find attached the initial version of the proposed script.
>>
>> Let me know what you think.
>
> Excellent idea!
> I would like to add -
> I already saw the work you did on engine-manage-domains.
> When we work on development machines, we might have the jars reside in
> different places.

Yes, this is one of the motivations for this new engine-java script, the 
fact that we can't expect the build-classpath script to work in all 
environments, specially development environments.

> I wanted to create a script that will allow for example to use
> build-classpath on spring-ldap-core, but I did not have a soft link for
> that in /usr/share/java (is that what I needed to do?)

Yes, just create the link in /usr/share/java and it should work. If you 
want to keep it compatible with the Fedora spring-ldap package create it 
as "/usr/share/java/spring-ldap/spring-ldap-core.jar", then you should 
be able to use it with "build-classpath spring-ldap/spring-ldap-core".

> I guess we will have to differentiate between the need of dev and
> production for this script.

I would rather try to make it work in all the environments without 
change, but I know that is quite difficult.

-- 
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 yzaslavs at redhat.com  Tue Jun  5 15:12:00 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Tue, 05 Jun 2012 18:12:00 +0300
Subject: [Engine-devel] Improve classpath building
In-Reply-To: <4FCE1FF9.3070701@redhat.com>
References: <4FCE0134.1040408@redhat.com> <4FCE1A94.6030206@redhat.com>
	<4FCE1FF9.3070701@redhat.com>
Message-ID: <4FCE21C0.1030506@redhat.com>

On 06/05/2012 06:04 PM, Juan Hernandez wrote:
> On 06/05/2012 04:41 PM, Yair Zaslavsky wrote:
>> On 06/05/2012 03:53 PM, Juan Hernandez wrote:
>>> Hello all,
>>>
>>> I would like to propose an improvement in the way we build class-paths
>>> in the tools associated to the engine. At the moment we have at least
>>> two different ways to build classpaths:
>>>
>>> 1. Hard coded in the scripts, with maybe some variables:
>>>
>>> CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
>>>
>>> This depends a lot on where we place the jar files, and we need to place
>>> them in different places in different environments if we want to adhere
>>> to common packaging practices.
>>>
>>> 2. Use the build-classpath script:
>>>
>>> CP=`build-classpath engine-encryptutils engine-compat ...`
>>>
>>> This depends less on the place we put them, but it doesn't work in
>>> development environments where some jars are not installed to the proper
>>> system locations.
>>>
>>> None of these is good for all environments.
>>>
>>> I would like to replace this classpath building logic with an script
>>> that performs the task in an smarter way and that works in all our
>>> environments (production, development, Fedora, RHEL, etc).
>>>
>>> My proposal is to create a "engine-java" script that we should use
>>> always when invoking java programs. This script will receive the same
>>> parameters that the "java" launcher receives, but the "-cp" or
>>> "-classpath" options will contain not the absolute name of the jar
>>> files, but just a simple jar name instead, something like
>>> "commons-logging", "commons-codec" or "engineencryptutils". The script
>>> will extract the "-cp" or "-classpath" options given and use them to do
>>> a search of the jar files in the locations where they can be in
>>> different environments:
>>>
>>> /usr/share/java
>>> /usr/share/java/ovirt-engine
>>> /usr/share/ovirt-engine/engine.ear
>>> /usr/share/ovirt-engine/engine.ear/lib
>>> <your jboss development installation>/engine.ear
>>> <your jboss development installation>/engine.ear/lib
>>>
>>> In addition the script will check that all the give jar files exist and
>>> will abort the execution if any of them is missing.
>>>
>>> Find attached the initial version of the proposed script.
>>>
>>> Let me know what you think.
>>
>> Excellent idea!
>> I would like to add -
>> I already saw the work you did on engine-manage-domains.
>> When we work on development machines, we might have the jars reside in
>> different places.
> 
> Yes, this is one of the motivations for this new engine-java script, the
> fact that we can't expect the build-classpath script to work in all
> environments, specially development environments.
> 
>> I wanted to create a script that will allow for example to use
>> build-classpath on spring-ldap-core, but I did not have a soft link for
>> that in /usr/share/java (is that what I needed to do?)
> 
> Yes, just create the link in /usr/share/java and it should work. If you
> want to keep it compatible with the Fedora spring-ldap package create it
> as "/usr/share/java/spring-ldap/spring-ldap-core.jar", then you should
> be able to use it with "build-classpath spring-ldap/spring-ldap-core".
> 
>> I guess we will have to differentiate between the need of dev and
>> production for this script.
> 
> I would rather try to make it work in all the environments without
> change, but I know that is quite difficult.
> 
Juan - and still, I feel this will be a great improvement.
Maybe what should be done is have, for example a script called -
engine-manage-domains-devel - this script will run  "engine-java-devel"
which will create the needed soft-links for developers, and then will
run engine-manage-domains.   Engine-manage-domains will run engine-java.
Engine-java will check if the soft links already exist, and if they
exist - will not create them.
Maybe this way we can utilize engine-manage-domains-devel to use
engine-manage-domains with minimal changes.


From jhernand at redhat.com  Tue Jun  5 15:23:52 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Tue, 05 Jun 2012 17:23:52 +0200
Subject: [Engine-devel] Improve classpath building
In-Reply-To: <90acdba9-e2cb-4953-8273-13c76f945ffb@zmail02.collab.prod.int.phx2.redhat.com>
References: <90acdba9-e2cb-4953-8273-13c76f945ffb@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4FCE2488.1050607@redhat.com>

On 06/05/2012 03:03 PM, Oved Ourfalli wrote:
>
>
> ----- Original Message -----
>> From: "Juan Hernandez"<jhernand at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, June 5, 2012 3:53:08 PM
>> Subject: [Engine-devel] Improve classpath building
>>
>> Hello all,
>>
>> I would like to propose an improvement in the way we build
>> class-paths
>> in the tools associated to the engine. At the moment we have at least
>> two different ways to build classpaths:
>>
>> 1. Hard coded in the scripts, with maybe some variables:
>>
>> CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
>>
>> This depends a lot on where we place the jar files, and we need to
>> place
>> them in different places in different environments if we want to
>> adhere
>> to common packaging practices.
>>
>> 2. Use the build-classpath script:
>>
>> CP=`build-classpath engine-encryptutils engine-compat ...`
>>
>> This depends less on the place we put them, but it doesn't work in
>> development environments where some jars are not installed to the
>> proper
>> system locations.
>>
>> None of these is good for all environments.
>>
>> I would like to replace this classpath building logic with an script
>> that performs the task in an smarter way and that works in all our
>> environments (production, development, Fedora, RHEL, etc).
>>
>
> In general it looks like a very good idea.
> Running the utilities in a development environment today is a real pain, so such a change will save a lot of time both when setting the development environment, and when testing changes.
>
> Didn't review all the whole source code, but from a quick glance I saw the preferredJars dictionary.
> IMO it is better to put this configuration in a configuration file, instead of a dictionary.
> Also, I would allow to change the path to this file, to allow developers to create a custom file (if they need one).

The idea of using a configuration file is nice, but I would make it 
completely optional, and would try to make every effort (almost) to make 
the script work without need for additional configuration.

>> My proposal is to create a "engine-java" script that we should use
>> always when invoking java programs. This script will receive the same
>> parameters that the "java" launcher receives, but the "-cp" or
>> "-classpath" options will contain not the absolute name of the jar
>> files, but just a simple jar name instead, something like
>> "commons-logging", "commons-codec" or "engineencryptutils". The
>> script
>> will extract the "-cp" or "-classpath" options given and use them to
>> do
>> a search of the jar files in the locations where they can be in
>> different environments:
>>
>> /usr/share/java
>> /usr/share/java/ovirt-engine
>> /usr/share/ovirt-engine/engine.ear
>> /usr/share/ovirt-engine/engine.ear/lib
>> <your jboss development installation>/engine.ear
>> <your jboss development installation>/engine.ear/lib
>>
>> In addition the script will check that all the give jar files exist
>> and
>> will abort the execution if any of them is missing.
>>
>> Find attached the initial version of the proposed script.
>>
>> Let me know what you think.
>>
>> Regards,
>> Juan Hernandez
>>
>> --
>> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
>> 3?D, 28016 Madrid, Spain
>> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat
>> S.L.
>>
>> _______________________________________________
>> 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


-- 
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 ovedo at redhat.com  Tue Jun  5 15:28:44 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Tue, 05 Jun 2012 11:28:44 -0400 (EDT)
Subject: [Engine-devel] Improve classpath building
In-Reply-To: <4FCE2488.1050607@redhat.com>
Message-ID: <f0d1e57f-2a70-4a54-af9d-9af6bc8ce97f@zmail02.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Juan Hernandez" <jhernand at redhat.com>
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, June 5, 2012 6:23:52 PM
> Subject: Re: [Engine-devel] Improve classpath building
> 
> On 06/05/2012 03:03 PM, Oved Ourfalli wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Juan Hernandez"<jhernand at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Tuesday, June 5, 2012 3:53:08 PM
> >> Subject: [Engine-devel] Improve classpath building
> >>
> >> Hello all,
> >>
> >> I would like to propose an improvement in the way we build
> >> class-paths
> >> in the tools associated to the engine. At the moment we have at
> >> least
> >> two different ways to build classpaths:
> >>
> >> 1. Hard coded in the scripts, with maybe some variables:
> >>
> >> CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
> >>
> >> This depends a lot on where we place the jar files, and we need to
> >> place
> >> them in different places in different environments if we want to
> >> adhere
> >> to common packaging practices.
> >>
> >> 2. Use the build-classpath script:
> >>
> >> CP=`build-classpath engine-encryptutils engine-compat ...`
> >>
> >> This depends less on the place we put them, but it doesn't work in
> >> development environments where some jars are not installed to the
> >> proper
> >> system locations.
> >>
> >> None of these is good for all environments.
> >>
> >> I would like to replace this classpath building logic with an
> >> script
> >> that performs the task in an smarter way and that works in all our
> >> environments (production, development, Fedora, RHEL, etc).
> >>
> >
> > In general it looks like a very good idea.
> > Running the utilities in a development environment today is a real
> > pain, so such a change will save a lot of time both when setting
> > the development environment, and when testing changes.
> >
> > Didn't review all the whole source code, but from a quick glance I
> > saw the preferredJars dictionary.
> > IMO it is better to put this configuration in a configuration file,
> > instead of a dictionary.
> > Also, I would allow to change the path to this file, to allow
> > developers to create a custom file (if they need one).
> 
> The idea of using a configuration file is nice, but I would make it
> completely optional, and would try to make every effort (almost) to
> make
> the script work without need for additional configuration.
> 
good enough :-)

> >> My proposal is to create a "engine-java" script that we should use
> >> always when invoking java programs. This script will receive the
> >> same
> >> parameters that the "java" launcher receives, but the "-cp" or
> >> "-classpath" options will contain not the absolute name of the jar
> >> files, but just a simple jar name instead, something like
> >> "commons-logging", "commons-codec" or "engineencryptutils". The
> >> script
> >> will extract the "-cp" or "-classpath" options given and use them
> >> to
> >> do
> >> a search of the jar files in the locations where they can be in
> >> different environments:
> >>
> >> /usr/share/java
> >> /usr/share/java/ovirt-engine
> >> /usr/share/ovirt-engine/engine.ear
> >> /usr/share/ovirt-engine/engine.ear/lib
> >> <your jboss development installation>/engine.ear
> >> <your jboss development installation>/engine.ear/lib
> >>
> >> In addition the script will check that all the give jar files
> >> exist
> >> and
> >> will abort the execution if any of them is missing.
> >>
> >> Find attached the initial version of the proposed script.
> >>
> >> Let me know what you think.
> >>
> >> Regards,
> >> Juan Hernandez
> >>
> >> --
> >> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3,
> >> planta
> >> 3?D, 28016 Madrid, Spain
> >> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red
> >> Hat
> >> S.L.
> >>
> >> _______________________________________________
> >> 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
> 
> 
> --
> 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.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From shuming at linux.vnet.ibm.com  Tue Jun  5 16:32:51 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Wed, 06 Jun 2012 00:32:51 +0800
Subject: [Engine-devel] engine complained that it couldn't find the
 ovirtmgmt interface in my FC16 ovirt node
Message-ID: <4FCE34B3.9040309@linux.vnet.ibm.com>

Hi,

I found  the followings logs in my engine and engine set the node to 
non-operation state.   It is strange that I can see the ovirtmgmt 
network interface was there in the ovirt node.  Below are the logs and 
steps I did in ovirt node.  It seems that engine didn't get the right 
network interface information from ovirt node.  Can any one show me some 
steps to debug this problem?


In my engine log:

2012-06-06 00:45:00,185 INFO  
[org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] 
(QuartzScheduler_Worker-68) [897fad0] START, 
SetVdsStatusVDSCommand(vdsId = 848bcff0-ae2a-11e1-bb49-5254001498c4, 
status=NonOperational, nonOperationalReason=NETWORK_UNREACHABLE), log 
id: 53d27ec8
2012-06-06 00:45:00,188 INFO  
[org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] 
(QuartzScheduler_Worker-68) [897fad0] FINISH, SetVdsStatusVDSCommand, 
log id: 53d27ec8
2012-06-06 00:45:00,190 INFO  
[org.ovirt.engine.core.bll.SetNonOperationalVdsCommand] 
(QuartzScheduler_Worker-68) [897fad0] Host ovirt-node1 is set to 
Non-Operational, it is missing the following networks: ovirtmgmt,
2012-06-06 00:45:00,198 INFO  
[org.ovirt.engine.core.bll.HandleVdsCpuFlagsOrClusterChangedCommand] 
(QuartzScheduler_Worker-68) [60291e0d] Running command: 
HandleVdsCpuFlagsOrClusterChangedCommand internal: true. Entities 
affected :  ID: 848bcff0-ae2a-11e1-bb49-5254001498c4 Type: VDS

However in my ovirt node,  the ovirtmgmt interface was there.

[root at ovirt-node1 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
ovirtmgmt               8000.5cf3fce432a0       no              eth0
[root at ovirt-node1 ~]#

[root at ovirt-node1 ~]# ifconfig -a|more
bond0     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond1     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond2     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond3     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond4     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

eth0      Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A0
           inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
           UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
           RX packets:315 errors:0 dropped:0 overruns:0 frame:0
           TX packets:143 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:30785 (30.0 KiB)  TX bytes:38501 (37.5 KiB)
           Interrupt:28 Memory:92000000-92012800

eth1      Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A2
           BROADCAST MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
           Interrupt:40 Memory:94000000-94012800

lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:13156 errors:0 dropped:0 overruns:0 frame:0
           TX packets:13156 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:3271301 (3.1 MiB)  TX bytes:3271301 (3.1 MiB)

ovirtmgmt Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A0
           inet addr:9.181.129.110  Bcast:9.181.129.255  Mask:255.255.255.0
           inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:182 errors:0 dropped:3 overruns:0 frame:0
           TX packets:133 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:16290 (15.9 KiB)  TX bytes:36667 (35.8 KiB)
[root at ovirt-node1 ~]#
[root at ovirt-node1 ~]# ifconfig -a|more
bond0     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond1     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond2     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond3     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bond4     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
           BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

eth0      Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A0
           inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
           UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
           RX packets:2036 errors:0 dropped:0 overruns:0 frame:0
           TX packets:246 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:184913 (180.5 KiB)  TX bytes:65801 (64.2 KiB)
           Interrupt:28 Memory:92000000-92012800

eth1      Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A2
           BROADCAST MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
           Interrupt:40 Memory:94000000-94012800

lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:13186 errors:0 dropped:0 overruns:0 frame:0
           TX packets:13186 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:3278642 (3.1 MiB)  TX bytes:3278642 (3.1 MiB)

ovirtmgmt Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A0
           inet addr:9.181.129.110  Bcast:9.181.129.255  Mask:255.255.255.0
           inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:1562 errors:0 dropped:69 overruns:0 frame:0
           TX packets:225 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:116628 (113.8 KiB)  TX bytes:62627 (61.1 KiB)

p4p1      Link encap:Ethernet  HWaddr 00:00:C9:E5:A1:36
           BROADCAST MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

p4p2      Link encap:Ethernet  HWaddr 00:00:C9:E5:A1:3A
           BROADCAST MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

usb0      Link encap:Ethernet  HWaddr 5E:F3:FC:DC:32:A3
           BROADCAST MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[root at ovirt-node1 ~]#


-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From simon at redhat.com  Tue Jun  5 17:30:43 2012
From: simon at redhat.com (Simon Grinberg)
Date: Tue, 05 Jun 2012 13:30:43 -0400 (EDT)
Subject: [Engine-devel] engine complained that it couldn't find the
	ovirtmgmt interface in my FC16 ovirt node
In-Reply-To: <4FCE34B3.9040309@linux.vnet.ibm.com>
Message-ID: <c6305b89-3e21-45d0-b05d-94692f27d6b8@zmail17.collab.prod.int.phx2.redhat.com>

If you go to the node and run 

vdsClient -s 0 getVdsCapabilities what is the response? 
You are suppose to get the network topology as reported by vdsm


----- Original Message -----
> From: "Shu Ming" <shuming at linux.vnet.ibm.com>
> To: engine-devel at ovirt.org
> Sent: Tuesday, June 5, 2012 7:32:51 PM
> Subject: [Engine-devel] engine complained that it couldn't find the ovirtmgmt interface in my FC16 ovirt node
> 
> Hi,
> 
> I found  the followings logs in my engine and engine set the node to
> non-operation state.   It is strange that I can see the ovirtmgmt
> network interface was there in the ovirt node.  Below are the logs
> and
> steps I did in ovirt node.  It seems that engine didn't get the right
> network interface information from ovirt node.  Can any one show me
> some
> steps to debug this problem?
> 
> 
> In my engine log:
> 
> 2012-06-06 00:45:00,185 INFO
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
> (QuartzScheduler_Worker-68) [897fad0] START,
> SetVdsStatusVDSCommand(vdsId = 848bcff0-ae2a-11e1-bb49-5254001498c4,
> status=NonOperational, nonOperationalReason=NETWORK_UNREACHABLE), log
> id: 53d27ec8
> 2012-06-06 00:45:00,188 INFO
> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
> (QuartzScheduler_Worker-68) [897fad0] FINISH, SetVdsStatusVDSCommand,
> log id: 53d27ec8
> 2012-06-06 00:45:00,190 INFO
> [org.ovirt.engine.core.bll.SetNonOperationalVdsCommand]
> (QuartzScheduler_Worker-68) [897fad0] Host ovirt-node1 is set to
> Non-Operational, it is missing the following networks: ovirtmgmt,
> 2012-06-06 00:45:00,198 INFO
> [org.ovirt.engine.core.bll.HandleVdsCpuFlagsOrClusterChangedCommand]
> (QuartzScheduler_Worker-68) [60291e0d] Running command:
> HandleVdsCpuFlagsOrClusterChangedCommand internal: true. Entities
> affected :  ID: 848bcff0-ae2a-11e1-bb49-5254001498c4 Type: VDS
> 
> However in my ovirt node,  the ovirtmgmt interface was there.
> 
> [root at ovirt-node1 ~]# brctl show
> bridge name     bridge id               STP enabled     interfaces
> ovirtmgmt               8000.5cf3fce432a0       no              eth0
> [root at ovirt-node1 ~]#
> 
> [root at ovirt-node1 ~]# ifconfig -a|more
> bond0     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>            BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> bond1     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>            BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> bond2     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>            BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> bond3     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>            BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> bond4     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>            BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> eth0      Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A0
>            inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
>            UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
>            RX packets:315 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:143 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:30785 (30.0 KiB)  TX bytes:38501 (37.5 KiB)
>            Interrupt:28 Memory:92000000-92012800
> 
> eth1      Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A2
>            BROADCAST MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>            Interrupt:40 Memory:94000000-94012800
> 
> lo        Link encap:Local Loopback
>            inet addr:127.0.0.1  Mask:255.0.0.0
>            inet6 addr: ::1/128 Scope:Host
>            UP LOOPBACK RUNNING  MTU:16436  Metric:1
>            RX packets:13156 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:13156 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:3271301 (3.1 MiB)  TX bytes:3271301 (3.1 MiB)
> 
> ovirtmgmt Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A0
>            inet addr:9.181.129.110  Bcast:9.181.129.255
>             Mask:255.255.255.0
>            inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:182 errors:0 dropped:3 overruns:0 frame:0
>            TX packets:133 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:16290 (15.9 KiB)  TX bytes:36667 (35.8 KiB)
> [root at ovirt-node1 ~]#
> [root at ovirt-node1 ~]# ifconfig -a|more
> bond0     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>            BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> bond1     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>            BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> bond2     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>            BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> bond3     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>            BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> bond4     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>            BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> eth0      Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A0
>            inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
>            UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
>            RX packets:2036 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:246 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:184913 (180.5 KiB)  TX bytes:65801 (64.2 KiB)
>            Interrupt:28 Memory:92000000-92012800
> 
> eth1      Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A2
>            BROADCAST MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>            Interrupt:40 Memory:94000000-94012800
> 
> lo        Link encap:Local Loopback
>            inet addr:127.0.0.1  Mask:255.0.0.0
>            inet6 addr: ::1/128 Scope:Host
>            UP LOOPBACK RUNNING  MTU:16436  Metric:1
>            RX packets:13186 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:13186 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:3278642 (3.1 MiB)  TX bytes:3278642 (3.1 MiB)
> 
> ovirtmgmt Link encap:Ethernet  HWaddr 5C:F3:FC:E4:32:A0
>            inet addr:9.181.129.110  Bcast:9.181.129.255
>             Mask:255.255.255.0
>            inet6 addr: fe80::5ef3:fcff:fee4:32a0/64 Scope:Link
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:1562 errors:0 dropped:69 overruns:0 frame:0
>            TX packets:225 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:116628 (113.8 KiB)  TX bytes:62627 (61.1 KiB)
> 
> p4p1      Link encap:Ethernet  HWaddr 00:00:C9:E5:A1:36
>            BROADCAST MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> p4p2      Link encap:Ethernet  HWaddr 00:00:C9:E5:A1:3A
>            BROADCAST MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> usb0      Link encap:Ethernet  HWaddr 5E:F3:FC:DC:32:A3
>            BROADCAST MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:1000
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> [root at ovirt-node1 ~]#
> 
> 
> --
> Shu Ming<shuming at linux.vnet.ibm.com>
> IBM China Systems and Technology Laboratory
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From lpeer at redhat.com  Wed Jun  6 12:04:31 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 06 Jun 2012 15:04:31 +0300
Subject: [Engine-devel] ovirt - quantum integretion
Message-ID: <4FCF474F.1030605@redhat.com>

Hi All,

A friendly reminder we'll have ovirt-quantum integration session in one
hour.

Thanks, Livnat


From lpeer at redhat.com  Wed Jun  6 12:38:43 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 06 Jun 2012 08:38:43 -0400 (EDT)
Subject: [Engine-devel] oVirt - quantum integration
Message-ID: <0ffebfad-6476-4dd2-b9ac-f2b9c54f4c01@zmail14.collab.prod.int.phx2.redhat.com>

The following meeting has been modified:

Subject: oVirt - quantum integration 
Organiser: "Livnat Peer" <lpeer at redhat.com> 

Location: "Antartica - TLV" <antartica-tlv at redhat.com> [MODIFIED]
Resources: "Antartica - TLV" <antartica-tlv at redhat.com> [MODIFIED]
Time: Wednesday, 6 June, 2012, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem
 
Invitees: engine-devel at ovirt.org; arch at ovirt.com; simon at redhat.com; gkotton at redhat.com; lhornyak at redhat.com; kroberts at redhat.com; rkukura at redhat.com 


*~*~*~*~*~*~*~*~*~*


Hi All, 

We'll have a discussion on oVirt-Quantum integration. 
In the meeting we'll discuss - 
http://www.ovirt.org/wiki/Quantum_and_oVirt 

Thanks, Livnat 

Bridge ID: 972506565679 
Dial-in information: 
Reservationless-Plus Toll Free Dial-In Number (US & Canada): (800) 451-8679 
Reservationless-Plus International Dial-In Number: (212) 729-5016 
Conference code: 972506565679 

Global Access Numbers Local: 
Australia, Sydney Dial-In #: 0289852326 
Austria, Vienna Dial-In #: 012534978196 
Belgium, Brussels Dial-In #: 027920405 
China Dial-In #: 4006205013 
Denmark, Copenhagen Dial-In #: 32729215 
Finland, Helsinki Dial-In #: 0923194436 
France, Paris Dial-In #: 0170377140 
Germany, Berlin Dial-In #: 030300190579 
Ireland, Dublin Dial-In #: 014367793 
Italy, Milan Dial-In #: 0236269529 
Netherlands, Amsterdam Dial-In #: 0207975872 
Norway, Oslo Dial-In #: 21033188 
Singapore Dial-In #: 64840858 
Spain, Barcelona Dial-In #: 935452328 
Sweden, Stockholm Dial-In #: 0850513770 
Switzerland, Geneva Dial-In #: 0225927881 
United Kingdom Dial-In #: 02078970515 
United Kingdom Dial-In #: 08445790676 
United Kingdom, LocalCall Dial-In #: 08445790678 
United States Dial-In #: 2127295016 


Global Access Numbers Tollfree: 
Argentina Dial-In #: 8004441016 
Australia Dial-In #: 1800337169 
Austria Dial-In #: 0800005898 
Bahamas Dial-In #: 18002054776 
Bahrain Dial-In #: 80004377 
Belgium Dial-In #: 080048325 
Brazil Dial-In #: 08008921002 
Bulgaria Dial-In #: 008001100236 
Chile Dial-In #: 800370228 
Colombia Dial-In #: 018009134033 
Costa Rica Dial-In #: 08000131048 
Cyprus Dial-In #: 80095297 
Czech Republic Dial-In #: 800700318 
Denmark Dial-In #: 80887114 
Dominican Republic Dial-In #: 18887512313 
Estonia Dial-In #: 8000100232 
Finland Dial-In #: 0800117116 
France Dial-In #: 0805632867 
Germany Dial-In #: 8006647541 
Greece Dial-In #: 00800127562 
Hong Kong Dial-In #: 800930349 
Hungary Dial-In #: 0680016796 
Iceland Dial-In #: 8008967 
India Dial-In #: 0008006501533 
Indonesia Dial-In #: 0018030179162 
Ireland Dial-In #: 1800932401 
Israel Dial-In #: 1809462557 
Italy Dial-In #: 800985897 
Jamaica Dial-In #: 18002050328 
Japan Dial-In #: 0120934453 
Korea (South) Dial-In #: 007986517393 
Latvia Dial-In #: 80003339 
Lithuania Dial-In #: 880030479 
Luxembourg Dial-In #: 80026595 
Malaysia Dial-In #: 1800814451 
Mexico Dial-In #: 0018664590915 
New Zealand Dial-In #: 0800888167 
Norway Dial-In #: 80012994 
Panama Dial-In #: 008002269184 
Philippines Dial-In #: 180011100991 
Poland Dial-In #: 008001210187 
Portugal Dial-In #: 800814625 
Russian Federation Dial-In #: 81080028341012 
Saint Kitts and Nevis Dial-In #: 18002059252 
Singapore Dial-In #: 8006162235 
Slovak Republic Dial-In #: 0800001441 
South Africa Dial-In #: 0800981148 
Spain Dial-In #: 800300524 
Sweden Dial-In #: 200896860 
Switzerland Dial-In #: 800650077 
Taiwan Dial-In #: 00801127141 
Thailand Dial-In #: 001800656966 
Trinidad and Tobago Dial-In #: 18002024615 
United Arab Emirates Dial-In #: 8000650591 
United Kingdom Dial-In #: 08006948057 
United States Dial-In #: 8004518679 
Uruguay Dial-In #: 00040190315 
Venezuela Dial-In #: 08001627182 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120606/2b01ce27/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meeting.ics
Type: text/calendar
Size: 10265 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120606/2b01ce27/attachment.ics>

From shuming at linux.vnet.ibm.com  Wed Jun  6 13:59:16 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Wed, 06 Jun 2012 21:59:16 +0800
Subject: [Engine-devel] A small patch foy iso-uploader
Message-ID: <4FCF6234.3020209@linux.vnet.ibm.com>

Hi
Can some review and approve this small patch?

http://gerrit.ovirt.org/#/c/4554/

-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From iheim at redhat.com  Wed Jun  6 14:15:53 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 06 Jun 2012 17:15:53 +0300
Subject: [Engine-devel] live migration and different technologies
Message-ID: <4FCF6619.2060701@redhat.com>

Hi Daniel,

on the quantum-ovirt call today the question of live migration between 
multiple technologies was raised.

iirc, you implemented the abstraction in libvirt between what the guest 
sees and the actual host networking implementation for live migration.

can you please share if there are any considerations around live 
migrations across different network implementations (bridge, sr-iov, 
ovs, qbg, openflow, etc.)

thanks,
    Itamar


From ovedo at redhat.com  Wed Jun  6 16:07:55 2012
From: ovedo at redhat.com (Oved Ourfalli)
Date: Wed, 06 Jun 2012 12:07:55 -0400 (EDT)
Subject: [Engine-devel] Ovirt on Fedora17
In-Reply-To: <888725ed02fc6eed8891fe901894750655c4927e@mail.qip.ru>
Message-ID: <b90d9521-5599-48ac-a39d-5dfb8012ced6@zmail02.collab.prod.int.phx2.redhat.com>

Hey,

You should really send such question to engine-devel, as someone might have encountered such an issue, so there might be a solution for that.
Can you also attach the vdsm.log file (in the host, under the directory /var/log/vdsm/vdsm.log).

Thank you,
Oved

----- Original Message -----
> From: ovirt at qip.ru
> To: "Oved Ourfalli" <ovedo at redhat.com>
> Sent: Wednesday, June 6, 2012 5:55:44 PM
> Subject: Re: Re: Ovirt on Fedora17
> 
> I use rpms from
> 
> http:// jenkins .ovirt.org/job/ovirt_engine_create_ rpms
> /lastSuccessfulBuild/artifact/output/*zip*/output.zip
> 
> and another problem that not solved is that VM don't start with
> attached CD
> 
> if only I attach CD to VM I got libvirt error ( i use only needed
> pachages from fedora17 repo except ovirt-engine and vdsm )
> 
> in webadmin error
> 
> VM VM01-Fedora17 is down. Exit message: internal error unsupported
> configuration: Readonly leases are not supported
> 
> in VM01-Fedora17.log
> 
> red_worker_main: begin
> display_channel_create: create display channel
> cursor_channel_create: create cursor channel
> Domain id=2 is tainted: custom- mon itor
> qemu: terminat ing on signal 15 from pid 606
> 2012-06-06 14:39:15.167+0000: shutt ing down
> 2012-06-06 14:39:37.381+0000: start ing up
> LC_ALL=C PATH=/ usr /local/sbin:/ usr /local/bin:/ usr /sbin:/ usr
> /bin QEMU _AUDIO_ DRV =none / usr /bin/qemu- kvm -S -M pc -0.14 -
> cpu kvm 64,+ lahf _lm,+ ssse 3,- cx 16 -enable- kvm -m 1024 - smp
> 1,sockets=1,cores=1,threads=1 -name VM01-Fedora17 - uuid
> e0a70093-5b11-472f-b452-d1ae815028f4 - smbios
> type=1,manufacturer=Red Hat,product= RHEV Hyperv iso r
> ,version=17-1,serial=49434D53-0200-9066-2500-66902500FE53_00:25:90:66:53:fe,
> uuid =e0a70093-5b11-472f-b452-d1ae815028f4 -nodefconfig - nodefaults
> - chardev socket,id= char mon itor ,path=/var/lib/ libvirt
> /qemu/VM01-Fedora17. mon itor,server, nowait - mon chardev = char
> mon itor ,id= mon itor,mode=control - rtc base=2012-06-06T14:39:37,
> driftfix =slew -no-shutdown -device piix 3- usb - uhci ,id= usb
> ,bus= pc i.0, addr =0x1.0x2 -device virtio -serial- pc i,id= virtio
> -serial0,bus= pc i.0, addr =0x4 -drive file=/ rhev
> /data-center/5ac3a99a- afdd -11e1-8957-000c290cc066/d2221 cee
> -7146-4197- aecf -0 dfad
> 32b54ea/images/11111111-1111-1111-1111-111111111111/Fedora-17-x86_64-
> netinst . iso ,if=none,media= cdrom ,id=drive- ide 0-1-0, readonly
> =on,format=raw,serial= -device ide -drive,bus= ide
> .1,unit=0,drive=drive- ide 0-1-0,id= ide 0-1-0 -drive file=/ rhev
> /data-center/5ac3a99a- afdd
> -11e1-8957-000c290cc066/e5485577-8f51-4213- acd
> 8-f38e064cf308/images/9865260a-7480-4cd2-8352-9f44ee2d6c37/00ed2438-6768-4c94-8215-8a678d4d0d50,if=none,id=drive-
> virtio -disk0,format= qcow
> 2,serial=9865260a-7480-4cd2-8352-9f44ee2d6c37,cache=none, werror
> =stop, rerror =stop, aio =native -device virtio - blk - pc i, scsi
> =off,bus= pc i.0, addr =0x5,drive=drive- virtio -disk0,id= virtio
> -disk0, bootindex =1 - netdev tap,fd=25,id= hostnet 0, vhost =on,
> vhost fd=26 -device virtio -net- pc i, netdev = hostnet
> 0,id=net0,mac=00:1a:4a:10:00:00,bus= pc i.0, addr =0x3 - chardev
> socket,id= charchannel 0,path=/var/lib/ libvirt
> /qemu/channels/VM01-Fedora17.com. redhat . rhev m. vdsm ,server,
> nowait -device virtserialport,bus= virtio -serial0.0,nr=1, chardev =
> charchannel 0,id=channel0,name=com. redhat . rhev m. vdsm - chardev
> pty ,id= charconsole 0 -device vi rtc onsole, chardev = charconsole
> 0,id=console0 -device usb -tablet,id=input0 - vnc 0:0,password -k
> en-us - vga qxl -global qxl - vga . vram _size=67108864 -device
> virtio -balloon- pc i,id=balloon0,bus= pc i.0, addr =0x6
> l ibvir: Lock ing error : unsupported configuration: Readonly leases
> are not supported
> 2012-06-06 14:39:37.412+0000: shutt ing down
> 
> 
> I tried to use this patch on libvirt
> 
> http:// www .mail-archive.com/libvir-list@ redhat .com/ msg 56247.
> html
> 
> but it didn't help



From oschreib at redhat.com  Wed Jun  6 16:39:28 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Wed, 06 Jun 2012 12:39:28 -0400 (EDT)
Subject: [Engine-devel] oVirt 3.1 Feature Freeze is TOMORROW (June 7th)
In-Reply-To: <b8107e5d-3bf5-46f1-bbbc-315b3881b727@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <486c1139-16dd-444e-90f2-10f5ab7e8e1a@zmail14.collab.prod.int.phx2.redhat.com>

Almost 4 month after oVirt's first release, we're one step closer to the next version.

The Feature Freeze is scheduled for tomorrow, June 7th, and shortly after that, new "beta" builds should be uploaded into http://ovirt.org:/releases/beta

Currently, http://ovirt.org:/releases/beta/fedora/17 is populated with "alpha" builds of oVirt. Feel free to test them, and share with us your feedback.

Regards,
--
Ofer Schreiber
oVirt Release Manager


From lpeer at redhat.com  Wed Jun  6 18:41:57 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Wed, 06 Jun 2012 21:41:57 +0300
Subject: [Engine-devel] quantum-ovirt integration meeting summary
Message-ID: <4FCFA475.7010803@redhat.com>

Hi All,

This is a summary of the first quantum-oVirt integration meeting.

In the meeting Garry Kotton started presenting his proposal for the
integration, for more details on his proposal look in -
http://www.ovirt.org/wiki/Quantum_and_oVirt

We did not cover much of the wiki as some question arose:

* What is the end goal of the integration? is it to replace the current
network configuration implementation in oVirt by quantum or have them
side by side.

- we need to remember non-VM networks (like storage and migration networks)

* Will oVirt use multiple quantum instances, one per technology, or will
oVirt use a single quantum instance that should support multiple
plug-ins (not supported in Quantum ATM)

* We'll oVirt support a mix of different technologies in a DC, Cluster,
host?
- Can we assume homogeneous clusters for the sake of simplicity (in a
single cluster we'll support either open Vswitch or UCSM or ..)
- Logical Network is defined in the scope of a data center, that means
we need to maintain layer 2 connectivity and within a cluster we need to
guarantee VM live migration (does libvirt abstract it for us?)


other notes -

* The UUIDs that are returned by Quantum will be managed by oVirt and
for a single network implemented in two different technologies in
quantum oVirt will be responsible to sync the different IDs.

* The integration should be as seamless as possible to the user of oVirt

* support of existing VLAN in quantum should be introduces in quantum in
a 3-4 weeks time-frame



Comments are welcomed, I'll schedule a follow up next week.

Thanks, Livnat



From iheim at redhat.com  Wed Jun  6 20:41:55 2012
From: iheim at redhat.com (Itamar Heim)
Date: Wed, 06 Jun 2012 23:41:55 +0300
Subject: [Engine-devel] Ovirt on Fedora17
In-Reply-To: <b90d9521-5599-48ac-a39d-5dfb8012ced6@zmail02.collab.prod.int.phx2.redhat.com>
References: <b90d9521-5599-48ac-a39d-5dfb8012ced6@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <4FCFC093.8020608@redhat.com>

On 06/06/2012 07:07 PM, Oved Ourfalli wrote:
> Hey,
>
> You should really send such question to engine-devel, as someone might have encountered such an issue, so there might be a solution for that.
> Can you also attach the vdsm.log file (in the host, under the directory /var/log/vdsm/vdsm.log).

I think i saw something around this recently.
federico?

>
> Thank you,
> Oved
>
> ----- Original Message -----
>> From: ovirt at qip.ru
>> To: "Oved Ourfalli"<ovedo at redhat.com>
>> Sent: Wednesday, June 6, 2012 5:55:44 PM
>> Subject: Re: Re: Ovirt on Fedora17
>>
>> I use rpms from
>>
>> http:// jenkins .ovirt.org/job/ovirt_engine_create_ rpms
>> /lastSuccessfulBuild/artifact/output/*zip*/output.zip
>>
>> and another problem that not solved is that VM don't start with
>> attached CD
>>
>> if only I attach CD to VM I got libvirt error ( i use only needed
>> pachages from fedora17 repo except ovirt-engine and vdsm )
>>
>> in webadmin error
>>
>> VM VM01-Fedora17 is down. Exit message: internal error unsupported
>> configuration: Readonly leases are not supported
>>
>> in VM01-Fedora17.log
>>
>> red_worker_main: begin
>> display_channel_create: create display channel
>> cursor_channel_create: create cursor channel
>> Domain id=2 is tainted: custom- mon itor
>> qemu: terminat ing on signal 15 from pid 606
>> 2012-06-06 14:39:15.167+0000: shutt ing down
>> 2012-06-06 14:39:37.381+0000: start ing up
>> LC_ALL=C PATH=/ usr /local/sbin:/ usr /local/bin:/ usr /sbin:/ usr
>> /bin QEMU _AUDIO_ DRV =none / usr /bin/qemu- kvm -S -M pc -0.14 -
>> cpu kvm 64,+ lahf _lm,+ ssse 3,- cx 16 -enable- kvm -m 1024 - smp
>> 1,sockets=1,cores=1,threads=1 -name VM01-Fedora17 - uuid
>> e0a70093-5b11-472f-b452-d1ae815028f4 - smbios
>> type=1,manufacturer=Red Hat,product= RHEV Hyperv iso r
>> ,version=17-1,serial=49434D53-0200-9066-2500-66902500FE53_00:25:90:66:53:fe,
>> uuid =e0a70093-5b11-472f-b452-d1ae815028f4 -nodefconfig - nodefaults
>> - chardev socket,id= char mon itor ,path=/var/lib/ libvirt
>> /qemu/VM01-Fedora17. mon itor,server, nowait - mon chardev = char
>> mon itor ,id= mon itor,mode=control - rtc base=2012-06-06T14:39:37,
>> driftfix =slew -no-shutdown -device piix 3- usb - uhci ,id= usb
>> ,bus= pc i.0, addr =0x1.0x2 -device virtio -serial- pc i,id= virtio
>> -serial0,bus= pc i.0, addr =0x4 -drive file=/ rhev
>> /data-center/5ac3a99a- afdd -11e1-8957-000c290cc066/d2221 cee
>> -7146-4197- aecf -0 dfad
>> 32b54ea/images/11111111-1111-1111-1111-111111111111/Fedora-17-x86_64-
>> netinst . iso ,if=none,media= cdrom ,id=drive- ide 0-1-0, readonly
>> =on,format=raw,serial= -device ide -drive,bus= ide
>> .1,unit=0,drive=drive- ide 0-1-0,id= ide 0-1-0 -drive file=/ rhev
>> /data-center/5ac3a99a- afdd
>> -11e1-8957-000c290cc066/e5485577-8f51-4213- acd
>> 8-f38e064cf308/images/9865260a-7480-4cd2-8352-9f44ee2d6c37/00ed2438-6768-4c94-8215-8a678d4d0d50,if=none,id=drive-
>> virtio -disk0,format= qcow
>> 2,serial=9865260a-7480-4cd2-8352-9f44ee2d6c37,cache=none, werror
>> =stop, rerror =stop, aio =native -device virtio - blk - pc i, scsi
>> =off,bus= pc i.0, addr =0x5,drive=drive- virtio -disk0,id= virtio
>> -disk0, bootindex =1 - netdev tap,fd=25,id= hostnet 0, vhost =on,
>> vhost fd=26 -device virtio -net- pc i, netdev = hostnet
>> 0,id=net0,mac=00:1a:4a:10:00:00,bus= pc i.0, addr =0x3 - chardev
>> socket,id= charchannel 0,path=/var/lib/ libvirt
>> /qemu/channels/VM01-Fedora17.com. redhat . rhev m. vdsm ,server,
>> nowait -device virtserialport,bus= virtio -serial0.0,nr=1, chardev =
>> charchannel 0,id=channel0,name=com. redhat . rhev m. vdsm - chardev
>> pty ,id= charconsole 0 -device vi rtc onsole, chardev = charconsole
>> 0,id=console0 -device usb -tablet,id=input0 - vnc 0:0,password -k
>> en-us - vga qxl -global qxl - vga . vram _size=67108864 -device
>> virtio -balloon- pc i,id=balloon0,bus= pc i.0, addr =0x6
>> l ibvir: Lock ing error : unsupported configuration: Readonly leases
>> are not supported
>> 2012-06-06 14:39:37.412+0000: shutt ing down
>>
>>
>> I tried to use this patch on libvirt
>>
>> http:// www .mail-archive.com/libvir-list@ redhat .com/ msg 56247.
>> html
>>
>> but it didn't help
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From snmishra at linux.vnet.ibm.com  Thu Jun  7 04:20:17 2012
From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com)
Date: Thu, 07 Jun 2012 00:20:17 -0400
Subject: [Engine-devel] Duplicate LdapProviderType and LdapVendorNameEnum
	reappear.
Message-ID: <20120607002017.Horde.Gm6BApir309P0CwBSmojbNA@imap.linux.ibm.com>


Hi,

    As part of http://gerrit.ovirt.org/#/c/4727/ patch, we had removed  
duplicate classes for LdapProviderType and LdapVendorNameEnum. But I  
noticed that they have reappeared upstream. Is it intentional or  
accidental?

Thanks
Sharad Mishra
IBM



From iheim at redhat.com  Thu Jun  7 05:15:42 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 07 Jun 2012 08:15:42 +0300
Subject: [Engine-devel] Ovirt on Fedora17
In-Reply-To: <4FCFC093.8020608@redhat.com>
References: <b90d9521-5599-48ac-a39d-5dfb8012ced6@zmail02.collab.prod.int.phx2.redhat.com>
	<4FCFC093.8020608@redhat.com>
Message-ID: <4FD038FE.3020004@redhat.com>

On 06/06/2012 11:41 PM, Itamar Heim wrote:
> On 06/06/2012 07:07 PM, Oved Ourfalli wrote:
>> Hey,
>>
>> You should really send such question to engine-devel, as someone might
>> have encountered such an issue, so there might be a solution for that.
>> Can you also attach the vdsm.log file (in the host, under the
>> directory /var/log/vdsm/vdsm.log).
>
> I think i saw something around this recently.
> federico?

found it - https://bugzilla.redhat.com/show_bug.cgi?id=828633

>
>>
>> Thank you,
>> Oved
>>
>> ----- Original Message -----
>>> From: ovirt at qip.ru
>>> To: "Oved Ourfalli"<ovedo at redhat.com>
>>> Sent: Wednesday, June 6, 2012 5:55:44 PM
>>> Subject: Re: Re: Ovirt on Fedora17
>>>
>>> I use rpms from
>>>
>>> http:// jenkins .ovirt.org/job/ovirt_engine_create_ rpms
>>> /lastSuccessfulBuild/artifact/output/*zip*/output.zip
>>>
>>> and another problem that not solved is that VM don't start with
>>> attached CD
>>>
>>> if only I attach CD to VM I got libvirt error ( i use only needed
>>> pachages from fedora17 repo except ovirt-engine and vdsm )
>>>
>>> in webadmin error
>>>
>>> VM VM01-Fedora17 is down. Exit message: internal error unsupported
>>> configuration: Readonly leases are not supported
>>>
>>> in VM01-Fedora17.log
>>>
>>> red_worker_main: begin
>>> display_channel_create: create display channel
>>> cursor_channel_create: create cursor channel
>>> Domain id=2 is tainted: custom- mon itor
>>> qemu: terminat ing on signal 15 from pid 606
>>> 2012-06-06 14:39:15.167+0000: shutt ing down
>>> 2012-06-06 14:39:37.381+0000: start ing up
>>> LC_ALL=C PATH=/ usr /local/sbin:/ usr /local/bin:/ usr /sbin:/ usr
>>> /bin QEMU _AUDIO_ DRV =none / usr /bin/qemu- kvm -S -M pc -0.14 -
>>> cpu kvm 64,+ lahf _lm,+ ssse 3,- cx 16 -enable- kvm -m 1024 - smp
>>> 1,sockets=1,cores=1,threads=1 -name VM01-Fedora17 - uuid
>>> e0a70093-5b11-472f-b452-d1ae815028f4 - smbios
>>> type=1,manufacturer=Red Hat,product= RHEV Hyperv iso r
>>> ,version=17-1,serial=49434D53-0200-9066-2500-66902500FE53_00:25:90:66:53:fe,
>>>
>>> uuid =e0a70093-5b11-472f-b452-d1ae815028f4 -nodefconfig - nodefaults
>>> - chardev socket,id= char mon itor ,path=/var/lib/ libvirt
>>> /qemu/VM01-Fedora17. mon itor,server, nowait - mon chardev = char
>>> mon itor ,id= mon itor,mode=control - rtc base=2012-06-06T14:39:37,
>>> driftfix =slew -no-shutdown -device piix 3- usb - uhci ,id= usb
>>> ,bus= pc i.0, addr =0x1.0x2 -device virtio -serial- pc i,id= virtio
>>> -serial0,bus= pc i.0, addr =0x4 -drive file=/ rhev
>>> /data-center/5ac3a99a- afdd -11e1-8957-000c290cc066/d2221 cee
>>> -7146-4197- aecf -0 dfad
>>> 32b54ea/images/11111111-1111-1111-1111-111111111111/Fedora-17-x86_64-
>>> netinst . iso ,if=none,media= cdrom ,id=drive- ide 0-1-0, readonly
>>> =on,format=raw,serial= -device ide -drive,bus= ide
>>> .1,unit=0,drive=drive- ide 0-1-0,id= ide 0-1-0 -drive file=/ rhev
>>> /data-center/5ac3a99a- afdd
>>> -11e1-8957-000c290cc066/e5485577-8f51-4213- acd
>>> 8-f38e064cf308/images/9865260a-7480-4cd2-8352-9f44ee2d6c37/00ed2438-6768-4c94-8215-8a678d4d0d50,if=none,id=drive-
>>>
>>> virtio -disk0,format= qcow
>>> 2,serial=9865260a-7480-4cd2-8352-9f44ee2d6c37,cache=none, werror
>>> =stop, rerror =stop, aio =native -device virtio - blk - pc i, scsi
>>> =off,bus= pc i.0, addr =0x5,drive=drive- virtio -disk0,id= virtio
>>> -disk0, bootindex =1 - netdev tap,fd=25,id= hostnet 0, vhost =on,
>>> vhost fd=26 -device virtio -net- pc i, netdev = hostnet
>>> 0,id=net0,mac=00:1a:4a:10:00:00,bus= pc i.0, addr =0x3 - chardev
>>> socket,id= charchannel 0,path=/var/lib/ libvirt
>>> /qemu/channels/VM01-Fedora17.com. redhat . rhev m. vdsm ,server,
>>> nowait -device virtserialport,bus= virtio -serial0.0,nr=1, chardev =
>>> charchannel 0,id=channel0,name=com. redhat . rhev m. vdsm - chardev
>>> pty ,id= charconsole 0 -device vi rtc onsole, chardev = charconsole
>>> 0,id=console0 -device usb -tablet,id=input0 - vnc 0:0,password -k
>>> en-us - vga qxl -global qxl - vga . vram _size=67108864 -device
>>> virtio -balloon- pc i,id=balloon0,bus= pc i.0, addr =0x6
>>> l ibvir: Lock ing error : unsupported configuration: Readonly leases
>>> are not supported
>>> 2012-06-06 14:39:37.412+0000: shutt ing down
>>>
>>>
>>> I tried to use this patch on libvirt
>>>
>>> http:// www .mail-archive.com/libvir-list@ redhat .com/ msg 56247.
>>> html
>>>
>>> but it didn't help
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>



From gkotton at redhat.com  Thu Jun  7 06:01:28 2012
From: gkotton at redhat.com (Gary Kotton)
Date: Thu, 07 Jun 2012 09:01:28 +0300
Subject: [Engine-devel] quantum-ovirt integration meeting summary
In-Reply-To: <4FCFA475.7010803@redhat.com>
References: <4FCFA475.7010803@redhat.com>
Message-ID: <4FD043B8.7080300@redhat.com>

Hi,
Thanks for the time yesterday. Please see my inline comments.
Please feel free to contact me if you have any additional questions.
Thanks
Gary

On 06/06/2012 09:41 PM, Livnat Peer wrote:
> Hi All,
>
> This is a summary of the first quantum-oVirt integration meeting.
>
> In the meeting Garry Kotton started presenting his proposal for the
> integration, for more details on his proposal look in -
> http://www.ovirt.org/wiki/Quantum_and_oVirt
>
> We did not cover much of the wiki as some question arose:
>
> * What is the end goal of the integration? is it to replace the current
> network configuration implementation in oVirt by quantum or have them
> side by side.
I think that the first phase should enable them to work together. That 
is, the user can have host that run traditional VDSM networking and host 
that run a specific Quantum agent. In addition to this. I think that the 
user should also have the flexibility to choose which network interfaces 
run Quantum or traditional VDSM.
In short the answer is "side by side".
> - we need to remember non-VM networks (like storage and migration networks)
The crystallizes the point above, management and storage can continue to 
use the existing VDSM networking and the VM networks can start to use 
Quantum.
> * Will oVirt use multiple quantum instances, one per technology, or will
> oVirt use a single quantum instance that should support multiple
> plug-ins (not supported in Quantum ATM)
oVirt should use one Quantum instance. Today I will draw up a blueprint 
for Quantum to have a "Rosetta Plugin", that is a plugin that can 
support a number of different networking technologies.
> * We'll oVirt support a mix of different technologies in a DC, Cluster,
> host?
I think that the only limitation should be to run one Quantum agent per 
host.
> - Can we assume homogeneous clusters for the sake of simplicity (in a
> single cluster we'll support either open Vswitch or UCSM or ..)
I do not think that we should go for a simple solution, but we should 
strive for a proper solution. I see no reason to prevent or limit this. 
I feel that this would be a hard limitation for oVirt users. A example 
to show this limitation is the addition of a host to the existing 
cluster that has new networking capabilities that are supported by a 
different Quantum plugin.
oVirt must be aware of the capabilities of each host to indicate to the 
user that certain operations may not be possible, or may cause the 
virtual machine to behave differently (performance degradation for 
example), if they have decided to work in this manner - for example live 
live migration.
> - Logical Network is defined in the scope of a data center, that means
> we need to maintain layer 2 connectivity and within a cluster we need to
> guarantee VM live migration (does libvirt abstract it for us?)
Once again, oVirt should be aware of the host characteristics. This will 
not only be the hardware but also the software running on the host. This 
will enable oVirt to indicate to the user what is and what is not possible.
>
> other notes -
>
> * The UUIDs that are returned by Quantum will be managed by oVirt and
> for a single network implemented in two different technologies in
> quantum oVirt will be responsible to sync the different IDs.
This is not relevant as oVirt will work with only one Quantum server - 
that is, each logical network will have only one UUID.
> * The integration should be as seamless as possible to the user of oVirt
+1
> * support of existing VLAN in quantum should be introduces in quantum in
> a 3-4 weeks time-frame
This is scheduled for Folsom-2 
(https://launchpad.net/quantum/+milestone/folsom-2). I do not see any 
blockers at the moment to prevent the start of integration.
>
>
> Comments are welcomed, I'll schedule a follow up next week.
I will try and prepare some diagrams that will maybe help us with the 
next talk. I'll post these as soon as they are ready.
> Thanks, Livnat
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From ovirt at qip.ru  Thu Jun  7 08:02:31 2012
From: ovirt at qip.ru (ovirt at qip.ru)
Date: Thu, 07 Jun 2012 12:02:31 +0400
Subject: [Engine-devel] =?utf-8?b?RndkOiBSZTogIE92aXJ0IMKtwq1vbiBGZWRvcmEx?=
	=?utf-8?q?7?=
In-Reply-To: <4FD05A2C.2060209@redhat.com>
References: <4FD05A2C.2060209@redhat.com>
Message-ID: <a654828d199896728e52ab3038ceb9af26046d9f@mail.qip.ru>

----- ???????????? ?????? -----
????: ??? 07 ??? 2012 11:37:22 +0400
??: Itamar Heim 
????: Re: [Engine-devel] Ovirt ??on Fedora17
????: ovirt at qip.ru

On 06/07/2012 08:55 AM, ovirt at qip.ru wrote:

> In libvirt there is no such parameter even in

> http://kojipkgs.fedoraproject.org/packages/libvirt/0.9.12/1.fc18/src/libvirt-0.9.12-1.fc18.src.rpm

>

> ignore_readonly_and_shared_disks

please reply to list

>

>

>

>

> ??? 07 ??? 2012 09:15:53 +0400, Itamar Heim  ???????:

>

>     On 06/06/2012 11:41 PM, Itamar Heim wrote:

>      > On 06/06/2012 07:07 PM, Oved Ourfalli wrote:

>      >> Hey,

>      >>

>      >> You should really send such question to engine-devel, as someone

>     might

>      >> have encountered such an issue, so there might be a solution for

>     that.

>      >> Can you also attach the vdsm.log file (in the host, under the

>      >> directory /var/log/vdsm/vdsm.log).

>      >

>      > I think i saw something around this recently.

>      > federico?

>

>     found it - https://bugzilla.redhat.com/show_bug.cgi?id=828633

>

>      >

>      >>

>      >> Thank you,

>      >> Oved

>      >>

>      >> ----- Original Message -----

>      >>> From: ovirt at qip.ru

>      >>> To: "Oved Ourfalli"

>      >>> Sent: Wednesday, June 6, 2012 5:55:44 PM

>      >>> Subject: Re: Re: Ovirt on Fedora17

>      >>>

>      >>> I use rpms from

>      >>>

>      >>> http:// jenkins .ovirt.org/job/ovirt_engine_create_ rpms

>      >>> /lastSuccessfulBuild/artifact/output/*zip*/output.zip

>      >>>

>      >>> and another problem that not solved is that VM don't start with

>      >>> attached CD

>      >>>

>      >>> if only I attach CD to VM I got libvirt error ( i use only needed

>      >>> pachages from fedora17 repo except ovirt-engine and vdsm )

>      >>>

>      >>> in webadmin error

>      >>>

>      >>> VM VM01-Fedora17 is down. Exit message: internal error unsupported

>      >>> configuration: Readonly leases are not supported

>      >>>

>      >>> in VM01-Fedora17.log

>      >>>

>      >>> red_worker_main: begin

>      >>> display_channel_create: create display channel

>      >>> cursor_channel_create: create cursor channel

>      >>> Domain id=2 is tainted: custom- mon itor

>      >>> qemu: terminat ing on signal 15 from pid 606

>      >>> 2012-06-06 14:39:15.167+0000: shutt ing down

>      >>> 2012-06-06 14:39:37.381+0000: start ing up

>      >>> LC_ALL=C PATH=/ usr /local/sbin:/ usr /local/bin:/ usr /sbin:/ usr

>      >>> /bin QEMU _AUDIO_ DRV =none / usr /bin/qemu- kvm -S -M pc -0.14 -

>      >>> cpu kvm 64,+ lahf _lm,+ ssse 3,- cx 16 -enable- kvm -m 1024 - smp

>      >>> 1,sockets=1,cores=1,threads=1 -name VM01-Fedora17 - uuid

>      >>> e0a70093-5b11-472f-b452-d1ae815028f4 - smbios

>      >>> type=1,manufacturer=Red Hat,product= RHEV Hyperv iso r

>      >>>

>     ,version=17-1,serial=49434D53-0200-9066-2500-66902500FE53_00:25:90:66:53:fe,

>

>      >>>

>      >>> uuid =e0a70093-5b11-472f-b452-d1ae815028f4 -nodefconfig -

>     nodefaults

>      >>> - chardev socket,id= char mon itor ,path=/var/lib/ libvirt

>      >>> /qemu/VM01-Fedora17. mon itor,server, nowait - mon chardev = char

>      >>> mon itor ,id= mon itor,mode=control - rtc

>     base=2012-06-06T14:39:37,

>      >>> driftfix =slew -no-shutdown -device piix 3- usb - uhci ,id= usb

>      >>> ,bus= pc i.0, addr =0x1.0x2 -device virtio -serial- pc i,id=

>     virtio

>      >>> -serial0,bus= pc i.0, addr =0x4 -drive file=/ rhev

>      >>> /data-center/5ac3a99a- afdd -11e1-8957-000c290cc066/d2221 cee

>      >>> -7146-4197- aecf -0 dfad

>      >>>

>     32b54ea/images/11111111-1111-1111-1111-111111111111/Fedora-17-x86_64-

>      >>> netinst . iso ,if=none,media= cdrom ,id=drive- ide 0-1-0, readonly

>      >>> =on,format=raw,serial= -device ide -drive,bus= ide

>      >>> .1,unit=0,drive=drive- ide 0-1-0,id= ide 0-1-0 -drive file=/ rhev

>      >>> /data-center/5ac3a99a- afdd

>      >>> -11e1-8957-000c290cc066/e5485577-8f51-4213- acd

>      >>>

>     8-f38e064cf308/images/9865260a-7480-4cd2-8352-9f44ee2d6c37/00ed2438-6768-4c94-8215-8a678d4d0d50,if=none,id=drive-

>

>      >>>

>      >>> virtio -disk0,format= qcow

>      >>> 2,serial=9865260a-7480-4cd2-8352-9f44ee2d6c37,cache=none, werror

>      >>> =stop, rerror =stop, aio =native -device virtio - blk - pc i, scsi

>      >>> =off,bus= pc i.0, addr =0x5,drive=drive- virtio -disk0,id= virtio

>      >>> -disk0, bootindex =1 - netdev tap,fd=25,id= hostnet 0, vhost =on,

>      >>> vhost fd=26 -device virtio -net- pc i, netdev = hostnet

>      >>> 0,id=net0,mac=00:1a:4a:10:00:00,bus= pc i.0, addr =0x3 - chardev

>      >>> socket,id= charchannel 0,path=/var/lib/ libvirt

>      >>> /qemu/channels/VM01-Fedora17.com. redhat . rhev m. vdsm ,server,

>      >>> nowait -device virtserialport,bus= virtio -serial0.0,nr=1,

>     chardev =

>      >>> charchannel 0,id=channel0,name=com. redhat . rhev m. vdsm -

>     chardev

>      >>> pty ,id= charconsole 0 -device vi rtc onsole, chardev =

>     charconsole

>      >>> 0,id=console0 -device usb -tablet,id=input0 - vnc 0:0,password -k

>      >>> en-us - vga qxl -global qxl - vga . vram _size=67108864 -device

>      >>> virtio -balloon- pc i,id=balloon0,bus= pc i.0, addr =0x6

>      >>> l ibvir: Lock ing error : unsupported configuration: Readonly

>     leases

>      >>> are not supported

>      >>> 2012-06-06 14:39:37.412+0000: shutt ing down

>      >>>

>      >>>

>      >>> I tried to use this patch on libvirt

>      >>>

>      >>> http:// www .mail-archive.com/libvir-list@ redhat .com/ msg 56247.

>      >>> html

>      >>>

>      >>> but it didn't help

>      >>

>      >> _______________________________________________

>      >> 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/20120607/6e546bd7/attachment.html>

From rgolan at redhat.com  Thu Jun  7 08:38:10 2012
From: rgolan at redhat.com (Roy Golan)
Date: Thu, 07 Jun 2012 11:38:10 +0300
Subject: [Engine-devel] Duplicate LdapProviderType and
 LdapVendorNameEnum reappear.
In-Reply-To: <20120607002017.Horde.Gm6BApir309P0CwBSmojbNA@imap.linux.ibm.com>
References: <20120607002017.Horde.Gm6BApir309P0CwBSmojbNA@imap.linux.ibm.com>
Message-ID: <4FD06872.8060807@redhat.com>

On 06/07/2012 07:20 AM, snmishra at linux.vnet.ibm.com wrote:
>
> Hi,
>
>    As part of http://gerrit.ovirt.org/#/c/4727/ patch, we had removed 
> duplicate classes for LdapProviderType and LdapVendorNameEnum. But I 
> noticed that they have reappeared upstream. Is it intentional or 
> accidental?
>
> Thanks
> Sharad Mishra
> IBM
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
its a merge problem caused by a rebase of 
http://gerrit.ovirt.org/#/c/4633/ . I try to diff the patchset and I get 
'Not Found' by gerrit.

send http://gerrit.ovirt.org/5120 to fix this


From jhernand at redhat.com  Thu Jun  7 11:43:46 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Thu, 07 Jun 2012 13:43:46 +0200
Subject: [Engine-devel] Improve classpath building
In-Reply-To: <4FCE0134.1040408@redhat.com>
References: <4FCE0134.1040408@redhat.com>
Message-ID: <4FD093F2.5000308@redhat.com>

On 06/05/2012 02:53 PM, Juan Hernandez wrote:
> Hello all,
>
> I would like to propose an improvement in the way we build class-paths
> in the tools associated to the engine. At the moment we have at least
> two different ways to build classpaths:
>
> 1. Hard coded in the scripts, with maybe some variables:
>
> CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
>
> This depends a lot on where we place the jar files, and we need to place
> them in different places in different environments if we want to adhere
> to common packaging practices.
>
> 2. Use the build-classpath script:
>
> CP=`build-classpath engine-encryptutils engine-compat ...`
>
> This depends less on the place we put them, but it doesn't work in
> development environments where some jars are not installed to the proper
> system locations.
>
> None of these is good for all environments.
>
> I would like to replace this classpath building logic with an script
> that performs the task in an smarter way and that works in all our
> environments (production, development, Fedora, RHEL, etc).
>
> My proposal is to create a "engine-java" script that we should use
> always when invoking java programs. This script will receive the same
> parameters that the "java" launcher receives, but the "-cp" or
> "-classpath" options will contain not the absolute name of the jar
> files, but just a simple jar name instead, something like
> "commons-logging", "commons-codec" or "engineencryptutils". The script
> will extract the "-cp" or "-classpath" options given and use them to do
> a search of the jar files in the locations where they can be in
> different environments:
>
> /usr/share/java
> /usr/share/java/ovirt-engine
> /usr/share/ovirt-engine/engine.ear
> /usr/share/ovirt-engine/engine.ear/lib
> <your jboss development installation>/engine.ear
> <your jboss development installation>/engine.ear/lib
>
> In addition the script will check that all the give jar files exist and
> will abort the execution if any of them is missing.
>
> Find attached the initial version of the proposed script.
>
> Let me know what you think.
>
> Regards,
> Juan Hernandez
>

I submitted the following draft to gerrit, in case you want to take a 
look at the current state of the script:

http://gerrit.ovirt.org/#/c/5129

-- 
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 rluxenbe at redhat.com  Thu Jun  7 14:10:02 2012
From: rluxenbe at redhat.com (Roni Luxenberg)
Date: Thu, 07 Jun 2012 10:10:02 -0400 (EDT)
Subject: [Engine-devel] quantum-ovirt integration meeting summary
In-Reply-To: <4FD043B8.7080300@redhat.com>
Message-ID: <bcd4cfba-3ed4-4db3-bf1b-b1fbba11a197@zmail07.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> Hi,
> Thanks for the time yesterday. Please see my inline comments.
> Please feel free to contact me if you have any additional questions.
> Thanks
> Gary
> 
> On 06/06/2012 09:41 PM, Livnat Peer wrote:
> > Hi All,
> >
> > This is a summary of the first quantum-oVirt integration meeting.
> >
> > In the meeting Garry Kotton started presenting his proposal for the
> > integration, for more details on his proposal look in -
> > http://www.ovirt.org/wiki/Quantum_and_oVirt
> >
> > We did not cover much of the wiki as some question arose:
> >
> > * What is the end goal of the integration? is it to replace the
> > current
> > network configuration implementation in oVirt by quantum or have
> > them
> > side by side.
> I think that the first phase should enable them to work together.
> That
> is, the user can have host that run traditional VDSM networking and
> host
> that run a specific Quantum agent. In addition to this. I think that
> the
> user should also have the flexibility to choose which network
> interfaces
> run Quantum or traditional VDSM.
> In short the answer is "side by side".
I think that quantum is just a mean to an end and assuming it works properly it should be "an implementation detail" completely transparent to the user so that all networks should be managed by quantum only. If this is the case we should have a procedure to migrate all networking to quantum during ovirt upgrade and thereafter use quantum solely.
To stress the point, it is an unnecessary added complexity for the user to be aware of quantum.

> > - we need to remember non-VM networks (like storage and migration
> > networks)
> The crystallizes the point above, management and storage can continue
> to
> use the existing VDSM networking and the VM networks can start to use
> Quantum.
On the same token I think we should aim for quantum to eventually own all network configuration regardless of the purpose and usage of the logical network (e.g. VM or non-VM).

> > * Will oVirt use multiple quantum instances, one per technology, or
> > will
> > oVirt use a single quantum instance that should support multiple
> > plug-ins (not supported in Quantum ATM)
> oVirt should use one Quantum instance. Today I will draw up a
> blueprint
> for Quantum to have a "Rosetta Plugin", that is a plugin that can
> support a number of different networking technologies.
> > * We'll oVirt support a mix of different technologies in a DC,
> > Cluster,
> > host?
> I think that the only limitation should be to run one Quantum agent
> per
> host.
> > - Can we assume homogeneous clusters for the sake of simplicity (in
> > a
> > single cluster we'll support either open Vswitch or UCSM or ..)
> I do not think that we should go for a simple solution, but we should
> strive for a proper solution. I see no reason to prevent or limit
> this.
> I feel that this would be a hard limitation for oVirt users. A
> example
> to show this limitation is the addition of a host to the existing
> cluster that has new networking capabilities that are supported by a
> different Quantum plugin.
> oVirt must be aware of the capabilities of each host to indicate to
> the
> user that certain operations may not be possible, or may cause the
> virtual machine to behave differently (performance degradation for
> example), if they have decided to work in this manner - for example
> live
> live migration.
agree. Assuming we have the "Rosetta Plugin" it will greatly simplify accomplishing the heterogeneous cluster approach.

> > - Logical Network is defined in the scope of a data center, that
> > means
> > we need to maintain layer 2 connectivity and within a cluster we
> > need to
> > guarantee VM live migration (does libvirt abstract it for us?)
> Once again, oVirt should be aware of the host characteristics. This
> will
> not only be the hardware but also the software running on the host.
> This
> will enable oVirt to indicate to the user what is and what is not
> possible.
> >
> > other notes -
> >
> > * The UUIDs that are returned by Quantum will be managed by oVirt
> > and
> > for a single network implemented in two different technologies in
> > quantum oVirt will be responsible to sync the different IDs.
> This is not relevant as oVirt will work with only one Quantum server
> -
> that is, each logical network will have only one UUID.
> > * The integration should be as seamless as possible to the user of
> > oVirt
> +1
> > * support of existing VLAN in quantum should be introduces in
> > quantum in
> > a 3-4 weeks time-frame
> This is scheduled for Folsom-2
> (https://launchpad.net/quantum/+milestone/folsom-2). I do not see any
> blockers at the moment to prevent the start of integration.
> >
> >
> > Comments are welcomed, I'll schedule a follow up next week.
> I will try and prepare some diagrams that will maybe help us with the
> next talk. I'll post these as soon as they are ready.
> > Thanks, Livnat
> >
> > _______________________________________________
> > 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 shaohef at linux.vnet.ibm.com  Thu Jun  7 15:14:00 2012
From: shaohef at linux.vnet.ibm.com (ShaoHe Feng)
Date: Thu, 07 Jun 2012 23:14:00 +0800
Subject: [Engine-devel] [ovirt-engine-sdk] some questions about the
 params.py code generated by generateSD
In-Reply-To: <4FBE7A47.6090001@linux.vnet.ibm.com>
References: <4FBE7A47.6090001@linux.vnet.ibm.com>
Message-ID: <4FD0C538.1080001@linux.vnet.ibm.com>

Hi all,

as we all know the current params.py was not completely by the 
generateSD.py, there are parts that have to be updated manually.

now I have post a primarypatch to improve it. 
http://gerrit.ovirt.org/#/c/4880/

it can generate some codes, but still two parts codes can not be generated.

they aretwo dictionaries: _rootClassMap and _elementToClassMap.

However, for I do get any clue to know these two dictionaries  from the 
params.py.

there are some questions:
1.
And the __all__ list  which include all the classes of _rootClassMap and 
_elementToClassMap.
And there some classes  both in _rootClassMap and _elementToClassMap.

2.
And  some of class in _rootClassMap inherit GeneratedsSuper class, some 
inherit BaseResource class, and two classes inherit Link class.
And it is the same with _elementToClassMap.

so what is the difference between _rootClassMap and _elementToClassMap.
What rule to generate these two dictionaries.

3.
And also, how to generate the keys in _rootClassMap and 
_elementToClassMap.Any rule to generate them?

there are some items in these two dictionaries

                       "access_control_list"           : 
AccessControlList,   #  "_" among the word in key
                       "api"                                    : API,
                       "body"                                 : Body,
                        "iscsi"                                 : 
IscsiDetails,             # key "iscsi" is one part of value "IscsiDetails"
                       "storage_domain"                : StorageDomain,
                       "topology"                           : CpuTopology,
                       "creation_status"                  : Status, # 
key has a more word  "creation"  than the value.
                       "parent"                                : TagParent






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

From jhernand at redhat.com  Thu Jun  7 18:04:32 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Thu, 07 Jun 2012 20:04:32 +0200
Subject: [Engine-devel] [ovirt-engine-sdk] some questions about the
 params.py code generated by generateSD
In-Reply-To: <4FD0C538.1080001@linux.vnet.ibm.com>
References: <4FBE7A47.6090001@linux.vnet.ibm.com>
	<4FD0C538.1080001@linux.vnet.ibm.com>
Message-ID: <4FD0ED30.5010804@redhat.com>

On 06/07/2012 05:14 PM, ShaoHe Feng wrote:
> Hi all,
>
> as we all know the current params.py was not completely by the
> generateSD.py, there are parts that have to be updated manually.
>
> now I have post a primarypatch to improve it.
> http://gerrit.ovirt.org/#/c/4880/
>
> it can generate some codes, but still two parts codes can not be generated.
>
> they aretwo dictionaries: _rootClassMap and _elementToClassMap.
>
> However, for I do get any clue to know these two dictionaries  from the
> params.py.

The reason for these dictionaries is that "generateDS.py" generates 
classes for the complex types inside the API .xsd, but it doesn't 
generate anything for the tags that can appear as root tags in the XML 
documents used by the API. The map helps the parser find the classes 
that correspond to each of those tags.

It might be possible to generate this map from the list of classes using 
a rule like this:

   CamelCaseName -> camel_case_names

But there are exceptions like these:

   VLAN -> vlan
   IPs  -> ips
   IscsiDetails -> iscsi

You could write code that takes into account the exceptions and 
generates the map. But I think it is not worth, and error prone. I would 
rather take that chunk of code out of params.py and move it to an 
external file or to a constant, like you do for other chunks of code in 
paramsconf.py.

> there are some questions:
> 1.
> And the __all__ list  which include all the classes of _rootClassMap and
> _elementToClassMap.
> And there some classes  both in _rootClassMap and _elementToClassMap.

The "__all__" list is just a python mechanism to control the symbols 
that are imported when you do something like "from whatever import *". 
In this case "generateDS.py" is making sure that all the generated 
classes are imported, which is not really relevant for us.

> 2.
> And  some of class in _rootClassMap inherit GeneratedsSuper class, some
> inherit BaseResource class, and two classes inherit Link class.
> And it is the same with _elementToClassMap.
>
> so what is the difference between _rootClassMap and _elementToClassMap.
> What rule to generate these two dictionaries.

I can't find any difference between those two dictionaries, they serve 
exactly the same purpose. Maybe Michael had a future use in mind.

> 3.
> And also, how to generate the keys in _rootClassMap and
> _elementToClassMap.Any rule to generate them?
>
> there are some items in these two dictionaries
>
>                         "access_control_list"           :
> AccessControlList,   #  "_" among the word in key
>                         "api"                                    : API,
>                         "body"                                 : Body,
>                          "iscsi"                                 :
> IscsiDetails,             # key "iscsi" is one part of value "IscsiDetails"
>                         "storage_domain"                : StorageDomain,
>                         "topology"                           : CpuTopology,
>                         "creation_status"                  : Status, #
> key has a more word  "creation"  than the value.
>                         "parent"                                : TagParent



-- 
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 tekka at normantec.it  Thu Jun  7 22:23:51 2012
From: tekka at normantec.it (Gianluca Cecchi)
Date: Fri, 8 Jun 2012 00:23:51 +0200
Subject: [Engine-devel] Ovirt on Fedora17
Message-ID: <CACK36mwzrUtCRgnTjJoRiq_RaHzNdRKNpyv7HT_TAYPj6vj8FA@mail.gmail.com>

On Wed Jun 6 12:07:55 EDT 2012 Oved Ourfalli wrote:
> Hey,
>
> You should really send such question to engine-devel, as someone might have encountered such an issue, so there might be a solution for that.
> Can you also attach the vdsm.log file (in the host, under the directory /var/log/vdsm/vdsm.log).
>
> Thank you,
> Oved
>
>> From: ovirt at qip.ru
>> To: "Oved Ourfalli" <ovedo at redhat.com>
>> Sent: Wednesday, June 6, 2012 5:55:44 PM
>> Subject: Re: Re: Ovirt on Fedora17
>>
>> I use rpms from
>>
>> http:// jenkins .ovirt.org/job/ovirt_engine_create_ rpms
>> /lastSuccessfulBuild/artifact/output/*zip*/output.zip

Hello,
I'm going to test ovrit on F17 too (both as  oVirt-engine server and
oVirt node).
Based on
http://fedoraproject.org/wiki/Features/oVirt
I supposed we don't need special repo any more and we can install
ovirt-engine and dependencies form default F17 repos...
Is it so?
Or should I enable any particular repo as in F16?
Thanks in advance

Gianluca


From iheim at redhat.com  Fri Jun  8 09:10:58 2012
From: iheim at redhat.com (Itamar Heim)
Date: Fri, 08 Jun 2012 12:10:58 +0300
Subject: [Engine-devel] Ovirt on Fedora17
In-Reply-To: <CACK36mwzrUtCRgnTjJoRiq_RaHzNdRKNpyv7HT_TAYPj6vj8FA@mail.gmail.com>
References: <CACK36mwzrUtCRgnTjJoRiq_RaHzNdRKNpyv7HT_TAYPj6vj8FA@mail.gmail.com>
Message-ID: <4FD1C1A2.2070809@redhat.com>

On 06/08/2012 01:23 AM, Gianluca Cecchi wrote:
> On Wed Jun 6 12:07:55 EDT 2012 Oved Ourfalli wrote:
>> Hey,
>>
>> You should really send such question to engine-devel, as someone might have encountered such an issue, so there might be a solution for that.
>> Can you also attach the vdsm.log file (in the host, under the directory /var/log/vdsm/vdsm.log).
>>
>> Thank you,
>> Oved
>>
>>> From: ovirt at qip.ru
>>> To: "Oved Ourfalli"<ovedo at redhat.com>
>>> Sent: Wednesday, June 6, 2012 5:55:44 PM
>>> Subject: Re: Re: Ovirt on Fedora17
>>>
>>> I use rpms from
>>>
>>> http:// jenkins .ovirt.org/job/ovirt_engine_create_ rpms
>>> /lastSuccessfulBuild/artifact/output/*zip*/output.zip
>
> Hello,
> I'm going to test ovrit on F17 too (both as  oVirt-engine server and
> oVirt node).
> Based on
> http://fedoraproject.org/wiki/Features/oVirt
> I supposed we don't need special repo any more and we can install
> ovirt-engine and dependencies form default F17 repos...
> Is it so?
> Or should I enable any particular repo as in F16?
> Thanks in advance

pay attention that the builtin fedora ovirt package does not include the 
UI yet.
and we'd welcome help testing our upcoming version of 3.1 and reporting 
issues:
http://www.ovirt.org/wiki/Second_Release


From jhernand at redhat.com  Fri Jun  8 09:14:34 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 08 Jun 2012 11:14:34 +0200
Subject: [Engine-devel] Ovirt on Fedora17
In-Reply-To: <CACK36mwzrUtCRgnTjJoRiq_RaHzNdRKNpyv7HT_TAYPj6vj8FA@mail.gmail.com>
References: <CACK36mwzrUtCRgnTjJoRiq_RaHzNdRKNpyv7HT_TAYPj6vj8FA@mail.gmail.com>
Message-ID: <4FD1C27A.3070303@redhat.com>

On 06/08/2012 12:23 AM, Gianluca Cecchi wrote:
> On Wed Jun 6 12:07:55 EDT 2012 Oved Ourfalli wrote:
>> Hey,
>>
>> You should really send such question to engine-devel, as someone might have encountered such an issue, so there might be a solution for that.
>> Can you also attach the vdsm.log file (in the host, under the directory /var/log/vdsm/vdsm.log).
>>
>> Thank you,
>> Oved
>>
>>> From: ovirt at qip.ru
>>> To: "Oved Ourfalli"<ovedo at redhat.com>
>>> Sent: Wednesday, June 6, 2012 5:55:44 PM
>>> Subject: Re: Re: Ovirt on Fedora17
>>>
>>> I use rpms from
>>>
>>> http:// jenkins .ovirt.org/job/ovirt_engine_create_ rpms
>>> /lastSuccessfulBuild/artifact/output/*zip*/output.zip
>
> Hello,
> I'm going to test ovrit on F17 too (both as  oVirt-engine server and
> oVirt node).
> Based on
> http://fedoraproject.org/wiki/Features/oVirt
> I supposed we don't need special repo any more and we can install
> ovirt-engine and dependencies form default F17 repos...
> Is it so?
> Or should I enable any particular repo as in F16?
> Thanks in advance
>
> Gianluca

In Fedora 17 you can just do "yum install ovirt-engine" and you will get 
version 3.0 without the GUI, only the backend and the RESTAPI. The 
reason for the missing GUI is that GWT is not yet available in Fedora.

If you want to help testing the upcoming 3.1 release, including the GUI, 
then it is better to use the latest alpha version, setting up an 
additional repository with a "ovirt-engine-31.repo" file in your 
"/etc/yum.repos.d" directory and the following content:

[ovirt-engine-31]
name=ovirt-engine-31
baseurl=http://ovirt.org/releases/beta/fedora/17
enabled=1
gpgcheck=0

Then install the engine with the following command:

yum install ovirt-engine-3.1.0_0001

If you find issues please let us know.

-- 
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 ovirt at qip.ru  Fri Jun  8 09:33:12 2012
From: ovirt at qip.ru (ovirt at qip.ru)
Date: Fri, 08 Jun 2012 13:33:12 +0400
Subject: [Engine-devel] =?utf-8?q?Ovirt_=C2=ADon_Fedora17?=
In-Reply-To: <4FD1C27A.3070303@redhat.com>
References: <4FD1C27A.3070303@redhat.com>
Message-ID: <e0ecb3fa484d8118798b9b246520b010c1a65460@mail.qip.ru>

When using build http://ovirt.org/releases/beta/fedora/17 not possible to create VM from webadmin

Oops! Error

2012-06-08 13:21:08,642 ERROR [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (ajp--0.0.0.0-8009-4) [aee90ef] Command org.ovirt.engine.core.bll.AddVmFromScratchCommand throw exception: org.springframework.dao.InvalidDataAccessApiUsageException: Required input parameter 'v_last_start_time' is missing
2012-06-08 13:21:08,699 ERROR [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (ajp--0.0.0.0-8009-4) [aee90ef] Transaction rolled-back for command: org.ovirt.engine.core.bll.AddVmFromScratchCommand.

May be it is possible to public new git?

??? 08 ??? 2012 13:14:44 +0400, Juan Hernandez  ???????:
On 06/08/2012 12:23 AM, Gianluca Cecchi wrote:
> On Wed Jun 6 12:07:55 EDT 2012 Oved Ourfalli wrote:
>> Hey,
>>
>> You should really send such question to engine-devel, as someone might have encountered such an issue, so there might be a solution for that.
>> Can you also attach the vdsm.log file (in the host, under the directory /var/log/vdsm/vdsm.log).
>>
>> Thank you,
>> Oved
>>
>>> From: ovirt at qip.ru
>>> To: "Oved Ourfalli"
>>> Sent: Wednesday, June 6, 2012 5:55:44 PM
>>> Subject: Re: Re: Ovirt on Fedora17
>>>
>>> I use rpms from
>>>
>>> http:// jenkins .ovirt.org/job/ovirt_engine_create_ rpms
>>> /lastSuccessfulBuild/artifact/output/*zip*/output.zip
>
> Hello,
> I'm going to test ovrit on F17 too (both as  oVirt-engine server and
> oVirt node).
> Based on
> http://fedoraproject.org/wiki/Features/oVirt
> I supposed we don't need special repo any more and we can install
> ovirt-engine and dependencies form default F17 repos...
> Is it so?
> Or should I enable any particular repo as in F16?
> Thanks in advance
>
> Gianluca

In Fedora 17 you can just do "yum install ovirt-engine" and you will get 
version 3.0 without the GUI, only the backend and the RESTAPI. The 
reason for the missing GUI is that GWT is not yet available in Fedora.

If you want to help testing the upcoming 3.1 release, including the GUI, 
then it is better to use the latest alpha version, setting up an 
additional repository with a "ovirt-engine-31.repo" file in your 
"/etc/yum.repos.d" directory and the following content:

[ovirt-engine-31]
name=ovirt-engine-31
baseurl=http://ovirt.org/releases/beta/fedora/17
enabled=1
gpgcheck=0

Then install the engine with the following command:

yum install ovirt-engine-3.1.0_0001

If you find issues please let us know.

-- 
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.
_______________________________________________
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/20120608/9803bef1/attachment.html>

From tekka at normantec.it  Fri Jun  8 09:47:22 2012
From: tekka at normantec.it (Gianluca Cecchi)
Date: Fri, 8 Jun 2012 11:47:22 +0200
Subject: [Engine-devel] Ovirt on Fedora17
In-Reply-To: <4FD1C27A.3070303@redhat.com>
References: <CACK36mwzrUtCRgnTjJoRiq_RaHzNdRKNpyv7HT_TAYPj6vj8FA@mail.gmail.com>
	<4FD1C27A.3070303@redhat.com>
Message-ID: <CACK36mzdMv_QdEwhQN8WMXNYwMfxf9D4UfD7Cf0XZx9GkBG0Ow@mail.gmail.com>

2012/6/8 Juan Hernandez wrote:
> If you want to help testing the upcoming 3.1 release, including the GUI,
> then it is better to use the latest alpha version, setting up an additional
> repository with a "ovirt-engine-31.repo" file in your "/etc/yum.repos.d"
> directory and the following content:
>
> [ovirt-engine-31]
> name=ovirt-engine-31
> baseurl=http://ovirt.org/releases/beta/fedora/17
> enabled=1
> gpgcheck=0
>
> Then install the engine with the following command:
>
> yum install ovirt-engine-3.1.0_0001
>
> If you find issues please let us know.
>

ok.
As two days ago I already installed ovirt-engine from f17 default
repo, I had to do these, due to dependency preoblems

[g.cecchi at f17 ~]$ sudo yum install ovirt-engine-3.1.0_0001
..
--> Finished Dependency Resolution
Error: Package: ovirt-engine-iso-uploader-3.0.0.0001-12.fc17.noarch (@fedora)
           Requires: ovirt-engine = 3.0.0.0001-12.fc17
           Removing: ovirt-engine-3.0.0.0001-12.fc17.noarch (@fedora)
               ovirt-engine = 3.0.0.0001-12.fc17
           Updated By: ovirt-engine-3.1.0_0001-0.gitf093e0.fc17.noarch
(ovirt-engine-31)
               ovirt-engine = 3.1.0_0001-0.gitf093e0.fc17
Error: Package: ovirt-engine-log-collector-3.0.0.0001-12.fc17.noarch (@fedora)
           Requires: ovirt-engine = 3.0.0.0001-12.fc17
           Removing: ovirt-engine-3.0.0.0001-12.fc17.noarch (@fedora)
               ovirt-engine = 3.0.0.0001-12.fc17
           Updated By: ovirt-engine-3.1.0_0001-0.gitf093e0.fc17.noarch
(ovirt-engine-31)
               ovirt-engine = 3.1.0_0001-0.gitf093e0.fc17

[g.cecchi at f17 ~]$ sudo yum remove
ovirt-engine-iso-uploader-3.0.0.0001-12.fc17.noarch
..
Dependencies Resolved

=========================================================================================================================================
 Package                                          Arch
 Version                             Repository              Size
=========================================================================================================================================
Removing:
 ovirt-engine-iso-uploader                        noarch
 3.0.0.0001-12.fc17                  @fedora                1.5 M
Removing for dependencies:
 ovirt-engine                                     noarch
 3.0.0.0001-12.fc17                  @fedora                1.2 M
 ovirt-engine-backend                             noarch
 3.0.0.0001-12.fc17                  @fedora                2.7 M
 ovirt-engine-config                              noarch
 3.0.0.0001-12.fc17                  @fedora                 27 k
 ovirt-engine-dbscripts                           noarch
 3.0.0.0001-12.fc17                  @fedora                482 k
 ovirt-engine-log-collector                       noarch
 3.0.0.0001-12.fc17                  @fedora                1.6 M
 ovirt-engine-notification-service                noarch
 3.0.0.0001-12.fc17                  @fedora                 64 k
 ovirt-engine-restapi                             noarch
 3.0.0.0001-12.fc17                  @fedora                772 k
 ovirt-engine-setup                               noarch
 3.0.0.0001-12.fc17                  @fedora                303 k
 ovirt-engine-tools-common                        noarch
 3.0.0.0001-12.fc17                  @fedora                8.8 k

Transaction Summary
=========================================================================================================================================
Remove  1 Package (+9 Dependent packages)


[g.cecchi at f17 ~]$ sudo yum install ovirt-engine-3.1.0_0001
...
Dependencies Resolved

=========================================================================================================================================
 Package                                      Arch
Version                                 Repository
Size
=========================================================================================================================================
Installing:
 ovirt-engine                                 noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            1.0
M
Installing for dependencies:
 apr-util                                     x86_64
1.4.1-2.fc17                            fedora                      78
k
 apr-util-ldap                                x86_64
1.4.1-2.fc17                            fedora                      17
k
 classpathx-mail                              noarch
1.1.2-4.fc17                            fedora                     413
k
 hibernate-commons-annotations                noarch
3.2.0-4.fc17                            fedora                      66
k
 httpd                                        x86_64
2.2.22-4.fc17                           fedora                     824
k
 httpd-tools                                  x86_64
2.2.22-4.fc17                           fedora                      75
k
 mod_ssl                                      x86_64
1:2.2.22-4.fc17                         fedora                      87
k
 ntp                                          x86_64
4.2.6p5-2.fc17                          fedora                     595
k
 ntpdate                                      x86_64
4.2.6p5-2.fc17                          fedora                      76
k
 ovirt-engine-backend                         noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            7.0
M
 ovirt-engine-config                          noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            130
k
 ovirt-engine-dbscripts                       noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            126
k
 ovirt-engine-genericapi                      noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             19
k
 ovirt-engine-notification-service            noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             52
k
 ovirt-engine-restapi                         noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            5.0
M
 ovirt-engine-sdk                             noarch
3.1.0.1-1alpha.fc17                     ovirt-engine-31            200
k
 ovirt-engine-setup                           noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            116
k
 ovirt-engine-tools-common                    noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            8.8
k
 ovirt-engine-userportal                      noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             13
M
 ovirt-engine-webadmin-portal                 noarch
3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             15
M
 ovirt-image-uploader                         noarch
3.1.0-0.git9c42c8.fc17                  ovirt-engine-31             92
k
 ovirt-iso-uploader                           noarch
3.1.0-0.git1841d9.fc17                  ovirt-engine-31             29
k
 ovirt-log-collector                          noarch
3.1.0-0.git10d719.fc17                  ovirt-engine-31             53
k
 yum-plugin-versionlock                       noarch
1.1.31-4.fc17                           fedora                      24
k

Transaction Summary
=========================================================================================================================================
Install  1 Package (+24 Dependent packages)


But now as I would like to update the system, I get this dependency,
probably not in ovirt repo itself but related to F17 perhaps:
$ sudo yum update
...
Error: Package: jboss-as-7.1.1-3.fc17.noarch (updates)
           Requires: apache-juddi
Error: Package: apache-scout-1.2.6-2.fc17.noarch (updates)
           Requires: apache-juddi

At this moment on my system
[g.cecchi at f17 ~]$ rpm -q jboss-as
jboss-as-7.1.1-2.fc17.noarch

On another F17 system I try

$ sudo yum install jboss-as
and I get the same dependency error.... so I think I have to open a
bugzilla with f17


From ovirt at qip.ru  Fri Jun  8 09:51:49 2012
From: ovirt at qip.ru (ovirt at qip.ru)
Date: Fri, 08 Jun 2012 13:51:49 +0400
Subject: [Engine-devel] =?utf-8?q?Ovirt_=C2=ADon_Fedora17?=
In-Reply-To: <CACK36mzdMv_QdEwhQN8WMXNYwMfxf9D4UfD7Cf0XZx9GkBG0Ow@mail.gmail.com>
References: <CACK36mzdMv_QdEwhQN8WMXNYwMfxf9D4UfD7Cf0XZx9GkBG0Ow@mail.gmail.com>
Message-ID: <51ec8f2c73f3fc96dbb84db867d73a22fb6960ce@mail.qip.ru>

+1

??? 08 ??? 2012 13:47:29 +0400, Gianluca Cecchi  ???????:
2012/6/8 Juan Hernandez wrote:

> If you want to help testing the upcoming 3.1 release, including the GUI,

> then it is better to use the latest alpha version, setting up an additional

> repository with a "ovirt-engine-31.repo" file in your "/etc/yum.repos.d"

> directory and the following content:

>

> [ovirt-engine-31]

> name=ovirt-engine-31

> baseurl=http://ovirt.org/releases/beta/fedora/17

> enabled=1

> gpgcheck=0

>

> Then install the engine with the following command:

>

> yum install ovirt-engine-3.1.0_0001

>

> If you find issues please let us know.

>

ok.

As two days ago I already installed ovirt-engine from f17 default

repo, I had to do these, due to dependency preoblems

[g.cecchi at f17 ~]$ sudo yum install ovirt-engine-3.1.0_0001

.

--> Finished Dependency Resolution

Error: Package: ovirt-engine-iso-uploader-3.0.0.0001-12.fc17.noarch (@fedora)

           Requires: ovirt-engine = 3.0.0.0001-12.fc17

           Removing: ovirt-engine-3.0.0.0001-12.fc17.noarch (@fedora)

               ovirt-engine = 3.0.0.0001-12.fc17

           Updated By: ovirt-engine-3.1.0_0001-0.gitf093e0.fc17.noarch

(ovirt-engine-31)

               ovirt-engine = 3.1.0_0001-0.gitf093e0.fc17

Error: Package: ovirt-engine-log-collector-3.0.0.0001-12.fc17.noarch (@fedora)

           Requires: ovirt-engine = 3.0.0.0001-12.fc17

           Removing: ovirt-engine-3.0.0.0001-12.fc17.noarch (@fedora)

               ovirt-engine = 3.0.0.0001-12.fc17

           Updated By: ovirt-engine-3.1.0_0001-0.gitf093e0.fc17.noarch

(ovirt-engine-31)

               ovirt-engine = 3.1.0_0001-0.gitf093e0.fc17

[g.cecchi at f17 ~]$ sudo yum remove

ovirt-engine-iso-uploader-3.0.0.0001-12.fc17.noarch

.

Dependencies Resolved

=========================================================================================================================================

 Package                                          Arch

 Version                             Repository              Size

=========================================================================================================================================

Removing:

 ovirt-engine-iso-uploader                        noarch

 3.0.0.0001-12.fc17                  @fedora                1.5 M

Removing for dependencies:

 ovirt-engine                                     noarch

 3.0.0.0001-12.fc17                  @fedora                1.2 M

 ovirt-engine-backend                             noarch

 3.0.0.0001-12.fc17                  @fedora                2.7 M

 ovirt-engine-config                              noarch

 3.0.0.0001-12.fc17                  @fedora                 27 k

 ovirt-engine-dbscripts                           noarch

 3.0.0.0001-12.fc17                  @fedora                482 k

 ovirt-engine-log-collector                       noarch

 3.0.0.0001-12.fc17                  @fedora                1.6 M

 ovirt-engine-notification-service                noarch

 3.0.0.0001-12.fc17                  @fedora                 64 k

 ovirt-engine-restapi                             noarch

 3.0.0.0001-12.fc17                  @fedora                772 k

 ovirt-engine-setup                               noarch

 3.0.0.0001-12.fc17                  @fedora                303 k

 ovirt-engine-tools-common                        noarch

 3.0.0.0001-12.fc17                  @fedora                8.8 k

Transaction Summary

=========================================================================================================================================

Remove  1 Package (+9 Dependent packages)

[g.cecchi at f17 ~]$ sudo yum install ovirt-engine-3.1.0_0001

..

Dependencies Resolved

=========================================================================================================================================

 Package                                      Arch

Version                                 Repository

Size

=========================================================================================================================================

Installing:

 ovirt-engine                                 noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            1.0

M

Installing for dependencies:

 apr-util                                     x86_64

1.4.1-2.fc17                            fedora                      78

k

 apr-util-ldap                                x86_64

1.4.1-2.fc17                            fedora                      17

k

 classpathx-mail                              noarch

1.1.2-4.fc17                            fedora                     413

k

 hibernate-commons-annotations                noarch

3.2.0-4.fc17                            fedora                      66

k

 httpd                                        x86_64

2.2.22-4.fc17                           fedora                     824

k

 httpd-tools                                  x86_64

2.2.22-4.fc17                           fedora                      75

k

 mod_ssl                                      x86_64

1:2.2.22-4.fc17                         fedora                      87

k

 ntp                                          x86_64

4.2.6p5-2.fc17                          fedora                     595

k

 ntpdate                                      x86_64

4.2.6p5-2.fc17                          fedora                      76

k

 ovirt-engine-backend                         noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            7.0

M

 ovirt-engine-config                          noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            130

k

 ovirt-engine-dbscripts                       noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            126

k

 ovirt-engine-genericapi                      noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             19

k

 ovirt-engine-notification-service            noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             52

k

 ovirt-engine-restapi                         noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            5.0

M

 ovirt-engine-sdk                             noarch

3.1.0.1-1alpha.fc17                     ovirt-engine-31            200

k

 ovirt-engine-setup                           noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            116

k

 ovirt-engine-tools-common                    noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            8.8

k

 ovirt-engine-userportal                      noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             13

M

 ovirt-engine-webadmin-portal                 noarch

3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             15

M

 ovirt-image-uploader                         noarch

3.1.0-0.git9c42c8.fc17                  ovirt-engine-31             92

k

 ovirt-iso-uploader                           noarch

3.1.0-0.git1841d9.fc17                  ovirt-engine-31             29

k

 ovirt-log-collector                          noarch

3.1.0-0.git10d719.fc17                  ovirt-engine-31             53

k

 yum-plugin-versionlock                       noarch

1.1.31-4.fc17                           fedora                      24

k

Transaction Summary

=========================================================================================================================================

Install  1 Package (+24 Dependent packages)

But now as I would like to update the system, I get this dependency,

probably not in ovirt repo itself but related to F17 perhaps:

$ sudo yum update

..

Error: Package: jboss-as-7.1.1-3.fc17.noarch (updates)

           Requires: apache-juddi

Error: Package: apache-scout-1.2.6-2.fc17.noarch (updates)

           Requires: apache-juddi

At this moment on my system

[g.cecchi at f17 ~]$ rpm -q jboss-as

jboss-as-7.1.1-2.fc17.noarch

On another F17 system I try

$ sudo yum install jboss-as

and I get the same dependency error.... so I think I have to open a

bugzilla with f17

_______________________________________________

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/20120608/3462b8a3/attachment.html>

From tekka at normantec.it  Fri Jun  8 09:57:27 2012
From: tekka at normantec.it (Gianluca Cecchi)
Date: Fri, 8 Jun 2012 11:57:27 +0200
Subject: [Engine-devel] Ovirt on Fedora17
In-Reply-To: <CACK36mzdMv_QdEwhQN8WMXNYwMfxf9D4UfD7Cf0XZx9GkBG0Ow@mail.gmail.com>
References: <CACK36mwzrUtCRgnTjJoRiq_RaHzNdRKNpyv7HT_TAYPj6vj8FA@mail.gmail.com>
	<4FD1C27A.3070303@redhat.com>
	<CACK36mzdMv_QdEwhQN8WMXNYwMfxf9D4UfD7Cf0XZx9GkBG0Ow@mail.gmail.com>
Message-ID: <CACK36myZ_Dstrem-OFe-boN3JCUhKSVE_u3YjArigzF01enEew@mail.gmail.com>

2012/6/8 Gianluca Cecchi <tekka at normantec.it>:

>
> On another F17 system I try
>
> $ sudo yum install jboss-as
> and I get the same dependency error.... so I think I have to open a
> bugzilla with f17

found bug
https://bugzilla.redhat.com/show_bug.cgi?id=830067
and
yum install apache-juddi --enablerepo=updates-testing
yum update

fixed the problem until apache-juddi lands on the stable repo...


From jhernand at redhat.com  Fri Jun  8 09:58:23 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Fri, 08 Jun 2012 11:58:23 +0200
Subject: [Engine-devel] Ovirt on Fedora17
In-Reply-To: <CACK36mzdMv_QdEwhQN8WMXNYwMfxf9D4UfD7Cf0XZx9GkBG0Ow@mail.gmail.com>
References: <CACK36mwzrUtCRgnTjJoRiq_RaHzNdRKNpyv7HT_TAYPj6vj8FA@mail.gmail.com>
	<4FD1C27A.3070303@redhat.com>
	<CACK36mzdMv_QdEwhQN8WMXNYwMfxf9D4UfD7Cf0XZx9GkBG0Ow@mail.gmail.com>
Message-ID: <4FD1CCBF.6080804@redhat.com>

On 06/08/2012 11:47 AM, Gianluca Cecchi wrote:
> 2012/6/8 Juan Hernandez wrote:
>> If you want to help testing the upcoming 3.1 release, including the GUI,
>> then it is better to use the latest alpha version, setting up an additional
>> repository with a "ovirt-engine-31.repo" file in your "/etc/yum.repos.d"
>> directory and the following content:
>>
>> [ovirt-engine-31]
>> name=ovirt-engine-31
>> baseurl=http://ovirt.org/releases/beta/fedora/17
>> enabled=1
>> gpgcheck=0
>>
>> Then install the engine with the following command:
>>
>> yum install ovirt-engine-3.1.0_0001
>>
>> If you find issues please let us know.
>>
>
> ok.
> As two days ago I already installed ovirt-engine from f17 default
> repo, I had to do these, due to dependency preoblems
>
> [g.cecchi at f17 ~]$ sudo yum install ovirt-engine-3.1.0_0001
> ..
> -->  Finished Dependency Resolution
> Error: Package: ovirt-engine-iso-uploader-3.0.0.0001-12.fc17.noarch (@fedora)
>             Requires: ovirt-engine = 3.0.0.0001-12.fc17
>             Removing: ovirt-engine-3.0.0.0001-12.fc17.noarch (@fedora)
>                 ovirt-engine = 3.0.0.0001-12.fc17
>             Updated By: ovirt-engine-3.1.0_0001-0.gitf093e0.fc17.noarch
> (ovirt-engine-31)
>                 ovirt-engine = 3.1.0_0001-0.gitf093e0.fc17
> Error: Package: ovirt-engine-log-collector-3.0.0.0001-12.fc17.noarch (@fedora)
>             Requires: ovirt-engine = 3.0.0.0001-12.fc17
>             Removing: ovirt-engine-3.0.0.0001-12.fc17.noarch (@fedora)
>                 ovirt-engine = 3.0.0.0001-12.fc17
>             Updated By: ovirt-engine-3.1.0_0001-0.gitf093e0.fc17.noarch
> (ovirt-engine-31)
>                 ovirt-engine = 3.1.0_0001-0.gitf093e0.fc17
>
> [g.cecchi at f17 ~]$ sudo yum remove
> ovirt-engine-iso-uploader-3.0.0.0001-12.fc17.noarch
> ..
> Dependencies Resolved
>
> =========================================================================================================================================
>   Package                                          Arch
>   Version                             Repository              Size
> =========================================================================================================================================
> Removing:
>   ovirt-engine-iso-uploader                        noarch
>   3.0.0.0001-12.fc17                  @fedora                1.5 M
> Removing for dependencies:
>   ovirt-engine                                     noarch
>   3.0.0.0001-12.fc17                  @fedora                1.2 M
>   ovirt-engine-backend                             noarch
>   3.0.0.0001-12.fc17                  @fedora                2.7 M
>   ovirt-engine-config                              noarch
>   3.0.0.0001-12.fc17                  @fedora                 27 k
>   ovirt-engine-dbscripts                           noarch
>   3.0.0.0001-12.fc17                  @fedora                482 k
>   ovirt-engine-log-collector                       noarch
>   3.0.0.0001-12.fc17                  @fedora                1.6 M
>   ovirt-engine-notification-service                noarch
>   3.0.0.0001-12.fc17                  @fedora                 64 k
>   ovirt-engine-restapi                             noarch
>   3.0.0.0001-12.fc17                  @fedora                772 k
>   ovirt-engine-setup                               noarch
>   3.0.0.0001-12.fc17                  @fedora                303 k
>   ovirt-engine-tools-common                        noarch
>   3.0.0.0001-12.fc17                  @fedora                8.8 k
>
> Transaction Summary
> =========================================================================================================================================
> Remove  1 Package (+9 Dependent packages)
>
>
> [g.cecchi at f17 ~]$ sudo yum install ovirt-engine-3.1.0_0001
> ...
> Dependencies Resolved
>
> =========================================================================================================================================
>   Package                                      Arch
> Version                                 Repository
> Size
> =========================================================================================================================================
> Installing:
>   ovirt-engine                                 noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            1.0
> M
> Installing for dependencies:
>   apr-util                                     x86_64
> 1.4.1-2.fc17                            fedora                      78
> k
>   apr-util-ldap                                x86_64
> 1.4.1-2.fc17                            fedora                      17
> k
>   classpathx-mail                              noarch
> 1.1.2-4.fc17                            fedora                     413
> k
>   hibernate-commons-annotations                noarch
> 3.2.0-4.fc17                            fedora                      66
> k
>   httpd                                        x86_64
> 2.2.22-4.fc17                           fedora                     824
> k
>   httpd-tools                                  x86_64
> 2.2.22-4.fc17                           fedora                      75
> k
>   mod_ssl                                      x86_64
> 1:2.2.22-4.fc17                         fedora                      87
> k
>   ntp                                          x86_64
> 4.2.6p5-2.fc17                          fedora                     595
> k
>   ntpdate                                      x86_64
> 4.2.6p5-2.fc17                          fedora                      76
> k
>   ovirt-engine-backend                         noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            7.0
> M
>   ovirt-engine-config                          noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            130
> k
>   ovirt-engine-dbscripts                       noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            126
> k
>   ovirt-engine-genericapi                      noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             19
> k
>   ovirt-engine-notification-service            noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             52
> k
>   ovirt-engine-restapi                         noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            5.0
> M
>   ovirt-engine-sdk                             noarch
> 3.1.0.1-1alpha.fc17                     ovirt-engine-31            200
> k
>   ovirt-engine-setup                           noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            116
> k
>   ovirt-engine-tools-common                    noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31            8.8
> k
>   ovirt-engine-userportal                      noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             13
> M
>   ovirt-engine-webadmin-portal                 noarch
> 3.1.0_0001-0.gitf093e0.fc17             ovirt-engine-31             15
> M
>   ovirt-image-uploader                         noarch
> 3.1.0-0.git9c42c8.fc17                  ovirt-engine-31             92
> k
>   ovirt-iso-uploader                           noarch
> 3.1.0-0.git1841d9.fc17                  ovirt-engine-31             29
> k
>   ovirt-log-collector                          noarch
> 3.1.0-0.git10d719.fc17                  ovirt-engine-31             53
> k
>   yum-plugin-versionlock                       noarch
> 1.1.31-4.fc17                           fedora                      24
> k
>
> Transaction Summary
> =========================================================================================================================================
> Install  1 Package (+24 Dependent packages)
>
>
> But now as I would like to update the system, I get this dependency,
> probably not in ovirt repo itself but related to F17 perhaps:
> $ sudo yum update
> ...
> Error: Package: jboss-as-7.1.1-3.fc17.noarch (updates)
>             Requires: apache-juddi
> Error: Package: apache-scout-1.2.6-2.fc17.noarch (updates)
>             Requires: apache-juddi
>
> At this moment on my system
> [g.cecchi at f17 ~]$ rpm -q jboss-as
> jboss-as-7.1.1-2.fc17.noarch
>
> On another F17 system I try
>
> $ sudo yum install jboss-as
> and I get the same dependency error.... so I think I have to open a
> bugzilla with f17

Yes, this looks like a but in Fedora. The apache-juddi should have been 
moved to stable before jboss-as-7.1.1-3. Meanwhile you can install 
version 7.1.1-2 of jboss-as:

yum install jboss-as-7.1.1-2

Or manually get and install the apache-juddi package from this URL:

http://kojipkgs.fedoraproject.org/packages/apache-juddi/3.1.3/3.fc17/noarch/apache-juddi-3.1.3-3.fc17.noarch.rpm

And if you want to speed up the process to move apache-juddi to stable 
(once you test it) please vote here:

https://admin.fedoraproject.org/updates/FEDORA-2012-8260/apache-juddi-3.1.3-3.fc17?_csrf_token=5577790d5b10df56243279ce6b20143c9e7077ee

-- 
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 berrange at redhat.com  Fri Jun  8 15:54:05 2012
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 8 Jun 2012 16:54:05 +0100
Subject: [Engine-devel] live migration and different technologies
In-Reply-To: <4FCF6619.2060701@redhat.com>
References: <4FCF6619.2060701@redhat.com>
Message-ID: <20120608155405.GW2289@redhat.com>

On Wed, Jun 06, 2012 at 05:15:53PM +0300, Itamar Heim wrote:
> Hi Daniel,
> 
> on the quantum-ovirt call today the question of live migration
> between multiple technologies was raised.
> 
> iirc, you implemented the abstraction in libvirt between what the
> guest sees and the actual host networking implementation for live
> migration.
> 
> can you please share if there are any considerations around live
> migrations across different network implementations (bridge, sr-iov,
> ovs, qbg, openflow, etc.)

Yes, we added the ability to use libvirt's 'virtual network' APIs
(virNetworkXXXXX) to define host networks using bridging, macvtap,
etc, etc. A guest's NICs can then be configured solely using
<interface type='network'>. This means that the guest XML will
not have any host-specific data in it, as you see when using
<interface type='bridge'> or <interface type='direct'>

This means you can migrate between machines where the bridges have
different names (eg br0 on host A and br7 on host B), without any
limitations.

You can also migrate between different impls of the same technology
(eg traditional software bridging vs macvtap bridging without
limitations.

Finally, you can migrate between completely different technologies
(eg bridging vs vepa), but you will likely loose connectivity in
the guests, since the technologies are not compatible at the ethernet
layer.

In summary, libvirt configuration ability should not be the limiting
factor in migrating between hosts with different networking config.
You should only be limited by the ethernet/kernel level compatibility.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


From shaohef at linux.vnet.ibm.com  Fri Jun  8 17:30:21 2012
From: shaohef at linux.vnet.ibm.com (ShaoHe Feng)
Date: Sat, 09 Jun 2012 01:30:21 +0800
Subject: [Engine-devel] [ovirt-engine-sdk] some questions about the
 params.py code generated by generateSD
In-Reply-To: <4FD0ED30.5010804@redhat.com>
References: <4FBE7A47.6090001@linux.vnet.ibm.com>
	<4FD0C538.1080001@linux.vnet.ibm.com> <4FD0ED30.5010804@redhat.com>
Message-ID: <4FD236AD.1090200@linux.vnet.ibm.com>

still a question.

I find  there are reduplicate items in _rootClassMap dictionary  of 
./src/ovirtsdk/xml/params.py file.
such as:
1.
in line 18924
                   "storage"                       : Storage,
in line 18931
                   "storage"                       : Storage,
above items has same key and value.

2.
in line 18905
                   "product_info"                  : ProductInfo,
in line 18934
                   "product_info"                  : ProductInfo,
above items has same key and value.

3.
  in line 18953
                     "vm_pause_details"              : VmPauseDetails,
  in line 18962
                     "vm_pause_detail"               : VmPauseDetails,

above items  has value but different key.

is it OK ? or should I commit  a patch to fix it?


On 06/08/2012 02:04 AM, Juan Hernandez wrote:
> On 06/07/2012 05:14 PM, ShaoHe Feng wrote:
>> Hi all,
>>
>> as we all know the current params.py was not completely by the
>> generateSD.py, there are parts that have to be updated manually.
>>
>> now I have post a primarypatch to improve it.
>> http://gerrit.ovirt.org/#/c/4880/
>>
>> it can generate some codes, but still two parts codes can not be 
>> generated.
>>
>> they aretwo dictionaries: _rootClassMap and _elementToClassMap.
>>
>> However, for I do get any clue to know these two dictionaries  from the
>> params.py.
>
> The reason for these dictionaries is that "generateDS.py" generates 
> classes for the complex types inside the API .xsd, but it doesn't 
> generate anything for the tags that can appear as root tags in the XML 
> documents used by the API. The map helps the parser find the classes 
> that correspond to each of those tags.
>
> It might be possible to generate this map from the list of classes 
> using a rule like this:
>
>   CamelCaseName -> camel_case_names
>
> But there are exceptions like these:
>
>   VLAN -> vlan
>   IPs  -> ips
>   IscsiDetails -> iscsi
>
> You could write code that takes into account the exceptions and 
> generates the map. But I think it is not worth, and error prone. I 
> would rather take that chunk of code out of params.py and move it to 
> an external file or to a constant, like you do for other chunks of 
> code in paramsconf.py.
>
>> there are some questions:
>> 1.
>> And the __all__ list  which include all the classes of _rootClassMap and
>> _elementToClassMap.
>> And there some classes  both in _rootClassMap and _elementToClassMap.
>
> The "__all__" list is just a python mechanism to control the symbols 
> that are imported when you do something like "from whatever import *". 
> In this case "generateDS.py" is making sure that all the generated 
> classes are imported, which is not really relevant for us.
>
>> 2.
>> And  some of class in _rootClassMap inherit GeneratedsSuper class, some
>> inherit BaseResource class, and two classes inherit Link class.
>> And it is the same with _elementToClassMap.
>>
>> so what is the difference between _rootClassMap and _elementToClassMap.
>> What rule to generate these two dictionaries.
>
> I can't find any difference between those two dictionaries, they serve 
> exactly the same purpose. Maybe Michael had a future use in mind.
>
>> 3.
>> And also, how to generate the keys in _rootClassMap and
>> _elementToClassMap.Any rule to generate them?
>>
>> there are some items in these two dictionaries
>>
>>                         "access_control_list"           :
>> AccessControlList,   #  "_" among the word in key
>>                         "api"                                    : API,
>>                         "body"                                 : Body,
>>                          "iscsi"                                 :
>> IscsiDetails,             # key "iscsi" is one part of value 
>> "IscsiDetails"
>>                         "storage_domain"                : StorageDomain,
>>                         "topology"                           : 
>> CpuTopology,
>>                         "creation_status"                  : Status, #
>> key has a more word  "creation"  than the value.
>>                         "parent"                                : 
>> TagParent
>
>
>



From iheim at redhat.com  Sat Jun  9 12:57:40 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sat, 09 Jun 2012 15:57:40 +0300
Subject: [Engine-devel] live migration and different technologies
In-Reply-To: <20120608155405.GW2289@redhat.com>
References: <4FCF6619.2060701@redhat.com> <20120608155405.GW2289@redhat.com>
Message-ID: <4FD34844.5030101@redhat.com>

On 06/08/2012 06:54 PM, Daniel P. Berrange wrote:
> On Wed, Jun 06, 2012 at 05:15:53PM +0300, Itamar Heim wrote:
>> Hi Daniel,
>>
>> on the quantum-ovirt call today the question of live migration
>> between multiple technologies was raised.
>>
>> iirc, you implemented the abstraction in libvirt between what the
>> guest sees and the actual host networking implementation for live
>> migration.
>>
>> can you please share if there are any considerations around live
>> migrations across different network implementations (bridge, sr-iov,
>> ovs, qbg, openflow, etc.)
>
> Yes, we added the ability to use libvirt's 'virtual network' APIs
> (virNetworkXXXXX) to define host networks using bridging, macvtap,
> etc, etc. A guest's NICs can then be configured solely using
> <interface type='network'>. This means that the guest XML will
> not have any host-specific data in it, as you see when using
> <interface type='bridge'>  or<interface type='direct'>
>
> This means you can migrate between machines where the bridges have
> different names (eg br0 on host A and br7 on host B), without any
> limitations.
>
> You can also migrate between different impls of the same technology
> (eg traditional software bridging vs macvtap bridging without
> limitations.
>
> Finally, you can migrate between completely different technologies
> (eg bridging vs vepa), but you will likely loose connectivity in
> the guests, since the technologies are not compatible at the ethernet
> layer.

can you please explain this point - how would packet going out of the 
host or arriving to the guest would be different between a bridged and a 
vepa implemtnaiton?

>
> In summary, libvirt configuration ability should not be the limiting
> factor in migrating between hosts with different networking config.
> You should only be limited by the ethernet/kernel level compatibility.
>
> Daniel



From mpastern at redhat.com  Sun Jun 10 06:49:52 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 10 Jun 2012 09:49:52 +0300
Subject: [Engine-devel] [ovirt-engine-sdk] some questions about the
 params.py code generated by generateSD
In-Reply-To: <4FD0C538.1080001@linux.vnet.ibm.com>
References: <4FBE7A47.6090001@linux.vnet.ibm.com>
	<4FD0C538.1080001@linux.vnet.ibm.com>
Message-ID: <4FD44390.7030209@redhat.com>


Hi,

On 06/07/2012 06:14 PM, ShaoHe Feng wrote:
> Hi all,
> 
> as we all know the current params.py was not completely by the generateSD.py,  there are parts that have to be updated manually.
> 
> now I have post a primarypatch to improve it. http://gerrit.ovirt.org/#/c/4880/
> 

(in review)

> it can generate some codes, but still two parts codes can not be generated.
> 
> they aretwo dictionaries: _rootClassMap and _elementToClassMap.
> 
> However, for I do get any clue to know these two dictionaries  from the params.py.
> 
> there are some questions:
> 1.
> And the __all__ list  which include all the classes of _rootClassMap and _elementToClassMap.
> And there some classes  both in _rootClassMap and _elementToClassMap.
> 
> 2.
> And  some of class in _rootClassMap inherit GeneratedsSuper class, some inherit BaseResource class, and two classes inherit Link class.
> And it is the same with _elementToClassMap.
> 
> so what is the difference between _rootClassMap and _elementToClassMap.
> What rule to generate these two dictionaries.

_elementToClassMap no longer relevant, you can place everything in _rootClassMap

> 
> 3.
> And also, how to generate the keys in _rootClassMap and _elementToClassMap.Any rule to generate them?

you can traverse all elements in the schema creating data structure where key is the type of the
schema element and value is the element name, for instance:

<xs:element name="special_objects" type="SpecialObjects"/>

_element_type_to_name_map {SpecialObjects, special_objects},

this way later when you go over items in __all__ [1] list, you can use each item as key
at _element_type_to_name_map to retrieve element name="special_objects".

[1] __all__ = [..., "SpecialObjects", ...]

> 
> there are some items in these two dictionaries
> 
>                       "access_control_list"           : AccessControlList,   #  "_" among the word in key
>                       "api"                                    : API,                        
>                       "body"                                 : Body,
>                        "iscsi"                                 : IscsiDetails,             # key "iscsi" is one part of value "IscsiDetails"
>                       "storage_domain"                : StorageDomain,
>                       "topology"                           : CpuTopology,         
>                       "creation_status"                  : Status,                  # key has a more word  "creation"  than the value.
>                       "parent"                                : TagParent
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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 Jun 10 06:57:02 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 10 Jun 2012 09:57:02 +0300
Subject: [Engine-devel] [ovirt-engine-sdk] some questions about the
 params.py code generated by generateSD
In-Reply-To: <4FD236AD.1090200@linux.vnet.ibm.com>
References: <4FBE7A47.6090001@linux.vnet.ibm.com>
	<4FD0C538.1080001@linux.vnet.ibm.com> <4FD0ED30.5010804@redhat.com>
	<4FD236AD.1090200@linux.vnet.ibm.com>
Message-ID: <4FD4453E.1030107@redhat.com>

On 06/08/2012 08:30 PM, ShaoHe Feng wrote:
> still a question.
> 
> I find  there are reduplicate items in _rootClassMap dictionary  of ./src/ovirtsdk/xml/params.py file.
> such as:
> 1.
> in line 18924
>                   "storage"                       : Storage,
> in line 18931
>                   "storage"                       : Storage,
> above items has same key and value.
> 
> 2.
> in line 18905
>                   "product_info"                  : ProductInfo,
> in line 18934
>                   "product_info"                  : ProductInfo,
> above items has same key and value.
> 
> 3.
>  in line 18953
>                     "vm_pause_details"              : VmPauseDetails,
>  in line 18962
>                     "vm_pause_detail"               : VmPauseDetails,
> 
> above items  has value but different key.
> 
> is it OK ? or should I commit  a patch to fix it?

should be single appearance of each element (it was handcrafted).

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From mkublin at redhat.com  Sun Jun 10 08:23:26 2012
From: mkublin at redhat.com (Michael Kublin)
Date: Sun, 10 Jun 2012 04:23:26 -0400 (EDT)
Subject: [Engine-devel] Do we need genericApi project?
In-Reply-To: <5651cfcf-8a8e-41bc-ab13-475e449cca4a@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <d8cedfdc-1f4a-4c28-8a0a-d9eebee6d0a9@zmail14.collab.prod.int.phx2.redhat.com>

Hi,

I found that we have a ovirt-engine/frontend/api/genericapi project, which is for my opinion is not at use any more.
If there are any reason that we want to keep it , maybe someone using it and I missed these?

Thanks Michael


From yzaslavs at redhat.com  Sun Jun 10 08:49:51 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Sun, 10 Jun 2012 11:49:51 +0300
Subject: [Engine-devel] Do we need genericApi project?
In-Reply-To: <d8cedfdc-1f4a-4c28-8a0a-d9eebee6d0a9@zmail14.collab.prod.int.phx2.redhat.com>
References: <d8cedfdc-1f4a-4c28-8a0a-d9eebee6d0a9@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD45FAF.2070906@redhat.com>

On 06/10/2012 11:23 AM, Michael Kublin wrote:
> Hi,
> 
> I found that we have a ovirt-engine/frontend/api/genericapi project, which is for my opinion is not at use any more.
> If there are any reason that we want to keep it , maybe someone using it and I missed these?

IIUC, this was served in order to create a SOAP web service to server
our clients.
I also don't see a reason why we should continue and use this - All GWT
based code does not use this (it uses GenericApiGWTServiceImpl to
communicate with engine, which injects the EJB bean of Backend).
This class as an obselete field of genericAPIService, which is no longer
being injected (so a fix should be done at GWT side as well).

Yair

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



From iheim at redhat.com  Sun Jun 10 08:48:53 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 10 Jun 2012 11:48:53 +0300
Subject: [Engine-devel] Do we need genericApi project?
In-Reply-To: <d8cedfdc-1f4a-4c28-8a0a-d9eebee6d0a9@zmail14.collab.prod.int.phx2.redhat.com>
References: <d8cedfdc-1f4a-4c28-8a0a-d9eebee6d0a9@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD45F75.20905@redhat.com>

On 06/10/2012 11:23 AM, Michael Kublin wrote:
> Hi,
>
> I found that we have a ovirt-engine/frontend/api/genericapi project, which is for my opinion is not at use any more.
> If there are any reason that we want to keep it , maybe someone using it and I missed these?
>
> Thanks Michael
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

iirc, it's intended to allow to add queries needed for the UI without 
adding them into the core.
and looking at GetUserActionGroups, I see it is used for example by 
uicommon.

(GWT still uses the generic api)


From gchaplik at redhat.com  Sun Jun 10 09:08:50 2012
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Sun, 10 Jun 2012 05:08:50 -0400 (EDT)
Subject: [Engine-devel] Do we need genericApi project?
In-Reply-To: <4FD45F75.20905@redhat.com>
Message-ID: <d5397dd9-1e5a-4a53-90e3-cf834aba138f@zmail14.collab.prod.int.phx2.redhat.com>

we don't use GetUserActionGroups (it's an unreachable code - can be deleted), IMHO we can remove the project.

Thanks, 
Gilad.

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, June 10, 2012 11:48:53 AM
> Subject: Re: [Engine-devel] Do we need genericApi project?
> 
> On 06/10/2012 11:23 AM, Michael Kublin wrote:
> > Hi,
> >
> > I found that we have a ovirt-engine/frontend/api/genericapi
> > project, which is for my opinion is not at use any more.
> > If there are any reason that we want to keep it , maybe someone
> > using it and I missed these?
> >
> > Thanks Michael
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> iirc, it's intended to allow to add queries needed for the UI without
> adding them into the core.
> and looking at GetUserActionGroups, I see it is used for example by
> uicommon.
> 
> (GWT still uses the generic api)
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From derez at redhat.com  Sun Jun 10 09:33:17 2012
From: derez at redhat.com (Daniel Erez)
Date: Sun, 10 Jun 2012 05:33:17 -0400 (EDT)
Subject: [Engine-devel] Do we need genericApi project?
In-Reply-To: <4FD45F75.20905@redhat.com>
Message-ID: <1af3e959-aa21-4d3f-8108-39408f95ba38@zmail14.collab.prod.int.phx2.redhat.com>

We may want to wait for the removal of the deprecated uicommon project (which is in use by the old UserPortal).
uicommonweb doesn't use UiQueries any more (it's not depended on the genericapi project) - so I think it can be removed.


----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, June 10, 2012 11:48:53 AM
> Subject: Re: [Engine-devel] Do we need genericApi project?
> 
> On 06/10/2012 11:23 AM, Michael Kublin wrote:
> > Hi,
> >
> > I found that we have a ovirt-engine/frontend/api/genericapi
> > project, which is for my opinion is not at use any more.
> > If there are any reason that we want to keep it , maybe someone
> > using it and I missed these?
> >
> > Thanks Michael
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> iirc, it's intended to allow to add queries needed for the UI without
> adding them into the core.
> and looking at GetUserActionGroups, I see it is used for example by
> uicommon.
> 
> (GWT still uses the generic api)
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From iheim at redhat.com  Sun Jun 10 09:44:08 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 10 Jun 2012 12:44:08 +0300
Subject: [Engine-devel] Do we need genericApi project?
In-Reply-To: <1af3e959-aa21-4d3f-8108-39408f95ba38@zmail14.collab.prod.int.phx2.redhat.com>
References: <1af3e959-aa21-4d3f-8108-39408f95ba38@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD46C68.3030300@redhat.com>

On 06/10/2012 12:33 PM, Daniel Erez wrote:
> We may want to wait for the removal of the deprecated uicommon project (which is in use by the old UserPortal).
> uicommonweb doesn't use UiQueries any more (it's not depended on the genericapi project) - so I think it can be removed.

I'd wait to see it really isn't needed any more.
it was added to cover a gap in which the UI is using logic which exists 
in methods in the business entities (IsLinux/IsWindows/Is64bit, etc.)

which is something we wanted to decouple, and the UI queries expose 
these as queries for the UI rather than use the entities directly.

so i'd say this still isn't fully utilized, rather than deprecated.

>
>
> ----- Original Message -----
>> From: "Itamar Heim"<iheim at redhat.com>
>> To: "Michael Kublin"<mkublin at redhat.com>
>> Cc: "engine-devel"<engine-devel at ovirt.org>
>> Sent: Sunday, June 10, 2012 11:48:53 AM
>> Subject: Re: [Engine-devel] Do we need genericApi project?
>>
>> On 06/10/2012 11:23 AM, Michael Kublin wrote:
>>> Hi,
>>>
>>> I found that we have a ovirt-engine/frontend/api/genericapi
>>> project, which is for my opinion is not at use any more.
>>> If there are any reason that we want to keep it , maybe someone
>>> using it and I missed these?
>>>
>>> Thanks Michael
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> iirc, it's intended to allow to add queries needed for the UI without
>> adding them into the core.
>> and looking at GetUserActionGroups, I see it is used for example by
>> uicommon.
>>
>> (GWT still uses the generic api)
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From mkublin at redhat.com  Sun Jun 10 12:47:22 2012
From: mkublin at redhat.com (Michael Kublin)
Date: Sun, 10 Jun 2012 08:47:22 -0400 (EDT)
Subject: [Engine-devel] Do we need genericApi project?
In-Reply-To: <4FD46C68.3030300@redhat.com>
Message-ID: <035d6460-154f-417d-a5ec-1bab03183ee5@zmail14.collab.prod.int.phx2.redhat.com>

At least meanwhile, can I disable loading of GenericApiService bean during start up of jboss?

----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: "Daniel Erez" <derez at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>, "Michael Kublin" <mkublin at redhat.com>
Sent: Sunday, June 10, 2012 12:44:08 PM
Subject: Re: [Engine-devel] Do we need genericApi project?

On 06/10/2012 12:33 PM, Daniel Erez wrote:
> We may want to wait for the removal of the deprecated uicommon project (which is in use by the old UserPortal).
> uicommonweb doesn't use UiQueries any more (it's not depended on the genericapi project) - so I think it can be removed.

I'd wait to see it really isn't needed any more.
it was added to cover a gap in which the UI is using logic which exists 
in methods in the business entities (IsLinux/IsWindows/Is64bit, etc.)

which is something we wanted to decouple, and the UI queries expose 
these as queries for the UI rather than use the entities directly.

so i'd say this still isn't fully utilized, rather than deprecated.

>
>
> ----- Original Message -----
>> From: "Itamar Heim"<iheim at redhat.com>
>> To: "Michael Kublin"<mkublin at redhat.com>
>> Cc: "engine-devel"<engine-devel at ovirt.org>
>> Sent: Sunday, June 10, 2012 11:48:53 AM
>> Subject: Re: [Engine-devel] Do we need genericApi project?
>>
>> On 06/10/2012 11:23 AM, Michael Kublin wrote:
>>> Hi,
>>>
>>> I found that we have a ovirt-engine/frontend/api/genericapi
>>> project, which is for my opinion is not at use any more.
>>> If there are any reason that we want to keep it , maybe someone
>>> using it and I missed these?
>>>
>>> Thanks Michael
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>> iirc, it's intended to allow to add queries needed for the UI without
>> adding them into the core.
>> and looking at GetUserActionGroups, I see it is used for example by
>> uicommon.
>>
>> (GWT still uses the generic api)
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>



From mpastern at redhat.com  Sun Jun 10 13:18:14 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 10 Jun 2012 16:18:14 +0300
Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks
	collection
Message-ID: <4FD49E96.5050000@redhat.com>


IIUC originally this collection was suppose to keep all disks
that can be shared between different vms and/or available to be
attached to certain vm.

At the moment this collection contains all disks in system while
engine does not provide any search capabilities for it,

in my view it not really useful, till we add search capabilities
for being able:

1. locate <shareable>true</shareable> disks
2. distinguish between <shareable>true|false</shareable> and <active>true|false</active>
   disks
3. maybe even worth taking <active>false</active>&&<shareable>false</shareable>
   out of this collection and place them under api/clusters/xxx/disks (or under DC).
   this way /api/disks will only have disks that can be shared.

your thoughts?

-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From ofrenkel at redhat.com  Sun Jun 10 14:11:15 2012
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 10 Jun 2012 10:11:15 -0400 (EDT)
Subject: [Engine-devel] RESTAPI: what is the purpose for
	/api/disks	collection
In-Reply-To: <4FD49E96.5050000@redhat.com>
Message-ID: <8e4069e5-5aba-44cc-91b0-f720d28bda97@zmail07.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, June 10, 2012 4:18:14 PM
> Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks	collection
> 
> 
> IIUC originally this collection was suppose to keep all disks
> that can be shared between different vms and/or available to be
> attached to certain vm.
> 
> At the moment this collection contains all disks in system while
> engine does not provide any search capabilities for it,
>

I'm pretty sure there is search for disks, or i misunderstood you,
but you can run search query to get disks by alias and so.
 
> in my view it not really useful, till we add search capabilities
> for being able:
> 
> 1. locate <shareable>true</shareable> disks

this is available. 

> 2. distinguish between <shareable>true|false</shareable> and
> <active>true|false</active>
>    disks
> 3. maybe even worth taking
> <active>false</active>&&<shareable>false</shareable>
>    out of this collection and place them under api/clusters/xxx/disks
>    (or under DC).
>    this way /api/disks will only have disks that can be shared.
> 
> your thoughts?
> 

active is not a property of a disk, but a vm-disk, as unattached floating disks has no meaning of active.
so maybe its place is unders /api/vms/xxx/disks (IIRC its already there)

> --
> 
> 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 mpastern at redhat.com  Sun Jun 10 14:27:10 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 10 Jun 2012 17:27:10 +0300
Subject: [Engine-devel] RESTAPI: what is the purpose for
	/api/disks	collection
In-Reply-To: <8e4069e5-5aba-44cc-91b0-f720d28bda97@zmail07.collab.prod.int.phx2.redhat.com>
References: <8e4069e5-5aba-44cc-91b0-f720d28bda97@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD4AEBE.3000605@redhat.com>

On 06/10/2012 05:11 PM, Omer Frenkel wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, June 10, 2012 4:18:14 PM
>> Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks	collection
>>
>>
>> IIUC originally this collection was suppose to keep all disks
>> that can be shared between different vms and/or available to be
>> attached to certain vm.
>>
>> At the moment this collection contains all disks in system while
>> engine does not provide any search capabilities for it,
>>
> 
> I'm pretty sure there is search for disks, or i misunderstood you,
> but you can run search query to get disks by alias and so.

it is implemented with VdcQueryType.GetAllDisks not search.

>  
>> in my view it not really useful, till we add search capabilities
>> for being able:
>>
>> 1. locate <shareable>true</shareable> disks
> 
> this is available. 
> 
>> 2. distinguish between <shareable>true|false</shareable> and
>> <active>true|false</active>
>>    disks
>> 3. maybe even worth taking
>> <active>false</active>&&<shareable>false</shareable>
>>    out of this collection and place them under api/clusters/xxx/disks
>>    (or under DC).
>>    this way /api/disks will only have disks that can be shared.
>>
>> your thoughts?
>>
> 
> active is not a property of a disk, but a vm-disk, as unattached floating disks has no meaning of active.
> so maybe its place is unders /api/vms/xxx/disks (IIRC its already there),

it there, but also in same time it's under /api/disks (while <active>true</active>),
so my question is how can you know if 'floating disk' is available to be attach to
different vm?

> 
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> 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 ofrenkel at redhat.com  Sun Jun 10 14:30:26 2012
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 10 Jun 2012 10:30:26 -0400 (EDT)
Subject: [Engine-devel] RESTAPI: what is the purpose for
	/api/disks	collection
In-Reply-To: <4FD4AEBE.3000605@redhat.com>
Message-ID: <f4f717ac-7d2e-47fc-8dc1-93d0afe8ee1c@zmail07.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, June 10, 2012 5:27:10 PM
> Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks	collection
> 
> On 06/10/2012 05:11 PM, Omer Frenkel wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Sunday, June 10, 2012 4:18:14 PM
> >> Subject: [Engine-devel] RESTAPI: what is the purpose for
> >> /api/disks	collection
> >>
> >>
> >> IIUC originally this collection was suppose to keep all disks
> >> that can be shared between different vms and/or available to be
> >> attached to certain vm.
> >>
> >> At the moment this collection contains all disks in system while
> >> engine does not provide any search capabilities for it,
> >>
> > 
> > I'm pretty sure there is search for disks, or i misunderstood you,
> > but you can run search query to get disks by alias and so.
> 
> it is implemented with VdcQueryType.GetAllDisks not search.
> 

you can also use VdcQueryType.Search with SearchType.Disk (as in any other object search)

> >  
> >> in my view it not really useful, till we add search capabilities
> >> for being able:
> >>
> >> 1. locate <shareable>true</shareable> disks
> > 
> > this is available.
> > 
> >> 2. distinguish between <shareable>true|false</shareable> and
> >> <active>true|false</active>
> >>    disks
> >> 3. maybe even worth taking
> >> <active>false</active>&&<shareable>false</shareable>
> >>    out of this collection and place them under
> >>    api/clusters/xxx/disks
> >>    (or under DC).
> >>    this way /api/disks will only have disks that can be shared.
> >>
> >> your thoughts?
> >>
> > 
> > active is not a property of a disk, but a vm-disk, as unattached
> > floating disks has no meaning of active.
> > so maybe its place is unders /api/vms/xxx/disks (IIRC its already
> > there),
> 
> it there, but also in same time it's under /api/disks (while
> <active>true</active>),
> so my question is how can you know if 'floating disk' is available to
> be attach to
> different vm?

if the disk is floating, for sure it is available to be attached.

> 
> > 
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >> _______________________________________________
> >> 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 Jun 10 15:30:53 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 10 Jun 2012 18:30:53 +0300
Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks
	collection
In-Reply-To: <f4f717ac-7d2e-47fc-8dc1-93d0afe8ee1c@zmail07.collab.prod.int.phx2.redhat.com>
References: <f4f717ac-7d2e-47fc-8dc1-93d0afe8ee1c@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD4BDAD.9040901@redhat.com>

On 06/10/2012 05:30 PM, Omer Frenkel wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Omer Frenkel" <ofrenkel at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, June 10, 2012 5:27:10 PM
>> Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks	collection
>>
>> On 06/10/2012 05:11 PM, Omer Frenkel wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Sunday, June 10, 2012 4:18:14 PM
>>>> Subject: [Engine-devel] RESTAPI: what is the purpose for
>>>> /api/disks	collection
>>>>
>>>>
>>>> IIUC originally this collection was suppose to keep all disks
>>>> that can be shared between different vms and/or available to be
>>>> attached to certain vm.
>>>>
>>>> At the moment this collection contains all disks in system while
>>>> engine does not provide any search capabilities for it,
>>>>
>>>
>>> I'm pretty sure there is search for disks, or i misunderstood you,
>>> but you can run search query to get disks by alias and so.
>>
>> it is implemented with VdcQueryType.GetAllDisks not search.
>>
> 
> you can also use VdcQueryType.Search with SearchType.Disk (as in any other object search)

Ori, is there any special reason for /disks collection been
implemented via query rather than VdcQueryType.Search?

> 
>>>  
>>>> in my view it not really useful, till we add search capabilities
>>>> for being able:
>>>>
>>>> 1. locate <shareable>true</shareable> disks
>>>
>>> this is available.
>>>
>>>> 2. distinguish between <shareable>true|false</shareable> and
>>>> <active>true|false</active>
>>>>    disks
>>>> 3. maybe even worth taking
>>>> <active>false</active>&&<shareable>false</shareable>
>>>>    out of this collection and place them under
>>>>    api/clusters/xxx/disks
>>>>    (or under DC).
>>>>    this way /api/disks will only have disks that can be shared.
>>>>
>>>> your thoughts?
>>>>
>>>
>>> active is not a property of a disk, but a vm-disk, as unattached
>>> floating disks has no meaning of active.
>>> so maybe its place is unders /api/vms/xxx/disks (IIRC its already
>>> there),
>>
>> it there, but also in same time it's under /api/disks (while
>> <active>true</active>),
>> so my question is how can you know if 'floating disk' is available to
>> be attach to
>> different vm?
> 
> if the disk is floating, for sure it is available to be attached.

from the feature page [1] "Any virtual disk can be in a floating state - by unattaching the disk from the VM/s. ",
or "Floating disk - a disk that is not attached to any VM." from [2],

so if disk attached to vm - it's "not floating" right? if so why it appear in /disks?,
i think root collection /disks should contain only items available for common usage.
(can't see any point in showing private vm disks there (such as not-shareable && not-floating))

[1] http://www.ovirt.org/wiki/Features/FloatingDisk
[2] http://www.ovirt.org/wiki/Features/DetailedFloatingDisk,

> 
>>
>>>
>>>> --
>>>>
>>>> Michael Pasternak
>>>> RedHat, ENG-Virtualization R&D
>>>> _______________________________________________
>>>> Engine-devel mailing list
>>>> Engine-devel at ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From ofrenkel at redhat.com  Sun Jun 10 15:35:30 2012
From: ofrenkel at redhat.com (Omer Frenkel)
Date: Sun, 10 Jun 2012 11:35:30 -0400 (EDT)
Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks
	collection
In-Reply-To: <4FD4BDAD.9040901@redhat.com>
Message-ID: <b9fb4881-347a-486a-a41d-013f631eb828@zmail07.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Michael Pasternak" <mpastern at redhat.com>
> To: "Ori Liel" <oliel at redhat.com>
> Cc: "Omer Frenkel" <ofrenkel at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Sent: Sunday, June 10, 2012 6:30:53 PM
> Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
> 
> On 06/10/2012 05:30 PM, Omer Frenkel wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Michael Pasternak" <mpastern at redhat.com>
> >> To: "Omer Frenkel" <ofrenkel at redhat.com>
> >> Cc: "engine-devel" <engine-devel at ovirt.org>
> >> Sent: Sunday, June 10, 2012 5:27:10 PM
> >> Subject: Re: [Engine-devel] RESTAPI: what is the purpose for
> >> /api/disks	collection
> >>
> >> On 06/10/2012 05:11 PM, Omer Frenkel wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Michael Pasternak" <mpastern at redhat.com>
> >>>> To: "engine-devel" <engine-devel at ovirt.org>
> >>>> Sent: Sunday, June 10, 2012 4:18:14 PM
> >>>> Subject: [Engine-devel] RESTAPI: what is the purpose for
> >>>> /api/disks	collection
> >>>>
> >>>>
> >>>> IIUC originally this collection was suppose to keep all disks
> >>>> that can be shared between different vms and/or available to be
> >>>> attached to certain vm.
> >>>>
> >>>> At the moment this collection contains all disks in system while
> >>>> engine does not provide any search capabilities for it,
> >>>>
> >>>
> >>> I'm pretty sure there is search for disks, or i misunderstood
> >>> you,
> >>> but you can run search query to get disks by alias and so.
> >>
> >> it is implemented with VdcQueryType.GetAllDisks not search.
> >>
> > 
> > you can also use VdcQueryType.Search with SearchType.Disk (as in
> > any other object search)
> 
> Ori, is there any special reason for /disks collection been
> implemented via query rather than VdcQueryType.Search?
> 
> > 
> >>>  
> >>>> in my view it not really useful, till we add search capabilities
> >>>> for being able:
> >>>>
> >>>> 1. locate <shareable>true</shareable> disks
> >>>
> >>> this is available.
> >>>
> >>>> 2. distinguish between <shareable>true|false</shareable> and
> >>>> <active>true|false</active>
> >>>>    disks
> >>>> 3. maybe even worth taking
> >>>> <active>false</active>&&<shareable>false</shareable>
> >>>>    out of this collection and place them under
> >>>>    api/clusters/xxx/disks
> >>>>    (or under DC).
> >>>>    this way /api/disks will only have disks that can be shared.
> >>>>
> >>>> your thoughts?
> >>>>
> >>>
> >>> active is not a property of a disk, but a vm-disk, as unattached
> >>> floating disks has no meaning of active.
> >>> so maybe its place is unders /api/vms/xxx/disks (IIRC its already
> >>> there),
> >>
> >> it there, but also in same time it's under /api/disks (while
> >> <active>true</active>),
> >> so my question is how can you know if 'floating disk' is available
> >> to
> >> be attach to
> >> different vm?
> > 
> > if the disk is floating, for sure it is available to be attached.
> 
> from the feature page [1] "Any virtual disk can be in a floating
> state - by unattaching the disk from the VM/s. ",
> or "Floating disk - a disk that is not attached to any VM." from [2],
>

correct
 
> so if disk attached to vm - it's "not floating" right? 

right

> if so why it
> appear in /disks?,
> i think root collection /disks should contain only items available
> for common usage.
> (can't see any point in showing private vm disks there (such as
> not-shareable && not-floating))
>

well i guess its a way of looking at it, 
personally i think that there is no reason blocking data from the user,
let the user decide if he would like to see all disks, or filter it with a simple query.
 
you mentioned common usage,
private templates also return in /templates, no? no one can use them but one user.
maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage
(probably not so good example but just trying to say don't hide info from the users,
you don't know all the use cases)


> [1] http://www.ovirt.org/wiki/Features/FloatingDisk
> [2] http://www.ovirt.org/wiki/Features/DetailedFloatingDisk,
> 
> > 
> >>
> >>>
> >>>> --
> >>>>
> >>>> Michael Pasternak
> >>>> RedHat, ENG-Virtualization R&D
> >>>> _______________________________________________
> >>>> Engine-devel mailing list
> >>>> Engine-devel at ovirt.org
> >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>
> >>
> >>
> >> --
> >>
> >> Michael Pasternak
> >> RedHat, ENG-Virtualization R&D
> >>
> 
> 
> --
> 
> Michael Pasternak
> RedHat, ENG-Virtualization R&D
> 


From mpastern at redhat.com  Sun Jun 10 15:58:58 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 10 Jun 2012 18:58:58 +0300
Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks
	collection
In-Reply-To: <b9fb4881-347a-486a-a41d-013f631eb828@zmail07.collab.prod.int.phx2.redhat.com>
References: <b9fb4881-347a-486a-a41d-013f631eb828@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD4C442.4060003@redhat.com>

On 06/10/2012 06:35 PM, Omer Frenkel wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Ori Liel" <oliel at redhat.com>
>> Cc: "Omer Frenkel" <ofrenkel at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, June 10, 2012 6:30:53 PM
>> Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks collection
>>
>> On 06/10/2012 05:30 PM, Omer Frenkel wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> To: "Omer Frenkel" <ofrenkel at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Sunday, June 10, 2012 5:27:10 PM
>>>> Subject: Re: [Engine-devel] RESTAPI: what is the purpose for
>>>> /api/disks	collection
>>>>
>>>> On 06/10/2012 05:11 PM, Omer Frenkel wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>>> Sent: Sunday, June 10, 2012 4:18:14 PM
>>>>>> Subject: [Engine-devel] RESTAPI: what is the purpose for
>>>>>> /api/disks	collection
>>>>>>
>>>>>>
>>>>>> IIUC originally this collection was suppose to keep all disks
>>>>>> that can be shared between different vms and/or available to be
>>>>>> attached to certain vm.
>>>>>>
>>>>>> At the moment this collection contains all disks in system while
>>>>>> engine does not provide any search capabilities for it,
>>>>>>
>>>>>
>>>>> I'm pretty sure there is search for disks, or i misunderstood
>>>>> you,
>>>>> but you can run search query to get disks by alias and so.
>>>>
>>>> it is implemented with VdcQueryType.GetAllDisks not search.
>>>>
>>>
>>> you can also use VdcQueryType.Search with SearchType.Disk (as in
>>> any other object search)
>>
>> Ori, is there any special reason for /disks collection been
>> implemented via query rather than VdcQueryType.Search?
>>
>>>
>>>>>  
>>>>>> in my view it not really useful, till we add search capabilities
>>>>>> for being able:
>>>>>>
>>>>>> 1. locate <shareable>true</shareable> disks
>>>>>
>>>>> this is available.
>>>>>
>>>>>> 2. distinguish between <shareable>true|false</shareable> and
>>>>>> <active>true|false</active>
>>>>>>    disks
>>>>>> 3. maybe even worth taking
>>>>>> <active>false</active>&&<shareable>false</shareable>
>>>>>>    out of this collection and place them under
>>>>>>    api/clusters/xxx/disks
>>>>>>    (or under DC).
>>>>>>    this way /api/disks will only have disks that can be shared.
>>>>>>
>>>>>> your thoughts?
>>>>>>
>>>>>
>>>>> active is not a property of a disk, but a vm-disk, as unattached
>>>>> floating disks has no meaning of active.
>>>>> so maybe its place is unders /api/vms/xxx/disks (IIRC its already
>>>>> there),
>>>>
>>>> it there, but also in same time it's under /api/disks (while
>>>> <active>true</active>),
>>>> so my question is how can you know if 'floating disk' is available
>>>> to
>>>> be attach to
>>>> different vm?
>>>
>>> if the disk is floating, for sure it is available to be attached.
>>
>> from the feature page [1] "Any virtual disk can be in a floating
>> state - by unattaching the disk from the VM/s. ",
>> or "Floating disk - a disk that is not attached to any VM." from [2],
>>
> 
> correct
>  
>> so if disk attached to vm - it's "not floating" right? 
> 
> right
> 
>> if so why it
>> appear in /disks?,
>> i think root collection /disks should contain only items available
>> for common usage.
>> (can't see any point in showing private vm disks there (such as
>> not-shareable && not-floating))
>>
> 
> well i guess its a way of looking at it, 

right

> personally i think that there is no reason blocking data from the user,
> let the user decide if he would like to see all disks, or filter it with a simple query.
>  
> you mentioned common usage,
> private templates also return in /templates, no? no one can use them but one user.
> maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage
> (probably not so good example but just trying to say don't hide info from the users,
> you don't know all the use cases)

i guess this is not about hiding, but about saving "too much information" from the user,

the main difference with /templates is amount of data, cause when you have N templates
in system and N*K vms and N*K*Q disks, it's too much data, so if part of this data is
not relevant, i'd like to be able not showing it,

query-parameter maybe good way to filter out disks not available for common usage,
this way we can emulate "extended" results (the default will be reduced and i will
expose matrix-parameter for this collection to see all disks)

p.s about /templates example, previously we had only admin-api,
and admins should be able seeing everything), now when we will support user-api,
no user will see private template unless he has permit on it.


> 
> 
>> [1] http://www.ovirt.org/wiki/Features/FloatingDisk
>> [2] http://www.ovirt.org/wiki/Features/DetailedFloatingDisk,
>>
>>>
>>>>
>>>>>
>>>>>> --
>>>>>>
>>>>>> Michael Pasternak
>>>>>> RedHat, ENG-Virtualization R&D
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Michael Pasternak
>>>> RedHat, ENG-Virtualization R&D
>>>>
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From iheim at redhat.com  Sun Jun 10 15:52:22 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 10 Jun 2012 18:52:22 +0300
Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks
	collection
In-Reply-To: <b9fb4881-347a-486a-a41d-013f631eb828@zmail07.collab.prod.int.phx2.redhat.com>
References: <b9fb4881-347a-486a-a41d-013f631eb828@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD4C2B6.1080502@redhat.com>

On 06/10/2012 06:35 PM, Omer Frenkel wrote:
>> >  if so why it
>> >  appear in /disks?,
>> >  i think root collection /disks should contain only items available
>> >  for common usage.
>> >  (can't see any point in showing private vm disks there (such as
>> >  not-shareable&&  not-floating))

i don't think it makes sense a disk will go away to a user from /disks 
once it was attached, etc.
why not show here all disks?

>> >
> well i guess its a way of looking at it,
> personally i think that there is no reason blocking data from the user,
> let the user decide if he would like to see all disks, or filter it with a simple query.
>
> you mentioned common usage,
> private templates also return in /templates, no? no one can use them but one user.
> maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage
> (probably not so good example but just trying to say don't hide info from the users,
> you don't know all the use cases)
>
>

not sure this is the same:
private template will not show to a user without relevant permissions 
via the user api.
admin api shows all objects, hence the private template as well.


From mpastern at redhat.com  Sun Jun 10 16:09:01 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Sun, 10 Jun 2012 19:09:01 +0300
Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks
	collection
In-Reply-To: <4FD4C2B6.1080502@redhat.com>
References: <b9fb4881-347a-486a-a41d-013f631eb828@zmail07.collab.prod.int.phx2.redhat.com>
	<4FD4C2B6.1080502@redhat.com>
Message-ID: <4FD4C69D.7020701@redhat.com>

On 06/10/2012 06:52 PM, Itamar Heim wrote:
> On 06/10/2012 06:35 PM, Omer Frenkel wrote:
>>> >  if so why it
>>> >  appear in /disks?,
>>> >  i think root collection /disks should contain only items available
>>> >  for common usage.
>>> >  (can't see any point in showing private vm disks there (such as
>>> >  not-shareable&&  not-floating))
> 
> i don't think it makes sense a disk will go away to a user from /disks once it was attached, etc.

it's exactly the behaviour i'd like to achieve (only disks available for common usage shown),
if you attached it to vm X and want detach it, go to vm/xx/disks/yy and detach it there,

(btw if we want support showing all disks in /disks, we should have link
from the disk->vm it attached to.)


> why not show here all disks?

the use-case is client-side filtering, in sdk i provide this capability where
it's not supported by ovirt-search (such as property based filtering etc.),
getting big chunk of not relevant data, is show-stopper for this feature.

in my other email, i suggested adding search-parameter for being able requesting
extended list, while the default should be reduced.

> 
>>> >
>> well i guess its a way of looking at it,
>> personally i think that there is no reason blocking data from the user,
>> let the user decide if he would like to see all disks, or filter it with a simple query.
>>
>> you mentioned common usage,
>> private templates also return in /templates, no? no one can use them but one user.
>> maybe im the storage guy, and my 'usage' in the disks tab is to see how people are handling disks and storage
>> (probably not so good example but just trying to say don't hide info from the users,
>> you don't know all the use cases)
>>
>>
> 
> not sure this is the same:
> private template will not show to a user without relevant permissions via the user api.
> admin api shows all objects, hence the private template as well.


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From abaron at redhat.com  Sun Jun 10 20:49:44 2012
From: abaron at redhat.com (Ayal Baron)
Date: Sun, 10 Jun 2012 16:49:44 -0400 (EDT)
Subject: [Engine-devel] RESTAPI: what is the purpose for
	/api/disks	collection
In-Reply-To: <4FD4C69D.7020701@redhat.com>
Message-ID: <17fb49af-8283-4e19-9550-260198fe68c8@zmail13.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On 06/10/2012 06:52 PM, Itamar Heim wrote:
> > On 06/10/2012 06:35 PM, Omer Frenkel wrote:
> >>> >  if so why it
> >>> >  appear in /disks?,
> >>> >  i think root collection /disks should contain only items
> >>> >  available
> >>> >  for common usage.
> >>> >  (can't see any point in showing private vm disks there (such
> >>> >  as
> >>> >  not-shareable&&  not-floating))
> > 
> > i don't think it makes sense a disk will go away to a user from
> > /disks once it was attached, etc.
> 
> it's exactly the behaviour i'd like to achieve (only disks available
> for common usage shown),
> if you attached it to vm X and want detach it, go to vm/xx/disks/yy
> and detach it there,
> 
> (btw if we want support showing all disks in /disks, we should have
> link
> from the disk->vm it attached to.)
> 
> 
> > why not show here all disks?
> 
> the use-case is client-side filtering, in sdk i provide this
> capability where
> it's not supported by ovirt-search (such as property based filtering
> etc.),
> getting big chunk of not relevant data, is show-stopper for this
> feature.

I totally disagree here.
First of all define 'not relevant data'.
A shareable disk can be already attached to a VM so should it or should it not be shown here? (obviously it should).

Now I want to mark a disk as shareable and attach to another VM so I need to go first to the VM where it happens to currently reside, change it then go to the general collection and attach to another VM?

I have a read only disk with movies (or whatever other type of data) on it, I don't care which vm it is currently attached to, I want to move it to a different vm now, so you'd make it mandatory for me to know which VM it is now attached to?

It is so simple to do a for list in client side script that would filter according to whatever parameter user wants and the use cases vary so widely I see no reason to filter whatsoever
Even if I have thousands of disks it would be fast to iterate over, it might be more convenient if I can filter server side, but show-stopper?

> 
> in my other email, i suggested adding search-parameter for being able
> requesting
> extended list, while the default should be reduced.

why only according to attached? why not according to other parameters? (raw/qcow2/qcow2V3 disks, disks with actual size >= 1TB, etc)

> 
> > 
> >>> >
> >> well i guess its a way of looking at it,
> >> personally i think that there is no reason blocking data from the
> >> user,
> >> let the user decide if he would like to see all disks, or filter
> >> it with a simple query.
> >>
> >> you mentioned common usage,
> >> private templates also return in /templates, no? no one can use
> >> them but one user.
> >> maybe im the storage guy, and my 'usage' in the disks tab is to
> >> see how people are handling disks and storage
> >> (probably not so good example but just trying to say don't hide
> >> info from the users,
> >> you don't know all the use cases)
> >>
> >>
> > 
> > not sure this is the same:
> > private template will not show to a user without relevant
> > permissions via the user api.
> > admin api shows all objects, hence the private template as well.
> 
> 
> --
> 
> 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 mpastern at redhat.com  Mon Jun 11 06:57:55 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 11 Jun 2012 09:57:55 +0300
Subject: [Engine-devel] RESTAPI: what is the purpose for
	/api/disks	collection
In-Reply-To: <17fb49af-8283-4e19-9550-260198fe68c8@zmail13.collab.prod.int.phx2.redhat.com>
References: <17fb49af-8283-4e19-9550-260198fe68c8@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD596F3.3050002@redhat.com>

On 06/10/2012 11:49 PM, Ayal Baron wrote:
> 
> 
> ----- Original Message -----
>> On 06/10/2012 06:52 PM, Itamar Heim wrote:
>>> On 06/10/2012 06:35 PM, Omer Frenkel wrote:
>>>>>>  if so why it
>>>>>>  appear in /disks?,
>>>>>>  i think root collection /disks should contain only items
>>>>>>  available
>>>>>>  for common usage.
>>>>>>  (can't see any point in showing private vm disks there (such
>>>>>>  as
>>>>>>  not-shareable&&  not-floating))
>>>
>>> i don't think it makes sense a disk will go away to a user from
>>> /disks once it was attached, etc.
>>
>> it's exactly the behaviour i'd like to achieve (only disks available
>> for common usage shown),
>> if you attached it to vm X and want detach it, go to vm/xx/disks/yy
>> and detach it there,
>>
>> (btw if we want support showing all disks in /disks, we should have
>> link
>> from the disk->vm it attached to.)
>>
>>
>>> why not show here all disks?
>>
>> the use-case is client-side filtering, in sdk i provide this
>> capability where
>> it's not supported by ovirt-search (such as property based filtering
>> etc.),
>> getting big chunk of not relevant data, is show-stopper for this
>> feature.
> 
> I totally disagree here.
> First of all define 'not relevant data'.

i did, - disks that are not available for common usage (not shareable/not floating)

> A shareable disk can be already attached to a VM so should it or should it not be shown here? (obviously it should).

based on told above - yes.

> 
> Now I want to mark a disk as shareable and attach to another VM so I need to go first to the VM where it happens to currently reside, change it 

yes (if you not requested full collection), otherwise how will you choose the disk? by name? - who told that this name
unique in collection ?...,

doing that on concrete vm is less 'error prone' (agree with me that sharing wrong disk won't be nice ...)

> then go to the general collection and attach to another VM?

or just took this disk representation and POST it to this /another vm/ disks collection,
attach action is modelled as POST {disk} /api/vms/xxx/disks
(same is true for general disks collection)

> 
> I have a read only disk with movies (or whatever other type of data) on it, I don't care which vm it is currently attached to, I want to move it to a different vm now, so you'd make it mandatory for me to know which VM it is now attached to?

what do you mean by /mandatory/? i think you confusing, it's not parameter for the attach action ...
engine should be able telling admin to what vms shareable disk currently attached, otherwise
how admin can detach it? from where? (detach is action on /api/vms/xxx/disks/yyy)

> 
> It is so simple to do a for list in client side script that would filter according to whatever parameter user wants and the use cases vary so widely I see no reason to filter whatsoever
> Even if I have thousands of disks it would be fast to iterate over, 

true, iterating over is very fast, but you forgetting few tying things: marshalling/unmarshalling + transfer,

1. marshal thousands disks from java to xml
2. trasfer thousands disks over the wire
3. unmarshal thousands disks from xml to python
4. engine returns results in portions of 300, so you have to do four calls
   to engine in order to do this.

that's true that it's not exactly show-stopper, but it still not scalable.

> it might be more convenient if I can filter server side, but show-stopper?
> 
>>
>> in my other email, i suggested adding search-parameter for being able
>> requesting
>> extended list, while the default should be reduced.
> 
> why only according to attached? why not according to other parameters? (raw/qcow2/qcow2V3 disks, disks with actual size >= 1TB, etc)

this should be handled by search engine, we talking here about disks
that's are not usable from user perspective.

> 
>>
>>>
>>>>>>
>>>> well i guess its a way of looking at it,
>>>> personally i think that there is no reason blocking data from the
>>>> user,
>>>> let the user decide if he would like to see all disks, or filter
>>>> it with a simple query.
>>>>
>>>> you mentioned common usage,
>>>> private templates also return in /templates, no? no one can use
>>>> them but one user.
>>>> maybe im the storage guy, and my 'usage' in the disks tab is to
>>>> see how people are handling disks and storage
>>>> (probably not so good example but just trying to say don't hide
>>>> info from the users,
>>>> you don't know all the use cases)
>>>>
>>>>
>>>
>>> not sure this is the same:
>>> private template will not show to a user without relevant
>>> permissions via the user api.
>>> admin api shows all objects, hence the private template as well.
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> 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 amureini at redhat.com  Mon Jun 11 07:41:44 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Mon, 11 Jun 2012 03:41:44 -0400 (EDT)
Subject: [Engine-devel] Testing queries
In-Reply-To: <7b8d6372-03a5-427b-8722-118b2b713441@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <83f813ed-2745-4e69-8c8c-a2258636eb46@zmail17.collab.prod.int.phx2.redhat.com>

Hi guys,

following some questions from last week regarding writing unit-tests for query objects, I whipped up this quick wiki page:
http://ovirt.org/wiki/Testing_Queries


Enjoy,
Allon


From jhenner at redhat.com  Mon Jun 11 09:10:02 2012
From: jhenner at redhat.com (Jaroslav Henner)
Date: Mon, 11 Jun 2012 11:10:02 +0200
Subject: [Engine-devel] Does RHEVM/Ovirt API violates the stateless
	requriement of REST?
Message-ID: <4FD5B5EA.8000100@redhat.com>

Hi.

I think the fact that when updating (PUT), we may send only the updated 
xml elements violates following.

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

------8<------8<------8<------8<------
Figure 5-2: The client-server style
5.1.3 Stateless

We next add a constraint to the client-server interaction: communication 
must be stateless in nature, as in the client-stateless-server (CSS) 
style of Section 3.4.3 (Figure 5-3), such that each request from client 
to server must contain all of the information necessary to understand 
the request, and cannot take advantage of any stored context on the 
server. Session state is therefore kept entirely on the client.
------8<------8<------8<------8<------

Am I right? If so, this is quite huge violation. Much much bigger than 
some state of SESSION_ID/TOKEN. Would caches/proxies work well with 
current design?

Jaroslav Henner.


From mpastern at redhat.com  Mon Jun 11 09:31:51 2012
From: mpastern at redhat.com (Michael Pasternak)
Date: Mon, 11 Jun 2012 12:31:51 +0300
Subject: [Engine-devel] Does RHEVM/Ovirt API violates the stateless
	requriement of REST?
In-Reply-To: <4FD5B5EA.8000100@redhat.com>
References: <4FD5B5EA.8000100@redhat.com>
Message-ID: <4FD5BB07.6020904@redhat.com>

On 06/11/2012 12:10 PM, Jaroslav Henner wrote:
> Hi.
> 
> I think the fact that when updating (PUT), we may send only the updated xml elements violates following.
> 
> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
> 
> ------8<------8<------8<------8<------
> Figure 5-2: The client-server style
> 5.1.3 Stateless
> 
> We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure
> 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context
> on the server. Session state is therefore kept entirely on the client.
> ------8<------8<------8<------8<------
> 
> Am I right? If so, this is quite huge violation. Much much bigger than some state of SESSION_ID/TOKEN. Would caches/proxies work well with current design?

No, you're not, the meaning of /stateless/ is that client send in request all info
needed for server to process this request,

and that's exactly what happens on PUT, the fact that we using PATCH as
PUT extension (e.g we send only elements that we want to be updated),
not violets REST /stateless/ concept in any way.

> 
> Jaroslav Henner.


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D


From berrange at redhat.com  Mon Jun 11 09:47:16 2012
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 11 Jun 2012 10:47:16 +0100
Subject: [Engine-devel] live migration and different technologies
In-Reply-To: <4FD34844.5030101@redhat.com>
References: <4FCF6619.2060701@redhat.com> <20120608155405.GW2289@redhat.com>
	<4FD34844.5030101@redhat.com>
Message-ID: <20120611094716.GB8233@redhat.com>

On Sat, Jun 09, 2012 at 03:57:40PM +0300, Itamar Heim wrote:
> On 06/08/2012 06:54 PM, Daniel P. Berrange wrote:
> >On Wed, Jun 06, 2012 at 05:15:53PM +0300, Itamar Heim wrote:
> >>Hi Daniel,
> >>
> >>on the quantum-ovirt call today the question of live migration
> >>between multiple technologies was raised.
> >>
> >>iirc, you implemented the abstraction in libvirt between what the
> >>guest sees and the actual host networking implementation for live
> >>migration.
> >>
> >>can you please share if there are any considerations around live
> >>migrations across different network implementations (bridge, sr-iov,
> >>ovs, qbg, openflow, etc.)
> >
> >Yes, we added the ability to use libvirt's 'virtual network' APIs
> >(virNetworkXXXXX) to define host networks using bridging, macvtap,
> >etc, etc. A guest's NICs can then be configured solely using
> ><interface type='network'>. This means that the guest XML will
> >not have any host-specific data in it, as you see when using
> ><interface type='bridge'>  or<interface type='direct'>
> >
> >This means you can migrate between machines where the bridges have
> >different names (eg br0 on host A and br7 on host B), without any
> >limitations.
> >
> >You can also migrate between different impls of the same technology
> >(eg traditional software bridging vs macvtap bridging without
> >limitations.
> >
> >Finally, you can migrate between completely different technologies
> >(eg bridging vs vepa), but you will likely loose connectivity in
> >the guests, since the technologies are not compatible at the ethernet
> >layer.
> 
> can you please explain this point - how would packet going out of
> the host or arriving to the guest would be different between a
> bridged and a vepa implemtnaiton?

I'm not the expert on VEPA - I'm just relaying what I have been told
wrt VEPA modes in the past.

IIUC, with VEPA modes there is quite alot of extra traffic due to a
handshake negotiation between the host & switch, before any guest
traffic can pass, and there needs to be a special synchronization
done with VEPA during migration to maintain state in the switch.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


From danken at redhat.com  Mon Jun 11 12:41:38 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Mon, 11 Jun 2012 15:41:38 +0300
Subject: [Engine-devel] live migration and different technologies
In-Reply-To: <20120611094716.GB8233@redhat.com>
References: <4FCF6619.2060701@redhat.com> <20120608155405.GW2289@redhat.com>
	<4FD34844.5030101@redhat.com> <20120611094716.GB8233@redhat.com>
Message-ID: <20120611124137.GL9656@redhat.com>

On Mon, Jun 11, 2012 at 10:47:16AM +0100, Daniel P. Berrange wrote:
> On Sat, Jun 09, 2012 at 03:57:40PM +0300, Itamar Heim wrote:
> > On 06/08/2012 06:54 PM, Daniel P. Berrange wrote:
> > >On Wed, Jun 06, 2012 at 05:15:53PM +0300, Itamar Heim wrote:
> > >>Hi Daniel,
> > >>
> > >>on the quantum-ovirt call today the question of live migration
> > >>between multiple technologies was raised.
> > >>
> > >>iirc, you implemented the abstraction in libvirt between what the
> > >>guest sees and the actual host networking implementation for live
> > >>migration.
> > >>
> > >>can you please share if there are any considerations around live
> > >>migrations across different network implementations (bridge, sr-iov,
> > >>ovs, qbg, openflow, etc.)
> > >
> > >Yes, we added the ability to use libvirt's 'virtual network' APIs
> > >(virNetworkXXXXX) to define host networks using bridging, macvtap,
> > >etc, etc. A guest's NICs can then be configured solely using
> > ><interface type='network'>. This means that the guest XML will
> > >not have any host-specific data in it, as you see when using
> > ><interface type='bridge'>  or<interface type='direct'>
> > >
> > >This means you can migrate between machines where the bridges have
> > >different names (eg br0 on host A and br7 on host B), without any
> > >limitations.
> > >
> > >You can also migrate between different impls of the same technology
> > >(eg traditional software bridging vs macvtap bridging without
> > >limitations.
> > >
> > >Finally, you can migrate between completely different technologies
> > >(eg bridging vs vepa), but you will likely loose connectivity in
> > >the guests, since the technologies are not compatible at the ethernet
> > >layer.
> > 
> > can you please explain this point - how would packet going out of
> > the host or arriving to the guest would be different between a
> > bridged and a vepa implemtnaiton?
> 
> I'm not the expert on VEPA - I'm just relaying what I have been told
> wrt VEPA modes in the past.
> 
> IIUC, with VEPA modes there is quite alot of extra traffic due to a
> handshake negotiation between the host & switch, before any guest
> traffic can pass, and there needs to be a special synchronization
> done with VEPA during migration to maintain state in the switch.

But at least on the libvirt level, <virtualport> tags are ignored if a
domain is migrated from Qbsomething to a bridge?

I suppose that a default <virtualport> tag cannot be generated, so
migration from bridge to Qb* is impossible without the source tweaking
the destinationxml?


From oliel at redhat.com  Mon Jun 11 12:55:32 2012
From: oliel at redhat.com (Ori Liel)
Date: Mon, 11 Jun 2012 08:55:32 -0400 (EDT)
Subject: [Engine-devel] RESTAPI: what is the purpose for /api/disks
	collection
In-Reply-To: <4FD4BDAD.9040901@redhat.com>
Message-ID: <9e233a9e-3aa1-40b5-ace1-d44bdb82c278@zmail17.collab.prod.int.phx2.redhat.com>

>On 06/10/2012 05:30 PM, Omer Frenkel wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>> To: "Omer Frenkel" <ofrenkel at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>> Sent: Sunday, June 10, 2012 5:27:10 PM
>>> Subject: Re: [Engine-devel] RESTAPI: what is the purpose for /api/disks        collection
>>>
>>> On 06/10/2012 05:11 PM, Omer Frenkel wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>> Sent: Sunday, June 10, 2012 4:18:14 PM
>>>>> Subject: [Engine-devel] RESTAPI: what is the purpose for
>>>>> /api/disks        collection
>>>>>
>>>>>
>>>>> IIUC originally this collection was suppose to keep all disks
>>>>> that can be shared between different vms and/or available to be
>>>>> attached to certain vm.
>>>>>
>>>>> At the moment this collection contains all disks in system while
>>>>> engine does not provide any search capabilities for it,
>>>>>
>>>>
>>>> I'm pretty sure there is search for disks, or i misunderstood you,
>>>> but you can run search query to get disks by alias and so.
>>>
>>> it is implemented with VdcQueryType.GetAllDisks not search.
>>>
>>
>> you can also use VdcQueryType.Search with SearchType.Disk (as in any other object search)
>
>Ori, is there any special reason for /disks collection been
>implemented via query rather than VdcQueryType.Search?

I believe I thought at the time that it's not supported. 
I'll open a code-change to use search.

>
>>
>>>>  
>>>>> in my view it not really useful, till we add search capabilities
>>>>> for being able:
>>>>>
>>>>> 1. locate <shareable>true</shareable> disks
>>>>
>>>> this is available.
>>>>
>>>>> 2. distinguish between <shareable>true|false</shareable> and
>>>>> <active>true|false</active>
>>>>>    disks
>>>>> 3. maybe even worth taking
>>>>> <active>false</active>&&<shareable>false</shareable>
>>>>>    out of this collection and place them under
>>>>>    api/clusters/xxx/disks
>>>>>    (or under DC).
>>>>>    this way /api/disks will only have disks that can be shared.
>>>>>
>>>>> your thoughts?
>>>>>
>>>>
>>>> active is not a property of a disk, but a vm-disk, as unattached
>>>> floating disks has no meaning of active.
>>>> so maybe its place is unders /api/vms/xxx/disks (IIRC its already
>>>> there),
>>>
>>> it there, but also in same time it's under /api/disks (while
>>> <active>true</active>),
>>> so my question is how can you know if 'floating disk' is available to
>>> be attach to
>>> different vm?
>>
>> if the disk is floating, for sure it is available to be attached.
>
>from the feature page [1] "Any virtual disk can be in a floating state - by unattaching the disk from the VM/s. ",
>or "Floating disk - a disk that is not attached to any VM." from [2],
>
>so if disk attached to vm - it's "not floating" right? if so why it appear in /disks?,
>i think root collection /disks should contain only items available for common usage.
>(can't see any point in showing private vm disks there (such as not-shareable && not-floating))
>
>[1] http://www.ovirt.org/wiki/Features/FloatingDisk
>[2] http://www.ovirt.org/wiki/Features/DetailedFloatingDisk,
>
>>
>>>
>>>>
>>>>> --
>>>>>
>>>>> Michael Pasternak
>>>>> RedHat, ENG-Virtualization R&D
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>
>>>
>>> --
>>>
>>> Michael Pasternak
>>> RedHat, ENG-Virtualization R&D
>>>
>
>
>-- 
>
>Michael Pasternak
>RedHat, ENG-Virtualization R&D


From ecohen at redhat.com  Tue Jun 12 05:09:07 2012
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 12 Jun 2012 01:09:07 -0400 (EDT)
Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup
In-Reply-To: <4FCE0465.4040506@redhat.com>
Message-ID: <32f1d27d-a845-44c5-b140-6e202d5e681f@zmail04.collab.prod.int.phx2.redhat.com>

> ----- Original Message -----
> From: "Keith Robertson" <kroberts at redhat.com>
> Sent: Tuesday, June 5, 2012 4:06:45 PM
> 
> On 06/05/2012 08:03 AM, Ayal Baron wrote:
> >> -------- Original Message --------
> >> Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup
> >> Date: Mon, 21 May 2012 06:34:32 -0400 (EDT)
> >> From: Einav Cohen<ecohen at redhat.com>
> >> To: Ayal Baron<abaron at redhat.com>, Eldan Hildesheim
> >> <ehildesh at redhat.com>,        Eldan Hildesheim<info at eldanet.com>,
> >>     Miki Kenneth<mkenneth at redhat.com>,        Andrew Cathrow
> >> <acathrow at redhat.com>,        Simon Grinberg<sgrinber at redhat.com>,
> >> Alexey Chub<achub at redhat.com>
> >> CC: engine-devel at ovirt.org
> >>
> >> Please review the mock-up on the feature page:
> >> http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience
> > Sorry, I just saw this.
> > The advanced features should be in an advanced tab (not easily
> > accessible) in general I'd like to discourage users from changing
> > these params.
> I agree with this.  Have an "Advanced Options" button or something
> that
> will display these options.  Default state should be hidden.  It
> could
> get really ugly if the user starts mucking around with options like
> (r,
> hard, and sync).
> 
> The reason I say this is that the default settings for NFS should be
> sufficient in the majority of cases.  Further, you would think that
> the
> NFS maintainers carefully selected and tested the default option set
> for
> a variety of scenarios, I'd be hesitant to make it easy to override
> them
> unless there is a ground swell of NFS problems.

Mock-ups updated - you can review them at: 
http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience

[You are welcome to suggest a better phrasing for the default-advanced-nfs-options-values-change warning.
Current one is: "It is recommended to keep the default values in the fields below unchanged"]


> 
> Most of the NFS problems that I've seen are related to server-side
> permissions and cannot be resolved by the client.
> > not sure what mount options is as it is not supported for NFS.
> >
> >> Comments are welcome.
> >>
> >> ----
> >> Thanks,
> >> Einav
> >> _______________________________________________
> >> 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 iheim at redhat.com  Tue Jun 12 06:56:30 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 12 Jun 2012 09:56:30 +0300
Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup
In-Reply-To: <32f1d27d-a845-44c5-b140-6e202d5e681f@zmail04.collab.prod.int.phx2.redhat.com>
References: <32f1d27d-a845-44c5-b140-6e202d5e681f@zmail04.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD6E81E.8080707@redhat.com>

On 06/12/2012 08:09 AM, Einav Cohen wrote:
> Mock-ups updated - you can review them at:
> http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience
>
> [You are welcome to suggest a better phrasing for the default-advanced-nfs-options-values-change warning.
> Current one is: "It is recommended to keep the default values in the fields below unchanged"]

I thought time out was discussed on the relevant patch to be in same 
units (tenth of seconds) as what users would copy from their mount options:

timeo=n
The time (in tenths of a second) the NFS client waits for a response 
before it retries an NFS request. If this option  is  not  specified, 
requests  are  retried  every 60 seconds for NFS over TCP.  The NFS 
client does not perform any kind of timeout backoff for NFS
over TCP.


From ecohen at redhat.com  Tue Jun 12 07:40:14 2012
From: ecohen at redhat.com (Einav Cohen)
Date: Tue, 12 Jun 2012 03:40:14 -0400 (EDT)
Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup
In-Reply-To: <4FD6E81E.8080707@redhat.com>
Message-ID: <6bede54d-c514-4b79-b1fe-acdb9d3fded2@zmail04.collab.prod.int.phx2.redhat.com>

> ----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> Sent: Tuesday, June 12, 2012 9:56:30 AM
> 
> On 06/12/2012 08:09 AM, Einav Cohen wrote:
> > Mock-ups updated - you can review them at:
> > http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#User_Experience
> >
> > [You are welcome to suggest a better phrasing for the
> > default-advanced-nfs-options-values-change warning.
> > Current one is: "It is recommended to keep the default values in
> > the fields below unchanged"]
> 
> I thought time out was discussed on the relevant patch to be in same
> units (tenth of seconds) as what users would copy from their mount
> options:

correct. mock-up updated.

> 
> timeo=n
> The time (in tenths of a second) the NFS client waits for a response
> before it retries an NFS request. If this option  is  not  specified,
> requests  are  retried  every 60 seconds for NFS over TCP.  The NFS
> client does not perform any kind of timeout backoff for NFS
> over TCP.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> 
> 


From eedri at redhat.com  Tue Jun 12 08:01:44 2012
From: eedri at redhat.com (Eyal Edri)
Date: Tue, 12 Jun 2012 04:01:44 -0400 (EDT)
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_dao_unit_tests -
	Build # 1208 - Still Failing!
In-Reply-To: <1668834140.701339487252857.JavaMail.jenkins@ip-10-114-123-188>
Message-ID: <13363838-3d8f-4116-a9b1-85bb5fcd6ab7@zmail17.collab.prod.int.phx2.redhat.com>

Hi,

It seems commit [sesubram] engine: Adding brick order to Gluster volume bricks added new failed dao test:

org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest.testReplaceBrick
> 
> Error Message:
> Required input parameter 'v_new_brick_dir' is missing

Can you please check?

Eyal Edri
oVirt Infra Team.


----- 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, mkolesni at redhat.com
> Sent: Tuesday, June 12, 2012 10:47:31 AM
> Subject: [oVirt Jenkins] ovirt_engine_dao_unit_tests - Build # 1208 - Still Failing!
> 
> Project: http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/
> Build: http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/1208/
> Build Number: 1208
> Build Status:  Still Failing
> Triggered By: Started by upstream project "ovirt_engine" build number
> 1,611, Started by upstream project "ovirt_engine" build number
> 1,612, Started by upstream project "ovirt_engine" build number 1,613
> 
> -------------------------------------
> Changes Since Last Success:
> -------------------------------------
> Changes for Build #1191
> [mkublin] core: Disable global transaction at InitVdsOnUp
> 
> [sesubram] engine: Adding brick order to Gluster volume bricks
> 
> 
> Changes for Build #1192
> 
> Changes for Build #1193
> [dgopal] restapi: Gluster Volume Bricks resource implementation
> 
> 
> Changes for Build #1194
> [kmayilsa] engine: Skipping Cluster CPU validation in GlusterOnly
> mode
> 
> [kmayilsa] engine: Removing default transport type in volume(#830495)
> 
> 
> Changes for Build #1195
> [derez] webadmin: display SD status in Storage sub-tab
> 
> [derez] webadmin: Differentiate Virtual/Actual size in disks
> 
> 
> Changes for Build #1196
> 
> Changes for Build #1197
> 
> Changes for Build #1198
> [emesika] core: VMs created by vmpool fail to run(#830789)
> 
> [sesubram] engine: upgrade sql file name sequence number issue fix
> 
> 
> Changes for Build #1199
> 
> Changes for Build #1200
> 
> Changes for Build #1201
> [gchaplik] webadmin: removing uicommon from build (pom)
> 
> 
> Changes for Build #1202
> 
> Changes for Build #1203
> [ecohen] ui: fix naming to oVirt Engine
> 
> 
> Changes for Build #1204
> 
> Changes for Build #1205
> 
> Changes for Build #1206
> 
> Changes for Build #1207
> [yzaslavs] core: Adding new MLA related functions
> 
> [yzaslavs] core: Adding new methods at RoleDAO
> 
> [yzaslavs] common: Introducing groupIds property to VdcUser
> 
> [yzaslavs] core: Preventing adding unauthorized users
> 
> 
> Changes for Build #1208
> [oliel] restapi: RSDL - Fix meta-data of some collections
> 
> [mkolesni] core: Handle correct NIC ID from OVF (#827061)
> 
> 
> 
> 
> -----------------
> Failed Tests:
> -----------------
> 1 tests failed.
> FAILED:
>  org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest.testReplaceBrick
> 
> Error Message:
> Required input parameter 'v_new_brick_dir' is missing
> 
> Stack Trace:
> org.springframework.dao.InvalidDataAccessApiUsageException: Required
> input parameter 'v_new_brick_dir' is missing
> 	at
> 	org.springframework.jdbc.core.CallableStatementCreatorFactory$CallableStatementCreatorImpl.createCallableStatement(CallableStatementCreatorFactory.java:210)
> 	at
> 	org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:930)
> 	at
> 	org.springframework.jdbc.core.JdbcTemplate.call(JdbcTemplate.java:985)
> 	at
> 	org.springframework.jdbc.core.simple.AbstractJdbcCall.executeCallInternal(AbstractJdbcCall.java:368)
> 	at
> 	org.springframework.jdbc.core.simple.AbstractJdbcCall.doExecute(AbstractJdbcCall.java:342)
> 	at
> 	org.springframework.jdbc.core.simple.SimpleJdbcCall.execute(SimpleJdbcCall.java:164)
> 	at
> 	org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeImpl(SimpleJdbcCallsHandler.java:124)
> 	at
> 	org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeModification(SimpleJdbcCallsHandler.java:37)
> 	at
> 	org.ovirt.engine.core.dao.gluster.GlusterBrickDaoDbFacadeImpl.replaceBrick(GlusterBrickDaoDbFacadeImpl.java:34)
> 	at
> 	org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest.testReplaceBrick(GlusterBrickDaoTest.java:74)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at
> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at
> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at
> 	org.springframework.test.context.junit4.SpringTestMethod.invoke(SpringTestMethod.java:160)
> 	at
> 	org.springframework.test.context.junit4.SpringMethodRoadie.runTestMethod(SpringMethodRoadie.java:233)
> 	at
> 	org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:333)
> 	at
> 	org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217)
> 	at
> 	org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197)
> 	at
> 	org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143)
> 	at
> 	org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160)
> 	at
> 	org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> 	at
> 	org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> 	at
> 	org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> 	at
> 	org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> 	at
> 	org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> 	at
> 	org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
> 	at
> 	org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> 	at
> 	org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> 	at
> 	org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at
> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at
> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	at
> 	org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> 	at
> 	org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> 	at
> 	org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> 	at
> 	org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> 	at
> 	org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
> 
> 
>  
> 
> ------------------
> Build Log:
> ------------------
> [...truncated 2719 lines...]
> [INFO] Encryption Libraries .............................. SUCCESS
> [2.368s]
> [INFO] oVirt Tools ....................................... SUCCESS
> [0.633s]
> [INFO] oVirt Tools Common Library ........................ SUCCESS
> [2.004s]
> [INFO] Common Code ....................................... SUCCESS
> [26.839s]
> [INFO] Common utilities .................................. SUCCESS
> [9.096s]
> [INFO] Data Access Layer ................................. SUCCESS
> [14.694s]
> [INFO] engine beans ...................................... SUCCESS
> [0.122s]
> [INFO] engine scheduler bean ............................. SUCCESS
> [8.457s]
> [INFO] Vds broker ........................................ SUCCESS
> [10.079s]
> [INFO] Search Backend .................................... SUCCESS
> [8.950s]
> [INFO] Backend Logic @Service bean ....................... SUCCESS
> [33.705s]
> [INFO] oVirt RESTful API Backend Integration ............. SUCCESS
> [0.621s]
> [INFO] oVirt RESTful API interface ....................... SUCCESS
> [0.298s]
> [INFO] oVirt Engine API Definition ....................... SUCCESS
> [9.564s]
> [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
> [0.125s]
> [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
> [4.601s]
> [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
> [5.894s]
> [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
>  SUCCESS [16.048s]
> [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
> [8.738s]
> [INFO] oVirt Engine Web Root ............................. SUCCESS
> [4.252s]
> [INFO] oVirt Configuration Tool .......................... SUCCESS
> [2.756s]
> [INFO] Notifier Service package .......................... SUCCESS
> [0.128s]
> [INFO] Notifier Service .................................. SUCCESS
> [3.762s]
> [INFO] Notifier Service Resources ........................ SUCCESS
> [9.760s]
> [INFO] oVirt Modules - frontend .......................... SUCCESS
> [0.742s]
> [INFO] oVirt APIs ........................................ SUCCESS
> [1.084s]
> [INFO] oVirt generic API ................................. SUCCESS
> [14.910s]
> [INFO] oVirt Modules - webadmin .......................... SUCCESS
> [0.151s]
> [INFO] oVirt Modules - ui ................................ SUCCESS
> [0.155s]
> [INFO] Extensions for GWT ................................ SUCCESS
> [17.891s]
> [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
> [2.642s]
> [INFO] Frontend for GWT UI Projects ...................... SUCCESS
> [6.577s]
> [INFO] UICommonWeb ....................................... SUCCESS
> [31.817s]
> [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
> [28.872s]
> [INFO] WebAdmin .......................................... SUCCESS
> [39.948s]
> [INFO] UserPortal ........................................ SUCCESS
> [21.221s]
> [INFO] oVirt WARs ........................................ SUCCESS
> [0.116s]
> [INFO] WPF Application Module ............................ SUCCESS
> [8.917s]
> [INFO] oVirt Web Application Module ...................... SUCCESS
> [9.918s]
> [INFO] oVirt Server EAR .................................. SUCCESS
> [15.338s]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 6:46.263s
> [INFO] Finished at: Tue Jun 12 03:40:19 EDT 2012
> [INFO] Final Memory: 317M/765M
> [INFO]
> ------------------------------------------------------------------------
> [ovirt_engine_dao_unit_tests] $ /home/jenkins/tools/3.0.4/bin/mvn -f
> backend/manager/modules/dal/pom.xml
> -Dmaven.repo.local=/home/jenkins/workspace/ovirt_engine_dao_unit_tests/.repository
> test -Penable-dao-tests
> -Dengine.db.url.escaped=jdbc:postgresql://localhost/ovirt_engine_dao_unit_tests_1208
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective
> model for org.ovirt.engine.core:dal:jar:3.1.0-0001
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-resources-plugin is missing. @ line
> 125, column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.apache.maven.plugins:maven-surefire-plugin is missing. @ line
> 181, column 15
> [WARNING] 'build.plugins.plugin.version' for
> org.codehaus.mojo:exec-maven-plugin is missing. @ line 145, column
> 15
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer
> support building such malformed projects.
> [WARNING]
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Data Access Layer 3.1.0-0001
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @
> dal ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 210 resources
> [INFO] Copying 8 resources
> [INFO] Copying 9 resources
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:copy-resources (copy-resources)
> @ dal ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 1 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
> dal ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-checkstyle-plugin:2.6:check (default) @ dal ---
> [INFO] Starting audit...
> Audit done.
> 
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:testResources
> (default-testResources) @ dal ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 9 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:testCompile
> (default-testCompile) @ dal ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ dal ---
> [INFO] Surefire report directory:
> /home/jenkins/workspace/ovirt_engine_dao_unit_tests/backend/manager/modules/dal/target/surefire-reports
> 
> -------------------------------------------------------
>  T E S T S
> -------------------------------------------------------
> Running org.ovirt.engine.core.dao.StorageServerConnectionDAOTest
> log4j:WARN No appenders could be found for logger
> (org.springframework.test.context.junit4.SpringJUnit4ClassRunner).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
> for more info.
> SLF4J: The requested version 1.5.11 by your slf4j binding is not
> compatible with [1.5.5, 1.5.6]
> SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for
> further details.
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 5.806 sec
> Running org.ovirt.engine.core.dao.VmTemplateDAOTest
> Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.24
> sec
> Running org.ovirt.engine.core.dao.StepDaoTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.13
> sec
> Running org.ovirt.engine.core.dao.VmDynamicDAOTest
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.96
> sec
> Running org.ovirt.engine.core.dao.TagDAOTest
> Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.984 sec
> Running org.ovirt.engine.core.dao.DbFacadeDAOTest
> Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 5.933 sec
> Running org.ovirt.engine.core.dao.AsyncTaskDAOTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.401
> sec
> Running org.ovirt.engine.core.dao.DiskImageDAOTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.06
> sec
> Running org.ovirt.engine.core.dao.RoleGroupMapDAOTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.394
> sec
> Running org.ovirt.engine.core.dao.NetworkClusterDAOTest
> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.496 sec
> Running org.ovirt.engine.core.dao.StoragePoolDAOTest
> Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 6.172 sec
> Running org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest
> Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.81
> sec <<< FAILURE!
> Running org.ovirt.engine.core.dao.gluster.GlusterOptionDaoTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.91
> sec
> Running org.ovirt.engine.core.dao.gluster.GlusterVolumeDaoTest
> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.059 sec
> Running org.ovirt.engine.core.dao.VmStaticDAOTest
> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.329 sec
> Running org.ovirt.engine.core.dao.BookmarkDAOTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.208
> sec
> Running org.ovirt.engine.core.dao.JobDaoTest
> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.937 sec
> Running org.ovirt.engine.core.dao.ImageDaoTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.345
> sec
> Running org.ovirt.engine.core.dao.BaseDiskDaoTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.953
> sec
> Running org.ovirt.engine.core.dao.StorageDomainStaticDAOTest
> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.04
> sec
> Running org.ovirt.engine.core.dao.VmNetworkStatisticsDAOTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.315
> sec
> Running org.ovirt.engine.core.dao.InterfaceDAOTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 4.734 sec
> Running org.ovirt.engine.core.dao.DiskDaoTest
> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.557 sec
> Running org.ovirt.engine.core.dao.VmStatisticsDAOTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.527
> sec
> Running org.ovirt.engine.core.dao.GeneralDbDAOTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.455
> sec
> Running org.ovirt.engine.core.dao.NetworkDAOTest
> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.583 sec
> Running org.ovirt.engine.core.dao.StorageDomainDynamicDAOTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.493
> sec
> Running org.ovirt.engine.core.dao.VmDAOTest
> Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 4.502 sec
> Running org.ovirt.engine.core.dao.EventDAOTest
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.485 sec
> Running org.ovirt.engine.core.dao.SnapshotDaoTest
> Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.761 sec
> Running org.ovirt.engine.core.dao.PermissionDAOTest
> Tests run: 45, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.003 sec
> Running org.ovirt.engine.core.dao.VdsDynamicDAOTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.431
> sec
> Running org.ovirt.engine.core.dao.StorageDomainDAOTest
> Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 11.28 sec
> Running org.ovirt.engine.core.dao.ImageStorageDomainMapDaoTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.796
> sec
> Running org.ovirt.engine.core.dao.DiskLunMapDaoTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.18
> sec
> Running org.ovirt.engine.core.dao.MultiThreadedDAOTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.503
> sec
> Running org.ovirt.engine.core.dao.ActionGroupDAOTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.238
> sec
> Running org.ovirt.engine.core.dao.VmNetworkInterfaceDAOTest
> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 2.875 sec
> Running org.ovirt.engine.core.dao.DiskImageDynamicDAOTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.645
> sec
> Running org.ovirt.engine.core.dao.VdsSpmIdMapDAOTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.719
> sec
> Running org.ovirt.engine.core.dao.VmDeviceDAOTest
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 4.664 sec
> Running org.ovirt.engine.core.dao.AuditLogDAOTest
> Tests run: 22, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4
> sec
> Running org.ovirt.engine.core.dao.BusinessEntitySnapshotDAOTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.824
> sec
> Running org.ovirt.engine.core.dao.VdsStatisticsDAOTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.13
> sec
> Running org.ovirt.engine.core.dao.VdsGroupDAOTest
> Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.59
> sec
> Running org.ovirt.engine.core.dao.JobSubjectEntityDaoTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.141
> sec
> Running org.ovirt.engine.core.dao.LunDAOTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.45
> sec
> Running org.ovirt.engine.core.dao.VdsDAOTest
> Tests run: 29, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 4.168 sec
> Running org.ovirt.engine.core.dao.VdsStaticDAOTest
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.945
> sec
> Running org.ovirt.engine.core.dao.RepoFileMetaDataDAOTest
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 5.622 sec
> Running org.ovirt.engine.core.dao.VmPoolDAOTest
> Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 6.066 sec
> Running org.ovirt.engine.core.dao.RoleDAOTest
> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.704 sec
> Running
> org.ovirt.engine.core.dao.StorageServerConnectionLunMapDAOTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.002
> sec
> Running org.ovirt.engine.core.dao.VdcOptionDAOTest
> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.233
> sec
> Running org.ovirt.engine.core.dao.DbUserDAOTest
> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 4.518 sec
> Running org.ovirt.engine.core.dao.StoragePoolIsoMapDAOTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.322
> sec
> Running org.ovirt.engine.core.dao.AdGroupDAOTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.376
> sec
> Running org.ovirt.engine.core.dao.QuotaDAOTest
> Tests run: 35, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 3.789 sec
> 
> Results :
> 
> Tests in error:
>   testReplaceBrick(org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest):
>   Required input parameter 'v_new_brick_dir' is missing
> 
> Tests run: 755, Failures: 0, Errors: 1, Skipped: 2
> 
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 3:59.609s
> [INFO] Finished at: Tue Jun 12 03:44:25 EDT 2012
> [INFO] Final Memory: 10M/490M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.10:test
> (default-test) on project dal: There are test failures.
> [ERROR]
> [ERROR] Please refer to
> /home/jenkins/workspace/ovirt_engine_dao_unit_tests/backend/manager/modules/dal/target/surefire-reports
> for the individual test results.
> [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/MojoFailureException
> Build step 'Invoke top-level Maven targets' marked build as failure
> Recording test results
> Email was triggered for: Failure
> Sending email for trigger: Failure
> 
> 


From sesubram at redhat.com  Tue Jun 12 08:23:37 2012
From: sesubram at redhat.com (Selvasundaram)
Date: Tue, 12 Jun 2012 13:53:37 +0530
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_dao_unit_tests -
 Build # 1208 - Still Failing!
In-Reply-To: <13363838-3d8f-4116-a9b1-85bb5fcd6ab7@zmail17.collab.prod.int.phx2.redhat.com>
References: <13363838-3d8f-4116-a9b1-85bb5fcd6ab7@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD6FC89.2090007@redhat.com>

Patch already submitted and approved now.
I am verifying it now.

--
Regards
Selvasundaram

On Tuesday 12 June 2012 01:31 PM, Eyal Edri wrote:
> Hi,
>
> It seems commit [sesubram] engine: Adding brick order to Gluster volume bricks added new failed dao test:
>
> org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest.testReplaceBrick
>> Error Message:
>> Required input parameter 'v_new_brick_dir' is missing
> Can you please check?
>
> Eyal Edri
> oVirt Infra Team.
>
>
> ----- 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, mkolesni at redhat.com
>> Sent: Tuesday, June 12, 2012 10:47:31 AM
>> Subject: [oVirt Jenkins] ovirt_engine_dao_unit_tests - Build # 1208 - Still Failing!
>>
>> Project: http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/
>> Build: http://jenkins.ovirt.org/job/ovirt_engine_dao_unit_tests/1208/
>> Build Number: 1208
>> Build Status:  Still Failing
>> Triggered By: Started by upstream project "ovirt_engine" build number
>> 1,611, Started by upstream project "ovirt_engine" build number
>> 1,612, Started by upstream project "ovirt_engine" build number 1,613
>>
>> -------------------------------------
>> Changes Since Last Success:
>> -------------------------------------
>> Changes for Build #1191
>> [mkublin] core: Disable global transaction at InitVdsOnUp
>>
>> [sesubram] engine: Adding brick order to Gluster volume bricks
>>
>>
>> Changes for Build #1192
>>
>> Changes for Build #1193
>> [dgopal] restapi: Gluster Volume Bricks resource implementation
>>
>>
>> Changes for Build #1194
>> [kmayilsa] engine: Skipping Cluster CPU validation in GlusterOnly
>> mode
>>
>> [kmayilsa] engine: Removing default transport type in volume(#830495)
>>
>>
>> Changes for Build #1195
>> [derez] webadmin: display SD status in Storage sub-tab
>>
>> [derez] webadmin: Differentiate Virtual/Actual size in disks
>>
>>
>> Changes for Build #1196
>>
>> Changes for Build #1197
>>
>> Changes for Build #1198
>> [emesika] core: VMs created by vmpool fail to run(#830789)
>>
>> [sesubram] engine: upgrade sql file name sequence number issue fix
>>
>>
>> Changes for Build #1199
>>
>> Changes for Build #1200
>>
>> Changes for Build #1201
>> [gchaplik] webadmin: removing uicommon from build (pom)
>>
>>
>> Changes for Build #1202
>>
>> Changes for Build #1203
>> [ecohen] ui: fix naming to oVirt Engine
>>
>>
>> Changes for Build #1204
>>
>> Changes for Build #1205
>>
>> Changes for Build #1206
>>
>> Changes for Build #1207
>> [yzaslavs] core: Adding new MLA related functions
>>
>> [yzaslavs] core: Adding new methods at RoleDAO
>>
>> [yzaslavs] common: Introducing groupIds property to VdcUser
>>
>> [yzaslavs] core: Preventing adding unauthorized users
>>
>>
>> Changes for Build #1208
>> [oliel] restapi: RSDL - Fix meta-data of some collections
>>
>> [mkolesni] core: Handle correct NIC ID from OVF (#827061)
>>
>>
>>
>>
>> -----------------
>> Failed Tests:
>> -----------------
>> 1 tests failed.
>> FAILED:
>>   org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest.testReplaceBrick
>>
>> Error Message:
>> Required input parameter 'v_new_brick_dir' is missing
>>
>> Stack Trace:
>> org.springframework.dao.InvalidDataAccessApiUsageException: Required
>> input parameter 'v_new_brick_dir' is missing
>> 	at
>> 	org.springframework.jdbc.core.CallableStatementCreatorFactory$CallableStatementCreatorImpl.createCallableStatement(CallableStatementCreatorFactory.java:210)
>> 	at
>> 	org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:930)
>> 	at
>> 	org.springframework.jdbc.core.JdbcTemplate.call(JdbcTemplate.java:985)
>> 	at
>> 	org.springframework.jdbc.core.simple.AbstractJdbcCall.executeCallInternal(AbstractJdbcCall.java:368)
>> 	at
>> 	org.springframework.jdbc.core.simple.AbstractJdbcCall.doExecute(AbstractJdbcCall.java:342)
>> 	at
>> 	org.springframework.jdbc.core.simple.SimpleJdbcCall.execute(SimpleJdbcCall.java:164)
>> 	at
>> 	org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeImpl(SimpleJdbcCallsHandler.java:124)
>> 	at
>> 	org.ovirt.engine.core.dal.dbbroker.SimpleJdbcCallsHandler.executeModification(SimpleJdbcCallsHandler.java:37)
>> 	at
>> 	org.ovirt.engine.core.dao.gluster.GlusterBrickDaoDbFacadeImpl.replaceBrick(GlusterBrickDaoDbFacadeImpl.java:34)
>> 	at
>> 	org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest.testReplaceBrick(GlusterBrickDaoTest.java:74)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at
>> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> 	at
>> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.lang.reflect.Method.invoke(Method.java:616)
>> 	at
>> 	org.springframework.test.context.junit4.SpringTestMethod.invoke(SpringTestMethod.java:160)
>> 	at
>> 	org.springframework.test.context.junit4.SpringMethodRoadie.runTestMethod(SpringMethodRoadie.java:233)
>> 	at
>> 	org.springframework.test.context.junit4.SpringMethodRoadie$RunBeforesThenTestThenAfters.run(SpringMethodRoadie.java:333)
>> 	at
>> 	org.springframework.test.context.junit4.SpringMethodRoadie.runWithRepetitions(SpringMethodRoadie.java:217)
>> 	at
>> 	org.springframework.test.context.junit4.SpringMethodRoadie.runTest(SpringMethodRoadie.java:197)
>> 	at
>> 	org.springframework.test.context.junit4.SpringMethodRoadie.run(SpringMethodRoadie.java:143)
>> 	at
>> 	org.springframework.test.context.junit4.SpringJUnit4ClassRunner.invokeTestMethod(SpringJUnit4ClassRunner.java:160)
>> 	at
>> 	org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
>> 	at
>> 	org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
>> 	at
>> 	org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
>> 	at
>> 	org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
>> 	at
>> 	org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
>> 	at
>> 	org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:97)
>> 	at
>> 	org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
>> 	at
>> 	org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
>> 	at
>> 	org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at
>> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> 	at
>> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.lang.reflect.Method.invoke(Method.java:616)
>> 	at
>> 	org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
>> 	at
>> 	org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
>> 	at
>> 	org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
>> 	at
>> 	org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
>> 	at
>> 	org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
>>
>>
>>
>>
>> ------------------
>> Build Log:
>> ------------------
>> [...truncated 2719 lines...]
>> [INFO] Encryption Libraries .............................. SUCCESS
>> [2.368s]
>> [INFO] oVirt Tools ....................................... SUCCESS
>> [0.633s]
>> [INFO] oVirt Tools Common Library ........................ SUCCESS
>> [2.004s]
>> [INFO] Common Code ....................................... SUCCESS
>> [26.839s]
>> [INFO] Common utilities .................................. SUCCESS
>> [9.096s]
>> [INFO] Data Access Layer ................................. SUCCESS
>> [14.694s]
>> [INFO] engine beans ...................................... SUCCESS
>> [0.122s]
>> [INFO] engine scheduler bean ............................. SUCCESS
>> [8.457s]
>> [INFO] Vds broker ........................................ SUCCESS
>> [10.079s]
>> [INFO] Search Backend .................................... SUCCESS
>> [8.950s]
>> [INFO] Backend Logic @Service bean ....................... SUCCESS
>> [33.705s]
>> [INFO] oVirt RESTful API Backend Integration ............. SUCCESS
>> [0.621s]
>> [INFO] oVirt RESTful API interface ....................... SUCCESS
>> [0.298s]
>> [INFO] oVirt Engine API Definition ....................... SUCCESS
>> [9.564s]
>> [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
>> [0.125s]
>> [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
>> [4.601s]
>> [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
>> [5.894s]
>> [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
>>   SUCCESS [16.048s]
>> [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
>> [8.738s]
>> [INFO] oVirt Engine Web Root ............................. SUCCESS
>> [4.252s]
>> [INFO] oVirt Configuration Tool .......................... SUCCESS
>> [2.756s]
>> [INFO] Notifier Service package .......................... SUCCESS
>> [0.128s]
>> [INFO] Notifier Service .................................. SUCCESS
>> [3.762s]
>> [INFO] Notifier Service Resources ........................ SUCCESS
>> [9.760s]
>> [INFO] oVirt Modules - frontend .......................... SUCCESS
>> [0.742s]
>> [INFO] oVirt APIs ........................................ SUCCESS
>> [1.084s]
>> [INFO] oVirt generic API ................................. SUCCESS
>> [14.910s]
>> [INFO] oVirt Modules - webadmin .......................... SUCCESS
>> [0.151s]
>> [INFO] oVirt Modules - ui ................................ SUCCESS
>> [0.155s]
>> [INFO] Extensions for GWT ................................ SUCCESS
>> [17.891s]
>> [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
>> [2.642s]
>> [INFO] Frontend for GWT UI Projects ...................... SUCCESS
>> [6.577s]
>> [INFO] UICommonWeb ....................................... SUCCESS
>> [31.817s]
>> [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
>> [28.872s]
>> [INFO] WebAdmin .......................................... SUCCESS
>> [39.948s]
>> [INFO] UserPortal ........................................ SUCCESS
>> [21.221s]
>> [INFO] oVirt WARs ........................................ SUCCESS
>> [0.116s]
>> [INFO] WPF Application Module ............................ SUCCESS
>> [8.917s]
>> [INFO] oVirt Web Application Module ...................... SUCCESS
>> [9.918s]
>> [INFO] oVirt Server EAR .................................. SUCCESS
>> [15.338s]
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD SUCCESS
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 6:46.263s
>> [INFO] Finished at: Tue Jun 12 03:40:19 EDT 2012
>> [INFO] Final Memory: 317M/765M
>> [INFO]
>> ------------------------------------------------------------------------
>> [ovirt_engine_dao_unit_tests] $ /home/jenkins/tools/3.0.4/bin/mvn -f
>> backend/manager/modules/dal/pom.xml
>> -Dmaven.repo.local=/home/jenkins/workspace/ovirt_engine_dao_unit_tests/.repository
>> test -Penable-dao-tests
>> -Dengine.db.url.escaped=jdbc:postgresql://localhost/ovirt_engine_dao_unit_tests_1208
>> [INFO] Scanning for projects...
>> [WARNING]
>> [WARNING] Some problems were encountered while building the effective
>> model for org.ovirt.engine.core:dal:jar:3.1.0-0001
>> [WARNING] 'build.plugins.plugin.version' for
>> org.apache.maven.plugins:maven-resources-plugin is missing. @ line
>> 125, column 15
>> [WARNING] 'build.plugins.plugin.version' for
>> org.apache.maven.plugins:maven-surefire-plugin is missing. @ line
>> 181, column 15
>> [WARNING] 'build.plugins.plugin.version' for
>> org.codehaus.mojo:exec-maven-plugin is missing. @ line 145, column
>> 15
>> [WARNING]
>> [WARNING] It is highly recommended to fix these problems because they
>> threaten the stability of your build.
>> [WARNING]
>> [WARNING] For this reason, future Maven versions might no longer
>> support building such malformed projects.
>> [WARNING]
>> [INFO]
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Building Data Access Layer 3.1.0-0001
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @
>> dal ---
>> [debug] execute contextualize
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 210 resources
>> [INFO] Copying 8 resources
>> [INFO] Copying 9 resources
>> [INFO] Copying 1 resource
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.5:copy-resources (copy-resources)
>> @ dal ---
>> [debug] execute contextualize
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 1 resource
>> [INFO]
>> [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
>> dal ---
>> [INFO] Nothing to compile - all classes are up to date
>> [INFO]
>> [INFO] --- maven-checkstyle-plugin:2.6:check (default) @ dal ---
>> [INFO] Starting audit...
>> Audit done.
>>
>> [INFO]
>> [INFO] --- maven-resources-plugin:2.5:testResources
>> (default-testResources) @ dal ---
>> [debug] execute contextualize
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 9 resources
>> [INFO]
>> [INFO] --- maven-compiler-plugin:2.3.2:testCompile
>> (default-testCompile) @ dal ---
>> [INFO] Nothing to compile - all classes are up to date
>> [INFO]
>> [INFO] --- maven-surefire-plugin:2.10:test (default-test) @ dal ---
>> [INFO] Surefire report directory:
>> /home/jenkins/workspace/ovirt_engine_dao_unit_tests/backend/manager/modules/dal/target/surefire-reports
>>
>> -------------------------------------------------------
>>   T E S T S
>> -------------------------------------------------------
>> Running org.ovirt.engine.core.dao.StorageServerConnectionDAOTest
>> log4j:WARN No appenders could be found for logger
>> (org.springframework.test.context.junit4.SpringJUnit4ClassRunner).
>> log4j:WARN Please initialize the log4j system properly.
>> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig
>> for more info.
>> SLF4J: The requested version 1.5.11 by your slf4j binding is not
>> compatible with [1.5.5, 1.5.6]
>> SLF4J: See http://www.slf4j.org/codes.html#version_mismatch for
>> further details.
>> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 5.806 sec
>> Running org.ovirt.engine.core.dao.VmTemplateDAOTest
>> Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.24
>> sec
>> Running org.ovirt.engine.core.dao.StepDaoTest
>> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.13
>> sec
>> Running org.ovirt.engine.core.dao.VmDynamicDAOTest
>> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.96
>> sec
>> Running org.ovirt.engine.core.dao.TagDAOTest
>> Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.984 sec
>> Running org.ovirt.engine.core.dao.DbFacadeDAOTest
>> Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 5.933 sec
>> Running org.ovirt.engine.core.dao.AsyncTaskDAOTest
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.401
>> sec
>> Running org.ovirt.engine.core.dao.DiskImageDAOTest
>> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.06
>> sec
>> Running org.ovirt.engine.core.dao.RoleGroupMapDAOTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.394
>> sec
>> Running org.ovirt.engine.core.dao.NetworkClusterDAOTest
>> Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.496 sec
>> Running org.ovirt.engine.core.dao.StoragePoolDAOTest
>> Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 6.172 sec
>> Running org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest
>> Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.81
>> sec<<<  FAILURE!
>> Running org.ovirt.engine.core.dao.gluster.GlusterOptionDaoTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.91
>> sec
>> Running org.ovirt.engine.core.dao.gluster.GlusterVolumeDaoTest
>> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.059 sec
>> Running org.ovirt.engine.core.dao.VmStaticDAOTest
>> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.329 sec
>> Running org.ovirt.engine.core.dao.BookmarkDAOTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.208
>> sec
>> Running org.ovirt.engine.core.dao.JobDaoTest
>> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 2.937 sec
>> Running org.ovirt.engine.core.dao.ImageDaoTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.345
>> sec
>> Running org.ovirt.engine.core.dao.BaseDiskDaoTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.953
>> sec
>> Running org.ovirt.engine.core.dao.StorageDomainStaticDAOTest
>> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.04
>> sec
>> Running org.ovirt.engine.core.dao.VmNetworkStatisticsDAOTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.315
>> sec
>> Running org.ovirt.engine.core.dao.InterfaceDAOTest
>> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 4.734 sec
>> Running org.ovirt.engine.core.dao.DiskDaoTest
>> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.557 sec
>> Running org.ovirt.engine.core.dao.VmStatisticsDAOTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.527
>> sec
>> Running org.ovirt.engine.core.dao.GeneralDbDAOTest
>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.455
>> sec
>> Running org.ovirt.engine.core.dao.NetworkDAOTest
>> Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.583 sec
>> Running org.ovirt.engine.core.dao.StorageDomainDynamicDAOTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.493
>> sec
>> Running org.ovirt.engine.core.dao.VmDAOTest
>> Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 4.502 sec
>> Running org.ovirt.engine.core.dao.EventDAOTest
>> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.485 sec
>> Running org.ovirt.engine.core.dao.SnapshotDaoTest
>> Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.761 sec
>> Running org.ovirt.engine.core.dao.PermissionDAOTest
>> Tests run: 45, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.003 sec
>> Running org.ovirt.engine.core.dao.VdsDynamicDAOTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.431
>> sec
>> Running org.ovirt.engine.core.dao.StorageDomainDAOTest
>> Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 11.28 sec
>> Running org.ovirt.engine.core.dao.ImageStorageDomainMapDaoTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.796
>> sec
>> Running org.ovirt.engine.core.dao.DiskLunMapDaoTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.18
>> sec
>> Running org.ovirt.engine.core.dao.MultiThreadedDAOTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.503
>> sec
>> Running org.ovirt.engine.core.dao.ActionGroupDAOTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.238
>> sec
>> Running org.ovirt.engine.core.dao.VmNetworkInterfaceDAOTest
>> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 2.875 sec
>> Running org.ovirt.engine.core.dao.DiskImageDynamicDAOTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.645
>> sec
>> Running org.ovirt.engine.core.dao.VdsSpmIdMapDAOTest
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.719
>> sec
>> Running org.ovirt.engine.core.dao.VmDeviceDAOTest
>> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 4.664 sec
>> Running org.ovirt.engine.core.dao.AuditLogDAOTest
>> Tests run: 22, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 4
>> sec
>> Running org.ovirt.engine.core.dao.BusinessEntitySnapshotDAOTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.824
>> sec
>> Running org.ovirt.engine.core.dao.VdsStatisticsDAOTest
>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.13
>> sec
>> Running org.ovirt.engine.core.dao.VdsGroupDAOTest
>> Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.59
>> sec
>> Running org.ovirt.engine.core.dao.JobSubjectEntityDaoTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.141
>> sec
>> Running org.ovirt.engine.core.dao.LunDAOTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.45
>> sec
>> Running org.ovirt.engine.core.dao.VdsDAOTest
>> Tests run: 29, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 4.168 sec
>> Running org.ovirt.engine.core.dao.VdsStaticDAOTest
>> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.945
>> sec
>> Running org.ovirt.engine.core.dao.RepoFileMetaDataDAOTest
>> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 5.622 sec
>> Running org.ovirt.engine.core.dao.VmPoolDAOTest
>> Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 6.066 sec
>> Running org.ovirt.engine.core.dao.RoleDAOTest
>> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.704 sec
>> Running
>> org.ovirt.engine.core.dao.StorageServerConnectionLunMapDAOTest
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.002
>> sec
>> Running org.ovirt.engine.core.dao.VdcOptionDAOTest
>> Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.233
>> sec
>> Running org.ovirt.engine.core.dao.DbUserDAOTest
>> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 4.518 sec
>> Running org.ovirt.engine.core.dao.StoragePoolIsoMapDAOTest
>> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.322
>> sec
>> Running org.ovirt.engine.core.dao.AdGroupDAOTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.376
>> sec
>> Running org.ovirt.engine.core.dao.QuotaDAOTest
>> Tests run: 35, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
>> 3.789 sec
>>
>> Results :
>>
>> Tests in error:
>>    testReplaceBrick(org.ovirt.engine.core.dao.gluster.GlusterBrickDaoTest):
>>    Required input parameter 'v_new_brick_dir' is missing
>>
>> Tests run: 755, Failures: 0, Errors: 1, Skipped: 2
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 3:59.609s
>> [INFO] Finished at: Tue Jun 12 03:44:25 EDT 2012
>> [INFO] Final Memory: 10M/490M
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-surefire-plugin:2.10:test
>> (default-test) on project dal: There are test failures.
>> [ERROR]
>> [ERROR] Please refer to
>> /home/jenkins/workspace/ovirt_engine_dao_unit_tests/backend/manager/modules/dal/target/surefire-reports
>> for the individual test results.
>> [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/MojoFailureException
>> Build step 'Invoke top-level Maven targets' marked build as failure
>> Recording test results
>> Email was triggered for: Failure
>> Sending email for trigger: Failure
>>
>>



From ykaul at redhat.com  Tue Jun 12 09:25:44 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Tue, 12 Jun 2012 12:25:44 +0300
Subject: [Engine-devel] 'deactivate' disk - what's the use case?
Message-ID: <4FD70B18.6090105@redhat.com>

I'm wondering what's the usefulness of having dual action of attach + 
activate to get a disk properly attached and working in a VM (and the 
deactivate and detach counterparts).

The only reason I can think of is that we've annoyed the user by this 
useless dual action when working with storage domains in a data center 
for ages, and we wish to remain consistent and annoy the user in the 
disks scenario as well, but there may be a reason I'm not aware of.

TIA,
Y.


From iheim at redhat.com  Tue Jun 12 09:34:54 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 12 Jun 2012 12:34:54 +0300
Subject: [Engine-devel] 'deactivate' disk - what's the use case?
In-Reply-To: <4FD70B18.6090105@redhat.com>
References: <4FD70B18.6090105@redhat.com>
Message-ID: <4FD70D3E.9000106@redhat.com>

On 06/12/2012 12:25 PM, Yaniv Kaul wrote:
> I'm wondering what's the usefulness of having dual action of attach +
> activate to get a disk properly attached and working in a VM (and the
> deactivate and detach counterparts).
>
> The only reason I can think of is that we've annoyed the user by this
> useless dual action when working with storage domains in a data center
> for ages, and we wish to remain consistent and annoy the user in the
> disks scenario as well, but there may be a reason I'm not aware of.

deactivated is like having a disk in offline, or hot unplugging when you 
still want to retain it in the context of the vm configuration

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



From ykaul at redhat.com  Tue Jun 12 09:40:08 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Tue, 12 Jun 2012 12:40:08 +0300
Subject: [Engine-devel] 'deactivate' disk - what's the use case?
In-Reply-To: <4FD70D3E.9000106@redhat.com>
References: <4FD70B18.6090105@redhat.com> <4FD70D3E.9000106@redhat.com>
Message-ID: <4FD70E78.8080100@redhat.com>

On 06/12/2012 12:34 PM, Itamar Heim wrote:
> On 06/12/2012 12:25 PM, Yaniv Kaul wrote:
>> I'm wondering what's the usefulness of having dual action of attach +
>> activate to get a disk properly attached and working in a VM (and the
>> deactivate and detach counterparts).
>>
>> The only reason I can think of is that we've annoyed the user by this
>> useless dual action when working with storage domains in a data center
>> for ages, and we wish to remain consistent and annoy the user in the
>> disks scenario as well, but there may be a reason I'm not aware of.
>
> deactivated is like having a disk in offline, or hot unplugging when 
> you still want to retain it in the context of the vm configuration

I understand that, I just argue it's quite useless (offline can be done 
from within the guest OS), does not work that way in physical hardware 
(offline is a logical action within the OS), has very little value to 
the RHEV Admin (unless he's paranoid and afraid that the disk will 
become float and someone else would 'steal' it from his VM) and is 
annoying to require multiple actions.
Y.

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




From lpeer at redhat.com  Tue Jun 12 09:47:25 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 12 Jun 2012 12:47:25 +0300
Subject: [Engine-devel] 'deactivate' disk - what's the use case?
In-Reply-To: <4FD70E78.8080100@redhat.com>
References: <4FD70B18.6090105@redhat.com> <4FD70D3E.9000106@redhat.com>
	<4FD70E78.8080100@redhat.com>
Message-ID: <4FD7102D.206@redhat.com>

On 12/06/12 12:40, Yaniv Kaul wrote:
> On 06/12/2012 12:34 PM, Itamar Heim wrote:
>> On 06/12/2012 12:25 PM, Yaniv Kaul wrote:
>>> I'm wondering what's the usefulness of having dual action of attach +
>>> activate to get a disk properly attached and working in a VM (and the
>>> deactivate and detach counterparts).
>>>
>>> The only reason I can think of is that we've annoyed the user by this
>>> useless dual action when working with storage domains in a data center
>>> for ages, and we wish to remain consistent and annoy the user in the
>>> disks scenario as well, but there may be a reason I'm not aware of.
>>
>> deactivated is like having a disk in offline, or hot unplugging when
>> you still want to retain it in the context of the vm configuration
> 
> I understand that, I just argue it's quite useless (offline can be done
> from within the guest OS), 

You can deactivate the disk if for some reason it blocks the guest from
starting. I think that if the disk not accessible the VM won't start and
then you can deactivate the disk and start the VM.


> does not work that way in physical hardware
> (offline is a logical action within the OS), has very little value to
> the RHEV Admin (unless he's paranoid and afraid that the disk will
> become float and someone else would 'steal' it from his VM) and is
> annoying to require multiple actions.
> Y.
> 
>>
>>>
>>> TIA,
>>> Y.
>>> _______________________________________________
>>> 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 ykaul at redhat.com  Tue Jun 12 11:14:00 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Tue, 12 Jun 2012 14:14:00 +0300
Subject: [Engine-devel] 'deactivate' disk - what's the use case?
In-Reply-To: <4FD7102D.206@redhat.com>
References: <4FD70B18.6090105@redhat.com> <4FD70D3E.9000106@redhat.com>
	<4FD70E78.8080100@redhat.com> <4FD7102D.206@redhat.com>
Message-ID: <4FD72478.4070004@redhat.com>

On 06/12/2012 12:47 PM, Livnat Peer wrote:
> On 12/06/12 12:40, Yaniv Kaul wrote:
>> On 06/12/2012 12:34 PM, Itamar Heim wrote:
>>> On 06/12/2012 12:25 PM, Yaniv Kaul wrote:
>>>> I'm wondering what's the usefulness of having dual action of attach +
>>>> activate to get a disk properly attached and working in a VM (and the
>>>> deactivate and detach counterparts).
>>>>
>>>> The only reason I can think of is that we've annoyed the user by this
>>>> useless dual action when working with storage domains in a data center
>>>> for ages, and we wish to remain consistent and annoy the user in the
>>>> disks scenario as well, but there may be a reason I'm not aware of.
>>> deactivated is like having a disk in offline, or hot unplugging when
>>> you still want to retain it in the context of the vm configuration
>> I understand that, I just argue it's quite useless (offline can be done
>> from within the guest OS),
> You can deactivate the disk if for some reason it blocks the guest from
> starting. I think that if the disk not accessible the VM won't start and
> then you can deactivate the disk and start the VM.

You can also detach it to get the same effect with one less click of a 
button or an API call.
Y.

>
>
>> does not work that way in physical hardware
>> (offline is a logical action within the OS), has very little value to
>> the RHEV Admin (unless he's paranoid and afraid that the disk will
>> become float and someone else would 'steal' it from his VM) and is
>> annoying to require multiple actions.
>> Y.
>>
>>>> TIA,
>>>> Y.
>>>> _______________________________________________
>>>> 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 lpeer at redhat.com  Tue Jun 12 11:23:09 2012
From: lpeer at redhat.com (Livnat Peer)
Date: Tue, 12 Jun 2012 14:23:09 +0300
Subject: [Engine-devel] 'deactivate' disk - what's the use case?
In-Reply-To: <4FD72478.4070004@redhat.com>
References: <4FD70B18.6090105@redhat.com> <4FD70D3E.9000106@redhat.com>
	<4FD70E78.8080100@redhat.com> <4FD7102D.206@redhat.com>
	<4FD72478.4070004@redhat.com>
Message-ID: <4FD7269D.5050900@redhat.com>

On 12/06/12 14:14, Yaniv Kaul wrote:
> On 06/12/2012 12:47 PM, Livnat Peer wrote:
>> On 12/06/12 12:40, Yaniv Kaul wrote:
>>> On 06/12/2012 12:34 PM, Itamar Heim wrote:
>>>> On 06/12/2012 12:25 PM, Yaniv Kaul wrote:
>>>>> I'm wondering what's the usefulness of having dual action of attach +
>>>>> activate to get a disk properly attached and working in a VM (and the
>>>>> deactivate and detach counterparts).
>>>>>
>>>>> The only reason I can think of is that we've annoyed the user by this
>>>>> useless dual action when working with storage domains in a data center
>>>>> for ages, and we wish to remain consistent and annoy the user in the
>>>>> disks scenario as well, but there may be a reason I'm not aware of.
>>>> deactivated is like having a disk in offline, or hot unplugging when
>>>> you still want to retain it in the context of the vm configuration
>>> I understand that, I just argue it's quite useless (offline can be done
>>> from within the guest OS),
>> You can deactivate the disk if for some reason it blocks the guest from
>> starting. I think that if the disk not accessible the VM won't start and
>> then you can deactivate the disk and start the VM.
> 
> You can also detach it to get the same effect with one less click of a
> button or an API call.
> Y.
> 

Why detach requires one less click than deactivate, both should require
a single click?

BTW you should be able to attach and activate disk in a single action
(to avoid non-user-friendly behavior like we have for SD).

>>
>>
>>> does not work that way in physical hardware
>>> (offline is a logical action within the OS), has very little value to
>>> the RHEV Admin (unless he's paranoid and afraid that the disk will
>>> become float and someone else would 'steal' it from his VM) and is
>>> annoying to require multiple actions.
>>> Y.
>>>
>>>>> TIA,
>>>>> Y.
>>>>> _______________________________________________
>>>>> 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 shaohef at linux.vnet.ibm.com  Wed Jun 13 03:00:01 2012
From: shaohef at linux.vnet.ibm.com (ShaoHe Feng)
Date: Wed, 13 Jun 2012 11:00:01 +0800
Subject: [Engine-devel]  Deploy ovirt-engine error
Message-ID: <4FD80231.3020009@linux.vnet.ibm.com>

I follow this guide http://ovirt.org/wiki/Building_oVirt_engine

1)
$> make install_tools
make: *** No rule to make target `install_tools'.  Stop

I have check the Makefile, there is really no install_tools rule.

2)
#>  make install_config
*** 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 /etc/ovirt-engine/engine-config/
install -m 644 
backend/manager/tools/engine-config/src/main/resources/engine-config.*properties 
/etc/ovirt-engine/engine-config/
install -m 644 
backend/manager/tools/engine-config/src/main/resources/log4j.xml 
/etc/ovirt-engine/engine-config/
# Jar files for the configuration tool:
# XXX: Should replace with links to the actual locations
# of the jar files, or fix the scripts to use that.
install -m 644 
/home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar 
/usr/share/ovirt-engine/engine-config/lib/
install: cannot stat 
`/home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar': 
No such file or directory
make: *** [install_config] Error 1


3) can not start jboss-as after deploy ovirt-engine.
  $# service jboss-as start
=========================================================================

   JBoss Bootstrap Environment

   JBOSS_HOME: /usr/share/jboss-as

   JAVA: java

   JAVA_OPTS:  -server -XX:+UseCompressedOops -XX:+TieredCompilation 
-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4S
tack=true -Dorg.jboss.resolver.warning=true 
-Dsun.rmi.dgc.client.gcInterval=3600000 
-Dsun.rmi.dgc.server.gcInterval=3600000 -Djb
oss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true 
-Djboss.server.default.config=standalone.xml

=========================================================================

10:39:51,401 INFO  [org.jboss.modules] JBoss Modules version 1.1.1.GA
10:39:51,643 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
10:39:51,682 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final 
"Brontes" starting
10:39:51,689 ERROR [org.jboss.msc.service.fail] MSC00001: Failed to 
start service jboss.as: org.jboss.msc.service.StartException
  in service jboss.as: Failed to start service
         at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) 
[jboss-msc-1.0.2.GA.jar:1.
0.2.GA]
         at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
[rt.jar:1.7.0_b147-icedtea]
         at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
[rt.jar:1.7.0_b147-icedtea]
         at java.lang.Thread.run(Thread.java:722) 
[rt.jar:1.7.0_b147-icedtea]
Caused by: java.lang.IllegalStateException: JBAS014922: Directory 
/usr/share/jboss-as/standalone/data/content is not writable
         at 
org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123)
         at 
org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97)
         at 
org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134) 
[jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
         at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) 
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
         at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) 
[jboss-msc-1.0.2.GA.jar:1.0.2.GA]
         ... 3 more

10:39:51,694 ERROR [stderr] java.util.concurrent.ExecutionException: 
Operation failed
10:39:51,695 ERROR [stderr]     at 
org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
10:39:51,695 ERROR [stderr]     at 
org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
10:39:51,695 ERROR [stderr]     at 
org.jboss.as.server.Main.main(Main.java:98)
10:39:51,695 ERROR [stderr]     at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
10:39:51,695 ERROR [stderr]     at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
10:39:51,707 ERROR [stderr]     at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
10:39:51,707 ERROR [stderr]     at 
java.lang.reflect.Method.invoke(Method.java:601)
10:39:51,708 ERROR [stderr]     at 
org.jboss.modules.Module.run(Module.java:260)
10:39:51,708 ERROR [stderr]     at 
org.jboss.modules.Main.main(Main.java:291)
10:39:51,708 ERROR [stderr] Caused by: 
org.jboss.msc.service.StartException in service jboss.as: Failed to 
start service
10:39:51,708 ERROR [stderr]     at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767)
10:39:51,708 ERROR [stderr]     at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
10:39:51,708 ERROR [stderr]     at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
10:39:51,709 ERROR [stderr]     at java.lang.Thread.run(Thread.java:722)
10:39:51,709 ERROR [stderr] Caused by: java.lang.IllegalStateException: 
JBAS014922: Directory /usr/share/jboss-as/standalone/data/content is not 
writable
10:39:51,709 ERROR [stderr]     at 
org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123)
10:39:51,709 ERROR [stderr]     at 
org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97)
10:39:51,709 ERROR [stderr]     at 
org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134)
10:39:51,710 ERROR [stderr]     at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
10:39:51,710 ERROR [stderr]     at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
10:39:51,710 ERROR [stderr]     ... 3 more
13469


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120613/0b3ebae3/attachment.html>

From shuming at linux.vnet.ibm.com  Wed Jun 13 03:08:27 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Wed, 13 Jun 2012 11:08:27 +0800
Subject: [Engine-devel] Deploy ovirt-engine error
In-Reply-To: <4FD80231.3020009@linux.vnet.ibm.com>
References: <4FD80231.3020009@linux.vnet.ibm.com>
Message-ID: <4FD8042B.60402@linux.vnet.ibm.com>

Shaohe,
   Also, you can try the beta oivrt-engine release package in ovirt.org.
        http://www.ovirt.org/releases/beta/fedora/17/

On 2012-6-13 11:00, ShaoHe Feng wrote:
> I follow this guide http://ovirt.org/wiki/Building_oVirt_engine
>
> 1)
> $> make install_tools
> make: *** No rule to make target `install_tools'.  Stop
>
> I have check the Makefile, there is really no install_tools rule.
>
> 2)
> #>  make install_config
> *** 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 
> /etc/ovirt-engine/engine-config/
> install -m 644 
> backend/manager/tools/engine-config/src/main/resources/engine-config.*properties 
> /etc/ovirt-engine/engine-config/
> install -m 644 
> backend/manager/tools/engine-config/src/main/resources/log4j.xml 
> /etc/ovirt-engine/engine-config/
> # Jar files for the configuration tool:
> # XXX: Should replace with links to the actual locations
> # of the jar files, or fix the scripts to use that.
> install -m 644 
> /home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar 
> /usr/share/ovirt-engine/engine-config/lib/
> install: cannot stat 
> `/home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar': 
> No such file or directory
> make: *** [install_config] Error 1
>
>
> 3) can not start jboss-as after deploy ovirt-engine.
>  $# service jboss-as start
> =========================================================================
>
>   JBoss Bootstrap Environment
>
>   JBOSS_HOME: /usr/share/jboss-as
>
>   JAVA: java
>
>   JAVA_OPTS:  -server -XX:+UseCompressedOops -XX:+TieredCompilation 
> -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4S
> tack=true -Dorg.jboss.resolver.warning=true 
> -Dsun.rmi.dgc.client.gcInterval=3600000 
> -Dsun.rmi.dgc.server.gcInterval=3600000 -Djb
> oss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true 
> -Djboss.server.default.config=standalone.xml
>
> =========================================================================
>
> 10:39:51,401 INFO  [org.jboss.modules] JBoss Modules version 1.1.1.GA
> 10:39:51,643 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 10:39:51,682 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final 
> "Brontes" starting
> 10:39:51,689 ERROR [org.jboss.msc.service.fail] MSC00001: Failed to 
> start service jboss.as: org.jboss.msc.service.StartException
>  in service jboss.as: Failed to start service
>         at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) 
> [jboss-msc-1.0.2.GA.jar:1.
> 0.2.GA]
>         at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
> [rt.jar:1.7.0_b147-icedtea]
>         at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
> [rt.jar:1.7.0_b147-icedtea]
>         at java.lang.Thread.run(Thread.java:722) 
> [rt.jar:1.7.0_b147-icedtea]
> Caused by: java.lang.IllegalStateException: JBAS014922: Directory 
> /usr/share/jboss-as/standalone/data/content is not writable
>         at 
> org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123)
>         at 
> org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97)
>         at 
> org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134) 
> [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>         at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) 
> [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) 
> [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         ... 3 more
>
> 10:39:51,694 ERROR [stderr] java.util.concurrent.ExecutionException: 
> Operation failed
> 10:39:51,695 ERROR [stderr]     at 
> org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
> 10:39:51,695 ERROR [stderr]     at 
> org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
> 10:39:51,695 ERROR [stderr]     at 
> org.jboss.as.server.Main.main(Main.java:98)
> 10:39:51,695 ERROR [stderr]     at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:39:51,695 ERROR [stderr]     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 10:39:51,707 ERROR [stderr]     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:39:51,707 ERROR [stderr]     at 
> java.lang.reflect.Method.invoke(Method.java:601)
> 10:39:51,708 ERROR [stderr]     at 
> org.jboss.modules.Module.run(Module.java:260)
> 10:39:51,708 ERROR [stderr]     at 
> org.jboss.modules.Main.main(Main.java:291)
> 10:39:51,708 ERROR [stderr] Caused by: 
> org.jboss.msc.service.StartException in service jboss.as: Failed to 
> start service
> 10:39:51,708 ERROR [stderr]     at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767)
> 10:39:51,708 ERROR [stderr]     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 10:39:51,708 ERROR [stderr]     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 10:39:51,709 ERROR [stderr]     at java.lang.Thread.run(Thread.java:722)
> 10:39:51,709 ERROR [stderr] Caused by: 
> java.lang.IllegalStateException: JBAS014922: Directory 
> /usr/share/jboss-as/standalone/data/content is not writable
> 10:39:51,709 ERROR [stderr]     at 
> org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123)
> 10:39:51,709 ERROR [stderr]     at 
> org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97)
> 10:39:51,709 ERROR [stderr]     at 
> org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134)
> 10:39:51,710 ERROR [stderr]     at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> 10:39:51,710 ERROR [stderr]     at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> 10:39:51,710 ERROR [stderr]     ... 3 more
> 13469
>
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120613/4a07e8f3/attachment.html>

From shaohef at linux.vnet.ibm.com  Wed Jun 13 03:21:42 2012
From: shaohef at linux.vnet.ibm.com (ShaoHe Feng)
Date: Wed, 13 Jun 2012 11:21:42 +0800
Subject: [Engine-devel] Deploy ovirt-engine error
In-Reply-To: <4FD8042B.60402@linux.vnet.ibm.com>
References: <4FD80231.3020009@linux.vnet.ibm.com>
	<4FD8042B.60402@linux.vnet.ibm.com>
Message-ID: <4FD80746.8040100@linux.vnet.ibm.com>

Thank you, I will try the release package.

On 06/13/2012 11:08 AM, Shu Ming wrote:
> Shaohe,
>   Also, you can try the beta oivrt-engine release package in ovirt.org.
> http://www.ovirt.org/releases/beta/fedora/17/
>
> On 2012-6-13 11:00, ShaoHe Feng wrote:
>> I follow this guide http://ovirt.org/wiki/Building_oVirt_engine
>>
>> 1)
>> $> make install_tools
>> make: *** No rule to make target `install_tools'.  Stop
>>
>> I have check the Makefile, there is really no install_tools rule.
>>
>> 2)
>> #>  make install_config
>> *** 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 
>> /etc/ovirt-engine/engine-config/
>> install -m 644 
>> backend/manager/tools/engine-config/src/main/resources/engine-config.*properties 
>> /etc/ovirt-engine/engine-config/
>> install -m 644 
>> backend/manager/tools/engine-config/src/main/resources/log4j.xml 
>> /etc/ovirt-engine/engine-config/
>> # Jar files for the configuration tool:
>> # XXX: Should replace with links to the actual locations
>> # of the jar files, or fix the scripts to use that.
>> install -m 644 
>> /home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar 
>> /usr/share/ovirt-engine/engine-config/lib/
>> install: cannot stat 
>> `/home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar': 
>> No such file or directory
>> make: *** [install_config] Error 1
>>
>>
>> 3) can not start jboss-as after deploy ovirt-engine.
>>  $# service jboss-as start
>> =========================================================================
>>
>>   JBoss Bootstrap Environment
>>
>>   JBOSS_HOME: /usr/share/jboss-as
>>
>>   JAVA: java
>>
>>   JAVA_OPTS:  -server -XX:+UseCompressedOops -XX:+TieredCompilation 
>> -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4S
>> tack=true -Dorg.jboss.resolver.warning=true 
>> -Dsun.rmi.dgc.client.gcInterval=3600000 
>> -Dsun.rmi.dgc.server.gcInterval=3600000 -Djb
>> oss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true 
>> -Djboss.server.default.config=standalone.xml
>>
>> =========================================================================
>>
>> 10:39:51,401 INFO  [org.jboss.modules] JBoss Modules version 1.1.1.GA
>> 10:39:51,643 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
>> 10:39:51,682 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final 
>> "Brontes" starting
>> 10:39:51,689 ERROR [org.jboss.msc.service.fail] MSC00001: Failed to 
>> start service jboss.as: org.jboss.msc.service.StartException
>>  in service jboss.as: Failed to start service
>>         at 
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) 
>> [jboss-msc-1.0.2.GA.jar:1.
>> 0.2.GA]
>>         at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
>> [rt.jar:1.7.0_b147-icedtea]
>>         at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
>> [rt.jar:1.7.0_b147-icedtea]
>>         at java.lang.Thread.run(Thread.java:722) 
>> [rt.jar:1.7.0_b147-icedtea]
>> Caused by: java.lang.IllegalStateException: JBAS014922: Directory 
>> /usr/share/jboss-as/standalone/data/content is not writable
>>         at 
>> org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123)
>>         at 
>> org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97)
>>         at 
>> org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134) 
>> [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>>         at 
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) 
>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>>         at 
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) 
>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>>         ... 3 more
>>
>> 10:39:51,694 ERROR [stderr] java.util.concurrent.ExecutionException: 
>> Operation failed
>> 10:39:51,695 ERROR [stderr]     at 
>> org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>> 10:39:51,695 ERROR [stderr]     at 
>> org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>> 10:39:51,695 ERROR [stderr]     at 
>> org.jboss.as.server.Main.main(Main.java:98)
>> 10:39:51,695 ERROR [stderr]     at 
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 10:39:51,695 ERROR [stderr]     at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> 10:39:51,707 ERROR [stderr]     at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 10:39:51,707 ERROR [stderr]     at 
>> java.lang.reflect.Method.invoke(Method.java:601)
>> 10:39:51,708 ERROR [stderr]     at 
>> org.jboss.modules.Module.run(Module.java:260)
>> 10:39:51,708 ERROR [stderr]     at 
>> org.jboss.modules.Main.main(Main.java:291)
>> 10:39:51,708 ERROR [stderr] Caused by: 
>> org.jboss.msc.service.StartException in service jboss.as: Failed to 
>> start service
>> 10:39:51,708 ERROR [stderr]     at 
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767)
>> 10:39:51,708 ERROR [stderr]     at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>> 10:39:51,708 ERROR [stderr]     at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>> 10:39:51,709 ERROR [stderr]     at java.lang.Thread.run(Thread.java:722)
>> 10:39:51,709 ERROR [stderr] Caused by: 
>> java.lang.IllegalStateException: JBAS014922: Directory 
>> /usr/share/jboss-as/standalone/data/content is not writable
>> 10:39:51,709 ERROR [stderr]     at 
>> org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123)
>> 10:39:51,709 ERROR [stderr]     at 
>> org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97)
>> 10:39:51,709 ERROR [stderr]     at 
>> org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134)
>> 10:39:51,710 ERROR [stderr]     at 
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>> 10:39:51,710 ERROR [stderr]     at 
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>> 10:39:51,710 ERROR [stderr]     ... 3 more
>> 13469
>>
>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
> -- 
> Shu Ming<shuming at linux.vnet.ibm.com>
> IBM China Systems and Technology Laboratory

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

From amureini at redhat.com  Wed Jun 13 09:08:17 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Wed, 13 Jun 2012 05:08:17 -0400 (EDT)
Subject: [Engine-devel] Forking unit tests
In-Reply-To: <4a850bd6-def5-4c04-ba84-5411feddba81@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <a0129773-e606-489b-95fb-bd8e52528dab@zmail17.collab.prod.int.phx2.redhat.com>

Hi guys,

If you're using settings.xml as published in Building the oVirt Engine page, you'd see we're forking for every test, in every subproject.
This behaviour was introduced to handle memory leaks in PowerMock we use in some subprojects, but is redundant in others.

Over the past month or so I've been working on removing PowerMock from as many places as possible (many thanks to mkolesni and lhornyak!), and we've got to the stage that forking is only needed in to subprojects - bll and resttypes.
The forking was defined explicitly in those two projects, so if you want to speed up your tests, just take the latest version of settings.xml from http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.


-Allon


From mkolesni at redhat.com  Wed Jun 13 10:28:36 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Wed, 13 Jun 2012 06:28:36 -0400 (EDT)
Subject: [Engine-devel] Forking unit tests
In-Reply-To: <a0129773-e606-489b-95fb-bd8e52528dab@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <c4e998a3-8142-4ff6-946f-814ba2884849@zmail14.collab.prod.int.phx2.redhat.com>

> Hi guys,
> 
> If you're using settings.xml as published in Building the oVirt
> Engine page, you'd see we're forking for every test, in every
> subproject.
> This behaviour was introduced to handle memory leaks in PowerMock we
> use in some subprojects, but is redundant in others.
> 
> Over the past month or so I've been working on removing PowerMock
> from as many places as possible (many thanks to mkolesni and
> lhornyak!), and we've got to the stage that forking is only needed
> in to subprojects - bll and resttypes.

+1 - great job!

Would it be possible to have this as a parameter (defaul true) that can be overridden, such as -Dengine.forkTests=false ?

> The forking was defined explicitly in those two projects, so if you
> want to speed up your tests, just take the latest version of
> settings.xml from
> http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.
> 
> 
> -Allon
> 


From yzaslavs at redhat.com  Wed Jun 13 11:11:37 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 13 Jun 2012 14:11:37 +0300
Subject: [Engine-devel] Cleanup of deployment leftovers - troubleshooting tip
Message-ID: <4FD87569.7060201@redhat.com>

Hi all,
Yesterday I encountered a situation that even though I performed local
build on my environment and deployed , engine application over JBOSS
acted as if it does not contain the changed code (upon deployment).
In the past I encountered such issues with tomcat.
I came (thanks to Juan Hernandez) with some instructions in what do do
in such a situation,

You can find them  at http://ovirt.org/wiki/Building_oVirt_engine under
the Troubleshooting section

Yair


From eedri at redhat.com  Wed Jun 13 11:30:16 2012
From: eedri at redhat.com (Eyal Edri)
Date: Wed, 13 Jun 2012 07:30:16 -0400 (EDT)
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build #
	1224 - Still Unstable!
In-Reply-To: <183288428.881339586242433.JavaMail.jenkins@ip-10-114-123-188>
Message-ID: <cc3b0b73-fe00-4456-b88b-c1d736d22275@zmail17.collab.prod.int.phx2.redhat.com>

FYI,

Jenkins findbugs plugin detected a HIGH priority bug in these commits, please handle:

http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/1217/

Eyal.

----- 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, derez at redhat.com
> Sent: Wednesday, June 13, 2012 2:17:22 PM
> Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 1224 - Still Unstable!
> 
> Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/
> Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/1224/
> Build Number: 1224
> Build Status:  Still Unstable
> Triggered By: Started by upstream project "ovirt_engine" build number
> 1,650
> 
> -------------------------------------
> Changes Since Last Success:
> -------------------------------------
> Changes for Build #1217
> [oliel] restapi: Fix RSDL Generics Issue
> 
> [oliel] restapi: Expose Current Time
> 
> 
> Changes for Build #1218
> [oliel] restapi: Add Search Capabilities To Disks
> 
> [oliel] restapi: Redefine Host Cores And Sockets
> 
> 
> Changes for Build #1219
> [oliel] Update API test with searchable disks
> 
> [lhornyak] restapi: Handle PermGen leak for Maven 3
> 
> 
> Changes for Build #1220
> [mkublin] core: Removing @Remote annotattion from Backend bean
> 
> [juan.hernandez] core: Remove dependency on org.jboss.interceptor
> 
> 
> Changes for Build #1221
> 
> Changes for Build #1222
> [gchaplik] core: import more than once - validate new name
> 
> [gchaplik] webadmin: import more than once - validate new name
> 
> [gchaplik] engine: fix typo ImportVmTemplateParameters
> 
> 
> Changes for Build #1223
> [tnisan] core: Added GetManagementInterfaceAddressByVdsId query
> 
> [tnisan] webadmin: Set Spice & VNC console models to use different
> query
> 
> 
> Changes for Build #1224
> [derez] webadmin: Missing RemoveDisk enum to LocalizedEnums
> 
> 
> 
> 
> -----------------
> Failed Tests:
> -----------------
> No tests ran.
> 
> ------------------
> Build Log:
> ------------------
> [...truncated 2650 lines...]
> [INFO] skip non existing resourceDirectory
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:2.3.2:testCompile
> (default-testCompile) @ rm-war ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.7.2:test (default-test) @ rm-war
> ---
> [INFO] Tests are skipped.
> [INFO]
> [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ rm-war ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [rm-war] in
> [/ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/target/rm-war-3.1.0-0001]
> [INFO] Processing war project
> [INFO] Copying webapp resources
> [/ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/src/main/webapp]
> [INFO] Webapp assembled in [3 msecs]
> [INFO] Building war:
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/target/rm-war-3.1.0-0001.war
> [INFO] WEB-INF/web.xml already added, skipping
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> rm-war ---
> [INFO] Installing
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/target/rm-war-3.1.0-0001.war
> to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/rm-war/3.1.0-0001/rm-war-3.1.0-0001.war
> [INFO] Installing
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/pom.xml to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/rm-war/3.1.0-0001/rm-war-3.1.0-0001.pom
> [INFO]
> [INFO] --- findbugs-maven-plugin:2.5:findbugs (default-cli) @ rm-war
> ---
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building oVirt Web Application Module 3.1.0-0001
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ rmw-war
> ---
> [INFO] Deleting
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/target
> [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] Compiling 4 source files to
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/classes
> [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.1.0-0001]
> [INFO] Processing war project
> [INFO] Copying webapp resources
> [/ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/src/main/webapp]
> [INFO] Webapp assembled in [9 msecs]
> [INFO] Building war:
> /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/rmw-war-3.1.0-0001.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.1.0-0001.war
> to
> /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/rmw-war/3.1.0-0001/rmw-war-3.1.0-0001.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.1.0-0001/rmw-war-3.1.0-0001.pom
> [INFO]
> [INFO] --- findbugs-maven-plugin:2.5:findbugs (default-cli) @ rmw-war
> ---
> [INFO] Fork Value is true
> [INFO] Done FindBugs Analysis....
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building oVirt Server EAR 3.1.0-0001
> [INFO]
> ------------------------------------------------------------------------
> Downloading:
> http://repo1.maven.org/maven2/org/codehaus/mojo/gwt-maven-plugin/1.3.2.google/gwt-maven-plugin-1.3.2.google.pom
> 
> [WARNING] The POM for
> org.codehaus.mojo:gwt-maven-plugin:jar:1.3.2.google is missing, no
> dependency information available
> [WARNING] Failed to retrieve plugin descriptor for
> org.codehaus.mojo:gwt-maven-plugin:1.3.2.google: Plugin
> org.codehaus.mojo:gwt-maven-plugin:1.3.2.google or one of its
> dependencies could not be resolved: Failed to read artifact
> descriptor for org.codehaus.mojo:gwt-maven-plugin:jar:1.3.2.google
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
> engine-server-ear ---
> [INFO] Deleting /ephemeral0/ovirt_engine_find_bugs/ear/target
> [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.1.0-0001]
> to[lib/engine-common.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:compat:3.1.0-0001]
> to[lib/engine-compat.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0-0001]
> to[lib/engine-dal.jar]
> [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0-0001]
> to[lib/engine-utils.jar]
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0-0001]
> to[lib/engine-encryptutils.jar]
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0-0001]
> to[lib/engine-vdsbroker.jar]
> [INFO] Copying
> artifact[war:org.ovirt.engine.core:root-war:3.1.0-0001] to[root.war]
> (unpacked)
> [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0-0001]
> to[ovirtengineweb.war] (unpacked)
> [INFO] Copying artifact[war:org.ovirt.engine.ui:rm-war:3.1.0-0001]
> to[ovirtengine.war] (unpacked)
> [INFO] Copying
> artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0-0001]
> to[restapi.war] (unpacked)
> [INFO] Copying
> artifact[war:org.ovirt.engine.ui:userportal:3.1.0-0001]
> to[userportal.war] (unpacked)
> [INFO] Copying artifact[war:org.ovirt.engine.ui:webadmin:3.1.0-0001]
> to[webadmin.war] (unpacked)
> [INFO] Copying
> artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0-0001]
> to[engine-genericapi.jar] (unpacked)
> [INFO] Copying
> artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0-0001]
> to[engine-scheduler.jar] (unpacked)
> [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0-0001]
> to[engine-bll.jar] (unpacked)
> [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4]
> to[lib/commons-codec-1.4.jar]
> [INFO] Copying
> artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA]
> to[lib/hibernate-validator-4.0.2.GA.jar]
> [INFO] Copying artifact[jar:javax.validation:validation-api:1.0.0.GA]
> to[lib/validation-api-1.0.0.GA.jar]
> [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6]
> to[lib/slf4j-api-1.5.6.jar]
> [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1]
> to[lib/jaxb-api-2.1.jar]
> [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2]
> to[lib/stax-api-1.0-2.jar]
> [INFO] Copying artifact[jar:javax.activation:activation:1.1]
> to[lib/activation-1.1.jar]
> [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3]
> to[lib/jaxb-impl-2.1.3.jar]
> [INFO] Copying
> artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA]
> to[lib/hibernate-annotations-3.4.0.GA.jar]
> [INFO] Copying artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA]
> to[lib/ejb3-persistence-1.0.2.GA.jar]
> [INFO] Copying
> artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA]
> to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
> [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1]
> to[lib/hibernate-core-3.3.0.SP1.jar]
> [INFO] Copying artifact[jar:antlr:antlr:2.7.6]
> to[lib/antlr-2.7.6.jar]
> [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1]
> to[lib/dom4j-1.6.1.jar]
> [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2]
> to[lib/xml-apis-1.0.b2.jar]
> [INFO] Copying
> artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final]
> to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0-0001]
> to[lib/engine-tools-common-3.1.0-0001.jar]
> [INFO] Copying
> artifact[jar:commons-beanutils:commons-beanutils:1.8.2]
> to[lib/commons-beanutils-1.8.2.jar]
> [INFO] Copying artifact[jar:com.jcraft:jsch:0.1.42]
> to[lib/jsch-0.1.42.jar]
> [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1]
> to[lib/mina-core-2.0.1.jar]
> [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.6.0]
> to[lib/sshd-core-0.6.0.jar]
> [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4]
> to[lib/commons-lang-2.4.jar]
> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3]
> to[lib/xmlrpc-client-3.1.3.jar]
> [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3]
> to[lib/xmlrpc-common-3.1.3.jar]
> [INFO] Copying
> artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2]
> to[lib/ws-commons-util-1.0.2.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-jdbc:2.5.6.SEC02]
> to[lib/spring-jdbc-2.5.6.SEC02.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-tx:2.5.6.SEC02]
> to[lib/spring-tx-2.5.6.SEC02.jar]
> [INFO] Copying
> artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.0.RELEASE]
> to[lib/spring-ldap-core-1.3.0.RELEASE.jar]
> [INFO] Copying
> artifact[jar:commons-httpclient:commons-httpclient:3.1]
> to[lib/commons-httpclient-3.1.jar]
> [INFO] Copying
> artifact[jar:commons-collections:commons-collections:3.1]
> to[lib/commons-collections-3.1.jar]
> [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2]
> to[lib/quartz-2.1.2.jar]
> [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1]
> to[lib/c3p0-0.9.1.1.jar]
> [INFO] Copying
> artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0-0001]
> to[lib/searchbackend-3.1.0-0001.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-core:2.5.6.SEC02]
> to[lib/spring-core-2.5.6.SEC02.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-beans:2.5.6.SEC02]
> to[lib/spring-beans-2.5.6.SEC02.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-context:2.5.6.SEC02]
> to[lib/spring-context-2.5.6.SEC02.jar]
> [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0]
> to[lib/aopalliance-1.0.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-agent:2.5.6.SEC02]
> to[lib/spring-agent-2.5.6.SEC02.jar]
> [INFO] Copying
> artifact[jar:org.springframework:spring-aop:2.5.6.SEC02]
> to[lib/spring-aop-2.5.6.SEC02.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.1.0-0001/engine-server-ear-3.1.0-0001.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.1.0-0001/engine-server-ear-3.1.0-0001.pom
> [INFO]
> [INFO] --- findbugs-maven-plugin:2.5:findbugs (default-cli) @
> engine-server-ear ---
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] oVirt Engine Root Project ......................... SUCCESS
> [2.914s]
> [INFO] oVirt Build Tools root ............................ SUCCESS
> [0.128s]
> [INFO] oVirt checkstyle .................................. SUCCESS
> [1.504s]
> [INFO] oVirt Checkstyle Checks ........................... SUCCESS
> [16.852s]
> [INFO] oVirt Modules - backend ........................... SUCCESS
> [0.102s]
> [INFO] oVirt Manager ..................................... SUCCESS
> [0.242s]
> [INFO] oVirt DB Scripts .................................. SUCCESS
> [0.750s]
> [INFO] oVirt Modules - manager ........................... SUCCESS
> [1.222s]
> [INFO] CSharp Compatibility .............................. SUCCESS
> [42.538s]
> [INFO] Encryption Libraries .............................. SUCCESS
> [20.725s]
> [INFO] oVirt Tools ....................................... SUCCESS
> [0.129s]
> [INFO] oVirt Tools Common Library ........................ SUCCESS
> [13.544s]
> [INFO] Common Code ....................................... SUCCESS
> [1:12.654s]
> [INFO] Common utilities .................................. SUCCESS
> [52.148s]
> [INFO] Data Access Layer ................................. SUCCESS
> [54.063s]
> [INFO] engine beans ...................................... SUCCESS
> [0.206s]
> [INFO] engine scheduler bean ............................. SUCCESS
> [21.790s]
> [INFO] Vds broker ........................................ SUCCESS
> [51.661s]
> [INFO] Search Backend .................................... SUCCESS
> [32.565s]
> [INFO] Backend Logic @Service bean ....................... SUCCESS
> [1:52.245s]
> [INFO] oVirt RESTful API Backend Integration ............. SUCCESS
> [0.243s]
> [INFO] oVirt RESTful API interface ....................... SUCCESS
> [0.214s]
> [INFO] oVirt Engine API Definition ....................... SUCCESS
> [40.016s]
> [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
> [0.211s]
> [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
> [36.584s]
> [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
> [34.977s]
> [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
>  SUCCESS [58.550s]
> [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
> [5.204s]
> [INFO] oVirt Engine Web Root ............................. SUCCESS
> [16.110s]
> [INFO] oVirt Configuration Tool .......................... SUCCESS
> [27.754s]
> [INFO] Notifier Service package .......................... SUCCESS
> [0.090s]
> [INFO] Notifier Service .................................. SUCCESS
> [30.927s]
> [INFO] Notifier Service Resources ........................ SUCCESS
> [5.056s]
> [INFO] oVirt Modules - frontend .......................... SUCCESS
> [1.073s]
> [INFO] oVirt APIs ........................................ SUCCESS
> [0.529s]
> [INFO] oVirt generic API ................................. SUCCESS
> [20.619s]
> [INFO] oVirt Modules - webadmin .......................... SUCCESS
> [0.042s]
> [INFO] oVirt Modules - ui ................................ SUCCESS
> [0.087s]
> [INFO] Extensions for GWT ................................ SUCCESS
> [47.819s]
> [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
> [27.623s]
> [INFO] Frontend for GWT UI Projects ...................... SUCCESS
> [30.490s]
> [INFO] UICommonWeb ....................................... SUCCESS
> [1:43.265s]
> [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
> [1:12.229s]
> [INFO] WebAdmin .......................................... SUCCESS
> [1:29.964s]
> [INFO] UserPortal ........................................ SUCCESS
> [50.107s]
> [INFO] oVirt WARs ........................................ SUCCESS
> [0.029s]
> [INFO] WPF Application Module ............................ SUCCESS
> [4.889s]
> [INFO] oVirt Web Application Module ...................... SUCCESS
> [21.794s]
> [INFO] oVirt Server EAR .................................. SUCCESS
> [8.703s]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 20:35.645s
> [INFO] Finished at: Wed Jun 13 07:16:01 EDT 2012
> [INFO] Final Memory: 326M/759M
> [INFO]
> ------------------------------------------------------------------------
> [FINDBUGS] Collecting findbugs analysis files...
> [FINDBUGS] Parsing 30 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 1 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/vdsbroker/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 429 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/common/target/findbugsXml.xml
> of module  with 269 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/compat/target/findbugsXml.xml
> of module  with 71 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 10 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 18 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 24 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/types/target/findbugsXml.xml
> of module  with 10 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/root/target/findbugsXml.xml
> of module  with 5 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/searchbackend/target/findbugsXml.xml
> of module  with 13 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/utils/target/findbugsXml.xml
> of module  with 113 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/vdsbroker/target/findbugsXml.xml
> of module  with 234 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 0 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/api/genericapi/target/findbugsXml.xml
> of module  with 2 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 22 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml
> of module  with 68 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml
> of module  with 29 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommon/target/findbugsXml.xml
> of module  with 417 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommonweb/target/findbugsXml.xml
> of module  with 610 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicompat/target/findbugsXml.xml
> of module  with 40 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/findbugsXml.xml
> of module  with 12 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal/target/findbugsXml.xml
> of module  with 118 warnings.
> [FINDBUGS] Successfully parsed file
> /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/findbugsXml.xml
> of module  with 56 warnings.
> [FINDBUGS] Computing warning deltas based on reference build #1216
> Build step 'Publish FindBugs analysis results' changed build result
> to UNSTABLE
> Email was triggered for: Unstable
> Sending email for trigger: Unstable
> 
> 


From lhornyak at redhat.com  Wed Jun 13 11:32:45 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 13 Jun 2012 07:32:45 -0400 (EDT)
Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build
	#	1224 - Still Unstable!
In-Reply-To: <cc3b0b73-fe00-4456-b88b-c1d736d22275@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <7121230d-03a5-4985-ab01-b45e4cb9770a@zmail03.collab.prod.int.phx2.redhat.com>

Hi!

I have already sent a patch for this, please review:
http://gerrit.ovirt.org/#/c/5304/

Thank you,
Laszlo

----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, June 13, 2012 1:30:16 PM
> Subject: Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build #	1224 - Still Unstable!
> 
> FYI,
> 
> Jenkins findbugs plugin detected a HIGH priority bug in these
> commits, please handle:
> 
> http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/1217/
> 
> Eyal.
> 
> ----- 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, derez at redhat.com
> > Sent: Wednesday, June 13, 2012 2:17:22 PM
> > Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 1224 -
> > Still Unstable!
> > 
> > Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/
> > Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/1224/
> > Build Number: 1224
> > Build Status:  Still Unstable
> > Triggered By: Started by upstream project "ovirt_engine" build
> > number
> > 1,650
> > 
> > -------------------------------------
> > Changes Since Last Success:
> > -------------------------------------
> > Changes for Build #1217
> > [oliel] restapi: Fix RSDL Generics Issue
> > 
> > [oliel] restapi: Expose Current Time
> > 
> > 
> > Changes for Build #1218
> > [oliel] restapi: Add Search Capabilities To Disks
> > 
> > [oliel] restapi: Redefine Host Cores And Sockets
> > 
> > 
> > Changes for Build #1219
> > [oliel] Update API test with searchable disks
> > 
> > [lhornyak] restapi: Handle PermGen leak for Maven 3
> > 
> > 
> > Changes for Build #1220
> > [mkublin] core: Removing @Remote annotattion from Backend bean
> > 
> > [juan.hernandez] core: Remove dependency on org.jboss.interceptor
> > 
> > 
> > Changes for Build #1221
> > 
> > Changes for Build #1222
> > [gchaplik] core: import more than once - validate new name
> > 
> > [gchaplik] webadmin: import more than once - validate new name
> > 
> > [gchaplik] engine: fix typo ImportVmTemplateParameters
> > 
> > 
> > Changes for Build #1223
> > [tnisan] core: Added GetManagementInterfaceAddressByVdsId query
> > 
> > [tnisan] webadmin: Set Spice & VNC console models to use different
> > query
> > 
> > 
> > Changes for Build #1224
> > [derez] webadmin: Missing RemoveDisk enum to LocalizedEnums
> > 
> > 
> > 
> > 
> > -----------------
> > Failed Tests:
> > -----------------
> > No tests ran.
> > 
> > ------------------
> > Build Log:
> > ------------------
> > [...truncated 2650 lines...]
> > [INFO] skip non existing resourceDirectory
> > /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/src/test/resources
> > [INFO]
> > [INFO] --- maven-compiler-plugin:2.3.2:testCompile
> > (default-testCompile) @ rm-war ---
> > [INFO] No sources to compile
> > [INFO]
> > [INFO] --- maven-surefire-plugin:2.7.2:test (default-test) @ rm-war
> > ---
> > [INFO] Tests are skipped.
> > [INFO]
> > [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ rm-war ---
> > [INFO] Packaging webapp
> > [INFO] Assembling webapp [rm-war] in
> > [/ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/target/rm-war-3.1.0-0001]
> > [INFO] Processing war project
> > [INFO] Copying webapp resources
> > [/ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/src/main/webapp]
> > [INFO] Webapp assembled in [3 msecs]
> > [INFO] Building war:
> > /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/target/rm-war-3.1.0-0001.war
> > [INFO] WEB-INF/web.xml already added, skipping
> > [INFO]
> > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> > rm-war ---
> > [INFO] Installing
> > /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/target/rm-war-3.1.0-0001.war
> > to
> > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/rm-war/3.1.0-0001/rm-war-3.1.0-0001.war
> > [INFO] Installing
> > /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rm-war/pom.xml to
> > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/rm-war/3.1.0-0001/rm-war-3.1.0-0001.pom
> > [INFO]
> > [INFO] --- findbugs-maven-plugin:2.5:findbugs (default-cli) @
> > rm-war
> > ---
> > [INFO]
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Building oVirt Web Application Module 3.1.0-0001
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO]
> > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ rmw-war
> > ---
> > [INFO] Deleting
> > /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/target
> > [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] Compiling 4 source files to
> > /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/classes
> > [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.1.0-0001]
> > [INFO] Processing war project
> > [INFO] Copying webapp resources
> > [/ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/src/main/webapp]
> > [INFO] Webapp assembled in [9 msecs]
> > [INFO] Building war:
> > /ephemeral0/ovirt_engine_find_bugs/frontend/wars/rmw-war/target/rmw-war-3.1.0-0001.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.1.0-0001.war
> > to
> > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/rmw-war/3.1.0-0001/rmw-war-3.1.0-0001.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.1.0-0001/rmw-war-3.1.0-0001.pom
> > [INFO]
> > [INFO] --- findbugs-maven-plugin:2.5:findbugs (default-cli) @
> > rmw-war
> > ---
> > [INFO] Fork Value is true
> > [INFO] Done FindBugs Analysis....
> > [INFO]
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Building oVirt Server EAR 3.1.0-0001
> > [INFO]
> > ------------------------------------------------------------------------
> > Downloading:
> > http://repo1.maven.org/maven2/org/codehaus/mojo/gwt-maven-plugin/1.3.2.google/gwt-maven-plugin-1.3.2.google.pom
> > 
> > [WARNING] The POM for
> > org.codehaus.mojo:gwt-maven-plugin:jar:1.3.2.google is missing, no
> > dependency information available
> > [WARNING] Failed to retrieve plugin descriptor for
> > org.codehaus.mojo:gwt-maven-plugin:1.3.2.google: Plugin
> > org.codehaus.mojo:gwt-maven-plugin:1.3.2.google or one of its
> > dependencies could not be resolved: Failed to read artifact
> > descriptor for org.codehaus.mojo:gwt-maven-plugin:jar:1.3.2.google
> > [INFO]
> > [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @
> > engine-server-ear ---
> > [INFO] Deleting /ephemeral0/ovirt_engine_find_bugs/ear/target
> > [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.1.0-0001]
> > to[lib/engine-common.jar]
> > [INFO] Copying
> > artifact[jar:org.ovirt.engine.core:compat:3.1.0-0001]
> > to[lib/engine-compat.jar]
> > [INFO] Copying artifact[jar:org.ovirt.engine.core:dal:3.1.0-0001]
> > to[lib/engine-dal.jar]
> > [INFO] Copying artifact[jar:org.ovirt.engine.core:utils:3.1.0-0001]
> > to[lib/engine-utils.jar]
> > [INFO] Copying
> > artifact[jar:org.ovirt.engine.core:engineencryptutils:3.1.0-0001]
> > to[lib/engine-encryptutils.jar]
> > [INFO] Copying
> > artifact[jar:org.ovirt.engine.core:vdsbroker:3.1.0-0001]
> > to[lib/engine-vdsbroker.jar]
> > [INFO] Copying
> > artifact[war:org.ovirt.engine.core:root-war:3.1.0-0001]
> > to[root.war]
> > (unpacked)
> > [INFO] Copying artifact[war:org.ovirt.engine.ui:rmw-war:3.1.0-0001]
> > to[ovirtengineweb.war] (unpacked)
> > [INFO] Copying artifact[war:org.ovirt.engine.ui:rm-war:3.1.0-0001]
> > to[ovirtengine.war] (unpacked)
> > [INFO] Copying
> > artifact[war:org.ovirt.engine.api:restapi-webapp:3.1.0-0001]
> > to[restapi.war] (unpacked)
> > [INFO] Copying
> > artifact[war:org.ovirt.engine.ui:userportal:3.1.0-0001]
> > to[userportal.war] (unpacked)
> > [INFO] Copying
> > artifact[war:org.ovirt.engine.ui:webadmin:3.1.0-0001]
> > to[webadmin.war] (unpacked)
> > [INFO] Copying
> > artifact[ejb:org.ovirt.engine.ui:genericapi:3.1.0-0001]
> > to[engine-genericapi.jar] (unpacked)
> > [INFO] Copying
> > artifact[ejb:org.ovirt.engine.core:scheduler:3.1.0-0001]
> > to[engine-scheduler.jar] (unpacked)
> > [INFO] Copying artifact[ejb:org.ovirt.engine.core:bll:3.1.0-0001]
> > to[engine-bll.jar] (unpacked)
> > [INFO] Copying artifact[jar:commons-codec:commons-codec:1.4]
> > to[lib/commons-codec-1.4.jar]
> > [INFO] Copying
> > artifact[jar:org.hibernate:hibernate-validator:4.0.2.GA]
> > to[lib/hibernate-validator-4.0.2.GA.jar]
> > [INFO] Copying
> > artifact[jar:javax.validation:validation-api:1.0.0.GA]
> > to[lib/validation-api-1.0.0.GA.jar]
> > [INFO] Copying artifact[jar:org.slf4j:slf4j-api:1.5.6]
> > to[lib/slf4j-api-1.5.6.jar]
> > [INFO] Copying artifact[jar:javax.xml.bind:jaxb-api:2.1]
> > to[lib/jaxb-api-2.1.jar]
> > [INFO] Copying artifact[jar:javax.xml.stream:stax-api:1.0-2]
> > to[lib/stax-api-1.0-2.jar]
> > [INFO] Copying artifact[jar:javax.activation:activation:1.1]
> > to[lib/activation-1.1.jar]
> > [INFO] Copying artifact[jar:com.sun.xml.bind:jaxb-impl:2.1.3]
> > to[lib/jaxb-impl-2.1.3.jar]
> > [INFO] Copying
> > artifact[jar:org.hibernate:hibernate-annotations:3.4.0.GA]
> > to[lib/hibernate-annotations-3.4.0.GA.jar]
> > [INFO] Copying
> > artifact[jar:org.hibernate:ejb3-persistence:1.0.2.GA]
> > to[lib/ejb3-persistence-1.0.2.GA.jar]
> > [INFO] Copying
> > artifact[jar:org.hibernate:hibernate-commons-annotations:3.1.0.GA]
> > to[lib/hibernate-commons-annotations-3.1.0.GA.jar]
> > [INFO] Copying artifact[jar:org.hibernate:hibernate-core:3.3.0.SP1]
> > to[lib/hibernate-core-3.3.0.SP1.jar]
> > [INFO] Copying artifact[jar:antlr:antlr:2.7.6]
> > to[lib/antlr-2.7.6.jar]
> > [INFO] Copying artifact[jar:dom4j:dom4j:1.6.1]
> > to[lib/dom4j-1.6.1.jar]
> > [INFO] Copying artifact[jar:xml-apis:xml-apis:1.0.b2]
> > to[lib/xml-apis-1.0.b2.jar]
> > [INFO] Copying
> > artifact[jar:org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final]
> > to[lib/jboss-interceptors-api_1.1_spec-1.0.0.Final.jar]
> > [INFO] Copying
> > artifact[jar:org.ovirt.engine.core:engine-tools-common:3.1.0-0001]
> > to[lib/engine-tools-common-3.1.0-0001.jar]
> > [INFO] Copying
> > artifact[jar:commons-beanutils:commons-beanutils:1.8.2]
> > to[lib/commons-beanutils-1.8.2.jar]
> > [INFO] Copying artifact[jar:com.jcraft:jsch:0.1.42]
> > to[lib/jsch-0.1.42.jar]
> > [INFO] Copying artifact[jar:org.apache.mina:mina-core:2.0.1]
> > to[lib/mina-core-2.0.1.jar]
> > [INFO] Copying artifact[jar:org.apache.sshd:sshd-core:0.6.0]
> > to[lib/sshd-core-0.6.0.jar]
> > [INFO] Copying artifact[jar:commons-lang:commons-lang:2.4]
> > to[lib/commons-lang-2.4.jar]
> > [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-client:3.1.3]
> > to[lib/xmlrpc-client-3.1.3.jar]
> > [INFO] Copying artifact[jar:org.apache.xmlrpc:xmlrpc-common:3.1.3]
> > to[lib/xmlrpc-common-3.1.3.jar]
> > [INFO] Copying
> > artifact[jar:org.apache.ws.commons.util:ws-commons-util:1.0.2]
> > to[lib/ws-commons-util-1.0.2.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-jdbc:2.5.6.SEC02]
> > to[lib/spring-jdbc-2.5.6.SEC02.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-tx:2.5.6.SEC02]
> > to[lib/spring-tx-2.5.6.SEC02.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework.ldap:spring-ldap-core:1.3.0.RELEASE]
> > to[lib/spring-ldap-core-1.3.0.RELEASE.jar]
> > [INFO] Copying
> > artifact[jar:commons-httpclient:commons-httpclient:3.1]
> > to[lib/commons-httpclient-3.1.jar]
> > [INFO] Copying
> > artifact[jar:commons-collections:commons-collections:3.1]
> > to[lib/commons-collections-3.1.jar]
> > [INFO] Copying artifact[jar:org.quartz-scheduler:quartz:2.1.2]
> > to[lib/quartz-2.1.2.jar]
> > [INFO] Copying artifact[jar:c3p0:c3p0:0.9.1.1]
> > to[lib/c3p0-0.9.1.1.jar]
> > [INFO] Copying
> > artifact[jar:org.ovirt.engine.core:searchbackend:3.1.0-0001]
> > to[lib/searchbackend-3.1.0-0001.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-core:2.5.6.SEC02]
> > to[lib/spring-core-2.5.6.SEC02.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-beans:2.5.6.SEC02]
> > to[lib/spring-beans-2.5.6.SEC02.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-context:2.5.6.SEC02]
> > to[lib/spring-context-2.5.6.SEC02.jar]
> > [INFO] Copying artifact[jar:aopalliance:aopalliance:1.0]
> > to[lib/aopalliance-1.0.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-agent:2.5.6.SEC02]
> > to[lib/spring-agent-2.5.6.SEC02.jar]
> > [INFO] Copying
> > artifact[jar:org.springframework:spring-aop:2.5.6.SEC02]
> > to[lib/spring-aop-2.5.6.SEC02.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.1.0-0001/engine-server-ear-3.1.0-0001.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.1.0-0001/engine-server-ear-3.1.0-0001.pom
> > [INFO]
> > [INFO] --- findbugs-maven-plugin:2.5:findbugs (default-cli) @
> > engine-server-ear ---
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Reactor Summary:
> > [INFO]
> > [INFO] oVirt Engine Root Project ......................... SUCCESS
> > [2.914s]
> > [INFO] oVirt Build Tools root ............................ SUCCESS
> > [0.128s]
> > [INFO] oVirt checkstyle .................................. SUCCESS
> > [1.504s]
> > [INFO] oVirt Checkstyle Checks ........................... SUCCESS
> > [16.852s]
> > [INFO] oVirt Modules - backend ........................... SUCCESS
> > [0.102s]
> > [INFO] oVirt Manager ..................................... SUCCESS
> > [0.242s]
> > [INFO] oVirt DB Scripts .................................. SUCCESS
> > [0.750s]
> > [INFO] oVirt Modules - manager ........................... SUCCESS
> > [1.222s]
> > [INFO] CSharp Compatibility .............................. SUCCESS
> > [42.538s]
> > [INFO] Encryption Libraries .............................. SUCCESS
> > [20.725s]
> > [INFO] oVirt Tools ....................................... SUCCESS
> > [0.129s]
> > [INFO] oVirt Tools Common Library ........................ SUCCESS
> > [13.544s]
> > [INFO] Common Code ....................................... SUCCESS
> > [1:12.654s]
> > [INFO] Common utilities .................................. SUCCESS
> > [52.148s]
> > [INFO] Data Access Layer ................................. SUCCESS
> > [54.063s]
> > [INFO] engine beans ...................................... SUCCESS
> > [0.206s]
> > [INFO] engine scheduler bean ............................. SUCCESS
> > [21.790s]
> > [INFO] Vds broker ........................................ SUCCESS
> > [51.661s]
> > [INFO] Search Backend .................................... SUCCESS
> > [32.565s]
> > [INFO] Backend Logic @Service bean ....................... SUCCESS
> > [1:52.245s]
> > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS
> > [0.243s]
> > [INFO] oVirt RESTful API interface ....................... SUCCESS
> > [0.214s]
> > [INFO] oVirt Engine API Definition ....................... SUCCESS
> > [40.016s]
> > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS
> > [0.211s]
> > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS
> > [36.584s]
> > [INFO] oVirt RESTful API Backend Integration Type Mappers  SUCCESS
> > [34.977s]
> > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources
> >  SUCCESS [58.550s]
> > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS
> > [5.204s]
> > [INFO] oVirt Engine Web Root ............................. SUCCESS
> > [16.110s]
> > [INFO] oVirt Configuration Tool .......................... SUCCESS
> > [27.754s]
> > [INFO] Notifier Service package .......................... SUCCESS
> > [0.090s]
> > [INFO] Notifier Service .................................. SUCCESS
> > [30.927s]
> > [INFO] Notifier Service Resources ........................ SUCCESS
> > [5.056s]
> > [INFO] oVirt Modules - frontend .......................... SUCCESS
> > [1.073s]
> > [INFO] oVirt APIs ........................................ SUCCESS
> > [0.529s]
> > [INFO] oVirt generic API ................................. SUCCESS
> > [20.619s]
> > [INFO] oVirt Modules - webadmin .......................... SUCCESS
> > [0.042s]
> > [INFO] oVirt Modules - ui ................................ SUCCESS
> > [0.087s]
> > [INFO] Extensions for GWT ................................ SUCCESS
> > [47.819s]
> > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS
> > [27.623s]
> > [INFO] Frontend for GWT UI Projects ...................... SUCCESS
> > [30.490s]
> > [INFO] UICommonWeb ....................................... SUCCESS
> > [1:43.265s]
> > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS
> > [1:12.229s]
> > [INFO] WebAdmin .......................................... SUCCESS
> > [1:29.964s]
> > [INFO] UserPortal ........................................ SUCCESS
> > [50.107s]
> > [INFO] oVirt WARs ........................................ SUCCESS
> > [0.029s]
> > [INFO] WPF Application Module ............................ SUCCESS
> > [4.889s]
> > [INFO] oVirt Web Application Module ...................... SUCCESS
> > [21.794s]
> > [INFO] oVirt Server EAR .................................. SUCCESS
> > [8.703s]
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] BUILD SUCCESS
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Total time: 20:35.645s
> > [INFO] Finished at: Wed Jun 13 07:16:01 EDT 2012
> > [INFO] Final Memory: 326M/759M
> > [INFO]
> > ------------------------------------------------------------------------
> > [FINDBUGS] Collecting findbugs analysis files...
> > [FINDBUGS] Parsing 30 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 1 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/vdsbroker/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 429 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/common/target/findbugsXml.xml
> > of module  with 269 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/compat/target/findbugsXml.xml
> > of module  with 71 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 10 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 18 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 24 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/types/target/findbugsXml.xml
> > of module  with 10 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/root/target/findbugsXml.xml
> > of module  with 5 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/searchbackend/target/findbugsXml.xml
> > of module  with 13 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/utils/target/findbugsXml.xml
> > of module  with 113 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/vdsbroker/target/findbugsXml.xml
> > of module  with 234 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 0 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/api/genericapi/target/findbugsXml.xml
> > of module  with 2 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 22 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml
> > of module  with 68 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml
> > of module  with 29 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommon/target/findbugsXml.xml
> > of module  with 417 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommonweb/target/findbugsXml.xml
> > of module  with 610 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicompat/target/findbugsXml.xml
> > of module  with 40 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/target/findbugsXml.xml
> > of module  with 12 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal/target/findbugsXml.xml
> > of module  with 118 warnings.
> > [FINDBUGS] Successfully parsed file
> > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/webadmin/target/findbugsXml.xml
> > of module  with 56 warnings.
> > [FINDBUGS] Computing warning deltas based on reference build #1216
> > Build step 'Publish FindBugs analysis results' changed build result
> > to UNSTABLE
> > Email was triggered for: Unstable
> > Sending email for trigger: Unstable
> > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From yzaslavs at redhat.com  Wed Jun 13 11:44:39 2012
From: yzaslavs at redhat.com (Yair Zaslavsky)
Date: Wed, 13 Jun 2012 14:44:39 +0300
Subject: [Engine-devel] Forking unit tests
In-Reply-To: <c4e998a3-8142-4ff6-946f-814ba2884849@zmail14.collab.prod.int.phx2.redhat.com>
References: <c4e998a3-8142-4ff6-946f-814ba2884849@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD87D27.7060707@redhat.com>

On 06/13/2012 01:28 PM, Mike Kolesnik wrote:
>> Hi guys,
>>
>> If you're using settings.xml as published in Building the oVirt
>> Engine page, you'd see we're forking for every test, in every
>> subproject.
>> This behaviour was introduced to handle memory leaks in PowerMock we
>> use in some subprojects, but is redundant in others.
>>
>> Over the past month or so I've been working on removing PowerMock
>> from as many places as possible (many thanks to mkolesni and
>> lhornyak!), and we've got to the stage that forking is only needed
>> in to subprojects - bll and resttypes.
> 
> +1 - great job!
+1
> 
> Would it be possible to have this as a parameter (defaul true) that can be overridden, such as -Dengine.forkTests=false ?+
+1 - good idea.

> 
>> The forking was defined explicitly in those two projects, so if you
>> want to speed up your tests, just take the latest version of
>> settings.xml from
>> http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.
>>
>>
>> -Allon
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From lhornyak at redhat.com  Wed Jun 13 12:41:00 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Wed, 13 Jun 2012 08:41:00 -0400 (EDT)
Subject: [Engine-devel] Forking unit tests
In-Reply-To: <4FD87D27.7060707@redhat.com>
Message-ID: <56c89244-18b2-4602-9742-996868664fe6@zmail03.collab.prod.int.phx2.redhat.com>


We can just move the surefire config to a higher level in the pom hierarchy, but that makes the tests slower globaly.
It is more work, but we could help Allon to rewrite the Powermock tests :-) And then the surefire settings could be removed and the tests will run quick again.

----- Original Message -----
> From: "Yair Zaslavsky" <yzaslavs at redhat.com>
> To: "Mike Kolesnik" <mkolesni at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, June 13, 2012 1:44:39 PM
> Subject: Re: [Engine-devel] Forking unit tests
> 
> On 06/13/2012 01:28 PM, Mike Kolesnik wrote:
> >> Hi guys,
> >>
> >> If you're using settings.xml as published in Building the oVirt
> >> Engine page, you'd see we're forking for every test, in every
> >> subproject.
> >> This behaviour was introduced to handle memory leaks in PowerMock
> >> we
> >> use in some subprojects, but is redundant in others.
> >>
> >> Over the past month or so I've been working on removing PowerMock
> >> from as many places as possible (many thanks to mkolesni and
> >> lhornyak!), and we've got to the stage that forking is only needed
> >> in to subprojects - bll and resttypes.
> > 
> > +1 - great job!
> +1
> > 
> > Would it be possible to have this as a parameter (defaul true) that
> > can be overridden, such as -Dengine.forkTests=false ?+
> +1 - good idea.
> 
> > 
> >> The forking was defined explicitly in those two projects, so if
> >> you
> >> want to speed up your tests, just take the latest version of
> >> settings.xml from
> >> http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.
> >>
> >>
> >> -Allon
> >>
> > _______________________________________________
> > 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 jhernand at redhat.com  Wed Jun 13 12:42:17 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Wed, 13 Jun 2012 14:42:17 +0200
Subject: [Engine-devel] Deploy ovirt-engine error
In-Reply-To: <4FD80231.3020009@linux.vnet.ibm.com>
References: <4FD80231.3020009@linux.vnet.ibm.com>
Message-ID: <4FD88AA9.7030204@redhat.com>

On 06/13/2012 05:00 AM, ShaoHe Feng wrote:
> I follow this guide http://ovirt.org/wiki/Building_oVirt_engine

That page as bit out of date. I am preparing an updated one specifically 
for development environments. It is available here:

http://ovirt.org/wiki/Building_Engine_Draft

I appreciate any feedback.

>
> 1)
> $>  make install_tools
> make: *** No rule to make target `install_tools'.  Stop
>
> I have check the Makefile, there is really no install_tools rule.
>
> 2)
> #>   make install_config
> *** 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 /etc/ovirt-engine/engine-config/
> install -m 644
> backend/manager/tools/engine-config/src/main/resources/engine-config.*properties
> /etc/ovirt-engine/engine-config/
> install -m 644
> backend/manager/tools/engine-config/src/main/resources/log4j.xml
> /etc/ovirt-engine/engine-config/
> # Jar files for the configuration tool:
> # XXX: Should replace with links to the actual locations
> # of the jar files, or fix the scripts to use that.
> install -m 644
> /home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar
> /usr/share/ovirt-engine/engine-config/lib/
> install: cannot stat
> `/home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar':
> No such file or directory
> make: *** [install_config] Error 1
>
>
> 3) can not start jboss-as after deploy ovirt-engine.
>    $# service jboss-as start
> =========================================================================
>
>     JBoss Bootstrap Environment
>
>     JBOSS_HOME: /usr/share/jboss-as
>
>     JAVA: java
>
>     JAVA_OPTS:  -server -XX:+UseCompressedOops -XX:+TieredCompilation
> -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4S
> tack=true -Dorg.jboss.resolver.warning=true
> -Dsun.rmi.dgc.client.gcInterval=3600000
> -Dsun.rmi.dgc.server.gcInterval=3600000 -Djb
> oss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> -Djboss.server.default.config=standalone.xml
>
> =========================================================================
>
> 10:39:51,401 INFO  [org.jboss.modules] JBoss Modules version 1.1.1.GA
> 10:39:51,643 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
> 10:39:51,682 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final
> "Brontes" starting
> 10:39:51,689 ERROR [org.jboss.msc.service.fail] MSC00001: Failed to
> start service jboss.as: org.jboss.msc.service.StartException
>    in service jboss.as: Failed to start service
>           at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767)
> [jboss-msc-1.0.2.GA.jar:1.
> 0.2.GA]
>           at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> [rt.jar:1.7.0_b147-icedtea]
>           at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> [rt.jar:1.7.0_b147-icedtea]
>           at java.lang.Thread.run(Thread.java:722)
> [rt.jar:1.7.0_b147-icedtea]
> Caused by: java.lang.IllegalStateException: JBAS014922: Directory
> /usr/share/jboss-as/standalone/data/content is not writable
>           at
> org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123)
>           at
> org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97)
>           at
> org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134)
> [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>           at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>           at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>           ... 3 more
>
> 10:39:51,694 ERROR [stderr] java.util.concurrent.ExecutionException:
> Operation failed
> 10:39:51,695 ERROR [stderr]     at
> org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
> 10:39:51,695 ERROR [stderr]     at
> org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
> 10:39:51,695 ERROR [stderr]     at
> org.jboss.as.server.Main.main(Main.java:98)
> 10:39:51,695 ERROR [stderr]     at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:39:51,695 ERROR [stderr]     at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 10:39:51,707 ERROR [stderr]     at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:39:51,707 ERROR [stderr]     at
> java.lang.reflect.Method.invoke(Method.java:601)
> 10:39:51,708 ERROR [stderr]     at
> org.jboss.modules.Module.run(Module.java:260)
> 10:39:51,708 ERROR [stderr]     at
> org.jboss.modules.Main.main(Main.java:291)
> 10:39:51,708 ERROR [stderr] Caused by:
> org.jboss.msc.service.StartException in service jboss.as: Failed to
> start service
> 10:39:51,708 ERROR [stderr]     at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767)
> 10:39:51,708 ERROR [stderr]     at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 10:39:51,708 ERROR [stderr]     at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 10:39:51,709 ERROR [stderr]     at java.lang.Thread.run(Thread.java:722)
> 10:39:51,709 ERROR [stderr] Caused by: java.lang.IllegalStateException:
> JBAS014922: Directory /usr/share/jboss-as/standalone/data/content is not
> writable
> 10:39:51,709 ERROR [stderr]     at
> org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123)
> 10:39:51,709 ERROR [stderr]     at
> org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97)
> 10:39:51,709 ERROR [stderr]     at
> org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134)
> 10:39:51,710 ERROR [stderr]     at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> 10:39:51,710 ERROR [stderr]     at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> 10:39:51,710 ERROR [stderr]     ... 3 more
> 13469
>
>
>
>
>
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel


-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From rgolan at redhat.com  Wed Jun 13 13:14:06 2012
From: rgolan at redhat.com (Roy Golan)
Date: Wed, 13 Jun 2012 16:14:06 +0300
Subject: [Engine-devel] Forking unit tests
In-Reply-To: <56c89244-18b2-4602-9742-996868664fe6@zmail03.collab.prod.int.phx2.redhat.com>
References: <56c89244-18b2-4602-9742-996868664fe6@zmail03.collab.prod.int.phx2.redhat.com>
Message-ID: <4FD8921E.1060703@redhat.com>

On 06/13/2012 03:41 PM, Laszlo Hornyak wrote:
> We can just move the surefire config to a higher level in the pom hierarchy, but that makes the tests slower globaly.
> It is more work, but we could help Allon to rewrite the Powermock tests :-) And then the surefire settings could be removed and the tests will run quick again.

great job.
I think that any further effort we want to put in refactoring the tests 
must be in abstracting the code *first* i.e creating facade + interfaces 
+ getters instead of static calling classes (Backend, Config, DbFacade 
...) . that way we can avoid a lot of mocking code (mkublin we can 
remove a lot of code here!)
>
> ----- Original Message -----
>> From: "Yair Zaslavsky"<yzaslavs at redhat.com>
>> To: "Mike Kolesnik"<mkolesni at redhat.com>
>> Cc: "engine-devel"<engine-devel at ovirt.org>
>> Sent: Wednesday, June 13, 2012 1:44:39 PM
>> Subject: Re: [Engine-devel] Forking unit tests
>>
>> On 06/13/2012 01:28 PM, Mike Kolesnik wrote:
>>>> Hi guys,
>>>>
>>>> If you're using settings.xml as published in Building the oVirt
>>>> Engine page, you'd see we're forking for every test, in every
>>>> subproject.
>>>> This behaviour was introduced to handle memory leaks in PowerMock
>>>> we
>>>> use in some subprojects, but is redundant in others.
>>>>
>>>> Over the past month or so I've been working on removing PowerMock
>>>> from as many places as possible (many thanks to mkolesni and
>>>> lhornyak!), and we've got to the stage that forking is only needed
>>>> in to subprojects - bll and resttypes.
>>> +1 - great job!
>> +1
>>> Would it be possible to have this as a parameter (defaul true) that
>>> can be overridden, such as -Dengine.forkTests=false ?+
>> +1 - good idea.
>>
>>>> The forking was defined explicitly in those two projects, so if
>>>> you
>>>> want to speed up your tests, just take the latest version of
>>>> settings.xml from
>>>> http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.
>>>>
>>>>
>>>> -Allon
>>>>
>>> _______________________________________________
>>> 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 atal at redhat.com  Wed Jun 13 13:33:09 2012
From: atal at redhat.com (Avi Tal)
Date: Wed, 13 Jun 2012 09:33:09 -0400 (EDT)
Subject: [Engine-devel] Vm nic active boolean should be converted to
	status/state=active
In-Reply-To: <23088134.222.1339592066920.JavaMail.atal@atal-fedora.tlv.redhat.com>
Message-ID: <14732815.258.1339594388086.JavaMail.atal@atal-fedora.tlv.redhat.com>

Hi,
I believe we should save the REST API behavior and keep using status object instead of <active>true</active> for vm nics.

We should use:
<status>
 <state>active<state>
</status>


Many rest frameworks works around that <status> object in order to verify element state and we shouldn't change that behavior.

This is true also for hotplug disk

Avi Tal 
Red Hat tlv




From mkolesni at redhat.com  Thu Jun 14 07:34:32 2012
From: mkolesni at redhat.com (Mike Kolesnik)
Date: Thu, 14 Jun 2012 03:34:32 -0400 (EDT)
Subject: [Engine-devel] Vm nic active boolean should be converted
	to	status/state=active
In-Reply-To: <14732815.258.1339594388086.JavaMail.atal@atal-fedora.tlv.redhat.com>
Message-ID: <7fef479a-f7e3-4691-80ee-f2b19f8c1c74@zmail14.collab.prod.int.phx2.redhat.com>

> Hi,
> I believe we should save the REST API behavior and keep using status
> object instead of <active>true</active> for vm nics.
> 
> We should use:
> <status>
>  <state>active<state>
> </status>

Active is a binary state, why would we need a multi-state representation for it?

> 
> 
> Many rest frameworks works around that <status> object in order to
> verify element state and we shouldn't change that behavior.
> 
> This is true also for hotplug disk
> 
> Avi Tal
> Red Hat tlv
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From atal at redhat.com  Thu Jun 14 07:47:26 2012
From: atal at redhat.com (Avi Tal)
Date: Thu, 14 Jun 2012 03:47:26 -0400 (EDT)
Subject: [Engine-devel] Vm nic active boolean should be converted
	to	status/state=active
In-Reply-To: <7fef479a-f7e3-4691-80ee-f2b19f8c1c74@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <30876232.166.1339660042309.JavaMail.atal@atal-fedora.tlv.redhat.com>



Avi Tal 
Red Hat tlv


----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Avi Tal" <atal at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, June 14, 2012 10:34:32 AM
> Subject: Re: [Engine-devel] Vm nic active boolean should be converted to	status/state=active
> 
> > Hi,
> > I believe we should save the REST API behavior and keep using
> > status
> > object instead of <active>true</active> for vm nics.
> > 
> > We should use:
> > <status>
> >  <state>active<state>
> > </status>
> 
> Active is a binary state, why would we need a multi-state
> representation for it?

The way i see it (as a REST API user) active/deactive are states just like up/down.
If i would like to verify the nic active state i would go to the nic state just as simple as it sound.

I can't see any good reason way defining it different then host state or DataCenter state or even storage state.

> 
> > 
> > 
> > Many rest frameworks works around that <status> object in order to
> > verify element state and we shouldn't change that behavior.
> > 
> > This is true also for hotplug disk
> > 
> > Avi Tal
> > Red Hat tlv
> > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 


From amureini at redhat.com  Thu Jun 14 09:13:30 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Thu, 14 Jun 2012 05:13:30 -0400 (EDT)
Subject: [Engine-devel] Forking unit tests
In-Reply-To: <4FD8921E.1060703@redhat.com>
Message-ID: <1398de5e-8e79-4f8b-923e-89f7d8104349@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Roy Golan" <rgolan at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Wednesday, June 13, 2012 4:14:06 PM
> Subject: Re: [Engine-devel] Forking unit tests
> 
> On 06/13/2012 03:41 PM, Laszlo Hornyak wrote:
> > We can just move the surefire config to a higher level in the pom
> > hierarchy, but that makes the tests slower globaly.
> > It is more work, but we could help Allon to rewrite the Powermock
> > tests :-) And then the surefire settings could be removed and the
> > tests will run quick again.
> 
> great job.
> I think that any further effort we want to put in refactoring the
> tests
> must be in abstracting the code *first* i.e creating facade +
> interfaces
> + getters instead of static calling classes (Backend, Config,
> DbFacade
> ...) . that way we can avoid a lot of mocking code (mkublin we can
> remove a lot of code here!)
+gazilion.
> >
> > ----- Original Message -----
> >> From: "Yair Zaslavsky"<yzaslavs at redhat.com>
> >> To: "Mike Kolesnik"<mkolesni at redhat.com>
> >> Cc: "engine-devel"<engine-devel at ovirt.org>
> >> Sent: Wednesday, June 13, 2012 1:44:39 PM
> >> Subject: Re: [Engine-devel] Forking unit tests
> >>
> >> On 06/13/2012 01:28 PM, Mike Kolesnik wrote:
> >>>> Hi guys,
> >>>>
> >>>> If you're using settings.xml as published in Building the oVirt
> >>>> Engine page, you'd see we're forking for every test, in every
> >>>> subproject.
> >>>> This behaviour was introduced to handle memory leaks in
> >>>> PowerMock
> >>>> we
> >>>> use in some subprojects, but is redundant in others.
> >>>>
> >>>> Over the past month or so I've been working on removing
> >>>> PowerMock
> >>>> from as many places as possible (many thanks to mkolesni and
> >>>> lhornyak!), and we've got to the stage that forking is only
> >>>> needed
> >>>> in to subprojects - bll and resttypes.
> >>> +1 - great job!
> >> +1
> >>> Would it be possible to have this as a parameter (defaul true)
> >>> that
> >>> can be overridden, such as -Dengine.forkTests=false ?+
> >> +1 - good idea.
> >>
> >>>> The forking was defined explicitly in those two projects, so if
> >>>> you
> >>>> want to speed up your tests, just take the latest version of
> >>>> settings.xml from
> >>>> http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.
> >>>>
> >>>>
> >>>> -Allon
> >>>>
> >>> _______________________________________________
> >>> 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 Jun 14 10:55:18 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 14 Jun 2012 06:55:18 -0400 (EDT)
Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
In-Reply-To: <3e67806a-53d1-4eb4-bc1f-2adbb7e616e2@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <d7eda1b0-bfb4-4b0f-ba8f-7ad80383af85@zmail16.collab.prod.int.phx2.redhat.com>

Hi everyone,

please note that the original (SmartGWT-based) UserPortal application has been removed from oVirt repository, as part of patch [http://gerrit.ovirt.org/5317].

This has no impact on the current UserPortal application, which is part of the standard oVirt Maven build.

Please let me know if you have any questions.

Thanks,
Vojtech


From lhornyak at redhat.com  Thu Jun 14 11:29:40 2012
From: lhornyak at redhat.com (Laszlo Hornyak)
Date: Thu, 14 Jun 2012 07:29:40 -0400 (EDT)
Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
In-Reply-To: <d7eda1b0-bfb4-4b0f-ba8f-7ad80383af85@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <39c7ebd6-37e9-434b-9dd9-dadd217d6aca@zmail03.collab.prod.int.phx2.redhat.com>

Hi,

A visualization of how that counts (from sonar)
https://twitter.com/kozka/status/213229060103483392/photo/1

Laszlo

----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, June 14, 2012 12:55:18 PM
> Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
> 
> Hi everyone,
> 
> please note that the original (SmartGWT-based) UserPortal application
> has been removed from oVirt repository, as part of patch
> [http://gerrit.ovirt.org/5317].
> 
> This has no impact on the current UserPortal application, which is
> part of the standard oVirt Maven build.
> 
> Please let me know if you have any questions.
> 
> Thanks,
> Vojtech
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From amureini at redhat.com  Thu Jun 14 13:28:05 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Thu, 14 Jun 2012 09:28:05 -0400 (EDT)
Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
In-Reply-To: <39c7ebd6-37e9-434b-9dd9-dadd217d6aca@zmail03.collab.prod.int.phx2.redhat.com>
Message-ID: <39efacf5-5e1f-43a2-a5e4-c03225c17c7b@zmail17.collab.prod.int.phx2.redhat.com>

awesome!

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, June 14, 2012 2:29:40 PM
> Subject: Re: [Engine-devel] oVirt UI: Legacy UserPortal removed
> 
> Hi,
> 
> A visualization of how that counts (from sonar)
> https://twitter.com/kozka/status/213229060103483392/photo/1
> 
> Laszlo
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Thursday, June 14, 2012 12:55:18 PM
> > Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
> > 
> > Hi everyone,
> > 
> > please note that the original (SmartGWT-based) UserPortal
> > application
> > has been removed from oVirt repository, as part of patch
> > [http://gerrit.ovirt.org/5317].
> > 
> > This has no impact on the current UserPortal application, which is
> > part of the standard oVirt Maven build.
> > 
> > Please let me know if you have any questions.
> > 
> > Thanks,
> > Vojtech
> > _______________________________________________
> > 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 wudxw at linux.vnet.ibm.com  Thu Jun 14 13:59:57 2012
From: wudxw at linux.vnet.ibm.com (Mark Wu)
Date: Thu, 14 Jun 2012 21:59:57 +0800
Subject: [Engine-devel] What BlockMigrationOnSwapUsagePercentage
Message-ID: <4FD9EE5D.3090206@linux.vnet.ibm.com>

Hi guys

I got the following error message when I tried to run a VM:

"VM's swap percentage is above the threshold. (check your configuration 
parameters for Host Swap Percentage)."

After increasing the parameter BlockMigrationOnSwapUsagePercentage, the 
problem disappeared.

But I don't understand the logic here:
IsVMSwapValueLegal
         ....
         return ((swap_total - swap_free - mem_available) * 100 / 
physical_mem_mb) <= Config
                 .<Integer> 
GetValue(ConfigValues.BlockMigrationOnSwapUsagePercentage);


So anyone can help me explain it?  Thanks a lot!

Mark.



From iheim at redhat.com  Thu Jun 14 14:21:45 2012
From: iheim at redhat.com (Itamar Heim)
Date: Thu, 14 Jun 2012 17:21:45 +0300
Subject: [Engine-devel] What BlockMigrationOnSwapUsagePercentage
In-Reply-To: <4FD9EE5D.3090206@linux.vnet.ibm.com>
References: <4FD9EE5D.3090206@linux.vnet.ibm.com>
Message-ID: <4FD9F379.10002@redhat.com>

On 06/14/2012 04:59 PM, Mark Wu wrote:
> Hi guys
>
> I got the following error message when I tried to run a VM:
>
> "VM's swap percentage is above the threshold. (check your configuration
> parameters for Host Swap Percentage)."
>
> After increasing the parameter BlockMigrationOnSwapUsagePercentage, the
> problem disappeared.
>
> But I don't understand the logic here:
> IsVMSwapValueLegal
> ....
> return ((swap_total - swap_free - mem_available) * 100 /

analyzing this...
how much memory swap has
minus
how much is still available
gives the amount of swap used
then subtract the amount of RAM available - since it won't require swap 
for that amount of RAM.

that's gives how much swap is used (taking into consideration available 
RAM) as a percentage from physical memory

yes, could be written in a more readable way.

> physical_mem_mb) <= Config
> .<Integer> GetValue(ConfigValues.BlockMigrationOnSwapUsagePercentage);
>
>
> So anyone can help me explain it? Thanks a lot!
>
> Mark.
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel



From shaohef at linux.vnet.ibm.com  Thu Jun 14 14:32:50 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Thu, 14 Jun 2012 22:32:50 +0800
Subject: [Engine-devel] reasonable,
	the actual size are unchanged during create virtual Disk, 
Message-ID: <4FD9F612.1070601@linux.vnet.ibm.com>


1.
add a 110GB disk and the format of disk is "Preallocated".

during the status is "locked", the actual size are unchanged, always is 
"< 1 GB".
but the the free space is decreasing, at the same time.
IMO, the total actual size should  be equal to what the free space 
decreased.

and I check the web browser display refresh rate is  5 seconds.

2.another one.
"Is bootable" and "Is bootable" are check box in the pop-up dialogue of 
"Add virtual Disk"
but error when select both.
Error: Cannot add Virtual Machine Disk. Low disk space on relevant 
Storage Domain.
is this reasonable?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120614/6f89cb87/attachment.html>

From mkublin at redhat.com  Thu Jun 14 14:37:20 2012
From: mkublin at redhat.com (Michael Kublin)
Date: Thu, 14 Jun 2012 10:37:20 -0400 (EDT)
Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
In-Reply-To: <39efacf5-5e1f-43a2-a5e4-c03225c17c7b@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <65522108-266c-47e7-85f3-dd77401aacce@zmail14.collab.prod.int.phx2.redhat.com>

AWESOME !!!

+0, -76860

----- Original Message -----
From: "Allon Mureinik" <amureini at redhat.com>
To: "Laszlo Hornyak" <lhornyak at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Thursday, June 14, 2012 4:28:05 PM
Subject: Re: [Engine-devel] oVirt UI: Legacy UserPortal removed

awesome!

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, June 14, 2012 2:29:40 PM
> Subject: Re: [Engine-devel] oVirt UI: Legacy UserPortal removed
> 
> Hi,
> 
> A visualization of how that counts (from sonar)
> https://twitter.com/kozka/status/213229060103483392/photo/1
> 
> Laszlo
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Thursday, June 14, 2012 12:55:18 PM
> > Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
> > 
> > Hi everyone,
> > 
> > please note that the original (SmartGWT-based) UserPortal
> > application
> > has been removed from oVirt repository, as part of patch
> > [http://gerrit.ovirt.org/5317].
> > 
> > This has no impact on the current UserPortal application, which is
> > part of the standard oVirt Maven build.
> > 
> > Please let me know if you have any questions.
> > 
> > Thanks,
> > Vojtech
> > _______________________________________________
> > 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 gchaplik at redhat.com  Thu Jun 14 17:23:35 2012
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 14 Jun 2012 13:23:35 -0400 (EDT)
Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
In-Reply-To: <d7eda1b0-bfb4-4b0f-ba8f-7ad80383af85@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <9c728ed3-2837-4fbb-9956-273a0abe3257@zmail14.collab.prod.int.phx2.redhat.com>

will you rename userportal-gwtp to userportal?

Thanks, 
Gilad.

----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: engine-devel at ovirt.org
> Sent: Thursday, June 14, 2012 1:55:18 PM
> Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
> 
> Hi everyone,
> 
> please note that the original (SmartGWT-based) UserPortal application
> has been removed from oVirt repository, as part of patch
> [http://gerrit.ovirt.org/5317].
> 
> This has no impact on the current UserPortal application, which is
> part of the standard oVirt Maven build.
> 
> Please let me know if you have any questions.
> 
> Thanks,
> Vojtech
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From gchaplik at redhat.com  Thu Jun 14 17:31:20 2012
From: gchaplik at redhat.com (Gilad Chaplik)
Date: Thu, 14 Jun 2012 13:31:20 -0400 (EDT)
Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
In-Reply-To: <39c7ebd6-37e9-434b-9dd9-dadd217d6aca@zmail03.collab.prod.int.phx2.redhat.com>
Message-ID: <06ac2526-14bf-47f1-ab22-da0c20b63334@zmail14.collab.prod.int.phx2.redhat.com>

who said the ex-fronend team is not virt-ecological?

Thanks, 
Gilad.

----- Original Message -----
> From: "Laszlo Hornyak" <lhornyak at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org
> Sent: Thursday, June 14, 2012 2:29:40 PM
> Subject: Re: [Engine-devel] oVirt UI: Legacy UserPortal removed
> 
> Hi,
> 
> A visualization of how that counts (from sonar)
> https://twitter.com/kozka/status/213229060103483392/photo/1
> 
> Laszlo
> 
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: engine-devel at ovirt.org
> > Sent: Thursday, June 14, 2012 12:55:18 PM
> > Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
> > 
> > Hi everyone,
> > 
> > please note that the original (SmartGWT-based) UserPortal
> > application
> > has been removed from oVirt repository, as part of patch
> > [http://gerrit.ovirt.org/5317].
> > 
> > This has no impact on the current UserPortal application, which is
> > part of the standard oVirt Maven build.
> > 
> > Please let me know if you have any questions.
> > 
> > Thanks,
> > Vojtech
> > _______________________________________________
> > 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 djasa at redhat.com  Fri Jun 15 08:50:33 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 15 Jun 2012 10:50:33 +0200
Subject: [Engine-devel] [Spice-devel] RFC: spice-server default listen
	behaviour change
In-Reply-To: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
References: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <1339750233.31425.546.camel@dhcp-29-7.brq.redhat.com>

(I missed engine-devel@ previously because of typo :()

just two additions I missed yesterday:

David Ja?a p??e v ?t 14. 06. 2012 v 17:32 +0200:
> Hi,
> 
> I learned few things about ipv6 lately. Most importantly about
> dual-socket that means that a process that opens ::0 automatically
> listens on both ipv4 _and_ ipv6 unless it sets IPV6_ONLY option of
> setsockopt() to 0.
> 
> This is pretty important wrt dual-stack configurations because they can
> be implemented with just slight changes to spice server (unlike the old
> RFE requesting listening on multiple addresses):
> 
> * when no addr= or ipvx options are set, listen on ::0
> 
> * when ipv4 and no addr= option is set, listen on 0.0.0.0
> 
> * when ipv6 is set, set IPV6_ONLY to 1 to make sure that spice server
> won't listen on ipv4
> 
> * when conflicting ipvx and addr= options are set, error out (this
> already works fine)
> 

* new spice-server feature: add option to bind to a selected interface
regardless of its addresses

> This will affect upper layers though, given bugs like
> https://bugzilla.redhat.com/show_bug.cgi?id=832121 , but it seems to me
> like the step in the right direction. Any thoughts/comments before I
> file this as a bug?

oVirt could leverage the last bullet to add dual-stack support pretty
much transparently if the display network is defined by dns name. Is
there an interest in this?

> 
> David
> 

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24






From djasa at redhat.com  Fri Jun 15 09:02:43 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 15 Jun 2012 11:02:43 +0200
Subject: [Engine-devel] [Spice-devel] RFC: spice-server default listen
	behaviour change
In-Reply-To: <4FDAF40B.6050104@redhat.com>
References: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
	<4FDAF40B.6050104@redhat.com>
Message-ID: <1339750963.31425.558.camel@dhcp-29-7.brq.redhat.com>

Gerd Hoffmann p??e v P? 15. 06. 2012 v 10:36 +0200:
> Hi,
> 
> > This is pretty important wrt dual-stack configurations because they can
> > be implemented with just slight changes to spice server (unlike the old
> > RFE requesting listening on multiple addresses):
> > 
> > * when no addr= or ipvx options are set, listen on ::0
> 
> spice-server sets "ai.ai_flags = AI_PASSIVE | AI_ADDRCONFIG", which
> should make getaddrinfo() pick something reasonable, specifically listen
> on ipv6 only if the machine actually has ipv6 connectivity.
> 

I don't think that listening on IPv6 exclusively is good when the host
has both IPv4 and IPv6 connectivity. Think about dual stack setups where
the spice-server host is defined by host name that can resolve to both
IPv6 and IPv4 addresses.

David

> I think this is the behavior we want here.
> 
> > * when ipv4 and no addr= option is set, listen on 0.0.0.0
> 
> Works today.
> 
> > * when ipv6 is set, set IPV6_ONLY to 1 to make sure that spice server
> > won't listen on ipv4
> 
> Trivially to add, see patch.
> 
> > * when conflicting ipvx and addr= options are set, error out (this
> > already works fine)
> 
> Works today indeed.
> 
> cheers,
>   Gerd
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From kraxel at redhat.com  Fri Jun 15 09:27:45 2012
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Fri, 15 Jun 2012 11:27:45 +0200
Subject: [Engine-devel] [Spice-devel] RFC: spice-server default listen
	behaviour change
In-Reply-To: <1339750963.31425.558.camel@dhcp-29-7.brq.redhat.com>
References: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
	<4FDAF40B.6050104@redhat.com>
	<1339750963.31425.558.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <4FDB0011.8070802@redhat.com>

On 06/15/12 11:02, David Ja?a wrote:
> Gerd Hoffmann p??e v P? 15. 06. 2012 v 10:36 +0200:
>> Hi,
>>
>>> This is pretty important wrt dual-stack configurations because they can
>>> be implemented with just slight changes to spice server (unlike the old
>>> RFE requesting listening on multiple addresses):
>>>
>>> * when no addr= or ipvx options are set, listen on ::0
>>
>> spice-server sets "ai.ai_flags = AI_PASSIVE | AI_ADDRCONFIG", which
>> should make getaddrinfo() pick something reasonable, specifically listen
>> on ipv6 only if the machine actually has ipv6 connectivity.
>>
> 
> I don't think that listening on IPv6 exclusively is good when the host
> has both IPv4 and IPv6 connectivity.

Huh?  Oh, I see you can read the sentence two ways:

(1) specifically listen on ipv6 only, if the machine actually has ipv6
connectivity

(2) specifically listen on ipv6, only if the machine actually has ipv6
connectivity

I mean (2), i.e. do not create a ipv6 socket if the machine has no ipv6
connectivity.

When creating a ipv6 socket IPV6_ONLY should be clear by default indeed,
so both ipv4 and ipv6 will work.

cheers,
  Gerd


From kraxel at redhat.com  Fri Jun 15 09:48:28 2012
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Fri, 15 Jun 2012 11:48:28 +0200
Subject: [Engine-devel] [libvirt] [Spice-devel] RFC: spice-server
 default listen behaviour change
In-Reply-To: <1339750233.31425.546.camel@dhcp-29-7.brq.redhat.com>
References: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
	<1339750233.31425.546.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <4FDB04EC.3030600@redhat.com>

  Hi,

> * new spice-server feature: add option to bind to a selected interface
> regardless of its addresses

How does that work?

cheers,
  Gerd


From berrange at redhat.com  Fri Jun 15 10:00:18 2012
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 15 Jun 2012 11:00:18 +0100
Subject: [Engine-devel] [libvirt] [Spice-devel] RFC: spice-server
 default listen behaviour change
In-Reply-To: <4FDB04EC.3030600@redhat.com>
References: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
	<1339750233.31425.546.camel@dhcp-29-7.brq.redhat.com>
	<4FDB04EC.3030600@redhat.com>
Message-ID: <20120615100018.GG16777@redhat.com>

On Fri, Jun 15, 2012 at 11:48:28AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > * new spice-server feature: add option to bind to a selected interface
> > regardless of its addresses
> 
> How does that work?

I presume the client app would request    listen=eth0, and the QEMU
would have to call getifaddrs() to determine what IP addresses
currently correspond to eth0.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


From djasa at redhat.com  Fri Jun 15 10:03:33 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 15 Jun 2012 12:03:33 +0200
Subject: [Engine-devel] [Spice-devel] [libvirt] RFC: spice-server
 default listen behaviour change
In-Reply-To: <4FDB04EC.3030600@redhat.com>
References: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
	<1339750233.31425.546.camel@dhcp-29-7.brq.redhat.com>
	<4FDB04EC.3030600@redhat.com>
Message-ID: <1339754613.31425.561.camel@dhcp-29-7.brq.redhat.com>

Gerd Hoffmann p??e v P? 15. 06. 2012 v 11:48 +0200:
> Hi,
> 
> > * new spice-server feature: add option to bind to a selected interface
> > regardless of its addresses
> 
> How does that work?

I'm aware that for example dnsmasq does this with its --bind-interfaces
option. If I'm grepping their repo correctly, it's done like this:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/option.c#l325
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/dhcp.c#l66

David

> 
> cheers,
>   Gerd
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From kraxel at redhat.com  Fri Jun 15 10:44:04 2012
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Fri, 15 Jun 2012 12:44:04 +0200
Subject: [Engine-devel] [libvirt] [Spice-devel] RFC: spice-server
 default listen behaviour change
In-Reply-To: <20120615100018.GG16777@redhat.com>
References: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
	<1339750233.31425.546.camel@dhcp-29-7.brq.redhat.com>
	<4FDB04EC.3030600@redhat.com> <20120615100018.GG16777@redhat.com>
Message-ID: <4FDB11F4.8020606@redhat.com>

On 06/15/12 12:00, Daniel P. Berrange wrote:
> On Fri, Jun 15, 2012 at 11:48:28AM +0200, Gerd Hoffmann wrote:
>>   Hi,
>>
>>> * new spice-server feature: add option to bind to a selected interface
>>> regardless of its addresses
>>
>> How does that work?
> 
> I presume the client app would request    listen=eth0, and the QEMU
> would have to call getifaddrs() to determine what IP addresses
> currently correspond to eth0.

Ah, so there isn't a direct way I'm not aware of, you still bind to a
specific ip address (or multiple), just specified in a different way ;)

Note that supporting this isn't going to work with a single listening
socket.  Having ipv6 sockets accept ipv4 connects too works for wildcard
sockets only.  If you want listening on all ip{v4,v6} addresses of an
interface you'll need a listening socket for each.

cheers,
  Gerd


From berrange at redhat.com  Fri Jun 15 10:54:28 2012
From: berrange at redhat.com (Daniel P. Berrange)
Date: Fri, 15 Jun 2012 11:54:28 +0100
Subject: [Engine-devel] [libvirt] [Spice-devel] RFC: spice-server
 default listen behaviour change
In-Reply-To: <4FDB11F4.8020606@redhat.com>
References: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
	<1339750233.31425.546.camel@dhcp-29-7.brq.redhat.com>
	<4FDB04EC.3030600@redhat.com> <20120615100018.GG16777@redhat.com>
	<4FDB11F4.8020606@redhat.com>
Message-ID: <20120615105428.GJ16777@redhat.com>

On Fri, Jun 15, 2012 at 12:44:04PM +0200, Gerd Hoffmann wrote:
> On 06/15/12 12:00, Daniel P. Berrange wrote:
> > On Fri, Jun 15, 2012 at 11:48:28AM +0200, Gerd Hoffmann wrote:
> >>   Hi,
> >>
> >>> * new spice-server feature: add option to bind to a selected interface
> >>> regardless of its addresses
> >>
> >> How does that work?
> > 
> > I presume the client app would request    listen=eth0, and the QEMU
> > would have to call getifaddrs() to determine what IP addresses
> > currently correspond to eth0.
> 
> Ah, so there isn't a direct way I'm not aware of, you still bind to a
> specific ip address (or multiple), just specified in a different way ;)
> 
> Note that supporting this isn't going to work with a single listening
> socket.  Having ipv6 sockets accept ipv4 connects too works for wildcard
> sockets only.  If you want listening on all ip{v4,v6} addresses of an
> interface you'll need a listening socket for each.

Yeah, I'm almost certain you'll need to have multiple listening sockets
for this to work

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


From djasa at redhat.com  Fri Jun 15 13:33:57 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 15 Jun 2012 15:33:57 +0200
Subject: [Engine-devel] [Spice-devel] [libvirt] RFC: spice-server
 default listen behaviour change
In-Reply-To: <1339765851.31425.580.camel@dhcp-29-7.brq.redhat.com>
References: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
	<1339750233.31425.546.camel@dhcp-29-7.brq.redhat.com>
	<4FDB04EC.3030600@redhat.com> <20120615100018.GG16777@redhat.com>
	<4FDB11F4.8020606@redhat.com>  <20120615105428.GJ16777@redhat.com>
	<1339765851.31425.580.camel@dhcp-29-7.brq.redhat.com>
Message-ID: <1339767237.31425.585.camel@dhcp-29-7.brq.redhat.com>

David Ja?a p??e v P? 15. 06. 2012 v 15:10 +0200:
> Daniel P. Berrange p??e v P? 15. 06. 2012 v 11:54 +0100:
> > On Fri, Jun 15, 2012 at 12:44:04PM +0200, Gerd Hoffmann wrote:
> > > On 06/15/12 12:00, Daniel P. Berrange wrote:
> > > > On Fri, Jun 15, 2012 at 11:48:28AM +0200, Gerd Hoffmann wrote:
> > > >>   Hi,
> > > >>
> > > >>> * new spice-server feature: add option to bind to a selected interface
> > > >>> regardless of its addresses
> > > >>
> > > >> How does that work?
> > > > 
> > > > I presume the client app would request    listen=eth0, and the QEMU
> > > > would have to call getifaddrs() to determine what IP addresses
> > > > currently correspond to eth0.
> > > 
> > > Ah, so there isn't a direct way I'm not aware of, you still bind to a
> > > specific ip address (or multiple), just specified in a different way ;)
> > > 
> > > Note that supporting this isn't going to work with a single listening
> > > socket.  Having ipv6 sockets accept ipv4 connects too works for wildcard
> > > sockets only.  If you want listening on all ip{v4,v6} addresses of an
> > > interface you'll need a listening socket for each.
> > 
> > Yeah, I'm almost certain you'll need to have multiple listening sockets
> > for this to work
> > 
> > Daniel
> 
> Well, I've checked what my local dnsmasq does and it's doing precisely
> what you say:
> tcp        0      0 127.0.0.1:53                0.0.0.0:*                   LISTEN      29426/dnsmasq       
> tcp        0      0 192.168.122.1:53            0.0.0.0:*                   LISTEN      29426/dnsmasq       
> tcp        0      0 ::1:53                      :::*                        LISTEN      29426/dnsmasq       
> tcp        0      0 fe80::4c03:d0ff:fec2:aa7:53 :::*                        LISTEN      29426/dnsmasq
> 
> In other words, dual-socket won't make dual-stack for selected interface
> possible without implementing
> https://bugzilla.redhat.com/show_bug.cgi?id=787256
> anyway. :(
> 
> David
> 

Scratch that. After some more research, I found this in socket (7):

SO_BINDTODEVICE
      Bind  this  socket to a particular device like "eth0", as speci-
      fied in the passed interface name.  If  the  name  is  an  empty
      string  or  the option length is zero, the socket device binding
      is removed.  The passed option is a variable-length  null-termi-
      nated  interface  name string with the maximum size of IFNAMSIZ.
      If a socket is bound to an interface, only packets received from
      that  particular  interface  are  processed by the socket.  Note
      that this only works for some socket types, particularly AF_INET
      sockets.   It  is  not  supported for packet sockets (use normal
      bind(8) there)

So using wildcard address and this socket option should be the
least-effort way to support dual-stack display networks if I get it
right...

David

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From djasa at redhat.com  Fri Jun 15 13:10:51 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Fri, 15 Jun 2012 15:10:51 +0200
Subject: [Engine-devel] [Spice-devel] [libvirt] RFC: spice-server
 default listen behaviour change
In-Reply-To: <20120615105428.GJ16777@redhat.com>
References: <1339687972.31425.449.camel@dhcp-29-7.brq.redhat.com>
	<1339750233.31425.546.camel@dhcp-29-7.brq.redhat.com>
	<4FDB04EC.3030600@redhat.com> <20120615100018.GG16777@redhat.com>
	<4FDB11F4.8020606@redhat.com>  <20120615105428.GJ16777@redhat.com>
Message-ID: <1339765851.31425.580.camel@dhcp-29-7.brq.redhat.com>

Daniel P. Berrange p??e v P? 15. 06. 2012 v 11:54 +0100:
> On Fri, Jun 15, 2012 at 12:44:04PM +0200, Gerd Hoffmann wrote:
> > On 06/15/12 12:00, Daniel P. Berrange wrote:
> > > On Fri, Jun 15, 2012 at 11:48:28AM +0200, Gerd Hoffmann wrote:
> > >>   Hi,
> > >>
> > >>> * new spice-server feature: add option to bind to a selected interface
> > >>> regardless of its addresses
> > >>
> > >> How does that work?
> > > 
> > > I presume the client app would request    listen=eth0, and the QEMU
> > > would have to call getifaddrs() to determine what IP addresses
> > > currently correspond to eth0.
> > 
> > Ah, so there isn't a direct way I'm not aware of, you still bind to a
> > specific ip address (or multiple), just specified in a different way ;)
> > 
> > Note that supporting this isn't going to work with a single listening
> > socket.  Having ipv6 sockets accept ipv4 connects too works for wildcard
> > sockets only.  If you want listening on all ip{v4,v6} addresses of an
> > interface you'll need a listening socket for each.
> 
> Yeah, I'm almost certain you'll need to have multiple listening sockets
> for this to work
> 
> Daniel

Well, I've checked what my local dnsmasq does and it's doing precisely
what you say:
tcp        0      0 127.0.0.1:53                0.0.0.0:*                   LISTEN      29426/dnsmasq       
tcp        0      0 192.168.122.1:53            0.0.0.0:*                   LISTEN      29426/dnsmasq       
tcp        0      0 ::1:53                      :::*                        LISTEN      29426/dnsmasq       
tcp        0      0 fe80::4c03:d0ff:fec2:aa7:53 :::*                        LISTEN      29426/dnsmasq

In other words, dual-socket won't make dual-stack for selected interface
possible without implementing
https://bugzilla.redhat.com/show_bug.cgi?id=787256
anyway. :(

David

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From shaohef at linux.vnet.ibm.com  Sat Jun 16 14:32:33 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Sat, 16 Jun 2012 22:32:33 +0800
Subject: [Engine-devel] Deploy ovirt-engine error
In-Reply-To: <4FD88AA9.7030204@redhat.com>
References: <4FD80231.3020009@linux.vnet.ibm.com> <4FD88AA9.7030204@redhat.com>
Message-ID: <4FDC9901.8000205@linux.vnet.ibm.com>

On 06/13/2012 08:42 PM, Juan Hernandez wrote:
> On 06/13/2012 05:00 AM, ShaoHe Feng wrote:
>> I follow this guide http://ovirt.org/wiki/Building_oVirt_engine
>
> That page as bit out of date. I am preparing an updated one 
> specifically for development environments. It is available here:
>
> http://ovirt.org/wiki/Building_Engine_Draft
>
> I appreciate any feedback.
I have update my  OS to ferdora 17, re-build ovirt-engine by 
http://ovirt.org/wiki/Building_Engine_Draft.
still failed.

Results :

Failed tests: 
macAddressTooShortForCreate(org.ovirt.engine.core.common.businessentities.VmNetworkInterfaceValidationTest): 
Validation should fail due to violation: 
[VALIDATION.VM.NETWORK.MAC.ADDRESS.INVALID]; Actual violations were: [] 
expected:<true> but was:<false>
>
>>
>> 1)
>> $>  make install_tools
>> make: *** No rule to make target `install_tools'.  Stop
>>
>> I have check the Makefile, there is really no install_tools rule.
>>
>> 2)
>> #>   make install_config
>> *** 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 
>> /etc/ovirt-engine/engine-config/
>> install -m 644
>> backend/manager/tools/engine-config/src/main/resources/engine-config.*properties 
>>
>> /etc/ovirt-engine/engine-config/
>> install -m 644
>> backend/manager/tools/engine-config/src/main/resources/log4j.xml
>> /etc/ovirt-engine/engine-config/
>> # Jar files for the configuration tool:
>> # XXX: Should replace with links to the actual locations
>> # of the jar files, or fix the scripts to use that.
>> install -m 644
>> /home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar 
>>
>> /usr/share/ovirt-engine/engine-config/lib/
>> install: cannot stat
>> `/home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar': 
>>
>> No such file or directory
>> make: *** [install_config] Error 1
>>
>>
>> 3) can not start jboss-as after deploy ovirt-engine.
>>    $# service jboss-as start
>> ========================================================================= 
>>
>>
>>     JBoss Bootstrap Environment
>>
>>     JBOSS_HOME: /usr/share/jboss-as
>>
>>     JAVA: java
>>
>>     JAVA_OPTS:  -server -XX:+UseCompressedOops -XX:+TieredCompilation
>> -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4S
>> tack=true -Dorg.jboss.resolver.warning=true
>> -Dsun.rmi.dgc.client.gcInterval=3600000
>> -Dsun.rmi.dgc.server.gcInterval=3600000 -Djb
>> oss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
>> -Djboss.server.default.config=standalone.xml
>>
>> ========================================================================= 
>>
>>
>> 10:39:51,401 INFO  [org.jboss.modules] JBoss Modules version 1.1.1.GA
>> 10:39:51,643 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
>> 10:39:51,682 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final
>> "Brontes" starting
>> 10:39:51,689 ERROR [org.jboss.msc.service.fail] MSC00001: Failed to
>> start service jboss.as: org.jboss.msc.service.StartException
>>    in service jboss.as: Failed to start service
>>           at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) 
>>
>> [jboss-msc-1.0.2.GA.jar:1.
>> 0.2.GA]
>>           at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
>>
>> [rt.jar:1.7.0_b147-icedtea]
>>           at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
>>
>> [rt.jar:1.7.0_b147-icedtea]
>>           at java.lang.Thread.run(Thread.java:722)
>> [rt.jar:1.7.0_b147-icedtea]
>> Caused by: java.lang.IllegalStateException: JBAS014922: Directory
>> /usr/share/jboss-as/standalone/data/content is not writable
>>           at
>> org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123) 
>>
>>           at
>> org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97) 
>>
>>           at
>> org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134) 
>>
>> [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>>           at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) 
>>
>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>>           at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) 
>>
>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>>           ... 3 more
>>
>> 10:39:51,694 ERROR [stderr] java.util.concurrent.ExecutionException:
>> Operation failed
>> 10:39:51,695 ERROR [stderr]     at
>> org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74) 
>>
>> 10:39:51,695 ERROR [stderr]     at
>> org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>> 10:39:51,695 ERROR [stderr]     at
>> org.jboss.as.server.Main.main(Main.java:98)
>> 10:39:51,695 ERROR [stderr]     at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 10:39:51,695 ERROR [stderr]     at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 
>>
>> 10:39:51,707 ERROR [stderr]     at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
>>
>> 10:39:51,707 ERROR [stderr]     at
>> java.lang.reflect.Method.invoke(Method.java:601)
>> 10:39:51,708 ERROR [stderr]     at
>> org.jboss.modules.Module.run(Module.java:260)
>> 10:39:51,708 ERROR [stderr]     at
>> org.jboss.modules.Main.main(Main.java:291)
>> 10:39:51,708 ERROR [stderr] Caused by:
>> org.jboss.msc.service.StartException in service jboss.as: Failed to
>> start service
>> 10:39:51,708 ERROR [stderr]     at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) 
>>
>> 10:39:51,708 ERROR [stderr]     at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
>>
>> 10:39:51,708 ERROR [stderr]     at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
>>
>> 10:39:51,709 ERROR [stderr]     at java.lang.Thread.run(Thread.java:722)
>> 10:39:51,709 ERROR [stderr] Caused by: java.lang.IllegalStateException:
>> JBAS014922: Directory /usr/share/jboss-as/standalone/data/content is not
>> writable
>> 10:39:51,709 ERROR [stderr]     at
>> org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123) 
>>
>> 10:39:51,709 ERROR [stderr]     at
>> org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97) 
>>
>> 10:39:51,709 ERROR [stderr]     at
>> org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134) 
>>
>> 10:39:51,710 ERROR [stderr]     at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) 
>>
>> 10:39:51,710 ERROR [stderr]     at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) 
>>
>> 10:39:51,710 ERROR [stderr]     ... 3 more
>> 13469
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>




From jhernand at redhat.com  Sat Jun 16 17:23:06 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Sat, 16 Jun 2012 19:23:06 +0200
Subject: [Engine-devel] Deploy ovirt-engine error
In-Reply-To: <4FDC9901.8000205@linux.vnet.ibm.com>
References: <4FD80231.3020009@linux.vnet.ibm.com> <4FD88AA9.7030204@redhat.com>
	<4FDC9901.8000205@linux.vnet.ibm.com>
Message-ID: <4FDCC0FA.3000107@redhat.com>

On 06/16/2012 04:32 PM, Sheldon wrote:
> On 06/13/2012 08:42 PM, Juan Hernandez wrote:
>> On 06/13/2012 05:00 AM, ShaoHe Feng wrote:
>>> I follow this guide http://ovirt.org/wiki/Building_oVirt_engine
>>
>> That page as bit out of date. I am preparing an updated one
>> specifically for development environments. It is available here:
>>
>> http://ovirt.org/wiki/Building_Engine_Draft
>>
>> I appreciate any feedback.
> I have update my  OS to ferdora 17, re-build ovirt-engine by
> http://ovirt.org/wiki/Building_Engine_Draft.
> still failed.
>
> Results :
>
> Failed tests:
> macAddressTooShortForCreate(org.ovirt.engine.core.common.businessentities.VmNetworkInterfaceValidationTest):
> Validation should fail due to violation:
> [VALIDATION.VM.NETWORK.MAC.ADDRESS.INVALID]; Actual violations were: []
> expected:<true>  but was:<false>

It is worth checking why that test is failing, but meanwhile you can 
repeat the build using the following option to skip execution of the tests:

mvn -DskipTests=true clean install

>>> 1)
>>> $>   make install_tools
>>> make: *** No rule to make target `install_tools'.  Stop
>>>
>>> I have check the Makefile, there is really no install_tools rule.
>>>
>>> 2)
>>> #>    make install_config
>>> *** 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
>>> /etc/ovirt-engine/engine-config/
>>> install -m 644
>>> backend/manager/tools/engine-config/src/main/resources/engine-config.*properties
>>>
>>> /etc/ovirt-engine/engine-config/
>>> install -m 644
>>> backend/manager/tools/engine-config/src/main/resources/log4j.xml
>>> /etc/ovirt-engine/engine-config/
>>> # Jar files for the configuration tool:
>>> # XXX: Should replace with links to the actual locations
>>> # of the jar files, or fix the scripts to use that.
>>> install -m 644
>>> /home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar
>>>
>>> /usr/share/ovirt-engine/engine-config/lib/
>>> install: cannot stat
>>> `/home/fsh/work/vm/wkspace/ovirt-engine/rpmbuild/SOURCES/engine-config-3.1.0-0001.jar':
>>>
>>> No such file or directory
>>> make: *** [install_config] Error 1
>>>
>>>
>>> 3) can not start jboss-as after deploy ovirt-engine.
>>>     $# service jboss-as start
>>> =========================================================================
>>>
>>>
>>>      JBoss Bootstrap Environment
>>>
>>>      JBOSS_HOME: /usr/share/jboss-as
>>>
>>>      JAVA: java
>>>
>>>      JAVA_OPTS:  -server -XX:+UseCompressedOops -XX:+TieredCompilation
>>> -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4S
>>> tack=true -Dorg.jboss.resolver.warning=true
>>> -Dsun.rmi.dgc.client.gcInterval=3600000
>>> -Dsun.rmi.dgc.server.gcInterval=3600000 -Djb
>>> oss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
>>> -Djboss.server.default.config=standalone.xml
>>>
>>> =========================================================================
>>>
>>>
>>> 10:39:51,401 INFO  [org.jboss.modules] JBoss Modules version 1.1.1.GA
>>> 10:39:51,643 INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
>>> 10:39:51,682 INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final
>>> "Brontes" starting
>>> 10:39:51,689 ERROR [org.jboss.msc.service.fail] MSC00001: Failed to
>>> start service jboss.as: org.jboss.msc.service.StartException
>>>     in service jboss.as: Failed to start service
>>>            at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767)
>>>
>>> [jboss-msc-1.0.2.GA.jar:1.
>>> 0.2.GA]
>>>            at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>>
>>> [rt.jar:1.7.0_b147-icedtea]
>>>            at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>>
>>> [rt.jar:1.7.0_b147-icedtea]
>>>            at java.lang.Thread.run(Thread.java:722)
>>> [rt.jar:1.7.0_b147-icedtea]
>>> Caused by: java.lang.IllegalStateException: JBAS014922: Directory
>>> /usr/share/jboss-as/standalone/data/content is not writable
>>>            at
>>> org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123)
>>>
>>>            at
>>> org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97)
>>>
>>>            at
>>> org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134)
>>>
>>> [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
>>>            at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>>>
>>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>>>            at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>>>
>>> [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>>>            ... 3 more
>>>
>>> 10:39:51,694 ERROR [stderr] java.util.concurrent.ExecutionException:
>>> Operation failed
>>> 10:39:51,695 ERROR [stderr]     at
>>> org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>>>
>>> 10:39:51,695 ERROR [stderr]     at
>>> org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>>> 10:39:51,695 ERROR [stderr]     at
>>> org.jboss.as.server.Main.main(Main.java:98)
>>> 10:39:51,695 ERROR [stderr]     at
>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> 10:39:51,695 ERROR [stderr]     at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>
>>> 10:39:51,707 ERROR [stderr]     at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>
>>> 10:39:51,707 ERROR [stderr]     at
>>> java.lang.reflect.Method.invoke(Method.java:601)
>>> 10:39:51,708 ERROR [stderr]     at
>>> org.jboss.modules.Module.run(Module.java:260)
>>> 10:39:51,708 ERROR [stderr]     at
>>> org.jboss.modules.Main.main(Main.java:291)
>>> 10:39:51,708 ERROR [stderr] Caused by:
>>> org.jboss.msc.service.StartException in service jboss.as: Failed to
>>> start service
>>> 10:39:51,708 ERROR [stderr]     at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767)
>>>
>>> 10:39:51,708 ERROR [stderr]     at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>>
>>> 10:39:51,708 ERROR [stderr]     at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>>
>>> 10:39:51,709 ERROR [stderr]     at java.lang.Thread.run(Thread.java:722)
>>> 10:39:51,709 ERROR [stderr] Caused by: java.lang.IllegalStateException:
>>> JBAS014922: Directory /usr/share/jboss-as/standalone/data/content is not
>>> writable
>>> 10:39:51,709 ERROR [stderr]     at
>>> org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.<init>(ContentRepository.java:123)
>>>
>>> 10:39:51,709 ERROR [stderr]     at
>>> org.jboss.as.repository.ContentRepository$Factory.addService(ContentRepository.java:97)
>>>
>>> 10:39:51,709 ERROR [stderr]     at
>>> org.jboss.as.server.ApplicationServerService.start(ApplicationServerService.java:134)
>>>
>>> 10:39:51,710 ERROR [stderr]     at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>>>
>>> 10:39:51,710 ERROR [stderr]     at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>>>
>>> 10:39:51,710 ERROR [stderr]     ... 3 more
>>> 13469
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>>
>
>


-- 
Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 
3?D, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L.


From simon at redhat.com  Sun Jun 17 09:44:19 2012
From: simon at redhat.com (Simon Grinberg)
Date: Sun, 17 Jun 2012 05:44:19 -0400 (EDT)
Subject: [Engine-devel] 'deactivate' disk - what's the use case?
In-Reply-To: <4FD72478.4070004@redhat.com>
Message-ID: <4358e83b-1e86-4b0a-9a1e-d62a4cc4f09e@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Yaniv Kaul" <ykaul at redhat.com>
> To: "Livnat Peer" <lpeer at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, June 12, 2012 2:14:00 PM
> Subject: Re: [Engine-devel] 'deactivate' disk - what's the use case?
> 
> On 06/12/2012 12:47 PM, Livnat Peer wrote:
> > On 12/06/12 12:40, Yaniv Kaul wrote:
> >> On 06/12/2012 12:34 PM, Itamar Heim wrote:
> >>> On 06/12/2012 12:25 PM, Yaniv Kaul wrote:
> >>>> I'm wondering what's the usefulness of having dual action of
> >>>> attach +
> >>>> activate to get a disk properly attached and working in a VM
> >>>> (and the
> >>>> deactivate and detach counterparts).
> >>>>
> >>>> The only reason I can think of is that we've annoyed the user by
> >>>> this
> >>>> useless dual action when working with storage domains in a data
> >>>> center
> >>>> for ages, and we wish to remain consistent and annoy the user in
> >>>> the
> >>>> disks scenario as well, but there may be a reason I'm not aware
> >>>> of.
> >>> deactivated is like having a disk in offline, or hot unplugging
> >>> when
> >>> you still want to retain it in the context of the vm
> >>> configuration
> >> I understand that, I just argue it's quite useless (offline can be
> >> done
> >> from within the guest OS),
> > You can deactivate the disk if for some reason it blocks the guest
> > from
> > starting. I think that if the disk not accessible the VM won't
> > start and
> > then you can deactivate the disk and start the VM.
> 
> You can also detach it to get the same effect with one less click of
> a
> button or an API call.

And then if you did it manually for 20 VMs as a temporary measure, you'll have to re-attach it to the VMs. Will you remember to which VM you should attach each of your floating disks? You may have to now consult event log. 
(And in any case you'll need better search capabilities on disk then what you have now)

There are use cases to have an off-line disks, the issue is how not to annoy the user. 
I think I've suggested in the past that by default:
Attach = Attach + set_Online
Detach = set_offline + Detach. 
Unless explicitly stated otherwise by the user.

Thus you do not annoy the user but still maintain the functionality.


> Y.
> 
> >
> >
> >> does not work that way in physical hardware
> >> (offline is a logical action within the OS), has very little value
> >> to
> >> the RHEV Admin (unless he's paranoid and afraid that the disk will
> >> become float and someone else would 'steal' it from his VM) and is
> >> annoying to require multiple actions.
> >> Y.
> >>
> >>>> TIA,
> >>>> Y.
> >>>> _______________________________________________
> >>>> 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 ykaul at redhat.com  Sun Jun 17 09:47:19 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Sun, 17 Jun 2012 12:47:19 +0300
Subject: [Engine-devel] 'deactivate' disk - what's the use case?
In-Reply-To: <4358e83b-1e86-4b0a-9a1e-d62a4cc4f09e@zmail17.collab.prod.int.phx2.redhat.com>
References: <4358e83b-1e86-4b0a-9a1e-d62a4cc4f09e@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4FDDA7A7.6060803@redhat.com>

On 06/17/2012 12:44 PM, Simon Grinberg wrote:
>
> ----- Original Message -----
>> From: "Yaniv Kaul" <ykaul at redhat.com>
>> To: "Livnat Peer" <lpeer at redhat.com>
>> Cc: engine-devel at ovirt.org
>> Sent: Tuesday, June 12, 2012 2:14:00 PM
>> Subject: Re: [Engine-devel] 'deactivate' disk - what's the use case?
>>
>> On 06/12/2012 12:47 PM, Livnat Peer wrote:
>>> On 12/06/12 12:40, Yaniv Kaul wrote:
>>>> On 06/12/2012 12:34 PM, Itamar Heim wrote:
>>>>> On 06/12/2012 12:25 PM, Yaniv Kaul wrote:
>>>>>> I'm wondering what's the usefulness of having dual action of
>>>>>> attach +
>>>>>> activate to get a disk properly attached and working in a VM
>>>>>> (and the
>>>>>> deactivate and detach counterparts).
>>>>>>
>>>>>> The only reason I can think of is that we've annoyed the user by
>>>>>> this
>>>>>> useless dual action when working with storage domains in a data
>>>>>> center
>>>>>> for ages, and we wish to remain consistent and annoy the user in
>>>>>> the
>>>>>> disks scenario as well, but there may be a reason I'm not aware
>>>>>> of.
>>>>> deactivated is like having a disk in offline, or hot unplugging
>>>>> when
>>>>> you still want to retain it in the context of the vm
>>>>> configuration
>>>> I understand that, I just argue it's quite useless (offline can be
>>>> done
>>>> from within the guest OS),
>>> You can deactivate the disk if for some reason it blocks the guest
>>> from
>>> starting. I think that if the disk not accessible the VM won't
>>> start and
>>> then you can deactivate the disk and start the VM.
>> You can also detach it to get the same effect with one less click of
>> a
>> button or an API call.
> And then if you did it manually for 20 VMs as a temporary measure, you'll have to re-attach it to the VMs. Will you remember to which VM you should attach each of your floating disks? You may have to now consult event log.
> (And in any case you'll need better search capabilities on disk then what you have now)

I still fail to see what the common use case for 
'deactivate-but-not-detach' is.
I assume the description for the disk is automatically filled by engine 
when the disk is created attached to the VM. I'm 99.9% my assumption is 
naive and I'll open a RFE for it...
Y.

>
> There are use cases to have an off-line disks, the issue is how not to annoy the user.
> I think I've suggested in the past that by default:
> Attach = Attach + set_Online
> Detach = set_offline + Detach.
> Unless explicitly stated otherwise by the user.
>
> Thus you do not annoy the user but still maintain the functionality.
>
>
>> Y.
>>
>>>
>>>> does not work that way in physical hardware
>>>> (offline is a logical action within the OS), has very little value
>>>> to
>>>> the RHEV Admin (unless he's paranoid and afraid that the disk will
>>>> become float and someone else would 'steal' it from his VM) and is
>>>> annoying to require multiple actions.
>>>> Y.
>>>>
>>>>>> TIA,
>>>>>> Y.
>>>>>> _______________________________________________
>>>>>> 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 jhernand at redhat.com  Mon Jun 18 11:45:51 2012
From: jhernand at redhat.com (Juan Hernandez)
Date: Mon, 18 Jun 2012 13:45:51 +0200
Subject: [Engine-devel] Version number changed to 3.1.0 (removing the _0001
	suffix)
Message-ID: <4FDF14EF.2000108@redhat.com>

Hello,

Please note that the suffix _0001 has been removed from the artifact 
versions and from the RPM version. This shouldn't be a problem, but if 
you find issues please let me know.

Also take extra care when merging changes to any POM files, as you may 
be undoing the change for that particular POM file.

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 oliel at redhat.com  Mon Jun 18 12:31:07 2012
From: oliel at redhat.com (Ori Liel)
Date: Mon, 18 Jun 2012 08:31:07 -0400 (EDT)
Subject: [Engine-devel] 'deactivate' disk - what's the use case?
In-Reply-To: <4FDDA7A7.6060803@redhat.com>
Message-ID: <a0ae05ba-b904-4b83-91fc-494136ae3e59@zmail17.collab.prod.int.phx2.redhat.com>

>On 06/17/2012 12:44 PM, Simon Grinberg wrote:
>>
>> ----- Original Message -----
>>> From: "Yaniv Kaul" <ykaul at redhat.com>
>>> To: "Livnat Peer" <lpeer at redhat.com>
>>> Cc: engine-devel at ovirt.org
>>> Sent: Tuesday, June 12, 2012 2:14:00 PM
>>> Subject: Re: [Engine-devel] 'deactivate' disk - what's the use case?
>>>
>>> On 06/12/2012 12:47 PM, Livnat Peer wrote:
>>>> On 12/06/12 12:40, Yaniv Kaul wrote:
>>>>> On 06/12/2012 12:34 PM, Itamar Heim wrote:
>>>>>> On 06/12/2012 12:25 PM, Yaniv Kaul wrote:
>>>>>>> I'm wondering what's the usefulness of having dual action of
>>>>>>> attach +
>>>>>>> activate to get a disk properly attached and working in a VM
>>>>>>> (and the
>>>>>>> deactivate and detach counterparts).
>>>>>>>
>>>>>>> The only reason I can think of is that we've annoyed the user by
>>>>>>> this
>>>>>>> useless dual action when working with storage domains in a data
>>>>>>> center
>>>>>>> for ages, and we wish to remain consistent and annoy the user in
>>>>>>> the
>>>>>>> disks scenario as well, but there may be a reason I'm not aware
>>>>>>> of.
>>>>>> deactivated is like having a disk in offline, or hot unplugging
>>>>>> when
>>>>>> you still want to retain it in the context of the vm
>>>>>> configuration
>>>>> I understand that, I just argue it's quite useless (offline can be
>>>>> done
>>>>> from within the guest OS),
>>>> You can deactivate the disk if for some reason it blocks the guest
>>>> from
>>>> starting. I think that if the disk not accessible the VM won't
>>>> start and
>>>> then you can deactivate the disk and start the VM.
>>> You can also detach it to get the same effect with one less click of
>>> a
>>> button or an API call.
>> And then if you did it manually for 20 VMs as a temporary measure, you'll have to re-attach it to the VMs. Will you remember to which VM you should attach each of your floating disks? You may have to now consult event log.
>> (And in any case you'll need better search capabilities on disk then what you have now)
>
>I still fail to see what the common use case for
>'deactivate-but-not-detach' is.

Perhaps the use case is: "I want to run the VM without this disk, but I don't want 
to make this disk available for other VMs" (since detached disk is 'up for grabs'.

>I assume the description for the disk is automatically filled by engine
>when the disk is created attached to the VM. I'm 99.9% my assumption is
>naive and I'll open a RFE for it...
>Y.
>
>>
>> There are use cases to have an off-line disks, the issue is how not to annoy the user.
>> I think I've suggested in the past that by default:
>> Attach = Attach + set_Online
>> Detach = set_offline + Detach.
>> Unless explicitly stated otherwise by the user.
>>
>> Thus you do not annoy the user but still maintain the functionality.
>>
>>
>>> Y.
>>>
>>>>
>>>>> does not work that way in physical hardware
>>>>> (offline is a logical action within the OS), has very little value
>>>>> to
>>>>> the RHEV Admin (unless he's paranoid and afraid that the disk will
>>>>> become float and someone else would 'steal' it from his VM) and is
>>>>> annoying to require multiple actions.
>>>>> Y.
>>>>>
>>>>>>> TIA,
>>>>>>> Y.
>>>>>>> _______________________________________________
>>>>>>> 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 oliel at redhat.com  Mon Jun 18 13:16:01 2012
From: oliel at redhat.com (Ori Liel)
Date: Mon, 18 Jun 2012 09:16:01 -0400 (EDT)
Subject: [Engine-devel] 'deactivate' disk - what's the use case?
In-Reply-To: <a0ae05ba-b904-4b83-91fc-494136ae3e59@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <c3b98184-03a1-4025-97fc-94a3316a5633@zmail17.collab.prod.int.phx2.redhat.com>

>
>
>----- Original Message -----
>From: "Ori Liel" <oliel at redhat.com>
>To: "Yaniv Kaul" <ykaul at redhat.com>
>Cc: engine-devel at ovirt.org, "Simon Grinberg" <simon at redhat.com>
>Sent: Monday, June 18, 2012 3:31:07 PM
>Subject: Re: [Engine-devel] 'deactivate' disk - what's the use case?
>
>>On 06/17/2012 12:44 PM, Simon Grinberg wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Yaniv Kaul" <ykaul at redhat.com>
>>>> To: "Livnat Peer" <lpeer at redhat.com>
>>>> Cc: engine-devel at ovirt.org
>>>> Sent: Tuesday, June 12, 2012 2:14:00 PM
>>>> Subject: Re: [Engine-devel] 'deactivate' disk - what's the use case?
>>>>
>>>> On 06/12/2012 12:47 PM, Livnat Peer wrote:
>>>>> On 12/06/12 12:40, Yaniv Kaul wrote:
>>>>>> On 06/12/2012 12:34 PM, Itamar Heim wrote:
>>>>>>> On 06/12/2012 12:25 PM, Yaniv Kaul wrote:
>>>>>>>> I'm wondering what's the usefulness of having dual action of
>>>>>>>> attach +
>>>>>>>> activate to get a disk properly attached and working in a VM
>>>>>>>> (and the
>>>>>>>> deactivate and detach counterparts).
>>>>>>>>
>>>>>>>> The only reason I can think of is that we've annoyed the user by
>>>>>>>> this
>>>>>>>> useless dual action when working with storage domains in a data
>>>>>>>> center
>>>>>>>> for ages, and we wish to remain consistent and annoy the user in
>>>>>>>> the
>>>>>>>> disks scenario as well, but there may be a reason I'm not aware
>>>>>>>> of.
>>>>>>> deactivated is like having a disk in offline, or hot unplugging
>>>>>>> when
>>>>>>> you still want to retain it in the context of the vm
>>>>>>> configuration
>>>>>> I understand that, I just argue it's quite useless (offline can be
>>>>>> done
>>>>>> from within the guest OS),
>>>>> You can deactivate the disk if for some reason it blocks the guest
>>>>> from
>>>>> starting. I think that if the disk not accessible the VM won't
>>>>> start and
>>>>> then you can deactivate the disk and start the VM.
>>>> You can also detach it to get the same effect with one less click of
>>>> a
>>>> button or an API call.
>>> And then if you did it manually for 20 VMs as a temporary measure, you'll have to re-attach it to the VMs. Will you remember to which VM you should attach each of your floating disks? You may have to now consult event log.
>>> (And in any case you'll need better search capabilities on disk then what you have now)
>>
>>I still fail to see what the common use case for
>>'deactivate-but-not-detach' is.
>
>Perhaps the use case is: "I want to run the VM without this disk, but I don't want 
>to make this disk available for other VMs" (since detached disk is 'up for grabs'.
>

(this is relevant only for non-shareable disks, as shareable disks can be attached to more
than one VM. If we only had only shareable disks in the system, then detach=deactivate).

>>I assume the description for the disk is automatically filled by engine
>>when the disk is created attached to the VM. I'm 99.9% my assumption is
>>naive and I'll open a RFE for it...
>>Y.
>>
>>>
>>> There are use cases to have an off-line disks, the issue is how not to annoy the user.
>>> I think I've suggested in the past that by default:
>>> Attach = Attach + set_Online
>>> Detach = set_offline + Detach.
>>> Unless explicitly stated otherwise by the user.
>>>
>>> Thus you do not annoy the user but still maintain the functionality.
>>>
>>>
>>>> Y.
>>>>
>>>>>
>>>>>> does not work that way in physical hardware
>>>>>> (offline is a logical action within the OS), has very little value
>>>>>> to
>>>>>> the RHEV Admin (unless he's paranoid and afraid that the disk will
>>>>>> become float and someone else would 'steal' it from his VM) and is
>>>>>> annoying to require multiple actions.
>>>>>> Y.
>>>>>>
>>>>>>>> TIA,
>>>>>>>> Y.
>>>>>>>> _______________________________________________
>>>>>>>> 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 amureini at redhat.com  Mon Jun 18 14:01:23 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Mon, 18 Jun 2012 10:01:23 -0400 (EDT)
Subject: [Engine-devel] Developer's All In One
In-Reply-To: <0984b10c-7109-4d94-bd74-b1947e97e061@zmail18.collab.prod.int.phx2.redhat.com>
Message-ID: <93ae29b9-6274-4a02-acb0-db34affa5890@zmail17.collab.prod.int.phx2.redhat.com>

Cross-posting to engine-devel

> ----- Forwarded Message -----
> From: "Yeela Kaplan" <ykaplan at redhat.com>
> To: vdsm-devel at lists.fedorahosted.org,
> engine-devel at lists.fedorahosted.org
> Cc: "Ayal Baron" <abaron at redhat.com>
> Sent: Monday, June 18, 2012 2:58:55 PM
> Subject: Developer's All In One
> 
> Enclosed is the link to a wiki containing a detailed explanation for
> installing a developer's All-In-One environment:
>  
> http://www.ovirt.org/wiki/Developers_All_In_One
> 
> Regards,
> Yeela
> 


From shuming at linux.vnet.ibm.com  Mon Jun 18 15:56:18 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Mon, 18 Jun 2012 23:56:18 +0800
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FC5EAA6.3090605@linux.vnet.ibm.com>
References: <4FC5EAA6.3090605@linux.vnet.ibm.com>
Message-ID: <4FDF4FA2.6000106@linux.vnet.ibm.com>

On 2012-5-30 17:38, Deepak C Shetty wrote:
> Hello All,
>
>     I have a draft write-up on the VDSM-libstoragemgmt integration.
> I wanted to run this thru' the mailing list(s) to help tune and 
> crystallize it, before putting it on the ovirt wiki.
> I have run this once thru Ayal and Tony, so have some of their 
> comments incorporated.
>
> I still have few doubts/questions, which I have posted below with 
> lines ending with '?'
>
> Comments / Suggestions are welcome & appreciated.
>
> thanx,
> deepak
>
> [Ccing engine-devel and libstoragemgmt lists as this stuff is relevant 
> to them too]
>
> -------------------------------------------------------------------------------------------------------------- 
>
>
> 1) Background:
>
> VDSM provides high level API for node virtualization management. It 
> acts in response to the requests sent by oVirt Engine, which uses VDSM 
> to do all node virtualization related tasks, including but not limited 
> to storage management.
>
> libstoragemgmt aims to provide vendor agnostic API for managing 
> external storage array. It should help system administrators utilizing 
> open source solutions have a way to programmatically manage their 
> storage hardware in a vendor neutral way. It also aims to facilitate 
> management automation, ease of use and take advantage of storage 
> vendor supported features which improve storage performance and space 
> utilization.
>
> Home Page: http://sourceforge.net/apps/trac/libstoragemgmt/
>
> libstoragemgmt (LSM) today supports C and python plugins for talking 
> to external storage array using SMI-S as well as native interfaces 
> (eg: netapp plugin )
> Plan is to grow the SMI-S interface as needed over time and add more 
> vendor specific plugins for exploiting features not possible via SMI-S 
> or have better alternatives than using SMI-S.
> For eg: Many of the copy offload features require to use vendor 
> specific commands, which justifies the need for a vendor specific plugin.
>
>
> 2) Goals:
>
>     2a) Ability to plugin external storage array into oVirt/VDSM 
> virtualization stack, in a vendor neutral way.
>
>     2b) Ability to list features/capabilities and other statistical 
> info of the array
>
>     2c) Ability to utilize the storage array offload capabilities from 
> oVirt/VDSM.
>
>
> 3) Details:
>
> LSM will sit as a new repository engine in VDSM.
> VDSM Repository Engine WIP @ http://gerrit.ovirt.org/#change,192
>
> Current plan is to have LSM co-exist with VDSM on the virtualization 
> nodes.

Does that mean LSM will be a different daemon process than VDSM?  Also, 
how about the vendor's plugin, another process in the nodes?

>
> *Note : 'storage' used below is generic. It can be a file/nfs-export 
> for NAS targets and LUN/logical-drive for SAN targets.
>
> VDSM can use LSM and do the following...
>     - Provision storage
>     - Consume storage
>
> 3.1) Provisioning Storage using LSM
>
> Typically this will be done by a Storage administrator.
>
> oVirt/VDSM should provide storage admin the
>     - ability to list the different storage arrays along with their 
> types (NAS/SAN), capabilities, free/used space.
>     - ability to provision storage using any of the array capabilities 
> (eg: thin provisioned lun or new NFS export )
>     - ability to manage the provisioned storage (eg: resize/delete 
> storage)
>
> Once the storage is provisioned by the storage admin, VDSM will have 
> to refresh the host(s) for them to be able to see the newly 
> provisioned storage.
>
> 3.1.1) Potential flows:
>
> Mgmt -> vdsm -> lsm: create LUN + LUN Mapping / Zoning / whatever is 
> needed to make LUN available to list of hosts passed by mgmt
> Mgmt -> vdsm: getDeviceList (refreshes host and gets list of devices)
>  Repeat above for all relevant hosts (depending on list passed 
> earlier, mostly relevant when extending an existing VG)
> Mgmt -> use LUN in normal flows.
>
>
> 3.1.2) How oVirt Engine will know which LSM to use ?
>
> Normally the way this works today is that user can choose the host to 
> use (default today is SPM), however there are a few flows where mgmt 
> will know which host to use:
> 1. extend storage domain (add LUN to existing VG) - Use SPM and make 
> sure *all* hosts that need access to this SD can see the new LUN
> 2. attach new LUN to a VM which is pinned to a specific host - use 
> this host
> 3. attach new LUN to a VM which is not pinned - use a host from the 
> cluster the VM belongs to and make sure all nodes in cluster can see 
> the new LUN

So this model depend on the work of removing storage pool?

>
> Flows for which there is no clear candidate (Maybe we can use the SPM 
> host itself which is the default ?)
> 1. create a new disk without attaching it to any VM

So the new floating disk should be exported to all nodes and all VMs?

> 2. create a LUN for a new storage domain
>
>
> 3.2) Consuming storage using LSM
>
> Typically this will be done by a virtualization administrator
>
> oVirt/VDSM should allow virtualization admin to
>     - Create a new storage domain using the storage on the array.
>     - Be able to specify whether VDSM should use the storage offload 
> capability (default) or override it to use its own internal logic.
>
> 4) VDSM potential changes:
>
> 4.1) How to represent a VM disk, 1 LUN = 1 VMdisk or 1 LV = 1 VMdisk ? 
> which bring another question...1 array == 1 storage domain OR 1 
> LUN/nfs-export on the array == 1 storage domain ?
>
> Pros & Cons of each...
>
> 1 array == 1 storage domain
>     - Each new vmdisk (aka volume) will be a new lun/file on the array.
>     - Easier to exploit offload capabilities, as they are available at 
> the LUN/File granularity
>     - Will there be any issues where there will be too many LUNs/Files 
> ... any maxluns limit on linux hosts that we might hit ?
>         -- VDSM has been tested with 1K LUNs and it worked fine - ayal
>     - Storage array limitations on the number of LUNs can be a 
> downside here.
>     - Would it be ok to share the array for hosting another storage 
> domain if need be ?
>         -- Provided the existing domain is not utilising all of the 
> free space
>         -- We can create new LUNs and hand it over to anyone needed ?
>     -- Changes needed in VDSM to work with raw LUNs, today it only has 
> support for consuming LUNs via VG/LV.
>
> 1 LUN/nfs-export on the array == 1 storage domain
>     - How to represent a new vmdisk (aka vdsm volume) if its a LUN 
> provisioned using SAN target ?
>         -- Will it be VG/LV as is done today for block domains ?
>         -- If yes, then it will be difficult to exploit offload 
> capabilities, as they are at LUN level, not at LV level.
>     - Each new vmdisk will be a new file on the nfs-export, assuming 
> offload capability is available at the file level, so this should work 
> for NAS targets ?
>     - Can use the storage array for hosting multiple storage domains.
>         -- Provision one more LUN and use it for another storage 
> domain if need be.
>     - VDSM already supports this today, as part of block storage 
> domains for LUNs case.
>
> Note that we will allow user to do either one of the two options 
> above, depending on need.
>
> 4.2) Storage domain metadata will also include the 
> features/capabilities of the storage array as reported by LSM.
>         - Capabilities (taken via LSM) will be stored in the domain 
> metadata during storage domain create flow.
>         - Need changes in oVirt engine as well ( see 'oVirt Engine 
> potential changes' section below )
>
> 4.3) VDSM to poll LSM for array capabilities on a regular basis ?
> Per ayal:
>     - If we have a 'storage array' entity in oVirt Engine (see 'oVirt 
> Engine potential changes' section below ) then we can have a 'refresh 
> capabilities' button/verb.
>     - We can periodically query the storage array.
>     - Query LSM before running operations (sounds redundant to me, but 
> if it's cheap enough it could be simplest).
>
>     Probably need a combination of 1+2 (query at very low frequency - 
> 1/hour or 1/day + refresh button)
>
>
> 5) oVirt Engine potential changes - as described by ayal :
>
>     - We will either need a new 'storage array' entity in engine to 
> keep credentials, or, in case of storage array as storage domain, just 
> keep this info as part of the domain at engine level.
>     - Have a 'storage array' entity in oVirt Engine to support  
> 'refresh capabilities' as a button/verb.
>     - When user during storage provisioning, selects a LUN exported 
> from a storage array (via LSM), the oVirt Engine would know from then 
> onwards that this LUN is being served via LSM.
>       It would then  be able to query the  capabilities of the LUN and 
> show it to the virt admin during storage consumption flow.
>
> 6) Potential flows:
>     - Create snapshot flow
>         -- VDSM will check the snapshot offload capability in the 
> domain metadata
>         -- If available, and override is not configured, it will use 
> LSM to offload LUN/File snapshot

If a LSM try to snapshot a running volume, does that mean all the IO 
activity to the volume will be blocked when the snapshot is undergoing?

>         -- If override is configured or capability is not available, 
> it will use its internal logic to create
>            snapshot (qcow2).
>
>     - Copy/Clone vmdisk flow
>         -- VDSM will check the copy offload capability in the domain 
> metadata
>         -- If available, and override is not configured, it will use 
> LSM to offload LUN/File copy
>         -- If override is configured or capability is not available, 
> it will use its internal logic to create
>            snapshot (eg: dd cmd in case of LUN).
>
> 7) LSM potential changes:
>
>     - list features/capabilities of the array. Eg: copy offload, thin 
> prov. etc.
>     - list containers (aka pools) (present in LSM today)
>     - Ability to list different types of arrays being managed, their 
> capabilities and used/free space
>     - Ability to create/list/delete/resize volumes ( LUN or exports, 
> available in LSM as of today)
>     - Get monitoring info with object (LUN/snapshot/volume) as 
> optional parameter for specific info. eg: container/pool free/used 
> space, raid type etc.
>
> Need to make sure above info is listed in a coherent way across arrays 
> (number of LUNs, raid type used? free/total per container/pool, per 
> LUN?. Also need I/O statistics wherever possible.
>
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel


-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From smizrahi at redhat.com  Mon Jun 18 20:15:05 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Mon, 18 Jun 2012 16:15:05 -0400 (EDT)
Subject: [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt integration
In-Reply-To: <4FC5EAA6.3090605@linux.vnet.ibm.com>
Message-ID: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>

First of all I'd like to suggest not using the LSM acronym as it can also mean live-storage-migration and maybe other things.

Secondly I would like to avoid talking about what needs to be changed in VDSM before we figure out what exactly we want to accomplish.

Also, there is no mention on credentials in any part of the process.
How does VDSM or the host get access to actually modify the storage array?
Who holds the creds for that and how?
How does the user set this up?

In the array as domain case. How are the luns being mapped to initiators. What about setting discovery credentials.
In the array set up case. How will the hosts be represented in regards to credentials?
How will the different schemes and capabilities in regard to authentication methods will be expressed.

Rest of the comments inline

----- Original Message -----
> From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
> To: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>
> Cc: libstoragemgmt-devel at lists.sourceforge.net, engine-devel at ovirt.org
> Sent: Wednesday, May 30, 2012 5:38:46 AM
> Subject: [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt integration
> 
> Hello All,
> 
>      I have a draft write-up on the VDSM-libstoragemgmt integration.
> I wanted to run this thru' the mailing list(s) to help tune and
> crystallize it, before putting it on the ovirt wiki.
> I have run this once thru Ayal and Tony, so have some of their
> comments
> incorporated.
> 
> I still have few doubts/questions, which I have posted below with
> lines
> ending with '?'
> 
> Comments / Suggestions are welcome & appreciated.
> 
> thanx,
> deepak
> 
> [Ccing engine-devel and libstoragemgmt lists as this stuff is
> relevant
> to them too]
> 
> --------------------------------------------------------------------------------------------------------------
> 
> 1) Background:
> 
> VDSM provides high level API for node virtualization management. It
> acts
> in response to the requests sent by oVirt Engine, which uses VDSM to
> do
> all node virtualization related tasks, including but not limited to
> storage management.
> 
> libstoragemgmt aims to provide vendor agnostic API for managing
> external
> storage array. It should help system administrators utilizing open
> source solutions have a way to programmatically manage their storage
> hardware in a vendor neutral way. It also aims to facilitate
> management
> automation, ease of use and take advantage of storage vendor
> supported
> features which improve storage performance and space utilization.
> 
> Home Page: http://sourceforge.net/apps/trac/libstoragemgmt/
> 
> libstoragemgmt (LSM) today supports C and python plugins for talking
> to
> external storage array using SMI-S as well as native interfaces (eg:
> netapp plugin )
> Plan is to grow the SMI-S interface as needed over time and add more
> vendor specific plugins for exploiting features not possible via
> SMI-S
> or have better alternatives than using SMI-S.
> For eg: Many of the copy offload features require to use vendor
> specific
> commands, which justifies the need for a vendor specific plugin.
> 
> 
> 2) Goals:
> 
>      2a) Ability to plugin external storage array into oVirt/VDSM
> virtualization stack, in a vendor neutral way.
> 
>      2b) Ability to list features/capabilities and other statistical
> info of the array
> 
>      2c) Ability to utilize the storage array offload capabilities
>      from
> oVirt/VDSM.
> 
> 
> 3) Details:
> 
> LSM will sit as a new repository engine in VDSM.
> VDSM Repository Engine WIP @ http://gerrit.ovirt.org/#change,192
> 
> Current plan is to have LSM co-exist with VDSM on the virtualization
> nodes.
> 
> *Note : 'storage' used below is generic. It can be a file/nfs-export
> for
> NAS targets and LUN/logical-drive for SAN targets.
> 
> VDSM can use LSM and do the following...
>      - Provision storage
>      - Consume storage
> 
> 3.1) Provisioning Storage using LSM
> 
> Typically this will be done by a Storage administrator.
> 
> oVirt/VDSM should provide storage admin the
>      - ability to list the different storage arrays along with their
> types (NAS/SAN), capabilities, free/used space.
>      - ability to provision storage using any of the array
>      capabilities
> (eg: thin provisioned lun or new NFS export )
>      - ability to manage the provisioned storage (eg: resize/delete
>      storage)
> 
> Once the storage is provisioned by the storage admin, VDSM will have
> to
> refresh the host(s) for them to be able to see the newly provisioned
> storage.
[SM] What about the clustered case, The management or the mailbox will have to be involved. Pros\Cons? Is there a capability for the storage to announce a change in topology? Can libstoragemgmt consume it? Does it even make sense?
> 
> 3.1.1) Potential flows:
> 
> Mgmt -> vdsm -> lsm: create LUN + LUN Mapping / Zoning / whatever is
> needed to make LUN available to list of hosts passed by mgmt
> Mgmt -> vdsm: getDeviceList (refreshes host and gets list of devices)
>   Repeat above for all relevant hosts (depending on list passed
>   earlier,
> mostly relevant when extending an existing VG)
> Mgmt -> use LUN in normal flows.
[SM] This is all a bit vague in my opinion, concrete cases might prove more beneficial.
> 
> 
> 3.1.2) How oVirt Engine will know which LSM to use ?
> 
> Normally the way this works today is that user can choose the host to
> use (default today is SPM), however there are a few flows where mgmt
> will know which host to use:
> 1. extend storage domain (add LUN to existing VG) - Use SPM and make
> sure *all* hosts that need access to this SD can see the new LUN
> 2. attach new LUN to a VM which is pinned to a specific host - use
> this host
> 3. attach new LUN to a VM which is not pinned - use a host from the
> cluster the VM belongs to and make sure all nodes in cluster can see
> the
> new LUN
> 
> Flows for which there is no clear candidate (Maybe we can use the SPM
> host itself which is the default ?)
> 1. create a new disk without attaching it to any VM
> 2. create a LUN for a new storage domain

[SM] Maybe the engine should do the work? What about permission? Will all hosts have the credentials to mess with the storage? Will they be passed on a per call basis to prevent other users from having access to the storage?
> 
> 
> 3.2) Consuming storage using LSM
> 
> Typically this will be done by a virtualization administrator
> 
> oVirt/VDSM should allow virtualization admin to
>      - Create a new storage domain using the storage on the array.
>      - Be able to specify whether VDSM should use the storage offload
> capability (default) or override it to use its own internal logic.
> 
> 4) VDSM potential changes:
> 
> 4.1) How to represent a VM disk, 1 LUN = 1 VMdisk or 1 LV = 1 VMdisk
I find this hard to understand. Maybe a different notation?
In ant case there is an abstracted case ie. storage domain. And there is a direct case ie. user provision luns to be used by VDSM and others as well.
The will both have different ways of representing the same underlying objects.
Also, I think that credentials might be tricky to represent as different arrays use different schemes to allocated users\hosts to luns\targets.
> ?
> which bring another question...1 array == 1 storage domain OR 1
> LUN/nfs-export on the array == 1 storage domain ?
> 
> Pros & Cons of each...
> 
> 1 array == 1 storage domain
>      - Each new vmdisk (aka volume) will be a new lun/file on the
>      array.
>      - Easier to exploit offload capabilities, as they are available
>      at
> the LUN/File granularity
>      - Will there be any issues where there will be too many
>      LUNs/Files
> ... any maxluns limit on linux hosts that we might hit ?
>          -- VDSM has been tested with 1K LUNs and it worked fine -
>          ayal
>      - Storage array limitations on the number of LUNs can be a
>      downside
> here.
>      - Would it be ok to share the array for hosting another storage
> domain if need be ?
>          -- Provided the existing domain is not utilising all of the
> free space
>          -- We can create new LUNs and hand it over to anyone needed
>          ?
>      -- Changes needed in VDSM to work with raw LUNs, today it only
>      has
> support for consuming LUNs via VG/LV.
> 
> 1 LUN/nfs-export on the array == 1 storage domain
>      - How to represent a new vmdisk (aka vdsm volume) if its a LUN
> provisioned using SAN target ?
>          -- Will it be VG/LV as is done today for block domains ?
>          -- If yes, then it will be difficult to exploit offload
> capabilities, as they are at LUN level, not at LV level.
>      - Each new vmdisk will be a new file on the nfs-export, assuming
> offload capability is available at the file level, so this should
> work
> for NAS targets ?
>      - Can use the storage array for hosting multiple storage
>      domains.
>          -- Provision one more LUN and use it for another storage
>          domain
> if need be.
>      - VDSM already supports this today, as part of block storage
> domains for LUNs case.
> 
> Note that we will allow user to do either one of the two options
> above,
> depending on need.
> 
> 4.2) Storage domain metadata will also include the
> features/capabilities
> of the storage array as reported by LSM.
>          - Capabilities (taken via LSM) will be stored in the domain
> metadata during storage domain create flow.
>          - Need changes in oVirt engine as well ( see 'oVirt Engine
> potential changes' section below )
> 
> 4.3) VDSM to poll LSM for array capabilities on a regular basis ?
> Per ayal:
>      - If we have a 'storage array' entity in oVirt Engine (see
>      'oVirt
> Engine potential changes' section below ) then we can have a 'refresh
> capabilities' button/verb.
>      - We can periodically query the storage array.
>      - Query LSM before running operations (sounds redundant to me,
>      but
> if it's cheap enough it could be simplest).
> 
>      Probably need a combination of 1+2 (query at very low frequency
>      -
> 1/hour or 1/day + refresh button)
> 
> 
> 5) oVirt Engine potential changes - as described by ayal :
> 
>      - We will either need a new 'storage array' entity in engine to
> keep credentials, or, in case of storage array as storage domain,
> just
> keep this info as part of the domain at engine level.
>      - Have a 'storage array' entity in oVirt Engine to support
> 'refresh capabilities' as a button/verb.
>      - When user during storage provisioning, selects a LUN exported
> from a storage array (via LSM), the oVirt Engine would know from then
> onwards that this LUN is being served via LSM.
>        It would then  be able to query the  capabilities of the LUN
>        and
> show it to the virt admin during storage consumption flow.
> 
> 6) Potential flows:
>      - Create snapshot flow
>          -- VDSM will check the snapshot offload capability in the
> domain metadata
>          -- If available, and override is not configured, it will use
> LSM to offload LUN/File snapshot
>          -- If override is configured or capability is not available,
>          it
> will use its internal logic to create
>             snapshot (qcow2).
> 
>      - Copy/Clone vmdisk flow
>          -- VDSM will check the copy offload capability in the domain
> metadata
>          -- If available, and override is not configured, it will use
> LSM to offload LUN/File copy
>          -- If override is configured or capability is not available,
>          it
> will use its internal logic to create
>             snapshot (eg: dd cmd in case of LUN).
> 
> 7) LSM potential changes:
> 
>      - list features/capabilities of the array. Eg: copy offload,
>      thin
> prov. etc.
>      - list containers (aka pools) (present in LSM today)
>      - Ability to list different types of arrays being managed, their
> capabilities and used/free space
>      - Ability to create/list/delete/resize volumes ( LUN or exports,
> available in LSM as of today)
>      - Get monitoring info with object (LUN/snapshot/volume) as
>      optional
> parameter for specific info. eg: container/pool free/used space, raid
> type etc.
> 
> Need to make sure above info is listed in a coherent way across
> arrays
> (number of LUNs, raid type used? free/total per container/pool, per
> LUN?. Also need I/O statistics wherever possible.
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From shuming at linux.vnet.ibm.com  Tue Jun 19 06:18:34 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Tue, 19 Jun 2012 14:18:34 +0800
Subject: [Engine-devel] Questions about ovirt engine
Message-ID: <4FE019BA.7060809@linux.vnet.ibm.com>

Hi,

I created a VM in my engine.  And I found that every time I run the VM 
after shutdown, the VM uuid was changed to a different not while the VM 
itself was not changed including the VM name.  Why doesn't engine keep 
the UUID for a VM and  use the UUID every time the VM starts?  How can I 
persistent my setting to a  VM with "vdsClient", like the password set 
by the "setVmTicket" command?

-- 
Shu Ming<shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From iheim at redhat.com  Tue Jun 19 06:34:16 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 19 Jun 2012 09:34:16 +0300
Subject: [Engine-devel] Questions about ovirt engine
In-Reply-To: <4FE019BA.7060809@linux.vnet.ibm.com>
References: <4FE019BA.7060809@linux.vnet.ibm.com>
Message-ID: <4FE01D68.2040601@redhat.com>

On 06/19/2012 09:18 AM, Shu Ming wrote:
> Hi,
>
> I created a VM in my engine. And I found that every time I run the VM
> after shutdown, the VM uuid was changed to a different not while the VM
> itself was not changed including the VM name. Why doesn't engine keep

that is very strange. can you please attach vdsm logs from two run vm 
commands of the same vm?

> the UUID for a VM and use the UUID every time the VM starts? How can I
> persistent my setting to a VM with "vdsClient", like the password set by
> the "setVmTicket" command?
>

you don't - we fix the bug...


From Dustin.Schoenbrun at netapp.com  Tue Jun 19 13:24:15 2012
From: Dustin.Schoenbrun at netapp.com (Schoenbrun, Dustin)
Date: Tue, 19 Jun 2012 13:24:15 +0000
Subject: [Engine-devel] GWT 2.4.0 and the oVirt Engine
Message-ID: <CC06582E.A7BF%dustin.schoenbrun@netapp.com>

Hey All,

I was looking at doing some work with extending the oVirt Engine GUI but some of the functionality that I need (such as dynamic creation of tabs) is only supported in GWT 2.4.0.  What sort of steps would have to be taken to update the Engine to GWT 2.4.0?  Also, what would be the easiest way of debugging and testing these updates through Eclipse, for example.  Thanks in advance!

-- Dustin

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

From vszocs at redhat.com  Tue Jun 19 14:40:28 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 19 Jun 2012 10:40:28 -0400 (EDT)
Subject: [Engine-devel] GWT 2.4.0 and the oVirt Engine
In-Reply-To: <CC06582E.A7BF%dustin.schoenbrun@netapp.com>
Message-ID: <a2e1e931-9cdb-413c-b1cb-f540617aa5d8@zmail16.collab.prod.int.phx2.redhat.com>

Hi Dustin, 

here are the basic steps for migrating oVirt web applications to GWT 2.4 and GWTP 0.7: 

1. update gwt.version property value to 2.4.0 in following POM files: 

    ? frontend/webadmin/modules/ gwt-common /pom.xml 
    ? frontend/webadmin/modules/ gwt-extension /pom.xml 
    ? frontend/webadmin/modules/ userportal-gwtp /pom.xml 
    ? frontend/webadmin/modules/ webadmin /pom.xml 


Note: oVirt root POM still defines gwt.version with value 2.2.0 , which is effectively inherited by frontend and uicompat modules (located at frontend/webadmin/modules ). This shouldn't be an issue, however, we should consolidate GWT version definition later on. 



2. update gwtp.version property value to 0.7 in frontend/webadmin/modules/pom.xml 


3. follow GWTP 0.7 migration steps , which will most likely involve UI code changes 


For all steps mentioned above, I'm planning to make a patch, since step (3) requires deeper knowledge of GWTP/WebAdmin code. 




In addition, here are the extra steps to finalize the migration (these items are relevant long-term, can be skipped for now): 


4. remove HTML5 drag'n'drop classes (originally copied from GWT 2.4 trunk) by removing following WebAdmin packages: 

    ? com.google.gwt.dom.client 
    ? com.google.gwt.event.dom.client 


5. adjust UI code regarding GWT Editor framework, which is now capable of handling primitive boolean is/has getter methods 



Vojtech 






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

From: "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com> 
To: engine-devel at ovirt.org 
Sent: Tuesday, June 19, 2012 3:24:15 PM 
Subject: [Engine-devel] GWT 2.4.0 and the oVirt Engine 




Hey All, 


I was looking at doing some work with extending the oVirt Engine GUI but some of the functionality that I need (such as dynamic creation of tabs) is only supported in GWT 2.4.0. What sort of steps would have to be taken to update the Engine to GWT 2.4.0? Also, what would be the easiest way of debugging and testing these updates through Eclipse, for example. Thanks in advance! 




-- Dustin 


_______________________________________________ 
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/20120619/cbda5f36/attachment.html>

From vszocs at redhat.com  Tue Jun 19 14:59:57 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 19 Jun 2012 10:59:57 -0400 (EDT)
Subject: [Engine-devel] GWT 2.4.0 and the oVirt Engine
In-Reply-To: <CC06582E.A7BF%dustin.schoenbrun@netapp.com>
Message-ID: <a61878d0-86a3-47f7-a7d4-3a333f64cd71@zmail16.collab.prod.int.phx2.redhat.com>

Forgot the debugging question :) 

To apply and test your changes using GWT development mode (emulated JS runtime environment): 

1. perform full oVirt Maven build: 


$ cd <OVIRT_HOME> 
$ mvn clean install -Psetup,dep,gwt-admin,gwt-user -Dmaven.test.skip 

2. upgrade your local PostgreSQL engine database: 


$ cd <OVIRT_HOME>/backend/manager/dbscripts/ 
$ ./upgrade.sh -u postgres 

3. start your JBoss AS 7.1.1 server instance (running in standalone mode): 


$ cd <JBOSS_HOME>/bin/ 
$ ./standalone.sh 

4. invoke GWT development mode for WebAdmin module (using GWT Maven plugin): 


$ cd <OVIRT_HOME>/frontend/webadmin/modules/webadmin/ 
$ mvn gwt:debug -Pgwtdev,gwt-admin -Dgwt.noserver=true 

5. in your Eclipse IDE, create new Remote Java Application debug configuration (port 8000) and start the debug session 

6. your Eclipse IDE will connect to GWT development mode and GWT development window will show up 

7. access WebAdmin using browser at http://127.0.0.1:8080/webadmin/webadmin/WebAdmin.html?gwt.codesvr=127.0.0.1:9997 

8. in case you don't have GWT developer plugin installed in your browser, you will be prompted to install it 

9. after any code change, you need to refresh (F5) WebAdmin browser window 

Vojtech 


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

From: "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com> 
To: engine-devel at ovirt.org 
Sent: Tuesday, June 19, 2012 3:24:15 PM 
Subject: [Engine-devel] GWT 2.4.0 and the oVirt Engine 




Hey All, 


I was looking at doing some work with extending the oVirt Engine GUI but some of the functionality that I need (such as dynamic creation of tabs) is only supported in GWT 2.4.0. What sort of steps would have to be taken to update the Engine to GWT 2.4.0? Also, what would be the easiest way of debugging and testing these updates through Eclipse, for example. Thanks in advance! 




-- Dustin 


_______________________________________________ 
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/20120619/19a2b002/attachment.html>

From deepakcs at linux.vnet.ibm.com  Tue Jun 19 15:10:31 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Tue, 19 Jun 2012 20:40:31 +0530
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FDF4FA2.6000106@linux.vnet.ibm.com>
References: <4FC5EAA6.3090605@linux.vnet.ibm.com>
	<4FDF4FA2.6000106@linux.vnet.ibm.com>
Message-ID: <4FE09667.2090805@linux.vnet.ibm.com>

On 06/18/2012 09:26 PM, Shu Ming wrote:
> On 2012-5-30 17:38, Deepak C Shetty wrote:
>> Hello All,
>>
>>     I have a draft write-up on the VDSM-libstoragemgmt integration.
>> I wanted to run this thru' the mailing list(s) to help tune and 
>> crystallize it, before putting it on the ovirt wiki.
>> I have run this once thru Ayal and Tony, so have some of their 
>> comments incorporated.
>>
>> I still have few doubts/questions, which I have posted below with 
>> lines ending with '?'
>>
>> Comments / Suggestions are welcome & appreciated.
>>
>> thanx,
>> deepak
>>
>> [Ccing engine-devel and libstoragemgmt lists as this stuff is 
>> relevant to them too]
>>
>> -------------------------------------------------------------------------------------------------------------- 
>>
>>
>> 1) Background:
>>
>> VDSM provides high level API for node virtualization management. It 
>> acts in response to the requests sent by oVirt Engine, which uses 
>> VDSM to do all node virtualization related tasks, including but not 
>> limited to storage management.
>>
>> libstoragemgmt aims to provide vendor agnostic API for managing 
>> external storage array. It should help system administrators 
>> utilizing open source solutions have a way to programmatically manage 
>> their storage hardware in a vendor neutral way. It also aims to 
>> facilitate management automation, ease of use and take advantage of 
>> storage vendor supported features which improve storage performance 
>> and space utilization.
>>
>> Home Page: http://sourceforge.net/apps/trac/libstoragemgmt/
>>
>> libstoragemgmt (LSM) today supports C and python plugins for talking 
>> to external storage array using SMI-S as well as native interfaces 
>> (eg: netapp plugin )
>> Plan is to grow the SMI-S interface as needed over time and add more 
>> vendor specific plugins for exploiting features not possible via 
>> SMI-S or have better alternatives than using SMI-S.
>> For eg: Many of the copy offload features require to use vendor 
>> specific commands, which justifies the need for a vendor specific 
>> plugin.
>>
>>
>> 2) Goals:
>>
>>     2a) Ability to plugin external storage array into oVirt/VDSM 
>> virtualization stack, in a vendor neutral way.
>>
>>     2b) Ability to list features/capabilities and other statistical 
>> info of the array
>>
>>     2c) Ability to utilize the storage array offload capabilities 
>> from oVirt/VDSM.
>>
>>
>> 3) Details:
>>
>> LSM will sit as a new repository engine in VDSM.
>> VDSM Repository Engine WIP @ http://gerrit.ovirt.org/#change,192
>>
>> Current plan is to have LSM co-exist with VDSM on the virtualization 
>> nodes.
>
> Does that mean LSM will be a different daemon process than VDSM?  
> Also, how about the vendor's plugin, another process in the nodes?

Pls see the LSM homepage on sourceforge.net on how LSM works. It already 
has a lsmd ( daemon) which invokes the appropriate plugin based on the 
URI prefix.
vendor plugins in LSM are supported in LSM as a .py module, which is 
invoked based on the URI prefix, which will be vendor specific. See the 
netapp vendor plugin.py in LSM source.

>
>>
>> *Note : 'storage' used below is generic. It can be a file/nfs-export 
>> for NAS targets and LUN/logical-drive for SAN targets.
>>
>> VDSM can use LSM and do the following...
>>     - Provision storage
>>     - Consume storage
>>
>> 3.1) Provisioning Storage using LSM
>>
>> Typically this will be done by a Storage administrator.
>>
>> oVirt/VDSM should provide storage admin the
>>     - ability to list the different storage arrays along with their 
>> types (NAS/SAN), capabilities, free/used space.
>>     - ability to provision storage using any of the array 
>> capabilities (eg: thin provisioned lun or new NFS export )
>>     - ability to manage the provisioned storage (eg: resize/delete 
>> storage)
>>
>> Once the storage is provisioned by the storage admin, VDSM will have 
>> to refresh the host(s) for them to be able to see the newly 
>> provisioned storage.
>>
>> 3.1.1) Potential flows:
>>
>> Mgmt -> vdsm -> lsm: create LUN + LUN Mapping / Zoning / whatever is 
>> needed to make LUN available to list of hosts passed by mgmt
>> Mgmt -> vdsm: getDeviceList (refreshes host and gets list of devices)
>>  Repeat above for all relevant hosts (depending on list passed 
>> earlier, mostly relevant when extending an existing VG)
>> Mgmt -> use LUN in normal flows.
>>
>>
>> 3.1.2) How oVirt Engine will know which LSM to use ?
>>
>> Normally the way this works today is that user can choose the host to 
>> use (default today is SPM), however there are a few flows where mgmt 
>> will know which host to use:
>> 1. extend storage domain (add LUN to existing VG) - Use SPM and make 
>> sure *all* hosts that need access to this SD can see the new LUN
>> 2. attach new LUN to a VM which is pinned to a specific host - use 
>> this host
>> 3. attach new LUN to a VM which is not pinned - use a host from the 
>> cluster the VM belongs to and make sure all nodes in cluster can see 
>> the new LUN
>
> So this model depend on the work of removing storage pool?

I am not sure and want the experts to comment here. I am not very clear 
yet on how things will work post SPM is gone. Here its assumed SPM is 
present.

>
>>
>> Flows for which there is no clear candidate (Maybe we can use the SPM 
>> host itself which is the default ?)
>> 1. create a new disk without attaching it to any VM
>
> So the new floating disk should be exported to all nodes and all VMs?
>
>> 2. create a LUN for a new storage domain
>>
>>
>> 3.2) Consuming storage using LSM
>>
>> Typically this will be done by a virtualization administrator
>>
>> oVirt/VDSM should allow virtualization admin to
>>     - Create a new storage domain using the storage on the array.
>>     - Be able to specify whether VDSM should use the storage offload 
>> capability (default) or override it to use its own internal logic.
>>
>> 4) VDSM potential changes:
>>
>> 4.1) How to represent a VM disk, 1 LUN = 1 VMdisk or 1 LV = 1 VMdisk 
>> ? which bring another question...1 array == 1 storage domain OR 1 
>> LUN/nfs-export on the array == 1 storage domain ?
>>
>> Pros & Cons of each...
>>
>> 1 array == 1 storage domain
>>     - Each new vmdisk (aka volume) will be a new lun/file on the array.
>>     - Easier to exploit offload capabilities, as they are available 
>> at the LUN/File granularity
>>     - Will there be any issues where there will be too many 
>> LUNs/Files ... any maxluns limit on linux hosts that we might hit ?
>>         -- VDSM has been tested with 1K LUNs and it worked fine - ayal
>>     - Storage array limitations on the number of LUNs can be a 
>> downside here.
>>     - Would it be ok to share the array for hosting another storage 
>> domain if need be ?
>>         -- Provided the existing domain is not utilising all of the 
>> free space
>>         -- We can create new LUNs and hand it over to anyone needed ?
>>     -- Changes needed in VDSM to work with raw LUNs, today it only 
>> has support for consuming LUNs via VG/LV.
>>
>> 1 LUN/nfs-export on the array == 1 storage domain
>>     - How to represent a new vmdisk (aka vdsm volume) if its a LUN 
>> provisioned using SAN target ?
>>         -- Will it be VG/LV as is done today for block domains ?
>>         -- If yes, then it will be difficult to exploit offload 
>> capabilities, as they are at LUN level, not at LV level.
>>     - Each new vmdisk will be a new file on the nfs-export, assuming 
>> offload capability is available at the file level, so this should 
>> work for NAS targets ?
>>     - Can use the storage array for hosting multiple storage domains.
>>         -- Provision one more LUN and use it for another storage 
>> domain if need be.
>>     - VDSM already supports this today, as part of block storage 
>> domains for LUNs case.
>>
>> Note that we will allow user to do either one of the two options 
>> above, depending on need.
>>
>> 4.2) Storage domain metadata will also include the 
>> features/capabilities of the storage array as reported by LSM.
>>         - Capabilities (taken via LSM) will be stored in the domain 
>> metadata during storage domain create flow.
>>         - Need changes in oVirt engine as well ( see 'oVirt Engine 
>> potential changes' section below )
>>
>> 4.3) VDSM to poll LSM for array capabilities on a regular basis ?
>> Per ayal:
>>     - If we have a 'storage array' entity in oVirt Engine (see 'oVirt 
>> Engine potential changes' section below ) then we can have a 'refresh 
>> capabilities' button/verb.
>>     - We can periodically query the storage array.
>>     - Query LSM before running operations (sounds redundant to me, 
>> but if it's cheap enough it could be simplest).
>>
>>     Probably need a combination of 1+2 (query at very low frequency - 
>> 1/hour or 1/day + refresh button)
>>
>>
>> 5) oVirt Engine potential changes - as described by ayal :
>>
>>     - We will either need a new 'storage array' entity in engine to 
>> keep credentials, or, in case of storage array as storage domain, 
>> just keep this info as part of the domain at engine level.
>>     - Have a 'storage array' entity in oVirt Engine to support  
>> 'refresh capabilities' as a button/verb.
>>     - When user during storage provisioning, selects a LUN exported 
>> from a storage array (via LSM), the oVirt Engine would know from then 
>> onwards that this LUN is being served via LSM.
>>       It would then  be able to query the  capabilities of the LUN 
>> and show it to the virt admin during storage consumption flow.
>>
>> 6) Potential flows:
>>     - Create snapshot flow
>>         -- VDSM will check the snapshot offload capability in the 
>> domain metadata
>>         -- If available, and override is not configured, it will use 
>> LSM to offload LUN/File snapshot
>
> If a LSM try to snapshot a running volume, does that mean all the IO 
> activity to the volume will be blocked when the snapshot is undergoing?

If VDSM offloads the snapshot to the array ( via LSM) the array will 
take care of the snapshotting.... typically i believe it will quiese the 
I/O temporarily for few ms ? and take a point-in-time copy of the 
LUN/File and resume the I/O... i think it will happen transparent to the 
vdsm/host.

>
>>         -- If override is configured or capability is not available, 
>> it will use its internal logic to create
>>            snapshot (qcow2).
>>
>>     - Copy/Clone vmdisk flow
>>         -- VDSM will check the copy offload capability in the domain 
>> metadata
>>         -- If available, and override is not configured, it will use 
>> LSM to offload LUN/File copy
>>         -- If override is configured or capability is not available, 
>> it will use its internal logic to create
>>            snapshot (eg: dd cmd in case of LUN).
>>
>> 7) LSM potential changes:
>>
>>     - list features/capabilities of the array. Eg: copy offload, thin 
>> prov. etc.
>>     - list containers (aka pools) (present in LSM today)
>>     - Ability to list different types of arrays being managed, their 
>> capabilities and used/free space
>>     - Ability to create/list/delete/resize volumes ( LUN or exports, 
>> available in LSM as of today)
>>     - Get monitoring info with object (LUN/snapshot/volume) as 
>> optional parameter for specific info. eg: container/pool free/used 
>> space, raid type etc.
>>
>> Need to make sure above info is listed in a coherent way across 
>> arrays (number of LUNs, raid type used? free/total per 
>> container/pool, per LUN?. Also need I/O statistics wherever possible.
>>
>>
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/vdsm-devel
>
>



From iheim at redhat.com  Tue Jun 19 15:48:46 2012
From: iheim at redhat.com (Itamar Heim)
Date: Tue, 19 Jun 2012 18:48:46 +0300
Subject: [Engine-devel] GWT 2.4.0 and the oVirt Engine
In-Reply-To: <a2e1e931-9cdb-413c-b1cb-f540617aa5d8@zmail16.collab.prod.int.phx2.redhat.com>
References: <a2e1e931-9cdb-413c-b1cb-f540617aa5d8@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <4FE09F5E.8030707@redhat.com>

On 06/19/2012 05:40 PM, Vojtech Szocs wrote:
> Hi Dustin,
...

> 3. follow GWTP 0.7 migration steps
> <http://code.google.com/p/gwt-platform/wiki/PortingV1#V0.7>, which will
> most likely involve UI code changes

can these be backward compatible with gwt 2.3?

>
>
> For all steps mentioned above, I'm planning to make a patch, since step
> (3) requires deeper knowledge of GWTP/WebAdmin code.
>
>
>
> In addition, here are the extra steps to finalize the migration (these
> items are relevant long-term, can be skipped for now):
>
>
> 4. remove HTML5 drag'n'drop classes (originally copied from GWT 2.4
> trunk) by removing following WebAdmin packages:
>
>   * com.google.gwt.dom.client
>   * com.google.gwt.event.dom.client
>
> 5. adjust UI code regarding GWT Editor framework, which is now capable
> of handling primitive boolean is/has getter methods
> <http://code.google.com/p/google-web-toolkit/issues/detail?id=6040>

is this 2.3 compatible?
is it a must step or optional?

6. test thoroughly webadmin and user portal behave correctly...


From vszocs at redhat.com  Tue Jun 19 16:25:57 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 19 Jun 2012 12:25:57 -0400 (EDT)
Subject: [Engine-devel] GWT 2.4.0 and the oVirt Engine
In-Reply-To: <4FE09F5E.8030707@redhat.com>
Message-ID: <61b8e713-eae2-4e22-aba9-557cc1bd5560@zmail16.collab.prod.int.phx2.redhat.com>

Hi Itamar,

>> 3. follow GWTP 0.7 migration steps
>> <http://code.google.com/p/gwt-platform/wiki/PortingV1#V0.7>, which will
>> most likely involve UI code changes
>
> can these be backward compatible with gwt 2.3?

In short, yes.

Technically, GWTP 0.7 should work with GWT 2.3 - GWTP migration wiki doesn't mention this explicitly.
Practically, GWTP 0.7 is built against GWT 2.4 - see "gwt.version" definition in [http://code.google.com/p/gwt-platform/source/browse/pom.xml?name=gwtp-0.7]

>> 5. adjust UI code regarding GWT Editor framework, which is now capable
>> of handling primitive boolean is/has getter methods
>> <http://code.google.com/p/google-web-toolkit/issues/detail?id=6040>
>
> is this 2.3 compatible?
> is it a must step or optional?

Step 5 is not compatible with GWT 2.3. It represents a bugfix that is shipped in GWT 2.4.
Steps 4 and 5 are optional (cleanup-like), but should be done in long-term.

> 6. test thoroughly webadmin and user portal behave correctly...

Fully agreed.

Vojtech


----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: engine-devel at ovirt.org
Sent: Tuesday, June 19, 2012 5:48:46 PM
Subject: Re: [Engine-devel] GWT 2.4.0 and the oVirt Engine

On 06/19/2012 05:40 PM, Vojtech Szocs wrote:
> Hi Dustin,
...

> 3. follow GWTP 0.7 migration steps
> <http://code.google.com/p/gwt-platform/wiki/PortingV1#V0.7>, which will
> most likely involve UI code changes

can these be backward compatible with gwt 2.3?

>
>
> For all steps mentioned above, I'm planning to make a patch, since step
> (3) requires deeper knowledge of GWTP/WebAdmin code.
>
>
>
> In addition, here are the extra steps to finalize the migration (these
> items are relevant long-term, can be skipped for now):
>
>
> 4. remove HTML5 drag'n'drop classes (originally copied from GWT 2.4
> trunk) by removing following WebAdmin packages:
>
>   * com.google.gwt.dom.client
>   * com.google.gwt.event.dom.client
>
> 5. adjust UI code regarding GWT Editor framework, which is now capable
> of handling primitive boolean is/has getter methods
> <http://code.google.com/p/google-web-toolkit/issues/detail?id=6040>

is this 2.3 compatible?
is it a must step or optional?

6. test thoroughly webadmin and user portal behave correctly...


From smizrahi at redhat.com  Tue Jun 19 21:32:20 2012
From: smizrahi at redhat.com (Saggi Mizrahi)
Date: Tue, 19 Jun 2012 17:32:20 -0400 (EDT)
Subject: [Engine-devel] [virt-node] VDSM as a general purpose virt host
	manager
In-Reply-To: <2945f14d-c5aa-4f7f-ade1-5fc83ef8482a@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <dc2369f9-35fc-414f-8e96-0168bf226db4@zmail16.collab.prod.int.phx2.redhat.com>

There is an important discussion starting about the future of the VDSM API on
vdsm-devel. If you want to be involved in the future of the VDSM API don't miss
out and join vdsm-devel. To sign up go to
https://fedorahosted.org/mailman/listinfo/vdsm-devel

There growing need for a way to more easily reuse of the functionality of VDSM
in order to service projects other than Ovirt-Engine.

Originally VDSM was created as a proprietary agent for the sole purpose of
serving the then proprietary version of what is known as ovirt-engine. Red Hat,
after acquiring the technology, pressed on with it's commitment to open source
ideals and released the code. But just releasing code into the wild doesn't
build a community or makes a project successful. Further more when building
open source software you should aspire to build reusable components instead of
monolithic stacks.

We would like to expose a stable, documented, well supported API. This gives
us a chance to rethink the VDSM API from the ground up. There is already work
in progress of making the internal logic of VDSM separate enough from the API
layer so we could continue feature development and bug fixing while designing
the API of the future.

In order to achieve this though we need to do several things:
   1. Declare API supportability guidelines
   2. Decide on an API transport (e.g. REST, ZMQ, AMQP)
   3. Make the API easily consumable (e.g. proper docs, example code, extending
      the API, etc)
   4. Implement the API itself

All of these are dependent on one another and the permutations are endless.
This is why I think we should try and work on each one separately. All
discussions will be done openly on the mailing list and until the final version
comes out nothing is set in stone.

If you think you have anything to contribute to this process, please do so
either by commenting on the discussions or by sending code/docs/whatever
patches. Once the API solidifies it will be quite difficult to change
fundamental things, so speak now or forever hold your peace. Note that this is
just an introductory email. There will be a quick follow up email to kick start
the discussions. Don't forget to sign up to the vdsm-devel mailing list.


From shuming at linux.vnet.ibm.com  Thu Jun 21 00:22:16 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Thu, 21 Jun 2012 08:22:16 +0800
Subject: [Engine-devel] [virt-node] VDSM as a general purpose virt host
 manager
In-Reply-To: <dc2369f9-35fc-414f-8e96-0168bf226db4@zmail16.collab.prod.int.phx2.redhat.com>
References: <dc2369f9-35fc-414f-8e96-0168bf226db4@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <4FE26938.2060602@linux.vnet.ibm.com>

On 2012-6-20 5:32, Saggi Mizrahi wrote:
> There is an important discussion starting about the future of the VDSM API on
> vdsm-devel. If you want to be involved in the future of the VDSM API don't miss
> out and join vdsm-devel. To sign up go to
> https://fedorahosted.org/mailman/listinfo/vdsm-devel
>
> There growing need for a way to more easily reuse of the functionality of VDSM
> in order to service projects other than Ovirt-Engine.
>
> Originally VDSM was created as a proprietary agent for the sole purpose of
> serving the then proprietary version of what is known as ovirt-engine. Red Hat,
> after acquiring the technology, pressed on with it's commitment to open source
> ideals and released the code. But just releasing code into the wild doesn't
> build a community or makes a project successful. Further more when building
> open source software you should aspire to build reusable components instead of
> monolithic stacks.
>
> We would like to expose a stable, documented, well supported API. This gives
> us a chance to rethink the VDSM API from the ground up. There is already work
> in progress of making the internal logic of VDSM separate enough from the API
> layer so we could continue feature development and bug fixing while designing
> the API of the future.
>
> In order to achieve this though we need to do several things:
>     1. Declare API supportability guidelines
>     2. Decide on an API transport (e.g. REST, ZMQ, AMQP)
>     3. Make the API easily consumable (e.g. proper docs, example code, extending
>        the API, etc)
>     4. Implement the API itself
Now,  VDSM version was highly bound with oVirt Engine version.  In order 
to make oVirt to work, both VDSM and ovirt engine should be synced with 
the latest binary, no back compatibility yet.  If we want to break this 
binding out,  we should classify the level of the VDSM APIs like these:

1) public stable
2) public evolving
3) undocumented volatile

And the we should make sure public stable interfaces to be supported in 
a very long time as possible as we can.  public evolving interfaces 
should keep the compatibility in the same major release(ie, 4.x.x). 
undocumented volatile is not recommended to the application and it is 
the responsibility of the application to take the risk.


>
> All of these are dependent on one another and the permutations are endless.
> This is why I think we should try and work on each one separately. All
> discussions will be done openly on the mailing list and until the final version
> comes out nothing is set in stone.
>
> If you think you have anything to contribute to this process, please do so
> either by commenting on the discussions or by sending code/docs/whatever
> patches. Once the API solidifies it will be quite difficult to change
> fundamental things, so speak now or forever hold your peace. Note that this is
> just an introductory email. There will be a quick follow up email to kick start
> the discussions. Don't forget to sign up to the vdsm-devel mailing list.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


-- 
Shu Ming <shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From oschreib at redhat.com  Thu Jun 21 08:37:41 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Thu, 21 Jun 2012 04:37:41 -0400 (EDT)
Subject: [Engine-devel] IMPORTANT: engine_3.1 branch created
In-Reply-To: <be00a17d-c182-4b86-8d98-258946d10578@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <253e794a-1ce8-4cb7-8a7a-9024e0c10199@zmail14.collab.prod.int.phx2.redhat.com>

Hey,

I created the engine_3.1 branch on gerrit.ovirt.org, based on commit 6ef9f873ab88a35c8ec5afdcbbab7541c0d54c4e (masayag: "core: Remove trailing comma from network names list", pushed Wed Jun 20 10:16:57 2012 +0300).

Any new critical bug fix, should be cherry-picked into engine_3.1 branch (by pushing the cherry-pick to refs/for/engine_3.1).
If you have a critical fix merged after this commit, please make sure it's cherry-picked properly.

Thanks,
--
Ofer Schreiber
oVirt Release Manager


From oschreib at redhat.com  Thu Jun 21 11:12:52 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Thu, 21 Jun 2012 07:12:52 -0400 (EDT)
Subject: [Engine-devel] IMPORTANT: engine_3.1 branch created
In-Reply-To: <253e794a-1ce8-4cb7-8a7a-9024e0c10199@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <a184f9fb-2abf-4bcd-805a-29a733acaa2d@zmail14.collab.prod.int.phx2.redhat.com>

Just a small update:
engine_3.1 branch has been rebased on 5692f204717817ad879f6b2c676b7681b8f868c8 (snmishra - engine: Refactored network.java to Network.java, pushed Jun 20 17:41:30 2012 +0300)

Ofer.
----- Original Message -----
> Hey,
> 
> I created the engine_3.1 branch on gerrit.ovirt.org, based on commit
> 6ef9f873ab88a35c8ec5afdcbbab7541c0d54c4e (masayag: "core: Remove
> trailing comma from network names list", pushed Wed Jun 20 10:16:57
> 2012 +0300).
> 
> Any new critical bug fix, should be cherry-picked into engine_3.1
> branch (by pushing the cherry-pick to refs/for/engine_3.1).
> If you have a critical fix merged after this commit, please make sure
> it's cherry-picked properly.
> 
> Thanks,
> --
> Ofer Schreiber
> oVirt Release Manager
> 


From vszocs at redhat.com  Thu Jun 21 15:03:13 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Thu, 21 Jun 2012 11:03:13 -0400 (EDT)
Subject: [Engine-devel] oVirt UI Plugins feature: Ready for review
In-Reply-To: <1962b477-89b3-4568-895f-cc96414453e5@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <9841e995-18d9-4993-95d5-4f48a580f946@zmail16.collab.prod.int.phx2.redhat.com>

Hi guys,

I wrote a wiki page describing UI Plugins, a feature planned for oVirt web administration (WebAdmin) application:
http://www.ovirt.org/wiki/Features/UIPlugins

Feature design is finished and ready for review. Please feel free to add comments, ask questions or reach me directly on #ovirt channel.

Cheers,
Vojtech


From agrover at redhat.com  Fri Jun 22 23:31:42 2012
From: agrover at redhat.com (Andy Grover)
Date: Fri, 22 Jun 2012 16:31:42 -0700
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>
References: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <4FE5005E.40703@redhat.com>

On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
> Also, there is no mention on credentials in any part of the process. 
> How does VDSM or the host get access to actually modify the storage
> array? Who holds the creds for that and how? How does the user set
> this up?

It seems to me more natural to have the oVirt-engine use libstoragemgmt
directly to allocate and export a volume on the storage array, and then
pass this info to the vdsm on the node creating the vm. This answers
Saggi's question about creds -- vdsm never needs array modification
creds, it only gets handed the params needed to connect and use the new
block device (ip, iqn, chap, lun).

Is this usage model made difficult or impossible by the current software
architecture?

Thanks -- Regards -- Andy


From iheim at redhat.com  Fri Jun 22 23:46:18 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sat, 23 Jun 2012 02:46:18 +0300
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FE5005E.40703@redhat.com>
References: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>
	<4FE5005E.40703@redhat.com>
Message-ID: <4FE503CA.60807@redhat.com>

On 06/23/2012 02:31 AM, Andy Grover wrote:
> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>> Also, there is no mention on credentials in any part of the process.
>> How does VDSM or the host get access to actually modify the storage
>> array? Who holds the creds for that and how? How does the user set
>> this up?
>
> It seems to me more natural to have the oVirt-engine use libstoragemgmt
> directly to allocate and export a volume on the storage array, and then
> pass this info to the vdsm on the node creating the vm. This answers
> Saggi's question about creds -- vdsm never needs array modification
> creds, it only gets handed the params needed to connect and use the new
> block device (ip, iqn, chap, lun).
>
> Is this usage model made difficult or impossible by the current software
> architecture?

what about live snapshots?


From agrover at redhat.com  Sat Jun 23 00:09:51 2012
From: agrover at redhat.com (Andy Grover)
Date: Fri, 22 Jun 2012 17:09:51 -0700
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FE503CA.60807@redhat.com>
References: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>
	<4FE5005E.40703@redhat.com> <4FE503CA.60807@redhat.com>
Message-ID: <4FE5094F.4090906@redhat.com>

On 06/22/2012 04:46 PM, Itamar Heim wrote:
> On 06/23/2012 02:31 AM, Andy Grover wrote:
>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>> Also, there is no mention on credentials in any part of the process.
>>> How does VDSM or the host get access to actually modify the storage
>>> array? Who holds the creds for that and how? How does the user set
>>> this up?
>>
>> It seems to me more natural to have the oVirt-engine use libstoragemgmt
>> directly to allocate and export a volume on the storage array, and then
>> pass this info to the vdsm on the node creating the vm. This answers
>> Saggi's question about creds -- vdsm never needs array modification
>> creds, it only gets handed the params needed to connect and use the new
>> block device (ip, iqn, chap, lun).
>>
>> Is this usage model made difficult or impossible by the current software
>> architecture?
> 
> what about live snapshots?

I'm not a virt guy, so extreme handwaving:

vm X uses luns 1 & 2

engine -> vdsm "pause vm X"
engine -> libstoragemgmt "snapshot luns 1, 2 to luns 3, 4"
engine -> vdsm "snapshot running state of X to Y"
engine -> vdsm "unpause vm X"
engine -> vdsm "change Y to use luns 3, 4"

?

-- Andy


From iheim at redhat.com  Sat Jun 23 12:40:53 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sat, 23 Jun 2012 15:40:53 +0300
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FE5094F.4090906@redhat.com>
References: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>
	<4FE5005E.40703@redhat.com> <4FE503CA.60807@redhat.com>
	<4FE5094F.4090906@redhat.com>
Message-ID: <4FE5B955.4070509@redhat.com>

On 06/23/2012 03:09 AM, Andy Grover wrote:
> On 06/22/2012 04:46 PM, Itamar Heim wrote:
>> On 06/23/2012 02:31 AM, Andy Grover wrote:
>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>>> Also, there is no mention on credentials in any part of the process.
>>>> How does VDSM or the host get access to actually modify the storage
>>>> array? Who holds the creds for that and how? How does the user set
>>>> this up?
>>>
>>> It seems to me more natural to have the oVirt-engine use libstoragemgmt
>>> directly to allocate and export a volume on the storage array, and then
>>> pass this info to the vdsm on the node creating the vm. This answers
>>> Saggi's question about creds -- vdsm never needs array modification
>>> creds, it only gets handed the params needed to connect and use the new
>>> block device (ip, iqn, chap, lun).
>>>
>>> Is this usage model made difficult or impossible by the current software
>>> architecture?
>>
>> what about live snapshots?
>
> I'm not a virt guy, so extreme handwaving:
>
> vm X uses luns 1&  2
>
> engine ->  vdsm "pause vm X"

that's pausing the VM. live snapshot isn't supposed to do so.

> engine ->  libstoragemgmt "snapshot luns 1, 2 to luns 3, 4"
> engine ->  vdsm "snapshot running state of X to Y"
> engine ->  vdsm "unpause vm X"

if engine had any failure before this step, the VM will remain paused. 
i.e., we compromised the VM to take a live snapshot.

> engine ->  vdsm "change Y to use luns 3, 4"
>
> ?
>
> -- Andy



From iheim at redhat.com  Sun Jun 24 10:20:25 2012
From: iheim at redhat.com (Itamar Heim)
Date: Sun, 24 Jun 2012 13:20:25 +0300
Subject: [Engine-devel] 3.1 bugs
Message-ID: <4FE6E9E9.6020005@redhat.com>

I have moved all MODIFIED bugs to ON_QA with target release of 3.1[1]

This will allow to easily distinguish them from bugs fixed from now on, 
and will allow reporters to try and verify the fix, should they choose to.

Plan is to close them currentrelease when 3.1 is released.

Thanks,
    Itamar


From amureini at redhat.com  Sun Jun 24 14:23:22 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Sun, 24 Jun 2012 10:23:22 -0400 (EDT)
Subject: [Engine-devel] Forking unit tests
In-Reply-To: <5b1ef373-7f50-4772-bbf0-e348023fbf56@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <28322afe-b430-4d3c-a039-b12387031dbe@zmail17.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Allon Mureinik" <amureini at redhat.com>
> To: "Mike Kolesnik" <mkolesni at redhat.com>
> Sent: Thursday, June 14, 2012 12:12:54 PM
> Subject: Re: Forking unit tests
> 
> 
> 
> ----- Original Message -----
> > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > To: "Allon Mureinik" <amureini at redhat.com>
> > Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "engine-devel"
> > <engine-devel at ovirt.org>
> > Sent: Wednesday, June 13, 2012 1:28:36 PM
> > Subject: Re: Forking unit tests
> > 
> > > Hi guys,
> > > 
> > > If you're using settings.xml as published in Building the oVirt
> > > Engine page, you'd see we're forking for every test, in every
> > > subproject.
> > > This behaviour was introduced to handle memory leaks in PowerMock
> > > we
> > > use in some subprojects, but is redundant in others.
> > > 
> > > Over the past month or so I've been working on removing PowerMock
> > > from as many places as possible (many thanks to mkolesni and
> > > lhornyak!), and we've got to the stage that forking is only
> > > needed
> > > in to subprojects - bll and resttypes.
> > 
> > +1 - great job!
> 10x!
> 
> > 
> > Would it be possible to have this as a parameter (defaul true) that
> > can be overridden, such as -Dengine.forkTests=false ?
> couldn't find a good way to do it <forkMode> doesn't seem to work
> when given a property as a value, sorry.
> :-(
Take a look at http://gerrit.ovirt.org/#/c/5653/1.
Once it is merged, you could user -Dengine.powermock.fork=one to stop forking.

> 
> > 
> > > The forking was defined explicitly in those two projects, so if
> > > you
> > > want to speed up your tests, just take the latest version of
> > > settings.xml from
> > > http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.
> > > 
> > > 
> > > -Allon
> > > 
> > 
> 


From shuming at linux.vnet.ibm.com  Sun Jun 24 14:28:29 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Sun, 24 Jun 2012 22:28:29 +0800
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FE5B955.4070509@redhat.com>
References: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>	<4FE5005E.40703@redhat.com>
	<4FE503CA.60807@redhat.com>	<4FE5094F.4090906@redhat.com>
	<4FE5B955.4070509@redhat.com>
Message-ID: <4FE7240D.2070407@linux.vnet.ibm.com>

On 2012-6-23 20:40, Itamar Heim wrote:
> On 06/23/2012 03:09 AM, Andy Grover wrote:
>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>>>> Also, there is no mention on credentials in any part of the process.
>>>>> How does VDSM or the host get access to actually modify the storage
>>>>> array? Who holds the creds for that and how? How does the user set
>>>>> this up?
>>>>
>>>> It seems to me more natural to have the oVirt-engine use 
>>>> libstoragemgmt
>>>> directly to allocate and export a volume on the storage array, and 
>>>> then
>>>> pass this info to the vdsm on the node creating the vm. This answers
>>>> Saggi's question about creds -- vdsm never needs array modification
>>>> creds, it only gets handed the params needed to connect and use the 
>>>> new
>>>> block device (ip, iqn, chap, lun).
>>>>
>>>> Is this usage model made difficult or impossible by the current 
>>>> software
>>>> architecture?
>>>
>>> what about live snapshots?
>>
>> I'm not a virt guy, so extreme handwaving:
>>
>> vm X uses luns 1&  2
>>
>> engine ->  vdsm "pause vm X"
>
> that's pausing the VM. live snapshot isn't supposed to do so.

Tough we don't expect to do a pausing operation to the VM when live 
snaphot is undergoing, the VM should be blocked on the access to 
specific luns for a while.  The blocking time should be very short to 
avoid the storage IO time out in the VM.

>
>> engine ->  libstoragemgmt "snapshot luns 1, 2 to luns 3, 4"
>> engine ->  vdsm "snapshot running state of X to Y"
>> engine ->  vdsm "unpause vm X"
>
> if engine had any failure before this step, the VM will remain paused. 
> i.e., we compromised the VM to take a live snapshot.
>
>> engine ->  vdsm "change Y to use luns 3, 4"
>>
>> ?
>>
>> -- Andy
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>


-- 
Shu Ming <shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From agrover at redhat.com  Mon Jun 25 02:05:45 2012
From: agrover at redhat.com (Andy Grover)
Date: Sun, 24 Jun 2012 19:05:45 -0700
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FE7240D.2070407@linux.vnet.ibm.com>
References: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>	<4FE5005E.40703@redhat.com>
	<4FE503CA.60807@redhat.com>	<4FE5094F.4090906@redhat.com>
	<4FE5B955.4070509@redhat.com> <4FE7240D.2070407@linux.vnet.ibm.com>
Message-ID: <4FE7C779.4040807@redhat.com>

On 06/24/2012 07:28 AM, Shu Ming wrote:
> On 2012-6-23 20:40, Itamar Heim wrote:
>> On 06/23/2012 03:09 AM, Andy Grover wrote:
>>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
>>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
>>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>>>>> Also, there is no mention on credentials in any part of the process.
>>>>>> How does VDSM or the host get access to actually modify the storage
>>>>>> array? Who holds the creds for that and how? How does the user set
>>>>>> this up?
>>>>>
>>>>> It seems to me more natural to have the oVirt-engine use
>>>>> libstoragemgmt
>>>>> directly to allocate and export a volume on the storage array, and
>>>>> then
>>>>> pass this info to the vdsm on the node creating the vm. This answers
>>>>> Saggi's question about creds -- vdsm never needs array modification
>>>>> creds, it only gets handed the params needed to connect and use the
>>>>> new
>>>>> block device (ip, iqn, chap, lun).
>>>>>
>>>>> Is this usage model made difficult or impossible by the current
>>>>> software
>>>>> architecture?
>>>>
>>>> what about live snapshots?
>>>
>>> I'm not a virt guy, so extreme handwaving:
>>>
>>> vm X uses luns 1&  2
>>>
>>> engine ->  vdsm "pause vm X"
>>
>> that's pausing the VM. live snapshot isn't supposed to do so.
> 
> Tough we don't expect to do a pausing operation to the VM when live
> snaphot is undergoing, the VM should be blocked on the access to
> specific luns for a while.  The blocking time should be very short to
> avoid the storage IO time out in the VM.

OK my mistake, we don't pause the VM during live snapshot, we block on
access to the luns while snapshotting. Does this keep live snapshots
working and mean ovirt-engine can use libsm to config the storage array
instead of vdsm?

Because that was really my main question, should we be talking about
engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
integration.

Thanks -- Regards -- Andy


From acathrow at redhat.com  Mon Jun 25 02:10:46 2012
From: acathrow at redhat.com (Andrew Cathrow)
Date: Sun, 24 Jun 2012 22:10:46 -0400 (EDT)
Subject: [Engine-devel] [vdsm] RFC: Writeup on
	VDSM-libstoragemgmt	integration
In-Reply-To: <4FE7C779.4040807@redhat.com>
Message-ID: <3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> From: "Andy Grover" <agrover at redhat.com>
> To: "Shu Ming" <shuming at linux.vnet.ibm.com>
> Cc: libstoragemgmt-devel at lists.sourceforge.net, engine-devel at ovirt.org, "VDSM Project Development"
> <vdsm-devel at lists.fedorahosted.org>
> Sent: Sunday, June 24, 2012 10:05:45 PM
> Subject: Re: [vdsm] [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt	integration
> 
> On 06/24/2012 07:28 AM, Shu Ming wrote:
> > On 2012-6-23 20:40, Itamar Heim wrote:
> >> On 06/23/2012 03:09 AM, Andy Grover wrote:
> >>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
> >>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
> >>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
> >>>>>> Also, there is no mention on credentials in any part of the
> >>>>>> process.
> >>>>>> How does VDSM or the host get access to actually modify the
> >>>>>> storage
> >>>>>> array? Who holds the creds for that and how? How does the user
> >>>>>> set
> >>>>>> this up?
> >>>>>
> >>>>> It seems to me more natural to have the oVirt-engine use
> >>>>> libstoragemgmt
> >>>>> directly to allocate and export a volume on the storage array,
> >>>>> and
> >>>>> then
> >>>>> pass this info to the vdsm on the node creating the vm. This
> >>>>> answers
> >>>>> Saggi's question about creds -- vdsm never needs array
> >>>>> modification
> >>>>> creds, it only gets handed the params needed to connect and use
> >>>>> the
> >>>>> new
> >>>>> block device (ip, iqn, chap, lun).
> >>>>>
> >>>>> Is this usage model made difficult or impossible by the current
> >>>>> software
> >>>>> architecture?
> >>>>
> >>>> what about live snapshots?
> >>>
> >>> I'm not a virt guy, so extreme handwaving:
> >>>
> >>> vm X uses luns 1&  2
> >>>
> >>> engine ->  vdsm "pause vm X"
> >>
> >> that's pausing the VM. live snapshot isn't supposed to do so.
> > 
> > Tough we don't expect to do a pausing operation to the VM when live
> > snaphot is undergoing, the VM should be blocked on the access to
> > specific luns for a while.  The blocking time should be very short
> > to
> > avoid the storage IO time out in the VM.
> 
> OK my mistake, we don't pause the VM during live snapshot, we block
> on
> access to the luns while snapshotting. Does this keep live snapshots
> working and mean ovirt-engine can use libsm to config the storage
> array
> instead of vdsm?
> 
> Because that was really my main question, should we be talking about
> engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
> integration.

for snapshotting wouldn't we want VDSM to handle the coordination of the various atomic functions?
> 
> Thanks -- Regards -- Andy
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel
> 


From shuming at linux.vnet.ibm.com  Mon Jun 25 02:17:38 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Mon, 25 Jun 2012 10:17:38 +0800
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
References: <3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <4FE7CA42.9050703@linux.vnet.ibm.com>

On 2012-6-25 10:10, Andrew Cathrow wrote:
>
> ----- Original Message -----
>> From: "Andy Grover" <agrover at redhat.com>
>> To: "Shu Ming" <shuming at linux.vnet.ibm.com>
>> Cc: libstoragemgmt-devel at lists.sourceforge.net, engine-devel at ovirt.org, "VDSM Project Development"
>> <vdsm-devel at lists.fedorahosted.org>
>> Sent: Sunday, June 24, 2012 10:05:45 PM
>> Subject: Re: [vdsm] [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt	integration
>>
>> On 06/24/2012 07:28 AM, Shu Ming wrote:
>>> On 2012-6-23 20:40, Itamar Heim wrote:
>>>> On 06/23/2012 03:09 AM, Andy Grover wrote:
>>>>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
>>>>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
>>>>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>>>>>>> Also, there is no mention on credentials in any part of the
>>>>>>>> process.
>>>>>>>> How does VDSM or the host get access to actually modify the
>>>>>>>> storage
>>>>>>>> array? Who holds the creds for that and how? How does the user
>>>>>>>> set
>>>>>>>> this up?
>>>>>>> It seems to me more natural to have the oVirt-engine use
>>>>>>> libstoragemgmt
>>>>>>> directly to allocate and export a volume on the storage array,
>>>>>>> and
>>>>>>> then
>>>>>>> pass this info to the vdsm on the node creating the vm. This
>>>>>>> answers
>>>>>>> Saggi's question about creds -- vdsm never needs array
>>>>>>> modification
>>>>>>> creds, it only gets handed the params needed to connect and use
>>>>>>> the
>>>>>>> new
>>>>>>> block device (ip, iqn, chap, lun).
>>>>>>>
>>>>>>> Is this usage model made difficult or impossible by the current
>>>>>>> software
>>>>>>> architecture?
>>>>>> what about live snapshots?
>>>>> I'm not a virt guy, so extreme handwaving:
>>>>>
>>>>> vm X uses luns 1&  2
>>>>>
>>>>> engine ->  vdsm "pause vm X"
>>>> that's pausing the VM. live snapshot isn't supposed to do so.
>>> Tough we don't expect to do a pausing operation to the VM when live
>>> snaphot is undergoing, the VM should be blocked on the access to
>>> specific luns for a while.  The blocking time should be very short
>>> to
>>> avoid the storage IO time out in the VM.
>> OK my mistake, we don't pause the VM during live snapshot, we block
>> on
>> access to the luns while snapshotting. Does this keep live snapshots
>> working and mean ovirt-engine can use libsm to config the storage
>> array
>> instead of vdsm?
>>
>> Because that was really my main question, should we be talking about
>> engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
>> integration.
> for snapshotting wouldn't we want VDSM to handle the coordination of the various atomic functions?

I think VDSM-libstoragemgmt will let the storage array itself to make 
the snapshot and handle the coordination of the various atomic 
functions. VDSM should be blocked on the following access to the 
specific luns which are under snapshotting.
>> Thanks -- Regards -- Andy
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/vdsm-devel
>>


-- 
Shu Ming <shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From deepakcs at linux.vnet.ibm.com  Mon Jun 25 14:14:08 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Mon, 25 Jun 2012 19:44:08 +0530
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FE7CA42.9050703@linux.vnet.ibm.com>
References: <3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
	<4FE7CA42.9050703@linux.vnet.ibm.com>
Message-ID: <4FE87230.4090500@linux.vnet.ibm.com>

On 06/25/2012 07:47 AM, Shu Ming wrote:
> On 2012-6-25 10:10, Andrew Cathrow wrote:
>>
>> ----- Original Message -----
>>> From: "Andy Grover" <agrover at redhat.com>
>>> To: "Shu Ming" <shuming at linux.vnet.ibm.com>
>>> Cc: libstoragemgmt-devel at lists.sourceforge.net, 
>>> engine-devel at ovirt.org, "VDSM Project Development"
>>> <vdsm-devel at lists.fedorahosted.org>
>>> Sent: Sunday, June 24, 2012 10:05:45 PM
>>> Subject: Re: [vdsm] [Engine-devel] RFC: Writeup on 
>>> VDSM-libstoragemgmt    integration
>>>
>>> On 06/24/2012 07:28 AM, Shu Ming wrote:
>>>> On 2012-6-23 20:40, Itamar Heim wrote:
>>>>> On 06/23/2012 03:09 AM, Andy Grover wrote:
>>>>>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
>>>>>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
>>>>>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>>>>>>>> Also, there is no mention on credentials in any part of the
>>>>>>>>> process.
>>>>>>>>> How does VDSM or the host get access to actually modify the
>>>>>>>>> storage
>>>>>>>>> array? Who holds the creds for that and how? How does the user
>>>>>>>>> set
>>>>>>>>> this up?
>>>>>>>> It seems to me more natural to have the oVirt-engine use
>>>>>>>> libstoragemgmt
>>>>>>>> directly to allocate and export a volume on the storage array,
>>>>>>>> and
>>>>>>>> then
>>>>>>>> pass this info to the vdsm on the node creating the vm. This
>>>>>>>> answers
>>>>>>>> Saggi's question about creds -- vdsm never needs array
>>>>>>>> modification
>>>>>>>> creds, it only gets handed the params needed to connect and use
>>>>>>>> the
>>>>>>>> new
>>>>>>>> block device (ip, iqn, chap, lun).
>>>>>>>>
>>>>>>>> Is this usage model made difficult or impossible by the current
>>>>>>>> software
>>>>>>>> architecture?
>>>>>>> what about live snapshots?
>>>>>> I'm not a virt guy, so extreme handwaving:
>>>>>>
>>>>>> vm X uses luns 1&  2
>>>>>>
>>>>>> engine ->  vdsm "pause vm X"
>>>>> that's pausing the VM. live snapshot isn't supposed to do so.
>>>> Tough we don't expect to do a pausing operation to the VM when live
>>>> snaphot is undergoing, the VM should be blocked on the access to
>>>> specific luns for a while.  The blocking time should be very short
>>>> to
>>>> avoid the storage IO time out in the VM.
>>> OK my mistake, we don't pause the VM during live snapshot, we block
>>> on
>>> access to the luns while snapshotting. Does this keep live snapshots
>>> working and mean ovirt-engine can use libsm to config the storage
>>> array
>>> instead of vdsm?
>>>
>>> Because that was really my main question, should we be talking about
>>> engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
>>> integration.
>> for snapshotting wouldn't we want VDSM to handle the coordination of 
>> the various atomic functions?
>
> I think VDSM-libstoragemgmt will let the storage array itself to make 
> the snapshot and handle the coordination of the various atomic 
> functions. VDSM should be blocked on the following access to the 
> specific luns which are under snapshotting.

I kind of agree. If snapshot is being done at the array level, then the 
array takes care of quiesing the I/O, taking the snapshot and allowing 
the I/O, why does VDSM have to worry about anything here, it should all 
happen transparently for VDSM, isnt it ?



From deepakcs at linux.vnet.ibm.com  Mon Jun 25 14:56:21 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Mon, 25 Jun 2012 20:26:21 +0530
Subject: [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt integration
In-Reply-To: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>
References: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <4FE87C15.3020501@linux.vnet.ibm.com>

On 06/19/2012 01:45 AM, Saggi Mizrahi wrote:
> First of all I'd like to suggest not using the LSM acronym as it can also mean live-storage-migration and maybe other things.

Sure, what do you suggest ? libSM ?

> Secondly I would like to avoid talking about what needs to be changed in VDSM before we figure out what exactly we want to accomplish.

> Also, there is no mention on credentials in any part of the process.
> How does VDSM or the host get access to actually modify the storage array?
> Who holds the creds for that and how?
> How does the user set this up?

Per my original discussion on this with Ayal, this is what he had 
suggested...
"In addition, I'm assuming we will either need a new 'storage array' 
entity in engine to keep credentials, or, in case of storage array as 
storage domain, just keep this info as part of the domain at engine level."

Either we can have the libstoragemgmt cred stored in the engine as part 
of engine-setup or have the user input them as part of Storage Prov and 
user clicks on "remember cred" button, so engine saves it and passes it 
to VDSM as needed ? In any way, the cred should come from the 
user/admin, no other way correct ?

> In the array as domain case. How are the luns being mapped to initiators. What about setting discovery credentials.
> In the array set up case. How will the hosts be represented in regards to credentials?
> How will the different schemes and capabilities in regard to authentication methods will be expressed.

Not clear on what the concern here is. Can you pls provide more clarity 
on the problem here ?
Maybe providing some examples will help.

> Rest of the comments inline
>
> ----- Original Message -----
>> From: "Deepak C Shetty"<deepakcs at linux.vnet.ibm.com>
>> To: "VDSM Project Development"<vdsm-devel at lists.fedorahosted.org>
>> Cc: libstoragemgmt-devel at lists.sourceforge.net, engine-devel at ovirt.org
>> Sent: Wednesday, May 30, 2012 5:38:46 AM
>> Subject: [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt integration
>>
>> Hello All,
>>
>>       I have a draft write-up on the VDSM-libstoragemgmt integration.
>> I wanted to run this thru' the mailing list(s) to help tune and
>> crystallize it, before putting it on the ovirt wiki.
>> I have run this once thru Ayal and Tony, so have some of their
>> comments
>> incorporated.
>>
>> I still have few doubts/questions, which I have posted below with
>> lines
>> ending with '?'
>>
>> Comments / Suggestions are welcome&  appreciated.
>>
>> thanx,
>> deepak
>>
>> [Ccing engine-devel and libstoragemgmt lists as this stuff is
>> relevant
>> to them too]
>>
>> --------------------------------------------------------------------------------------------------------------
>>
>> 1) Background:
>>
>> VDSM provides high level API for node virtualization management. It
>> acts
>> in response to the requests sent by oVirt Engine, which uses VDSM to
>> do
>> all node virtualization related tasks, including but not limited to
>> storage management.
>>
>> libstoragemgmt aims to provide vendor agnostic API for managing
>> external
>> storage array. It should help system administrators utilizing open
>> source solutions have a way to programmatically manage their storage
>> hardware in a vendor neutral way. It also aims to facilitate
>> management
>> automation, ease of use and take advantage of storage vendor
>> supported
>> features which improve storage performance and space utilization.
>>
>> Home Page: http://sourceforge.net/apps/trac/libstoragemgmt/
>>
>> libstoragemgmt (LSM) today supports C and python plugins for talking
>> to
>> external storage array using SMI-S as well as native interfaces (eg:
>> netapp plugin )
>> Plan is to grow the SMI-S interface as needed over time and add more
>> vendor specific plugins for exploiting features not possible via
>> SMI-S
>> or have better alternatives than using SMI-S.
>> For eg: Many of the copy offload features require to use vendor
>> specific
>> commands, which justifies the need for a vendor specific plugin.
>>
>>
>> 2) Goals:
>>
>>       2a) Ability to plugin external storage array into oVirt/VDSM
>> virtualization stack, in a vendor neutral way.
>>
>>       2b) Ability to list features/capabilities and other statistical
>> info of the array
>>
>>       2c) Ability to utilize the storage array offload capabilities
>>       from
>> oVirt/VDSM.
>>
>>
>> 3) Details:
>>
>> LSM will sit as a new repository engine in VDSM.
>> VDSM Repository Engine WIP @ http://gerrit.ovirt.org/#change,192
>>
>> Current plan is to have LSM co-exist with VDSM on the virtualization
>> nodes.
>>
>> *Note : 'storage' used below is generic. It can be a file/nfs-export
>> for
>> NAS targets and LUN/logical-drive for SAN targets.
>>
>> VDSM can use LSM and do the following...
>>       - Provision storage
>>       - Consume storage
>>
>> 3.1) Provisioning Storage using LSM
>>
>> Typically this will be done by a Storage administrator.
>>
>> oVirt/VDSM should provide storage admin the
>>       - ability to list the different storage arrays along with their
>> types (NAS/SAN), capabilities, free/used space.
>>       - ability to provision storage using any of the array
>>       capabilities
>> (eg: thin provisioned lun or new NFS export )
>>       - ability to manage the provisioned storage (eg: resize/delete
>>       storage)
>>
>> Once the storage is provisioned by the storage admin, VDSM will have
>> to
>> refresh the host(s) for them to be able to see the newly provisioned
>> storage.
> [SM] What about the clustered case, The management or the mailbox will have to be involved. Pros\Cons? Is there a capability for the storage to announce a change in topology? Can libstoragemgmt consume it? Does it even make sense?

A change in storage topology can only happen via the storage admin 
provisioning new LUNs, so why not have 'refresh capability' as a verb in 
the 'storage array' entity which causes VDSM to refresh the hosts via 
getDeviceList as put in 3.1.1 below ? Refresh capability can be invoked 
manually by the admin or can be setup periodically to happen.

>> 3.1.1) Potential flows:
>>
>> Mgmt ->  vdsm ->  lsm: create LUN + LUN Mapping / Zoning / whatever is
>> needed to make LUN available to list of hosts passed by mgmt
>> Mgmt ->  vdsm: getDeviceList (refreshes host and gets list of devices)
>>    Repeat above for all relevant hosts (depending on list passed
>>    earlier,
>> mostly relevant when extending an existing VG)
>> Mgmt ->  use LUN in normal flows.
> [SM] This is all a bit vague in my opinion, concrete cases might prove more beneficial.

Can you provide your point of view here ?

>>
>> 3.1.2) How oVirt Engine will know which LSM to use ?
>>
>> Normally the way this works today is that user can choose the host to
>> use (default today is SPM), however there are a few flows where mgmt
>> will know which host to use:
>> 1. extend storage domain (add LUN to existing VG) - Use SPM and make
>> sure *all* hosts that need access to this SD can see the new LUN
>> 2. attach new LUN to a VM which is pinned to a specific host - use
>> this host
>> 3. attach new LUN to a VM which is not pinned - use a host from the
>> cluster the VM belongs to and make sure all nodes in cluster can see
>> the
>> new LUN
>>
>> Flows for which there is no clear candidate (Maybe we can use the SPM
>> host itself which is the default ?)
>> 1. create a new disk without attaching it to any VM
>> 2. create a LUN for a new storage domain
> [SM] Maybe the engine should do the work? What about permission? Will all hosts have the credentials to mess with the storage? Will they be passed on a per call basis to prevent other users from having access to the storage?

VDSM will get the creds via the engine or from the domain metadata, 
whatever is chosen as the right way. Once it has the creds, what perm 
issues do you see ? VDSM just uses the creds to talk with the 
libstoragemgmt.

>>
>> 3.2) Consuming storage using LSM
>>
>> Typically this will be done by a virtualization administrator
>>
>> oVirt/VDSM should allow virtualization admin to
>>       - Create a new storage domain using the storage on the array.
>>       - Be able to specify whether VDSM should use the storage offload
>> capability (default) or override it to use its own internal logic.
>>
>> 4) VDSM potential changes:
>>
>> 4.1) How to represent a VM disk, 1 LUN = 1 VMdisk or 1 LV = 1 VMdisk
> I find this hard to understand. Maybe a different notation?

Like what ?

> In ant case there is an abstracted case ie. storage domain. And there is a direct case ie. user provision luns to be used by VDSM and others as well.
> The will both have different ways of representing the same underlying objects.

Do you see the storage repository engine fitting the bill here ? Does 
implementing a storage repo engine for each of the above case make sense 
here ?

> Also, I think that credentials might be tricky to represent as different arrays use different schemes to allocated users\hosts to luns\targets.

Maybe Tony (from libstoragemgmt) can provide more insight here on how 
the creds can be passed to cover different scenarios. I am not very 
aware on the diff. types of schemes possible.

>> ?
>> which bring another question...1 array == 1 storage domain OR 1
>> LUN/nfs-export on the array == 1 storage domain ?
>>
>> Pros&  Cons of each...
>>
>> 1 array == 1 storage domain
>>       - Each new vmdisk (aka volume) will be a new lun/file on the
>>       array.
>>       - Easier to exploit offload capabilities, as they are available
>>       at
>> the LUN/File granularity
>>       - Will there be any issues where there will be too many
>>       LUNs/Files
>> ... any maxluns limit on linux hosts that we might hit ?
>>           -- VDSM has been tested with 1K LUNs and it worked fine -
>>           ayal
>>       - Storage array limitations on the number of LUNs can be a
>>       downside
>> here.
>>       - Would it be ok to share the array for hosting another storage
>> domain if need be ?
>>           -- Provided the existing domain is not utilising all of the
>> free space
>>           -- We can create new LUNs and hand it over to anyone needed
>>           ?
>>       -- Changes needed in VDSM to work with raw LUNs, today it only
>>       has
>> support for consuming LUNs via VG/LV.
>>
>> 1 LUN/nfs-export on the array == 1 storage domain
>>       - How to represent a new vmdisk (aka vdsm volume) if its a LUN
>> provisioned using SAN target ?
>>           -- Will it be VG/LV as is done today for block domains ?
>>           -- If yes, then it will be difficult to exploit offload
>> capabilities, as they are at LUN level, not at LV level.
>>       - Each new vmdisk will be a new file on the nfs-export, assuming
>> offload capability is available at the file level, so this should
>> work
>> for NAS targets ?
>>       - Can use the storage array for hosting multiple storage
>>       domains.
>>           -- Provision one more LUN and use it for another storage
>>           domain
>> if need be.
>>       - VDSM already supports this today, as part of block storage
>> domains for LUNs case.
>>
>> Note that we will allow user to do either one of the two options
>> above,
>> depending on need.
>>
>> 4.2) Storage domain metadata will also include the
>> features/capabilities
>> of the storage array as reported by LSM.
>>           - Capabilities (taken via LSM) will be stored in the domain
>> metadata during storage domain create flow.
>>           - Need changes in oVirt engine as well ( see 'oVirt Engine
>> potential changes' section below )
>>
>> 4.3) VDSM to poll LSM for array capabilities on a regular basis ?
>> Per ayal:
>>       - If we have a 'storage array' entity in oVirt Engine (see
>>       'oVirt
>> Engine potential changes' section below ) then we can have a 'refresh
>> capabilities' button/verb.
>>       - We can periodically query the storage array.
>>       - Query LSM before running operations (sounds redundant to me,
>>       but
>> if it's cheap enough it could be simplest).
>>
>>       Probably need a combination of 1+2 (query at very low frequency
>>       -
>> 1/hour or 1/day + refresh button)
>>
>>
>> 5) oVirt Engine potential changes - as described by ayal :
>>
>>       - We will either need a new 'storage array' entity in engine to
>> keep credentials, or, in case of storage array as storage domain,
>> just
>> keep this info as part of the domain at engine level.
>>       - Have a 'storage array' entity in oVirt Engine to support
>> 'refresh capabilities' as a button/verb.
>>       - When user during storage provisioning, selects a LUN exported
>> from a storage array (via LSM), the oVirt Engine would know from then
>> onwards that this LUN is being served via LSM.
>>         It would then  be able to query the  capabilities of the LUN
>>         and
>> show it to the virt admin during storage consumption flow.
>>
>> 6) Potential flows:
>>       - Create snapshot flow
>>           -- VDSM will check the snapshot offload capability in the
>> domain metadata
>>           -- If available, and override is not configured, it will use
>> LSM to offload LUN/File snapshot
>>           -- If override is configured or capability is not available,
>>           it
>> will use its internal logic to create
>>              snapshot (qcow2).
>>
>>       - Copy/Clone vmdisk flow
>>           -- VDSM will check the copy offload capability in the domain
>> metadata
>>           -- If available, and override is not configured, it will use
>> LSM to offload LUN/File copy
>>           -- If override is configured or capability is not available,
>>           it
>> will use its internal logic to create
>>              snapshot (eg: dd cmd in case of LUN).
>>
>> 7) LSM potential changes:
>>
>>       - list features/capabilities of the array. Eg: copy offload,
>>       thin
>> prov. etc.
>>       - list containers (aka pools) (present in LSM today)
>>       - Ability to list different types of arrays being managed, their
>> capabilities and used/free space
>>       - Ability to create/list/delete/resize volumes ( LUN or exports,
>> available in LSM as of today)
>>       - Get monitoring info with object (LUN/snapshot/volume) as
>>       optional
>> parameter for specific info. eg: container/pool free/used space, raid
>> type etc.
>>
>> Need to make sure above info is listed in a coherent way across
>> arrays
>> (number of LUNs, raid type used? free/total per container/pool, per
>> LUN?. Also need I/O statistics wherever possible.
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
>



From shuming at linux.vnet.ibm.com  Mon Jun 25 14:57:06 2012
From: shuming at linux.vnet.ibm.com (Shu Ming)
Date: Mon, 25 Jun 2012 22:57:06 +0800
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FE87230.4090500@linux.vnet.ibm.com>
References: <3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
	<4FE7CA42.9050703@linux.vnet.ibm.com>
	<4FE87230.4090500@linux.vnet.ibm.com>
Message-ID: <4FE87C42.50404@linux.vnet.ibm.com>

On 2012-6-25 22:14, Deepak C Shetty wrote:
> On 06/25/2012 07:47 AM, Shu Ming wrote:
>> On 2012-6-25 10:10, Andrew Cathrow wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Andy Grover" <agrover at redhat.com>
>>>> To: "Shu Ming" <shuming at linux.vnet.ibm.com>
>>>> Cc: libstoragemgmt-devel at lists.sourceforge.net, 
>>>> engine-devel at ovirt.org, "VDSM Project Development"
>>>> <vdsm-devel at lists.fedorahosted.org>
>>>> Sent: Sunday, June 24, 2012 10:05:45 PM
>>>> Subject: Re: [vdsm] [Engine-devel] RFC: Writeup on 
>>>> VDSM-libstoragemgmt    integration
>>>>
>>>> On 06/24/2012 07:28 AM, Shu Ming wrote:
>>>>> On 2012-6-23 20:40, Itamar Heim wrote:
>>>>>> On 06/23/2012 03:09 AM, Andy Grover wrote:
>>>>>>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
>>>>>>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
>>>>>>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>>>>>>>>> Also, there is no mention on credentials in any part of the
>>>>>>>>>> process.
>>>>>>>>>> How does VDSM or the host get access to actually modify the
>>>>>>>>>> storage
>>>>>>>>>> array? Who holds the creds for that and how? How does the user
>>>>>>>>>> set
>>>>>>>>>> this up?
>>>>>>>>> It seems to me more natural to have the oVirt-engine use
>>>>>>>>> libstoragemgmt
>>>>>>>>> directly to allocate and export a volume on the storage array,
>>>>>>>>> and
>>>>>>>>> then
>>>>>>>>> pass this info to the vdsm on the node creating the vm. This
>>>>>>>>> answers
>>>>>>>>> Saggi's question about creds -- vdsm never needs array
>>>>>>>>> modification
>>>>>>>>> creds, it only gets handed the params needed to connect and use
>>>>>>>>> the
>>>>>>>>> new
>>>>>>>>> block device (ip, iqn, chap, lun).
>>>>>>>>>
>>>>>>>>> Is this usage model made difficult or impossible by the current
>>>>>>>>> software
>>>>>>>>> architecture?
>>>>>>>> what about live snapshots?
>>>>>>> I'm not a virt guy, so extreme handwaving:
>>>>>>>
>>>>>>> vm X uses luns 1&  2
>>>>>>>
>>>>>>> engine ->  vdsm "pause vm X"
>>>>>> that's pausing the VM. live snapshot isn't supposed to do so.
>>>>> Tough we don't expect to do a pausing operation to the VM when live
>>>>> snaphot is undergoing, the VM should be blocked on the access to
>>>>> specific luns for a while.  The blocking time should be very short
>>>>> to
>>>>> avoid the storage IO time out in the VM.
>>>> OK my mistake, we don't pause the VM during live snapshot, we block
>>>> on
>>>> access to the luns while snapshotting. Does this keep live snapshots
>>>> working and mean ovirt-engine can use libsm to config the storage
>>>> array
>>>> instead of vdsm?
>>>>
>>>> Because that was really my main question, should we be talking about
>>>> engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
>>>> integration.
>>> for snapshotting wouldn't we want VDSM to handle the coordination of 
>>> the various atomic functions?
>>
>> I think VDSM-libstoragemgmt will let the storage array itself to make 
>> the snapshot and handle the coordination of the various atomic 
>> functions. VDSM should be blocked on the following access to the 
>> specific luns which are under snapshotting.
>
> I kind of agree. If snapshot is being done at the array level, then 
> the array takes care of quiesing the I/O, taking the snapshot and 
> allowing the I/O, why does VDSM have to worry about anything here, it 
> should all happen transparently for VDSM, isnt it ?
The only issue is the quiesing may time out the VDSM io functions if it 
takes a non-trivial time.  Not sure if VDSM can handle all the time out 
gracefully.



-- 
Shu Ming <shuming at linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory




From ryanh at us.ibm.com  Mon Jun 25 14:58:36 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Mon, 25 Jun 2012 09:58:36 -0500
Subject: [Engine-devel] [vdsm] RFC: Writeup on	VDSM-libstoragemgmt
 integration
In-Reply-To: <3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
References: <4FE7C779.4040807@redhat.com>
	<3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
Message-ID: <20120625145836.GB8043@frylock.austin.ibm.com>

* Andrew Cathrow <acathrow at redhat.com> [2012-06-24 21:11]:
> 
> 
> ----- Original Message -----
> > From: "Andy Grover" <agrover at redhat.com>
> > To: "Shu Ming" <shuming at linux.vnet.ibm.com>
> > Cc: libstoragemgmt-devel at lists.sourceforge.net, engine-devel at ovirt.org, "VDSM Project Development"
> > <vdsm-devel at lists.fedorahosted.org>
> > Sent: Sunday, June 24, 2012 10:05:45 PM
> > Subject: Re: [vdsm] [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt	integration
> > 
> > On 06/24/2012 07:28 AM, Shu Ming wrote:
> > > On 2012-6-23 20:40, Itamar Heim wrote:
> > >> On 06/23/2012 03:09 AM, Andy Grover wrote:
> > >>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
> > >>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
> > >>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
> > >>>>>> Also, there is no mention on credentials in any part of the
> > >>>>>> process.
> > >>>>>> How does VDSM or the host get access to actually modify the
> > >>>>>> storage
> > >>>>>> array? Who holds the creds for that and how? How does the user
> > >>>>>> set
> > >>>>>> this up?
> > >>>>>
> > >>>>> It seems to me more natural to have the oVirt-engine use
> > >>>>> libstoragemgmt
> > >>>>> directly to allocate and export a volume on the storage array,
> > >>>>> and
> > >>>>> then
> > >>>>> pass this info to the vdsm on the node creating the vm. This
> > >>>>> answers
> > >>>>> Saggi's question about creds -- vdsm never needs array
> > >>>>> modification
> > >>>>> creds, it only gets handed the params needed to connect and use
> > >>>>> the
> > >>>>> new
> > >>>>> block device (ip, iqn, chap, lun).
> > >>>>>
> > >>>>> Is this usage model made difficult or impossible by the current
> > >>>>> software
> > >>>>> architecture?
> > >>>>
> > >>>> what about live snapshots?
> > >>>
> > >>> I'm not a virt guy, so extreme handwaving:
> > >>>
> > >>> vm X uses luns 1&  2
> > >>>
> > >>> engine ->  vdsm "pause vm X"
> > >>
> > >> that's pausing the VM. live snapshot isn't supposed to do so.
> > > 
> > > Tough we don't expect to do a pausing operation to the VM when live
> > > snaphot is undergoing, the VM should be blocked on the access to
> > > specific luns for a while.  The blocking time should be very short
> > > to
> > > avoid the storage IO time out in the VM.
> > 
> > OK my mistake, we don't pause the VM during live snapshot, we block
> > on
> > access to the luns while snapshotting. Does this keep live snapshots
> > working and mean ovirt-engine can use libsm to config the storage
> > array
> > instead of vdsm?
> > 
> > Because that was really my main question, should we be talking about
> > engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
> > integration.
> 
> for snapshotting wouldn't we want VDSM to handle the coordination of
> the various atomic functions?

Absolutely.  Requiring every management application (engine, etc) to
integrate with libstoragemanagement is a win here.  We want to simplify
working with KVM, storage, etc not require every mgmt application to
know deep details about how to create a live VM snapshot.


> > 
> > Thanks -- Regards -- Andy
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/vdsm-devel
> > 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com



From djasa at redhat.com  Mon Jun 25 15:06:25 2012
From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=)
Date: Mon, 25 Jun 2012 17:06:25 +0200
Subject: [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt integration
In-Reply-To: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>
References: <65cba00e-8780-46da-bcdc-47d3f9960182@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <1340636785.20077.126.camel@dhcp-29-7.brq.redhat.com>

Saggi Mizrahi p??e v Po 18. 06. 2012 v 16:15 -0400:
> First of all I'd like to suggest not using the LSM acronym as it can
> also mean live-storage-migration and maybe other things.

Linux Security Modules (base of SELinux and AppArmor) comes to my mind
every time I see the acronym.

David

-- 

David Ja?a, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24





From tasleson at redhat.com  Mon Jun 25 15:08:22 2012
From: tasleson at redhat.com (Tony Asleson)
Date: Mon, 25 Jun 2012 10:08:22 -0500
Subject: [Engine-devel] [Libstoragemgmt-devel] [vdsm] RFC: Writeup on
 VDSM-libstoragemgmt integration
In-Reply-To: <4FE87230.4090500@linux.vnet.ibm.com>
References: <3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
	<4FE7CA42.9050703@linux.vnet.ibm.com>
	<4FE87230.4090500@linux.vnet.ibm.com>
Message-ID: <4FE87EE6.7060200@redhat.com>

On 06/25/2012 09:14 AM, Deepak C Shetty wrote:
> On 06/25/2012 07:47 AM, Shu Ming wrote:

>> I think VDSM-libstoragemgmt will let the storage array itself to make 
>> the snapshot and handle the coordination of the various atomic 
>> functions. VDSM should be blocked on the following access to the 
>> specific luns which are under snapshotting.
> 
> I kind of agree. If snapshot is being done at the array level, then the 
> array takes care of quiesing the I/O, taking the snapshot and allowing 
> the I/O, why does VDSM have to worry about anything here, it should all 
> happen transparently for VDSM, isnt it ?

The array can take a snapshot in flight, but the data may be in an
inconsistent state.  Only the end application/user of the storage knows
when a point in time is consistent.  Typically the application(s) are
quiesced, the OS buffers flushed (outstanding tagged IO is allowed to
complete) and then the storage is told to make a point in time copy.
This is the only way to be sure of what you have on disk is coherent.

A transactional database (two-phase commit) and logging file systems
(meta data) are specifically written to handle these inconsistencies,
but many applications are not.

Regards,
Tony



From deepakcs at linux.vnet.ibm.com  Mon Jun 25 15:13:28 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Mon, 25 Jun 2012 20:43:28 +0530
Subject: [Engine-devel] [vdsm] RFC: Writeup on	VDSM-libstoragemgmt
	integration
In-Reply-To: <20120625145836.GB8043@frylock.austin.ibm.com>
References: <4FE7C779.4040807@redhat.com>
	<3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
	<20120625145836.GB8043@frylock.austin.ibm.com>
Message-ID: <4FE88018.2080900@linux.vnet.ibm.com>

On 06/25/2012 08:28 PM, Ryan Harper wrote:
> * Andrew Cathrow<acathrow at redhat.com>  [2012-06-24 21:11]:
>>
>> ----- Original Message -----
>>> From: "Andy Grover"<agrover at redhat.com>
>>> To: "Shu Ming"<shuming at linux.vnet.ibm.com>
>>> Cc: libstoragemgmt-devel at lists.sourceforge.net, engine-devel at ovirt.org, "VDSM Project Development"
>>> <vdsm-devel at lists.fedorahosted.org>
>>> Sent: Sunday, June 24, 2012 10:05:45 PM
>>> Subject: Re: [vdsm] [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt	integration
>>>
>>> On 06/24/2012 07:28 AM, Shu Ming wrote:
>>>> On 2012-6-23 20:40, Itamar Heim wrote:
>>>>> On 06/23/2012 03:09 AM, Andy Grover wrote:
>>>>>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
>>>>>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
>>>>>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>>>>>>>> Also, there is no mention on credentials in any part of the
>>>>>>>>> process.
>>>>>>>>> How does VDSM or the host get access to actually modify the
>>>>>>>>> storage
>>>>>>>>> array? Who holds the creds for that and how? How does the user
>>>>>>>>> set
>>>>>>>>> this up?
>>>>>>>> It seems to me more natural to have the oVirt-engine use
>>>>>>>> libstoragemgmt
>>>>>>>> directly to allocate and export a volume on the storage array,
>>>>>>>> and
>>>>>>>> then
>>>>>>>> pass this info to the vdsm on the node creating the vm. This
>>>>>>>> answers
>>>>>>>> Saggi's question about creds -- vdsm never needs array
>>>>>>>> modification
>>>>>>>> creds, it only gets handed the params needed to connect and use
>>>>>>>> the
>>>>>>>> new
>>>>>>>> block device (ip, iqn, chap, lun).
>>>>>>>>
>>>>>>>> Is this usage model made difficult or impossible by the current
>>>>>>>> software
>>>>>>>> architecture?
>>>>>>> what about live snapshots?
>>>>>> I'm not a virt guy, so extreme handwaving:
>>>>>>
>>>>>> vm X uses luns 1&   2
>>>>>>
>>>>>> engine ->   vdsm "pause vm X"
>>>>> that's pausing the VM. live snapshot isn't supposed to do so.
>>>> Tough we don't expect to do a pausing operation to the VM when live
>>>> snaphot is undergoing, the VM should be blocked on the access to
>>>> specific luns for a while.  The blocking time should be very short
>>>> to
>>>> avoid the storage IO time out in the VM.
>>> OK my mistake, we don't pause the VM during live snapshot, we block
>>> on
>>> access to the luns while snapshotting. Does this keep live snapshots
>>> working and mean ovirt-engine can use libsm to config the storage
>>> array
>>> instead of vdsm?
>>>
>>> Because that was really my main question, should we be talking about
>>> engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
>>> integration.
>> for snapshotting wouldn't we want VDSM to handle the coordination of
>> the various atomic functions?
> Absolutely.  Requiring every management application (engine, etc) to
> integrate with libstoragemanagement is a win here.  We want to simplify
> working with KVM, storage, etc not require every mgmt application to
> know deep details about how to create a live VM snapshot.
>

Sorry, but not clear to me. Are you saying engine-libstoragemgmt 
integration is a win here ?
VDSM is the common factor here.. so integrating libstoragemgmt with VDSM 
helps anybody talkign with VDSM in future AFAIU.



From vszocs at redhat.com  Mon Jun 25 15:14:53 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 25 Jun 2012 11:14:53 -0400 (EDT)
Subject: [Engine-devel] GWT 2.4.0 and the oVirt Engine
In-Reply-To: <a2e1e931-9cdb-413c-b1cb-f540617aa5d8@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <374628a9-d0fd-428a-b75d-77d0ec597e05@zmail16.collab.prod.int.phx2.redhat.com>

Hi everyone,

there are patches available for basic UI migration steps described in my previous email:

Move to GWT 2.4  : http://gerrit.ovirt.org/5613
Move to GWTP 0.7 : http://gerrit.ovirt.org/5684

Let me know if you have any questions.

Vojtech


----- Original Message -----
From: "Vojtech Szocs" <vszocs at redhat.com>
To: engine-devel at ovirt.org
Sent: Tuesday, June 19, 2012 4:40:28 PM
Subject: Re: [Engine-devel] GWT 2.4.0 and the oVirt Engine



Hi Dustin, 

here are the basic steps for migrating oVirt web applications to GWT 2.4 and GWTP 0.7: 

1. update gwt.version property value to 2.4.0 in following POM files: 

    ? frontend/webadmin/modules/ gwt-common /pom.xml 
    ? frontend/webadmin/modules/ gwt-extension /pom.xml 
    ? frontend/webadmin/modules/ userportal-gwtp /pom.xml 
    ? frontend/webadmin/modules/ webadmin /pom.xml 



Note: oVirt root POM still defines gwt.version with value 2.2.0 , which is effectively inherited by frontend and uicompat modules (located at frontend/webadmin/modules ). This shouldn't be an issue, however, we should consolidate GWT version definition later on. 






2. update gwtp.version property value to 0.7 in frontend/webadmin/modules/pom.xml 




3. follow GWTP 0.7 migration steps , which will most likely involve UI code changes 




For all steps mentioned above, I'm planning to make a patch, since step (3) requires deeper knowledge of GWTP/WebAdmin code. 







In addition, here are the extra steps to finalize the migration (these items are relevant long-term, can be skipped for now): 




4. remove HTML5 drag'n'drop classes (originally copied from GWT 2.4 trunk) by removing following WebAdmin packages: 

    ? com.google.gwt.dom.client 
    ? com.google.gwt.event.dom.client 



5. adjust UI code regarding GWT Editor framework, which is now capable of handling primitive boolean is/has getter methods 




Vojtech 











From: "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com> 
To: engine-devel at ovirt.org 
Sent: Tuesday, June 19, 2012 3:24:15 PM 
Subject: [Engine-devel] GWT 2.4.0 and the oVirt Engine 




Hey All, 


I was looking at doing some work with extending the oVirt Engine GUI but some of the functionality that I need (such as dynamic creation of tabs) is only supported in GWT 2.4.0. What sort of steps would have to be taken to update the Engine to GWT 2.4.0? Also, what would be the easiest way of debugging and testing these updates through Eclipse, for example. Thanks in advance! 




-- Dustin 


_______________________________________________ 
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 deepakcs at linux.vnet.ibm.com  Mon Jun 25 15:23:27 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Mon, 25 Jun 2012 20:53:27 +0530
Subject: [Engine-devel] [Libstoragemgmt-devel] [vdsm] RFC: Writeup on
 VDSM-libstoragemgmt integration
In-Reply-To: <4FE87EE6.7060200@redhat.com>
References: <3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
	<4FE7CA42.9050703@linux.vnet.ibm.com>
	<4FE87230.4090500@linux.vnet.ibm.com> <4FE87EE6.7060200@redhat.com>
Message-ID: <4FE8826F.3070801@linux.vnet.ibm.com>

On 06/25/2012 08:38 PM, Tony Asleson wrote:
> On 06/25/2012 09:14 AM, Deepak C Shetty wrote:
>> On 06/25/2012 07:47 AM, Shu Ming wrote:
>>> I think VDSM-libstoragemgmt will let the storage array itself to make
>>> the snapshot and handle the coordination of the various atomic
>>> functions. VDSM should be blocked on the following access to the
>>> specific luns which are under snapshotting.
>> I kind of agree. If snapshot is being done at the array level, then the
>> array takes care of quiesing the I/O, taking the snapshot and allowing
>> the I/O, why does VDSM have to worry about anything here, it should all
>> happen transparently for VDSM, isnt it ?
> The array can take a snapshot in flight, but the data may be in an
> inconsistent state.  Only the end application/user of the storage knows
> when a point in time is consistent.  Typically the application(s) are
> quiesced, the OS buffers flushed (outstanding tagged IO is allowed to
> complete) and then the storage is told to make a point in time copy.
> This is the only way to be sure of what you have on disk is coherent.
>
> A transactional database (two-phase commit) and logging file systems
> (meta data) are specifically written to handle these inconsistencies,
> but many applications are not.
>

Thanks for clarifying Tony. So that means we need to do whatever from 
VDSM to quiese the I/O
and then VDSM should instruct the array to take the snapshot.



From ryanh at us.ibm.com  Mon Jun 25 15:17:10 2012
From: ryanh at us.ibm.com (Ryan Harper)
Date: Mon, 25 Jun 2012 10:17:10 -0500
Subject: [Engine-devel] [vdsm] RFC: Writeup on	VDSM-libstoragemgmt
 integration
In-Reply-To: <4FE88018.2080900@linux.vnet.ibm.com>
References: <4FE7C779.4040807@redhat.com>
	<3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
	<20120625145836.GB8043@frylock.austin.ibm.com>
	<4FE88018.2080900@linux.vnet.ibm.com>
Message-ID: <20120625151710.GC8043@frylock.austin.ibm.com>

* Deepak C Shetty <deepakcs at linux.vnet.ibm.com> [2012-06-25 10:14]:
> On 06/25/2012 08:28 PM, Ryan Harper wrote:
> >* Andrew Cathrow<acathrow at redhat.com>  [2012-06-24 21:11]:
> >>
> >>----- Original Message -----
> >>>From: "Andy Grover"<agrover at redhat.com>
> >>>To: "Shu Ming"<shuming at linux.vnet.ibm.com>
> >>>Cc: libstoragemgmt-devel at lists.sourceforge.net, engine-devel at ovirt.org, "VDSM Project Development"
> >>><vdsm-devel at lists.fedorahosted.org>
> >>>Sent: Sunday, June 24, 2012 10:05:45 PM
> >>>Subject: Re: [vdsm] [Engine-devel] RFC: Writeup on VDSM-libstoragemgmt	integration
> >>>
> >>>On 06/24/2012 07:28 AM, Shu Ming wrote:
> >>>>On 2012-6-23 20:40, Itamar Heim wrote:
> >>>>>On 06/23/2012 03:09 AM, Andy Grover wrote:
> >>>>>>On 06/22/2012 04:46 PM, Itamar Heim wrote:
> >>>>>>>On 06/23/2012 02:31 AM, Andy Grover wrote:
> >>>>>>>>On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
> >>>>>>>>>Also, there is no mention on credentials in any part of the
> >>>>>>>>>process.
> >>>>>>>>>How does VDSM or the host get access to actually modify the
> >>>>>>>>>storage
> >>>>>>>>>array? Who holds the creds for that and how? How does the user
> >>>>>>>>>set
> >>>>>>>>>this up?
> >>>>>>>>It seems to me more natural to have the oVirt-engine use
> >>>>>>>>libstoragemgmt
> >>>>>>>>directly to allocate and export a volume on the storage array,
> >>>>>>>>and
> >>>>>>>>then
> >>>>>>>>pass this info to the vdsm on the node creating the vm. This
> >>>>>>>>answers
> >>>>>>>>Saggi's question about creds -- vdsm never needs array
> >>>>>>>>modification
> >>>>>>>>creds, it only gets handed the params needed to connect and use
> >>>>>>>>the
> >>>>>>>>new
> >>>>>>>>block device (ip, iqn, chap, lun).
> >>>>>>>>
> >>>>>>>>Is this usage model made difficult or impossible by the current
> >>>>>>>>software
> >>>>>>>>architecture?
> >>>>>>>what about live snapshots?
> >>>>>>I'm not a virt guy, so extreme handwaving:
> >>>>>>
> >>>>>>vm X uses luns 1&   2
> >>>>>>
> >>>>>>engine ->   vdsm "pause vm X"
> >>>>>that's pausing the VM. live snapshot isn't supposed to do so.
> >>>>Tough we don't expect to do a pausing operation to the VM when live
> >>>>snaphot is undergoing, the VM should be blocked on the access to
> >>>>specific luns for a while.  The blocking time should be very short
> >>>>to
> >>>>avoid the storage IO time out in the VM.
> >>>OK my mistake, we don't pause the VM during live snapshot, we block
> >>>on
> >>>access to the luns while snapshotting. Does this keep live snapshots
> >>>working and mean ovirt-engine can use libsm to config the storage
> >>>array
> >>>instead of vdsm?
> >>>
> >>>Because that was really my main question, should we be talking about
> >>>engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
> >>>integration.
> >>for snapshotting wouldn't we want VDSM to handle the coordination of
> >>the various atomic functions?
> >Absolutely.  Requiring every management application (engine, etc) to
> >integrate with libstoragemanagement is a win here.  We want to simplify
> >working with KVM, storage, etc not require every mgmt application to
> >know deep details about how to create a live VM snapshot.
> >
> 
> Sorry, but not clear to me. Are you saying engine-libstoragemgmt
> integration is a win here ?

Sorry if I wasn't clear.  To answer your question: No. 

The mgmt app should *NOT* have to learn all of the ins and outs of the
end-point storage and the management of it.

> VDSM is the common factor here.. so integrating libstoragemgmt with
> VDSM helps anybody talkign with VDSM in future AFAIU.

Yes.  100% agree.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com



From vszocs at redhat.com  Mon Jun 25 17:11:41 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Mon, 25 Jun 2012 13:11:41 -0400 (EDT)
Subject: [Engine-devel] oVirt UI Plugins feature: Ready for review
In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A4801205546@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <fbd00d07-45c7-418f-a9a6-428484c657b8@zmail16.collab.prod.int.phx2.redhat.com>

Hi George,

thanks for your feedback. Please find my answers below.


> 1) Are the plugins hosted by the same jboss server that hosts the engine?  It would appear the answer is yes and that no separate container is required for the plugins.

In short, yes.

Plugins, along with their configuration and 3rd party dependencies, are meant to be embedded into final WebAdmin HTML page, see [http://www.ovirt.org/wiki/Features/UIPlugins#Plugin_lifecycle] step #5. 
JBoss AS instance serves WebAdmin HTML page (WebadminDynamicHostingServlet), along with providing GWT RPC and REST endpoints that delegate to Engine business logic through EJB BackendLocal interface.

However, plugins are not 'hosted' in a typical sense - WebadminDynamicHostingServlet reads and embeds all plugin data directly into final WebAdmin HTML page.


> 2) Does each plugin map to a unique extension within WebAdmin?  Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension.  This is named pluginApi.plugins.myPlugin.  Can I safely assume that this is per extension?  I would have pluginApi.plugins.myPlugin2 for extending a storage domain?

Extension points are represented by application events, triggered by WebAdmin and consumed by plugins. For example, 'tableContextMenu' event gets triggered when a table context menu is about to be shown to the user, which gives plugins the ability to do something custom with the context menu before it's shown.

There can be multiple plugins handling the same event (extension point). You can have two plugins, say 'pluginApi.plugins.One' and 'pluginApi.plugins.Two', each providing 'tableContextMenu' function for handling the above mentioned event. WebAdmin will invoke all plugins for the given event.

To answer your question, in order to handle X events (extension points), you don't need to write X plugins. You can write one plugin that handles X events.


> 3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs?

You can do anything you want in your plugin event handler function. Show a jQuery UI dialog, make oVirt REST API request, call arbitrary remote server using cross-domain technique like JSONP [1] or CORS [2], etc. Plugin authors are free to decide if they want to rely on 3rd party JavaScript libraries, or if they want to write entire plugin code by themselves.

In my opinion, tools like jQuery are far more elegant for handling simple things such as UI dialogs. But if you really want to use GWT for this purpose, I suggest following approach:

a, develop a 'plugin support application' in GWT, which implements the necessary dialog functionality
b, export its main (e.g. dialog handling) classes for use in native JavaScript through gwt-exporter [3]
c, have your oVirt UI plugin depend on your compiled 'plugin support application' (this will cause your 'plugin support application' to be called during WebAdmin startup)
d, in your oVirt UI plugin, invoke 'plugin support application' functionality through exported classes (plugin -> GWT delegate pattern)


> 4) Is session info passed into the plugin so that I can invoke APIs into the engine?  To power on a VM for instance?  Or to mount a new NFS storage domain?

Yes, this should be part of [http://www.ovirt.org/wiki/Features/UIPlugins#Global_API_functions] "Plugin utility functions" (global API).

Your plugin might access user session information in the following way: pluginApi.util().userInfo().* (replace * with id(), name(), domain(), etc.)

As you pointed out, this could be used to authenticate oVirt REST API requests made from your plugin code.


> BTW, the link to the original design notes on the wiki doesn't work.

This is strange, [http://rhevmf.pad.engineering.redhat.com/68] has its visibility set to "Public (Allow Internet guests)" ... Does anybody know why this doesn't work?


Vojtech


[1] http://en.wikipedia.org/wiki/JSONP
[2] http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
[3] http://code.google.com/p/gwt-exporter/


----- Original Message -----
From: "George Costea" <George.Costea at netapp.com>
To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org
Cc: "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com>, "Ricky Hopper" <Ricky.Hopper at netapp.com>
Sent: Monday, June 25, 2012 3:09:43 PM
Subject: RE: oVirt UI Plugins feature: Ready for review

Hi Vojtech,

I have a few questions on this feature.

1) Are the plugins hosted by the same jboss server that hosts the engine?  It would appear the answer is yes and that no separate container is required for the plugins.
2) Does each plugin map to a unique extension within WebAdmin?  Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension.  This is named pluginApi.plugins.myPlugin.  Can I safely assume that this is per extension?  I would have pluginApi.plugins.myPlugin2 for extending a storage domain?
3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs?
4) Is session info passed into the plugin so that I can invoke APIs into the engine?  To power on a VM for instance?  Or to mount a new NFS storage domain?

BTW, the link to the original design notes on the wiki doesn't work.

Thanks,
George

-----Original Message-----
From: Vojtech Szocs [mailto:vszocs at redhat.com] 
Sent: Thursday, June 21, 2012 11:03 AM
To: engine-devel at ovirt.org
Cc: Schoenbrun, Dustin; Costea, George; Hopper, Ricky
Subject: oVirt UI Plugins feature: Ready for review

Hi guys,

I wrote a wiki page describing UI Plugins, a feature planned for oVirt web administration (WebAdmin) application:
http://www.ovirt.org/wiki/Features/UIPlugins

Feature design is finished and ready for review. Please feel free to add comments, ask questions or reach me directly on #ovirt channel.

Cheers,
Vojtech


From agrover at redhat.com  Mon Jun 25 17:15:43 2012
From: agrover at redhat.com (Andy Grover)
Date: Mon, 25 Jun 2012 10:15:43 -0700
Subject: [Engine-devel] [vdsm] RFC: Writeup on	VDSM-libstoragemgmt
	integration
In-Reply-To: <20120625151710.GC8043@frylock.austin.ibm.com>
References: <4FE7C779.4040807@redhat.com>
	<3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
	<20120625145836.GB8043@frylock.austin.ibm.com>
	<4FE88018.2080900@linux.vnet.ibm.com>
	<20120625151710.GC8043@frylock.austin.ibm.com>
Message-ID: <4FE89CBF.6050808@redhat.com>

On 06/25/2012 08:17 AM, Ryan Harper wrote:
> * Deepak C Shetty <deepakcs at linux.vnet.ibm.com> [2012-06-25 10:14]:
>> On 06/25/2012 08:28 PM, Ryan Harper wrote:
> The mgmt app should *NOT* have to learn all of the ins and outs of the
> end-point storage and the management of it.
> 
>> VDSM is the common factor here.. so integrating libstoragemgmt with
>> VDSM helps anybody talkign with VDSM in future AFAIU.
> 
> Yes.  100% agree.

Thanks, this has helped me understand vdsm's role much better.

-- Andy


From iheim at redhat.com  Mon Jun 25 17:43:55 2012
From: iheim at redhat.com (Itamar Heim)
Date: Mon, 25 Jun 2012 13:43:55 -0400
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FE87230.4090500@linux.vnet.ibm.com>
References: <3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
	<4FE7CA42.9050703@linux.vnet.ibm.com>
	<4FE87230.4090500@linux.vnet.ibm.com>
Message-ID: <4FE8A35B.50807@redhat.com>

On 06/25/2012 10:14 AM, Deepak C Shetty wrote:
> On 06/25/2012 07:47 AM, Shu Ming wrote:
>> On 2012-6-25 10:10, Andrew Cathrow wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Andy Grover" <agrover at redhat.com>
>>>> To: "Shu Ming" <shuming at linux.vnet.ibm.com>
>>>> Cc: libstoragemgmt-devel at lists.sourceforge.net,
>>>> engine-devel at ovirt.org, "VDSM Project Development"
>>>> <vdsm-devel at lists.fedorahosted.org>
>>>> Sent: Sunday, June 24, 2012 10:05:45 PM
>>>> Subject: Re: [vdsm] [Engine-devel] RFC: Writeup on
>>>> VDSM-libstoragemgmt integration
>>>>
>>>> On 06/24/2012 07:28 AM, Shu Ming wrote:
>>>>> On 2012-6-23 20:40, Itamar Heim wrote:
>>>>>> On 06/23/2012 03:09 AM, Andy Grover wrote:
>>>>>>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
>>>>>>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
>>>>>>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>>>>>>>>> Also, there is no mention on credentials in any part of the
>>>>>>>>>> process.
>>>>>>>>>> How does VDSM or the host get access to actually modify the
>>>>>>>>>> storage
>>>>>>>>>> array? Who holds the creds for that and how? How does the user
>>>>>>>>>> set
>>>>>>>>>> this up?
>>>>>>>>> It seems to me more natural to have the oVirt-engine use
>>>>>>>>> libstoragemgmt
>>>>>>>>> directly to allocate and export a volume on the storage array,
>>>>>>>>> and
>>>>>>>>> then
>>>>>>>>> pass this info to the vdsm on the node creating the vm. This
>>>>>>>>> answers
>>>>>>>>> Saggi's question about creds -- vdsm never needs array
>>>>>>>>> modification
>>>>>>>>> creds, it only gets handed the params needed to connect and use
>>>>>>>>> the
>>>>>>>>> new
>>>>>>>>> block device (ip, iqn, chap, lun).
>>>>>>>>>
>>>>>>>>> Is this usage model made difficult or impossible by the current
>>>>>>>>> software
>>>>>>>>> architecture?
>>>>>>>> what about live snapshots?
>>>>>>> I'm not a virt guy, so extreme handwaving:
>>>>>>>
>>>>>>> vm X uses luns 1& 2
>>>>>>>
>>>>>>> engine -> vdsm "pause vm X"
>>>>>> that's pausing the VM. live snapshot isn't supposed to do so.
>>>>> Tough we don't expect to do a pausing operation to the VM when live
>>>>> snaphot is undergoing, the VM should be blocked on the access to
>>>>> specific luns for a while. The blocking time should be very short
>>>>> to
>>>>> avoid the storage IO time out in the VM.
>>>> OK my mistake, we don't pause the VM during live snapshot, we block
>>>> on
>>>> access to the luns while snapshotting. Does this keep live snapshots
>>>> working and mean ovirt-engine can use libsm to config the storage
>>>> array
>>>> instead of vdsm?
>>>>
>>>> Because that was really my main question, should we be talking about
>>>> engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
>>>> integration.
>>> for snapshotting wouldn't we want VDSM to handle the coordination of
>>> the various atomic functions?
>>
>> I think VDSM-libstoragemgmt will let the storage array itself to make
>> the snapshot and handle the coordination of the various atomic
>> functions. VDSM should be blocked on the following access to the
>> specific luns which are under snapshotting.
>
> I kind of agree. If snapshot is being done at the array level, then the
> array takes care of quiesing the I/O, taking the snapshot and allowing
> the I/O, why does VDSM have to worry about anything here, it should all
> happen transparently for VDSM, isnt it ?

I may be misssing something, but afaiu you need to ask the guest to 
perform the quiesce, and i'm sure the storage array can't do that.


From George.Costea at netapp.com  Mon Jun 25 13:09:43 2012
From: George.Costea at netapp.com (Costea, George)
Date: Mon, 25 Jun 2012 13:09:43 +0000
Subject: [Engine-devel] oVirt UI Plugins feature: Ready for review
In-Reply-To: <9841e995-18d9-4993-95d5-4f48a580f946@zmail16.collab.prod.int.phx2.redhat.com>
References: <1962b477-89b3-4568-895f-cc96414453e5@zmail16.collab.prod.int.phx2.redhat.com>
	<9841e995-18d9-4993-95d5-4f48a580f946@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <6C8AC8C50E170C4E9B44D47B39B24A4801205546@SACEXCMBX04-PRD.hq.netapp.com>

Hi Vojtech,

I have a few questions on this feature.

1) Are the plugins hosted by the same jboss server that hosts the engine?  It would appear the answer is yes and that no separate container is required for the plugins.
2) Does each plugin map to a unique extension within WebAdmin?  Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension.  This is named pluginApi.plugins.myPlugin.  Can I safely assume that this is per extension?  I would have pluginApi.plugins.myPlugin2 for extending a storage domain?
3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs?
4) Is session info passed into the plugin so that I can invoke APIs into the engine?  To power on a VM for instance?  Or to mount a new NFS storage domain?

BTW, the link to the original design notes on the wiki doesn't work.

Thanks,
George

-----Original Message-----
From: Vojtech Szocs [mailto:vszocs at redhat.com] 
Sent: Thursday, June 21, 2012 11:03 AM
To: engine-devel at ovirt.org
Cc: Schoenbrun, Dustin; Costea, George; Hopper, Ricky
Subject: oVirt UI Plugins feature: Ready for review

Hi guys,

I wrote a wiki page describing UI Plugins, a feature planned for oVirt web administration (WebAdmin) application:
http://www.ovirt.org/wiki/Features/UIPlugins

Feature design is finished and ready for review. Please feel free to add comments, ask questions or reach me directly on #ovirt channel.

Cheers,
Vojtech

From George.Costea at netapp.com  Mon Jun 25 19:11:33 2012
From: George.Costea at netapp.com (Costea, George)
Date: Mon, 25 Jun 2012 19:11:33 +0000
Subject: [Engine-devel] oVirt UI Plugins feature: Ready for review
In-Reply-To: <fbd00d07-45c7-418f-a9a6-428484c657b8@zmail16.collab.prod.int.phx2.redhat.com>
References: <6C8AC8C50E170C4E9B44D47B39B24A4801205546@SACEXCMBX04-PRD.hq.netapp.com>
	<fbd00d07-45c7-418f-a9a6-428484c657b8@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <6C8AC8C50E170C4E9B44D47B39B24A4801205F4B@SACEXCMBX04-PRD.hq.netapp.com>

Thanks Vojtech.

Since the plugins are embedded into the WebAdmin HTML page, that seems to simplify things; no external web service is needed.  This approach ties into the issue over the freedom to decide which technology to use when developing a plugin.  While I agree that jQuery is best for simple dialogs, a wizard-driven workflow is easier to develop in GWT.  

For example, if I want to step a user through the process of creating a new storage domain I would like to provide a workflow to select a storage array, provide credentials, and configure the details of the NFS export.  This workflow could presumably have a GWT-RPC mechanism that relies on some additional libraries on the backend (libraries that allow me to communicate with the storage array).  Using the GWT-Exporter, I could export the classes that would display the workflow which would then get launched as my extension is selected.  You said that I would have my oVirt UI plugin depend on my compiled 'plugin support application'.  My compiled plugin support application would normally be a war file containing my compiled GWT code and a web-inf folder containing my libraries.  Is the plugin depending on the war file?  Is that what I specify?

-George

-----Original Message-----
From: Vojtech Szocs [mailto:vszocs at redhat.com] 
Sent: Monday, June 25, 2012 1:12 PM
To: Costea, George; engine-devel at ovirt.org
Cc: Schoenbrun, Dustin; Hopper, Ricky; Itamar Heim
Subject: Re: oVirt UI Plugins feature: Ready for review

Hi George,

thanks for your feedback. Please find my answers below.


> 1) Are the plugins hosted by the same jboss server that hosts the engine?  It would appear the answer is yes and that no separate container is required for the plugins.

In short, yes.

Plugins, along with their configuration and 3rd party dependencies, are meant to be embedded into final WebAdmin HTML page, see [http://www.ovirt.org/wiki/Features/UIPlugins#Plugin_lifecycle] step #5. 
JBoss AS instance serves WebAdmin HTML page (WebadminDynamicHostingServlet), along with providing GWT RPC and REST endpoints that delegate to Engine business logic through EJB BackendLocal interface.

However, plugins are not 'hosted' in a typical sense - WebadminDynamicHostingServlet reads and embeds all plugin data directly into final WebAdmin HTML page.


> 2) Does each plugin map to a unique extension within WebAdmin?  Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension.  This is named pluginApi.plugins.myPlugin.  Can I safely assume that this is per extension?  I would have pluginApi.plugins.myPlugin2 for extending a storage domain?

Extension points are represented by application events, triggered by WebAdmin and consumed by plugins. For example, 'tableContextMenu' event gets triggered when a table context menu is about to be shown to the user, which gives plugins the ability to do something custom with the context menu before it's shown.

There can be multiple plugins handling the same event (extension point). You can have two plugins, say 'pluginApi.plugins.One' and 'pluginApi.plugins.Two', each providing 'tableContextMenu' function for handling the above mentioned event. WebAdmin will invoke all plugins for the given event.

To answer your question, in order to handle X events (extension points), you don't need to write X plugins. You can write one plugin that handles X events.


> 3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs?

You can do anything you want in your plugin event handler function. Show a jQuery UI dialog, make oVirt REST API request, call arbitrary remote server using cross-domain technique like JSONP [1] or CORS [2], etc. Plugin authors are free to decide if they want to rely on 3rd party JavaScript libraries, or if they want to write entire plugin code by themselves.

In my opinion, tools like jQuery are far more elegant for handling simple things such as UI dialogs. But if you really want to use GWT for this purpose, I suggest following approach:

a, develop a 'plugin support application' in GWT, which implements the necessary dialog functionality b, export its main (e.g. dialog handling) classes for use in native JavaScript through gwt-exporter [3] c, have your oVirt UI plugin depend on your compiled 'plugin support application' (this will cause your 'plugin support application' to be called during WebAdmin startup) d, in your oVirt UI plugin, invoke 'plugin support application' functionality through exported classes (plugin -> GWT delegate pattern)


> 4) Is session info passed into the plugin so that I can invoke APIs into the engine?  To power on a VM for instance?  Or to mount a new NFS storage domain?

Yes, this should be part of [http://www.ovirt.org/wiki/Features/UIPlugins#Global_API_functions] "Plugin utility functions" (global API).

Your plugin might access user session information in the following way: pluginApi.util().userInfo().* (replace * with id(), name(), domain(), etc.)

As you pointed out, this could be used to authenticate oVirt REST API requests made from your plugin code.


> BTW, the link to the original design notes on the wiki doesn't work.

This is strange, [http://rhevmf.pad.engineering.redhat.com/68] has its visibility set to "Public (Allow Internet guests)" ... Does anybody know why this doesn't work?


Vojtech


[1] http://en.wikipedia.org/wiki/JSONP
[2] http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
[3] http://code.google.com/p/gwt-exporter/


----- Original Message -----
From: "George Costea" <George.Costea at netapp.com>
To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org
Cc: "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com>, "Ricky Hopper" <Ricky.Hopper at netapp.com>
Sent: Monday, June 25, 2012 3:09:43 PM
Subject: RE: oVirt UI Plugins feature: Ready for review

Hi Vojtech,

I have a few questions on this feature.

1) Are the plugins hosted by the same jboss server that hosts the engine?  It would appear the answer is yes and that no separate container is required for the plugins.
2) Does each plugin map to a unique extension within WebAdmin?  Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension.  This is named pluginApi.plugins.myPlugin.  Can I safely assume that this is per extension?  I would have pluginApi.plugins.myPlugin2 for extending a storage domain?
3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs?
4) Is session info passed into the plugin so that I can invoke APIs into the engine?  To power on a VM for instance?  Or to mount a new NFS storage domain?

BTW, the link to the original design notes on the wiki doesn't work.

Thanks,
George

-----Original Message-----
From: Vojtech Szocs [mailto:vszocs at redhat.com]
Sent: Thursday, June 21, 2012 11:03 AM
To: engine-devel at ovirt.org
Cc: Schoenbrun, Dustin; Costea, George; Hopper, Ricky
Subject: oVirt UI Plugins feature: Ready for review

Hi guys,

I wrote a wiki page describing UI Plugins, a feature planned for oVirt web administration (WebAdmin) application:
http://www.ovirt.org/wiki/Features/UIPlugins

Feature design is finished and ready for review. Please feel free to add comments, ask questions or reach me directly on #ovirt channel.

Cheers,
Vojtech

From sgordon at redhat.com  Mon Jun 25 20:05:11 2012
From: sgordon at redhat.com (Steve Gordon)
Date: Mon, 25 Jun 2012 16:05:11 -0400 (EDT)
Subject: [Engine-devel] 3.1 Release Notes
In-Reply-To: <e60bf277-e531-46ef-8e09-bd2c1bff3974@zmail15.collab.prod.int.phx2.redhat.com>
Message-ID: <94425642-795b-4e14-8150-c65d6071202f@zmail15.collab.prod.int.phx2.redhat.com>

Hi guys,
 
As you all know we have a new release coming up shortly, and as
discussed in the sync meeting last week I'm getting ready to prepare
the release notes for it. To do that I need some help though, as it
currently stands there are no bugs against the oVirt project with a
target release of 3.1 and the ovirt_requires_release_note? flag set.

If you are the maintainer of one of the sub-projects please ensure
that you flag all notable features/fixes included in the 3.1*
release with ovirt_requires_release_notes? and, ideally, add a brief
description in the technical notes field. If you don't have access
to set the flag for some reason then please reply to this email with
a list of bugs instead.
 
I know you've all been working very hard on this release, but without
your input into this process I can not hope to accurately capture
and highlight your efforts in the release notes.

Thanks,
 
Steve

* I have assumed target release = 3.1 is the best flag to use in
Bugzilla to determine which bugs are likely to be included in the
release - if there is a better value to filter on please let me
know.


From amureini at redhat.com  Tue Jun 26 06:22:23 2012
From: amureini at redhat.com (Allon Mureinik)
Date: Tue, 26 Jun 2012 02:22:23 -0400 (EDT)
Subject: [Engine-devel] Forking unit tests
In-Reply-To: <28322afe-b430-4d3c-a039-b12387031dbe@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <930ac795-70d7-4636-a489-5dee9ce821fa@zmail17.collab.prod.int.phx2.redhat.com>

Merged:
http://ovirt.org/wiki/Advanced_oVirt_Engine_Build_Notes#Forking_Unit_Tests

----- Original Message -----
> From: "Allon Mureinik" <amureini at redhat.com>
> To: "Mike Kolesnik" <mkolesni at redhat.com>, engine-devel at ovirt.org
> Sent: Sunday, June 24, 2012 5:23:22 PM
> Subject: Re: [Engine-devel] Forking unit tests
> 
> 
> 
> ----- Original Message -----
> > From: "Allon Mureinik" <amureini at redhat.com>
> > To: "Mike Kolesnik" <mkolesni at redhat.com>
> > Sent: Thursday, June 14, 2012 12:12:54 PM
> > Subject: Re: Forking unit tests
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Mike Kolesnik" <mkolesni at redhat.com>
> > > To: "Allon Mureinik" <amureini at redhat.com>
> > > Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Sent: Wednesday, June 13, 2012 1:28:36 PM
> > > Subject: Re: Forking unit tests
> > > 
> > > > Hi guys,
> > > > 
> > > > If you're using settings.xml as published in Building the oVirt
> > > > Engine page, you'd see we're forking for every test, in every
> > > > subproject.
> > > > This behaviour was introduced to handle memory leaks in
> > > > PowerMock
> > > > we
> > > > use in some subprojects, but is redundant in others.
> > > > 
> > > > Over the past month or so I've been working on removing
> > > > PowerMock
> > > > from as many places as possible (many thanks to mkolesni and
> > > > lhornyak!), and we've got to the stage that forking is only
> > > > needed
> > > > in to subprojects - bll and resttypes.
> > > 
> > > +1 - great job!
> > 10x!
> > 
> > > 
> > > Would it be possible to have this as a parameter (defaul true)
> > > that
> > > can be overridden, such as -Dengine.forkTests=false ?
> > couldn't find a good way to do it <forkMode> doesn't seem to work
> > when given a property as a value, sorry.
> > :-(
> Take a look at http://gerrit.ovirt.org/#/c/5653/1.
> Once it is merged, you could user -Dengine.powermock.fork=one to stop
> forking.
> 
> > 
> > > 
> > > > The forking was defined explicitly in those two projects, so if
> > > > you
> > > > want to speed up your tests, just take the latest version of
> > > > settings.xml from
> > > > http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.
> > > > 
> > > > 
> > > > -Allon
> > > > 
> > > 
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From deepakcs at linux.vnet.ibm.com  Tue Jun 26 06:37:42 2012
From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty)
Date: Tue, 26 Jun 2012 12:07:42 +0530
Subject: [Engine-devel] [vdsm] RFC: Writeup on VDSM-libstoragemgmt
	integration
In-Reply-To: <4FE8A35B.50807@redhat.com>
References: <3607212c-d711-4334-b990-0b749b63c413@zmail07.collab.prod.int.phx2.redhat.com>
	<4FE7CA42.9050703@linux.vnet.ibm.com>
	<4FE87230.4090500@linux.vnet.ibm.com> <4FE8A35B.50807@redhat.com>
Message-ID: <4FE958B6.7000505@linux.vnet.ibm.com>

On 06/25/2012 11:13 PM, Itamar Heim wrote:
> On 06/25/2012 10:14 AM, Deepak C Shetty wrote:
>> On 06/25/2012 07:47 AM, Shu Ming wrote:
>>> On 2012-6-25 10:10, Andrew Cathrow wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Andy Grover" <agrover at redhat.com>
>>>>> To: "Shu Ming" <shuming at linux.vnet.ibm.com>
>>>>> Cc: libstoragemgmt-devel at lists.sourceforge.net,
>>>>> engine-devel at ovirt.org, "VDSM Project Development"
>>>>> <vdsm-devel at lists.fedorahosted.org>
>>>>> Sent: Sunday, June 24, 2012 10:05:45 PM
>>>>> Subject: Re: [vdsm] [Engine-devel] RFC: Writeup on
>>>>> VDSM-libstoragemgmt integration
>>>>>
>>>>> On 06/24/2012 07:28 AM, Shu Ming wrote:
>>>>>> On 2012-6-23 20:40, Itamar Heim wrote:
>>>>>>> On 06/23/2012 03:09 AM, Andy Grover wrote:
>>>>>>>> On 06/22/2012 04:46 PM, Itamar Heim wrote:
>>>>>>>>> On 06/23/2012 02:31 AM, Andy Grover wrote:
>>>>>>>>>> On 06/18/2012 01:15 PM, Saggi Mizrahi wrote:
>>>>>>>>>>> Also, there is no mention on credentials in any part of the
>>>>>>>>>>> process.
>>>>>>>>>>> How does VDSM or the host get access to actually modify the
>>>>>>>>>>> storage
>>>>>>>>>>> array? Who holds the creds for that and how? How does the user
>>>>>>>>>>> set
>>>>>>>>>>> this up?
>>>>>>>>>> It seems to me more natural to have the oVirt-engine use
>>>>>>>>>> libstoragemgmt
>>>>>>>>>> directly to allocate and export a volume on the storage array,
>>>>>>>>>> and
>>>>>>>>>> then
>>>>>>>>>> pass this info to the vdsm on the node creating the vm. This
>>>>>>>>>> answers
>>>>>>>>>> Saggi's question about creds -- vdsm never needs array
>>>>>>>>>> modification
>>>>>>>>>> creds, it only gets handed the params needed to connect and use
>>>>>>>>>> the
>>>>>>>>>> new
>>>>>>>>>> block device (ip, iqn, chap, lun).
>>>>>>>>>>
>>>>>>>>>> Is this usage model made difficult or impossible by the current
>>>>>>>>>> software
>>>>>>>>>> architecture?
>>>>>>>>> what about live snapshots?
>>>>>>>> I'm not a virt guy, so extreme handwaving:
>>>>>>>>
>>>>>>>> vm X uses luns 1& 2
>>>>>>>>
>>>>>>>> engine -> vdsm "pause vm X"
>>>>>>> that's pausing the VM. live snapshot isn't supposed to do so.
>>>>>> Tough we don't expect to do a pausing operation to the VM when live
>>>>>> snaphot is undergoing, the VM should be blocked on the access to
>>>>>> specific luns for a while. The blocking time should be very short
>>>>>> to
>>>>>> avoid the storage IO time out in the VM.
>>>>> OK my mistake, we don't pause the VM during live snapshot, we block
>>>>> on
>>>>> access to the luns while snapshotting. Does this keep live snapshots
>>>>> working and mean ovirt-engine can use libsm to config the storage
>>>>> array
>>>>> instead of vdsm?
>>>>>
>>>>> Because that was really my main question, should we be talking about
>>>>> engine-libstoragemgmt integration rather than vdsm-libstoragemgmt
>>>>> integration.
>>>> for snapshotting wouldn't we want VDSM to handle the coordination of
>>>> the various atomic functions?
>>>
>>> I think VDSM-libstoragemgmt will let the storage array itself to make
>>> the snapshot and handle the coordination of the various atomic
>>> functions. VDSM should be blocked on the following access to the
>>> specific luns which are under snapshotting.
>>
>> I kind of agree. If snapshot is being done at the array level, then the
>> array takes care of quiesing the I/O, taking the snapshot and allowing
>> the I/O, why does VDSM have to worry about anything here, it should all
>> happen transparently for VDSM, isnt it ?
>
> I may be misssing something, but afaiu you need to ask the guest to 
> perform the quiesce, and i'm sure the storage array can't do that.

No, you are not, I missed it. After Tony & Shu Ming's reply, I realised 
that the guest has to quiese the I/O before VDSM can ask storage array 
to take the snapshot.
>
>



From oschreib at redhat.com  Tue Jun 26 09:53:56 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Tue, 26 Jun 2012 05:53:56 -0400 (EDT)
Subject: [Engine-devel] New Fedora VDSM Build?
In-Reply-To: <a859fd4f-a147-4c72-8b0c-9d2ef9c83092@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <a748d592-0f84-43f9-8eb1-258ad7041d6c@zmail14.collab.prod.int.phx2.redhat.com>

Any updates about $topic?

--
Ofer Schreiber
oVirt Release Manager


From danken at redhat.com  Tue Jun 26 10:49:20 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 26 Jun 2012 13:49:20 +0300
Subject: [Engine-devel] New Fedora VDSM Build?
In-Reply-To: <a748d592-0f84-43f9-8eb1-258ad7041d6c@zmail14.collab.prod.int.phx2.redhat.com>
References: <a859fd4f-a147-4c72-8b0c-9d2ef9c83092@zmail14.collab.prod.int.phx2.redhat.com>
	<a748d592-0f84-43f9-8eb1-258ad7041d6c@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <20120626104920.GE29891@redhat.com>

On Tue, Jun 26, 2012 at 05:53:56AM -0400, Ofer Schreiber wrote:
> Any updates about $topic?

Federico is herding sheep in Scotland right now.
Saggi is his second-in-command.

Currently, there ore nly 2 patches on top of Fedrico latest build
https://koji.fedoraproject.org/koji/buildinfo?buildID=327015

But setupNetworks is still rather broken, so it is not our last one :-(

Dan.


From ykaul at redhat.com  Tue Jun 26 10:51:30 2012
From: ykaul at redhat.com (Yaniv Kaul)
Date: Tue, 26 Jun 2012 13:51:30 +0300
Subject: [Engine-devel] New Fedora VDSM Build?
In-Reply-To: <20120626104920.GE29891@redhat.com>
References: <a859fd4f-a147-4c72-8b0c-9d2ef9c83092@zmail14.collab.prod.int.phx2.redhat.com>
	<a748d592-0f84-43f9-8eb1-258ad7041d6c@zmail14.collab.prod.int.phx2.redhat.com>
	<20120626104920.GE29891@redhat.com>
Message-ID: <4FE99432.6070708@redhat.com>

On 06/26/2012 01:49 PM, Dan Kenigsberg wrote:
> On Tue, Jun 26, 2012 at 05:53:56AM -0400, Ofer Schreiber wrote:
>> Any updates about $topic?
> Federico is herding sheep in Scotland right now.
> Saggi is his second-in-command.
>
> Currently, there ore nly 2 patches on top of Fedrico latest build
> https://koji.fedoraproject.org/koji/buildinfo?buildID=327015
>
> But setupNetworks is still rather broken, so it is not our last one :-(

What's the action plan to fix it? I have people who can help test fixes.
Y.

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




From oschreib at redhat.com  Tue Jun 26 10:57:45 2012
From: oschreib at redhat.com (Ofer Schreiber)
Date: Tue, 26 Jun 2012 06:57:45 -0400 (EDT)
Subject: [Engine-devel] New Fedora VDSM Build?
In-Reply-To: <20120626104920.GE29891@redhat.com>
Message-ID: <82c10517-820d-4b7a-9bb5-403e80406466@zmail14.collab.prod.int.phx2.redhat.com>



----- Original Message -----
> On Tue, Jun 26, 2012 at 05:53:56AM -0400, Ofer Schreiber wrote:
> > Any updates about $topic?
> 
> Federico is herding sheep in Scotland right now.
> Saggi is his second-in-command.
> 
> Currently, there ore nly 2 patches on top of Fedrico latest build
> https://koji.fedoraproject.org/koji/buildinfo?buildID=327015

Did you fixed the bootstrap?
If yes, I'd like to get a new build, so people will be able to install VDSM.

> 
> But setupNetworks is still rather broken, so it is not our last one
> :-(
> 
> Dan.
> 


From danken at redhat.com  Tue Jun 26 11:21:09 2012
From: danken at redhat.com (Dan Kenigsberg)
Date: Tue, 26 Jun 2012 14:21:09 +0300
Subject: [Engine-devel] New Fedora VDSM Build?
In-Reply-To: <82c10517-820d-4b7a-9bb5-403e80406466@zmail14.collab.prod.int.phx2.redhat.com>
References: <20120626104920.GE29891@redhat.com>
	<82c10517-820d-4b7a-9bb5-403e80406466@zmail14.collab.prod.int.phx2.redhat.com>
Message-ID: <20120626112109.GH29891@redhat.com>

On Tue, Jun 26, 2012 at 06:57:45AM -0400, Ofer Schreiber wrote:
> 
> 
> ----- Original Message -----
> > On Tue, Jun 26, 2012 at 05:53:56AM -0400, Ofer Schreiber wrote:
> > > Any updates about $topic?
> > 
> > Federico is herding sheep in Scotland right now.
> > Saggi is his second-in-command.
> > 
> > Currently, there ore nly 2 patches on top of Fedrico latest build
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=327015
> 
> Did you fixed the bootstrap?
> If yes, I'd like to get a new build, so people will be able to install VDSM.

bootstrap fixes are in the above-mentioned build -2.  (But there
should be another one regarding kernel version. I could use some help
understanding why douglas cannot verify
http://gerrit.ovirt.org/#/c/5637/ )

Dan.


From ewoud+ovirt at kohlvanwijngaarden.nl  Tue Jun 26 14:15:21 2012
From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden)
Date: Tue, 26 Jun 2012 16:15:21 +0200
Subject: [Engine-devel] oVirt UI Plugins feature: Ready for review
In-Reply-To: <fbd00d07-45c7-418f-a9a6-428484c657b8@zmail16.collab.prod.int.phx2.redhat.com>
References: <6C8AC8C50E170C4E9B44D47B39B24A4801205546@SACEXCMBX04-PRD.hq.netapp.com>
	<fbd00d07-45c7-418f-a9a6-428484c657b8@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <20120626141521.GJ28104@bogey.xentower.nl>

On Mon, Jun 25, 2012 at 01:11:41PM -0400, Vojtech Szocs wrote:
> > BTW, the link to the original design notes on the wiki doesn't work.
>
> This is strange, [http://rhevmf.pad.engineering.redhat.com/68] has its
> visibility set to "Public (Allow Internet guests)" ... Does anybody
> know why this doesn't work?

The DNS records aren't public.


From vszocs at redhat.com  Tue Jun 26 14:44:15 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 26 Jun 2012 10:44:15 -0400 (EDT)
Subject: [Engine-devel] oVirt UI Plugins feature: Ready for review
In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A4801205F4B@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <16757592-60df-4b6a-93f7-33cbc7029e79@zmail16.collab.prod.int.phx2.redhat.com>

Hi George, 

I've been thinking about developing plugins with GWT. There are some important issues that need to be addressed: 


    1. GWT bootstrap sequence requires permutation selector script ( <pluginApplication>.nocache.js ) to be invoked first. Selector script determines the correct permutation ( <hashName>.cache.html ) and fetches it asynchronously from the same location. 
    2. GWT bootstrap sequence is asynchronous in nature. 
    3. GWT RPC ( XMLHttpRequest ) is subject to Same Origin Policy [1]. This means that pluginApplication 's server-side code should be deployed on oVirt JBoss AS instance (next to engine.ear ). 

Given these limitations, I'd say the process could be like this: 

a) In pluginApplication 's EntryPoint , use GWT JSNI [2] to register the plugin using native JavaScript code. 

You don't need to use gwt-exporter here, since plugin registration and logic is combined in one place. 
Using plugin-to-GWT delegate pattern with gwt-exporter is actually more complicated than going with plain JSNI. 

For example: 

package com.myplugin; 

public class MyPluginApp implements com.google.gwt.core.client.EntryPoint { 

public void void onModuleLoad() { 
// Initialize plugin application, call registerPlugin() when ready 
registerPlugin(); 
} 

public static void tableContextMenu(com.google.gwt.core.client.JavaScriptObject eventContext) { 
// Consider using GWT overlay types [3] to easily work with JavaScriptObjects 
} 

private static native void registerPlugin() /*-{ 
// Register 'myPlugin' into pluginApi.plugins object 
$wnd.pluginApi.plugins.myPlugin = myPlugin = { 
tableContextMenu: function(eventContext) { 
// Call Java static method to handle this event 
@com.myplugin.MyPluginApp::tableContextMenu(Lcom/google/gwt/core/client/JavaScriptObject;)(eventContext); 
} 
}; 
// Call the ready() function right away 
$wnd.pluginApi.lifecycle(myPlugin).ready(); 
}-*/; 

} 

b) Deploy the <pluginApplication>.war file on JBoss AS instance, e.g. <JBOSS_HOME>/standalone/deployments . 

This makes pluginApplication 's GWT RPC servlet(s) accessible from the same origin (protocol, domain, port). 

c) Modification of plugin lifecycle step #5: 

Instead of embedding <pluginApplication>.nocache.js content into WebAdmin HTML page, just embed the link to it, e.g. http(s)://127.0.0.1:<port>/path/to/<pluginApplication>.nocache.js 

d) Modification of plugin lifecycle step #6: 

During WebAdmin startup, for each plugin that is supposed to be loaded remotely, create an <iframe> that will fetch the plugin asynchronously. 

The <iframe> is required in order for <pluginApplication>.nocache.js to appear from different ( pluginApplication -specific ) domain than WebAdmin HTML page. 

This way, fetching permutation ( <hashName>.cache.html ) files, which are relative to <pluginApplication>.nocache.js , will work out-of-the-box. 


George, please let me know what you think, and I will update UI Plugins wiki accordingly. 

Vojtech 


[1] http://en.wikipedia.org/wiki/Same_origin_policy 
[2] https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsJSNI 
[3] https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsOverlay 


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

From: "George Costea" <George.Costea at netapp.com> 
To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org 
Cc: "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com>, "Ricky Hopper" <Ricky.Hopper at netapp.com>, "Itamar Heim" <iheim at redhat.com> 
Sent: Monday, June 25, 2012 9:11:33 PM 
Subject: RE: oVirt UI Plugins feature: Ready for review 

Thanks Vojtech. 

Since the plugins are embedded into the WebAdmin HTML page, that seems to simplify things; no external web service is needed. This approach ties into the issue over the freedom to decide which technology to use when developing a plugin. While I agree that jQuery is best for simple dialogs, a wizard-driven workflow is easier to develop in GWT. 

For example, if I want to step a user through the process of creating a new storage domain I would like to provide a workflow to select a storage array, provide credentials, and configure the details of the NFS export. This workflow could presumably have a GWT-RPC mechanism that relies on some additional libraries on the backend (libraries that allow me to communicate with the storage array). Using the GWT-Exporter, I could export the classes that would display the workflow which would then get launched as my extension is selected. You said that I would have my oVirt UI plugin depend on my compiled 'plugin support application'. My compiled plugin support application would normally be a war file containing my compiled GWT code and a web-inf folder containing my libraries. Is the plugin depending on the war file? Is that what I specify? 

-George 

-----Original Message----- 
From: Vojtech Szocs [mailto:vszocs at redhat.com] 
Sent: Monday, June 25, 2012 1:12 PM 
To: Costea, George; engine-devel at ovirt.org 
Cc: Schoenbrun, Dustin; Hopper, Ricky; Itamar Heim 
Subject: Re: oVirt UI Plugins feature: Ready for review 

Hi George, 

thanks for your feedback. Please find my answers below. 




1) Are the plugins hosted by the same jboss server that hosts the engine? It would appear the answer is yes and that no separate container is required for the plugins. 

In short, yes. 



Plugins, along with their configuration and 3rd party dependencies, are meant to be embedded into final WebAdmin HTML page, see [http://www.ovirt.org/wiki/Features/UIPlugins#Plugin_lifecycle] step #5. 
JBoss AS instance serves WebAdmin HTML page (WebadminDynamicHostingServlet), along with providing GWT RPC and REST endpoints that delegate to Engine business logic through EJB BackendLocal interface. 

However, plugins are not 'hosted' in a typical sense - WebadminDynamicHostingServlet reads and embeds all plugin data directly into final WebAdmin HTML page. 



<blockquote>
2) Does each plugin map to a unique extension within WebAdmin? Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension. This is named pluginApi.plugins.myPlugin. Can I safely assume that this is per extension? I would have pluginApi.plugins.myPlugin2 for extending a storage domain? 

Extension points are represented by application events, triggered by WebAdmin and consumed by plugins. For example, 'tableContextMenu' event gets triggered when a table context menu is about to be shown to the user, which gives plugins the ability to do something custom with the context menu before it's shown. 
</blockquote>


There can be multiple plugins handling the same event (extension point). You can have two plugins, say 'pluginApi.plugins.One' and 'pluginApi.plugins.Two', each providing 'tableContextMenu' function for handling the above mentioned event. WebAdmin will invoke all plugins for the given event. 

To answer your question, in order to handle X events (extension points), you don't need to write X plugins. You can write one plugin that handles X events. 



<blockquote>
3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs? 

You can do anything you want in your plugin event handler function. Show a jQuery UI dialog, make oVirt REST API request, call arbitrary remote server using cross-domain technique like JSONP [1] or CORS [2], etc. Plugin authors are free to decide if they want to rely on 3rd party JavaScript libraries, or if they want to write entire plugin code by themselves. 
</blockquote>


In my opinion, tools like jQuery are far more elegant for handling simple things such as UI dialogs. But if you really want to use GWT for this purpose, I suggest following approach: 

a, develop a 'plugin support application' in GWT, which implements the necessary dialog functionality b, export its main (e.g. dialog handling) classes for use in native JavaScript through gwt-exporter [3] c, have your oVirt UI plugin depend on your compiled 'plugin support application' (this will cause your 'plugin support application' to be called during WebAdmin startup) d, in your oVirt UI plugin, invoke 'plugin support application' functionality through exported classes (plugin -> GWT delegate pattern) 



<blockquote>
4) Is session info passed into the plugin so that I can invoke APIs into the engine? To power on a VM for instance? Or to mount a new NFS storage domain? 

Yes, this should be part of [http://www.ovirt.org/wiki/Features/UIPlugins#Global_API_functions] "Plugin utility functions" (global API). 
</blockquote>


Your plugin might access user session information in the following way: pluginApi.util().userInfo().* (replace * with id(), name(), domain(), etc.) 

As you pointed out, this could be used to authenticate oVirt REST API requests made from your plugin code. 



<blockquote>
BTW, the link to the original design notes on the wiki doesn't work. 

This is strange, [http://rhevmf.pad.engineering.redhat.com/68] has its visibility set to "Public (Allow Internet guests)" ... Does anybody know why this doesn't work? 
</blockquote>



Vojtech 


[1] http://en.wikipedia.org/wiki/JSONP 
[2] http://en.wikipedia.org/wiki/Cross-origin_resource_sharing 
[3] http://code.google.com/p/gwt-exporter/ 


----- Original Message ----- 
From: "George Costea" <George.Costea at netapp.com> 
To: "Vojtech Szocs" <vszocs at redhat.com>, engine-devel at ovirt.org 
Cc: "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com>, "Ricky Hopper" <Ricky.Hopper at netapp.com> 
Sent: Monday, June 25, 2012 3:09:43 PM 
Subject: RE: oVirt UI Plugins feature: Ready for review 

Hi Vojtech, 

I have a few questions on this feature. 

1) Are the plugins hosted by the same jboss server that hosts the engine? It would appear the answer is yes and that no separate container is required for the plugins. 
2) Does each plugin map to a unique extension within WebAdmin? Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension. This is named pluginApi.plugins.myPlugin. Can I safely assume that this is per extension? I would have pluginApi.plugins.myPlugin2 for extending a storage domain? 
3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs? 
4) Is session info passed into the plugin so that I can invoke APIs into the engine? To power on a VM for instance? Or to mount a new NFS storage domain? 

BTW, the link to the original design notes on the wiki doesn't work. 

Thanks, 
George 

-----Original Message----- 
From: Vojtech Szocs [mailto:vszocs at redhat.com] 
Sent: Thursday, June 21, 2012 11:03 AM 
To: engine-devel at ovirt.org 
Cc: Schoenbrun, Dustin; Costea, George; Hopper, Ricky 
Subject: oVirt UI Plugins feature: Ready for review 

Hi guys, 

I wrote a wiki page describing UI Plugins, a feature planned for oVirt web administration (WebAdmin) application: 
http://www.ovirt.org/wiki/Features/UIPlugins 

Feature design is finished and ready for review. Please feel free to add comments, ask questions or reach me directly on #ovirt channel. 

Cheers, 
Vojtech 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120626/556dceab/attachment.html>

From vszocs at redhat.com  Tue Jun 26 15:04:27 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 26 Jun 2012 11:04:27 -0400 (EDT)
Subject: [Engine-devel] oVirt UI Plugins feature: Ready for review
In-Reply-To: <20120626141521.GJ28104@bogey.xentower.nl>
Message-ID: <a95c006d-2773-49c6-9ccf-fb045a525389@zmail16.collab.prod.int.phx2.redhat.com>

Looks like rhevmf.pad.engineering.redhat.com is on internal network :(

You can find original UI plugin design notes here: http://www.ovirt.org/wiki/Features/UIPluginsOriginalDesignNotes

(I've also updated UI plugin main wiki page to reflect the link above.)

Vojtech


----- Original Message -----
From: "Ewoud Kohl van Wijngaarden" <ewoud+ovirt at kohlvanwijngaarden.nl>
To: engine-devel at ovirt.org
Sent: Tuesday, June 26, 2012 4:15:21 PM
Subject: Re: [Engine-devel] oVirt UI Plugins feature: Ready for review

On Mon, Jun 25, 2012 at 01:11:41PM -0400, Vojtech Szocs wrote:
> > BTW, the link to the original design notes on the wiki doesn't work.
>
> This is strange, [http://rhevmf.pad.engineering.redhat.com/68] has its
> visibility set to "Public (Allow Internet guests)" ... Does anybody
> know why this doesn't work?

The DNS records aren't public.
_______________________________________________
Engine-devel mailing list
Engine-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel


From vszocs at redhat.com  Tue Jun 26 15:19:18 2012
From: vszocs at redhat.com (Vojtech Szocs)
Date: Tue, 26 Jun 2012 11:19:18 -0400 (EDT)
Subject: [Engine-devel] oVirt UI Plugins: some more ideas
In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A4801205F4B@SACEXCMBX04-PRD.hq.netapp.com>
Message-ID: <f91ae75b-b27b-4e3a-a6fb-7e3f1b55c82c@zmail16.collab.prod.int.phx2.redhat.com>

Hi guys,

as a follow-up to an excellent discussion with Michal, here are some ideas that could prove useful when implementing robust UI plugin infrastructure. (Please let me know what you think.)

1. Implement WebAdmin dialog that lists active plugins, with the ability to turn them on/off (during WebAdmin runtime).
2. Implement WebAdmin 'plugin-safe' mode, which disables all plugins during WebAdmin startup (could be controlled via HTTP parameter)
3. Introduce WebAdmin plugin API compliance version, so that plugins can be made against specific version of WebAdmin

Cheers,
Vojtech


From George.Costea at netapp.com  Tue Jun 26 19:05:16 2012
From: George.Costea at netapp.com (Costea, George)
Date: Tue, 26 Jun 2012 19:05:16 +0000
Subject: [Engine-devel] oVirt UI Plugins: some more ideas
In-Reply-To: <f91ae75b-b27b-4e3a-a6fb-7e3f1b55c82c@zmail16.collab.prod.int.phx2.redhat.com>
References: <6C8AC8C50E170C4E9B44D47B39B24A4801205F4B@SACEXCMBX04-PRD.hq.netapp.com>
	<f91ae75b-b27b-4e3a-a6fb-7e3f1b55c82c@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <6C8AC8C50E170C4E9B44D47B39B24A4801207D20@SACEXCMBX04-PRD.hq.netapp.com>

All of these are excellent ideas!

-----Original Message-----
From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Vojtech Szocs
Sent: Tuesday, June 26, 2012 11:19 AM
To: engine-devel at ovirt.org
Cc: Michal Skrivanek
Subject: [Engine-devel] oVirt UI Plugins: some more ideas

Hi guys,

as a follow-up to an excellent discussion with Michal, here are some ideas that could prove useful when implementing robust UI plugin infrastructure. (Please let me know what you think.)

1. Implement WebAdmin dialog that lists active plugins, with the ability to turn them on/off (during WebAdmin runtime).
2. Implement WebAdmin 'plugin-safe' mode, which disables all plugins during WebAdmin startup (could be controlled via HTTP parameter) 3. Introduce WebAdmin plugin API compliance version, so that plugins can be made against specific version of WebAdmin

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


From fsimonce at redhat.com  Tue Jun 26 19:29:31 2012
From: fsimonce at redhat.com (Federico Simoncelli)
Date: Tue, 26 Jun 2012 15:29:31 -0400 (EDT)
Subject: [Engine-devel] New Fedora VDSM Build?
In-Reply-To: <20120626112109.GH29891@redhat.com>
Message-ID: <fdbf9f01-5bd5-40bb-a23f-d30ba08bfc4e@zmail16.collab.prod.int.phx2.redhat.com>

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Ofer Schreiber" <oschreib at redhat.com>
> Cc: "Federico Simoncelli" <fsimonce at redhat.com>, engine-devel at ovirt.org, "Saggi Mizrahi" <smizrahi at redhat.com>
> Sent: Tuesday, June 26, 2012 1:21:09 PM
> Subject: Re: New Fedora VDSM Build?
> 
> On Tue, Jun 26, 2012 at 06:57:45AM -0400, Ofer Schreiber wrote:
> > ----- Original Message -----
> > > On Tue, Jun 26, 2012 at 05:53:56AM -0400, Ofer Schreiber wrote:
> > > > Any updates about $topic?
> > > 
> > > Federico is herding sheep in Scotland right now.
> > > Saggi is his second-in-command.
> > > 
> > > Currently, there ore nly 2 patches on top of Fedrico latest build
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=327015
> > 
> > Did you fixed the bootstrap?
> > If yes, I'd like to get a new build, so people will be able to
> > install VDSM.
> 
> bootstrap fixes are in the above-mentioned build -2.  (But there
> should be another one regarding kernel version. I could use some help
> understanding why douglas cannot verify
> http://gerrit.ovirt.org/#/c/5637/ )

FYI, for other reasons (related to koji) I had to make another build and
since I was at it I added BZ#832577 and BZ#824298:

http://koji.fedoraproject.org/koji/buildinfo?buildID=327730

* Tue Jun 26 2012 Federico Simoncelli <fsimonce at redhat.com> 4.10.0-3.fc17
- BZ#832577: node can't be approved
- BZ#824298 fix typo in keyword argument exc_info

You can ignore it if it's not fixing anything that you care about.
-- 
Federico


From George.Costea at netapp.com  Tue Jun 26 20:39:55 2012
From: George.Costea at netapp.com (Costea, George)
Date: Tue, 26 Jun 2012 20:39:55 +0000
Subject: [Engine-devel] oVirt UI Plugins feature: Ready for review
In-Reply-To: <16757592-60df-4b6a-93f7-33cbc7029e79@zmail16.collab.prod.int.phx2.redhat.com>
References: <6C8AC8C50E170C4E9B44D47B39B24A4801205F4B@SACEXCMBX04-PRD.hq.netapp.com>
	<16757592-60df-4b6a-93f7-33cbc7029e79@zmail16.collab.prod.int.phx2.redhat.com>
Message-ID: <6C8AC8C50E170C4E9B44D47B39B24A48012080BA@SACEXCMBX04-PRD.hq.netapp.com>

This sounds great.  Thanks Vojtech.

From: Vojtech Szocs [mailto:vszocs at redhat.com]
Sent: Tuesday, June 26, 2012 10:44 AM
To: engine-devel at ovirt.org
Cc: Costea, George; Schoenbrun, Dustin; Hopper, Ricky; Itamar Heim
Subject: Re: oVirt UI Plugins feature: Ready for review

Hi George,

I've been thinking about developing plugins with GWT. There are some important issues that need to be addressed:

  1.  GWT bootstrap sequence requires permutation selector script (<pluginApplication>.nocache.js) to be invoked first.
Selector script determines the correct permutation (<hashName>.cache.html) and fetches it asynchronously from the same location.
  2.  GWT bootstrap sequence is asynchronous in nature.
  3.  GWT RPC (XMLHttpRequest) is subject to Same Origin Policy [1].
This means that pluginApplication's server-side code should be deployed on oVirt JBoss AS instance (next to engine.ear).

Given these limitations, I'd say the process could be like this:

a) In pluginApplication's EntryPoint, use GWT JSNI [2] to register the plugin using native JavaScript code.

   You don't need to use gwt-exporter here, since plugin registration and logic is combined in one place.
   Using plugin-to-GWT delegate pattern with gwt-exporter is actually more complicated than going with plain JSNI.

   For example:

   package com.myplugin;

   public class MyPluginApp implements com.google.gwt.core.client.EntryPoint {

      public void void onModuleLoad() {
         // Initialize plugin application, call registerPlugin() when ready
         registerPlugin();
      }

      public static void tableContextMenu(com.google.gwt.core.client.JavaScriptObject eventContext) {
         // Consider using GWT overlay types [3] to easily work with JavaScriptObjects
      }

      private static native void registerPlugin() /*-{
         // Register 'myPlugin' into pluginApi.plugins object
         $wnd.pluginApi.plugins.myPlugin = myPlugin = {
            tableContextMenu: function(eventContext) {
               // Call Java static method to handle this event
               @com.myplugin.MyPluginApp::tableContextMenu(Lcom/google/gwt/core/client/JavaScriptObject;)(eventContext);
            }
         };
         // Call the ready() function right away
         $wnd.pluginApi.lifecycle(myPlugin).ready();
      }-*/;

   }

b) Deploy the <pluginApplication>.war file on JBoss AS instance, e.g. <JBOSS_HOME>/standalone/deployments.

   This makes pluginApplication's GWT RPC servlet(s) accessible from the same origin (protocol, domain, port).

c) Modification of plugin lifecycle step #5:

   Instead of embedding <pluginApplication>.nocache.js content into WebAdmin HTML page, just embed the link to it, e.g. http(s)://127.0.0.1:<port>/path/to/<pluginApplication>.nocache.js

d) Modification of plugin lifecycle step #6:

   During WebAdmin startup, for each plugin that is supposed to be loaded remotely, create an <iframe> that will fetch the plugin asynchronously.

   The <iframe> is required in order for <pluginApplication>.nocache.js to appear from different (pluginApplication-specific) domain than WebAdmin HTML page.

   This way, fetching permutation (<hashName>.cache.html) files, which are relative to <pluginApplication>.nocache.js, will work out-of-the-box.


George, please let me know what you think, and I will update UI Plugins wiki accordingly.

Vojtech


[1] http://en.wikipedia.org/wiki/Same_origin_policy
[2] https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsJSNI
[3] https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsOverlay

________________________________

From: "George Costea" <George.Costea at netapp.com<mailto:George.Costea at netapp.com>>
To: "Vojtech Szocs" <vszocs at redhat.com<mailto:vszocs at redhat.com>>, engine-devel at ovirt.org<mailto:engine-devel at ovirt.org>
Cc: "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com<mailto:Dustin.Schoenbrun at netapp.com>>, "Ricky Hopper" <Ricky.Hopper at netapp.com<mailto:Ricky.Hopper at netapp.com>>, "Itamar Heim" <iheim at redhat.com<mailto:iheim at redhat.com>>
Sent: Monday, June 25, 2012 9:11:33 PM
Subject: RE: oVirt UI Plugins feature: Ready for review

Thanks Vojtech.

Since the plugins are embedded into the WebAdmin HTML page, that seems to simplify things; no external web service is needed.  This approach ties into the issue over the freedom to decide which technology to use when developing a plugin.  While I agree that jQuery is best for simple dialogs, a wizard-driven workflow is easier to develop in GWT.

For example, if I want to step a user through the process of creating a new storage domain I would like to provide a workflow to select a storage array, provide credentials, and configure the details of the NFS export.  This workflow could presumably have a GWT-RPC mechanism that relies on some additional libraries on the backend (libraries that allow me to communicate with the storage array).  Using the GWT-Exporter, I could export the classes that would display the workflow which would then get launched as my extension is selected.  You said that I would have my oVirt UI plugin depend on my compiled 'plugin support application'.  My compiled plugin support application would normally be a war file containing my compiled GWT code and a web-inf folder containing my libraries.  Is the plugin depending on the war file?  Is that what I specify?

-George

-----Original Message-----
From: Vojtech Szocs [mailto:vszocs at redhat.com]<mailto:[mailto:vszocs at redhat.com]>
Sent: Monday, June 25, 2012 1:12 PM
To: Costea, George; engine-devel at ovirt.org<mailto:engine-devel at ovirt.org>
Cc: Schoenbrun, Dustin; Hopper, Ricky; Itamar Heim
Subject: Re: oVirt UI Plugins feature: Ready for review

Hi George,

thanks for your feedback. Please find my answers below.

1) Are the plugins hosted by the same jboss server that hosts the engine?  It would appear the answer is yes and that no separate container is required for the plugins.

In short, yes.


Plugins, along with their configuration and 3rd party dependencies, are meant to be embedded into final WebAdmin HTML page, see [http://www.ovirt.org/wiki/Features/UIPlugins#Plugin_lifecycle] step #5.
JBoss AS instance serves WebAdmin HTML page (WebadminDynamicHostingServlet), along with providing GWT RPC and REST endpoints that delegate to Engine business logic through EJB BackendLocal interface.

However, plugins are not 'hosted' in a typical sense - WebadminDynamicHostingServlet reads and embeds all plugin data directly into final WebAdmin HTML page.

2) Does each plugin map to a unique extension within WebAdmin?  Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension.  This is named pluginApi.plugins.myPlugin.  Can I safely assume that this is per extension?  I would have pluginApi.plugins.myPlugin2 for extending a storage domain?

Extension points are represented by application events, triggered by WebAdmin and consumed by plugins. For example, 'tableContextMenu' event gets triggered when a table context menu is about to be shown to the user, which gives plugins the ability to do something custom with the context menu before it's shown.


There can be multiple plugins handling the same event (extension point). You can have two plugins, say 'pluginApi.plugins.One' and 'pluginApi.plugins.Two', each providing 'tableContextMenu' function for handling the above mentioned event. WebAdmin will invoke all plugins for the given event.

To answer your question, in order to handle X events (extension points), you don't need to write X plugins. You can write one plugin that handles X events.

3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs?

You can do anything you want in your plugin event handler function. Show a jQuery UI dialog, make oVirt REST API request, call arbitrary remote server using cross-domain technique like JSONP [1] or CORS [2], etc. Plugin authors are free to decide if they want to rely on 3rd party JavaScript libraries, or if they want to write entire plugin code by themselves.


In my opinion, tools like jQuery are far more elegant for handling simple things such as UI dialogs. But if you really want to use GWT for this purpose, I suggest following approach:

a, develop a 'plugin support application' in GWT, which implements the necessary dialog functionality b, export its main (e.g. dialog handling) classes for use in native JavaScript through gwt-exporter [3] c, have your oVirt UI plugin depend on your compiled 'plugin support application' (this will cause your 'plugin support application' to be called during WebAdmin startup) d, in your oVirt UI plugin, invoke 'plugin support application' functionality through exported classes (plugin -> GWT delegate pattern)

4) Is session info passed into the plugin so that I can invoke APIs into the engine?  To power on a VM for instance?  Or to mount a new NFS storage domain?

Yes, this should be part of [http://www.ovirt.org/wiki/Features/UIPlugins#Global_API_functions] "Plugin utility functions" (global API).


Your plugin might access user session information in the following way: pluginApi.util().userInfo().* (replace * with id(), name(), domain(), etc.)

As you pointed out, this could be used to authenticate oVirt REST API requests made from your plugin code.

BTW, the link to the original design notes on the wiki doesn't work.

This is strange, [http://rhevmf.pad.engineering.redhat.com/68] has its visibility set to "Public (Allow Internet guests)" ... Does anybody know why this doesn't work?



Vojtech


[1] http://en.wikipedia.org/wiki/JSONP
[2] http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
[3] http://code.google.com/p/gwt-exporter/


----- Original Message -----
From: "George Costea" <George.Costea at netapp.com<mailto:George.Costea at netapp.com>>
To: "Vojtech Szocs" <vszocs at redhat.com<mailto:vszocs at redhat.com>>, engine-devel at ovirt.org<mailto:engine-devel at ovirt.org>
Cc: "Dustin Schoenbrun" <Dustin.Schoenbrun at netapp.com<mailto:Dustin.Schoenbrun at netapp.com>>, "Ricky Hopper" <Ricky.Hopper at netapp.com<mailto:Ricky.Hopper at netapp.com>>
Sent: Monday, June 25, 2012 3:09:43 PM
Subject: RE: oVirt UI Plugins feature: Ready for review

Hi Vojtech,

I have a few questions on this feature.

1) Are the plugins hosted by the same jboss server that hosts the engine?  It would appear the answer is yes and that no separate container is required for the plugins.
2) Does each plugin map to a unique extension within WebAdmin?  Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension.  This is named pluginApi.plugins.myPlugin.  Can I safely assume that this is per extension?  I would have pluginApi.plugins.myPlugin2 for extending a storage domain?
3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs?
4) Is session info passed into the plugin so that I can invoke APIs into the engine?  To power on a VM for instance?  Or to mount a new NFS storage domain?

BTW, the link to the original design notes on the wiki doesn't work.

Thanks,
George

-----Original Message-----
From: Vojtech Szocs [mailto:vszocs at redhat.com]<mailto:[mailto:vszocs at redhat.com]>
Sent: Thursday, June 21, 2012 11:03 AM
To: engine-devel at ovirt.org<mailto:engine-devel at ovirt.org>
Cc: Schoenbrun, Dustin; Costea, George; Hopper, Ricky
Subject: oVirt UI Plugins feature: Ready for review

Hi guys,

I wrote a wiki page describing UI Plugins, a feature planned for oVirt web administration (WebAdmin) application:
http://www.ovirt.org/wiki/Features/UIPlugins

Feature design is finished and ready for review. Please feel free to add comments, ask questions or reach me directly on #ovirt channel.

Cheers,
Vojtech
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/engine-devel/attachments/20120626/3d6d6393/attachment.html>

From ovirt at qip.ru  Wed Jun 27 10:36:23 2012
From: ovirt at qip.ru (ovirt at qip.ru)
Date: Wed, 27 Jun 2012 14:36:23 +0400
Subject: [Engine-devel] fedora_17_slave_02 on jenkins
Message-ID: <f74d5d7d89b00d916f7bdba9c56dc9e9840249b6@mail.qip.ru>

Hi, ALL

Is it ok that node 
fedora_17_slave_02 on http://jenkins.ovirt.org/computer/fedora_17_slave_02/

has
Process leaked file descriptors error about two days?

Bye,
Vadim

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

From eedri at redhat.com  Wed Jun 27 11:49:20 2012
From: eedri at redhat.com (Eyal Edri)
Date: Wed, 27 Jun 2012 07:49:20 -0400 (EDT)
Subject: [Engine-devel] fedora_17_slave_02 on jenkins
In-Reply-To: <f74d5d7d89b00d916f7bdba9c56dc9e9840249b6@mail.qip.ru>
Message-ID: <4fbfe5d7-d34a-4806-903b-956a89ef1910@zmail17.collab.prod.int.phx2.redhat.com>

You are right.

seems like a few jobs got hang and weren't released by jenkins.

it can sometimes happen in jenkins [1], i've added a timeout for these job so next time they will fail if they last for too long.
thanks for the heads up.

[1] https://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build

Eyal Edri
oVirt Infra Team.

----- Original Message -----
> From: ovirt at qip.ru
> To: engine-devel at ovirt.org
> Sent: Wednesday, June 27, 2012 1:36:23 PM
> Subject: [Engine-devel] fedora_17_slave_02 on jenkins
> 
> 
> Hi, ALL
> 
> Is it ok that node
> fedora_17_slave_02 on
> http://jenkins.ovirt.org/computer/fedora_17_slave_02/
> 
> 
> has Process leaked file descriptors error about two days?
> Bye,
> Vadim
> 
> 
> --
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


From shaohef at linux.vnet.ibm.com  Thu Jun 28 20:30:37 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Fri, 29 Jun 2012 04:30:37 +0800
Subject: [Engine-devel] Request for code review
Message-ID: <4FECBEED.1080306@linux.vnet.ibm.com>

Hi guys:

My patch "add a new tool for auto-generate python entities from schema" 
is ready for review.
http://gerrit.ovirt.org/#/c/4880/
I am looking forward to your comments. Thanks.



From shaohef at linux.vnet.ibm.com  Fri Jun 29 10:53:47 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Fri, 29 Jun 2012 18:53:47 +0800
Subject: [Engine-devel] Developer's All In One -Can not create an vm on
 iscsi disk
In-Reply-To: <93ae29b9-6274-4a02-acb0-db34affa5890@zmail17.collab.prod.int.phx2.redhat.com>
References: <93ae29b9-6274-4a02-acb0-db34affa5890@zmail17.collab.prod.int.phx2.redhat.com>
Message-ID: <4FED893B.20902@linux.vnet.ibm.com>

I have set up all-in-one. but I use iscsi data center, not NFS  data center.
ovirt-engine create an direct Lun disk, but can not create an vm.
The status is always "wait for launch". It take a long time, but the 
status is still "wait for launch"

I set up an iscsi server, as follow:
# dd if=/dev/zero of=$SCPATH/fs.iscsi.disk2 bs=1M count=15360
# dd if=/dev/zero of=$SCPATH/fs.iscsi.disk3 bs=1M count=15360
# sudo tgtadm --lld iscsi --op new --mode target --tid 1 -T 
iqn.2012-02.com.example.data1
# sudo tgtadm --lld iscsi --op new  --mode logicalunit --tid 1 --lun 2 
-b $SCPATH/fs.iscsi.disk2
# sudo tgtadm --lld iscsi --op new  --mode logicalunit --tid 1 --lun 3 
-b $SCPATH/fs.iscsi.disk3
# sudo tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL




On 06/18/2012 10:01 PM, Allon Mureinik wrote:
> Cross-posting to engine-devel
>
>> ----- Forwarded Message -----
>> From: "Yeela Kaplan" <ykaplan at redhat.com>
>> To: vdsm-devel at lists.fedorahosted.org,
>> engine-devel at lists.fedorahosted.org
>> Cc: "Ayal Baron" <abaron at redhat.com>
>> Sent: Monday, June 18, 2012 2:58:55 PM
>> Subject: Developer's All In One
>>
>> Enclosed is the link to a wiki containing a detailed explanation for
>> installing a developer's All-In-One environment:
>>   
>> http://www.ovirt.org/wiki/Developers_All_In_One
>>
>> Regards,
>> Yeela
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>




From shaohef at linux.vnet.ibm.com  Fri Jun 29 11:37:48 2012
From: shaohef at linux.vnet.ibm.com (Sheldon)
Date: Fri, 29 Jun 2012 19:37:48 +0800
Subject: [Engine-devel] Developer's All In One -Can not create an vm on
 iscsi disk
In-Reply-To: <4FED893B.20902@linux.vnet.ibm.com>
References: <93ae29b9-6274-4a02-acb0-db34affa5890@zmail17.collab.prod.int.phx2.redhat.com>
	<4FED893B.20902@linux.vnet.ibm.com>
Message-ID: <4FED938C.2010800@linux.vnet.ibm.com>

I have find an error in vdsm.log
error : virNetClientProgramDispatchError:174 :  internal error 
unsupported configuration: Readonly leases are not supported

I create an nfs iso domain.
# ls 
/rhev/data-center/af7ddcdd-8c3e-49d1-b885-38daa7f79030/76df39bd-cb52-4783-a5a7-fce9fd82d421/images/11111111-1111-1111-1111-111111111111/ubuntu-12.04-dvd-amd64.iso 
-l
-rwxr-xr-x. 1 vdsm kvm 1666560000 Jun 29 17:49 
/rhev/data-center/af7ddcdd-8c3e-49d1-b885-38daa7f79030/76df39bd-cb52-4783-a5a7-fce9fd82d421/images/11111111-1111-1111-1111-111111111111/ubuntu-12.04-dvd-amd64.iso

On 06/29/2012 06:53 PM, Sheldon wrote:
> I have set up all-in-one. but I use iscsi data center, not NFS  data 
> center.
> ovirt-engine create an direct Lun disk, but can not create an vm.
> The status is always "wait for launch". It take a long time, but the 
> status is still "wait for launch"
>
> I set up an iscsi server, as follow:
> # dd if=/dev/zero of=$SCPATH/fs.iscsi.disk2 bs=1M count=15360
> # dd if=/dev/zero of=$SCPATH/fs.iscsi.disk3 bs=1M count=15360
> # sudo tgtadm --lld iscsi --op new --mode target --tid 1 -T 
> iqn.2012-02.com.example.data1
> # sudo tgtadm --lld iscsi --op new  --mode logicalunit --tid 1 --lun 2 
> -b $SCPATH/fs.iscsi.disk2
> # sudo tgtadm --lld iscsi --op new  --mode logicalunit --tid 1 --lun 3 
> -b $SCPATH/fs.iscsi.disk3
> # sudo tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
>
>
>
>
> On 06/18/2012 10:01 PM, Allon Mureinik wrote:
>> Cross-posting to engine-devel
>>
>>> ----- Forwarded Message -----
>>> From: "Yeela Kaplan" <ykaplan at redhat.com>
>>> To: vdsm-devel at lists.fedorahosted.org,
>>> engine-devel at lists.fedorahosted.org
>>> Cc: "Ayal Baron" <abaron at redhat.com>
>>> Sent: Monday, June 18, 2012 2:58:55 PM
>>> Subject: Developer's All In One
>>>
>>> Enclosed is the link to a wiki containing a detailed explanation for
>>> installing a developer's All-In-One environment:
>>>   http://www.ovirt.org/wiki/Developers_All_In_One
>>>
>>> Regards,
>>> Yeela
>>>
>> _______________________________________________
>> 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 gpadgett at redhat.com  Fri Jun 29 15:39:33 2012
From: gpadgett at redhat.com (gpadgett at redhat.com)
Date: Fri, 29 Jun 2012 11:39:33 -0400
Subject: [Engine-devel] Developer's All In One -Can not create an vm on
 iscsi disk
In-Reply-To: <4FED938C.2010800@linux.vnet.ibm.com>
References: <93ae29b9-6274-4a02-acb0-db34affa5890@zmail17.collab.prod.int.phx2.redhat.com>
	<4FED893B.20902@linux.vnet.ibm.com>
	<4FED938C.2010800@linux.vnet.ibm.com>
Message-ID: <4FEDCC35.9080005@redhat.com>

On 06/29/2012 07:37 AM, Sheldon wrote:
> I have find an error in vdsm.log
> error : virNetClientProgramDispatchError:174 :  internal error
> unsupported configuration: Readonly leases are not supported

This may be related to bug 828633 (http://bugzilla.redhat.com/828633), 
in which case installing the new libvirt package in the bz's most recent 
comment should fix the problem.

>
> I create an nfs iso domain.
> # ls
> /rhev/data-center/af7ddcdd-8c3e-49d1-b885-38daa7f79030/76df39bd-cb52-4783-a5a7-fce9fd82d421/images/11111111-1111-1111-1111-111111111111/ubuntu-12.04-dvd-amd64.iso
> -l
> -rwxr-xr-x. 1 vdsm kvm 1666560000 Jun 29 17:49
> /rhev/data-center/af7ddcdd-8c3e-49d1-b885-38daa7f79030/76df39bd-cb52-4783-a5a7-fce9fd82d421/images/11111111-1111-1111-1111-111111111111/ubuntu-12.04-dvd-amd64.iso
>
>
> On 06/29/2012 06:53 PM, Sheldon wrote:
>> I have set up all-in-one. but I use iscsi data center, not NFS  data
>> center.
>> ovirt-engine create an direct Lun disk, but can not create an vm.
>> The status is always "wait for launch". It take a long time, but the
>> status is still "wait for launch"
>>
>> I set up an iscsi server, as follow:
>> # dd if=/dev/zero of=$SCPATH/fs.iscsi.disk2 bs=1M count=15360
>> # dd if=/dev/zero of=$SCPATH/fs.iscsi.disk3 bs=1M count=15360
>> # sudo tgtadm --lld iscsi --op new --mode target --tid 1 -T
>> iqn.2012-02.com.example.data1
>> # sudo tgtadm --lld iscsi --op new  --mode logicalunit --tid 1 --lun 2
>> -b $SCPATH/fs.iscsi.disk2
>> # sudo tgtadm --lld iscsi --op new  --mode logicalunit --tid 1 --lun 3
>> -b $SCPATH/fs.iscsi.disk3
>> # sudo tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL
>>