From deepakcs at linux.vnet.ibm.com Fri Mar 1 07:04:45 2013 From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty) Date: Fri, 01 Mar 2013 12:34:45 +0530 Subject: [Engine-devel] DC Compat Version Vs Storage Format Version Message-ID: <5130530D.6030408@linux.vnet.ibm.com> Hi All, I am seeing an error while testing the WIP engine patches for supporting GLUSTERFS_DOMAIN @ http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:glusterfs,n,z (Copyign Sharad, who is the author for the patch series) Note my VDSM host has VDSM running which has support for GLUSTERFS_DOMAIN (its already upstream in VDSM) I get the below error in GUI while trying to create a new Storage Domain of type Data/GlusterFS *Error: Cannot add Storage. Storage format V3 is not supported on the selected host version." * I cannot change storgae format in the GUI, its fixed at V3 DC is of type GlusterFS and so is cluster, compat version is 3.3 I have few questions ... 1) How are compat version and storage format related ? 2) What does 'host version' in the above error msg mean. It doesn't tell clearly why/what the incompatibility is about 3) What needs to be done in the engine to make this work ? thanx, deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From iheim at redhat.com Fri Mar 1 08:28:51 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 01 Mar 2013 10:28:51 +0200 Subject: [Engine-devel] DC Compat Version Vs Storage Format Version In-Reply-To: <5130530D.6030408@linux.vnet.ibm.com> References: <5130530D.6030408@linux.vnet.ibm.com> Message-ID: <513066C3.9060700@redhat.com> On 01/03/2013 09:04, Deepak C Shetty wrote: > Hi All, > I am seeing an error while testing the WIP engine patches for > supporting GLUSTERFS_DOMAIN @ > > http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:glusterfs,n,z > > (Copyign Sharad, who is the author for the patch series) > Note my VDSM host has VDSM running which has support for > GLUSTERFS_DOMAIN (its already upstream in VDSM) > > I get the below error in GUI while trying to create a new Storage Domain > of type Data/GlusterFS > *Error: Cannot add Storage. Storage format V3 is not supported on the > selected host version." * > > I cannot change storgae format in the GUI, its fixed at V3 > DC is of type GlusterFS and so is cluster, compat version is 3.3 > > I have few questions ... > > 1) How are compat version and storage format related ? storage formats are supported for specific compat version. > > 2) What does 'host version' in the above error msg mean. It doesn't tell > clearly why/what the incompatibility is about host version is probably the supported cluster levels it has. > > 3) What needs to be done in the engine to make this work ? it seems while 3.3 cluster version was added, not all config keys are available for it yet (yair/eli?) for example: backend/manager/dbscripts/upgrade/pre_upgrade/0000_config.sql:select fn_db_add_config_value('SupportedStorageFormats','0,2,3','3.2'); is missing for 3.3 cluster level. Also, specifcially, need to review the logic of this method when adding a new type of storage domain. NFS is V0/V1 for backward compatibility and V3. but GlusterFS should probably only be V3: in AddStorageDomainCommand: private boolean isStorageFormatCompatibleWithDomain() { StorageFormatType storageFormat = getStorageDomain().getStorageFormat(); StorageType storageType = getStorageDomain().getStorageType(); StorageDomainType storageDomainFunction = getStorageDomain().getStorageDomainType(); boolean isBlockStorage = storageType == StorageType.ISCSI || storageType == StorageType.FCP; boolean isDataStorageDomain = storageDomainFunction == StorageDomainType.Data; // V2 is applicable only for block data storage domains if (storageFormat == StorageFormatType.V2 && (!isBlockStorage || !isDataStorageDomain)) { return false; } // V3 is applicable only for data storage domains if (storageFormat == StorageFormatType.V3 && !isDataStorageDomain) { return false; } return true; } From jhernand at redhat.com Fri Mar 1 09:14:15 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Fri, 01 Mar 2013 10:14:15 +0100 Subject: [Engine-devel] Maven 3 Message-ID: <51307167.2040400@redhat.com> I have recently seen several people getting into trouble building because they are using the obsolete maven 2. Please make sure that you use maven 3 for all your builds. -- 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 snmishra at linux.vnet.ibm.com Sun Mar 3 01:34:11 2013 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Sat, 02 Mar 2013 17:34:11 -0800 Subject: [Engine-devel] Missing vfsType from VDSM conList. Message-ID: <20130302173411.Horde.TJJ8w5ir309RMqiTI9JlT6A@imap.linux.ibm.com> Trying to create a new storage domain using a glusterfs data center. The operation is failing because vfsType is not being passed to VDSM. Debugging on engine, I can see that Frontend.runActionImpl() is called with vfsType correctly set but it doesn't seem to reach VDSM. Any clues as to what may be causing this behaviour? When I run the test with posixfs, I see - Thread-169::INFO::2013-03-01 11:11:30,889::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=6, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': 'vm-vdsm-de-1:dpkvol3', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'posixfs', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000'}], options=None) but with glusterfs, I get - Thread-73::INFO::2013-02-27 15:40:57,750::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'vm-vdsm-de-1:dpkvol3', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=None) Notice that vfsType is not passed in second case. This test was run using the upstream + http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:glusterfs,n,z Thanks Sharad Mishra From yzaslavs at redhat.com Sun Mar 3 06:49:33 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 3 Mar 2013 01:49:33 -0500 (EST) Subject: [Engine-devel] Missing vfsType from VDSM conList. In-Reply-To: <20130302173411.Horde.TJJ8w5ir309RMqiTI9JlT6A@imap.linux.ibm.com> Message-ID: <785827068.11485140.1362293373347.JavaMail.root@redhat.com> ----- Original Message ----- > From: snmishra at linux.vnet.ibm.com > To: engine-devel at ovirt.org > Sent: Sunday, March 3, 2013 3:34:11 AM > Subject: [Engine-devel] Missing vfsType from VDSM conList. > > > Trying to create a new storage domain using a glusterfs data center. > The operation is failing because vfsType is not being passed to VDSM. > Debugging on engine, I can see that Frontend.runActionImpl() is > called > with vfsType correctly set but it doesn't seem to reach VDSM. Any > clues as to what may be causing this behaviour? > > When I run the test with posixfs, I see - > Thread-169::INFO::2013-03-01 > 11:11:30,889::logUtils::44::dispatcher::(wrapper) Run and protect: > connectStorageServer(domType=6, > spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', > 'connection': 'vm-vdsm-de-1:dpkvol3', 'iqn': '', 'portal': '', > 'user': > '', 'vfs_type': 'posixfs', 'password': '******', 'id': > '00000000-0000-0000-0000-000000000000'}], options=None) > > but with glusterfs, I get - > Thread-73::INFO::2013-02-27 > 15:40:57,750::logUtils::44::dispatcher::(wrapper) Run and protect: > connectStorageServer(domType=7, > spUUID='00000000-0000-0000-0000-000000000000', > conList=[{'connection': > 'vm-vdsm-de-1:dpkvol3', 'iqn': '', 'portal': '', 'user': '', > 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', > 'port': ''}], options=None) > > > Notice that vfsType is not passed in second case. > > This test was run using the upstream + > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:glusterfs,n,z Hi Sharad, Why doesn't the new Add*StroageDomain* in case of Gluster extends the one of PosixFS? Yair > > Thanks > Sharad Mishra > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mpastern at redhat.com Sun Mar 3 09:44:26 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 03 Mar 2013 11:44:26 +0200 Subject: [Engine-devel] Improvement for the oVirt java sdk In-Reply-To: References: Message-ID: <51331B7A.5020009@redhat.com> Hi Christopher, In general SDK abstracts the transport layer, therefore all authentication internals hidden from the user, i.e SESSION based authentication happens implicitly (by default), when you initiate SDK entry point, the story is different if you want using SSO-like login by reusing JSESSIONID from the REST-API for instance, and i can support such scenario, but, is this your case? On 02/28/2013 10:04 PM, Morrissey, Christopher wrote: > Hi Michael, > > I'm looking to use the oVirt java sdk for connecting into oVirt from our server. However, > we have a UI plugin that gets access to a session ID that we should be able to use to connect through > the REST API instead of the username and password. Any chance the sdk could be updated to take the session > ID and create a connection vs. a user name and password? > > -Chris > > Chris Morrissey > Software Engineer > NetApp Inc. > 919.476.4428 > > -- Michael Pasternak RedHat, ENG-Virtualization R&D From abonas at redhat.com Sun Mar 3 12:59:01 2013 From: abonas at redhat.com (Alissa Bonas) Date: Sun, 3 Mar 2013 07:59:01 -0500 (EST) Subject: [Engine-devel] Missing vfsType from VDSM conList. In-Reply-To: <20130302173411.Horde.TJJ8w5ir309RMqiTI9JlT6A@imap.linux.ibm.com> Message-ID: <1645996106.40451040.1362315541417.JavaMail.root@redhat.com> ----- Original Message ----- > From: snmishra at linux.vnet.ibm.com > To: engine-devel at ovirt.org > Sent: Sunday, March 3, 2013 3:34:11 AM > Subject: [Engine-devel] Missing vfsType from VDSM conList. > > > Trying to create a new storage domain using a glusterfs data center. > The operation is failing because vfsType is not being passed to VDSM. > Debugging on engine, I can see that Frontend.runActionImpl() is > called > with vfsType correctly set but it doesn't seem to reach VDSM. Any > clues as to what may be causing this behaviour? > > When I run the test with posixfs, I see - > Thread-169::INFO::2013-03-01 > 11:11:30,889::logUtils::44::dispatcher::(wrapper) Run and protect: > connectStorageServer(domType=6, > spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', > 'connection': 'vm-vdsm-de-1:dpkvol3', 'iqn': '', 'portal': '', > 'user': > '', 'vfs_type': 'posixfs', 'password': '******', 'id': > '00000000-0000-0000-0000-000000000000'}], options=None) > > but with glusterfs, I get - > Thread-73::INFO::2013-02-27 > 15:40:57,750::logUtils::44::dispatcher::(wrapper) Run and protect: > connectStorageServer(domType=7, > spUUID='00000000-0000-0000-0000-000000000000', > conList=[{'connection': > 'vm-vdsm-de-1:dpkvol3', 'iqn': '', 'portal': '', 'user': '', > 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', > 'port': ''}], options=None) > > > Notice that vfsType is not passed in second case. Hi Sharad, I recommend to check/debug these 2 classes: AddStorageServerConnectionCommand and ConnectStorageServerVDSCommand. Is the missing type arriving to "AddStorageServerConnectionCommand" parameters from UI ? I'd also recommend to put a breakpoint in method CreateStructFromConnection in class ConnectStorageServerVDSCommand . the vfsType is set there before the command is sent to vdsm in an "if" statement, perhaps the condition there is not evaluated to "true", so it doesn't enter the "if" and the vfsType is not set... (look for this line inside the if statement : con.putIfNotEmpty("vfs_type", connection.getVfsType());) > This test was run using the upstream + > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:glusterfs,n,z > > Thanks > Sharad Mishra > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From eedri at redhat.com Sun Mar 3 13:11:55 2013 From: eedri at redhat.com (Eyal Edri) Date: Sun, 3 Mar 2013 08:11:55 -0500 (EST) Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3652 - Still Unstable! In-Reply-To: <396487812.2506.1362315989080.JavaMail.jenkins@jenkins.ovirt.org> Message-ID: <304853338.11725672.1362316315822.JavaMail.root@redhat.com> New patches inserted NORMAL priority find bugs, please review and fix asap: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/changes E. ----- Original Message ----- > From: "Jenkins oVirt Server" > To: eedri at redhat.com, engine-patches at ovirt.org, dcaro at redhat.com, asaf at redhat.com, amureini at redhat.com, > gerrit2 at gerrit.ovirt.org > Sent: Sunday, March 3, 2013 3:06:08 PM > Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3652 - Still Unstable! > > Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/ > Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3652/ > Build Number: 3652 > Build Status: Still Unstable > Triggered By: Started by upstream project "ovirt_engine" build number > 4,474 > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #3647 > [gerrit2] webadmin: get HotPlugEnabled config value synchronously > > [gerrit2] webadmin: get LocalFSPath config value synchronously > > > Changes for Build #3648 > [gerrit2] userportal: ignore the NetworkUser role > > [fkobzik] core: Non-plugin automatic invocation of console session > > [fkobzik] frontend: Non-plugin automatic invocation of console > session > > [ecohen] userportal: fix memory leaks > > [ecohen] userportal: stop basic list provider on extended tab > > [ecohen] userportal: Optimize basic view > > [ecohen] userportal: Optimize extended view VM/Pool grid > > [ecohen] userportal: Optimization fixes > > [ecohen] userportal: fix memory leak when VM selected > > [ecohen] userportal: Set default VM/Pool refresh rate to 30s for IE8 > > [ecohen] userportal: Fix UI update for Basic list item > > > Changes for Build #3649 > [gerrit2] core: Disable unsupported fence agents in UI > > > Changes for Build #3650 > [gerrit2] packaging: Updated psql calls not to ask password > > [amureini] core: Remove fixtures.out.xml > > [amureini] core: Singleton row mappers for EventDAO > > [amureini] core: StorageDoaminSynamic Singleton row mapper > > [amureini] core: StoragePoolDAO single RowMapper > > [amureini] core: Singleton row mapper for StoragePoolIsoMap > > [amureini] core: Singleton row mapper for DiskImageDynamic > > [amureini] core: Singleton row mapper for DiskLunMap > > [amureini] core: final RowMapper for ImageStorageDomainMaoDao > > [amureini] core: Singleton row mapper for VdcOption > > [amureini] core: Use VdsRowMapper static instance > > [amureini] core: Singleton row mapper for VdsDynamic > > [amureini] core: Singleton row mapper for VdsStatistics > > > Changes for Build #3651 > > Changes for Build #3652 > [nslomian] webadmin: add isCancel to command in quota > > [gerrit2] core:Upgrade from 3.1 to 3.2 fails > > [gerrit2] core: change shared-lock msg of AddVmFromTemplate > > [amureini] core: ImagesHandler: filterImageDisks readability > > [amureini] core: ImageHandlerTest - add missing annotation > > > > > ----------------- > Failed Tests: > ----------------- > No tests ran. > > ------------------ > Build Log: > ------------------ > [...truncated 36768 lines...] > [java] Warnings generated: 12 > [INFO] Done FindBugs Analysis.... > [INFO] > [INFO] > ------------------------------------------------------------------------ > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT > [INFO] > ------------------------------------------------------------------------ > [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is > missing, no dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin > org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies > could not be resolved: Failed to read artifact descriptor for > org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 > [INFO] > [INFO] --- maven-ear-plugin:2.8:generate-application-xml > (default-generate-application-xml) @ engine-server-ear --- > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.pom > 4 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.pom > (4 KB at 27.3 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/3.0.2/plexus-utils-3.0.2.pom > 3 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/3.0.2/plexus-utils-3.0.2.pom > (3 KB at 59.8 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/3.1/plexus-3.1.pom > 4 KB > 8 KB > 12 KB > 15 KB > 19 KB > 19 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/3.1/plexus-3.1.pom > (19 KB at 586.4 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.pom > 2 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.pom > (2 KB at 188.0 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.jar > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.jar > 4 KB > 8 KB > 12 KB > 15 KB > 19 KB > 23 KB > 27 KB > 31 KB > 35 KB > 39 KB > 43 KB > 43 KB > 47 KB > 50 KB > 54 KB > 57 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.jar > (57 KB at 2995.4 KB/sec) > 4 KB > 8 KB > 12 KB > 16 KB > 19 KB > 23 KB > 23 KB > 27 KB > 31 KB > 35 KB > 39 KB > 40 KB > 44 KB > 44 KB > 48 KB > 52 KB > 56 KB > 60 KB > 64 KB > 67 KB > 71 KB > 75 KB > 76 KB > 80 KB > 82 KB > 86 KB > 90 KB > 94 KB > 98 KB > 102 KB > 104 KB > 108 KB > 112 KB > 116 KB > 120 KB > 124 KB > 128 KB > 132 KB > 136 KB > 140 KB > 144 KB > 148 KB > 152 KB > 156 KB > 160 KB > 164 KB > 168 KB > 172 KB > 176 KB > 180 KB > 181 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.jar > (181 KB at 1298.7 KB/sec) > [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.8:ear (default-ear) @ engine-server-ear > --- > [INFO] Copying artifact > [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] to [root.war] > (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to > [restapi.war] (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] to > [userportal.war] (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to [webadmin.war] > (unpacked) > [INFO] Copying artifact > [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] to > [scheduler.jar] > [INFO] Copying artifact > [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to [bll.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] to > [lib/vdsbroker.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to > [lib/compat.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to > [lib/common.jar] > [INFO] Copying artifact > [jar:org.hibernate:hibernate-validator:4.0.2.GA] to > [lib/hibernate-validator.jar] > [INFO] Copying artifact > [jar:javax.validation:validation-api:1.0.0.GA] to > [lib/validation-api.jar] > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to > [lib/jaxb-api.jar] > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to > [lib/stax-api.jar] > [INFO] Copying artifact [jar:javax.activation:activation:1.1] to > [lib/activation.jar] > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to > [lib/jaxb-impl.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to [lib/utils.jar] > [INFO] Copying artifact > [jar:commons-beanutils:commons-beanutils:1.8.2] to > [lib/commons-beanutils.jar] > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to > [lib/mina-core.jar] > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to > [lib/sshd-core.jar] > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to > [lib/otopi.jar] > [INFO] Copying artifact > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to > [lib/ovirt-host-deploy.jar] > [INFO] Copying artifact > [jar:org.apache.commons:commons-compress:1.4.1] to > [lib/commons-compress.jar] > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to > [lib/commons-lang.jar] > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to > [lib/commons-codec.jar] > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] > to [lib/xmlrpc-client.jar] > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] > to [lib/xmlrpc-common.jar] > [INFO] Copying artifact > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to > [lib/ws-commons-util.jar] > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to > [lib/xml-apis.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to [lib/dal.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] to > [lib/spring-jdbc.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-tx:3.1.1.RELEASE] to > [lib/spring-tx.jar] > [INFO] Copying artifact > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to > [lib/spring-ldap-core.jar] > [INFO] Copying artifact > [jar:commons-httpclient:commons-httpclient:3.1] to > [lib/commons-httpclient.jar] > [INFO] Copying artifact > [jar:commons-collections:commons-collections:3.1] to > [lib/commons-collections.jar] > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to > [lib/quartz.jar] > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to > [lib/slf4j-api.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to > [lib/searchbackend.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.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-core:3.1.1.RELEASE] to > [lib/spring-core.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-asm:3.1.1.RELEASE] to > [lib/spring-asm.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-beans:3.1.1.RELEASE] to > [lib/spring-beans.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-context:3.1.1.RELEASE] to > [lib/spring-context.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-aop:3.1.1.RELEASE] to > [lib/spring-aop.jar] > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to > [lib/aopalliance.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to > [lib/spring-expression.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-install-plugin:2.3.1:install (default-install) @ > engine-server-ear --- > [INFO] Installing > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine.ear to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > [INFO] Installing /ephemeral0/ovirt_engine_find_bugs/ear/pom.xml to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > [INFO] > [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @ > engine-server-ear --- > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] ovirt-root ........................................ SUCCESS > [12.875s] > [INFO] oVirt Build Tools root ............................ SUCCESS > [0.064s] > [INFO] oVirt checkstyle .................................. SUCCESS > [4.433s] > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS > [30.118s] > [INFO] oVirt Checkstyle Checks ........................... SUCCESS > [17.939s] > [INFO] oVirt Modules - backend ........................... SUCCESS > [0.032s] > [INFO] oVirt Manager ..................................... SUCCESS > [0.038s] > [INFO] oVirt DB Scripts .................................. SUCCESS > [0.598s] > [INFO] oVirt Engine dependencies ......................... SUCCESS > [4.554s] > [INFO] oVirt Modules - manager ........................... SUCCESS > [1.063s] > [INFO] CSharp Compatibility .............................. SUCCESS > [28.914s] > [INFO] Common Code ....................................... SUCCESS > [1:23.325s] > [INFO] Common utilities .................................. SUCCESS > [53.754s] > [INFO] Data Access Layer ................................. SUCCESS > [1:01.992s] > [INFO] engine beans ...................................... SUCCESS > [0.150s] > [INFO] engine scheduler bean ............................. SUCCESS > [20.642s] > [INFO] Vds broker ........................................ SUCCESS > [1:10.185s] > [INFO] Search Backend .................................... SUCCESS > [33.750s] > [INFO] Backend Logic @Service bean ....................... SUCCESS > [2:02.847s] > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS > [6.359s] > [INFO] oVirt RESTful API interface ....................... SUCCESS > [0.116s] > [INFO] oVirt Engine API Definition ....................... SUCCESS > [1:06.571s] > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS > [0.173s] > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS > [31.871s] > [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS > [38.586s] > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources > SUCCESS [1:09.994s] > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS > [0.934s] > [INFO] oVirt Engine Web Root ............................. SUCCESS > [21.532s] > [INFO] oVirt Engine Tools ................................ SUCCESS > [38.078s] > [INFO] oVirt Modules :: Frontend ......................... SUCCESS > [0.029s] > [INFO] oVirt Modules :: Webadmin ......................... SUCCESS > [0.024s] > [INFO] oVirt Modules - ui ................................ SUCCESS > [0.292s] > [INFO] Extensions for GWT ................................ SUCCESS > [21.585s] > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS > [27.833s] > [INFO] Frontend for GWT UI Projects ...................... SUCCESS > [30.205s] > [INFO] UICommonWeb ....................................... SUCCESS > [1:57.923s] > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS > [1:24.085s] > [INFO] WebAdmin .......................................... SUCCESS > [1:39.023s] > [INFO] UserPortal ........................................ SUCCESS > [49.974s] > [INFO] oVirt Server EAR .................................. SUCCESS > [2.999s] > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 21:01.931s > [INFO] Finished at: Sun Mar 03 08:06:13 EST 2013 > [INFO] Final Memory: 238M/779M > [INFO] > ------------------------------------------------------------------------ > [FINDBUGS] Collecting findbugs analysis files... > [FINDBUGS] Finding all files that match the pattern > **/findbugsXml.xml > [FINDBUGS] Parsing 23 files in > /home/jenkins/workspace/ovirt_engine_find_bugs > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/scheduler/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/bll/target/findbugsXml.xml > of module with 251 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/common/target/findbugsXml.xml > of module with 245 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/compat/target/findbugsXml.xml > of module with 25 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/dal/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml > of module with 15 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml > of module with 28 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/types/target/findbugsXml.xml > of module with 13 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/root/target/findbugsXml.xml > of module with 3 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/searchbackend/target/findbugsXml.xml > of module with 11 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/utils/target/findbugsXml.xml > of module with 71 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/vdsbroker/target/findbugsXml.xml > of module with 230 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/target/findbugsXml.xml > of module with 30 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/build-tools-root/jboss-modules-maven-plugin/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/build-tools-root/ovirt-checkstyle-extension/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/frontend/target/findbugsXml.xml > of module with 38 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml > of module with 84 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommonweb/target/findbugsXml.xml > of module with 649 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicompat/target/findbugsXml.xml > of module with 50 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/webadmin/target/findbugsXml.xml > of module with 68 warnings. > [FINDBUGS] Computing warning deltas based on reference build #3646 > Build step 'Publish FindBugs analysis results' changed build result > to UNSTABLE > IRC notifier plugin: Sending notification to: #ovirt-jenkins > Email was triggered for: Unstable > Sending email for trigger: Unstable > From eedri at redhat.com Sun Mar 3 17:14:23 2013 From: eedri at redhat.com (Eyal Edri) Date: Sun, 3 Mar 2013 12:14:23 -0500 (EST) Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3653 - Still Unstable! In-Reply-To: <1828011055.2521.1362322674475.JavaMail.jenkins@jenkins.ovirt.org> Message-ID: <1863763565.11754056.1362330863863.JavaMail.root@redhat.com> the following is the 2 new bugs added by the followings commits: http://jenkins.ovirt.org/view/00%20-%20Unstable%20Jobs/job/ovirt_engine_find_bugs/3648/findbugsResult/new/NORMAL/category.-675839583/ http://jenkins.ovirt.org/view/00%20-%20Unstable%20Jobs/job/ovirt_engine_find_bugs/3648/findbugsResult/new/NORMAL/category.1731749696/ looks like cause by the following commit: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git&a=commit&h=ecdfea9300cc27081203fde5c6b2dcff6665a3d4 other commits in the same build: userportal: ignore the NetworkUser role (detail / gitweb) core: Non-plugin automatic invocation of console session (detail / gitweb) frontend: Non-plugin automatic invocation of console session (detail / gitweb) userportal: fix memory leaks (detail / gitweb) userportal: stop basic list provider on extended tab (detail / gitweb) userportal: Optimize basic view (detail / gitweb) userportal: Optimize extended view VM/Pool grid (detail / gitweb) userportal: Optimization fixes (detail / gitweb) userportal: fix memory leak when VM selected (detail / gitweb) userportal: Set default VM/Pool refresh rate to 30s for IE8 (detail / gitweb) userportal: Fix UI update for Basic list item (detail / gitweb) ----- Original Message ----- > From: "Jenkins oVirt Server" > To: eedri at redhat.com, engine-patches at ovirt.org, dcaro at redhat.com, asaf at redhat.com, oourfali at redhat.com > Sent: Sunday, March 3, 2013 4:57:54 PM > Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3653 - Still Unstable! > > Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/ > Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3653/ > Build Number: 3653 > Build Status: Still Unstable > Triggered By: Started by upstream project "ovirt_engine" build number > 4,475 > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #3647 > [gerrit2] webadmin: get HotPlugEnabled config value synchronously > > [gerrit2] webadmin: get LocalFSPath config value synchronously > > > Changes for Build #3648 > [gerrit2] userportal: ignore the NetworkUser role > > [fkobzik] core: Non-plugin automatic invocation of console session > > [fkobzik] frontend: Non-plugin automatic invocation of console > session > > [ecohen] userportal: fix memory leaks > > [ecohen] userportal: stop basic list provider on extended tab > > [ecohen] userportal: Optimize basic view > > [ecohen] userportal: Optimize extended view VM/Pool grid > > [ecohen] userportal: Optimization fixes > > [ecohen] userportal: fix memory leak when VM selected > > [ecohen] userportal: Set default VM/Pool refresh rate to 30s for IE8 > > [ecohen] userportal: Fix UI update for Basic list item > > > Changes for Build #3649 > [gerrit2] core: Disable unsupported fence agents in UI > > > Changes for Build #3650 > [gerrit2] packaging: Updated psql calls not to ask password > > [amureini] core: Remove fixtures.out.xml > > [amureini] core: Singleton row mappers for EventDAO > > [amureini] core: StorageDoaminSynamic Singleton row mapper > > [amureini] core: StoragePoolDAO single RowMapper > > [amureini] core: Singleton row mapper for StoragePoolIsoMap > > [amureini] core: Singleton row mapper for DiskImageDynamic > > [amureini] core: Singleton row mapper for DiskLunMap > > [amureini] core: final RowMapper for ImageStorageDomainMaoDao > > [amureini] core: Singleton row mapper for VdcOption > > [amureini] core: Use VdsRowMapper static instance > > [amureini] core: Singleton row mapper for VdsDynamic > > [amureini] core: Singleton row mapper for VdsStatistics > > > Changes for Build #3651 > > Changes for Build #3652 > [nslomian] webadmin: add isCancel to command in quota > > [gerrit2] core:Upgrade from 3.1 to 3.2 fails > > [gerrit2] core: change shared-lock msg of AddVmFromTemplate > > [amureini] core: ImagesHandler: filterImageDisks readability > > [amureini] core: ImageHandlerTest - add missing annotation > > > Changes for Build #3653 > [oourfali] rest: after creating a REST session request without Prefer > returns 401 > > > > > ----------------- > Failed Tests: > ----------------- > No tests ran. > > ------------------ > Build Log: > ------------------ > [...truncated 36666 lines...] > [INFO] Installing > /ephemeral0/ovirt_engine_find_bugs/frontend/webadmin/modules/userportal-gwtp/pom.xml > to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/ui/userportal/3.3.0-SNAPSHOT/userportal-3.3.0-SNAPSHOT.pom > [INFO] > [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @ > userportal --- > [INFO] Fork Value is true > [java] Warnings generated: 12 > [INFO] Done FindBugs Analysis.... > [INFO] > [INFO] > ------------------------------------------------------------------------ > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT > [INFO] > ------------------------------------------------------------------------ > [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is > missing, no dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin > org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies > could not be resolved: Failed to read artifact descriptor for > org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 > [INFO] > [INFO] --- maven-ear-plugin:2.8:generate-application-xml > (default-generate-application-xml) @ engine-server-ear --- > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.pom > 4 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.pom > (4 KB at 39.2 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/3.0.2/plexus-utils-3.0.2.pom > 3 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/3.0.2/plexus-utils-3.0.2.pom > (3 KB at 129.1 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/3.1/plexus-3.1.pom > 4 KB > 8 KB > 12 KB > 15 KB > 19 KB > 19 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/3.1/plexus-3.1.pom > (19 KB at 1652.6 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.pom > 2 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.pom > (2 KB at 211.5 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.jar > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.jar > 4 KB > 8 KB > 12 KB > 16 KB > 19 KB > 23 KB > 27 KB > 31 KB > 4 KB 31 KB > 4 KB 35 KB > 4 KB 39 KB > 4 KB 43 KB > 8 KB 43 KB > 8 KB 44 KB > 8 KB 48 KB > 8 KB 49 KB > 8 KB 53 KB > 8 KB 57 KB > 8 KB 61 KB > 8 KB 63 KB > 12 KB 63 KB > 16 KB 63 KB > 20 KB 63 KB > 24 KB 63 KB > 28 KB 63 KB > 32 KB 63 KB > 36 KB 63 KB > 40 KB 63 KB > 44 KB 63 KB > 48 KB 63 KB > 52 KB 63 KB > 56 KB 63 KB > 57 KB 63 KB > 57 KB 67 KB > 57 KB 71 KB > 57 KB 75 KB > 57 KB 79 KB > 57 KB 83 KB > 57 KB 87 KB > 57 KB 91 KB > 57 KB 95 KB > 57 KB 99 KB > 57 KB 103 KB > 57 KB 107 KB > 57 KB 111 KB > 57 KB 115 KB > 57 KB 119 KB > 57 KB 123 KB > 57 KB 127 KB > 57 KB 131 KB > 57 KB 135 KB > 57 KB 139 KB > 57 KB 143 KB > 57 KB 147 KB > 57 KB 151 KB > 57 KB 155 KB > 57 KB 159 KB > 57 KB 163 KB > 57 KB 167 KB > 57 KB 171 KB > > 175 KB > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.jar > (57 KB at 2107.9 KB/sec) > 179 KB > 181 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.jar > (181 KB at 5641.4 KB/sec) > [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.8:ear (default-ear) @ engine-server-ear > --- > [INFO] Copying artifact > [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] to [root.war] > (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to > [restapi.war] (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] to > [userportal.war] (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to [webadmin.war] > (unpacked) > [INFO] Copying artifact > [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] to > [scheduler.jar] > [INFO] Copying artifact > [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to [bll.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] to > [lib/vdsbroker.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to > [lib/compat.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to > [lib/common.jar] > [INFO] Copying artifact > [jar:org.hibernate:hibernate-validator:4.0.2.GA] to > [lib/hibernate-validator.jar] > [INFO] Copying artifact > [jar:javax.validation:validation-api:1.0.0.GA] to > [lib/validation-api.jar] > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to > [lib/jaxb-api.jar] > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to > [lib/stax-api.jar] > [INFO] Copying artifact [jar:javax.activation:activation:1.1] to > [lib/activation.jar] > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to > [lib/jaxb-impl.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to [lib/utils.jar] > [INFO] Copying artifact > [jar:commons-beanutils:commons-beanutils:1.8.2] to > [lib/commons-beanutils.jar] > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to > [lib/mina-core.jar] > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to > [lib/sshd-core.jar] > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to > [lib/otopi.jar] > [INFO] Copying artifact > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to > [lib/ovirt-host-deploy.jar] > [INFO] Copying artifact > [jar:org.apache.commons:commons-compress:1.4.1] to > [lib/commons-compress.jar] > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to > [lib/commons-lang.jar] > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to > [lib/commons-codec.jar] > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] > to [lib/xmlrpc-client.jar] > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] > to [lib/xmlrpc-common.jar] > [INFO] Copying artifact > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to > [lib/ws-commons-util.jar] > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to > [lib/xml-apis.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to [lib/dal.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] to > [lib/spring-jdbc.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-tx:3.1.1.RELEASE] to > [lib/spring-tx.jar] > [INFO] Copying artifact > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to > [lib/spring-ldap-core.jar] > [INFO] Copying artifact > [jar:commons-httpclient:commons-httpclient:3.1] to > [lib/commons-httpclient.jar] > [INFO] Copying artifact > [jar:commons-collections:commons-collections:3.1] to > [lib/commons-collections.jar] > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to > [lib/quartz.jar] > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to > [lib/slf4j-api.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to > [lib/searchbackend.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.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-core:3.1.1.RELEASE] to > [lib/spring-core.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-asm:3.1.1.RELEASE] to > [lib/spring-asm.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-beans:3.1.1.RELEASE] to > [lib/spring-beans.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-context:3.1.1.RELEASE] to > [lib/spring-context.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-aop:3.1.1.RELEASE] to > [lib/spring-aop.jar] > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to > [lib/aopalliance.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to > [lib/spring-expression.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-install-plugin:2.3.1:install (default-install) @ > engine-server-ear --- > [INFO] Installing > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine.ear to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > [INFO] Installing /ephemeral0/ovirt_engine_find_bugs/ear/pom.xml to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > [INFO] > [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @ > engine-server-ear --- > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] ovirt-root ........................................ SUCCESS > [13.128s] > [INFO] oVirt Build Tools root ............................ SUCCESS > [0.118s] > [INFO] oVirt checkstyle .................................. SUCCESS > [4.284s] > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS > [39.292s] > [INFO] oVirt Checkstyle Checks ........................... SUCCESS > [24.694s] > [INFO] oVirt Modules - backend ........................... SUCCESS > [0.071s] > [INFO] oVirt Manager ..................................... SUCCESS > [0.081s] > [INFO] oVirt DB Scripts .................................. SUCCESS > [0.814s] > [INFO] oVirt Engine dependencies ......................... SUCCESS > [5.528s] > [INFO] oVirt Modules - manager ........................... SUCCESS > [1.803s] > [INFO] CSharp Compatibility .............................. SUCCESS > [48.046s] > [INFO] Common Code ....................................... SUCCESS > [2:20.376s] > [INFO] Common utilities .................................. SUCCESS > [1:36.684s] > [INFO] Data Access Layer ................................. SUCCESS > [1:44.820s] > [INFO] engine beans ...................................... SUCCESS > [0.191s] > [INFO] engine scheduler bean ............................. SUCCESS > [33.861s] > [INFO] Vds broker ........................................ SUCCESS > [2:04.436s] > [INFO] Search Backend .................................... SUCCESS > [59.575s] > [INFO] Backend Logic @Service bean ....................... SUCCESS > [3:00.927s] > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS > [8.322s] > [INFO] oVirt RESTful API interface ....................... SUCCESS > [0.183s] > [INFO] oVirt Engine API Definition ....................... SUCCESS > [1:31.456s] > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS > [0.438s] > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS > [49.339s] > [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS > [55.814s] > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources > SUCCESS [1:22.295s] > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS > [1.090s] > [INFO] oVirt Engine Web Root ............................. SUCCESS > [22.632s] > [INFO] oVirt Engine Tools ................................ SUCCESS > [37.699s] > [INFO] oVirt Modules :: Frontend ......................... SUCCESS > [0.029s] > [INFO] oVirt Modules :: Webadmin ......................... SUCCESS > [0.028s] > [INFO] oVirt Modules - ui ................................ SUCCESS > [0.358s] > [INFO] Extensions for GWT ................................ SUCCESS > [22.230s] > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS > [25.679s] > [INFO] Frontend for GWT UI Projects ...................... SUCCESS > [30.625s] > [INFO] UICommonWeb ....................................... SUCCESS > [1:55.468s] > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS > [1:20.778s] > [INFO] WebAdmin .......................................... SUCCESS > [1:40.544s] > [INFO] UserPortal ........................................ SUCCESS > [51.397s] > [INFO] oVirt Server EAR .................................. SUCCESS > [2.959s] > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 27:47.913s > [INFO] Finished at: Sun Mar 03 09:58:00 EST 2013 > [INFO] Final Memory: 215M/726M > [INFO] > ------------------------------------------------------------------------ > [FINDBUGS] Collecting findbugs analysis files... > [FINDBUGS] Finding all files that match the pattern > **/findbugsXml.xml > [FINDBUGS] Parsing 23 files in > /home/jenkins/workspace/ovirt_engine_find_bugs > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/scheduler/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/bll/target/findbugsXml.xml > of module with 251 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/common/target/findbugsXml.xml > of module with 245 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/compat/target/findbugsXml.xml > of module with 25 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/dal/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml > of module with 15 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml > of module with 28 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/types/target/findbugsXml.xml > of module with 13 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/root/target/findbugsXml.xml > of module with 3 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/searchbackend/target/findbugsXml.xml > of module with 11 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/utils/target/findbugsXml.xml > of module with 71 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/vdsbroker/target/findbugsXml.xml > of module with 230 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/target/findbugsXml.xml > of module with 30 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/build-tools-root/jboss-modules-maven-plugin/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/build-tools-root/ovirt-checkstyle-extension/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/frontend/target/findbugsXml.xml > of module with 38 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml > of module with 84 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommonweb/target/findbugsXml.xml > of module with 649 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicompat/target/findbugsXml.xml > of module with 50 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/webadmin/target/findbugsXml.xml > of module with 68 warnings. > [FINDBUGS] Computing warning deltas based on reference build #3646 > Build step 'Publish FindBugs analysis results' changed build result > to UNSTABLE > IRC notifier plugin: Sending notification to: #ovirt-jenkins > Email was triggered for: Unstable > Sending email for trigger: Unstable > From ecohen at redhat.com Sun Mar 3 17:48:00 2013 From: ecohen at redhat.com (Einav Cohen) Date: Sun, 3 Mar 2013 12:48:00 -0500 (EST) Subject: [Engine-devel] "find bugs" - please solve the following In-Reply-To: <304853338.11725672.1362316315822.JavaMail.root@redhat.com> Message-ID: <1989460029.13408978.1362332880266.JavaMail.root@redhat.com> @Vojtech: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.-1256403867/source.1011/#436 warning introduced by the "Resizable Table Columns" commit [http://gerrit.ovirt.org/#/c/5243/] @Kublin: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.1463187495/source.486/#24 last update of relevant line was in "Fixing possible ConcurrentModificationException" commit [http://gerrit.ovirt.org/#/c/8436] @Frantisek: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.1591650016/category.-675839583/source.580/#43 http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.1591650016/category.1731749696/source.579/#22 file introduced in "Non-plugin automatic invocation of console session" [http://gerrit.ovirt.org/#/c/11702/] @Libor: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.742587459/source.1588/#176 last update of relevant line was in " webadmin,userportal: Show data centers and their clusters based on configured cluster service" [http://gerrit.ovirt.org/#/c/11395] ----- Forwarded Message ----- From: "Eyal Edri" To: engine-patches at ovirt.org, "engine-devel" Cc: dcaro at redhat.com Sent: Sunday, March 3, 2013 8:11:55 AM Subject: Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3652 - Still Unstable! New patches inserted NORMAL priority find bugs, please review and fix asap: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/changes E. ----- Original Message ----- > From: "Jenkins oVirt Server" > To: eedri at redhat.com, engine-patches at ovirt.org, dcaro at redhat.com, asaf at redhat.com, amureini at redhat.com, > gerrit2 at gerrit.ovirt.org > Sent: Sunday, March 3, 2013 3:06:08 PM > Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3652 - Still Unstable! > > Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/ > Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3652/ > Build Number: 3652 > Build Status: Still Unstable > Triggered By: Started by upstream project "ovirt_engine" build number > 4,474 > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #3647 > [gerrit2] webadmin: get HotPlugEnabled config value synchronously > > [gerrit2] webadmin: get LocalFSPath config value synchronously > > > Changes for Build #3648 > [gerrit2] userportal: ignore the NetworkUser role > > [fkobzik] core: Non-plugin automatic invocation of console session > > [fkobzik] frontend: Non-plugin automatic invocation of console > session > > [ecohen] userportal: fix memory leaks > > [ecohen] userportal: stop basic list provider on extended tab > > [ecohen] userportal: Optimize basic view > > [ecohen] userportal: Optimize extended view VM/Pool grid > > [ecohen] userportal: Optimization fixes > > [ecohen] userportal: fix memory leak when VM selected > > [ecohen] userportal: Set default VM/Pool refresh rate to 30s for IE8 > > [ecohen] userportal: Fix UI update for Basic list item > > > Changes for Build #3649 > [gerrit2] core: Disable unsupported fence agents in UI > > > Changes for Build #3650 > [gerrit2] packaging: Updated psql calls not to ask password > > [amureini] core: Remove fixtures.out.xml > > [amureini] core: Singleton row mappers for EventDAO > > [amureini] core: StorageDoaminSynamic Singleton row mapper > > [amureini] core: StoragePoolDAO single RowMapper > > [amureini] core: Singleton row mapper for StoragePoolIsoMap > > [amureini] core: Singleton row mapper for DiskImageDynamic > > [amureini] core: Singleton row mapper for DiskLunMap > > [amureini] core: final RowMapper for ImageStorageDomainMaoDao > > [amureini] core: Singleton row mapper for VdcOption > > [amureini] core: Use VdsRowMapper static instance > > [amureini] core: Singleton row mapper for VdsDynamic > > [amureini] core: Singleton row mapper for VdsStatistics > > > Changes for Build #3651 > > Changes for Build #3652 > [nslomian] webadmin: add isCancel to command in quota > > [gerrit2] core:Upgrade from 3.1 to 3.2 fails > > [gerrit2] core: change shared-lock msg of AddVmFromTemplate > > [amureini] core: ImagesHandler: filterImageDisks readability > > [amureini] core: ImageHandlerTest - add missing annotation > > > > > ----------------- > Failed Tests: > ----------------- > No tests ran. > > ------------------ > Build Log: > ------------------ > [...truncated 36768 lines...] > [java] Warnings generated: 12 > [INFO] Done FindBugs Analysis.... > [INFO] > [INFO] > ------------------------------------------------------------------------ > [INFO] Building oVirt Server EAR 3.3.0-SNAPSHOT > [INFO] > ------------------------------------------------------------------------ > [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is > missing, no dependency information available > [WARNING] Failed to retrieve plugin descriptor for > org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin > org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies > could not be resolved: Failed to read artifact descriptor for > org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 > [INFO] > [INFO] --- maven-ear-plugin:2.8:generate-application-xml > (default-generate-application-xml) @ engine-server-ear --- > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.pom > 4 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.pom > (4 KB at 27.3 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/3.0.2/plexus-utils-3.0.2.pom > 3 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/3.0.2/plexus-utils-3.0.2.pom > (3 KB at 59.8 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/3.1/plexus-3.1.pom > 4 KB > 8 KB > 12 KB > 15 KB > 19 KB > 19 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus/3.1/plexus-3.1.pom > (19 KB at 586.4 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.pom > 2 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.pom > (2 KB at 188.0 KB/sec) > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.jar > Downloading: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.jar > 4 KB > 8 KB > 12 KB > 15 KB > 19 KB > 23 KB > 27 KB > 31 KB > 35 KB > 39 KB > 43 KB > 43 KB > 47 KB > 50 KB > 54 KB > 57 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/2.0.4/plexus-io-2.0.4.jar > (57 KB at 2995.4 KB/sec) > 4 KB > 8 KB > 12 KB > 16 KB > 19 KB > 23 KB > 23 KB > 27 KB > 31 KB > 35 KB > 39 KB > 40 KB > 44 KB > 44 KB > 48 KB > 52 KB > 56 KB > 60 KB > 64 KB > 67 KB > 71 KB > 75 KB > 76 KB > 80 KB > 82 KB > 86 KB > 90 KB > 94 KB > 98 KB > 102 KB > 104 KB > 108 KB > 112 KB > 116 KB > 120 KB > 124 KB > 128 KB > 132 KB > 136 KB > 140 KB > 144 KB > 148 KB > 152 KB > 156 KB > 160 KB > 164 KB > 168 KB > 172 KB > 176 KB > 180 KB > 181 KB > > Downloaded: > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/2.1.2/plexus-archiver-2.1.2.jar > (181 KB at 1298.7 KB/sec) > [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.8:ear (default-ear) @ engine-server-ear > --- > [INFO] Copying artifact > [war:org.ovirt.engine.core:root-war:3.3.0-SNAPSHOT] to [root.war] > (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.api:restapi-webapp:3.3.0-SNAPSHOT] to > [restapi.war] (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.ui:userportal:3.3.0-SNAPSHOT] to > [userportal.war] (unpacked) > [INFO] Copying artifact > [war:org.ovirt.engine.ui:webadmin:3.3.0-SNAPSHOT] to [webadmin.war] > (unpacked) > [INFO] Copying artifact > [ejb:org.ovirt.engine.core:scheduler:3.3.0-SNAPSHOT] to > [scheduler.jar] > [INFO] Copying artifact > [ejb:org.ovirt.engine.core:bll:3.3.0-SNAPSHOT] to [bll.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:vdsbroker:3.3.0-SNAPSHOT] to > [lib/vdsbroker.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:compat:3.3.0-SNAPSHOT] to > [lib/compat.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:common:3.3.0-SNAPSHOT] to > [lib/common.jar] > [INFO] Copying artifact > [jar:org.hibernate:hibernate-validator:4.0.2.GA] to > [lib/hibernate-validator.jar] > [INFO] Copying artifact > [jar:javax.validation:validation-api:1.0.0.GA] to > [lib/validation-api.jar] > [INFO] Copying artifact [jar:javax.xml.bind:jaxb-api:2.1] to > [lib/jaxb-api.jar] > [INFO] Copying artifact [jar:javax.xml.stream:stax-api:1.0-2] to > [lib/stax-api.jar] > [INFO] Copying artifact [jar:javax.activation:activation:1.1] to > [lib/activation.jar] > [INFO] Copying artifact [jar:com.sun.xml.bind:jaxb-impl:2.1.3] to > [lib/jaxb-impl.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:utils:3.3.0-SNAPSHOT] to [lib/utils.jar] > [INFO] Copying artifact > [jar:commons-beanutils:commons-beanutils:1.8.2] to > [lib/commons-beanutils.jar] > [INFO] Copying artifact [jar:org.apache.mina:mina-core:2.0.1] to > [lib/mina-core.jar] > [INFO] Copying artifact [jar:org.apache.sshd:sshd-core:0.7.0] to > [lib/sshd-core.jar] > [INFO] Copying artifact [jar:org.ovirt.otopi:otopi:1.0.0] to > [lib/otopi.jar] > [INFO] Copying artifact > [jar:org.ovirt.ovirt-host-deploy:ovirt-host-deploy:1.0.0] to > [lib/ovirt-host-deploy.jar] > [INFO] Copying artifact > [jar:org.apache.commons:commons-compress:1.4.1] to > [lib/commons-compress.jar] > [INFO] Copying artifact [jar:org.tukaani:xz:1.0] to [lib/xz.jar] > [INFO] Copying artifact [jar:commons-lang:commons-lang:2.6] to > [lib/commons-lang.jar] > [INFO] Copying artifact [jar:commons-codec:commons-codec:1.4] to > [lib/commons-codec.jar] > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-client:3.1.3] > to [lib/xmlrpc-client.jar] > [INFO] Copying artifact [jar:org.apache.xmlrpc:xmlrpc-common:3.1.3] > to [lib/xmlrpc-common.jar] > [INFO] Copying artifact > [jar:org.apache.ws.commons.util:ws-commons-util:1.0.2] to > [lib/ws-commons-util.jar] > [INFO] Copying artifact [jar:xml-apis:xml-apis:1.0.b2] to > [lib/xml-apis.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:dal:3.3.0-SNAPSHOT] to [lib/dal.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-jdbc:3.1.1.RELEASE] to > [lib/spring-jdbc.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-tx:3.1.1.RELEASE] to > [lib/spring-tx.jar] > [INFO] Copying artifact > [jar:org.springframework.ldap:spring-ldap-core:1.3.1.RELEASE] to > [lib/spring-ldap-core.jar] > [INFO] Copying artifact > [jar:commons-httpclient:commons-httpclient:3.1] to > [lib/commons-httpclient.jar] > [INFO] Copying artifact > [jar:commons-collections:commons-collections:3.1] to > [lib/commons-collections.jar] > [INFO] Copying artifact [jar:org.quartz-scheduler:quartz:2.1.2] to > [lib/quartz.jar] > [INFO] Copying artifact [jar:c3p0:c3p0:0.9.1.1] to [lib/c3p0.jar] > [INFO] Copying artifact [jar:org.slf4j:slf4j-api:1.6.1] to > [lib/slf4j-api.jar] > [INFO] Copying artifact > [jar:org.ovirt.engine.core:searchbackend:3.3.0-SNAPSHOT] to > [lib/searchbackend.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.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-core:3.1.1.RELEASE] to > [lib/spring-core.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-asm:3.1.1.RELEASE] to > [lib/spring-asm.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-beans:3.1.1.RELEASE] to > [lib/spring-beans.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-context:3.1.1.RELEASE] to > [lib/spring-context.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-aop:3.1.1.RELEASE] to > [lib/spring-aop.jar] > [INFO] Copying artifact [jar:aopalliance:aopalliance:1.0] to > [lib/aopalliance.jar] > [INFO] Copying artifact > [jar:org.springframework:spring-expression:3.1.1.RELEASE] to > [lib/spring-expression.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-install-plugin:2.3.1:install (default-install) @ > engine-server-ear --- > [INFO] Installing > /ephemeral0/ovirt_engine_find_bugs/ear/target/engine.ear to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > [INFO] Installing /ephemeral0/ovirt_engine_find_bugs/ear/pom.xml to > /home/jenkins/workspace/ovirt_engine_find_bugs/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > [INFO] > [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @ > engine-server-ear --- > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] ovirt-root ........................................ SUCCESS > [12.875s] > [INFO] oVirt Build Tools root ............................ SUCCESS > [0.064s] > [INFO] oVirt checkstyle .................................. SUCCESS > [4.433s] > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS > [30.118s] > [INFO] oVirt Checkstyle Checks ........................... SUCCESS > [17.939s] > [INFO] oVirt Modules - backend ........................... SUCCESS > [0.032s] > [INFO] oVirt Manager ..................................... SUCCESS > [0.038s] > [INFO] oVirt DB Scripts .................................. SUCCESS > [0.598s] > [INFO] oVirt Engine dependencies ......................... SUCCESS > [4.554s] > [INFO] oVirt Modules - manager ........................... SUCCESS > [1.063s] > [INFO] CSharp Compatibility .............................. SUCCESS > [28.914s] > [INFO] Common Code ....................................... SUCCESS > [1:23.325s] > [INFO] Common utilities .................................. SUCCESS > [53.754s] > [INFO] Data Access Layer ................................. SUCCESS > [1:01.992s] > [INFO] engine beans ...................................... SUCCESS > [0.150s] > [INFO] engine scheduler bean ............................. SUCCESS > [20.642s] > [INFO] Vds broker ........................................ SUCCESS > [1:10.185s] > [INFO] Search Backend .................................... SUCCESS > [33.750s] > [INFO] Backend Logic @Service bean ....................... SUCCESS > [2:02.847s] > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS > [6.359s] > [INFO] oVirt RESTful API interface ....................... SUCCESS > [0.116s] > [INFO] oVirt Engine API Definition ....................... SUCCESS > [1:06.571s] > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS > [0.173s] > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS > [31.871s] > [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS > [38.586s] > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources > SUCCESS [1:09.994s] > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS > [0.934s] > [INFO] oVirt Engine Web Root ............................. SUCCESS > [21.532s] > [INFO] oVirt Engine Tools ................................ SUCCESS > [38.078s] > [INFO] oVirt Modules :: Frontend ......................... SUCCESS > [0.029s] > [INFO] oVirt Modules :: Webadmin ......................... SUCCESS > [0.024s] > [INFO] oVirt Modules - ui ................................ SUCCESS > [0.292s] > [INFO] Extensions for GWT ................................ SUCCESS > [21.585s] > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS > [27.833s] > [INFO] Frontend for GWT UI Projects ...................... SUCCESS > [30.205s] > [INFO] UICommonWeb ....................................... SUCCESS > [1:57.923s] > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS > [1:24.085s] > [INFO] WebAdmin .......................................... SUCCESS > [1:39.023s] > [INFO] UserPortal ........................................ SUCCESS > [49.974s] > [INFO] oVirt Server EAR .................................. SUCCESS > [2.999s] > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 21:01.931s > [INFO] Finished at: Sun Mar 03 08:06:13 EST 2013 > [INFO] Final Memory: 238M/779M > [INFO] > ------------------------------------------------------------------------ > [FINDBUGS] Collecting findbugs analysis files... > [FINDBUGS] Finding all files that match the pattern > **/findbugsXml.xml > [FINDBUGS] Parsing 23 files in > /home/jenkins/workspace/ovirt_engine_find_bugs > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/beans/scheduler/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/bll/target/findbugsXml.xml > of module with 251 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/common/target/findbugsXml.xml > of module with 245 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/compat/target/findbugsXml.xml > of module with 25 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/dal/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml > of module with 15 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml > of module with 28 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/restapi/types/target/findbugsXml.xml > of module with 13 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/root/target/findbugsXml.xml > of module with 3 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/searchbackend/target/findbugsXml.xml > of module with 11 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/utils/target/findbugsXml.xml > of module with 71 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/modules/vdsbroker/target/findbugsXml.xml > of module with 230 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/backend/manager/tools/target/findbugsXml.xml > of module with 30 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/build-tools-root/jboss-modules-maven-plugin/target/findbugsXml.xml > of module with 1 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/build-tools-root/ovirt-checkstyle-extension/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/frontend/target/findbugsXml.xml > of module with 38 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml > of module with 84 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicommonweb/target/findbugsXml.xml > of module with 649 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs/frontend/webadmin/modules/uicompat/target/findbugsXml.xml > of module with 50 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/webadmin/target/findbugsXml.xml > of module with 68 warnings. > [FINDBUGS] Computing warning deltas based on reference build #3646 > Build step 'Publish FindBugs analysis results' changed build result > to UNSTABLE > IRC notifier plugin: Sending notification to: #ovirt-jenkins > Email was triggered for: Unstable > Sending email for trigger: Unstable > _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Sun Mar 3 22:03:13 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 04 Mar 2013 00:03:13 +0200 Subject: [Engine-devel] Adding Kanagaraj Mayilsamy as a webadmin maintainer Message-ID: <5133C8A1.6090707@redhat.com> I'd like to propose Kanagaraj as a web admin maintainer - he has been working on the webadmin for about a year, with more than 130 UI patches merged. Thanks, Itamar From derez at redhat.com Sun Mar 3 22:06:14 2013 From: derez at redhat.com (Daniel Erez) Date: Sun, 3 Mar 2013 17:06:14 -0500 (EST) Subject: [Engine-devel] Adding Kanagaraj Mayilsamy as a webadmin maintainer In-Reply-To: <5133C8A1.6090707@redhat.com> Message-ID: <2026598396.8432480.1362348374706.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" , "Einav Cohen" , "Gilad Chaplik" , > "Daniel Erez" , "Tal Nisan" , "Tomas Jelinek" , "Alona > Kaplan" > Cc: "engine-devel" > Sent: Monday, March 4, 2013 12:03:13 AM > Subject: Adding Kanagaraj Mayilsamy as a webadmin maintainer > > I'd like to propose Kanagaraj as a web admin maintainer - he has been > working on the webadmin for about a year, with more than 130 UI > patches > merged. +1 > > Thanks, > Itamar > From tjelinek at redhat.com Mon Mar 4 07:52:01 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Mon, 4 Mar 2013 02:52:01 -0500 (EST) Subject: [Engine-devel] Adding Kanagaraj Mayilsamy as a webadmin maintainer In-Reply-To: <2026598396.8432480.1362348374706.JavaMail.root@redhat.com> Message-ID: <630776752.9686120.1362383521300.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Daniel Erez" > To: "Itamar Heim" > Cc: "engine-devel" , "Vojtech Szocs" , "Einav Cohen" , > "Gilad Chaplik" , "Tal Nisan" , "Tomas Jelinek" , > "Alona Kaplan" > Sent: Sunday, March 3, 2013 11:06:14 PM > Subject: Re: Adding Kanagaraj Mayilsamy as a webadmin maintainer > > > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Vojtech Szocs" , "Einav Cohen" > > , "Gilad Chaplik" , > > "Daniel Erez" , "Tal Nisan" , > > "Tomas Jelinek" , "Alona > > Kaplan" > > Cc: "engine-devel" > > Sent: Monday, March 4, 2013 12:03:13 AM > > Subject: Adding Kanagaraj Mayilsamy as a webadmin maintainer > > > > I'd like to propose Kanagaraj as a web admin maintainer - he has > > been > > working on the webadmin for about a year, with more than 130 UI > > patches > > merged. > > +1 > +1 > > > > Thanks, > > Itamar > > > From jhernand at redhat.com Mon Mar 4 08:12:25 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Mon, 04 Mar 2013 09:12:25 +0100 Subject: [Engine-devel] Local configuration moved from /etc/sysconfig/ovirt-engine to /etc/ovirt-engine/engine.conf Message-ID: <51345769.3060605@redhat.com> Hello, I just merged the a change [1] that moves the local configuration from the /etc/sysconfig/ovirt-engine file to /etc/ovirt-engine/engine.conf. If you are using the engine-upgrade utility to upgrade your installation then it should move the configuration automatically during the next upgrade. If you are not using engine-upgrade then you will have to move manually whatever you have in /etc/sysconfig/ovirt-engine to /etc/ovirt-engine/engine.conf. Let me know if you find issues. [1] http://gerrit.ovirt.org/7591 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. From oliel at redhat.com Mon Mar 4 15:24:52 2013 From: oliel at redhat.com (Ori Liel) Date: Mon, 4 Mar 2013 10:24:52 -0500 (EST) Subject: [Engine-devel] Engine Configuration API In-Reply-To: <27476237.12336220.1362409979811.JavaMail.root@redhat.com> Message-ID: <1326992059.12341799.1362410692692.JavaMail.root@redhat.com> I am adding the ability to display and update engine configuration parameters through the REST API. Working on this has raised a lot of dilemmas. The one I want to focus on here is: "Which configuration items do you think should be managed through the API?" Possible answers (you can add different ones too): 1) All items (the entire contents of VDC_OPTIONS, mirrored in the engine enum: ConfigValues.java). 2) Only the items in engine enum ConfigurationValues.java (an enum which IIUC was created in the past for GUI, and contains a subset of the items in the engine enum ConfigValues.java) 3) Only the items exposed by engine-config-tool. When I set out to work on this task, I was under the assumption that the API should show what the GUI shows (option 2). But since then I've found out that the set of items in engine-config-tool isn't identical to that in ConfigurationValues.java, and I've also heard the opinion that the API should show all values in vdc_options (option 1), because the clients of the API (& SDK, & CLI) are developers (as opposed to clients of GUI, which can be more though of as 'users'). I'd be glad to hear some opinions about this, especially PM input would be appreciated. Thanks, Ori. From Christopher.Morrissey at netapp.com Mon Mar 4 15:26:45 2013 From: Christopher.Morrissey at netapp.com (Morrissey, Christopher) Date: Mon, 4 Mar 2013 15:26:45 +0000 Subject: [Engine-devel] Improvement for the oVirt java sdk In-Reply-To: <51331B7A.5020009@redhat.com> References: <51331B7A.5020009@redhat.com> Message-ID: Hi Michael, Yes, that is the case here. I'm getting the JSESSIONID from the client and passing it to our server so that it can perform REST-API calls back to oVirt under the logged in user's authenticated session. -Chris > -----Original Message----- > From: Michael Pasternak [mailto:mpastern at redhat.com] > Sent: Sunday, March 03, 2013 4:44 AM > To: Morrissey, Christopher > Cc: users at ovirt.org; engine-devel > Subject: Re: Improvement for the oVirt java sdk > > > Hi Christopher, > > In general SDK abstracts the transport layer, therefore all authentication > internals hidden from the user, > > i.e SESSION based authentication happens implicitly (by default), when you > initiate SDK entry point, > > the story is different if you want using SSO-like login by reusing JSESSIONID > from the REST-API for instance, and i can support such scenario, > > but, is this your case? > > On 02/28/2013 10:04 PM, Morrissey, Christopher wrote: > > Hi Michael, > > > > I'm looking to use the oVirt java sdk for connecting into oVirt from > > our server. However, we have a UI plugin that gets access to a session > > ID that we should be able to use to connect through the REST API > > instead of the username and password. Any chance the sdk could be > updated to take the session ID and create a connection vs. a user name and > password? > > > > -Chris > > > > Chris Morrissey > > Software Engineer > > NetApp Inc. > > 919.476.4428 > > > > > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D From vszocs at redhat.com Mon Mar 4 15:38:01 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 4 Mar 2013 10:38:01 -0500 (EST) Subject: [Engine-devel] How to debug in frontend project In-Reply-To: <934551863.3516395.1361870419314.JavaMail.root@redhat.com> Message-ID: <1533055171.9916488.1362411481475.JavaMail.root@redhat.com> Hi, please find some details on debugging Web Admin below: 0) Make sure to export appropriate oVirt-related environment variables, for example: $ export OVIRT_GIT=$HOME/workspace/ovirt-engine $ export JBOSS_HOME=/usr/local/dev/ovirt-jboss-as $ export ENGINE_DEFAULTS=$OVIRT_GIT/backend/manager/conf/engine.conf.defaults 1) Perform full oVirt build, with Web Admin GWT compilation enabled $ cd $OVIRT_GIT $ mvn clean install -Pdep,gwt-admin -Dgwt.compiler.localWorkers=8 (Note: 'dep' profile deploys engine.ear to Engine JBoss instance, 'gwt-admin' profile enables Web Admin GWT compilation, 'gwt.compiler.localWorkers' is optional and should match the number of CPU cores to speed up GWT compilation) 2) Start Engine JBoss instance (standalone mode) $ cd $JBOSS_HOME/bin $ ./standalone.sh (Note: for server-side code debugging, you might want to edit '$JBOSS_HOME/bin/standalone.conf' and uncomment JPDA settings for remote socket debugging) 3) Launch Web Admin Development Mode session $ cd $OVIRT_GIT/frontend/webadmin/modules/webadmin $ mvn gwt:debug -Pgwtdev,gwt-admin -Dgwt.noserver=true 4) Connect to Web Admin Development Mode session from Java IDE > In Eclipse, create new 'Remote Java Application' debug configuration as follows: - host 'localhost', port 8000 - connection type 'Standard (Socket Attach)' - in 'Source' tab, you might want to add related frontend projects if you previously imported them into Eclipse (Add | Java project), e.g. 'uicommonweb' and 'gwt-common' 5) Launch Web Admin in web browser > open http://127.0.0.1:8700/webadmin/webadmin/WebAdmin.html?gwt.codesvr=127.0.0.1:9997 > (first-time only) you will be prompted to install GWT Developer plugin for the given browser, proceed with installation and restart the browser > open the URL again, GWT Developer plugin will now connect to Web Admin Development Mode ('gwt.codesvr') > there will be a new tab in Development Mode GUI for the given browser, including client-side logs (Note: each time you make a client-side code change, you have to refresh the URL in web browser, causing Web Admin to restart.) Regards, Vojtech ----- Original Message ----- From: "Ofri Masad" To: "Wei D Chen" Cc: engine-devel at ovirt.org Sent: Tuesday, February 26, 2013 10:20:19 AM Subject: Re: [Engine-devel] How to debug in frontend project Hi, Not sure this it what you've meant, but gwt allows you to debug directly from your IDE. Here is how: - compile using maven - go to: frontend/webadmin/modules/webadmin - run: mvn clean gwt:debug -Pgwt-admin,gwtdev (This will invoke a maven build which will get to the line: "[INFO] Listening for transport dt_socket at address: 8000") - Create a debug configuration on your IDE for remote debug on host:localhost port:8000 - Debug using the IDE (The IDE debug would launch a gwt tool which would allow you to activate the webadmin on you browser) * after activating the webadmin on the browser via the gwt tool, be patient - it takes few minutes to load. Ofri ----- Original Message ----- > From: "Wei D Chen" > To: engine-devel at ovirt.org > Sent: Tuesday, February 26, 2013 11:00:57 AM > Subject: [Engine-devel] How to debug in frontend project > > Hi, > > How to debug the code in frontend project? I mean, print out some > debug message from "onSave" method in the java file of > "VmListModel.java" which is located in uicommonweb project. Thanks > in advance. > > Best Regards, > Dave Chen > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From vszocs at redhat.com Mon Mar 4 17:03:41 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 4 Mar 2013 12:03:41 -0500 (EST) Subject: [Engine-devel] Adding Kanagaraj Mayilsamy as a webadmin maintainer In-Reply-To: <5133C8A1.6090707@redhat.com> Message-ID: <1014626711.9959908.1362416621070.JavaMail.root@redhat.com> +1 :) Vojtech ----- Original Message ----- From: "Itamar Heim" To: "Vojtech Szocs" , "Einav Cohen" , "Gilad Chaplik" , "Daniel Erez" , "Tal Nisan" , "Tomas Jelinek" , "Alona Kaplan" Cc: "engine-devel" Sent: Sunday, March 3, 2013 11:03:13 PM Subject: Adding Kanagaraj Mayilsamy as a webadmin maintainer I'd like to propose Kanagaraj as a web admin maintainer - he has been working on the webadmin for about a year, with more than 130 UI patches merged. Thanks, Itamar From vszocs at redhat.com Mon Mar 4 18:11:08 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 4 Mar 2013 13:11:08 -0500 (EST) Subject: [Engine-devel] "find bugs" - please solve the following In-Reply-To: <1989460029.13408978.1362332880266.JavaMail.root@redhat.com> Message-ID: <808720894.9980015.1362420668381.JavaMail.root@redhat.com> Hi, just a small note on how you can invoke findbugs-maven-plugin manually: $ cd $ mvn clean site -Preporting after that, just open /target/site/findbugs.html Regards, Vojtech ----- Original Message ----- From: "Einav Cohen" To: "Vojtech Szocs" , "Michael Kublin" , "Frantisek Kobzik" , "Libor Spevak" Cc: "engine-devel" , "Eyal Edri" Sent: Sunday, March 3, 2013 6:48:00 PM Subject: "find bugs" - please solve the following @Vojtech: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.-1256403867/source.1011/#436 warning introduced by the "Resizable Table Columns" commit [http://gerrit.ovirt.org/#/c/5243/] @Kublin: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.1463187495/source.486/#24 last update of relevant line was in "Fixing possible ConcurrentModificationException" commit [http://gerrit.ovirt.org/#/c/8436] @Frantisek: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.1591650016/category.-675839583/source.580/#43 http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.1591650016/category.1731749696/source.579/#22 file introduced in "Non-plugin automatic invocation of console session" [http://gerrit.ovirt.org/#/c/11702/] @Libor: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.742587459/source.1588/#176 last update of relevant line was in " webadmin,userportal: Show data centers and their clusters based on configured cluster service" [http://gerrit.ovirt.org/#/c/11395] ----- Forwarded Message ----- From: "Eyal Edri" To: engine-patches at ovirt.org, "engine-devel" Cc: dcaro at redhat.com Sent: Sunday, March 3, 2013 8:11:55 AM Subject: Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3652 - Still Unstable! New patches inserted NORMAL priority find bugs, please review and fix asap: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/changes E. From emesika at redhat.com Mon Mar 4 23:39:10 2013 From: emesika at redhat.com (Eli Mesika) Date: Mon, 4 Mar 2013 18:39:10 -0500 (EST) Subject: [Engine-devel] Engine Configuration API In-Reply-To: <1326992059.12341799.1362410692692.JavaMail.root@redhat.com> Message-ID: <1055022015.2372730.1362440350315.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ori Liel" > To: "engine-devel" > Sent: Monday, March 4, 2013 5:24:52 PM > Subject: [Engine-devel] Engine Configuration API > > I am adding the ability to display and update engine configuration > parameters through the REST API. > > Working on this has raised a lot of dilemmas. The one I want to focus > on here is: > > "Which configuration items do you think should be managed through > the API?" > > Possible answers (you can add different ones too): > > 1) All items (the entire contents of VDC_OPTIONS, mirrored in the > engine enum: ConfigValues.java). > 2) Only the items in engine enum ConfigurationValues.java (an enum > which IIUC was created in the past for GUI, and contains a subset of > the items in the engine enum ConfigValues.java) > 3) Only the items exposed by engine-config-tool. +1 Other values are internal and should not be exposed to the user > > When I set out to work on this task, I was under the assumption that > the API should show what the GUI shows (option 2). But since then > I've found out that the set of items in engine-config-tool isn't > identical to that in ConfigurationValues.java, and I've also heard > the opinion that the API should show all values in vdc_options > (option 1), because the clients of the API (& SDK, & CLI) are > developers (as opposed to clients of GUI, which can be more though > of as 'users'). > > I'd be glad to hear some opinions about this, especially PM input > would be appreciated. > > Thanks, > > Ori. > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alonbl at redhat.com Tue Mar 5 06:10:06 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 5 Mar 2013 01:10:06 -0500 (EST) Subject: [Engine-devel] Engine Configuration API In-Reply-To: <1055022015.2372730.1362440350315.JavaMail.root@redhat.com> Message-ID: <1953674131.4973669.1362463806689.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eli Mesika" > To: "Ori Liel" > Cc: "engine-devel" > Sent: Tuesday, March 5, 2013 1:39:10 AM > Subject: Re: [Engine-devel] Engine Configuration API > > > > ----- Original Message ----- > > From: "Ori Liel" > > To: "engine-devel" > > Sent: Monday, March 4, 2013 5:24:52 PM > > Subject: [Engine-devel] Engine Configuration API > > > > I am adding the ability to display and update engine configuration > > parameters through the REST API. > > > > Working on this has raised a lot of dilemmas. The one I want to > > focus > > on here is: > > > > "Which configuration items do you think should be managed > > through > > the API?" > > > > Possible answers (you can add different ones too): > > > > 1) All items (the entire contents of VDC_OPTIONS, mirrored in the > > engine enum: ConfigValues.java). > > 2) Only the items in engine enum ConfigurationValues.java (an enum > > which IIUC was created in the past for GUI, and contains a subset > > of > > the items in the engine enum ConfigValues.java) > > 3) Only the items exposed by engine-config-tool. > > +1 > Other values are internal and should not be exposed to the user Who is the 'user' of an API? A simple field of 'internal'/'private' per variable should be sufficient to warn developers aka 'user' not to expose it to end-'user'. > > > > When I set out to work on this task, I was under the assumption > > that > > the API should show what the GUI shows (option 2). But since then > > I've found out that the set of items in engine-config-tool isn't > > identical to that in ConfigurationValues.java, and I've also heard > > the opinion that the API should show all values in vdc_options > > (option 1), because the clients of the API (& SDK, & CLI) are > > developers (as opposed to clients of GUI, which can be more though > > of as 'users'). > > > > I'd be glad to hear some opinions about this, especially PM input > > would be appreciated. > > > > Thanks, > > > > Ori. > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From eedri at redhat.com Tue Mar 5 08:01:26 2013 From: eedri at redhat.com (Eyal Edri) Date: Tue, 5 Mar 2013 03:01:26 -0500 (EST) Subject: [Engine-devel] [JENKINS][ANN] jenkins.ovirt.org new look and infra In-Reply-To: <445282002.12600127.1362470084152.JavaMail.root@redhat.com> Message-ID: <2147271911.12603780.1362470486759.JavaMail.root@redhat.com> fyi, Starting from yesterday (4/3/13) jenkins.ovirt.org [1] has migrated to a new hosting server provided by alterway [2]. the new server has a new ui look that is similar to ovirt.org and is running on stronger infra then the previous one. All jobs and configuration have migrated from the old instance, but if you're still missing a certain job or permissions please contact infra team at infra at ovirt.org. I want to thank David caro from the infra team in helping with the migration and einav cohen from the ovirt frontend developer community for helping with the new css for jenkins. [1] http://jenkins.ovirt.org/ [2] http://www.ovirt.org/Sponsors_and_supporters Eyal Edri oVirt infra team. From eedri at redhat.com Tue Mar 5 08:17:39 2013 From: eedri at redhat.com (Eyal Edri) Date: Tue, 5 Mar 2013 03:17:39 -0500 (EST) Subject: [Engine-devel] "find bugs" - please solve the following In-Reply-To: <808720894.9980015.1362420668381.JavaMail.root@redhat.com> Message-ID: <2084181464.12610240.1362471459941.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Vojtech Szocs" > To: "Einav Cohen" > Cc: "engine-devel" , "Eyal Edri" , "Michael Kublin" , > "Frantisek Kobzik" , "Libor Spevak" > Sent: Monday, March 4, 2013 8:11:08 PM > Subject: Re: "find bugs" - please solve the following > > Hi, > > just a small note on how you can invoke findbugs-maven-plugin > manually: > > $ cd > $ mvn clean site -Preporting > > after that, just open > /target/site/findbugs.html > or use eclipse findbugs plugin http://findbugs.sourceforge.net/manual/eclipse.html > Regards, > Vojtech > > > ----- Original Message ----- > From: "Einav Cohen" > To: "Vojtech Szocs" , "Michael Kublin" > , "Frantisek Kobzik" , > "Libor Spevak" > Cc: "engine-devel" , "Eyal Edri" > > Sent: Sunday, March 3, 2013 6:48:00 PM > Subject: "find bugs" - please solve the following > > @Vojtech: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.-1256403867/source.1011/#436 > warning introduced by the "Resizable Table Columns" commit > [http://gerrit.ovirt.org/#/c/5243/] > > @Kublin: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.1463187495/source.486/#24 > last update of relevant line was in "Fixing possible > ConcurrentModificationException" commit > [http://gerrit.ovirt.org/#/c/8436] > > @Frantisek: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.1591650016/category.-675839583/source.580/#43 > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.1591650016/category.1731749696/source.579/#22 > file introduced in "Non-plugin automatic invocation of console > session" [http://gerrit.ovirt.org/#/c/11702/] > > @Libor: > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3648/findbugsResult/NORMAL/file.742587459/source.1588/#176 > last update of relevant line was in " webadmin,userportal: Show data > centers and their clusters based on configured cluster service" > [http://gerrit.ovirt.org/#/c/11395] > > > ----- Forwarded Message ----- > From: "Eyal Edri" > To: engine-patches at ovirt.org, "engine-devel" > Cc: dcaro at redhat.com > Sent: Sunday, March 3, 2013 8:11:55 AM > Subject: Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - > Build # 3652 - Still Unstable! > > New patches inserted NORMAL priority find bugs, > please review and fix asap: > > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/changes > > E. > From emesika at redhat.com Tue Mar 5 09:36:01 2013 From: emesika at redhat.com (Eli Mesika) Date: Tue, 5 Mar 2013 04:36:01 -0500 (EST) Subject: [Engine-devel] Engine Configuration API In-Reply-To: <1953674131.4973669.1362463806689.JavaMail.root@redhat.com> Message-ID: <1871025691.2523665.1362476161559.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Eli Mesika" > Cc: "engine-devel" , "Ori Liel" > Sent: Tuesday, March 5, 2013 8:10:06 AM > Subject: Re: [Engine-devel] Engine Configuration API > > > > ----- Original Message ----- > > From: "Eli Mesika" > > To: "Ori Liel" > > Cc: "engine-devel" > > Sent: Tuesday, March 5, 2013 1:39:10 AM > > Subject: Re: [Engine-devel] Engine Configuration API > > > > > > > > ----- Original Message ----- > > > From: "Ori Liel" > > > To: "engine-devel" > > > Sent: Monday, March 4, 2013 5:24:52 PM > > > Subject: [Engine-devel] Engine Configuration API > > > > > > I am adding the ability to display and update engine > > > configuration > > > parameters through the REST API. > > > > > > Working on this has raised a lot of dilemmas. The one I want to > > > focus > > > on here is: > > > > > > "Which configuration items do you think should be managed > > > through > > > the API?" > > > > > > Possible answers (you can add different ones too): > > > > > > 1) All items (the entire contents of VDC_OPTIONS, mirrored in the > > > engine enum: ConfigValues.java). > > > 2) Only the items in engine enum ConfigurationValues.java (an > > > enum > > > which IIUC was created in the past for GUI, and contains a subset > > > of > > > the items in the engine enum ConfigValues.java) > > > 3) Only the items exposed by engine-config-tool. > > > > +1 > > Other values are internal and should not be exposed to the user > > Who is the 'user' of an API? The same user running engine-config > A simple field of 'internal'/'private' per variable should be > sufficient to warn developers aka 'user' not to expose it to > end-'user'. I am OK with that if 1) we will add such 'internal' field 2) you will have to explicitly say that you want 'internal' fields, the default will be to skip that > > > > > > > When I set out to work on this task, I was under the assumption > > > that > > > the API should show what the GUI shows (option 2). But since then > > > I've found out that the set of items in engine-config-tool isn't > > > identical to that in ConfigurationValues.java, and I've also > > > heard > > > the opinion that the API should show all values in vdc_options > > > (option 1), because the clients of the API (& SDK, & CLI) are > > > developers (as opposed to clients of GUI, which can be more > > > though > > > of as 'users'). > > > > > > I'd be glad to hear some opinions about this, especially PM input > > > would be appreciated. > > > > > > Thanks, > > > > > > Ori. > > > > > > _______________________________________________ > > > 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 Tue Mar 5 12:16:17 2013 From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty) Date: Tue, 05 Mar 2013 17:46:17 +0530 Subject: [Engine-devel] Error during "Create new VM" Message-ID: <5135E211.6040303@linux.vnet.ibm.com> Hi, I get the following error in the engine web gui while trying to create a new VM (server or desktop) Error: gvm: Cannot add VM if custom VM properties are in invalid format. Please check the input. Whats custom property is it talking about ? Under 'Custom Property' in new VM Dialog.. it has nothing.. it says "no properties" I am on a git based engine setup.... trying to validate gluster storage domain, but unable to proceed from this step. Any workarounds/inputs appreciate thanx, deepak From deepakcs at linux.vnet.ibm.com Tue Mar 5 12:35:02 2013 From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty) Date: Tue, 05 Mar 2013 18:05:02 +0530 Subject: [Engine-devel] Error during "Create new VM" In-Reply-To: <5135E211.6040303@linux.vnet.ibm.com> References: <5135E211.6040303@linux.vnet.ibm.com> Message-ID: <5135E676.9000306@linux.vnet.ibm.com> On 03/05/2013 05:46 PM, Deepak C Shetty wrote: > Hi, > I get the following error in the engine web gui while trying to > create a new VM (server or desktop) > > Error: > > gvm: > > Cannot add VM if custom VM properties are in invalid format. > Please check the input. > > > Whats custom property is it talking about ? > Under 'Custom Property' in new VM Dialog.. it has nothing.. it says > "no properties" > > I am on a git based engine setup.... trying to validate gluster > storage domain, but unable to proceed from this step. > > Any workarounds/inputs appreciate I see the foll. WARN msgs in my engine log (standalone.sh console) 2013-03-05 18:02:57,584 INFO [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (http--0.0.0.0-8700-4) [1ec0c6a5] Lock Acquired to object EngineLock [exclusiveLocks= key: adsa value: VM_NAME , sharedLocks= ] 2013-03-05 18:02:57,589 WARN [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (http--0.0.0.0-8700-4) [1ec0c6a5] CanDoAction of action AddVmFromScratch failed. Reasons:VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_FAILED_INVALID_CUSTOM_VM_PROPERTIES_INVALID_SYNTAX 2013-03-05 18:02:57,592 INFO [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (http--0.0.0.0-8700-4) [1ec0c6a5] Lock freed to object EngineLock [exclusiveLocks= key: adsa value: VM_NAME , sharedLocks= ] 2013-03-05 18:02:59,561 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-4) No string for UNASSIGNED type. Use default Log 2013-03-05 18:03:04,229 INFO [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (http--0.0.0.0-8700-4) [479a4c15] Lock Acquired to object EngineLock [exclusiveLocks= key: adsa value: VM_NAME , sharedLocks= ] 2013-03-05 18:03:04,239 WARN [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (http--0.0.0.0-8700-4) [479a4c15] CanDoAction of action AddVmFromScratch failed. Reasons:VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_FAILED_INVALID_CUSTOM_VM_PROPERTIES_INVALID_SYNTAX 2013-03-05 18:03:04,241 INFO [org.ovirt.engine.core.bll.AddVmFromScratchCommand] (http--0.0.0.0-8700-4) [479a4c15] Lock freed to object EngineLock [exclusiveLocks= key: adsa value: VM_NAME , sharedLocks= ] > > thanx, > deepak > > _______________________________________________ > 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 Mar 5 12:57:54 2013 From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty) Date: Tue, 05 Mar 2013 18:27:54 +0530 Subject: [Engine-devel] Error during "Create new VM" [SOLVED] In-Reply-To: <5135E676.9000306@linux.vnet.ibm.com> References: <5135E211.6040303@linux.vnet.ibm.com> <5135E676.9000306@linux.vnet.ibm.com> Message-ID: <5135EBD2.9090909@linux.vnet.ibm.com> On 03/05/2013 06:05 PM, Deepak C Shetty wrote: > On 03/05/2013 05:46 PM, Deepak C Shetty wrote: >> Hi, >> I get the following error in the engine web gui while trying to >> create a new VM (server or desktop) >> >> Error: >> >> gvm: >> >> Cannot add VM if custom VM properties are in invalid format. >> Please check the input. >> >> >> Whats custom property is it talking about ? >> Under 'Custom Property' in new VM Dialog.. it has nothing.. it says >> "no properties" >> >> I am on a git based engine setup.... trying to validate gluster >> storage domain, but unable to proceed from this step. >> >> Any workarounds/inputs appreciate > > I see the foll. WARN msgs in my engine log (standalone.sh console) > > 2013-03-05 18:02:57,584 INFO > [org.ovirt.engine.core.bll.AddVmFromScratchCommand] > (http--0.0.0.0-8700-4) [1ec0c6a5] Lock Acquired to object EngineLock > [exclusiveLocks= key: adsa value: VM_NAME > , sharedLocks= ] > 2013-03-05 18:02:57,589 WARN > [org.ovirt.engine.core.bll.AddVmFromScratchCommand] > (http--0.0.0.0-8700-4) [1ec0c6a5] CanDoAction of action > AddVmFromScratch failed. > Reasons:VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_FAILED_INVALID_CUSTOM_VM_PROPERTIES_INVALID_SYNTAX > 2013-03-05 18:02:57,592 INFO > [org.ovirt.engine.core.bll.AddVmFromScratchCommand] > (http--0.0.0.0-8700-4) [1ec0c6a5] Lock freed to object EngineLock > [exclusiveLocks= key: adsa value: VM_NAME > , sharedLocks= ] > 2013-03-05 18:02:59,561 INFO > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (DefaultQuartzScheduler_Worker-4) No string for UNASSIGNED type. Use > default Log > 2013-03-05 18:03:04,229 INFO > [org.ovirt.engine.core.bll.AddVmFromScratchCommand] > (http--0.0.0.0-8700-4) [479a4c15] Lock Acquired to object EngineLock > [exclusiveLocks= key: adsa value: VM_NAME > , sharedLocks= ] > 2013-03-05 18:03:04,239 WARN > [org.ovirt.engine.core.bll.AddVmFromScratchCommand] > (http--0.0.0.0-8700-4) [479a4c15] CanDoAction of action > AddVmFromScratch failed. > Reasons:VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_FAILED_INVALID_CUSTOM_VM_PROPERTIES_INVALID_SYNTAX > 2013-03-05 18:03:04,241 INFO > [org.ovirt.engine.core.bll.AddVmFromScratchCommand] > (http--0.0.0.0-8700-4) [479a4c15] Lock freed to object EngineLock > [exclusiveLocks= key: adsa value: VM_NAME > , sharedLocks= ] > > Looks like some UI bug... i clicked on '+' then the custom property combo chnaged to "Pls select key" from "no keys available", then create VM works ! From lhornyak at redhat.com Tue Mar 5 13:49:28 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Tue, 5 Mar 2013 08:49:28 -0500 (EST) Subject: [Engine-devel] ovirtbot wiki activity noise Message-ID: <76943461.5755521.1362491368549.JavaMail.root@redhat.com> Hi, Anyone needs ovirtbot in #ovirt to log the page edits on the ovirt wiki? Maybe it was better when it did not :) Laszlo From tjelinek at redhat.com Tue Mar 5 14:21:27 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Tue, 5 Mar 2013 09:21:27 -0500 (EST) Subject: [Engine-devel] oVirt Engine GUI: builders infrastructure feedback (conf: 712 886 7405#) In-Reply-To: <1438771223.10335512.1362493246663.JavaMail.root@redhat.com> Message-ID: <183419836.10335682.1362493287231.JavaMail.root@redhat.com> attaching the slides ----- Original Message ----- > The following is a new meeting request: > > Subject: oVirt Engine GUI: builders infrastructure feedback (conf: > 712 886 7405#) > Organizer: "Einav Cohen" > > Location: Intercall conf code: 712 886 7405# > Time: Tuesday, March 5, 2013, 9:30:00 AM - 11:00:00 AM GMT -05:00 > US/Canada Eastern > > Invitees: tjelinek at redhat.com; engine-devel at ovirt.org > > > *~*~*~*~*~*~*~*~*~* > > Following the correspondence in the builders infrastructure patch [1] > and engine-devel thread [2]: > In the first part of the meeting, Tomas Jelinek > will present his builders infrastructure solution. > In the second part of the meeting, we will hear feedback about this > solution from the other parties and try to converge to a final, > unanimous decision. > > > conference call details: > ======================== > Intercall dial-in numbers: > https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405 > > Intercall conf code: > 712 886 7405# > > > elluminate session: > =================== > https://sas.elluminate.com/m.jnlp?sid=819&password=M.A7793C4C197B25A20229D725900B25 > > ---- > > [1] http://gerrit.ovirt.org/#/c/10874/ > > [2] > http://lists.ovirt.org/pipermail/engine-devel/2013-January/003528.html > -------------- next part -------------- A non-text attachment was scrubbed... Name: builders.pdf Type: application/pdf Size: 408998 bytes Desc: not available URL: From dneary at redhat.com Tue Mar 5 14:41:05 2013 From: dneary at redhat.com (Dave Neary) Date: Tue, 05 Mar 2013 15:41:05 +0100 Subject: [Engine-devel] ovirtbot wiki activity noise In-Reply-To: <76943461.5755521.1362491368549.JavaMail.root@redhat.com> References: <76943461.5755521.1362491368549.JavaMail.root@redhat.com> Message-ID: <51360401.1020802@redhat.com> Do you think there are too many? I don't find it annoying personally (except when we approve users, because that causes 4 wiki messages for one event). Cheers, Dave. On 03/05/2013 02:49 PM, Laszlo Hornyak wrote: > Hi, > > Anyone needs ovirtbot in #ovirt to log the page edits on the ovirt wiki? Maybe it was better when it did not :) > > Laszlo > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 From lhornyak at redhat.com Tue Mar 5 14:55:23 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Tue, 5 Mar 2013 09:55:23 -0500 (EST) Subject: [Engine-devel] ovirtbot wiki activity noise In-Reply-To: <51360401.1020802@redhat.com> Message-ID: <619321595.5830044.1362495323408.JavaMail.root@redhat.com> Maybe not too many compared to the whole traffic of the irc channel, but there is very little interest in these messages. Also, when I edit a page, it tells my name in the IRC channel, and my irc client is set to notify me when that happens. While most of us use this to get notification if someone needs some info fro us (important) this notification is quite unimportant. ----- Original Message ----- > From: "Dave Neary" > To: engine-devel at ovirt.org > Sent: Tuesday, March 5, 2013 3:41:05 PM > Subject: Re: [Engine-devel] ovirtbot wiki activity noise > > Do you think there are too many? I don't find it annoying personally > (except when we approve users, because that causes 4 wiki messages > for > one event). > > Cheers, > Dave. > > On 03/05/2013 02:49 PM, Laszlo Hornyak wrote: > > Hi, > > > > Anyone needs ovirtbot in #ovirt to log the page edits on the ovirt > > wiki? Maybe it was better when it did not :) > > > > Laszlo > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > -- > Dave Neary - Community Action and Impact > Open Source and Standards, Red Hat - http://community.redhat.com > Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ecohen at redhat.com Tue Mar 5 17:17:59 2013 From: ecohen at redhat.com (Einav Cohen) Date: Tue, 5 Mar 2013 12:17:59 -0500 (EST) Subject: [Engine-devel] oVirt Engine GUI: builders infrastructure - meeting minutes In-Reply-To: <183419836.10335682.1362493287231.JavaMail.root@redhat.com> Message-ID: <1898678508.15058657.1362503879572.JavaMail.root@redhat.com> - Problem and proposed solution in a nutshell: * we have a lot of duplication in the GUI code that can be eliminated using the builders infrastructure, which attempts to solve the problem by breaking down the logic to "atomic" particles, which can be (re)used as necessary. * Tomas came up with the solution when planning the implementation of the GUI code for the new Instance Types and Images [1] business entities (which are VM-related business entities, and the VM-related GUI code already have a lot of code duplication), when he realized that additional code duplication would have to be introduced unless some kind of new infrastructure/refactoring will be done. - Inheritance? * Code duplication exists across the entire GUI code, not only in the VM-related parts of it. It seems that an inheritance solution in the Networking code has already been introduced by Alona, and is possibly applicable to VM-related code as well. * Tomas has already tried the inheritance approach, however the result hasn't introduced a significant improvement to the current state of the code. * Derez/Alona will help Tomas with trying to figure out the most "correct" way to solve the code-duplication problem by inheritance. * If it will be concluded that an inheritance solution is not feasible, we will think of an alternative (builders, something else, stay with code duplication(???)), but we would really like to try and utilize the code inheritance, as it is already successfully used in other parts of the GUI code that had similar problems. - Need to keep in mind potential future plans for the GUI code: * moving to REST API business entities and REST API in general [Java(script?) SDK] * eliminating some entity models, and binding the view directly to the REST API business entities (possibly using decorators?). Need to keep in mind that a lot of the models will still need to be retained, e.g. since they are stateful (e.g. list model holds selected item(s)). * grouping several queries together, allowing to load data into a dialog, for example, in a single "bulk", rather than calling 20 different queries (New VM dialog and alike are the most painful - can take a lot of time to load, especially on WAN). - I would like to thank: * Tomas for his excellent presentation of the problem and the builders infrastructure solution (slides attached). * All other participants in the meeting for taking the time to listen, express their opinion and helping Tomas in this issue. [Participants: feel free to add to/amend the above as necessary] ---- Best Regards, Einav [1] http://www.ovirt.org/Features/Instance_Types ----- Original Message ----- > From: "Tomas Jelinek" > To: ecohen at redhat.com, engine-devel at ovirt.org > Sent: Tuesday, March 5, 2013 9:21:27 AM > Subject: [Engine-devel] oVirt Engine GUI: builders infrastructure feedback (conf: 712 886 7405#) > > attaching the slides > > ----- Original Message ----- > > The following is a new meeting request: > > > > Subject: oVirt Engine GUI: builders infrastructure feedback (conf: > > 712 886 7405#) > > Organizer: "Einav Cohen" > > > > Location: Intercall conf code: 712 886 7405# > > Time: Tuesday, March 5, 2013, 9:30:00 AM - 11:00:00 AM GMT -05:00 > > US/Canada Eastern > > > > Invitees: tjelinek at redhat.com; engine-devel at ovirt.org > > > > > > *~*~*~*~*~*~*~*~*~* > > > > Following the correspondence in the builders infrastructure patch > > [1] > > and engine-devel thread [2]: > > In the first part of the meeting, Tomas Jelinek > > > > will present his builders infrastructure solution. > > In the second part of the meeting, we will hear feedback about this > > solution from the other parties and try to converge to a final, > > unanimous decision. > > > > > > conference call details: > > ======================== > > Intercall dial-in numbers: > > https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405 > > > > Intercall conf code: > > 712 886 7405# > > > > > > elluminate session: > > =================== > > https://sas.elluminate.com/m.jnlp?sid=819&password=M.A7793C4C197B25A20229D725900B25 > > > > ---- > > > > [1] http://gerrit.ovirt.org/#/c/10874/ > > > > [2] > > http://lists.ovirt.org/pipermail/engine-devel/2013-January/003528.html > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: builders.pdf Type: application/pdf Size: 408998 bytes Desc: not available URL: From vszocs at redhat.com Tue Mar 5 18:07:36 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Tue, 5 Mar 2013 13:07:36 -0500 (EST) Subject: [Engine-devel] How to debug in frontend project In-Reply-To: <1533055171.9916488.1362411481475.JavaMail.root@redhat.com> Message-ID: <1838680023.10487153.1362506856184.JavaMail.root@redhat.com> Hi guys, I rewrote [http://www.ovirt.org/DebugFrontend] to include all details on debugging Frontend applications, as well as some frequently asked questions. Regards, Vojtech ----- Original Message ----- From: "Vojtech Szocs" To: "Ofri Masad" , "Wei D Chen" Cc: engine-devel at ovirt.org Sent: Monday, March 4, 2013 4:38:01 PM Subject: Re: [Engine-devel] How to debug in frontend project Hi, please find some details on debugging Web Admin below: 0) Make sure to export appropriate oVirt-related environment variables, for example: $ export OVIRT_GIT=$HOME/workspace/ovirt-engine $ export JBOSS_HOME=/usr/local/dev/ovirt-jboss-as $ export ENGINE_DEFAULTS=$OVIRT_GIT/backend/manager/conf/engine.conf.defaults 1) Perform full oVirt build, with Web Admin GWT compilation enabled $ cd $OVIRT_GIT $ mvn clean install -Pdep,gwt-admin -Dgwt.compiler.localWorkers=8 (Note: 'dep' profile deploys engine.ear to Engine JBoss instance, 'gwt-admin' profile enables Web Admin GWT compilation, 'gwt.compiler.localWorkers' is optional and should match the number of CPU cores to speed up GWT compilation) 2) Start Engine JBoss instance (standalone mode) $ cd $JBOSS_HOME/bin $ ./standalone.sh (Note: for server-side code debugging, you might want to edit '$JBOSS_HOME/bin/standalone.conf' and uncomment JPDA settings for remote socket debugging) 3) Launch Web Admin Development Mode session $ cd $OVIRT_GIT/frontend/webadmin/modules/webadmin $ mvn gwt:debug -Pgwtdev,gwt-admin -Dgwt.noserver=true 4) Connect to Web Admin Development Mode session from Java IDE > In Eclipse, create new 'Remote Java Application' debug configuration as follows: - host 'localhost', port 8000 - connection type 'Standard (Socket Attach)' - in 'Source' tab, you might want to add related frontend projects if you previously imported them into Eclipse (Add | Java project), e.g. 'uicommonweb' and 'gwt-common' 5) Launch Web Admin in web browser > open http://127.0.0.1:8700/webadmin/webadmin/WebAdmin.html?gwt.codesvr=127.0.0.1:9997 > (first-time only) you will be prompted to install GWT Developer plugin for the given browser, proceed with installation and restart the browser > open the URL again, GWT Developer plugin will now connect to Web Admin Development Mode ('gwt.codesvr') > there will be a new tab in Development Mode GUI for the given browser, including client-side logs (Note: each time you make a client-side code change, you have to refresh the URL in web browser, causing Web Admin to restart.) Regards, Vojtech ----- Original Message ----- From: "Ofri Masad" To: "Wei D Chen" Cc: engine-devel at ovirt.org Sent: Tuesday, February 26, 2013 10:20:19 AM Subject: Re: [Engine-devel] How to debug in frontend project Hi, Not sure this it what you've meant, but gwt allows you to debug directly from your IDE. Here is how: - compile using maven - go to: frontend/webadmin/modules/webadmin - run: mvn clean gwt:debug -Pgwt-admin,gwtdev (This will invoke a maven build which will get to the line: "[INFO] Listening for transport dt_socket at address: 8000") - Create a debug configuration on your IDE for remote debug on host:localhost port:8000 - Debug using the IDE (The IDE debug would launch a gwt tool which would allow you to activate the webadmin on you browser) * after activating the webadmin on the browser via the gwt tool, be patient - it takes few minutes to load. Ofri ----- Original Message ----- > From: "Wei D Chen" > To: engine-devel at ovirt.org > Sent: Tuesday, February 26, 2013 11:00:57 AM > Subject: [Engine-devel] How to debug in frontend project > > Hi, > > How to debug the code in frontend project? I mean, print out some > debug message from "onSave" method in the java file of > "VmListModel.java" which is located in uicommonweb project. Thanks > in advance. > > Best Regards, > Dave Chen > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From startup_002 at sina.cn Wed Mar 6 01:37:38 2013 From: startup_002 at sina.cn (startup_002 at sina.cn) Date: Wed, 06 Mar 2013 09:37:38 +0800 Subject: [Engine-devel] function insertstorage_domain_static(uuid, ...) does not exist Message-ID: <20130306013738.EEDC056056E@webmail.sinamail.sina.com.cn> Hi, I built the oVirt engine RPM packages from the latest oVirt engine source code and setup a yum installation server with these packages. I can successfully install the RPM packages on my oVirt engine test server. But when the "engine-setup" command was used to setup the engine sever, the following errors were encountered from engine-setup log. It seems that inst_add_iso_storage_domain was not created properly for psql. Any clue to this problem? 2013-03-05 20:02:19::DEBUG::nfsutils::192::root:: Generating unique uuid 2013-03-05 20:02:19::DEBUG::common_utils::501::root:: running sql query 'select inst_add_iso_storage_domain ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', 'ead292ee-14dd-40f9-b06b-f2250f7594a9', 'localhost.localdomain:/ISO', 0, 0)' on db server: 'localhost'. 2013-03-05 20:02:19::DEBUG::common_utils::454::root:: Executing command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine -c select inst_add_iso_storage_domain ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', 'ead292ee-14dd-40f9-b06b-f2250f7594a9', 'localhost.localdomain:/ISO', 0, 0)' in working directory '/root' 2013-03-05 20:02:19::DEBUG::common_utils::492::root:: output = 2013-03-05 20:02:19::DEBUG::common_utils::493::root:: stderr = ERROR: NUM:42883, DETAILS:function insertstorage_domain_static(uuid, character varying, character varying, integer, integer, unknown, integer) does not exist 2013-03-05 20:02:19::DEBUG::common_utils::494::root:: retcode = 1 2013-03-05 20:02:19::ERROR::engine-setup::1809::root:: Traceback (most recent call last): File "/bin/engine-setup", line 1804, in _configNfsShare _addIsoDomaintoDB(controller.CONF["sd_uuid"], controller.CONF["ISO_DOMAIN_NAME"]) File "/bin/engine-setup", line 1860, in _addIsoDomaintoDB utils.execRemoteSqlCommand(getDbUser(), getDbHostName(), getDbPort(), basedefs.DB_NAME, sqlQuery, True, output_messages.ERR_FAILED_INSERT_ISO_DOMAIN%(basedefs.DB_NAME)) File "/usr/share/ovirt-engine/scripts/common_utils.py", line 510, in execRemoteSqlCommand return execCmd(cmdList=cmd, failOnError=failOnError, msg=errMsg, envDict=getPgEnv()) File "/usr/share/ovirt-engine/scripts/common_utils.py", line 497, in execCmd raise Exception(msg) Exception: Failed inserting ISO domain into engine db 2013-03-05 20:02:19::DEBUG::setup_sequences::62::root:: Traceback (most recent call last): File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, in run function() File "/bin/engine-setup", line 1810, in _configNfsShare raise Exception(output_messages.ERR_FAILED_CFG_NFS_SHARE) Exception: Failed to configure NFS share on this host 2013-03-05 20:02:19::DEBUG::engine-setup::1992::root:: *** The following params were used as user input: 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: override-httpd-config: yes 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: http-port: 80 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: https-port: 443 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: random-passwords: no 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: mac-range: 00:1A:4A:A8:01:00-00:1A:4A:A8:01:FF 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: host-fqdn: localhost.localdomain 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: auth-pass: ******** 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: org-name: localdomain 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: application-mode: virt 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: default-dc-type: NFS 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-remote-install: local 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-host: localhost 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-local-pass: ******** 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: nfs-mp: /ISO 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: iso-domain-name: ISO_DOMAIN 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: config-nfs: yes 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: firewall-manager: iptables 2013-03-05 20:02:19::ERROR::engine-setup::2413::root:: Traceback (most recent call last): File "/bin/engine-setup", line 2407, in main(confFile) File "/bin/engine-setup", line 2190, in main -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpastern at redhat.com Wed Mar 6 08:55:03 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 06 Mar 2013 10:55:03 +0200 Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <5137004D.6010901@redhat.com> References: <5137004D.6010901@redhat.com> Message-ID: <51370467.5070903@redhat.com> Ok, here how it works, old id: https://admin.fedoraproject.org/accounts/openid/id/username is no longer supported according to [1], new format is: username.id.fedoraproject.org [1] https://fedoraproject.org/wiki/OpenID thanks. On 03/06/2013 10:37 AM, Michael Pasternak wrote: > https://admin.fedoraproject.org/accounts/openid/server > > 404 Not Found > > The path '/openid/server' was not found. -- Michael Pasternak RedHat, ENG-Virtualization R&D From iheim at redhat.com Wed Mar 6 08:51:20 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 06 Mar 2013 10:51:20 +0200 Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <51370467.5070903@redhat.com> References: <5137004D.6010901@redhat.com> <51370467.5070903@redhat.com> Message-ID: <51370388.1020805@redhat.com> On 03/06/2013 10:55 AM, Michael Pasternak wrote: > Ok, > > here how it works, > > old id: https://admin.fedoraproject.org/accounts/openid/id/username > is no longer supported according to [1], > new format is: username.id.fedoraproject.org i used this format to login a couple of days ago and it worked, but seems to be failing now. > > [1] https://fedoraproject.org/wiki/OpenID > > thanks. > > On 03/06/2013 10:37 AM, Michael Pasternak wrote: >> https://admin.fedoraproject.org/accounts/openid/server >> >> 404 Not Found >> >> The path '/openid/server' was not found. > > From rydekull at gmail.com Wed Mar 6 08:55:45 2013 From: rydekull at gmail.com (Alexander Rydekull) Date: Wed, 6 Mar 2013 09:55:45 +0100 Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <51370388.1020805@redhat.com> References: <5137004D.6010901@redhat.com> <51370467.5070903@redhat.com> <51370388.1020805@redhat.com> Message-ID: Itamar, I think Vered summarize it quite perfectly in a parallell thread: http://lists.ovirt.org/pipermail/infra/2013-March/002314.html He was also kind enough to open a ticket on the issue. Could you look into it? /Alexander Rydekull On Wed, Mar 6, 2013 at 9:51 AM, Itamar Heim wrote: > On 03/06/2013 10:55 AM, Michael Pasternak wrote: > >> Ok, >> >> here how it works, >> >> old id: https://admin.fedoraproject.**org/accounts/openid/id/**username >> is no longer supported according to [1], >> new format is: username.id.fedoraproject.org >> > > i used this format to login a couple of days ago and it worked, but seems > to be failing now. > > > >> [1] https://fedoraproject.org/**wiki/OpenID >> >> thanks. >> >> On 03/06/2013 10:37 AM, Michael Pasternak wrote: >> >>> https://admin.fedoraproject.**org/accounts/openid/server >>> >>> 404 Not Found >>> >>> The path '/openid/server' was not found. >>> >> >> >> > ______________________________**_________________ > Infra mailing list > Infra at ovirt.org > http://lists.ovirt.org/**mailman/listinfo/infra > -- /Alexander Rydekull -------------- next part -------------- An HTML attachment was scrubbed... URL: From lspevak at redhat.com Wed Mar 6 09:06:53 2013 From: lspevak at redhat.com (Libor Spevak) Date: Wed, 06 Mar 2013 10:06:53 +0100 Subject: [Engine-devel] REST API using BASH Message-ID: <5137072D.6020409@redhat.com> Hi, let me introduce some basic concepts when using REST API from the command line. I hope, it would be useful for newcomers. E.g. probably everybody has tried curl and then grep, sed, ... for response, but XPath processing tool is more convenient for this task. http://www.ovirt.org/REST_API_Using_BASH_Automation Regards, Libor -------------- next part -------------- An HTML attachment was scrubbed... URL: From gchaplik at redhat.com Wed Mar 6 09:12:48 2013 From: gchaplik at redhat.com (Gilad Chaplik) Date: Wed, 6 Mar 2013 04:12:48 -0500 (EST) Subject: [Engine-devel] oVirt Engine GUI: builders infrastructure - meeting minutes In-Reply-To: <1898678508.15058657.1362503879572.JavaMail.root@redhat.com> Message-ID: <740385243.10002523.1362561168198.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Tomas Jelinek" , "engine-devel" > Cc: "Alona Kaplan" , "Daniel Erez" , "Gilad Chaplik" , > "Vojtech Szocs" > Sent: Tuesday, March 5, 2013 7:17:59 PM > Subject: oVirt Engine GUI: builders infrastructure - meeting minutes > > > - Problem and proposed solution in a nutshell: > > * we have a lot of duplication in the GUI code that can be > eliminated > using the builders infrastructure, which attempts to solve the > problem by breaking > down the logic to "atomic" particles, which can be (re)used as > necessary. > > * Tomas came up with the solution when planning the implementation > of the GUI code > for the new Instance Types and Images [1] business entities (which > are VM-related > business entities, and the VM-related GUI code already have a lot of > code > duplication), when he realized that additional code duplication would > have > to be introduced unless some kind of new infrastructure/refactoring > will be done. > > - Inheritance? > > * Code duplication exists across the entire GUI code, not only in > the VM-related > parts of it. It seems that an inheritance solution in the Networking > code has already > been introduced by Alona, and is possibly applicable to VM-related > code as well. > > * Tomas has already tried the inheritance approach, however the > result hasn't > introduced a significant improvement to the current state of the > code. > > * Derez/Alona will help Tomas with trying to figure out the most > "correct" way to solve the code-duplication problem by inheritance. > > * If it will be concluded that an inheritance solution is not > feasible, we will > think of an alternative (builders, something else, stay with code > duplication(???)), > but we would really like to try and utilize the code inheritance, as > it is already > successfully used in other parts of the GUI code that had similar > problems. > > - Need to keep in mind potential future plans for the GUI code: > > * moving to REST API business entities and REST API in general > [Java(script?) SDK] > > * eliminating some entity models, and binding the view directly to > the REST API > business entities (possibly using decorators?). Need to keep in mind > that a lot > of the models will still need to be retained, e.g. since they are > stateful (e.g. list model > holds selected item(s)). small note: I think that stateless won't be a big deal (there are places in the code that we consider list model as stateless). > > * grouping several queries together, allowing to load data into a > dialog, for > example, in a single "bulk", rather than calling 20 different queries > (New VM dialog > and alike are the most painful - can take a lot of time to load, > especially on WAN). I think that all other issues are insignificant comparing to this one. If we invest the resources to refactor this area, this should be our primary goal. different approaches may lead us to have the same talk/cycle in the near future. I think that each of the items you've mentioned here is more than enough to postpone/delay/rethink the solution for this issue; maybe propose a quick POC instead of investing time in sth that could/may change soon. [FYI: I think that inheritance is the way to go, but on the servlet side... we should call a single query to fill out the entire dialog] Great discussion! and thanks you Tomas :-) Gilad. > > - I would like to thank: > > * Tomas for his excellent presentation of the problem and the > builders infrastructure solution (slides attached). > > * All other participants in the meeting for taking the time > to listen, express their opinion and helping Tomas in this issue. > > [Participants: feel free to add to/amend the above as necessary] > > ---- > Best Regards, > Einav > > > [1] http://www.ovirt.org/Features/Instance_Types > > ----- Original Message ----- > > From: "Tomas Jelinek" > > To: ecohen at redhat.com, engine-devel at ovirt.org > > Sent: Tuesday, March 5, 2013 9:21:27 AM > > Subject: [Engine-devel] oVirt Engine GUI: builders infrastructure > > feedback (conf: 712 886 7405#) > > > > attaching the slides > > > > ----- Original Message ----- > > > The following is a new meeting request: > > > > > > Subject: oVirt Engine GUI: builders infrastructure feedback > > > (conf: > > > 712 886 7405#) > > > Organizer: "Einav Cohen" > > > > > > Location: Intercall conf code: 712 886 7405# > > > Time: Tuesday, March 5, 2013, 9:30:00 AM - 11:00:00 AM GMT -05:00 > > > US/Canada Eastern > > > > > > Invitees: tjelinek at redhat.com; engine-devel at ovirt.org > > > > > > > > > *~*~*~*~*~*~*~*~*~* > > > > > > Following the correspondence in the builders infrastructure patch > > > [1] > > > and engine-devel thread [2]: > > > In the first part of the meeting, Tomas Jelinek > > > > > > will present his builders infrastructure solution. > > > In the second part of the meeting, we will hear feedback about > > > this > > > solution from the other parties and try to converge to a final, > > > unanimous decision. > > > > > > > > > conference call details: > > > ======================== > > > Intercall dial-in numbers: > > > https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405 > > > > > > Intercall conf code: > > > 712 886 7405# > > > > > > > > > elluminate session: > > > =================== > > > https://sas.elluminate.com/m.jnlp?sid=819&password=M.A7793C4C197B25A20229D725900B25 > > > > > > ---- > > > > > > [1] http://gerrit.ovirt.org/#/c/10874/ > > > > > > [2] > > > http://lists.ovirt.org/pipermail/engine-devel/2013-January/003528.html > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From danken at redhat.com Wed Mar 6 09:38:45 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 6 Mar 2013 11:38:45 +0200 Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: References: <5137004D.6010901@redhat.com> <51370467.5070903@redhat.com> <51370388.1020805@redhat.com> Message-ID: <20130306093845.GC15722@redhat.com> On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull wrote: > Itamar, I think Vered summarize it quite perfectly in a parallell thread: > http://lists.ovirt.org/pipermail/infra/2013-March/002314.html > > He was also kind enough to open a ticket on the issue. Could you look into > it? I wonder if our friendly gerrit.ovirt.org dba could add the new url https://danken.id.fedoraproject.org/ for every user with the old one, so that people lacking the new one can keep on working? (/me not included, I have both urls) Dan. From iheim at redhat.com Wed Mar 6 10:34:37 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 06 Mar 2013 12:34:37 +0200 Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <20130306093845.GC15722@redhat.com> References: <5137004D.6010901@redhat.com> <51370467.5070903@redhat.com> <51370388.1020805@redhat.com> <20130306093845.GC15722@redhat.com> Message-ID: <51371BBD.1040201@redhat.com> On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: > On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull wrote: >> Itamar, I think Vered summarize it quite perfectly in a parallell thread: >> http://lists.ovirt.org/pipermail/infra/2013-March/002314.html >> >> He was also kind enough to open a ticket on the issue. Could you look into >> it? > > I wonder if our friendly gerrit.ovirt.org dba could add the new url > https://danken.id.fedoraproject.org/ > for every user with the old one, so that people lacking the new one can > keep on working? (/me not included, I have both urls) > > Dan. > it's not that simple, still investigating... From iheim at redhat.com Wed Mar 6 10:48:57 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 06 Mar 2013 12:48:57 +0200 Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <51371BBD.1040201@redhat.com> References: <5137004D.6010901@redhat.com> <51370467.5070903@redhat.com> <51370388.1020805@redhat.com> <20130306093845.GC15722@redhat.com> <51371BBD.1040201@redhat.com> Message-ID: <51371F19.8010400@redhat.com> On 03/06/2013 12:34 PM, Itamar Heim wrote: > On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: >> On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull wrote: >>> Itamar, I think Vered summarize it quite perfectly in a parallell >>> thread: >>> http://lists.ovirt.org/pipermail/infra/2013-March/002314.html >>> >>> He was also kind enough to open a ticket on the issue. Could you look >>> into >>> it? >> >> I wonder if our friendly gerrit.ovirt.org dba could add the new url >> https://danken.id.fedoraproject.org/ >> for every user with the old one, so that people lacking the new one can >> keep on working? (/me not included, I have both urls) >> >> Dan. >> > > it's not that simple, still investigating... > _______________________________________________ > Infra mailing list > Infra at ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ok, new url is working. for general knowledge, its aside of the use of the new identity url and in the form of: https://admin.fedoraproject.org/accounts/user/view/iheim previous format was: https://admin.fedoraproject.org/accounts/openid/id/iheim (there could be something more "correct", but this works...) please check and update if you still see issues. thanks, Itamar From ydary at redhat.com Wed Mar 6 12:18:08 2013 From: ydary at redhat.com (Yaniv Dary) Date: Wed, 6 Mar 2013 07:18:08 -0500 (EST) Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <51371F19.8010400@redhat.com> Message-ID: <462140507.10072052.1362572288184.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Dan Kenigsberg" > Cc: "engine-devel" , "Vered Volansky" , infra at ovirt.org > Sent: Wednesday, March 6, 2013 12:48:57 PM > Subject: Re: [Engine-devel] fedora openid authentication for gerrit is broken > > On 03/06/2013 12:34 PM, Itamar Heim wrote: > > On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: > >> On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull > >> wrote: > >>> Itamar, I think Vered summarize it quite perfectly in a parallell > >>> thread: > >>> http://lists.ovirt.org/pipermail/infra/2013-March/002314.html > >>> > >>> He was also kind enough to open a ticket on the issue. Could you > >>> look > >>> into > >>> it? > >> > >> I wonder if our friendly gerrit.ovirt.org dba could add the new > >> url > >> https://danken.id.fedoraproject.org/ > >> for every user with the old one, so that people lacking the new > >> one can > >> keep on working? (/me not included, I have both urls) > >> > >> Dan. > >> > > > > it's not that simple, still investigating... > > _______________________________________________ > > Infra mailing list > > Infra at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > ok, new url is working. > for general knowledge, its aside of the use of the new identity url > and > in the form of: > https://admin.fedoraproject.org/accounts/user/view/iheim > previous format was: > https://admin.fedoraproject.org/accounts/openid/id/iheim > > (there could be something more "correct", but this works...) > > please check and update if you still see issues. Getting 'Provider is not supported, or was incorrectly entered.'. Yaniv > > thanks, > Itamar > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Wed Mar 6 12:42:46 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 06 Mar 2013 14:42:46 +0200 Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <462140507.10072052.1362572288184.JavaMail.root@redhat.com> References: <462140507.10072052.1362572288184.JavaMail.root@redhat.com> Message-ID: <513739C6.4090808@redhat.com> On 03/06/2013 02:18 PM, Yaniv Dary wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Dan Kenigsberg" >> Cc: "engine-devel" , "Vered Volansky" , infra at ovirt.org >> Sent: Wednesday, March 6, 2013 12:48:57 PM >> Subject: Re: [Engine-devel] fedora openid authentication for gerrit is broken >> >> On 03/06/2013 12:34 PM, Itamar Heim wrote: >>> On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: >>>> On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull >>>> wrote: >>>>> Itamar, I think Vered summarize it quite perfectly in a parallell >>>>> thread: >>>>> http://lists.ovirt.org/pipermail/infra/2013-March/002314.html >>>>> >>>>> He was also kind enough to open a ticket on the issue. Could you >>>>> look >>>>> into >>>>> it? >>>> >>>> I wonder if our friendly gerrit.ovirt.org dba could add the new >>>> url >>>> https://danken.id.fedoraproject.org/ >>>> for every user with the old one, so that people lacking the new >>>> one can >>>> keep on working? (/me not included, I have both urls) >>>> >>>> Dan. >>>> >>> >>> it's not that simple, still investigating... >>> _______________________________________________ >>> Infra mailing list >>> Infra at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/infra >> >> ok, new url is working. >> for general knowledge, its aside of the use of the new identity url >> and >> in the form of: >> https://admin.fedoraproject.org/accounts/user/view/iheim >> previous format was: >> https://admin.fedoraproject.org/accounts/openid/id/iheim >> >> (there could be something more "correct", but this works...) >> >> please check and update if you still see issues. > > Getting 'Provider is not supported, or was incorrectly entered.'. use this format in the gerrit sign in screen: http://iheim.id.fedoraproject.org/ From ydary at redhat.com Wed Mar 6 12:44:59 2013 From: ydary at redhat.com (Yaniv Dary) Date: Wed, 6 Mar 2013 07:44:59 -0500 (EST) Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <513739C6.4090808@redhat.com> Message-ID: <341913426.10082405.1362573899898.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Yaniv Dary" > Cc: "engine-devel" , "Vered Volansky" , infra at ovirt.org, "Dan Kenigsberg" > > Sent: Wednesday, March 6, 2013 2:42:46 PM > Subject: Re: [Engine-devel] fedora openid authentication for gerrit is broken > > On 03/06/2013 02:18 PM, Yaniv Dary wrote: > > > > > > ----- Original Message ----- > >> From: "Itamar Heim" > >> To: "Dan Kenigsberg" > >> Cc: "engine-devel" , "Vered Volansky" > >> , infra at ovirt.org > >> Sent: Wednesday, March 6, 2013 12:48:57 PM > >> Subject: Re: [Engine-devel] fedora openid authentication for > >> gerrit is broken > >> > >> On 03/06/2013 12:34 PM, Itamar Heim wrote: > >>> On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: > >>>> On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull > >>>> wrote: > >>>>> Itamar, I think Vered summarize it quite perfectly in a > >>>>> parallell > >>>>> thread: > >>>>> http://lists.ovirt.org/pipermail/infra/2013-March/002314.html > >>>>> > >>>>> He was also kind enough to open a ticket on the issue. Could > >>>>> you > >>>>> look > >>>>> into > >>>>> it? > >>>> > >>>> I wonder if our friendly gerrit.ovirt.org dba could add the new > >>>> url > >>>> https://danken.id.fedoraproject.org/ > >>>> for every user with the old one, so that people lacking the new > >>>> one can > >>>> keep on working? (/me not included, I have both urls) > >>>> > >>>> Dan. > >>>> > >>> > >>> it's not that simple, still investigating... > >>> _______________________________________________ > >>> Infra mailing list > >>> Infra at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/infra > >> > >> ok, new url is working. > >> for general knowledge, its aside of the use of the new identity > >> url > >> and > >> in the form of: > >> https://admin.fedoraproject.org/accounts/user/view/iheim > >> previous format was: > >> https://admin.fedoraproject.org/accounts/openid/id/iheim > >> > >> (there could be something more "correct", but this works...) > >> > >> please check and update if you still see issues. > > > > Getting 'Provider is not supported, or was incorrectly entered.'. > > use this format in the gerrit sign in screen: > http://iheim.id.fedoraproject.org/ This logs me in to a empty new account. Losing all permissions and previous patches. > > From mkublin at redhat.com Wed Mar 6 12:46:38 2013 From: mkublin at redhat.com (Michael Kublin) Date: Wed, 6 Mar 2013 07:46:38 -0500 (EST) Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <513739C6.4090808@redhat.com> Message-ID: <826426364.10082772.1362573998271.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Yaniv Dary" > Cc: "engine-devel" , "Vered Volansky" , infra at ovirt.org > Sent: Wednesday, March 6, 2013 2:42:46 PM > Subject: Re: [Engine-devel] fedora openid authentication for gerrit is broken > > On 03/06/2013 02:18 PM, Yaniv Dary wrote: > > > > > > ----- Original Message ----- > >> From: "Itamar Heim" > >> To: "Dan Kenigsberg" > >> Cc: "engine-devel" , "Vered Volansky" > >> , infra at ovirt.org > >> Sent: Wednesday, March 6, 2013 12:48:57 PM > >> Subject: Re: [Engine-devel] fedora openid authentication for > >> gerrit is broken > >> > >> On 03/06/2013 12:34 PM, Itamar Heim wrote: > >>> On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: > >>>> On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull > >>>> wrote: > >>>>> Itamar, I think Vered summarize it quite perfectly in a > >>>>> parallell > >>>>> thread: > >>>>> http://lists.ovirt.org/pipermail/infra/2013-March/002314.html > >>>>> > >>>>> He was also kind enough to open a ticket on the issue. Could > >>>>> you > >>>>> look > >>>>> into > >>>>> it? > >>>> > >>>> I wonder if our friendly gerrit.ovirt.org dba could add the new > >>>> url > >>>> https://danken.id.fedoraproject.org/ > >>>> for every user with the old one, so that people lacking the new > >>>> one can > >>>> keep on working? (/me not included, I have both urls) > >>>> > >>>> Dan. > >>>> > >>> > >>> it's not that simple, still investigating... > >>> _______________________________________________ > >>> Infra mailing list > >>> Infra at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/infra > >> > >> ok, new url is working. > >> for general knowledge, its aside of the use of the new identity > >> url > >> and > >> in the form of: > >> https://admin.fedoraproject.org/accounts/user/view/iheim > >> previous format was: > >> https://admin.fedoraproject.org/accounts/openid/id/iheim > >> > >> (there could be something more "correct", but this works...) > >> > >> please check and update if you still see issues. > > > > Getting 'Provider is not supported, or was incorrectly entered.'. > > use this format in the gerrit sign in screen: > http://iheim.id.fedoraproject.org/ But all my patches and reviews are not linked to my old user and I can not link it via gerrit because of https://admin.fedoraproject.org/accounts/user/view/mkublin is not valid anymore From mpastern at redhat.com Wed Mar 6 13:00:24 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 06 Mar 2013 15:00:24 +0200 Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <826426364.10082772.1362573998271.JavaMail.root@redhat.com> References: <826426364.10082772.1362573998271.JavaMail.root@redhat.com> Message-ID: <51373DE8.6020704@redhat.com> On 03/06/2013 02:46 PM, Michael Kublin wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Yaniv Dary" >> Cc: "engine-devel" , "Vered Volansky" , infra at ovirt.org >> Sent: Wednesday, March 6, 2013 2:42:46 PM >> Subject: Re: [Engine-devel] fedora openid authentication for gerrit is broken >> >> On 03/06/2013 02:18 PM, Yaniv Dary wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Dan Kenigsberg" >>>> Cc: "engine-devel" , "Vered Volansky" >>>> , infra at ovirt.org >>>> Sent: Wednesday, March 6, 2013 12:48:57 PM >>>> Subject: Re: [Engine-devel] fedora openid authentication for >>>> gerrit is broken >>>> >>>> On 03/06/2013 12:34 PM, Itamar Heim wrote: >>>>> On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: >>>>>> On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull >>>>>> wrote: >>>>>>> Itamar, I think Vered summarize it quite perfectly in a >>>>>>> parallell >>>>>>> thread: >>>>>>> http://lists.ovirt.org/pipermail/infra/2013-March/002314.html >>>>>>> >>>>>>> He was also kind enough to open a ticket on the issue. Could >>>>>>> you >>>>>>> look >>>>>>> into >>>>>>> it? >>>>>> >>>>>> I wonder if our friendly gerrit.ovirt.org dba could add the new >>>>>> url >>>>>> https://danken.id.fedoraproject.org/ >>>>>> for every user with the old one, so that people lacking the new >>>>>> one can >>>>>> keep on working? (/me not included, I have both urls) >>>>>> >>>>>> Dan. >>>>>> >>>>> >>>>> it's not that simple, still investigating... >>>>> _______________________________________________ >>>>> Infra mailing list >>>>> Infra at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>> >>>> ok, new url is working. >>>> for general knowledge, its aside of the use of the new identity >>>> url >>>> and >>>> in the form of: >>>> https://admin.fedoraproject.org/accounts/user/view/iheim >>>> previous format was: >>>> https://admin.fedoraproject.org/accounts/openid/id/iheim >>>> >>>> (there could be something more "correct", but this works...) >>>> >>>> please check and update if you still see issues. >>> >>> Getting 'Provider is not supported, or was incorrectly entered.'. >> >> use this format in the gerrit sign in screen: >> http://iheim.id.fedoraproject.org/ > But all my patches and reviews are not linked to my old user and I can not > link it via gerrit because of https://admin.fedoraproject.org/accounts/user/view/mkublin is > not valid anymore > in general you should be linking your old identity in gerrit from the [1], but since it's disabled - it's not possible. [1] https://admin.fedoraproject.org/accounts/openid/id/user > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D From iheim at redhat.com Wed Mar 6 13:00:59 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 06 Mar 2013 15:00:59 +0200 Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <826426364.10082772.1362573998271.JavaMail.root@redhat.com> References: <826426364.10082772.1362573998271.JavaMail.root@redhat.com> Message-ID: <51373E0B.9040306@redhat.com> On 03/06/2013 02:46 PM, Michael Kublin wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Yaniv Dary" >> Cc: "engine-devel" , "Vered Volansky" , infra at ovirt.org >> Sent: Wednesday, March 6, 2013 2:42:46 PM >> Subject: Re: [Engine-devel] fedora openid authentication for gerrit is broken >> >> On 03/06/2013 02:18 PM, Yaniv Dary wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Dan Kenigsberg" >>>> Cc: "engine-devel" , "Vered Volansky" >>>> , infra at ovirt.org >>>> Sent: Wednesday, March 6, 2013 12:48:57 PM >>>> Subject: Re: [Engine-devel] fedora openid authentication for >>>> gerrit is broken >>>> >>>> On 03/06/2013 12:34 PM, Itamar Heim wrote: >>>>> On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: >>>>>> On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull >>>>>> wrote: >>>>>>> Itamar, I think Vered summarize it quite perfectly in a >>>>>>> parallell >>>>>>> thread: >>>>>>> http://lists.ovirt.org/pipermail/infra/2013-March/002314.html >>>>>>> >>>>>>> He was also kind enough to open a ticket on the issue. Could >>>>>>> you >>>>>>> look >>>>>>> into >>>>>>> it? >>>>>> >>>>>> I wonder if our friendly gerrit.ovirt.org dba could add the new >>>>>> url >>>>>> https://danken.id.fedoraproject.org/ >>>>>> for every user with the old one, so that people lacking the new >>>>>> one can >>>>>> keep on working? (/me not included, I have both urls) >>>>>> >>>>>> Dan. >>>>>> >>>>> >>>>> it's not that simple, still investigating... >>>>> _______________________________________________ >>>>> Infra mailing list >>>>> Infra at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>> >>>> ok, new url is working. >>>> for general knowledge, its aside of the use of the new identity >>>> url >>>> and >>>> in the form of: >>>> https://admin.fedoraproject.org/accounts/user/view/iheim >>>> previous format was: >>>> https://admin.fedoraproject.org/accounts/openid/id/iheim >>>> >>>> (there could be something more "correct", but this works...) >>>> >>>> please check and update if you still see issues. >>> >>> Getting 'Provider is not supported, or was incorrectly entered.'. >> >> use this format in the gerrit sign in screen: >> http://iheim.id.fedoraproject.org/ > But all my patches and reviews are not linked to my old user and I can not > link it via gerrit because of https://admin.fedoraproject.org/accounts/user/view/mkublin is > not valid anymore > if you get a new user - send me a private email with your details and I'll help clean it up. From iheim at redhat.com Wed Mar 6 13:01:17 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 06 Mar 2013 15:01:17 +0200 Subject: [Engine-devel] fedora openid authentication for gerrit is broken In-Reply-To: <51373DE8.6020704@redhat.com> References: <826426364.10082772.1362573998271.JavaMail.root@redhat.com> <51373DE8.6020704@redhat.com> Message-ID: <51373E1D.5040200@redhat.com> On 03/06/2013 03:00 PM, Michael Pasternak wrote: > On 03/06/2013 02:46 PM, Michael Kublin wrote: >> >> >> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Yaniv Dary" >>> Cc: "engine-devel" , "Vered Volansky" , infra at ovirt.org >>> Sent: Wednesday, March 6, 2013 2:42:46 PM >>> Subject: Re: [Engine-devel] fedora openid authentication for gerrit is broken >>> >>> On 03/06/2013 02:18 PM, Yaniv Dary wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Itamar Heim" >>>>> To: "Dan Kenigsberg" >>>>> Cc: "engine-devel" , "Vered Volansky" >>>>> , infra at ovirt.org >>>>> Sent: Wednesday, March 6, 2013 12:48:57 PM >>>>> Subject: Re: [Engine-devel] fedora openid authentication for >>>>> gerrit is broken >>>>> >>>>> On 03/06/2013 12:34 PM, Itamar Heim wrote: >>>>>> On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: >>>>>>> On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull >>>>>>> wrote: >>>>>>>> Itamar, I think Vered summarize it quite perfectly in a >>>>>>>> parallell >>>>>>>> thread: >>>>>>>> http://lists.ovirt.org/pipermail/infra/2013-March/002314.html >>>>>>>> >>>>>>>> He was also kind enough to open a ticket on the issue. Could >>>>>>>> you >>>>>>>> look >>>>>>>> into >>>>>>>> it? >>>>>>> >>>>>>> I wonder if our friendly gerrit.ovirt.org dba could add the new >>>>>>> url >>>>>>> https://danken.id.fedoraproject.org/ >>>>>>> for every user with the old one, so that people lacking the new >>>>>>> one can >>>>>>> keep on working? (/me not included, I have both urls) >>>>>>> >>>>>>> Dan. >>>>>>> >>>>>> >>>>>> it's not that simple, still investigating... >>>>>> _______________________________________________ >>>>>> Infra mailing list >>>>>> Infra at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/infra >>>>> >>>>> ok, new url is working. >>>>> for general knowledge, its aside of the use of the new identity >>>>> url >>>>> and >>>>> in the form of: >>>>> https://admin.fedoraproject.org/accounts/user/view/iheim >>>>> previous format was: >>>>> https://admin.fedoraproject.org/accounts/openid/id/iheim >>>>> >>>>> (there could be something more "correct", but this works...) >>>>> >>>>> please check and update if you still see issues. >>>> >>>> Getting 'Provider is not supported, or was incorrectly entered.'. >>> >>> use this format in the gerrit sign in screen: >>> http://iheim.id.fedoraproject.org/ >> But all my patches and reviews are not linked to my old user and I can not >> link it via gerrit because of https://admin.fedoraproject.org/accounts/user/view/mkublin is >> not valid anymore >> > > in general you should be linking your old identity in gerrit from the [1], > but since it's disabled - it's not possible. > if you get a new user - send me a private email with your details and I'll help clean it up. > [1] https://admin.fedoraproject.org/accounts/openid/id/user > >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > From eedri at redhat.com Wed Mar 6 14:49:22 2013 From: eedri at redhat.com (Eyal Edri) Date: Wed, 6 Mar 2013 09:49:22 -0500 (EST) Subject: [Engine-devel] [JENKINS] new job on jenkins.ovirt.org - verify errors codes on engine <-> vdsm In-Reply-To: <1649506650.13822758.1362581224192.JavaMail.root@redhat.com> Message-ID: <955440257.13823542.1362581362054.JavaMail.root@redhat.com> fyi, a new job has been added (more liked fixed) - http://jenkins.ovirt.org/view/vdsm/job/vdsm_verify_error_codes/ Job Desc: " The purpose of this jenkins job is verify each error code reported by VDSM has a correlated message on the engine side, else we get the 'Unexpected error'. The missing error code should be added to: ovirt-engine/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/errors/VdcBllErrors.java and the error message to: ovirt-engine/backend/manager/modules/dal/src/main/resources/bundles/VdsmErrors.properties If a specific VDSM error code should not be reported by VDSM and needed to be ignored, we can add it to the 'ignored list' of the jenkins job. " please notice if this job breaks after your commit, it will probably mean you changed/added an error code in one component but not in the other. eyal edri oVirt infra team. From rnori at redhat.com Wed Mar 6 16:57:10 2013 From: rnori at redhat.com (Ravi Nori) Date: Wed, 06 Mar 2013 11:57:10 -0500 Subject: [Engine-devel] Best place for new interfaces used by bll Message-ID: <51377566.6070604@redhat.com> Hi, I am working on refactoring some of the backend code in bll and need to create interfaces so that I can eliminate the dependency between bll and the new module. Currently I created the interfaces in org.ovirt.engine.core.common.interfaces, but from what I understand this module is used by both frontend and backend. The new interfaces will only be used by the backend. What would be the best place to put these new interfaces? Ravi From abonas at redhat.com Wed Mar 6 20:50:52 2013 From: abonas at redhat.com (Alissa Bonas) Date: Wed, 6 Mar 2013 15:50:52 -0500 (EST) Subject: [Engine-devel] Best place for new interfaces used by bll In-Reply-To: <51377566.6070604@redhat.com> Message-ID: <1205420993.42301208.1362603052115.JavaMail.root@redhat.com> 1. For start, and since you are already refactoring :) I recommend putting the interfaces in package named "api" and not "interfaces" - it's a much more standard name. 2. Can you elaborate a bit more what area/functionality in engine are those interfaces for? It will reflect their location. ----- Original Message ----- > From: "Ravi Nori" > To: engine-devel at ovirt.org > Sent: Wednesday, March 6, 2013 6:57:10 PM > Subject: [Engine-devel] Best place for new interfaces used by bll > > Hi, > > I am working on refactoring some of the backend code in bll and need > to > create interfaces so that I can eliminate the dependency between bll > and > the new module. > > Currently I created the interfaces in > org.ovirt.engine.core.common.interfaces, but from what I understand > this > module is used by both frontend and backend. The new interfaces will > only be used by the backend. What would be the best place to put > these > new interfaces? > > Ravi > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Wed Mar 6 21:37:29 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 06 Mar 2013 23:37:29 +0200 Subject: [Engine-devel] [JENKINS][ANN] jenkins.ovirt.org new look and infra In-Reply-To: <2147271911.12603780.1362470486759.JavaMail.root@redhat.com> References: <2147271911.12603780.1362470486759.JavaMail.root@redhat.com> Message-ID: <5137B719.8000303@redhat.com> On 03/05/2013 10:01 AM, Eyal Edri wrote: > fyi, > > Starting from yesterday (4/3/13) jenkins.ovirt.org [1] has migrated to a new hosting server provided by alterway [2]. > the new server has a new ui look that is similar to ovirt.org and is running on stronger infra then the previous one. > > All jobs and configuration have migrated from the old instance, > but if you're still missing a certain job or permissions please contact infra team at infra at ovirt.org. > > I want to thank David caro from the infra team in helping with the migration and einav cohen from the > ovirt frontend developer community for helping with the new css for jenkins. > > > [1] http://jenkins.ovirt.org/ > [2] http://www.ovirt.org/Sponsors_and_supporters > > Eyal Edri > oVirt infra team. > _______________________________________________ > Infra mailing list > Infra at ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > finally... (and looks very nice) can we shutdown the ec2 instance for now? do we have more horsepower to start running say engine findbugs on gerrit patches? Thanks, Itamar From eedri at redhat.com Wed Mar 6 21:43:55 2013 From: eedri at redhat.com (Eyal Edri) Date: Wed, 6 Mar 2013 16:43:55 -0500 (EST) Subject: [Engine-devel] [JENKINS][ANN] jenkins.ovirt.org new look and infra In-Reply-To: <5137B719.8000303@redhat.com> Message-ID: <390390686.14058610.1362606235088.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Eyal Edri" > Cc: users at ovirt.org, "engine-devel" , vdsm-devel at lists.fedorahosted.org, "infra" > > Sent: Wednesday, March 6, 2013 11:37:29 PM > Subject: Re: [JENKINS][ANN] jenkins.ovirt.org new look and infra > > On 03/05/2013 10:01 AM, Eyal Edri wrote: > > fyi, > > > > Starting from yesterday (4/3/13) jenkins.ovirt.org [1] has migrated > > to a new hosting server provided by alterway [2]. > > the new server has a new ui look that is similar to ovirt.org and > > is running on stronger infra then the previous one. > > > > All jobs and configuration have migrated from the old instance, > > but if you're still missing a certain job or permissions please > > contact infra team at infra at ovirt.org. > > > > I want to thank David caro from the infra team in helping with the > > migration and einav cohen from the > > ovirt frontend developer community for helping with the new css for > > jenkins. > > > > > > [1] http://jenkins.ovirt.org/ > > [2] http://www.ovirt.org/Sponsors_and_supporters > > > > Eyal Edri > > oVirt infra team. > > _______________________________________________ > > Infra mailing list > > Infra at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > finally... (and looks very nice) > can we shutdown the ec2 instance for now? not yet, me & quaid should change the dns 1st (tomorrow)? and then we can do it. > do we have more horsepower to start running say engine findbugs on > gerrit patches? not really, since we're still using the same ec2 slaves. (unless we'll run it on the master, but that's not recommended in terms of security) once we'll have ovirt instance running with vms, i imagine we can. hopefully we'll have it running soon (either on alterway02 or on the rackspace servers) > > Thanks, > Itamar > From snmishra at linux.vnet.ibm.com Wed Mar 6 21:48:17 2013 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Wed, 06 Mar 2013 13:48:17 -0800 Subject: [Engine-devel] VDSM: make rpm is failing. Message-ID: <20130306134817.Horde.DBVYaJir309RN7mhs-HD5IA@imap.linux.ibm.com> Hi, Using latest VDSM source, I see make rpm failing bunch on tests. Running with 'NOSE_EXCLUDE=.*' I see the following error - ---------------------------------------------------------------------- Ran 0 tests in 0.081s OK make[4]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' make[3]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' Making check in vdsm-tool make[2]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm-tool' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm-tool' Making check in vdsm_api make[2]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm_api' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm_api' Making check in yajsonrpc make[2]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3/yajsonrpc' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/yajsonrpc' make[2]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3' make check-local make[3]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3' find . -path './.git' -prune -type f -o \ -name '*.py' -o -name '*.py.in' | xargs /usr/bin/pyflakes ./vdsm/storage/lvm.py:608: list comprehension redefines 'lv' from line 603 make[3]: *** [check-local] Error 123 make[3]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' error: Bad exit status from /var/tmp/rpm-tmp.pay1sz (%check) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.pay1sz (%check) make: *** [rpm] Error 1 From lhornyak at redhat.com Wed Mar 6 22:07:51 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Wed, 6 Mar 2013 17:07:51 -0500 (EST) Subject: [Engine-devel] VDSM: make rpm is failing. In-Reply-To: <20130306134817.Horde.DBVYaJir309RN7mhs-HD5IA@imap.linux.ibm.com> Message-ID: <1018752575.6726142.1362607671655.JavaMail.root@redhat.com> Hi Sharad, There is an update pep8 that you have to use when compiling vdsm, that may be the problem. See http://wiki.ovirt.org/Vdsm_Developers (however this document is frequently outdated) ----- Original Message ----- > From: snmishra at linux.vnet.ibm.com > To: engine-devel at ovirt.org > Sent: Wednesday, March 6, 2013 10:48:17 PM > Subject: [Engine-devel] VDSM: make rpm is failing. > > > Hi, > > Using latest VDSM source, I see make rpm failing bunch on tests. > Running with 'NOSE_EXCLUDE=.*' I see the following error - > > > ---------------------------------------------------------------------- > Ran 0 tests in 0.081s > > OK > make[4]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' > make[3]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' > make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' > Making check in vdsm-tool > make[2]: Entering directory > `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm-tool' > make[2]: Nothing to be done for `check'. > make[2]: Leaving directory > `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm-tool' > Making check in vdsm_api > make[2]: Entering directory > `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm_api' > make[2]: Nothing to be done for `check'. > make[2]: Leaving directory > `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm_api' > Making check in yajsonrpc > make[2]: Entering directory > `/root/rpmbuild/BUILD/vdsm-4.10.3/yajsonrpc' > make[2]: Nothing to be done for `check'. > make[2]: Leaving directory > `/root/rpmbuild/BUILD/vdsm-4.10.3/yajsonrpc' > make[2]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3' > make check-local > make[3]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3' > find . -path './.git' -prune -type f -o \ > -name '*.py' -o -name '*.py.in' | xargs /usr/bin/pyflakes > ./vdsm/storage/lvm.py:608: list comprehension redefines 'lv' from > line 603 > make[3]: *** [check-local] Error 123 > make[3]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' > make[2]: *** [check-am] Error 2 > make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' > make[1]: *** [check-recursive] Error 1 > make[1]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' > error: Bad exit status from /var/tmp/rpm-tmp.pay1sz (%check) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.pay1sz (%check) > make: *** [rpm] Error 1 > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From emesika at redhat.com Wed Mar 6 22:15:36 2013 From: emesika at redhat.com (Eli Mesika) Date: Wed, 6 Mar 2013 17:15:36 -0500 (EST) Subject: [Engine-devel] REST API using BASH In-Reply-To: <5137072D.6020409@redhat.com> Message-ID: <399818240.3501369.1362608136743.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Libor Spevak" > To: engine-devel at ovirt.org > Sent: Wednesday, March 6, 2013 11:06:53 AM > Subject: [Engine-devel] REST API using BASH > > > Hi, > > let me introduce some basic concepts when using REST API from the > command line. I hope, it would be useful for newcomers. Very useful in creating working instance from scratch. Are there any plans to extend it to cover more commands? Thanks > E.g. probably everybody has tried curl and then grep, sed, ... for > response, but XPath processing tool is more convenient for this > task. > > http://www.ovirt.org/REST_API_Using_BASH_Automation > > Regards, > Libor > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alonbl at redhat.com Wed Mar 6 22:19:59 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 6 Mar 2013 17:19:59 -0500 (EST) Subject: [Engine-devel] REST API using BASH In-Reply-To: <5137072D.6020409@redhat.com> Message-ID: <341058460.5422121.1362608399958.JavaMail.root@redhat.com> Hi, I recommend not using bash but standard POSIX shell. There is almost nothing that cannot be done in standard POSIX shell these days, so no need to have constraint. Regards, Alon ----- Original Message ----- > From: "Libor Spevak" > To: engine-devel at ovirt.org > Sent: Wednesday, March 6, 2013 11:06:53 AM > Subject: [Engine-devel] REST API using BASH > > > Hi, > > let me introduce some basic concepts when using REST API from the > command line. I hope, it would be useful for newcomers. > E.g. probably everybody has tried curl and then grep, sed, ... for > response, but XPath processing tool is more convenient for this > task. > > http://www.ovirt.org/REST_API_Using_BASH_Automation > > Regards, > Libor > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From kwade at redhat.com Thu Mar 7 00:34:49 2013 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 06 Mar 2013 16:34:49 -0800 Subject: [Engine-devel] [JENKINS][ANN] jenkins.ovirt.org new look and infra In-Reply-To: <390390686.14058610.1362606235088.JavaMail.root@redhat.com> References: <390390686.14058610.1362606235088.JavaMail.root@redhat.com> Message-ID: <5137E0A9.8020105@redhat.com> On 03/06/2013 01:43 PM, Eyal Edri wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> can we shutdown the ec2 instance for now? > > not yet, me & quaid should change the dns 1st (tomorrow)? > and then we can do it. If the host thinks it's already jenkins.ovirt.org, then we can just do the DNS switch "soonest". Do we need to coordinate more closely on timing? Otherwise I can just file the ticket. (I'll wait for your word before picking a time.) >> do we have more horsepower to start running say engine findbugs on >> gerrit patches? > > not really, since we're still using the same ec2 slaves. > (unless we'll run it on the master, but that's not recommended in terms of security) > once we'll have ovirt instance running with vms, i imagine we can. > hopefully we'll have it running soon (either on alterway02 or on the rackspace servers) I was supposed to be working RackSpace servers today, but I got caught up in being a bit sick and post-travel. But the plan is to load F18 + the oVirt all-in-one on rax01. - Karsten -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: OpenPGP digital signature URL: From snmishra at linux.vnet.ibm.com Thu Mar 7 01:39:33 2013 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Wed, 06 Mar 2013 17:39:33 -0800 Subject: [Engine-devel] VDSM: make rpm is failing. In-Reply-To: <1018752575.6726142.1362607671655.JavaMail.root@redhat.com> References: <1018752575.6726142.1362607671655.JavaMail.root@redhat.com> Message-ID: <20130306173933.Horde.bUxv4pir309RN_-VTTvFEBA@imap.linux.ibm.com> Quoting Laszlo Hornyak : > Hi Sharad, > > There is an update pep8 that you have to use when compiling vdsm, > that may be the problem. > See http://wiki.ovirt.org/Vdsm_Developers > (however this document is frequently outdated) I only saw reference to el6 python-pep8 on the VDSM developer page and that version (1.3.3) is older than whats installed on F18 (1.4.2). -Sharad > > > > ----- Original Message ----- >> From: snmishra at linux.vnet.ibm.com >> To: engine-devel at ovirt.org >> Sent: Wednesday, March 6, 2013 10:48:17 PM >> Subject: [Engine-devel] VDSM: make rpm is failing. >> >> >> Hi, >> >> Using latest VDSM source, I see make rpm failing bunch on tests. >> Running with 'NOSE_EXCLUDE=.*' I see the following error - >> >> >> ---------------------------------------------------------------------- >> Ran 0 tests in 0.081s >> >> OK >> make[4]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' >> make[3]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' >> make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' >> Making check in vdsm-tool >> make[2]: Entering directory >> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm-tool' >> make[2]: Nothing to be done for `check'. >> make[2]: Leaving directory >> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm-tool' >> Making check in vdsm_api >> make[2]: Entering directory >> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm_api' >> make[2]: Nothing to be done for `check'. >> make[2]: Leaving directory >> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm_api' >> Making check in yajsonrpc >> make[2]: Entering directory >> `/root/rpmbuild/BUILD/vdsm-4.10.3/yajsonrpc' >> make[2]: Nothing to be done for `check'. >> make[2]: Leaving directory >> `/root/rpmbuild/BUILD/vdsm-4.10.3/yajsonrpc' >> make[2]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >> make check-local >> make[3]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >> find . -path './.git' -prune -type f -o \ >> -name '*.py' -o -name '*.py.in' | xargs /usr/bin/pyflakes >> ./vdsm/storage/lvm.py:608: list comprehension redefines 'lv' from >> line 603 >> make[3]: *** [check-local] Error 123 >> make[3]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >> make[2]: *** [check-am] Error 2 >> make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >> make[1]: *** [check-recursive] Error 1 >> make[1]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >> error: Bad exit status from /var/tmp/rpm-tmp.pay1sz (%check) >> >> >> RPM build errors: >> Bad exit status from /var/tmp/rpm-tmp.pay1sz (%check) >> make: *** [rpm] Error 1 >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From dougsland at redhat.com Thu Mar 7 06:35:50 2013 From: dougsland at redhat.com (Douglas Landgraf) Date: Thu, 07 Mar 2013 01:35:50 -0500 Subject: [Engine-devel] VDSM: make rpm is failing. In-Reply-To: <20130306173933.Horde.bUxv4pir309RN_-VTTvFEBA@imap.linux.ibm.com> References: <1018752575.6726142.1362607671655.JavaMail.root@redhat.com> <20130306173933.Horde.bUxv4pir309RN_-VTTvFEBA@imap.linux.ibm.com> Message-ID: <51383546.7060300@redhat.com> Hi, On 03/06/2013 08:39 PM, snmishra at linux.vnet.ibm.com wrote: > > Quoting Laszlo Hornyak : > >> Hi Sharad, >> >> There is an update pep8 that you have to use when compiling vdsm, that >> may be the problem. >> See http://wiki.ovirt.org/Vdsm_Developers >> (however this document is frequently outdated) > > I only saw reference to el6 python-pep8 on the VDSM developer page and > that version (1.3.3) is older than whats installed on F18 (1.4.2). > Can you please try: http://gerrit.ovirt.org/#/c/12700/ Thanks Douglas > -Sharad > >> >> >> >> ----- Original Message ----- >>> From: snmishra at linux.vnet.ibm.com >>> To: engine-devel at ovirt.org >>> Sent: Wednesday, March 6, 2013 10:48:17 PM >>> Subject: [Engine-devel] VDSM: make rpm is failing. >>> >>> >>> Hi, >>> >>> Using latest VDSM source, I see make rpm failing bunch on tests. >>> Running with 'NOSE_EXCLUDE=.*' I see the following error - >>> >>> >>> ---------------------------------------------------------------------- >>> Ran 0 tests in 0.081s >>> >>> OK >>> make[4]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' >>> make[3]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' >>> make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' >>> Making check in vdsm-tool >>> make[2]: Entering directory >>> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm-tool' >>> make[2]: Nothing to be done for `check'. >>> make[2]: Leaving directory >>> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm-tool' >>> Making check in vdsm_api >>> make[2]: Entering directory >>> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm_api' >>> make[2]: Nothing to be done for `check'. >>> make[2]: Leaving directory >>> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm_api' >>> Making check in yajsonrpc >>> make[2]: Entering directory >>> `/root/rpmbuild/BUILD/vdsm-4.10.3/yajsonrpc' >>> make[2]: Nothing to be done for `check'. >>> make[2]: Leaving directory >>> `/root/rpmbuild/BUILD/vdsm-4.10.3/yajsonrpc' >>> make[2]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >>> make check-local >>> make[3]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >>> find . -path './.git' -prune -type f -o \ >>> -name '*.py' -o -name '*.py.in' | xargs /usr/bin/pyflakes >>> ./vdsm/storage/lvm.py:608: list comprehension redefines 'lv' from >>> line 603 >>> make[3]: *** [check-local] Error 123 >>> make[3]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >>> make[2]: *** [check-am] Error 2 >>> make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >>> make[1]: *** [check-recursive] Error 1 >>> make[1]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >>> error: Bad exit status from /var/tmp/rpm-tmp.pay1sz (%check) >>> >>> >>> RPM build errors: >>> Bad exit status from /var/tmp/rpm-tmp.pay1sz (%check) >>> make: *** [rpm] Error 1 >>> >>> _______________________________________________ >>> 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 -- Cheers Douglas From shuming at linux.vnet.ibm.com Thu Mar 7 05:39:29 2013 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Thu, 07 Mar 2013 13:39:29 +0800 Subject: [Engine-devel] function insertstorage_domain_static(uuid, ...) does not exist In-Reply-To: <20130306013738.EEDC056056E@webmail.sinamail.sina.com.cn> References: <20130306013738.EEDC056056E@webmail.sinamail.sina.com.cn> Message-ID: <51382811.1050504@linux.vnet.ibm.com> Doron, Do you get any idea about it? startup_002 at sina.cn: > Hi, > > I built the oVirt engine RPM packages from the latest oVirt engine > source code and setup a yum installation server with these packages. > I can successfully install the RPM packages on my oVirt engine test > server. But when the "engine-setup" command was used to setup the > engine sever, the following errors were encountered from engine-setup > log. It seems that inst_add_iso_storage_domain was not created > properly for psql. Any clue to this problem? > > 2013-03-05 20:02:19::DEBUG::nfsutils::192::root:: Generating unique uuid > 2013-03-05 20:02:19::DEBUG::common_utils::501::root:: running sql > query 'select inst_add_iso_storage_domain > ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', > 'ead292ee-14dd-40f9-b06b-f2250f7594a9', 'localhost.localdomain:/ISO', > 0, 0)' on db server: 'localhost'. > 2013-03-05 20:02:19::DEBUG::common_utils::454::root:: Executing > command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine -c > select inst_add_iso_storage_domain > ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', > 'ead292ee-14dd-40f9-b06b-f2250f7594a9', 'localhost.localdomain:/ISO', > 0, 0)' in working directory '/root' > 2013-03-05 20:02:19::DEBUG::common_utils::492::root:: output = > 2013-03-05 20:02:19::DEBUG::common_utils::493::root:: stderr = ERROR: > NUM:42883, DETAILS:function insertstorage_domain_static(uuid, > character varying, character varying, integer, integer, unknown, > integer) does not exist > > 2013-03-05 20:02:19::DEBUG::common_utils::494::root:: retcode = 1 > 2013-03-05 20:02:19::ERROR::engine-setup::1809::root:: Traceback (most > recent call last): > File "/bin/engine-setup", line 1804, in _configNfsShare > _addIsoDomaintoDB(controller.CONF["sd_uuid"], > controller.CONF["ISO_DOMAIN_NAME"]) > File "/bin/engine-setup", line 1860, in _addIsoDomaintoDB > utils.execRemoteSqlCommand(getDbUser(), getDbHostName(), > getDbPort(), basedefs.DB_NAME, sqlQuery, True, > output_messages.ERR_FAILED_INSERT_ISO_DOMAIN%(basedefs.DB_NAME)) > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 510, in > execRemoteSqlCommand > return execCmd(cmdList=cmd, failOnError=failOnError, msg=errMsg, > envDict=getPgEnv()) > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 497, in > execCmd > raise Exception(msg) > Exception: Failed inserting ISO domain into engine db > > 2013-03-05 20:02:19::DEBUG::setup_sequences::62::root:: Traceback > (most recent call last): > File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, > in run > function() > File "/bin/engine-setup", line 1810, in _configNfsShare > raise Exception(output_messages.ERR_FAILED_CFG_NFS_SHARE) > Exception: Failed to configure NFS share on this host > > 2013-03-05 20:02:19::DEBUG::engine-setup::1992::root:: *** The > following params were used as user input: > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > override-httpd-config: yes > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: http-port: 80 > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: https-port: 443 > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > random-passwords: no > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: mac-range: > 00:1A:4A:A8:01:00-00:1A:4A:A8:01:FF > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: host-fqdn: > localhost.localdomain > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: auth-pass: ******** > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: org-name: > localdomain > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > application-mode: virt > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > default-dc-type: NFS > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > db-remote-install: local > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-host: localhost > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-local-pass: > ******** > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: nfs-mp: /ISO > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > iso-domain-name: ISO_DOMAIN > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: config-nfs: yes > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > firewall-manager: iptables > 2013-03-05 20:02:19::ERROR::engine-setup::2413::root:: Traceback (most > recent call last): > File "/bin/engine-setup", line 2407, in > main(confFile) > File "/bin/engine-setup", line 2190, in main > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- --- ?? Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or shuming at linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanjal at redhat.com Thu Mar 7 05:45:27 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Thu, 07 Mar 2013 11:15:27 +0530 Subject: [Engine-devel] restapi - domains Message-ID: <51382977.4040801@redhat.com> Hi, We are trying to develop a simple android app to monitor and manage gluster clusters by consuming the restapi exposed by engine. The first screen is the login screen, which is similar to the webadmin login screen. Here, we want to populate the combo box of "domains" by fetching it from the restapi. However, the domains api cannot be invoked without authentication! So we have a sort of a chicken-and-egg problem. Any suggestions on how to tackle this? I feel the "domains" api should be "public", in the sense it should not expect authentication. Regards, Shireesh From yzaslavs at redhat.com Thu Mar 7 06:27:23 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 7 Mar 2013 01:27:23 -0500 (EST) Subject: [Engine-devel] Best place for new interfaces used by bll In-Reply-To: <1205420993.42301208.1362603052115.JavaMail.root@redhat.com> Message-ID: <725450053.2094556.1362637643352.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alissa Bonas" > To: rnori at redhat.com > Cc: engine-devel at ovirt.org > Sent: Wednesday, March 6, 2013 10:50:52 PM > Subject: Re: [Engine-devel] Best place for new interfaces used by bll > > 1. For start, and since you are already refactoring :) I recommend > putting the interfaces in package named "api" and not "interfaces" - > it's a much more standard name. > 2. Can you elaborate a bit more what area/functionality in engine are > those interfaces for? It will reflect their location. Yes, we're working on modularization/refactoring/improving of the async task manager. Bll will be a consumer (depend on) of async task mgr. > > ----- Original Message ----- > > From: "Ravi Nori" > > To: engine-devel at ovirt.org > > Sent: Wednesday, March 6, 2013 6:57:10 PM > > Subject: [Engine-devel] Best place for new interfaces used by bll > > > > Hi, > > > > I am working on refactoring some of the backend code in bll and > > need > > to > > create interfaces so that I can eliminate the dependency between > > bll > > and > > the new module. > > > > Currently I created the interfaces in > > org.ovirt.engine.core.common.interfaces, but from what I understand > > this > > module is used by both frontend and backend. The new interfaces > > will > > only be used by the backend. What would be the best place to put > > these > > new interfaces? > > > > Ravi > > _______________________________________________ > > 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 avishwan at redhat.com Thu Mar 7 07:35:26 2013 From: avishwan at redhat.com (Aravinda) Date: Thu, 07 Mar 2013 13:05:26 +0530 Subject: [Engine-devel] restapi - domains In-Reply-To: <51382977.4040801@redhat.com> References: <51382977.4040801@redhat.com> Message-ID: <5138433E.1030601@redhat.com> We can have only two fields in login screen, username and password. Username will include domain name(username at domain). Default domain name can be "internal" if user didn't enter the domain name as part of username then we can append the default value and validate. Note: We use username at domain as username when we connect through /api -- regards Aravinda On 03/07/2013 11:15 AM, Shireesh Anjal wrote: > Hi, > > We are trying to develop a simple android app to monitor and manage > gluster clusters by consuming the restapi exposed by engine. The first > screen is the login screen, which is similar to the webadmin login > screen. Here, we want to populate the combo box of "domains" by > fetching it from the restapi. However, the domains api cannot be > invoked without authentication! So we have a sort of a chicken-and-egg > problem. > > Any suggestions on how to tackle this? I feel the "domains" api should > be "public", in the sense it should not expect authentication. > > Regards, > Shireesh > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From vfeenstr at redhat.com Thu Mar 7 11:25:54 2013 From: vfeenstr at redhat.com (Vinzenz Feenstra) Date: Thu, 07 Mar 2013 12:25:54 +0100 Subject: [Engine-devel] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization Message-ID: <51387942.606@redhat.com> Please find the prettier version on the wiki: http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval Proposal VDSM - Engine Data Statistics Retrieval VDSM <=> Engine data retrieval optimization Motivation: Currently the RHEVM engine is polling the a lot of data from VDSM every 15 seconds. This should be optimized and the amount of data requested should be more specific. For each VM the data currently contains much more information than actually needed which blows up the size of the XML content quite big. We could optimize this by splitting the reply on the getVmStats based on the request of the engine into sections. For this reason Omer Frenkel and me have split up the data into parts based on their usage. This data can and usually does change during the lifetime of the VM. Rarely Changed: This data is change not very frequent and it should be enough to update this only once in a while. Most commonly this data changes after changes made in the UI or after a migration of the VM to another Host. *Status* = Running *acpiEnable* = true *vmType* = kvm *guestName* = W864GUESTAGENTT *displayType* = qxl *guestOs* = Win 8 *kvmEnable* = true #/*this should be constant and never changed*/ *pauseCode* = NOERR *monitorResponse* = 0 *session* = Locked # unused *netIfaces* = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': ['10.34.60.148'], 'hw': '00:1a:4a:22:3c:db'}] *appsList* = ['RHEV-Tools 3.2.4', 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 3.2.2', 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] *pid* = 11314 *guestIPs* = 10.34.60.148 # duplicated info *displayIp* = 0 *displayPort* = 5902 *displaySecurePort* = 5903 *username* = user at W864GUESTAGENTT *clientIp* = *lastLogin* = 1361976900.67 Often Changed: This data is changed quite often however it is not necessary to update this data every 15 seconds. As this is cumulative data and reflects the current status, and it does not need to be snapshotted every 15 seconds to retrieve statistics. The data can be retrieved in much more generous time slices. (e.g. Every 5 minutes) *network* = {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': 'vnet1'}} *disksUsage* = [{'path': 'c:\\', 'total': '64055406592', 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': '3490912256', 'fs': 'UDF', 'used': '3490912256'}] *timeOffset* = 14422 *elapsedTime* = 68591 *hash* = 2335461227228498964 *statsAge* = 0.09 # unused Often Changed but unused This data does not seem to be used in the engine at all. It is *not* even used in the data warehouse. *memoryStats* = {'swap_out': '0', 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', 'pageflt': '0', 'mem_total': '2096736', 'mem_unused': '1466884'} *balloonInfo* = {'balloon_max': 2097152, 'balloon_cur': 2097152} *disks* = {'vda': {'readLatency': '0', 'apparentsize': '64424509440', 'writeLatency': '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', 'flushLatency': '156549', 'readRate': '0.00', 'truesize': '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': '0', 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very frequent uppdates needed by webadmin portal: This data is mostly needed for the webadmin portal and might be required to be updated quite often. An exception here is the statsAge field, which seems to be unused by the Engine. This data could be requested every 15 seconds to keep things as they are now. *cpuSys* = 2.32 *cpuUser* = 1.34 *memUsage* = 30 Proposed Solution for VDSM & Engine: We will introduce new optional parameters to getVmStats, getAllVmStats and list to allow a finer grained specification of data which should be included. *Parameter:* *statsType*=/**/ (getVmStats, getAllVmStats only) *Allowed values:* * full (default to keep backwards compatibility) * app-list (Just send the application list) * rare (include everything from rarely changed to very frequent) * often (include everything from often changed to very frequent) * frequent (only send the very frequently changed items) *Parameter:* *clientId*=** The client id is specified by the client and should be unique however constantly used. *Parameter:* *diff*=** In combination with the clientId VDSM will send only differences to the previous request from the named clientId. (if diff=true) Additional Change: Besides the introduction of the new parameters for list, getVmStats and getAllVmStats it might make sense to include a hash for the appList into the rarely changed section of the response which would allow to identify changes and avoid having to sent the complete appList every so often and only if the hash known to the client is outdated. *Note:* The appList (Application List) reported by the guest agent could be fully implemented on request only, as long as the guest agent installed supports this. As there seems to be a request to have the complete list of installed applications on all guests this data could be quite extensive and a huge list. On the other hand this data is only rarely visible and therefore it should not be requested all the time and only on demand. Improvement of the Guest Agent: As part of the proposed solution it is necessary to improve the guest agent as well. For the full application list there should be implemented a caching system which will be fully reactive and should not poll the application list for example all the time. The guest can create a prepared data file containing all data in the JSON format (as used for the communication with VDSM via VIO) and just have to read that file from disk and directly sends it to VDSM. However it is quite possible that this list is to big and it might have to be chunked into pieces. (Multiple messages, which would have to be supported by VDSM then as well) The solution for this is to make VDSM request this data and it will retrieve the data necessary on request only. -- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpastern at redhat.com Thu Mar 7 11:32:31 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 07 Mar 2013 13:32:31 +0200 Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.5-1 released Message-ID: <51387ACF.9040705@redhat.com> - use explicit classloader for JAXBContext - implement support for (user defined) session authentication - implement generic JAXBElement generation - to DataCenterStorageDomain added Disks sub-collection - to StorageDomain added Disks sub-collection - to host added display.address property - to vms.add() added overload for creating vm from snapshot More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Thu Mar 7 11:37:10 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 07 Mar 2013 13:37:10 +0200 Subject: [Engine-devel] Improvement for the oVirt java sdk In-Reply-To: References: <51331B7A.5020009@redhat.com> Message-ID: <51387BE6.4060707@redhat.com> On 03/04/2013 05:26 PM, Morrissey, Christopher wrote: > Hi Michael, > > Yes, that is the case here. I'm getting the JSESSIONID from the client and passing it to our server > so that it can perform REST-API calls back to oVirt under the logged in user's authenticated session. done, see http://lists.ovirt.org/pipermail/users/2013-March/012969.html > > -Chris > >> -----Original Message----- >> From: Michael Pasternak [mailto:mpastern at redhat.com] >> Sent: Sunday, March 03, 2013 4:44 AM >> To: Morrissey, Christopher >> Cc: users at ovirt.org; engine-devel >> Subject: Re: Improvement for the oVirt java sdk >> >> >> Hi Christopher, >> >> In general SDK abstracts the transport layer, therefore all authentication >> internals hidden from the user, >> >> i.e SESSION based authentication happens implicitly (by default), when you >> initiate SDK entry point, >> >> the story is different if you want using SSO-like login by reusing JSESSIONID >> from the REST-API for instance, and i can support such scenario, >> >> but, is this your case? >> >> On 02/28/2013 10:04 PM, Morrissey, Christopher wrote: >>> Hi Michael, >>> >>> I'm looking to use the oVirt java sdk for connecting into oVirt from >>> our server. However, we have a UI plugin that gets access to a session >>> ID that we should be able to use to connect through the REST API >>> instead of the username and password. Any chance the sdk could be >> updated to take the session ID and create a connection vs. a user name and >> password? >>> >>> -Chris >>> >>> Chris Morrissey >>> Software Engineer >>> NetApp Inc. >>> 919.476.4428 >>> >>> >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D -- Michael Pasternak RedHat, ENG-Virtualization R&D From bazulay at redhat.com Thu Mar 7 11:43:00 2013 From: bazulay at redhat.com (Barak Azulay) Date: Thu, 7 Mar 2013 06:43:00 -0500 (EST) Subject: [Engine-devel] function insertstorage_domain_static(uuid, ...) does not exist In-Reply-To: <51382811.1050504@linux.vnet.ibm.com> Message-ID: <1652690059.16213732.1362656580979.JavaMail.root@redhat.com> Shu, A few notes. 1 - you are tring to create iso domain on / 'select ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', 'ead292ee-14dd-40f9-b06b-f2250f7594a9', 'localhost.localdomain:/ISO', 0, 0)' 2 - your host name is localhost.localdomain But those doesn't look like the real problem here. I assume you are running it on F18 ? Can we get the full installation log? Thanks Barak ----- Original Message ----- > From: "Shu Ming" > To: engine-devel at ovirt.org, "Doron Fediuck" > Sent: Thursday, March 7, 2013 7:39:29 AM > Subject: Re: [Engine-devel] function insertstorage_domain_static(uuid, ...) does not exist > > > > Doron, > > Do you get any idea about it? > > startup_002 at sina.cn : > > > > Hi, > > I built the oVirt engine RPM packages from the latest oVirt engine > source code and setup a yum installation server with these packages. > I can successfully install the RPM packages on my oVirt engine test > server. But when the "engine-setup" command was used to setup the > engine sever, the following errors were encountered from > engine-setup log. It seems that inst_add_iso_storage_domain was not > created properly for psql. Any clue to this problem? > > 2013-03-05 20:02:19::DEBUG::nfsutils::192::root:: Generating unique > uuid > 2013-03-05 20:02:19::DEBUG::common_utils::501::root:: running sql > query 'select inst_add_iso_storage_domain > ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', > 'ead292ee-14dd-40f9-b06b-f2250f7594a9', > 'localhost.localdomain:/ISO', 0, 0)' on db server: 'localhost'. > 2013-03-05 20:02:19::DEBUG::common_utils::454::root:: Executing > command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine > -c select inst_add_iso_storage_domain > ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', > 'ead292ee-14dd-40f9-b06b-f2250f7594a9', > 'localhost.localdomain:/ISO', 0, 0)' in working directory '/root' > 2013-03-05 20:02:19::DEBUG::common_utils::492::root:: output = > 2013-03-05 20:02:19::DEBUG::common_utils::493::root:: stderr = ERROR: > NUM:42883, DETAILS:function insertstorage_domain_static(uuid, > character varying, character varying, integer, integer, unknown, > integer) does not exist > > 2013-03-05 20:02:19::DEBUG::common_utils::494::root:: retcode = 1 > 2013-03-05 20:02:19::ERROR::engine-setup::1809::root:: Traceback > (most recent call last): > File "/bin/engine-setup", line 1804, in _configNfsShare > _addIsoDomaintoDB(controller.CONF["sd_uuid"], > controller.CONF["ISO_DOMAIN_NAME"]) > File "/bin/engine-setup", line 1860, in _addIsoDomaintoDB > utils.execRemoteSqlCommand(getDbUser(), getDbHostName(), getDbPort(), > basedefs.DB_NAME, sqlQuery, True, > output_messages.ERR_FAILED_INSERT_ISO_DOMAIN%(basedefs.DB_NAME)) > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 510, in > execRemoteSqlCommand > return execCmd(cmdList=cmd, failOnError=failOnError, msg=errMsg, > envDict=getPgEnv()) > File "/usr/share/ovirt-engine/scripts/common_utils.py", line 497, in > execCmd > raise Exception(msg) > Exception: Failed inserting ISO domain into engine db > > 2013-03-05 20:02:19::DEBUG::setup_sequences::62::root:: Traceback > (most recent call last): > File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, > in run > function() > File "/bin/engine-setup", line 1810, in _configNfsShare > raise Exception(output_messages.ERR_FAILED_CFG_NFS_SHARE) > Exception: Failed to configure NFS share on this host > > 2013-03-05 20:02:19::DEBUG::engine-setup::1992::root:: *** The > following params were used as user input: > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > override-httpd-config: yes > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: http-port: 80 > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: https-port: > 443 > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > random-passwords: no > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: mac-range: > 00:1A:4A:A8:01:00-00:1A:4A:A8:01:FF > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: host-fqdn: > localhost.localdomain > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: auth-pass: > ******** > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: org-name: > localdomain > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > application-mode: virt > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > default-dc-type: NFS > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > db-remote-install: local > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-host: > localhost > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-local-pass: > ******** > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: nfs-mp: /ISO > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > iso-domain-name: ISO_DOMAIN > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: config-nfs: > yes > 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > firewall-manager: iptables > 2013-03-05 20:02:19::ERROR::engine-setup::2413::root:: Traceback > (most recent call last): > File "/bin/engine-setup", line 2407, in > main(confFile) > File "/bin/engine-setup", line 2190, in main > > > _______________________________________________ > Engine-devel mailing list Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > -- > --- > ?? Shu Ming > Open Virtualization Engineerning; CSTL, IBM Corp. > Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or > shuming at linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun > Software Park, Haidian District, Beijing 100193, PRC > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From jhernand at redhat.com Thu Mar 7 12:00:51 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Thu, 07 Mar 2013 13:00:51 +0100 Subject: [Engine-devel] function insertstorage_domain_static(uuid, ...) does not exist In-Reply-To: <1652690059.16213732.1362656580979.JavaMail.root@redhat.com> References: <1652690059.16213732.1362656580979.JavaMail.root@redhat.com> Message-ID: <51388173.70508@redhat.com> On 03/07/2013 12:43 PM, Barak Azulay wrote: > Shu, > > A few notes. > > 1 - you are tring to create iso domain on / > 'select ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', 'ead292ee-14dd-40f9-b06b-f2250f7594a9', 'localhost.localdomain:/ISO', 0, 0)' > 2 - your host name is localhost.localdomain > > But those doesn't look like the real problem here. > > I assume you are running it on F18 ? > > Can we get the full installation log? > > Thanks > Barak Commit 5ca1ec0337d921f1057321da2688ad2a014b8ffb added a parameter to the stored procedure, but engine-setup calls inst_add_iso_storage_domain (in inst_sp.sql) which in turn calls insertstorage_domain_static, and that call hasn't been updated. > > > > > > > > ----- Original Message ----- >> From: "Shu Ming" >> To: engine-devel at ovirt.org, "Doron Fediuck" >> Sent: Thursday, March 7, 2013 7:39:29 AM >> Subject: Re: [Engine-devel] function insertstorage_domain_static(uuid, ...) does not exist >> >> >> >> Doron, >> >> Do you get any idea about it? >> >> startup_002 at sina.cn : >> >> >> >> Hi, >> >> I built the oVirt engine RPM packages from the latest oVirt engine >> source code and setup a yum installation server with these packages. >> I can successfully install the RPM packages on my oVirt engine test >> server. But when the "engine-setup" command was used to setup the >> engine sever, the following errors were encountered from >> engine-setup log. It seems that inst_add_iso_storage_domain was not >> created properly for psql. Any clue to this problem? >> >> 2013-03-05 20:02:19::DEBUG::nfsutils::192::root:: Generating unique >> uuid >> 2013-03-05 20:02:19::DEBUG::common_utils::501::root:: running sql >> query 'select inst_add_iso_storage_domain >> ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', >> 'ead292ee-14dd-40f9-b06b-f2250f7594a9', >> 'localhost.localdomain:/ISO', 0, 0)' on db server: 'localhost'. >> 2013-03-05 20:02:19::DEBUG::common_utils::454::root:: Executing >> command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine >> -c select inst_add_iso_storage_domain >> ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', >> 'ead292ee-14dd-40f9-b06b-f2250f7594a9', >> 'localhost.localdomain:/ISO', 0, 0)' in working directory '/root' >> 2013-03-05 20:02:19::DEBUG::common_utils::492::root:: output = >> 2013-03-05 20:02:19::DEBUG::common_utils::493::root:: stderr = ERROR: >> NUM:42883, DETAILS:function insertstorage_domain_static(uuid, >> character varying, character varying, integer, integer, unknown, >> integer) does not exist >> >> 2013-03-05 20:02:19::DEBUG::common_utils::494::root:: retcode = 1 >> 2013-03-05 20:02:19::ERROR::engine-setup::1809::root:: Traceback >> (most recent call last): >> File "/bin/engine-setup", line 1804, in _configNfsShare >> _addIsoDomaintoDB(controller.CONF["sd_uuid"], >> controller.CONF["ISO_DOMAIN_NAME"]) >> File "/bin/engine-setup", line 1860, in _addIsoDomaintoDB >> utils.execRemoteSqlCommand(getDbUser(), getDbHostName(), getDbPort(), >> basedefs.DB_NAME, sqlQuery, True, >> output_messages.ERR_FAILED_INSERT_ISO_DOMAIN%(basedefs.DB_NAME)) >> File "/usr/share/ovirt-engine/scripts/common_utils.py", line 510, in >> execRemoteSqlCommand >> return execCmd(cmdList=cmd, failOnError=failOnError, msg=errMsg, >> envDict=getPgEnv()) >> File "/usr/share/ovirt-engine/scripts/common_utils.py", line 497, in >> execCmd >> raise Exception(msg) >> Exception: Failed inserting ISO domain into engine db >> >> 2013-03-05 20:02:19::DEBUG::setup_sequences::62::root:: Traceback >> (most recent call last): >> File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, >> in run >> function() >> File "/bin/engine-setup", line 1810, in _configNfsShare >> raise Exception(output_messages.ERR_FAILED_CFG_NFS_SHARE) >> Exception: Failed to configure NFS share on this host >> >> 2013-03-05 20:02:19::DEBUG::engine-setup::1992::root:: *** The >> following params were used as user input: >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> override-httpd-config: yes >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: http-port: 80 >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: https-port: >> 443 >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> random-passwords: no >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: mac-range: >> 00:1A:4A:A8:01:00-00:1A:4A:A8:01:FF >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: host-fqdn: >> localhost.localdomain >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: auth-pass: >> ******** >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: org-name: >> localdomain >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> application-mode: virt >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> default-dc-type: NFS >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> db-remote-install: local >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-host: >> localhost >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-local-pass: >> ******** >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: nfs-mp: /ISO >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> iso-domain-name: ISO_DOMAIN >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: config-nfs: >> yes >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> firewall-manager: iptables >> 2013-03-05 20:02:19::ERROR::engine-setup::2413::root:: Traceback >> (most recent call last): >> File "/bin/engine-setup", line 2407, in >> main(confFile) >> File "/bin/engine-setup", line 2190, in main >> >> >> _______________________________________________ >> Engine-devel mailing list Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> -- >> --- >> ?? Shu Ming >> Open Virtualization Engineerning; CSTL, IBM Corp. >> Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or >> shuming at linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun >> Software Park, Haidian District, Beijing 100193, PRC >> _______________________________________________ >> 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 Christopher.Morrissey at netapp.com Thu Mar 7 14:53:37 2013 From: Christopher.Morrissey at netapp.com (Morrissey, Christopher) Date: Thu, 7 Mar 2013 14:53:37 +0000 Subject: [Engine-devel] Improvement for the oVirt java sdk In-Reply-To: <51387BE6.4060707@redhat.com> References: <51331B7A.5020009@redhat.com> <51387BE6.4060707@redhat.com> Message-ID: -Chris > -----Original Message----- > From: Michael Pasternak [mailto:mpastern at redhat.com] > Sent: Thursday, March 07, 2013 6:37 AM > To: Morrissey, Christopher > Cc: users at ovirt.org; engine-devel > Subject: Re: Improvement for the oVirt java sdk > > On 03/04/2013 05:26 PM, Morrissey, Christopher wrote: > > Hi Michael, > > > > Yes, that is the case here. I'm getting the JSESSIONID from the client > > and passing it to our server so that it can perform REST-API calls back to > oVirt under the logged in user's authenticated session. > > done, see http://lists.ovirt.org/pipermail/users/2013-March/012969.html Thanks for the very quick implementation! I'll give it a try shortly. > > > > > -Chris > > > >> -----Original Message----- > >> From: Michael Pasternak [mailto:mpastern at redhat.com] > >> Sent: Sunday, March 03, 2013 4:44 AM > >> To: Morrissey, Christopher > >> Cc: users at ovirt.org; engine-devel > >> Subject: Re: Improvement for the oVirt java sdk > >> > >> > >> Hi Christopher, > >> > >> In general SDK abstracts the transport layer, therefore all > >> authentication internals hidden from the user, > >> > >> i.e SESSION based authentication happens implicitly (by default), > >> when you initiate SDK entry point, > >> > >> the story is different if you want using SSO-like login by reusing > >> JSESSIONID from the REST-API for instance, and i can support such > >> scenario, > >> > >> but, is this your case? > >> > >> On 02/28/2013 10:04 PM, Morrissey, Christopher wrote: > >>> Hi Michael, > >>> > >>> I'm looking to use the oVirt java sdk for connecting into oVirt from > >>> our server. However, we have a UI plugin that gets access to a > >>> session ID that we should be able to use to connect through the REST > >>> API instead of the username and password. Any chance the sdk could > >>> be > >> updated to take the session ID and create a connection vs. a user > >> name and password? > >>> > >>> -Chris > >>> > >>> Chris Morrissey > >>> Software Engineer > >>> NetApp Inc. > >>> 919.476.4428 > >>> > >>> > >> > >> > >> -- > >> > >> Michael Pasternak > >> RedHat, ENG-Virtualization R&D > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D From startup_002 at sina.cn Thu Mar 7 15:25:21 2013 From: startup_002 at sina.cn (startup_002 at sina.cn) Date: Thu, 07 Mar 2013 23:25:21 +0800 Subject: [Engine-devel] =?gbk?b?16q3oqO6UmU6ICBmdW5jdGlvbiBpbnNlcnRzdG9y?= =?gbk?b?YWdlX2RvbWFpbl9zdGF0aWModXVpZCwgLi4uKSBkb2VzIG5vdCBleGlz?= =?gbk?q?t?= Message-ID: <20130307152521.DA7904600CC@webmail.sinamail.sina.com.cn> Juan, Thanks for your answer. Can you provide more details on how I can fix this problem? I think engine-setup is built from the ovirt engine workspace and It should call the new interface properly. I am confused why engine-setup--->inst_add_iso_storage_domai---->insertstorage_domain_static was not updated based on the new interface losing one parameter. Is that a bug in the workspace introduced by the commit? ----- ???? ----- ????Juan Hernandez ????Juan Hernandez ????engine-devel at ovirt.org ???Re: [Engine-devel] function insertstorage_domain_static(uuid, ...) does not exist ???2013?03?07? 20?00? On 03/07/2013 12:43 PM, Barak Azulay wrote: > Shu, > > A few notes. > > 1 - you are tring to create iso domain on / > 'select ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', 'ead292ee-14dd-40f9-b06b-f2250f7594a9', 'localhost.localdomain:/ISO', 0, 0)' > 2 - your host name is localhost.localdomain > > But those doesn't look like the real problem here. > > I assume you are running it on F18 ? > > Can we get the full installation log? > > Thanks > Barak Commit 5ca1ec0337d921f1057321da2688ad2a014b8ffb added a parameter to the stored procedure, but engine-setup calls inst_add_iso_storage_domain (in inst_sp.sql) which in turn calls insertstorage_domain_static, and that call hasn't been updated. > > > > > > > > ----- Original Message ----- >> From: "Shu Ming" >> To: engine-devel at ovirt.org, "Doron Fediuck" >> Sent: Thursday, March 7, 2013 7:39:29 AM >> Subject: Re: [Engine-devel] function insertstorage_domain_static(uuid, ...) does not exist >> >> >> >> Doron, >> >> Do you get any idea about it? >> >> startup_002 at sina.cn : >> >> >> >> Hi, >> >> I built the oVirt engine RPM packages from the latest oVirt engine >> source code and setup a yum installation server with these packages. >> I can successfully install the RPM packages on my oVirt engine test >> server. But when the "engine-setup" command was used to setup the >> engine sever, the following errors were encountered from >> engine-setup log. It seems that inst_add_iso_storage_domain was not >> created properly for psql. Any clue to this problem? >> >> 2013-03-05 20:02:19::DEBUG::nfsutils::192::root:: Generating unique >> uuid >> 2013-03-05 20:02:19::DEBUG::common_utils::501::root:: running sql >> query 'select inst_add_iso_storage_domain >> ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', >> 'ead292ee-14dd-40f9-b06b-f2250f7594a9', >> 'localhost.localdomain:/ISO', 0, 0)' on db server: 'localhost'. >> 2013-03-05 20:02:19::DEBUG::common_utils::454::root:: Executing >> command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine >> -c select inst_add_iso_storage_domain >> ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', >> 'ead292ee-14dd-40f9-b06b-f2250f7594a9', >> 'localhost.localdomain:/ISO', 0, 0)' in working directory '/root' >> 2013-03-05 20:02:19::DEBUG::common_utils::492::root:: output = >> 2013-03-05 20:02:19::DEBUG::common_utils::493::root:: stderr = ERROR: >> NUM:42883, DETAILS:function insertstorage_domain_static(uuid, >> character varying, character varying, integer, integer, unknown, >> integer) does not exist >> >> 2013-03-05 20:02:19::DEBUG::common_utils::494::root:: retcode = 1 >> 2013-03-05 20:02:19::ERROR::engine-setup::1809::root:: Traceback >> (most recent call last): >> File "/bin/engine-setup", line 1804, in _configNfsShare >> _addIsoDomaintoDB(controller.CONF["sd_uuid"], >> controller.CONF["ISO_DOMAIN_NAME"]) >> File "/bin/engine-setup", line 1860, in _addIsoDomaintoDB >> utils.execRemoteSqlCommand(getDbUser(), getDbHostName(), getDbPort(), >> basedefs.DB_NAME, sqlQuery, True, >> output_messages.ERR_FAILED_INSERT_ISO_DOMAIN%(basedefs.DB_NAME)) >> File "/usr/share/ovirt-engine/scripts/common_utils.py", line 510, in >> execRemoteSqlCommand >> return execCmd(cmdList=cmd, failOnError=failOnError, msg=errMsg, >> envDict=getPgEnv()) >> File "/usr/share/ovirt-engine/scripts/common_utils.py", line 497, in >> execCmd >> raise Exception(msg) >> Exception: Failed inserting ISO domain into engine db >> >> 2013-03-05 20:02:19::DEBUG::setup_sequences::62::root:: Traceback >> (most recent call last): >> File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, >> in run >> function() >> File "/bin/engine-setup", line 1810, in _configNfsShare >> raise Exception(output_messages.ERR_FAILED_CFG_NFS_SHARE) >> Exception: Failed to configure NFS share on this host >> >> 2013-03-05 20:02:19::DEBUG::engine-setup::1992::root:: *** The >> following params were used as user input: >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> override-httpd-config: yes >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: http-port: 80 >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: https-port: >> 443 >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> random-passwords: no >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: mac-range: >> 00:1A:4A:A8:01:00-00:1A:4A:A8:01:FF >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: host-fqdn: >> localhost.localdomain >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: auth-pass: >> ******** >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: org-name: >> localdomain >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> application-mode: virt >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> default-dc-type: NFS >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> db-remote-install: local >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-host: >> localhost >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-local-pass: >> ******** >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: nfs-mp: /ISO >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> iso-domain-name: ISO_DOMAIN >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: config-nfs: >> yes >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: >> firewall-manager: iptables >> 2013-03-05 20:02:19::ERROR::engine-setup::2413::root:: Traceback >> (most recent call last): >> File "/bin/engine-setup", line 2407, in >> main(confFile) >> File "/bin/engine-setup", line 2190, in main >> >> >> _______________________________________________ >> Engine-devel mailing list Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> -- >> --- >> ?? Shu Ming >> Open Virtualization Engineerning; CSTL, IBM Corp. >> Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or >> shuming at linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun >> Software Park, Haidian District, Beijing 100193, PRC >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eedri at redhat.com Thu Mar 7 15:29:04 2013 From: eedri at redhat.com (Eyal Edri) Date: Thu, 7 Mar 2013 10:29:04 -0500 (EST) Subject: [Engine-devel] [JENKINS][ANN] jenkins.ovirt.org new look and infra In-Reply-To: <5137E0A9.8020105@redhat.com> Message-ID: <1345421098.14568886.1362670144501.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Karsten 'quaid' Wade" > To: "Eyal Edri" > Cc: "Itamar Heim" , users at ovirt.org, "engine-devel" , > vdsm-devel at lists.fedorahosted.org, "infra" > Sent: Thursday, March 7, 2013 2:34:49 AM > Subject: Re: [JENKINS][ANN] jenkins.ovirt.org new look and infra > > On 03/06/2013 01:43 PM, Eyal Edri wrote: > > > > > > ----- Original Message ----- > >> From: "Itamar Heim" > >> can we shutdown the ec2 instance for now? > > > > not yet, me & quaid should change the dns 1st (tomorrow)? > > and then we can do it. > > If the host thinks it's already jenkins.ovirt.org, then we can just > do > the DNS switch "soonest". Do we need to coordinate more closely on > timing? Otherwise I can just file the ticket. (I'll wait for your > word > before picking a time.) i think we're OK with moving it: i changed all configuration files & hostname on alterway01 to be jenkins.ovirt.org, so we just need to point jenkins.ovirt.org to alterway01.ovirt.org (ip) in dns i belive. so go a head and open the ticket. itamar, let's wait with deleting the vm until we're sure it's OK? > > >> do we have more horsepower to start running say engine findbugs on > >> gerrit patches? > > > > not really, since we're still using the same ec2 slaves. > > (unless we'll run it on the master, but that's not recommended in > > terms of security) > > once we'll have ovirt instance running with vms, i imagine we can. > > hopefully we'll have it running soon (either on alterway02 or on > > the rackspace servers) > > I was supposed to be working RackSpace servers today, but I got > caught > up in being a bit sick and post-travel. But the plan is to load F18 + > the oVirt all-in-one on rax01. > > - Karsten > -- > Karsten 'quaid' Wade, Sr. Analyst - Community Growth > http://TheOpenSourceWay.org .^\ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > > From abonas at redhat.com Thu Mar 7 15:31:03 2013 From: abonas at redhat.com (Alissa Bonas) Date: Thu, 7 Mar 2013 10:31:03 -0500 (EST) Subject: [Engine-devel] Best place for new interfaces used by bll In-Reply-To: <725450053.2094556.1362637643352.JavaMail.root@redhat.com> Message-ID: <1886727311.42715380.1362670263892.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Alissa Bonas" > Cc: engine-devel at ovirt.org, rnori at redhat.com > Sent: Thursday, March 7, 2013 8:27:23 AM > Subject: Re: [Engine-devel] Best place for new interfaces used by bll > > > > ----- Original Message ----- > > From: "Alissa Bonas" > > To: rnori at redhat.com > > Cc: engine-devel at ovirt.org > > Sent: Wednesday, March 6, 2013 10:50:52 PM > > Subject: Re: [Engine-devel] Best place for new interfaces used by > > bll > > > > 1. For start, and since you are already refactoring :) I recommend > > putting the interfaces in package named "api" and not "interfaces" > > - > > it's a much more standard name. > > 2. Can you elaborate a bit more what area/functionality in engine > > are > > those interfaces for? It will reflect their location. > > Yes, we're working on modularization/refactoring/improving of the > async task manager. > Bll will be a consumer (depend on) of async task mgr. >From going briefly over the packages in "common" module, it seems that there are 2 types of code there- code really in use by backend and frontend, and code used only by the backend. So part of the code residing there is not really "common". My suggestion is to take out that non common code from "common" (along with async task mgr which is also not common), and create a new module (names - core? infra? ) on which only backend/bll will depend. > > > > ----- Original Message ----- > > > From: "Ravi Nori" > > > To: engine-devel at ovirt.org > > > Sent: Wednesday, March 6, 2013 6:57:10 PM > > > Subject: [Engine-devel] Best place for new interfaces used by bll > > > > > > Hi, > > > > > > I am working on refactoring some of the backend code in bll and > > > need > > > to > > > create interfaces so that I can eliminate the dependency between > > > bll > > > and > > > the new module. > > > > > > Currently I created the interfaces in > > > org.ovirt.engine.core.common.interfaces, but from what I > > > understand > > > this > > > module is used by both frontend and backend. The new interfaces > > > will > > > only be used by the backend. What would be the best place to put > > > these > > > new interfaces? > > > > > > Ravi > > > _______________________________________________ > > > 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 Thu Mar 7 15:40:39 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Thu, 07 Mar 2013 16:40:39 +0100 Subject: [Engine-devel] =?utf-8?b?6L2s5Y+R77yaUmU6ICBmdW5jdGlvbiBpbnNlcnRz?= =?utf-8?q?torage=5Fdomain=5Fstatic=28uuid=2C_=2E=2E=2E=29_does_not_exist?= In-Reply-To: <20130307152521.DA7904600CC@webmail.sinamail.sina.com.cn> References: <20130307152521.DA7904600CC@webmail.sinamail.sina.com.cn> Message-ID: <5138B4F7.6000209@redhat.com> On 03/07/2013 04:25 PM, startup_002 at sina.cn wrote: > Juan, > > Thanks for your answer. Can you provide more details on how I can fix > this problem? I think engine-setup is built from the ovirt engine > workspace and It should call the new interface properly. I am > confused why > engine-setup--->inst_add_iso_storage_domai---->insertstorage_domain_static > was not updated based on the new interface losing one parameter. Is > that a bug in the workspace introduced by the commit? > Yes, I think it is a bug. To workaround it try to add the new parameter to the inst_sp.sql file. In line 31 you will see this: perform Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id as varchar(250)),v_name,1,2,'0',0); I think it can be fixed adding the new parameter as follows: perform Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id as varchar(250)),v_name,v_name,1,2,'0',0); This is just using the name of the storage domain as description. Once you have modified that file you will have to repeat the installation. If that solves the problem then we may need to apply the following patch to the source code: diff --git a/backend/manager/dbscripts/inst_sp.sql b/backend/manager/dbscripts/inst_sp.sql index 82e8502..a4dcd20 100644 --- a/backend/manager/dbscripts/inst_sp.sql +++ b/backend/manager/dbscripts/inst_sp.sql @@ -28,7 +28,7 @@ BEGIN -- Insert storage server connection info perform Insertstorage_server_connections(v_connection,cast(v_connection_id as varchar(250)),NULL,NULL,NULL,NULL,1,NULL,NULL,N -- Insert storage domain static info - perform Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id as varchar(250)),v_name,1,2,'0',0); + perform Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id as varchar(250)),v_name,v_name,1,2,'0',0); -- Insert storage domain dynamic info perform Insertstorage_domain_dynamic(v_available,v_storage_domain_id,v_used); end if; Would you mind submitting it to gerrit? > ----- ???? ----- > ????Juan Hernandez > ????Juan Hernandez > ????engine-devel at ovirt.org > ???Re: [Engine-devel] function insertstorage_domain_static(uuid, ...) > does not exist > ???2013?03?07? 20?00? > > On 03/07/2013 12:43 PM, Barak Azulay wrote: > > Shu, > > > > A few notes. > > > > 1 - you are tring to create iso domain on / > > 'select ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', > 'ead292ee-14dd-40f9-b06b-f2250f7594a9', 'localhost.localdomain:/ISO', 0, 0)' > > 2 - your host name is localhost.localdomain > > > > But those doesn't look like the real problem here. > > > > I assume you are running it on F18 ? > > > > Can we get the full installation log? > > > > Thanks > > Barak > Commit 5ca1ec0337d921f1057321da2688ad2a014b8ffb added a parameter to the > stored procedure, but engine-setup calls inst_add_iso_storage_domain > (in inst_sp.sql) which in turn calls insertstorage_domain_static, and > that call hasn't been updated. > > > > > > > > > > > > > > > > ----- Original Message ----- > >> From: "Shu Ming" > >> To: engine-devel at ovirt.org, "Doron Fediuck" > >> Sent: Thursday, March 7, 2013 7:39:29 AM > >> Subject: Re: [Engine-devel] function > insertstorage_domain_static(uuid, ...) does not exist > >> > >> > >> > >> Doron, > >> > >> Do you get any idea about it? > >> > >> startup_002 at sina.cn : > >> > >> > >> > >> Hi, > >> > >> I built the oVirt engine RPM packages from the latest oVirt engine > >> source code and setup a yum installation server with these packages. > >> I can successfully install the RPM packages on my oVirt engine test > >> server. But when the "engine-setup" command was used to setup the > >> engine sever, the following errors were encountered from > >> engine-setup log. It seems that inst_add_iso_storage_domain was not > >> created properly for psql. Any clue to this problem? > >> > >> 2013-03-05 20:02:19::DEBUG::nfsutils::192::root:: Generating unique > >> uuid > >> 2013-03-05 20:02:19::DEBUG::common_utils::501::root:: running sql > >> query 'select inst_add_iso_storage_domain > >> ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', > >> 'ead292ee-14dd-40f9-b06b-f2250f7594a9', > >> 'localhost.localdomain:/ISO', 0, 0)' on db server: 'localhost'. > >> 2013-03-05 20:02:19::DEBUG::common_utils::454::root:: Executing > >> command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine > >> -c select inst_add_iso_storage_domain > >> ('ab22b419-6381-4f0a-8b46-aa72c81edbb5', 'ISO_DOMAIN', > >> 'ead292ee-14dd-40f9-b06b-f2250f7594a9', > >> 'localhost.localdomain:/ISO', 0, 0)' in working directory '/root' > >> 2013-03-05 20:02:19::DEBUG::common_utils::492::root:: output = > >> 2013-03-05 20:02:19::DEBUG::common_utils::493::root:: stderr = ERROR: > >> NUM:42883, DETAILS:function insertstorage_domain_static(uuid, > >> character varying, character varying, integer, integer, unknown, > >> integer) does not exist > >> > >> 2013-03-05 20:02:19::DEBUG::common_utils::494::root:: retcode = 1 > >> 2013-03-05 20:02:19::ERROR::engine-setup::1809::root:: Traceback > >> (most recent call last): > >> File "/bin/engine-setup", line 1804, in _configNfsShare > >> _addIsoDomaintoDB(controller.CONF["sd_uuid"], > >> controller.CONF["ISO_DOMAIN_NAME"]) > >> File "/bin/engine-setup", line 1860, in _addIsoDomaintoDB > >> utils.execRemoteSqlCommand(getDbUser(), getDbHostName(), getDbPort(), > >> basedefs.DB_NAME, sqlQuery, True, > >> output_messages.ERR_FAILED_INSERT_ISO_DOMAIN%(basedefs.DB_NAME)) > >> File "/usr/share/ovirt-engine/scripts/common_utils.py", line 510, in > >> execRemoteSqlCommand > >> return execCmd(cmdList=cmd, failOnError=failOnError, msg=errMsg, > >> envDict=getPgEnv()) > >> File "/usr/share/ovirt-engine/scripts/common_utils.py", line 497, in > >> execCmd > >> raise Exception(msg) > >> Exception: Failed inserting ISO domain into engine db > >> > >> 2013-03-05 20:02:19::DEBUG::setup_sequences::62::root:: Traceback > >> (most recent call last): > >> File "/usr/share/ovirt-engine/scripts/setup_sequences.py", line 60, > >> in run > >> function() > >> File "/bin/engine-setup", line 1810, in _configNfsShare > >> raise Exception(output_messages.ERR_FAILED_CFG_NFS_SHARE) > >> Exception: Failed to configure NFS share on this host > >> > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1992::root:: *** The > >> following params were used as user input: > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > >> override-httpd-config: yes > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: http-port: 80 > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: https-port: > >> 443 > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > >> random-passwords: no > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: mac-range: > >> 00:1A:4A:A8:01:00-00:1A:4A:A8:01:FF > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: host-fqdn: > >> localhost.localdomain > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: auth-pass: > >> ******** > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: org-name: > >> localdomain > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > >> application-mode: virt > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > >> default-dc-type: NFS > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > >> db-remote-install: local > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-host: > >> localhost > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: db-local-pass: > >> ******** > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: nfs-mp: /ISO > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > >> iso-domain-name: ISO_DOMAIN > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: config-nfs: > >> yes > >> 2013-03-05 20:02:19::DEBUG::engine-setup::1997::root:: > >> firewall-manager: iptables > >> 2013-03-05 20:02:19::ERROR::engine-setup::2413::root:: Traceback > >> (most recent call last): > >> File "/bin/engine-setup", line 2407, in > >> main(confFile) > >> File "/bin/engine-setup", line 2190, in main > >> > >> > >> _______________________________________________ > >> 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 alonbl at redhat.com Thu Mar 7 15:43:35 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 7 Mar 2013 10:43:35 -0500 (EST) Subject: [Engine-devel] Best place for new interfaces used by bll In-Reply-To: <1886727311.42715380.1362670263892.JavaMail.root@redhat.com> Message-ID: <1731598337.5570306.1362671015056.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alissa Bonas" > To: "Yair Zaslavsky" , rnori at redhat.com > Cc: engine-devel at ovirt.org > Sent: Thursday, March 7, 2013 5:31:03 PM > Subject: Re: [Engine-devel] Best place for new interfaces used by bll > > > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > To: "Alissa Bonas" > > Cc: engine-devel at ovirt.org, rnori at redhat.com > > Sent: Thursday, March 7, 2013 8:27:23 AM > > Subject: Re: [Engine-devel] Best place for new interfaces used by > > bll > > > > > > > > ----- Original Message ----- > > > From: "Alissa Bonas" > > > To: rnori at redhat.com > > > Cc: engine-devel at ovirt.org > > > Sent: Wednesday, March 6, 2013 10:50:52 PM > > > Subject: Re: [Engine-devel] Best place for new interfaces used by > > > bll > > > > > > 1. For start, and since you are already refactoring :) I > > > recommend > > > putting the interfaces in package named "api" and not > > > "interfaces" > > > - > > > it's a much more standard name. > > > 2. Can you elaborate a bit more what area/functionality in engine > > > are > > > those interfaces for? It will reflect their location. > > > > Yes, we're working on modularization/refactoring/improving of the > > async task manager. > > Bll will be a consumer (depend on) of async task mgr. > > From going briefly over the packages in "common" module, it seems > that there are 2 types of code there- > code really in use by backend and frontend, and code used only by the > backend. > So part of the code residing there is not really "common". > My suggestion is to take out that non common code from "common" > (along with async task mgr which is also not common), and create a > new module (names - core? infra? ) on which only backend/bll will > depend. Right. And then start splitting bll in by subject... and then split the interfaces by subject... and then merge the interfaces of specific subject with bll of specific subject. For example bll of host deploy should be maintained separately from bll of gluster etc... > > > > > > > ----- Original Message ----- > > > > From: "Ravi Nori" > > > > To: engine-devel at ovirt.org > > > > Sent: Wednesday, March 6, 2013 6:57:10 PM > > > > Subject: [Engine-devel] Best place for new interfaces used by > > > > bll > > > > > > > > Hi, > > > > > > > > I am working on refactoring some of the backend code in bll and > > > > need > > > > to > > > > create interfaces so that I can eliminate the dependency > > > > between > > > > bll > > > > and > > > > the new module. > > > > > > > > Currently I created the interfaces in > > > > org.ovirt.engine.core.common.interfaces, but from what I > > > > understand > > > > this > > > > module is used by both frontend and backend. The new interfaces > > > > will > > > > only be used by the backend. What would be the best place to > > > > put > > > > these > > > > new interfaces? > > > > > > > > Ravi > > > > _______________________________________________ > > > > 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 snmishra at linux.vnet.ibm.com Thu Mar 7 19:54:49 2013 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Thu, 07 Mar 2013 11:54:49 -0800 Subject: [Engine-devel] VDSM: make rpm is failing. In-Reply-To: <51383546.7060300@redhat.com> References: <1018752575.6726142.1362607671655.JavaMail.root@redhat.com> <20130306173933.Horde.bUxv4pir309RN_-VTTvFEBA@imap.linux.ibm.com> <51383546.7060300@redhat.com> Message-ID: <20130307115449.Horde.OPHPmZir309ROPCJvwbC1PA@imap.linux.ibm.com> Quoting Douglas Landgraf : > Hi, > > On 03/06/2013 08:39 PM, snmishra at linux.vnet.ibm.com wrote: >> >> Quoting Laszlo Hornyak : >> >>> Hi Sharad, >>> >>> There is an update pep8 that you have to use when compiling vdsm, that >>> may be the problem. >>> See http://wiki.ovirt.org/Vdsm_Developers >>> (however this document is frequently outdated) >> >> I only saw reference to el6 python-pep8 on the VDSM developer page and >> that version (1.3.3) is older than whats installed on F18 (1.4.2). >> > > Can you please try: > http://gerrit.ovirt.org/#/c/12700/ > > Thanks > Douglas > This patch fixed the issue. Thanks Sharad >> -Sharad >> >>> >>> >>> >>> ----- Original Message ----- >>>> From: snmishra at linux.vnet.ibm.com >>>> To: engine-devel at ovirt.org >>>> Sent: Wednesday, March 6, 2013 10:48:17 PM >>>> Subject: [Engine-devel] VDSM: make rpm is failing. >>>> >>>> >>>> Hi, >>>> >>>> Using latest VDSM source, I see make rpm failing bunch on tests. >>>> Running with 'NOSE_EXCLUDE=.*' I see the following error - >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> Ran 0 tests in 0.081s >>>> >>>> OK >>>> make[4]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' >>>> make[3]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' >>>> make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3/tests' >>>> Making check in vdsm-tool >>>> make[2]: Entering directory >>>> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm-tool' >>>> make[2]: Nothing to be done for `check'. >>>> make[2]: Leaving directory >>>> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm-tool' >>>> Making check in vdsm_api >>>> make[2]: Entering directory >>>> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm_api' >>>> make[2]: Nothing to be done for `check'. >>>> make[2]: Leaving directory >>>> `/root/rpmbuild/BUILD/vdsm-4.10.3/vdsm_api' >>>> Making check in yajsonrpc >>>> make[2]: Entering directory >>>> `/root/rpmbuild/BUILD/vdsm-4.10.3/yajsonrpc' >>>> make[2]: Nothing to be done for `check'. >>>> make[2]: Leaving directory >>>> `/root/rpmbuild/BUILD/vdsm-4.10.3/yajsonrpc' >>>> make[2]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >>>> make check-local >>>> make[3]: Entering directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >>>> find . -path './.git' -prune -type f -o \ >>>> -name '*.py' -o -name '*.py.in' | xargs /usr/bin/pyflakes >>>> ./vdsm/storage/lvm.py:608: list comprehension redefines 'lv' from >>>> line 603 >>>> make[3]: *** [check-local] Error 123 >>>> make[3]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >>>> make[2]: *** [check-am] Error 2 >>>> make[2]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >>>> make[1]: *** [check-recursive] Error 1 >>>> make[1]: Leaving directory `/root/rpmbuild/BUILD/vdsm-4.10.3' >>>> error: Bad exit status from /var/tmp/rpm-tmp.pay1sz (%check) >>>> >>>> >>>> RPM build errors: >>>> Bad exit status from /var/tmp/rpm-tmp.pay1sz (%check) >>>> make: *** [rpm] Error 1 >>>> >>>> _______________________________________________ >>>> 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 > > > -- > Cheers > Douglas From kwade at redhat.com Thu Mar 7 21:30:36 2013 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Thu, 07 Mar 2013 13:30:36 -0800 Subject: [Engine-devel] [JENKINS][ANN] jenkins.ovirt.org new look and infra In-Reply-To: <1345421098.14568886.1362670144501.JavaMail.root@redhat.com> References: <1345421098.14568886.1362670144501.JavaMail.root@redhat.com> Message-ID: <513906FC.2070300@redhat.com> On 03/07/2013 07:29 AM, Eyal Edri wrote: > i think we're OK with moving it: > i changed all configuration files & hostname on alterway01 to be jenkins.ovirt.org, > so we just need to point jenkins.ovirt.org to alterway01.ovirt.org (ip) in dns i belive. I just put in the CNAME request to have jenkins.ovirt.org point to alterway01.ovirt.org, and told them to "just do it & tell me when it's done." I'll bounce the good word back to this list when I get it. - Karsten -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 255 bytes Desc: OpenPGP digital signature URL: From danken at redhat.com Thu Mar 7 22:11:20 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Fri, 8 Mar 2013 00:11:20 +0200 Subject: [Engine-devel] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <51387942.606@redhat.com> References: <51387942.606@redhat.com> Message-ID: <20130307221120.GE14400@redhat.com> On Thu, Mar 07, 2013 at 12:25:54PM +0100, Vinzenz Feenstra wrote: > Please find the prettier version on the wiki: > http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > > > Proposal VDSM - Engine Data Statistics Retrieval > > > VDSM <=> Engine data retrieval optimization > > > Motivation: > > Currently the RHEVM engine is polling the a lot of data from VDSM > every 15 seconds. This should be optimized and the amount of data > requested should be more specific. It feels like a good idea, but do you have numbers? How much traffic would be saved? Remember the added computation incurred on each host - there's always a price to pay. > > For each VM the data currently contains much more information than > actually needed which blows up the size of the XML content quite > big. We could optimize this by splitting the reply on the getVmStats > based on the request of the engine into sections. For this reason > Omer Frenkel and me have split up the data into parts based on their > usage. > > This data can and usually does change during the lifetime of the VM. > > > Rarely Changed: > > This data is change not very frequent and it should be enough to > update this only once in a while. Most commonly this data changes > after changes made in the UI or after a migration of the VM to > another Host. > > *Status* = Running Status does not change much, but when it does, it is important to report that quickly. > *acpiEnable* = true > *vmType* = kvm > *guestName* = W864GUESTAGENTT > *displayType* = qxl > *guestOs* = Win 8 > *kvmEnable* = true #/*this should be constant and never changed*/ > *pauseCode* = NOERR > *monitorResponse* = 0 > *session* = Locked # unused > *netIfaces* = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': ['10.34.60.148'], 'hw': '00:1a:4a:22:3c:db'}] > *appsList* = ['RHEV-Tools 3.2.4', 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 3.2.2', 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] > *pid* = 11314 > *guestIPs* = 10.34.60.148 # duplicated info > *displayIp* = 0 > *displayPort* = 5902 > *displaySecurePort* = 5903 > *username* = user at W864GUESTAGENTT > *clientIp* = > *lastLogin* = 1361976900.67 > > > Often Changed: > > This data is changed quite often however it is not necessary to > update this data every 15 seconds. As this is cumulative data and > reflects the current status, and it does not need to be snapshotted > every 15 seconds to retrieve statistics. The data can be retrieved > in much more generous time slices. (e.g. Every 5 minutes) > > *network* = {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': 'vnet1'}} > *disksUsage* = [{'path': 'c:\\', 'total': '64055406592', 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': '3490912256', 'fs': 'UDF', 'used': '3490912256'}] > *timeOffset* = 14422 > *elapsedTime* = 68591 > *hash* = 2335461227228498964 > *statsAge* = 0.09 # unused > > > Often Changed but unused > > This data does not seem to be used in the engine at all. It is *not* > even used in the data warehouse. > > *memoryStats* = {'swap_out': '0', 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', 'pageflt': '0', 'mem_total': '2096736', 'mem_unused': '1466884'} > *balloonInfo* = {'balloon_max': 2097152, 'balloon_cur': 2097152} > *disks* = {'vda': {'readLatency': '0', 'apparentsize': '64424509440', 'writeLatency': '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', 'flushLatency': '156549', 'readRate': '0.00', 'truesize': '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': '0', 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} I am pretty sure that {read,write,flush}Latency is collected and reported by Engine. `git grep writeLatency` reinforces my vague memory. > > > Very frequent uppdates needed by webadmin portal: > > This data is mostly needed for the webadmin portal and might be > required to be updated quite often. An exception here is the > statsAge field, which seems to be unused by the Engine. This data > could be requested every 15 seconds to keep things as they are now. > > *cpuSys* = 2.32 > *cpuUser* = 1.34 > *memUsage* = 30 > > > Proposed Solution for VDSM & Engine: > > We will introduce new optional parameters to getVmStats, > getAllVmStats and list to allow a finer grained specification of > data which should be included. > > *Parameter:* *statsType*=/**/ (getVmStats, getAllVmStats > only) *Allowed values:* > > * full (default to keep backwards compatibility) > * app-list (Just send the application list) > * rare (include everything from rarely changed to very frequent) > * often (include everything from often changed to very frequent) > * frequent (only send the very frequently changed items) I think that a nice way to think of this, is that Engine ask for a set of keys it is interested about. Asking for getVmStats(keys=[displayType, netIfaces]) would return only the requrested values of the VM. "full", "rare", "often" and "frequent" are simply pre-defined sets of key names. A side effect of this pov is that we can avoid the vague name "statsType". > > > *Parameter:* *clientId*=** The client id is specified by the > client and should be unique however constantly used. > > *Parameter:* *diff*=** In combination with the clientId > VDSM will send only differences to the previous request from the > named clientId. (if diff=true) The semantics of "diff" is not completely defined: how about complex structures like that of "network"? It is most likely to be reported every time. Since this requires a caching mechanism on vdsm side, Engine must expect that the cache may be evicted in any moment, and that a full list is received. > > > Additional Change: > > Besides the introduction of the new parameters for list, getVmStats > and getAllVmStats it might make sense to include a hash for the > appList into the rarely changed section of the response which would > allow to identify changes and avoid having to sent the complete > appList every so often and only if the hash known to the client is > outdated. > > *Note:* The appList (Application List) reported by the guest agent > could be fully implemented on request only, as long as the guest > agent installed supports this. As there seems to be a request to > have the complete list of installed applications on all guests this > data could be quite extensive and a huge list. On the other hand > this data is only rarely visible and therefore it should not be > requested all the time and only on demand. > > > Improvement of the Guest Agent: > > As part of the proposed solution it is necessary to improve the > guest agent as well. Improving the agent may be a good idea, but I do not see the necessity in it. It's also important to improve the horrible multithreaded vdsm/libvirt statistics acquisition, but just as unrelated to the core of this feature. > For the full application list there should be > implemented a caching system which will be fully reactive and should > not poll the application list for example all the time. The guest > can create a prepared data file containing all data in the JSON > format (as used for the communication with VDSM via VIO) and just > have to read that file from disk and directly sends it to VDSM. > However it is quite possible that this list is to big and it might > have to be chunked into pieces. (Multiple messages, which would have > to be supported by VDSM then as well) The solution for this is to > make VDSM request this data and it will retrieve the data necessary > on request only. From wudxw at linux.vnet.ibm.com Fri Mar 8 02:21:27 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Fri, 08 Mar 2013 10:21:27 +0800 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <51387942.606@redhat.com> References: <51387942.606@redhat.com> Message-ID: <51394B27.2040106@linux.vnet.ibm.com> On 03/07/2013 07:25 PM, Vinzenz Feenstra wrote: > Please find the prettier version on the wiki: > http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > > > Proposal VDSM - Engine Data Statistics Retrieval > > > VDSM <=> Engine data retrieval optimization > > > Motivation: > > Currently the RHEVM engine is polling the a lot of data from VDSM > every 15 seconds. This should be optimized and the amount of data > requested should be more specific. > If the data size really matters, we could also consider to pack the information into binary. I am not sure if it's suitable in the transmission of XMLRPC. > > For each VM the data currently contains much more information than > actually needed which blows up the size of the XML content quite big. > We could optimize this by splitting the reply on the getVmStats based > on the request of the engine into sections. For this reason Omer > Frenkel and me have split up the data into parts based on their usage. > > This data can and usually does change during the lifetime of the VM. > > > Rarely Changed: > > This data is change not very frequent and it should be enough to > update this only once in a while. Most commonly this data changes > after changes made in the UI or after a migration of the VM to another > Host. > > *Status* = Running > *acpiEnable* = true > *vmType* = kvm > *guestName* = W864GUESTAGENTT > *displayType* = qxl > *guestOs* = Win 8 > *kvmEnable* = true #/*this should be constant and never changed*/ Then it should be removed from vm stats. In my opinion, any information belongs to vm's static configuration, it shouldn't be included in vm stats. For the fields above, except 'Status', engine can get the information without querying the vdsm host. It could not be changed by vdsm itself, right? > *pauseCode* = NOERR > *monitorResponse* = 0 > *session* = Locked # unused > *netIfaces* = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': ['10.34.60.148'], 'hw': '00:1a:4a:22:3c:db'}] > *appsList* = ['RHEV-Tools 3.2.4', 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 3.2.2', 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] > *pid* = 11314 > *guestIPs* = 10.34.60.148 # duplicated info > > *displayIp* = 0 > *displayPort* = 5902 > *displaySecurePort* = 5903 > > *username* = user at W864GUESTAGENTT > *clientIp* = > *lastLogin* = 1361976900.67 > > > Often Changed: > > This data is changed quite often however it is not necessary to update > this data every 15 seconds. As this is cumulative data and reflects > the current status, and it does not need to be snapshotted every 15 > seconds to retrieve statistics. The data can be retrieved in much more > generous time slices. (e.g. Every 5 minutes) > > *network* = {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': 'vnet1'}} macAddr and name don't change either. > *disksUsage* = [{'path': 'c:\\', 'total': '64055406592', 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': '3490912256', 'fs': 'UDF', 'used': '3490912256'}] > > *timeOffset* = 14422 > *elapsedTime* = 68591 > *hash* = 2335461227228498964 > *statsAge* = 0.09 # unused > > > Often Changed but unused > > This data does not seem to be used in the engine at all. It is *not* > even used in the data warehouse. > > *memoryStats* = {'swap_out': '0', 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', 'pageflt': '0', 'mem_total': '2096736', 'mem_unused': '1466884'} > *balloonInfo* = {'balloon_max': 2097152, 'balloon_cur': 2097152} > It's used by mom to adjust memory overcommitment dynamically. > *disks* = {'vda': {'readLatency': '0', 'apparentsize': '64424509440', 'writeLatency': '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', 'flushLatency': '156549', 'readRate': '0.00', 'truesize': '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': '0', 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} > > > Very frequent uppdates needed by webadmin portal: > > This data is mostly needed for the webadmin portal and might be > required to be updated quite often. An exception here is the statsAge > field, which seems to be unused by the Engine. This data could be > requested every 15 seconds to keep things as they are now. > > *cpuSys* = 2.32 > *cpuUser* = 1.34 > *memUsage* = 30 > > > Proposed Solution for VDSM & Engine: > > We will introduce new optional parameters to getVmStats, getAllVmStats > and list to allow a finer grained specification of data which should > be included. > > *Parameter:* *statsType*=/**/ (getVmStats, getAllVmStats only) > *Allowed values:* > > * full (default to keep backwards compatibility) > * app-list (Just send the application list) > * rare (include everything from rarely changed to very frequent) > * often (include everything from often changed to very frequent) > * frequent (only send the very frequently changed items) > > > *Parameter:* *clientId*=** The client id is specified by the > client and should be unique however constantly used. > > *Parameter:* *diff*=** In combination with the clientId VDSM > will send only differences to the previous request from the named > clientId. (if diff=true) > > > Additional Change: > > Besides the introduction of the new parameters for list, getVmStats > and getAllVmStats it might make sense to include a hash for the > appList into the rarely changed section of the response which would > allow to identify changes and avoid having to sent the complete > appList every so often and only if the hash known to the client is > outdated. > > *Note:* The appList (Application List) reported by the guest agent > could be fully implemented on request only, as long as the guest agent > installed supports this. As there seems to be a request to have the > complete list of installed applications on all guests this data could > be quite extensive and a huge list. On the other hand this data is > only rarely visible and therefore it should not be requested all the > time and only on demand. > > > Improvement of the Guest Agent: > > As part of the proposed solution it is necessary to improve the guest > agent as well. For the full application list there should be > implemented a caching system which will be fully reactive and should > not poll the application list for example all the time. The guest can > create a prepared data file containing all data in the JSON format (as > used for the communication with VDSM via VIO) and just have to read > that file from disk and directly sends it to VDSM. However it is quite > possible that this list is to big and it might have to be chunked into > pieces. (Multiple messages, which would have to be supported by VDSM > then as well) The solution for this is to make VDSM request this data > and it will retrieve the data necessary on request only. > > -- > Regards, > > Vinzenz Feenstra | Senior Software Engineer > RedHat Engineering Virtualization R & D > Phone: +420 532 294 625 > IRC: vfeenstr or evilissimo > > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From wudxw at linux.vnet.ibm.com Fri Mar 8 02:30:50 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Fri, 08 Mar 2013 10:30:50 +0800 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <20130307221120.GE14400@redhat.com> References: <51387942.606@redhat.com> <20130307221120.GE14400@redhat.com> Message-ID: <51394D5A.70309@linux.vnet.ibm.com> On 03/08/2013 06:11 AM, Dan Kenigsberg wrote: > On Thu, Mar 07, 2013 at 12:25:54PM +0100, Vinzenz Feenstra wrote: >> Please find the prettier version on the wiki: >> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval >> >> >> Proposal VDSM - Engine Data Statistics Retrieval >> >> >> VDSM <=> Engine data retrieval optimization >> >> >> Motivation: >> >> Currently the RHEVM engine is polling the a lot of data from VDSM >> every 15 seconds. This should be optimized and the amount of data >> requested should be more specific. > It feels like a good idea, but do you have numbers? How much traffic > would be saved? Remember the added computation incurred on each host - > there's always a price to pay. > >> For each VM the data currently contains much more information than >> actually needed which blows up the size of the XML content quite >> big. We could optimize this by splitting the reply on the getVmStats >> based on the request of the engine into sections. For this reason >> Omer Frenkel and me have split up the data into parts based on their >> usage. >> >> This data can and usually does change during the lifetime of the VM. >> >> >> Rarely Changed: >> >> This data is change not very frequent and it should be enough to >> update this only once in a while. Most commonly this data changes >> after changes made in the UI or after a migration of the VM to >> another Host. >> >> *Status* = Running > Status does not change much, but when it does, it is important to report > that quickly. For this kind of data, it is suitable to use an event report, which should be available in the jsonrpc API. > >> *acpiEnable* = true >> *vmType* = kvm >> *guestName* = W864GUESTAGENTT >> *displayType* = qxl >> *guestOs* = Win 8 >> *kvmEnable* = true #/*this should be constant and never changed*/ >> *pauseCode* = NOERR >> *monitorResponse* = 0 >> *session* = Locked # unused >> *netIfaces* = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': ['10.34.60.148'], 'hw': '00:1a:4a:22:3c:db'}] >> *appsList* = ['RHEV-Tools 3.2.4', 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 3.2.2', 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] >> *pid* = 11314 >> *guestIPs* = 10.34.60.148 # duplicated info >> *displayIp* = 0 >> *displayPort* = 5902 >> *displaySecurePort* = 5903 >> *username* = user at W864GUESTAGENTT >> *clientIp* = >> *lastLogin* = 1361976900.67 >> >> >> Often Changed: >> >> This data is changed quite often however it is not necessary to >> update this data every 15 seconds. As this is cumulative data and >> reflects the current status, and it does not need to be snapshotted >> every 15 seconds to retrieve statistics. The data can be retrieved >> in much more generous time slices. (e.g. Every 5 minutes) >> >> *network* = {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': '0.0', 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': 'vnet1'}} >> *disksUsage* = [{'path': 'c:\\', 'total': '64055406592', 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': '3490912256', 'fs': 'UDF', 'used': '3490912256'}] >> *timeOffset* = 14422 >> *elapsedTime* = 68591 >> *hash* = 2335461227228498964 >> *statsAge* = 0.09 # unused >> >> >> Often Changed but unused >> >> This data does not seem to be used in the engine at all. It is *not* >> even used in the data warehouse. >> >> *memoryStats* = {'swap_out': '0', 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', 'pageflt': '0', 'mem_total': '2096736', 'mem_unused': '1466884'} >> *balloonInfo* = {'balloon_max': 2097152, 'balloon_cur': 2097152} >> *disks* = {'vda': {'readLatency': '0', 'apparentsize': '64424509440', 'writeLatency': '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', 'flushLatency': '156549', 'readRate': '0.00', 'truesize': '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': '0', 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} > I am pretty sure that {read,write,flush}Latency is collected and > reported by Engine. `git grep writeLatency` reinforces my vague memory. >> >> Very frequent uppdates needed by webadmin portal: >> >> This data is mostly needed for the webadmin portal and might be >> required to be updated quite often. An exception here is the >> statsAge field, which seems to be unused by the Engine. This data >> could be requested every 15 seconds to keep things as they are now. >> >> *cpuSys* = 2.32 >> *cpuUser* = 1.34 >> *memUsage* = 30 >> >> >> Proposed Solution for VDSM & Engine: >> >> We will introduce new optional parameters to getVmStats, >> getAllVmStats and list to allow a finer grained specification of >> data which should be included. >> >> *Parameter:* *statsType*=/**/ (getVmStats, getAllVmStats >> only) *Allowed values:* >> >> * full (default to keep backwards compatibility) >> * app-list (Just send the application list) >> * rare (include everything from rarely changed to very frequent) >> * often (include everything from often changed to very frequent) >> * frequent (only send the very frequently changed items) > I think that a nice way to think of this, is that Engine ask for a set > of keys it is interested about. Asking for getVmStats(keys=[displayType, > netIfaces]) would return only the requrested values of the VM. +1. It could split the information according to different functions, not just change frequency. > "full", > "rare", "often" and "frequent" are simply pre-defined sets of key names. > > A side effect of this pov is that we can avoid the vague name > "statsType". > >> >> *Parameter:* *clientId*=** The client id is specified by the >> client and should be unique however constantly used. >> >> *Parameter:* *diff*=** In combination with the clientId >> VDSM will send only differences to the previous request from the >> named clientId. (if diff=true) > The semantics of "diff" is not completely defined: how about complex > structures like that of "network"? It is most likely to be reported > every time. > > Since this requires a caching mechanism on vdsm side, Engine must expect > that the cache may be evicted in any moment, and that a full list is > received. Every data collector should be responsible to invalidate/update the cache. It could reduce the time to calculate the diff. >> >> Additional Change: >> >> Besides the introduction of the new parameters for list, getVmStats >> and getAllVmStats it might make sense to include a hash for the >> appList into the rarely changed section of the response which would >> allow to identify changes and avoid having to sent the complete >> appList every so often and only if the hash known to the client is >> outdated. >> >> *Note:* The appList (Application List) reported by the guest agent >> could be fully implemented on request only, as long as the guest >> agent installed supports this. As there seems to be a request to >> have the complete list of installed applications on all guests this >> data could be quite extensive and a huge list. On the other hand >> this data is only rarely visible and therefore it should not be >> requested all the time and only on demand. >> >> >> Improvement of the Guest Agent: >> >> As part of the proposed solution it is necessary to improve the >> guest agent as well. > Improving the agent may be a good idea, but I do not see the necessity > in it. It's also important to improve the horrible multithreaded > vdsm/libvirt statistics acquisition, but just as unrelated to the core > of this feature. > >> For the full application list there should be >> implemented a caching system which will be fully reactive and should >> not poll the application list for example all the time. The guest >> can create a prepared data file containing all data in the JSON >> format (as used for the communication with VDSM via VIO) and just >> have to read that file from disk and directly sends it to VDSM. >> However it is quite possible that this list is to big and it might >> have to be chunked into pieces. (Multiple messages, which would have >> to be supported by VDSM then as well) The solution for this is to >> make VDSM request this data and it will retrieve the data necessary >> on request only. > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel From sanjal at redhat.com Fri Mar 8 04:04:09 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Fri, 08 Mar 2013 09:34:09 +0530 Subject: [Engine-devel] restapi - domains In-Reply-To: <5138433E.1030601@redhat.com> References: <51382977.4040801@redhat.com> <5138433E.1030601@redhat.com> Message-ID: <51396339.6070507@redhat.com> On 03/07/2013 01:05 PM, Aravinda wrote: > We can have only two fields in login screen, username and password. > Username will include domain name(username at domain). > > Default domain name can be "internal" if user didn't enter the domain > name as part of username then we can append the default value and > validate. > > Note: We use username at domain as username when we connect through > /api The idea is to *not* have the user type in the domain name, but rather let him/her choose one, just like what happens in webadmin. We should try and minimize typing as much as possible when it comes to mobile apps. > > -- > regards > Aravinda > > On 03/07/2013 11:15 AM, Shireesh Anjal wrote: >> Hi, >> >> We are trying to develop a simple android app to monitor and manage >> gluster clusters by consuming the restapi exposed by engine. The >> first screen is the login screen, which is similar to the webadmin >> login screen. Here, we want to populate the combo box of "domains" by >> fetching it from the restapi. However, the domains api cannot be >> invoked without authentication! So we have a sort of a >> chicken-and-egg problem. >> >> Any suggestions on how to tackle this? I feel the "domains" api >> should be "public", in the sense it should not expect authentication. >> >> Regards, >> Shireesh >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From mpastern at redhat.com Fri Mar 8 08:21:55 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Fri, 08 Mar 2013 10:21:55 +0200 Subject: [Engine-devel] Improvement for the oVirt java sdk In-Reply-To: References: <51331B7A.5020009@redhat.com> <51387BE6.4060707@redhat.com> Message-ID: <51399FA3.1050505@redhat.com> On 03/07/2013 04:53 PM, Morrissey, Christopher wrote: > > -Chris > >> -----Original Message----- >> From: Michael Pasternak [mailto:mpastern at redhat.com] >> Sent: Thursday, March 07, 2013 6:37 AM >> To: Morrissey, Christopher >> Cc: users at ovirt.org; engine-devel >> Subject: Re: Improvement for the oVirt java sdk >> >> On 03/04/2013 05:26 PM, Morrissey, Christopher wrote: >>> Hi Michael, >>> >>> Yes, that is the case here. I'm getting the JSESSIONID from the client >>> and passing it to our server so that it can perform REST-API calls back to >> oVirt under the logged in user's authenticated session. >> >> done, see http://lists.ovirt.org/pipermail/users/2013-March/012969.html > > Thanks for the very quick implementation! I'll give it a try shortly. here [1] is wiki for this change. [1] http://www.ovirt.org/Java-sdk#Authenticating_using_sessionid > >> >>> >>> -Chris >>> >>>> -----Original Message----- >>>> From: Michael Pasternak [mailto:mpastern at redhat.com] >>>> Sent: Sunday, March 03, 2013 4:44 AM >>>> To: Morrissey, Christopher >>>> Cc: users at ovirt.org; engine-devel >>>> Subject: Re: Improvement for the oVirt java sdk >>>> >>>> >>>> Hi Christopher, >>>> >>>> In general SDK abstracts the transport layer, therefore all >>>> authentication internals hidden from the user, >>>> >>>> i.e SESSION based authentication happens implicitly (by default), >>>> when you initiate SDK entry point, >>>> >>>> the story is different if you want using SSO-like login by reusing >>>> JSESSIONID from the REST-API for instance, and i can support such >>>> scenario, >>>> >>>> but, is this your case? >>>> >>>> On 02/28/2013 10:04 PM, Morrissey, Christopher wrote: >>>>> Hi Michael, >>>>> >>>>> I'm looking to use the oVirt java sdk for connecting into oVirt from >>>>> our server. However, we have a UI plugin that gets access to a >>>>> session ID that we should be able to use to connect through the REST >>>>> API instead of the username and password. Any chance the sdk could >>>>> be >>>> updated to take the session ID and create a connection vs. a user >>>> name and password? >>>>> >>>>> -Chris >>>>> >>>>> Chris Morrissey >>>>> Software Engineer >>>>> NetApp Inc. >>>>> 919.476.4428 >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Michael Pasternak >>>> RedHat, ENG-Virtualization R&D >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D -- Michael Pasternak RedHat, ENG-Virtualization R&D From vfeenstr at redhat.com Fri Mar 8 08:37:03 2013 From: vfeenstr at redhat.com (Vinzenz Feenstra) Date: Fri, 08 Mar 2013 09:37:03 +0100 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <51394D5A.70309@linux.vnet.ibm.com> References: <51387942.606@redhat.com> <20130307221120.GE14400@redhat.com> <51394D5A.70309@linux.vnet.ibm.com> Message-ID: <5139A32F.80809@redhat.com> On 03/08/2013 03:30 AM, Mark Wu wrote: > On 03/08/2013 06:11 AM, Dan Kenigsberg wrote: >> On Thu, Mar 07, 2013 at 12:25:54PM +0100, Vinzenz Feenstra wrote: >>> Please find the prettier version on the wiki: >>> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval >>> >>> >>> Proposal VDSM - Engine Data Statistics Retrieval >>> >>> >>> VDSM <=> Engine data retrieval optimization >>> >>> >>> Motivation: >>> >>> Currently the RHEVM engine is polling the a lot of data from VDSM >>> every 15 seconds. This should be optimized and the amount of data >>> requested should be more specific. >> It feels like a good idea, but do you have numbers? How much traffic >> would be saved? Remember the added computation incurred on each host - >> there's always a price to pay. Well the data of a single really basic simple VM has about 4 KiB data in the output of vdsClient, the XMLRPC formatted body part has almost 16KiB. The thing is that this data is queried every 15 seconds (previously 10) with little value for having ALL data sent all the time, the engine is not even using all of the data all the time. This optimization must be seen on a bigger scale, if you have a datacenter with let's say 1000 VMs then the data needed to be transmitted and parsed by the engine every 15 seconds is about 16MiB. This optimization wouldn't pay off that much in a 2 server 20 VM datacenter however on a larger scale it has quite a big impact. >> >>> For each VM the data currently contains much more information than >>> actually needed which blows up the size of the XML content quite >>> big. We could optimize this by splitting the reply on the getVmStats >>> based on the request of the engine into sections. For this reason >>> Omer Frenkel and me have split up the data into parts based on their >>> usage. >>> >>> This data can and usually does change during the lifetime of the VM. >>> >>> >>> Rarely Changed: >>> >>> This data is change not very frequent and it should be enough to >>> update this only once in a while. Most commonly this data changes >>> after changes made in the UI or after a migration of the VM to >>> another Host. >>> >>> *Status* = Running >> Status does not change much, but when it does, it is important to report >> that quickly. This is done by the list command which is executed every 2 seconds (maybe 3?) > For this kind of data, it is suitable to use an event report, which > should be available in the jsonrpc API. >> >>> *acpiEnable* = true >>> *vmType* = kvm >>> *guestName* = W864GUESTAGENTT >>> *displayType* = qxl >>> *guestOs* = Win 8 >>> *kvmEnable* = true #/*this should be constant and never changed*/ >>> *pauseCode* = NOERR >>> *monitorResponse* = 0 >>> *session* = Locked # unused >>> *netIfaces* = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', >>> 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': ['10.34.60.148'], >>> 'hw': '00:1a:4a:22:3c:db'}] >>> *appsList* = ['RHEV-Tools 3.2.4', 'RHEV-Agent64 3.2.3', >>> 'RHEV-Serial64 3.2.3', 'RHEV-Network64 3.2.2', 'RHEV-Network64 >>> 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 3.2.3', >>> 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB 3.2.3', >>> 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] >>> *pid* = 11314 >>> *guestIPs* = 10.34.60.148 # duplicated info >>> *displayIp* = 0 >>> *displayPort* = 5902 >>> *displaySecurePort* = 5903 >>> *username* = user at W864GUESTAGENTT >>> *clientIp* = >>> *lastLogin* = 1361976900.67 >>> >>> >>> Often Changed: >>> >>> This data is changed quite often however it is not necessary to >>> update this data every 15 seconds. As this is cumulative data and >>> reflects the current status, and it does not need to be snapshotted >>> every 15 seconds to retrieve statistics. The data can be retrieved >>> in much more generous time slices. (e.g. Every 5 minutes) >>> >>> *network* = {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', >>> 'rxDropped': '0', 'txDropped': '0', 'rxErrors': '0', 'txRate': >>> '0.0', 'rxRate': '0.0', 'txErrors': '0', 'state': 'unknown', >>> 'speed': '100', 'name': 'vnet1'}} >>> *disksUsage* = [{'path': 'c:\\', 'total': '64055406592', 'fs': >>> 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': >>> '3490912256', 'fs': 'UDF', 'used': '3490912256'}] >>> *timeOffset* = 14422 >>> *elapsedTime* = 68591 >>> *hash* = 2335461227228498964 >>> *statsAge* = 0.09 # unused >>> >>> >>> Often Changed but unused >>> >>> This data does not seem to be used in the engine at all. It is *not* >>> even used in the data warehouse. >>> >>> *memoryStats* = {'swap_out': '0', 'majflt': '0', 'mem_free': >>> '1466884', 'swap_in': '0', 'pageflt': '0', 'mem_total': '2096736', >>> 'mem_unused': '1466884'} >>> *balloonInfo* = {'balloon_max': 2097152, 'balloon_cur': 2097152} >>> *disks* = {'vda': {'readLatency': '0', 'apparentsize': >>> '64424509440', 'writeLatency': '1754496', 'imageID': >>> '28abb923-7b89-4638-84f8-1700f0b76482', 'flushLatency': '156549', >>> 'readRate': '0.00', 'truesize': '18855059456', 'writeRate': >>> '952.05'}, 'hdc': {'readLatency': '0', 'apparentsize': '0', >>> 'writeLatency': '0', 'flushLatency': '0', 'readRate': '0.00', >>> 'truesize': '0', 'writeRate': '0.00'}} >> I am pretty sure that {read,write,flush}Latency is collected and >> reported by Engine. `git grep writeLatency` reinforces my vague memory. Ok, well we did just a quite quick query about the usage and we searched rather for the keys than for the individual entries. Good to know what we need to be a bit more specific about the individual entries to classify them more appropriate. >>> >>> Very frequent uppdates needed by webadmin portal: >>> >>> This data is mostly needed for the webadmin portal and might be >>> required to be updated quite often. An exception here is the >>> statsAge field, which seems to be unused by the Engine. This data >>> could be requested every 15 seconds to keep things as they are now. >>> >>> *cpuSys* = 2.32 >>> *cpuUser* = 1.34 >>> *memUsage* = 30 >>> >>> >>> Proposed Solution for VDSM & Engine: >>> >>> We will introduce new optional parameters to getVmStats, >>> getAllVmStats and list to allow a finer grained specification of >>> data which should be included. >>> >>> *Parameter:* *statsType*=/**/ (getVmStats, getAllVmStats >>> only) *Allowed values:* >>> >>> * full (default to keep backwards compatibility) >>> * app-list (Just send the application list) >>> * rare (include everything from rarely changed to very frequent) >>> * often (include everything from often changed to very frequent) >>> * frequent (only send the very frequently changed items) >> I think that a nice way to think of this, is that Engine ask for a set >> of keys it is interested about. Asking for getVmStats(keys=[displayType, >> netIfaces]) would return only the requrested values of the VM. I was thinking of that as well or a way to exclude things from the list. > +1. It could split the information according to different functions, > not just change frequency. I would say to go for either or, both wouldn't make much sense. >> "full", >> "rare", "often" and "frequent" are simply pre-defined sets of key names. >> >> A side effect of this pov is that we can avoid the vague name >> "statsType". >> >>> >>> *Parameter:* *clientId*=** The client id is specified by the >>> client and should be unique however constantly used. >>> >>> *Parameter:* *diff*=** In combination with the clientId >>> VDSM will send only differences to the previous request from the >>> named clientId. (if diff=true) >> The semantics of "diff" is not completely defined: how about complex >> structures like that of "network"? It is most likely to be reported >> every time. Well the idea was a per key evaluation, maybe in cases like network and disks per device/interface. >> >> Since this requires a caching mechanism on vdsm side, Engine must expect >> that the cache may be evicted in any moment, and that a full list is >> received. Well the engine should always expect that. > Every data collector should be responsible to invalidate/update the > cache. > It could reduce the time to calculate the diff. >>> >>> Additional Change: >>> >>> Besides the introduction of the new parameters for list, getVmStats >>> and getAllVmStats it might make sense to include a hash for the >>> appList into the rarely changed section of the response which would >>> allow to identify changes and avoid having to sent the complete >>> appList every so often and only if the hash known to the client is >>> outdated. >>> >>> *Note:* The appList (Application List) reported by the guest agent >>> could be fully implemented on request only, as long as the guest >>> agent installed supports this. As there seems to be a request to >>> have the complete list of installed applications on all guests this >>> data could be quite extensive and a huge list. On the other hand >>> this data is only rarely visible and therefore it should not be >>> requested all the time and only on demand. >>> >>> >>> Improvement of the Guest Agent: >>> >>> As part of the proposed solution it is necessary to improve the >>> guest agent as well. >> Improving the agent may be a good idea, but I do not see the necessity >> in it. The guest agent is doing 'expensive' queries (e.g. "application_list") way too often. And things like network interfaces, disk usage and installed applications won't usually change every n minutes. Those queries could be much more reactive then proactive. >> It's also important to improve the horrible multithreaded >> vdsm/libvirt statistics acquisition, but just as unrelated to the core >> of this feature. >> >>> For the full application list there should be >>> implemented a caching system which will be fully reactive and should >>> not poll the application list for example all the time. The guest >>> can create a prepared data file containing all data in the JSON >>> format (as used for the communication with VDSM via VIO) and just >>> have to read that file from disk and directly sends it to VDSM. >>> However it is quite possible that this list is to big and it might >>> have to be chunked into pieces. (Multiple messages, which would have >>> to be supported by VDSM then as well) The solution for this is to >>> make VDSM request this data and it will retrieve the data necessary >>> on request only. >> _______________________________________________ >> vdsm-devel mailing list >> vdsm-devel at lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > -- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From danken at redhat.com Fri Mar 8 09:47:25 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Fri, 8 Mar 2013 11:47:25 +0200 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <5139A32F.80809@redhat.com> References: <51387942.606@redhat.com> <20130307221120.GE14400@redhat.com> <51394D5A.70309@linux.vnet.ibm.com> <5139A32F.80809@redhat.com> Message-ID: <20130308094725.GB24722@redhat.com> On Fri, Mar 08, 2013 at 09:37:03AM +0100, Vinzenz Feenstra wrote: > >>> > >>> > >>> Improvement of the Guest Agent: > >>> > >>>As part of the proposed solution it is necessary to improve the > >>>guest agent as well. > >>Improving the agent may be a good idea, but I do not see the necessity > >>in it. > The guest agent is doing 'expensive' queries (e.g. > "application_list") way too often. And things like network > interfaces, disk usage and installed applications won't usually > change every n minutes. > Those queries could be much more reactive then proactive. Of course, but as I said: > >>It's also important to improve the horrible multithreaded > >>vdsm/libvirt statistics acquisition, but just as unrelated to the core > >>of this feature. I think it is misleading to include this in the discussion about vdsm/Engine interface change. From danken at redhat.com Fri Mar 8 09:53:20 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Fri, 8 Mar 2013 11:53:20 +0200 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <51394B27.2040106@linux.vnet.ibm.com> References: <51387942.606@redhat.com> <51394B27.2040106@linux.vnet.ibm.com> Message-ID: <20130308095320.GC24722@redhat.com> On Fri, Mar 08, 2013 at 10:21:27AM +0800, Mark Wu wrote: > On 03/07/2013 07:25 PM, Vinzenz Feenstra wrote: > >Please find the prettier version on the wiki: http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > > > > > > Proposal VDSM - Engine Data Statistics Retrieval > > > > > > VDSM <=> Engine data retrieval optimization > > > > > > Motivation: > > > >Currently the RHEVM engine is polling the a lot of data from VDSM > >every 15 seconds. This should be optimized and the amount of data > >requested should be more specific. > > > If the data size really matters, we could also consider to pack the > information into binary. I am not sure if it's suitable in the > transmission of XMLRPC. I do not think we should embed binary in XMLRPC. I'd consider compressing the data at the transport layer - but that would be a completely deferent feature. > > > >For each VM the data currently contains much more information than > >actually needed which blows up the size of the XML content quite > >big. We could optimize this by splitting the reply on the > >getVmStats based on the request of the engine into sections. For > >this reason Omer Frenkel and me have split up the data into parts > >based on their usage. > > > >This data can and usually does change during the lifetime of the VM. > > > > > > Rarely Changed: > > > >This data is change not very frequent and it should be enough to > >update this only once in a while. Most commonly this data changes > >after changes made in the UI or after a migration of the VM to > >another Host. > > > > *Status* = Running > > *acpiEnable* = true > > *vmType* = kvm > > *guestName* = W864GUESTAGENTT > > *displayType* = qxl > > *guestOs* = Win 8 > > *kvmEnable* = true #/*this should be constant and never changed*/ > Then it should be removed from vm stats. In my opinion, any > information belongs to vm's static configuration, it shouldn't be > included in vm stats. For the fields above, except 'Status', engine > can get the information without querying the vdsm host. It could not > be changed by vdsm itself, right? actually, guestName and guestOs may change - for example by installing Linux on that Windows guest. From lspevak at redhat.com Fri Mar 8 12:06:40 2013 From: lspevak at redhat.com (Libor Spevak) Date: Fri, 08 Mar 2013 13:06:40 +0100 Subject: [Engine-devel] REST API using BASH In-Reply-To: <399818240.3501369.1362608136743.JavaMail.root@redhat.com> References: <399818240.3501369.1362608136743.JavaMail.root@redhat.com> Message-ID: <5139D450.8050702@redhat.com> On 6.3.2013 23:15, Eli Mesika wrote: > ----- Original Message ----- >> From: "Libor Spevak" >> To: engine-devel at ovirt.org >> Sent: Wednesday, March 6, 2013 11:06:53 AM >> Subject: [Engine-devel] REST API using BASH >> >> >> Hi, >> >> let me introduce some basic concepts when using REST API from the >> command line. I hope, it would be useful for newcomers. > Very useful in creating working instance from scratch. > Are there any plans to extend it to cover more commands? > Thanks It depends on available documentation and samples, too. Do you have ideas, what should be covered? The intent was to provide inspiration, not start a new project, but from practical point of view, extensions would be useful. >> E.g. probably everybody has tried curl and then grep, sed, ... for >> response, but XPath processing tool is more convenient for this >> task. >> >> http://www.ovirt.org/REST_API_Using_BASH_Automation >> >> Regards, >> Libor >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From sbonazzo at redhat.com Fri Mar 8 15:33:42 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Fri, 08 Mar 2013 16:33:42 +0100 Subject: [Engine-devel] =?utf-8?b?6L2s5Y+R77yaUmU6ICBmdW5jdGlvbiBpbnNlcnRz?= =?utf-8?q?torage=5Fdomain=5Fstatic=28uuid=2C_=2E=2E=2E=29_does_not_exist?= In-Reply-To: <5138B4F7.6000209@redhat.com> References: <20130307152521.DA7904600CC@webmail.sinamail.sina.com.cn> <5138B4F7.6000209@redhat.com> Message-ID: <513A04D6.8040305@redhat.com> Il 07/03/2013 16:40, Juan Hernandez ha scritto: > > Yes, I think it is a bug. To workaround it try to add the new > parameter to the inst_sp.sql file. In line 31 you will see this: > > perform > Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id > as varchar(250)),v_name,1,2,'0',0); > > I think it can be fixed adding the new parameter as follows: > > perform > Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id > as varchar(250)),v_name,v_name,1,2,'0',0); > > This is just using the name of the storage domain as description. > > Once you have modified that file you will have to repeat the > installation. > > If that solves the problem then we may need to apply the following > patch to the source code: > > diff --git a/backend/manager/dbscripts/inst_sp.sql > b/backend/manager/dbscripts/inst_sp.sql > index 82e8502..a4dcd20 100644 > --- a/backend/manager/dbscripts/inst_sp.sql > +++ b/backend/manager/dbscripts/inst_sp.sql > @@ -28,7 +28,7 @@ BEGIN > -- Insert storage server connection info > perform > Insertstorage_server_connections(v_connection,cast(v_connection_id as > varchar(250)),NULL,NULL,NULL,NULL,1,NULL,NULL,N > -- Insert storage domain static info > - perform > Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id > as varchar(250)),v_name,1,2,'0',0); > + perform > Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id > as varchar(250)),v_name,v_name,1,2,'0',0); > -- Insert storage domain dynamic info > perform > Insertstorage_domain_dynamic(v_available,v_storage_domain_id,v_used); > end if; > > Would you mind submitting it to gerrit? Hi Juan, I've tried the fix you suggested while working on another bug and it worked for me. Has anybody already submitted the patch to gerrit? -- Sandro From jhernand at redhat.com Fri Mar 8 15:34:27 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Fri, 08 Mar 2013 16:34:27 +0100 Subject: [Engine-devel] =?utf-8?b?6L2s5Y+R77yaUmU6ICBmdW5jdGlvbiBpbnNlcnRz?= =?utf-8?q?torage=5Fdomain=5Fstatic=28uuid=2C_=2E=2E=2E=29_does_not_exist?= In-Reply-To: <513A04D6.8040305@redhat.com> References: <20130307152521.DA7904600CC@webmail.sinamail.sina.com.cn> <5138B4F7.6000209@redhat.com> <513A04D6.8040305@redhat.com> Message-ID: <513A0503.3000001@redhat.com> On 03/08/2013 04:33 PM, Sandro Bonazzola wrote: > Il 07/03/2013 16:40, Juan Hernandez ha scritto: >> >> Yes, I think it is a bug. To workaround it try to add the new >> parameter to the inst_sp.sql file. In line 31 you will see this: >> >> perform >> Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id >> as varchar(250)),v_name,1,2,'0',0); >> >> I think it can be fixed adding the new parameter as follows: >> >> perform >> Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id >> as varchar(250)),v_name,v_name,1,2,'0',0); >> >> This is just using the name of the storage domain as description. >> >> Once you have modified that file you will have to repeat the >> installation. >> >> If that solves the problem then we may need to apply the following >> patch to the source code: >> >> diff --git a/backend/manager/dbscripts/inst_sp.sql >> b/backend/manager/dbscripts/inst_sp.sql >> index 82e8502..a4dcd20 100644 >> --- a/backend/manager/dbscripts/inst_sp.sql >> +++ b/backend/manager/dbscripts/inst_sp.sql >> @@ -28,7 +28,7 @@ BEGIN >> -- Insert storage server connection info >> perform >> Insertstorage_server_connections(v_connection,cast(v_connection_id as >> varchar(250)),NULL,NULL,NULL,NULL,1,NULL,NULL,N >> -- Insert storage domain static info >> - perform >> Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id >> as varchar(250)),v_name,1,2,'0',0); >> + perform >> Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id >> as varchar(250)),v_name,v_name,1,2,'0',0); >> -- Insert storage domain dynamic info >> perform >> Insertstorage_domain_dynamic(v_available,v_storage_domain_id,v_used); >> end if; >> >> Would you mind submitting it to gerrit? > > Hi Juan, > I've tried the fix you suggested while working on another bug and it > worked for me. > Has anybody already submitted the patch to gerrit? > I think it hasn't been submitted, would you be so kind to submit it? -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From sbonazzo at redhat.com Fri Mar 8 15:42:49 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Fri, 08 Mar 2013 16:42:49 +0100 Subject: [Engine-devel] =?utf-8?b?6L2s5Y+R77yaUmU6ICBmdW5jdGlvbiBpbnNlcnRz?= =?utf-8?q?torage=5Fdomain=5Fstatic=28uuid=2C_=2E=2E=2E=29_does_not_exist?= In-Reply-To: <513A0503.3000001@redhat.com> References: <20130307152521.DA7904600CC@webmail.sinamail.sina.com.cn> <5138B4F7.6000209@redhat.com> <513A04D6.8040305@redhat.com> <513A0503.3000001@redhat.com> Message-ID: <513A06F9.6050309@redhat.com> Il 08/03/2013 16:34, Juan Hernandez ha scritto: > On 03/08/2013 04:33 PM, Sandro Bonazzola wrote: >> Il 07/03/2013 16:40, Juan Hernandez ha scritto: >>> >>> Yes, I think it is a bug. To workaround it try to add the new >>> parameter to the inst_sp.sql file. In line 31 you will see this: >>> >>> perform >>> Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id >>> as varchar(250)),v_name,1,2,'0',0); >>> >>> I think it can be fixed adding the new parameter as follows: >>> >>> perform >>> Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id >>> as varchar(250)),v_name,v_name,1,2,'0',0); >>> >>> This is just using the name of the storage domain as description. >>> >>> Once you have modified that file you will have to repeat the >>> installation. >>> >>> If that solves the problem then we may need to apply the following >>> patch to the source code: >>> >>> diff --git a/backend/manager/dbscripts/inst_sp.sql >>> b/backend/manager/dbscripts/inst_sp.sql >>> index 82e8502..a4dcd20 100644 >>> --- a/backend/manager/dbscripts/inst_sp.sql >>> +++ b/backend/manager/dbscripts/inst_sp.sql >>> @@ -28,7 +28,7 @@ BEGIN >>> -- Insert storage server connection info >>> perform >>> Insertstorage_server_connections(v_connection,cast(v_connection_id as >>> varchar(250)),NULL,NULL,NULL,NULL,1,NULL,NULL,N >>> -- Insert storage domain static info >>> - perform >>> Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id >>> as varchar(250)),v_name,1,2,'0',0); >>> + perform >>> Insertstorage_domain_static(v_storage_domain_id,cast(v_connection_id >>> as varchar(250)),v_name,v_name,1,2,'0',0); >>> -- Insert storage domain dynamic info >>> perform >>> Insertstorage_domain_dynamic(v_available,v_storage_domain_id,v_used); >>> end if; >>> >>> Would you mind submitting it to gerrit? >> >> Hi Juan, >> I've tried the fix you suggested while working on another bug and it >> worked for me. >> Has anybody already submitted the patch to gerrit? >> > > I think it hasn't been submitted, would you be so kind to submit it? > Sure, here itis: http://gerrit.ovirt.org/12881 From ecohen at redhat.com Fri Mar 8 16:24:15 2013 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 8 Mar 2013 11:24:15 -0500 (EST) Subject: [Engine-devel] webadmin: left pane ("System") tree disappeared? In-Reply-To: <1161919728.17238315.1362759693529.JavaMail.root@redhat.com> Message-ID: <1223101216.17239248.1362759855975.JavaMail.root@redhat.com> http://oi49.tinypic.com/34r817t.jpg latest upstream (gerrit.ovirt.org / master), no left-pane System tree. [Expand All, Collapse All and refresh buttons are still there] [Bookmarks and Tags sections are OK] any idea? ---- Thanks, Einav From awels at redhat.com Fri Mar 8 16:35:18 2013 From: awels at redhat.com (Alexander Wels) Date: Fri, 08 Mar 2013 11:35:18 -0500 Subject: [Engine-devel] webadmin: left pane ("System") tree disappeared? In-Reply-To: <1223101216.17239248.1362759855975.JavaMail.root@redhat.com> References: <1223101216.17239248.1362759855975.JavaMail.root@redhat.com> Message-ID: <14676336.rTYNZBzCGi@awels> Make sure you update your database, I had the same thing, I had a missing entry or table or something, once I updated the database and restarted jboss it was fine. On Friday, March 08, 2013 11:24:15 AM Einav Cohen wrote: > http://oi49.tinypic.com/34r817t.jpg > > latest upstream (gerrit.ovirt.org / master), no left-pane System tree. > > [Expand All, Collapse All and refresh buttons are still there] > [Bookmarks and Tags sections are OK] > > any idea? > > ---- > Thanks, > Einav From ecohen at redhat.com Fri Mar 8 17:00:17 2013 From: ecohen at redhat.com (Einav Cohen) Date: Fri, 8 Mar 2013 12:00:17 -0500 (EST) Subject: [Engine-devel] webadmin: left pane ("System") tree disappeared? In-Reply-To: <14676336.rTYNZBzCGi@awels> Message-ID: <73627989.17263686.1362762017026.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Alexander Wels" > Sent: Friday, March 8, 2013 11:35:18 AM > > Make sure you update your database, I had the same thing, I had a > missing > entry or table or something, once I updated the database and > restarted jboss > it was fine. thanks Alex, that indeed did the trick. [usually, when there is a DB problem, the webadmin is not activated at all, so it didn't occur to me that it could be the root cause of my problem] sorry for the noise. > > On Friday, March 08, 2013 11:24:15 AM Einav Cohen wrote: > > http://oi49.tinypic.com/34r817t.jpg > > > > latest upstream (gerrit.ovirt.org / master), no left-pane System > > tree. > > > > [Expand All, Collapse All and refresh buttons are still there] > > [Bookmarks and Tags sections are OK] > > > > any idea? > > > > ---- > > Thanks, > > Einav > From lhornyak at redhat.com Fri Mar 8 17:18:59 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Fri, 8 Mar 2013 12:18:59 -0500 (EST) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <1537272338.7557412.1362754694254.JavaMail.root@redhat.com> Message-ID: <915149967.7601674.1362763139941.JavaMail.root@redhat.com> Hi, I uploaded a new version of the watchdog patch. This patch is still a work in progress, it adds audit log alerts to the functionality. http://gerrit.ovirt.org/12419/ Feature page: http://www.ovirt.org/Features/Watchdog_engine_support Laszlo From iheim at redhat.com Fri Mar 8 19:22:32 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 08 Mar 2013 21:22:32 +0200 Subject: [Engine-devel] restapi - domains In-Reply-To: <51396339.6070507@redhat.com> References: <51382977.4040801@redhat.com> <5138433E.1030601@redhat.com> <51396339.6070507@redhat.com> Message-ID: <513A3A78.1070302@redhat.com> On 03/08/2013 06:04 AM, Shireesh Anjal wrote: > On 03/07/2013 01:05 PM, Aravinda wrote: >> We can have only two fields in login screen, username and password. >> Username will include domain name(username at domain). >> >> Default domain name can be "internal" if user didn't enter the domain >> name as part of username then we can append the default value and >> validate. >> >> Note: We use username at domain as username when we connect through >> /api > > The idea is to *not* have the user type in the domain name, but rather > let him/her choose one, just like what happens in webadmin. We should > try and minimize typing as much as possible when it comes to mobile apps. I think this was done on purpose for some reason to not provide a public api for the rest api, but i could be wrong and don't remember the detail. as the concepts of multi tenancy and multiple domains grow, providing the list of domains is considered an issue, and most systems today require user to provide their full user/domain (well, usually in the form of their email address). > >> >> -- >> regards >> Aravinda >> >> On 03/07/2013 11:15 AM, Shireesh Anjal wrote: >>> Hi, >>> >>> We are trying to develop a simple android app to monitor and manage >>> gluster clusters by consuming the restapi exposed by engine. The >>> first screen is the login screen, which is similar to the webadmin >>> login screen. Here, we want to populate the combo box of "domains" by >>> fetching it from the restapi. However, the domains api cannot be >>> invoked without authentication! So we have a sort of a >>> chicken-and-egg problem. >>> >>> Any suggestions on how to tackle this? I feel the "domains" api >>> should be "public", in the sense it should not expect authentication. >>> >>> Regards, >>> Shireesh >>> _______________________________________________ >>> 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 Fri Mar 8 19:26:07 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 08 Mar 2013 21:26:07 +0200 Subject: [Engine-devel] REST API using BASH In-Reply-To: <399818240.3501369.1362608136743.JavaMail.root@redhat.com> References: <399818240.3501369.1362608136743.JavaMail.root@redhat.com> Message-ID: <513A3B4F.9040506@redhat.com> On 03/07/2013 12:15 AM, Eli Mesika wrote: > > > ----- Original Message ----- >> From: "Libor Spevak" >> To: engine-devel at ovirt.org >> Sent: Wednesday, March 6, 2013 11:06:53 AM >> Subject: [Engine-devel] REST API using BASH >> >> >> Hi, >> >> let me introduce some basic concepts when using REST API from the >> command line. I hope, it would be useful for newcomers. > > Very useful in creating working instance from scratch. > Are there any plans to extend it to cover more commands? > Thanks Can you please explain the difference from using the ovirt-shell cli tool? > >> E.g. probably everybody has tried curl and then grep, sed, ... for >> response, but XPath processing tool is more convenient for this >> task. >> >> http://www.ovirt.org/REST_API_Using_BASH_Automation >> >> Regards, >> Libor >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ofrenkel at redhat.com Sun Mar 10 07:36:46 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Sun, 10 Mar 2013 03:36:46 -0400 (EDT) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <915149967.7601674.1362763139941.JavaMail.root@redhat.com> Message-ID: <1496876088.17650170.1362901006007.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Laszlo Hornyak" > To: "engine-devel" > Sent: Friday, March 8, 2013 7:18:59 PM > Subject: [Engine-devel] new engine watchdog version > > Hi, > > I uploaded a new version of the watchdog patch. This patch is still a > work in progress, it adds audit log alerts to the functionality. > http://gerrit.ovirt.org/12419/ > > Feature page: > http://www.ovirt.org/Features/Watchdog_engine_support > > Laszlo > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > Hi, i looked at the patch and there is something i don't understand, i see you are treating the watchdog as a vm device, which is great, so why do we need to save the device details in vm_static table in addition to the vm_devices? i think its even not used at all (only setting the device in command which could be parameters, no need to persist) From tnisan at redhat.com Sun Mar 10 09:25:53 2013 From: tnisan at redhat.com (Tal Nisan) Date: Sun, 10 Mar 2013 11:25:53 +0200 Subject: [Engine-devel] webadmin: left pane ("System") tree disappeared? In-Reply-To: <73627989.17263686.1362762017026.JavaMail.root@redhat.com> References: <73627989.17263686.1362762017026.JavaMail.root@redhat.com> Message-ID: <513C51A1.2020104@redhat.com> Yeah, had it too and couldn't figure out why cause there were no errors in Jboss console, only when I ran web mode I saw the DB error in the GWT console On 03/08/2013 07:00 PM, Einav Cohen wrote: >> ----- Original Message ----- >> From: "Alexander Wels" >> Sent: Friday, March 8, 2013 11:35:18 AM >> >> Make sure you update your database, I had the same thing, I had a >> missing >> entry or table or something, once I updated the database and >> restarted jboss >> it was fine. > thanks Alex, that indeed did the trick. > [usually, when there is a DB problem, the webadmin is not activated > at all, so it didn't occur to me that it could be the root cause of my problem] > sorry for the noise. > >> On Friday, March 08, 2013 11:24:15 AM Einav Cohen wrote: >>> http://oi49.tinypic.com/34r817t.jpg >>> >>> latest upstream (gerrit.ovirt.org / master), no left-pane System >>> tree. >>> >>> [Expand All, Collapse All and refresh buttons are still there] >>> [Bookmarks and Tags sections are OK] >>> >>> any idea? >>> >>> ---- >>> Thanks, >>> Einav From dfediuck at redhat.com Sun Mar 10 09:26:28 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Sun, 10 Mar 2013 05:26:28 -0400 (EDT) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <1496876088.17650170.1362901006007.JavaMail.root@redhat.com> Message-ID: <1448280202.17656684.1362907588452.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Omer Frenkel" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Sunday, March 10, 2013 9:36:46 AM > Subject: Re: [Engine-devel] new engine watchdog version > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "engine-devel" > > Sent: Friday, March 8, 2013 7:18:59 PM > > Subject: [Engine-devel] new engine watchdog version > > > > Hi, > > > > I uploaded a new version of the watchdog patch. This patch is still > > a > > work in progress, it adds audit log alerts to the functionality. > > http://gerrit.ovirt.org/12419/ > > > > Feature page: > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > Laszlo > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > Hi, > i looked at the patch and there is something i don't understand, > i see you are treating the watchdog as a vm device, which is great, > so why do we need to save the device details in vm_static table in > addition to the vm_devices? > i think its even not used at all (only setting the device in command > which could be parameters, no need to persist) Omer, This is WIP, so a few bit are still in the works. Generally speaking model and action are needed since we should be able to use it for template creation, OVF*, and user interaction (user may choose a different model or watchdog for specific VM). Do you recommend on keeping this as spec-param? From lhornyak at redhat.com Mon Mar 11 07:59:53 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Mon, 11 Mar 2013 03:59:53 -0400 (EDT) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <1496876088.17650170.1362901006007.JavaMail.root@redhat.com> Message-ID: <2140746687.8253278.1362988793700.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Omer Frenkel" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Sunday, March 10, 2013 8:36:46 AM > Subject: Re: [Engine-devel] new engine watchdog version > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "engine-devel" > > Sent: Friday, March 8, 2013 7:18:59 PM > > Subject: [Engine-devel] new engine watchdog version > > > > Hi, > > > > I uploaded a new version of the watchdog patch. This patch is still > > a > > work in progress, it adds audit log alerts to the functionality. > > http://gerrit.ovirt.org/12419/ > > > > Feature page: > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > Laszlo > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > Hi, > i looked at the patch and there is something i don't understand, > i see you are treating the watchdog as a vm device, which is great, > so why do we need to save the device details in vm_static table in > addition to the vm_devices? > i think its even not used at all (only setting the device in command > which could be parameters, no need to persist) > Hi Omer, Thanks, I hoped someone will come up with that question :) The answer is that I followed the established design patterns in the backend. See smartcard and memory balloon, probably others. The motivation for this pattern could be that in case of these devices, you must have the settings in the VM data, not separately in the devices. Also when vdsbroker builds the devices list, it just asks the device list. The redundancy is already there, we can make it differently in this case but that will present the readers with a puzzle: why this pattern in feature X, why that pattern in feature Y... So I would recommend to leave it like this for now and schedule a cleanup on device handling. Devices deserve a cleanup. Thx, Laszlo From sanjal at redhat.com Mon Mar 11 08:19:28 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Mon, 11 Mar 2013 13:49:28 +0530 Subject: [Engine-devel] restapi - domains In-Reply-To: <513A3A78.1070302@redhat.com> References: <51382977.4040801@redhat.com> <5138433E.1030601@redhat.com> <51396339.6070507@redhat.com> <513A3A78.1070302@redhat.com> Message-ID: <513D9390.4020704@redhat.com> On 03/09/2013 12:52 AM, Itamar Heim wrote: > On 03/08/2013 06:04 AM, Shireesh Anjal wrote: >> On 03/07/2013 01:05 PM, Aravinda wrote: >>> We can have only two fields in login screen, username and password. >>> Username will include domain name(username at domain). >>> >>> Default domain name can be "internal" if user didn't enter the domain >>> name as part of username then we can append the default value and >>> validate. >>> >>> Note: We use username at domain as username when we connect through >>> /api >> >> The idea is to *not* have the user type in the domain name, but rather >> let him/her choose one, just like what happens in webadmin. We should >> try and minimize typing as much as possible when it comes to mobile >> apps. > > I think this was done on purpose for some reason to not provide a > public api for the rest api, but i could be wrong and don't remember > the detail. > as the concepts of multi tenancy and multiple domains grow, providing > the list of domains is considered an issue, Is it an issue specific to restapi? For we *do show* the list of domains in webadmin login screen. > and most systems today require user to provide their full user/domain > (well, usually in the form of their email address). > >> >>> >>> -- >>> regards >>> Aravinda >>> >>> On 03/07/2013 11:15 AM, Shireesh Anjal wrote: >>>> Hi, >>>> >>>> We are trying to develop a simple android app to monitor and manage >>>> gluster clusters by consuming the restapi exposed by engine. The >>>> first screen is the login screen, which is similar to the webadmin >>>> login screen. Here, we want to populate the combo box of "domains" by >>>> fetching it from the restapi. However, the domains api cannot be >>>> invoked without authentication! So we have a sort of a >>>> chicken-and-egg problem. >>>> >>>> Any suggestions on how to tackle this? I feel the "domains" api >>>> should be "public", in the sense it should not expect authentication. >>>> >>>> Regards, >>>> Shireesh >>>> _______________________________________________ >>>> 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 mpastern at redhat.com Mon Mar 11 08:37:32 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 11 Mar 2013 10:37:32 +0200 Subject: [Engine-devel] restapi - domains In-Reply-To: <513D9390.4020704@redhat.com> References: <51382977.4040801@redhat.com> <5138433E.1030601@redhat.com> <51396339.6070507@redhat.com> <513A3A78.1070302@redhat.com> <513D9390.4020704@redhat.com> Message-ID: <513D97CC.5050005@redhat.com> On 03/11/2013 10:19 AM, Shireesh Anjal wrote: > On 03/09/2013 12:52 AM, Itamar Heim wrote: >> On 03/08/2013 06:04 AM, Shireesh Anjal wrote: >>> On 03/07/2013 01:05 PM, Aravinda wrote: >>>> We can have only two fields in login screen, username and password. >>>> Username will include domain name(username at domain). >>>> >>>> Default domain name can be "internal" if user didn't enter the domain >>>> name as part of username then we can append the default value and >>>> validate. >>>> >>>> Note: We use username at domain as username when we connect through >>>> /api >>> >>> The idea is to *not* have the user type in the domain name, but rather >>> let him/her choose one, just like what happens in webadmin. We should >>> try and minimize typing as much as possible when it comes to mobile apps. >> >> I think this was done on purpose for some reason to not provide a public api for the rest api, but i could be wrong and don't remember the detail. >> as the concepts of multi tenancy and multiple domains grow, providing the list of domains is considered an issue, > > Is it an issue specific to restapi? For we *do show* the list of domains in webadmin login screen. indeed, UI using public query for that, while in api each request has to be authenticated, as workaround, i suggest creating internal user for this purpose and using it in the app (internally) to fetch entities that should not require explicit authentication from the application PoV. > >> and most systems today require user to provide their full user/domain (well, usually in the form of their email address). >> >>> >>>> >>>> -- >>>> regards >>>> Aravinda >>>> >>>> On 03/07/2013 11:15 AM, Shireesh Anjal wrote: >>>>> Hi, >>>>> >>>>> We are trying to develop a simple android app to monitor and manage >>>>> gluster clusters by consuming the restapi exposed by engine. The >>>>> first screen is the login screen, which is similar to the webadmin >>>>> login screen. Here, we want to populate the combo box of "domains" by >>>>> fetching it from the restapi. However, the domains api cannot be >>>>> invoked without authentication! So we have a sort of a >>>>> chicken-and-egg problem. >>>>> >>>>> Any suggestions on how to tackle this? I feel the "domains" api >>>>> should be "public", in the sense it should not expect authentication. >>>>> >>>>> Regards, >>>>> Shireesh >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization R&D From wudxw at linux.vnet.ibm.com Mon Mar 11 09:08:13 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Mon, 11 Mar 2013 17:08:13 +0800 Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Message-ID: <513D9EFD.7000305@linux.vnet.ibm.com> Hi guys, Currently, ISO domain is only supported on NFS storage. It could improve the ease of use if it allows other types of file based storage to store ISO images. After an investigation, I found there's not any restriction on this idea. So the whole work is removing the limitation on engine side. That means engine should allow ISO domain could have different storage type from the data center it's attached, like what we do with nfs ISO domain in SAN DC. I start this idea with localfs. I know local storage can't be seen in cluster level. But it also provides a choice if no NFS available. VMs can be created on the host which has the ISO repo, and then be migrated to any other host in the cluster. I have done the initial patches: allow creation ISO domain on localfs [1] and support import ISO domain on localfs [2] I don't have much experience in java/j2ee/web development and engine architecture. The patches just work for me. I am not sure if it will bring some potential problems. So any feedback on the patch or the idea will be appreciated very much. Mark. [1] http://gerrit.ovirt.org/#/c/12687/ [2] http://gerrit.ovirt.org/#/c/12916/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From iheim at redhat.com Mon Mar 11 09:43:25 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 11 Mar 2013 11:43:25 +0200 Subject: [Engine-devel] restapi - domains In-Reply-To: <513D97CC.5050005@redhat.com> References: <51382977.4040801@redhat.com> <5138433E.1030601@redhat.com> <51396339.6070507@redhat.com> <513A3A78.1070302@redhat.com> <513D9390.4020704@redhat.com> <513D97CC.5050005@redhat.com> Message-ID: <513DA73D.2000304@redhat.com> On 03/11/2013 10:37 AM, Michael Pasternak wrote: > On 03/11/2013 10:19 AM, Shireesh Anjal wrote: >> On 03/09/2013 12:52 AM, Itamar Heim wrote: >>> On 03/08/2013 06:04 AM, Shireesh Anjal wrote: >>>> On 03/07/2013 01:05 PM, Aravinda wrote: >>>>> We can have only two fields in login screen, username and password. >>>>> Username will include domain name(username at domain). >>>>> >>>>> Default domain name can be "internal" if user didn't enter the domain >>>>> name as part of username then we can append the default value and >>>>> validate. >>>>> >>>>> Note: We use username at domain as username when we connect through >>>>> /api >>>> >>>> The idea is to *not* have the user type in the domain name, but rather >>>> let him/her choose one, just like what happens in webadmin. We should >>>> try and minimize typing as much as possible when it comes to mobile apps. >>> >>> I think this was done on purpose for some reason to not provide a public api for the rest api, but i could be wrong and don't remember the detail. >>> as the concepts of multi tenancy and multiple domains grow, providing the list of domains is considered an issue, >> >> Is it an issue specific to restapi? For we *do show* the list of domains in webadmin login screen. yes, but we may want to remove that going forward and not show the domains, as most sites don't, which allows using more domains, without exposing them to other users. > > indeed, UI using public query for that, while in api each request has to be authenticated, > as workaround, i suggest creating internal user for this purpose and using it in the app > (internally) to fetch entities that should not require explicit authentication from the > application PoV. i assume rest api can use the public queries as well if we go that way? > >> >>> and most systems today require user to provide their full user/domain (well, usually in the form of their email address). >>> >>>> >>>>> >>>>> -- >>>>> regards >>>>> Aravinda >>>>> >>>>> On 03/07/2013 11:15 AM, Shireesh Anjal wrote: >>>>>> Hi, >>>>>> >>>>>> We are trying to develop a simple android app to monitor and manage >>>>>> gluster clusters by consuming the restapi exposed by engine. The >>>>>> first screen is the login screen, which is similar to the webadmin >>>>>> login screen. Here, we want to populate the combo box of "domains" by >>>>>> fetching it from the restapi. However, the domains api cannot be >>>>>> invoked without authentication! So we have a sort of a >>>>>> chicken-and-egg problem. >>>>>> >>>>>> Any suggestions on how to tackle this? I feel the "domains" api >>>>>> should be "public", in the sense it should not expect authentication. >>>>>> >>>>>> Regards, >>>>>> Shireesh >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > From yzaslavs at redhat.com Mon Mar 11 10:08:22 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 11 Mar 2013 06:08:22 -0400 (EDT) Subject: [Engine-devel] Async Task Manager improvements Message-ID: <1031458467.4691292.1362996502278.JavaMail.root@redhat.com> Hi all, I would like to present you a document I'm working on (still in draft/working-in-progress mode) of changes to be done at the engine async task manager. Regarding the detailed design - The suggested design breaks the task management into two modules - task management/polling part + command management (in context of completion of tasks/commands). The current status of the design is that the design of task management is provided (needs some polishing) - the command management design will be provided soon. In addition, we already have some ideas for an alternative design for the task management part (as suggested by Saggi Mizrahi). After converging , we will present the complete design. The reason we're sending the Wiki now is that community members will be aware mainly to the motivations behind the changes (Perhaps we should create separate documents for the design and for the motivation/requirements) http://www.ovirt.org/Wiki/AsyncTaskManagerChanges Yair From ofrenkel at redhat.com Mon Mar 11 10:12:48 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Mon, 11 Mar 2013 06:12:48 -0400 (EDT) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <2140746687.8253278.1362988793700.JavaMail.root@redhat.com> Message-ID: <2131138860.17906275.1362996768967.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Laszlo Hornyak" > To: "Omer Frenkel" > Cc: "engine-devel" > Sent: Monday, March 11, 2013 9:59:53 AM > Subject: Re: [Engine-devel] new engine watchdog version > > > > ----- Original Message ----- > > From: "Omer Frenkel" > > To: "Laszlo Hornyak" > > Cc: "engine-devel" > > Sent: Sunday, March 10, 2013 8:36:46 AM > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > ----- Original Message ----- > > > From: "Laszlo Hornyak" > > > To: "engine-devel" > > > Sent: Friday, March 8, 2013 7:18:59 PM > > > Subject: [Engine-devel] new engine watchdog version > > > > > > Hi, > > > > > > I uploaded a new version of the watchdog patch. This patch is > > > still > > > a > > > work in progress, it adds audit log alerts to the functionality. > > > http://gerrit.ovirt.org/12419/ > > > > > > Feature page: > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > Laszlo > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > Hi, > > i looked at the patch and there is something i don't understand, > > i see you are treating the watchdog as a vm device, which is great, > > so why do we need to save the device details in vm_static table in > > addition to the vm_devices? > > i think its even not used at all (only setting the device in > > command > > which could be parameters, no need to persist) > > > > Hi Omer, > > Thanks, I hoped someone will come up with that question :) The answer > is that I followed the established design patterns in the backend. > See smartcard and memory balloon, probably others. The motivation > for this pattern could be that in case of these devices, you must > have the settings in the VM data, not separately in the devices. > Also when vdsbroker builds the devices list, it just asks the device > list. The redundancy is already there, we can make it differently in > this case but that will present the readers with a puzzle: why this > pattern in feature X, why that pattern in feature Y... > So I would recommend to leave it like this for now and schedule a > cleanup on device handling. Devices deserve a cleanup. > > Thx, > Laszlo > i agree there is a mess that requires clean-up, but i don't think its a good thing to keep piling up the mess, i don't like it that smartcard is there, but some other devices are ok (balloon and payload) so we already have 2 'patterns', lets go with the right one.. and answering also @Doron's question - yes the device data should be kept with the device From lhornyak at redhat.com Mon Mar 11 10:15:39 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Mon, 11 Mar 2013 06:15:39 -0400 (EDT) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <2131138860.17906275.1362996768967.JavaMail.root@redhat.com> Message-ID: <486247970.8290735.1362996939300.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Omer Frenkel" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Monday, March 11, 2013 11:12:48 AM > Subject: Re: [Engine-devel] new engine watchdog version > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "Omer Frenkel" > > Cc: "engine-devel" > > Sent: Monday, March 11, 2013 9:59:53 AM > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > ----- Original Message ----- > > > From: "Omer Frenkel" > > > To: "Laszlo Hornyak" > > > Cc: "engine-devel" > > > Sent: Sunday, March 10, 2013 8:36:46 AM > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Laszlo Hornyak" > > > > To: "engine-devel" > > > > Sent: Friday, March 8, 2013 7:18:59 PM > > > > Subject: [Engine-devel] new engine watchdog version > > > > > > > > Hi, > > > > > > > > I uploaded a new version of the watchdog patch. This patch is > > > > still > > > > a > > > > work in progress, it adds audit log alerts to the > > > > functionality. > > > > http://gerrit.ovirt.org/12419/ > > > > > > > > Feature page: > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > Laszlo > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > Hi, > > > i looked at the patch and there is something i don't understand, > > > i see you are treating the watchdog as a vm device, which is > > > great, > > > so why do we need to save the device details in vm_static table > > > in > > > addition to the vm_devices? > > > i think its even not used at all (only setting the device in > > > command > > > which could be parameters, no need to persist) > > > > > > > Hi Omer, > > > > Thanks, I hoped someone will come up with that question :) The > > answer > > is that I followed the established design patterns in the backend. > > See smartcard and memory balloon, probably others. The motivation > > for this pattern could be that in case of these devices, you must > > have the settings in the VM data, not separately in the devices. > > Also when vdsbroker builds the devices list, it just asks the > > device > > list. The redundancy is already there, we can make it differently > > in > > this case but that will present the readers with a puzzle: why this > > pattern in feature X, why that pattern in feature Y... > > So I would recommend to leave it like this for now and schedule a > > cleanup on device handling. Devices deserve a cleanup. > > > > Thx, > > Laszlo > > > > i agree there is a mess that requires clean-up, > but i don't think its a good thing to keep piling up the mess, > i don't like it that smartcard is there, but some other devices are > ok (balloon and payload) > so we already have 2 'patterns', lets go with the right one.. > and answering also @Doron's question - yes the device data should be > kept with the device > Ok, I may have missed the other pattern, could you explain which one do you mean? Balloon does not very different from smartcard, it is there in VM. From ofrenkel at redhat.com Mon Mar 11 12:25:39 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Mon, 11 Mar 2013 08:25:39 -0400 (EDT) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <486247970.8290735.1362996939300.JavaMail.root@redhat.com> Message-ID: <1780482129.17952208.1363004739805.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Laszlo Hornyak" > To: "Omer Frenkel" > Cc: "engine-devel" > Sent: Monday, March 11, 2013 12:15:39 PM > Subject: Re: [Engine-devel] new engine watchdog version > > > > ----- Original Message ----- > > From: "Omer Frenkel" > > To: "Laszlo Hornyak" > > Cc: "engine-devel" > > Sent: Monday, March 11, 2013 11:12:48 AM > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > ----- Original Message ----- > > > From: "Laszlo Hornyak" > > > To: "Omer Frenkel" > > > Cc: "engine-devel" > > > Sent: Monday, March 11, 2013 9:59:53 AM > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Omer Frenkel" > > > > To: "Laszlo Hornyak" > > > > Cc: "engine-devel" > > > > Sent: Sunday, March 10, 2013 8:36:46 AM > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Laszlo Hornyak" > > > > > To: "engine-devel" > > > > > Sent: Friday, March 8, 2013 7:18:59 PM > > > > > Subject: [Engine-devel] new engine watchdog version > > > > > > > > > > Hi, > > > > > > > > > > I uploaded a new version of the watchdog patch. This patch is > > > > > still > > > > > a > > > > > work in progress, it adds audit log alerts to the > > > > > functionality. > > > > > http://gerrit.ovirt.org/12419/ > > > > > > > > > > Feature page: > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > > > Laszlo > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > Hi, > > > > i looked at the patch and there is something i don't > > > > understand, > > > > i see you are treating the watchdog as a vm device, which is > > > > great, > > > > so why do we need to save the device details in vm_static table > > > > in > > > > addition to the vm_devices? > > > > i think its even not used at all (only setting the device in > > > > command > > > > which could be parameters, no need to persist) > > > > > > > > > > Hi Omer, > > > > > > Thanks, I hoped someone will come up with that question :) The > > > answer > > > is that I followed the established design patterns in the > > > backend. > > > See smartcard and memory balloon, probably others. The motivation > > > for this pattern could be that in case of these devices, you must > > > have the settings in the VM data, not separately in the devices. > > > Also when vdsbroker builds the devices list, it just asks the > > > device > > > list. The redundancy is already there, we can make it differently > > > in > > > this case but that will present the readers with a puzzle: why > > > this > > > pattern in feature X, why that pattern in feature Y... > > > So I would recommend to leave it like this for now and schedule a > > > cleanup on device handling. Devices deserve a cleanup. > > > > > > Thx, > > > Laszlo > > > > > > > i agree there is a mess that requires clean-up, > > but i don't think its a good thing to keep piling up the mess, > > i don't like it that smartcard is there, but some other devices are > > ok (balloon and payload) > > so we already have 2 'patterns', lets go with the right one.. > > and answering also @Doron's question - yes the device data should > > be > > kept with the device > > > > Ok, I may have missed the other pattern, could you explain which one > do you mean? > Balloon does not very different from smartcard, it is there in VM. > the difference is that balloon is not in vm_static table at all (the only place in the db for it is in vm_devices) and smartcard has 'is_smartcard_enabled' field in vm_static in addition to vm_devices (which is not needed..) the way i think we (currently) need to work with devices is: add a parameter for it in the parameters, and use it in add/update (/run-once?) (as done for balloon) i don't know what is the use of the field balloonEnabled in VM, i don't see any use of it.. going forward we need to think if we want to expose devices to frontend, so then we can drop the encapsulation and just use list of devices in VmBase or something like that From gchaplik at redhat.com Mon Mar 11 14:02:21 2013 From: gchaplik at redhat.com (Gilad Chaplik) Date: Mon, 11 Mar 2013 10:02:21 -0400 (EDT) Subject: [Engine-devel] Adding Kanagaraj Mayilsamy as a webadmin maintainer In-Reply-To: <1014626711.9959908.1362416621070.JavaMail.root@redhat.com> Message-ID: <828325023.12212985.1363010541467.JavaMail.root@redhat.com> +1 Thanks, Gilad. ----- Original Message ----- > From: "Vojtech Szocs" > To: "Itamar Heim" > Cc: "engine-devel" , "Einav Cohen" , "Gilad Chaplik" > , "Daniel Erez" , "Tal Nisan" , "Tomas Jelinek" > , "Alona Kaplan" > Sent: Monday, March 4, 2013 7:03:41 PM > Subject: Re: Adding Kanagaraj Mayilsamy as a webadmin maintainer > > +1 :) > > Vojtech > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" , "Einav Cohen" > , "Gilad Chaplik" , "Daniel > Erez" , "Tal Nisan" , "Tomas > Jelinek" , "Alona Kaplan" > Cc: "engine-devel" > Sent: Sunday, March 3, 2013 11:03:13 PM > Subject: Adding Kanagaraj Mayilsamy as a webadmin maintainer > > I'd like to propose Kanagaraj as a web admin maintainer - he has been > working on the webadmin for about a year, with more than 130 UI > patches > merged. > > Thanks, > Itamar > From tnisan at redhat.com Mon Mar 11 14:22:25 2013 From: tnisan at redhat.com (Tal Nisan) Date: Mon, 11 Mar 2013 16:22:25 +0200 Subject: [Engine-devel] Adding Kanagaraj Mayilsamy as a webadmin maintainer In-Reply-To: <828325023.12212985.1363010541467.JavaMail.root@redhat.com> References: <828325023.12212985.1363010541467.JavaMail.root@redhat.com> Message-ID: <513DE8A1.6020605@redhat.com> +1 On 03/11/2013 04:02 PM, Gilad Chaplik wrote: > +1 > > Thanks, > Gilad. > > ----- Original Message ----- >> From: "Vojtech Szocs" >> To: "Itamar Heim" >> Cc: "engine-devel", "Einav Cohen", "Gilad Chaplik" >> , "Daniel Erez", "Tal Nisan", "Tomas Jelinek" >> , "Alona Kaplan" >> Sent: Monday, March 4, 2013 7:03:41 PM >> Subject: Re: Adding Kanagaraj Mayilsamy as a webadmin maintainer >> >> +1 :) >> >> Vojtech >> >> ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs", "Einav Cohen" >> , "Gilad Chaplik", "Daniel >> Erez", "Tal Nisan", "Tomas >> Jelinek", "Alona Kaplan" >> Cc: "engine-devel" >> Sent: Sunday, March 3, 2013 11:03:13 PM >> Subject: Adding Kanagaraj Mayilsamy as a webadmin maintainer >> >> I'd like to propose Kanagaraj as a web admin maintainer - he has been >> working on the webadmin for about a year, with more than 130 UI >> patches >> merged. >> >> Thanks, >> Itamar >> From dfediuck at redhat.com Mon Mar 11 15:10:02 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Mon, 11 Mar 2013 11:10:02 -0400 (EDT) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <1780482129.17952208.1363004739805.JavaMail.root@redhat.com> Message-ID: <96976087.18074232.1363014602814.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Omer Frenkel" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Monday, March 11, 2013 2:25:39 PM > Subject: Re: [Engine-devel] new engine watchdog version > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "Omer Frenkel" > > Cc: "engine-devel" > > Sent: Monday, March 11, 2013 12:15:39 PM > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > ----- Original Message ----- > > > From: "Omer Frenkel" > > > To: "Laszlo Hornyak" > > > Cc: "engine-devel" > > > Sent: Monday, March 11, 2013 11:12:48 AM > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Laszlo Hornyak" > > > > To: "Omer Frenkel" > > > > Cc: "engine-devel" > > > > Sent: Monday, March 11, 2013 9:59:53 AM > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Omer Frenkel" > > > > > To: "Laszlo Hornyak" > > > > > Cc: "engine-devel" > > > > > Sent: Sunday, March 10, 2013 8:36:46 AM > > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Laszlo Hornyak" > > > > > > To: "engine-devel" > > > > > > Sent: Friday, March 8, 2013 7:18:59 PM > > > > > > Subject: [Engine-devel] new engine watchdog version > > > > > > > > > > > > Hi, > > > > > > > > > > > > I uploaded a new version of the watchdog patch. This patch > > > > > > is > > > > > > still > > > > > > a > > > > > > work in progress, it adds audit log alerts to the > > > > > > functionality. > > > > > > http://gerrit.ovirt.org/12419/ > > > > > > > > > > > > Feature page: > > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > > > > > Laszlo > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > Hi, > > > > > i looked at the patch and there is something i don't > > > > > understand, > > > > > i see you are treating the watchdog as a vm device, which is > > > > > great, > > > > > so why do we need to save the device details in vm_static > > > > > table > > > > > in > > > > > addition to the vm_devices? > > > > > i think its even not used at all (only setting the device in > > > > > command > > > > > which could be parameters, no need to persist) > > > > > > > > > > > > > Hi Omer, > > > > > > > > Thanks, I hoped someone will come up with that question :) The > > > > answer > > > > is that I followed the established design patterns in the > > > > backend. > > > > See smartcard and memory balloon, probably others. The > > > > motivation > > > > for this pattern could be that in case of these devices, you > > > > must > > > > have the settings in the VM data, not separately in the > > > > devices. > > > > Also when vdsbroker builds the devices list, it just asks the > > > > device > > > > list. The redundancy is already there, we can make it > > > > differently > > > > in > > > > this case but that will present the readers with a puzzle: why > > > > this > > > > pattern in feature X, why that pattern in feature Y... > > > > So I would recommend to leave it like this for now and schedule > > > > a > > > > cleanup on device handling. Devices deserve a cleanup. > > > > > > > > Thx, > > > > Laszlo > > > > > > > > > > i agree there is a mess that requires clean-up, > > > but i don't think its a good thing to keep piling up the mess, > > > i don't like it that smartcard is there, but some other devices > > > are > > > ok (balloon and payload) > > > so we already have 2 'patterns', lets go with the right one.. > > > and answering also @Doron's question - yes the device data should > > > be > > > kept with the device > > > > > > > Ok, I may have missed the other pattern, could you explain which > > one > > do you mean? > > Balloon does not very different from smartcard, it is there in VM. > > > > the difference is that balloon is not in vm_static table at all (the > only place in the db for it is in vm_devices) > and smartcard has 'is_smartcard_enabled' field in vm_static in > addition to vm_devices (which is not needed..) > > the way i think we (currently) need to work with devices is: > add a parameter for it in the parameters, and use it in add/update > (/run-once?) (as done for balloon) > i don't know what is the use of the field balloonEnabled in VM, i > don't see any use of it.. > > going forward we need to think if we want to expose devices to > frontend, > so then we can drop the encapsulation and just use list of devices in > VmBase or something like that Or VMDeviceBase... In the meantime, it seems that watchdog needs to use spec params as vga card does. From lhornyak at redhat.com Mon Mar 11 16:46:06 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Mon, 11 Mar 2013 12:46:06 -0400 (EDT) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <1780482129.17952208.1363004739805.JavaMail.root@redhat.com> Message-ID: <263871406.8590817.1363020366758.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Omer Frenkel" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Monday, March 11, 2013 1:25:39 PM > Subject: Re: [Engine-devel] new engine watchdog version > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "Omer Frenkel" > > Cc: "engine-devel" > > Sent: Monday, March 11, 2013 12:15:39 PM > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > ----- Original Message ----- > > > From: "Omer Frenkel" > > > To: "Laszlo Hornyak" > > > Cc: "engine-devel" > > > Sent: Monday, March 11, 2013 11:12:48 AM > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Laszlo Hornyak" > > > > To: "Omer Frenkel" > > > > Cc: "engine-devel" > > > > Sent: Monday, March 11, 2013 9:59:53 AM > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Omer Frenkel" > > > > > To: "Laszlo Hornyak" > > > > > Cc: "engine-devel" > > > > > Sent: Sunday, March 10, 2013 8:36:46 AM > > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Laszlo Hornyak" > > > > > > To: "engine-devel" > > > > > > Sent: Friday, March 8, 2013 7:18:59 PM > > > > > > Subject: [Engine-devel] new engine watchdog version > > > > > > > > > > > > Hi, > > > > > > > > > > > > I uploaded a new version of the watchdog patch. This patch > > > > > > is > > > > > > still > > > > > > a > > > > > > work in progress, it adds audit log alerts to the > > > > > > functionality. > > > > > > http://gerrit.ovirt.org/12419/ > > > > > > > > > > > > Feature page: > > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > > > > > Laszlo > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > Hi, > > > > > i looked at the patch and there is something i don't > > > > > understand, > > > > > i see you are treating the watchdog as a vm device, which is > > > > > great, > > > > > so why do we need to save the device details in vm_static > > > > > table > > > > > in > > > > > addition to the vm_devices? > > > > > i think its even not used at all (only setting the device in > > > > > command > > > > > which could be parameters, no need to persist) > > > > > > > > > > > > > Hi Omer, > > > > > > > > Thanks, I hoped someone will come up with that question :) The > > > > answer > > > > is that I followed the established design patterns in the > > > > backend. > > > > See smartcard and memory balloon, probably others. The > > > > motivation > > > > for this pattern could be that in case of these devices, you > > > > must > > > > have the settings in the VM data, not separately in the > > > > devices. > > > > Also when vdsbroker builds the devices list, it just asks the > > > > device > > > > list. The redundancy is already there, we can make it > > > > differently > > > > in > > > > this case but that will present the readers with a puzzle: why > > > > this > > > > pattern in feature X, why that pattern in feature Y... > > > > So I would recommend to leave it like this for now and schedule > > > > a > > > > cleanup on device handling. Devices deserve a cleanup. > > > > > > > > Thx, > > > > Laszlo > > > > > > > > > > i agree there is a mess that requires clean-up, > > > but i don't think its a good thing to keep piling up the mess, > > > i don't like it that smartcard is there, but some other devices > > > are > > > ok (balloon and payload) > > > so we already have 2 'patterns', lets go with the right one.. > > > and answering also @Doron's question - yes the device data should > > > be > > > kept with the device > > > > > > > Ok, I may have missed the other pattern, could you explain which > > one > > do you mean? > > Balloon does not very different from smartcard, it is there in VM. > > > > the difference is that balloon is not in vm_static table at all (the > only place in the db for it is in vm_devices) > and smartcard has 'is_smartcard_enabled' field in vm_static in > addition to vm_devices (which is not needed..) Ok, so what you want is that - the engine should query the devices each time the VM record is set (from DAO's or Action) XOR - the client code (rest-api and frontend) should query the devices to figure out if the watchdog is there > > the way i think we (currently) need to work with devices is: > add a parameter for it in the parameters, and use it in add/update > (/run-once?) (as done for balloon) run once for watchdog? why? > i don't know what is the use of the field balloonEnabled in VM, i > don't see any use of it.. It is a write-only property. > > going forward we need to think if we want to expose devices to > frontend, > so then we can drop the encapsulation and just use list of devices in > VmBase or something like that > From iheim at redhat.com Mon Mar 11 20:42:18 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 11 Mar 2013 22:42:18 +0200 Subject: [Engine-devel] Adding Kanagaraj Mayilsamy as a webadmin maintainer In-Reply-To: <513DE8A1.6020605@redhat.com> References: <828325023.12212985.1363010541467.JavaMail.root@redhat.com> <513DE8A1.6020605@redhat.com> Message-ID: <513E41AA.8010900@redhat.com> On 03/11/2013 04:22 PM, Tal Nisan wrote: > +1 > > > On 03/11/2013 04:02 PM, Gilad Chaplik wrote: >> +1 >> >> Thanks, >> Gilad. >> >> ----- Original Message ----- >>> From: "Vojtech Szocs" >>> To: "Itamar Heim" >>> Cc: "engine-devel", "Einav >>> Cohen", "Gilad Chaplik" >>> , "Daniel Erez", "Tal >>> Nisan", "Tomas Jelinek" >>> , "Alona Kaplan" >>> Sent: Monday, March 4, 2013 7:03:41 PM >>> Subject: Re: Adding Kanagaraj Mayilsamy as a webadmin maintainer >>> >>> +1 :) >>> >>> Vojtech >>> >>> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Vojtech Szocs", "Einav Cohen" >>> , "Gilad Chaplik", "Daniel >>> Erez", "Tal Nisan", "Tomas >>> Jelinek", "Alona Kaplan" >>> Cc: "engine-devel" >>> Sent: Sunday, March 3, 2013 11:03:13 PM >>> Subject: Adding Kanagaraj Mayilsamy as a webadmin maintainer >>> >>> I'd like to propose Kanagaraj as a web admin maintainer - he has been >>> working on the webadmin for about a year, with more than 130 UI >>> patches >>> merged. >>> >>> Thanks, >>> Itamar >>> Thanks all - added to webadmin group (Kanagaraj - feel free to update the subprojects wiki). From kmayilsa at redhat.com Tue Mar 12 04:38:54 2013 From: kmayilsa at redhat.com (Kanagaraj) Date: Tue, 12 Mar 2013 10:08:54 +0530 Subject: [Engine-devel] Adding Kanagaraj Mayilsamy as a webadmin maintainer In-Reply-To: <513E41AA.8010900@redhat.com> References: <828325023.12212985.1363010541467.JavaMail.root@redhat.com> <513DE8A1.6020605@redhat.com> <513E41AA.8010900@redhat.com> Message-ID: <513EB15E.8080108@redhat.com> On 03/12/2013 02:12 AM, Itamar Heim wrote: > On 03/11/2013 04:22 PM, Tal Nisan wrote: >> +1 >> >> >> On 03/11/2013 04:02 PM, Gilad Chaplik wrote: >>> +1 >>> >>> Thanks, >>> Gilad. >>> >>> ----- Original Message ----- >>>> From: "Vojtech Szocs" >>>> To: "Itamar Heim" >>>> Cc: "engine-devel", "Einav >>>> Cohen", "Gilad Chaplik" >>>> , "Daniel Erez", "Tal >>>> Nisan", "Tomas Jelinek" >>>> , "Alona Kaplan" >>>> Sent: Monday, March 4, 2013 7:03:41 PM >>>> Subject: Re: Adding Kanagaraj Mayilsamy as a webadmin maintainer >>>> >>>> +1 :) >>>> >>>> Vojtech >>>> >>>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Vojtech Szocs", "Einav Cohen" >>>> , "Gilad Chaplik", "Daniel >>>> Erez", "Tal Nisan", "Tomas >>>> Jelinek", "Alona Kaplan" >>>> Cc: "engine-devel" >>>> Sent: Sunday, March 3, 2013 11:03:13 PM >>>> Subject: Adding Kanagaraj Mayilsamy as a webadmin maintainer >>>> >>>> I'd like to propose Kanagaraj as a web admin maintainer - he has been >>>> working on the webadmin for about a year, with more than 130 UI >>>> patches >>>> merged. >>>> >>>> Thanks, >>>> Itamar >>>> > > > Thanks all - added to webadmin group (Kanagaraj - feel free to update > the subprojects wiki). Thanks everyone! From wei.d.chen at intel.com Tue Mar 12 08:48:34 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Tue, 12 Mar 2013 08:48:34 +0000 Subject: [Engine-devel] Got some troubles when I want to modify oVirt GUI Message-ID: Hi, In order to add new feature to Ovirt, that is user can choose virtual machine whether on trusted machine or not when it runs up, we modified the relative files. Our goal is when the user click the trusted button, Run/Migration options are disabled. But unfortunately, we haven?t succeeded in graphic interface. I modified these files, I can?t see Host Tab, can you give me some help? Maybe we need modify more files. We did the following efforts: (1) add a trusted radio button. (2) Modify AbstractVmPopupWidget.ui.xml ???? ? ??? (3) Modify AbstractVmPopupWidget.java @UiField(provided = true) @Path(value = "runVMOnTrustedHost.entity") ??? @WithElementId("runVMOnTrustedHost") public EntityModelRadioButtonEditor runVMOnTrustedHostEditor; initListeners method: object.getIsAutoAssign().getPropertyChangedEvent().addListener(new IEventListener() { ??????????? @Override ??????????? public void eventRaised(Event ev, Object sender, EventArgs args) { ??????????????? boolean isAutoAssign = (Boolean) object.getIsAutoAssign().getEntity(); ??????????????? boolean runVMOnTrustedHost = (Boolean) object.getRunVMOnTrustedHost().getEntity(); ??????????????? defaultHostEditor.setEnabled(!isAutoAssign && !runVMOnTrustedHost); ??????????????? //defaultHostEditor.setEnabled(!isAutoAssign); ??????????????? // only this is not bind to the model, so needs to listen to the change explicitly ?????????????? specificHost.setValue(!isAutoAssign && !runVMOnTrustedHost); ?????????????? //specificHost.setValue(!isAutoAssign); ??????????? } ??????? }); isAutoAssignEditor.addDomHandler(new ClickHandler() { ??????????? @Override ??????????? public void onClick(ClickEvent event) { ??????????????? defaultHostEditor.setEnabled(false); ??????????? } ??????? }, ClickEvent.getType()); ??????? vm.getIsAutoAssign().getEntityChangedEvent().addListener(new IEventListener() { ??????????? @Override ??????????? public void eventRaised(Event ev, Object sender, EventArgs args) { ??????????????? if (!isAutoAssignEditor.asRadioButton().getValue() && !runVMOnTrustedHostEditor.asRadioButton().getValue()) ??????????????? { ??????????????????? specificHost.setValue(true, true); ??????????????? } ??????????? } ??????? }); ??????? runVMOnTrustedHostEditor.addDomHandler(new ClickHandler() { ?? ?????????@Override ??????????? public void onClick(ClickEvent event) { ??????????????? defaultHostEditor.setEnabled(false); ??????????? } ??????? }, ClickEvent.getType()); ??????? vm.getRunVMOnTrustedHost().getEntityChangedEvent().addListener(new IEventListener() { ??????????? @Override ??????????? public void eventRaised(Event ev, Object sender, EventArgs args) { ??????????????? if (!runVMOnTrustedHostEditor.asRadioButton().getValue() && !isAutoAssignEditor.asRadioButton().getValue()) ??????????????? { ??????????????????? specificHost.setValue(true, true); ??????????????? } ??????????? } ??????? }); (4) Modify UnitVmModel.java ? private void RunVMOnTrustedHost_EntityChanged(Object sender, EventArgs args) ?? { ??????? if ((Boolean) getRunVMOnTrustedHost().getEntity() == true) ??????? { ??????????? clearAndDisable(getRunVMOnSpecificHost()); ??????????? clearAndDisable(getHostCpu()); ??????? } ??????? else ??????? { ??????????? getRunVMOnSpecificHost().setIsChangable(true); ??????? } ?? ?????behavior.updateCpuPinningVisibility(); ??} -------------- next part -------------- A non-text attachment was scrubbed... Name: AbstractVmPopupWidget.ui.xml Type: text/xml Size: 16078 bytes Desc: AbstractVmPopupWidget.ui.xml URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UnitVmModel.java Type: application/octet-stream Size: 75481 bytes Desc: UnitVmModel.java URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AbstractVmPopupWidget.java Type: application/octet-stream Size: 44510 bytes Desc: AbstractVmPopupWidget.java URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VmListModel.java Type: application/octet-stream Size: 114678 bytes Desc: VmListModel.java URL: From vszocs at redhat.com Tue Mar 12 10:57:39 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Tue, 12 Mar 2013 06:57:39 -0400 (EDT) Subject: [Engine-devel] Got some troubles when I want to modify oVirt GUI In-Reply-To: Message-ID: <241525725.13604300.1363085859679.JavaMail.root@redhat.com> Hi, first of all, did you consider submitting this as RFE in oVirt bugzilla? Maybe it could be useful to have it in oVirt. (Implementing this via UI plugin would be far too complicated, as UI code is tightly coupled with UiCommon code in case of VM dialog.) Regarding UI code changes, the general idea is to implement business logic in UiCommon models (VmListModel, UnitVmModel, etc.) and have UI code bind to these models. It would be best if you just send a patch (diff) instead of specific files, it's really hard to see what changes you made, but based on the files you sent, here are my comments: * Changes in UnitVmModel look good, you basically added two new fields [privateRunVMOnSpecificHost, privateRunVMOnTrustedHost], hooked up their *_EntityChanged methods, and implemented logic for handling field value changes in these methods * Changes in VmListModel look good, you used newly added UnitVmModel fields in onSave [I assume setTrustedHostFlag/setDedicatedVmForVds are new fields for VM entity?], note - you might also want to update UpdateActionAvailability disable migrating VM when RunVMOnTrustedHost=true, etc. * AbstractVmPopupWidget already has specificHost radio button & drop-down on Host dialog tab, and I assume you want to reuse the drop-down (host list) for trustedHost, so just add new radio button there: AbstractVmPopupWidget.ui.xml line 331 * In AbstractVmPopupWidget you to bind newly added RadioButton: @UiField(provided = true) @Ignore @WithElementId("trustedHost") public RadioButton trustedHost; You create trustedHost widget in constructor, and in initTabAvailabilityListeners you just add trustedHost.addValueChangeHandler(...) to have logic when trustedHost gets selected. Regards, Vojtech ----- Original Message ----- From: "Wei D Chen" To: engine-devel at ovirt.org Sent: Tuesday, March 12, 2013 9:48:34 AM Subject: [Engine-devel] Got some troubles when I want to modify oVirt GUI Hi, In order to add new feature to Ovirt, that is user can choose virtual machine whether on trusted machine or not when it runs up, we modified the relative files. Our goal is when the user click the trusted button, Run/Migration options are disabled. But unfortunately, we haven?t succeeded in graphic interface. I modified these files, I can?t see Host Tab, can you give me some help? Maybe we need modify more files. We did the following efforts: (1) add a trusted radio button. (2) Modify AbstractVmPopupWidget.ui.xml ???? ? ??? (3) Modify AbstractVmPopupWidget.java @UiField(provided = true) @Path(value = "runVMOnTrustedHost.entity") ??? @WithElementId("runVMOnTrustedHost") public EntityModelRadioButtonEditor runVMOnTrustedHostEditor; initListeners method: object.getIsAutoAssign().getPropertyChangedEvent().addListener(new IEventListener() { ??????????? @Override ??????????? public void eventRaised(Event ev, Object sender, EventArgs args) { ??????????????? boolean isAutoAssign = (Boolean) object.getIsAutoAssign().getEntity(); ??????????????? boolean runVMOnTrustedHost = (Boolean) object.getRunVMOnTrustedHost().getEntity(); ??????????????? defaultHostEditor.setEnabled(!isAutoAssign && !runVMOnTrustedHost); ??????????????? //defaultHostEditor.setEnabled(!isAutoAssign); ??????????????? // only this is not bind to the model, so needs to listen to the change explicitly ?????????????? specificHost.setValue(!isAutoAssign && !runVMOnTrustedHost); ?????????????? //specificHost.setValue(!isAutoAssign); ??????????? } ??????? }); isAutoAssignEditor.addDomHandler(new ClickHandler() { ??????????? @Override ??????????? public void onClick(ClickEvent event) { ??????????????? defaultHostEditor.setEnabled(false); ??????????? } ??????? }, ClickEvent.getType()); ??????? vm.getIsAutoAssign().getEntityChangedEvent().addListener(new IEventListener() { ??????????? @Override ??????????? public void eventRaised(Event ev, Object sender, EventArgs args) { ??????????????? if (!isAutoAssignEditor.asRadioButton().getValue() && !runVMOnTrustedHostEditor.asRadioButton().getValue()) ??????????????? { ??????????????????? specificHost.setValue(true, true); ??????????????? } ??????????? } ??????? }); ??????? runVMOnTrustedHostEditor.addDomHandler(new ClickHandler() { ?? ?????????@Override ??????????? public void onClick(ClickEvent event) { ??????????????? defaultHostEditor.setEnabled(false); ??????????? } ??????? }, ClickEvent.getType()); ??????? vm.getRunVMOnTrustedHost().getEntityChangedEvent().addListener(new IEventListener() { ??????????? @Override ??????????? public void eventRaised(Event ev, Object sender, EventArgs args) { ??????????????? if (!runVMOnTrustedHostEditor.asRadioButton().getValue() && !isAutoAssignEditor.asRadioButton().getValue()) ??????????????? { ??????????????????? specificHost.setValue(true, true); ??????????????? } ??????????? } ??????? }); (4) Modify UnitVmModel.java ? private void RunVMOnTrustedHost_EntityChanged(Object sender, EventArgs args) ?? { ??????? if ((Boolean) getRunVMOnTrustedHost().getEntity() == true) ??????? { ??????????? clearAndDisable(getRunVMOnSpecificHost()); ??????????? clearAndDisable(getHostCpu()); ??????? } ??????? else ??????? { ??????????? getRunVMOnSpecificHost().setIsChangable(true); ??????? } ?? ?????behavior.updateCpuPinningVisibility(); ??} _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Tue Mar 12 13:30:57 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 12 Mar 2013 15:30:57 +0200 Subject: [Engine-devel] Got some troubles when I want to modify oVirt GUI In-Reply-To: <241525725.13604300.1363085859679.JavaMail.root@redhat.com> References: <241525725.13604300.1363085859679.JavaMail.root@redhat.com> Message-ID: <513F2E11.4060101@redhat.com> On 03/12/2013 12:57 PM, Vojtech Szocs wrote: > Hi, > > first of all, did you consider submitting this as RFE in oVirt bugzilla? Maybe it could be useful to have it in oVirt. (Implementing this via UI plugin would be far too complicated, as UI code is tightly coupled with UiCommon code in case of VM dialog.)> my understanding this is a full blown feature, not a plugin. Wei D - please note UI is to help the user to not make mistakes, but validations must also happen at engine side to cover rest api, etc. > Regarding UI code changes, the general idea is to implement business logic in UiCommon models (VmListModel, UnitVmModel, etc.) and have UI code bind to these models. It would be best if you just send a patch (diff) instead of specific files, it's really hard to see what changes you made, but based on the files you sent, here are my comments: > > * Changes in UnitVmModel look good, you basically added two new fields [privateRunVMOnSpecificHost, privateRunVMOnTrustedHost], hooked up their *_EntityChanged methods, and implemented logic for handling field value changes in these methods > > * Changes in VmListModel look good, you used newly added UnitVmModel fields in onSave [I assume setTrustedHostFlag/setDedicatedVmForVds are new fields for VM entity?], note - you might also want to update UpdateActionAvailability disable migrating VM when RunVMOnTrustedHost=true, etc. > > * AbstractVmPopupWidget already has specificHost radio button & drop-down on Host dialog tab, and I assume you want to reuse the drop-down (host list) for trustedHost, so just add new radio button there: > > AbstractVmPopupWidget.ui.xml line 331 > > > > > > > > > * In AbstractVmPopupWidget you to bind newly added RadioButton: > > @UiField(provided = true) > @Ignore > @WithElementId("trustedHost") > public RadioButton trustedHost; > > You create trustedHost widget in constructor, and in initTabAvailabilityListeners you just add trustedHost.addValueChangeHandler(...) to have logic when trustedHost gets selected. > > Regards, > Vojtech > > > ----- Original Message ----- > From: "Wei D Chen" > To: engine-devel at ovirt.org > Sent: Tuesday, March 12, 2013 9:48:34 AM > Subject: [Engine-devel] Got some troubles when I want to modify oVirt GUI > > Hi, > In order to add new feature to Ovirt, that is user can choose virtual machine whether on trusted machine or not when it runs up, we modified the relative files. > Our goal is when the user click the trusted button, Run/Migration options are disabled. But unfortunately, we haven?t succeeded in graphic interface. > I modified these files, I can?t see Host Tab, can you give me some help? Maybe we need modify more files. We did the following efforts: > (1) add a trusted radio button. > (2) Modify AbstractVmPopupWidget.ui.xml > > > addStyleNames="{style.radioButton}" /> > > (3) Modify AbstractVmPopupWidget.java > @UiField(provided = true) > @Path(value = "runVMOnTrustedHost.entity") > @WithElementId("runVMOnTrustedHost") > public EntityModelRadioButtonEditor runVMOnTrustedHostEditor; > > initListeners method: > object.getIsAutoAssign().getPropertyChangedEvent().addListener(new IEventListener() { > @Override > public void eventRaised(Event ev, Object sender, EventArgs args) { > boolean isAutoAssign = (Boolean) object.getIsAutoAssign().getEntity(); > boolean runVMOnTrustedHost = (Boolean) object.getRunVMOnTrustedHost().getEntity(); > defaultHostEditor.setEnabled(!isAutoAssign && !runVMOnTrustedHost); > //defaultHostEditor.setEnabled(!isAutoAssign); > // only this is not bind to the model, so needs to listen to the change explicitly > specificHost.setValue(!isAutoAssign && !runVMOnTrustedHost); > //specificHost.setValue(!isAutoAssign); > } > }); > isAutoAssignEditor.addDomHandler(new ClickHandler() { > @Override > public void onClick(ClickEvent event) { > defaultHostEditor.setEnabled(false); > } > }, ClickEvent.getType()); > vm.getIsAutoAssign().getEntityChangedEvent().addListener(new IEventListener() { > @Override > public void eventRaised(Event ev, Object sender, EventArgs args) { > if (!isAutoAssignEditor.asRadioButton().getValue() && !runVMOnTrustedHostEditor.asRadioButton().getValue()) > { > specificHost.setValue(true, true); > } > } > }); > runVMOnTrustedHostEditor.addDomHandler(new ClickHandler() { > @Override > public void onClick(ClickEvent event) { > defaultHostEditor.setEnabled(false); > } > }, ClickEvent.getType()); > vm.getRunVMOnTrustedHost().getEntityChangedEvent().addListener(new IEventListener() { > @Override > public void eventRaised(Event ev, Object sender, EventArgs args) { > if (!runVMOnTrustedHostEditor.asRadioButton().getValue() && !isAutoAssignEditor.asRadioButton().getValue()) > { > specificHost.setValue(true, true); > } > } > }); > (4) Modify UnitVmModel.java > private void RunVMOnTrustedHost_EntityChanged(Object sender, EventArgs args) > { > if ((Boolean) getRunVMOnTrustedHost().getEntity() == true) > { > clearAndDisable(getRunVMOnSpecificHost()); > clearAndDisable(getHostCpu()); > } > else > { > getRunVMOnSpecificHost().setIsChangable(true); > } > behavior.updateCpuPinningVisibility(); > ??} > > > _______________________________________________ > 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 ofrenkel at redhat.com Tue Mar 12 13:41:38 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Tue, 12 Mar 2013 09:41:38 -0400 (EDT) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <263871406.8590817.1363020366758.JavaMail.root@redhat.com> Message-ID: <501438656.18651166.1363095698175.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Laszlo Hornyak" > To: "Omer Frenkel" > Cc: "engine-devel" > Sent: Monday, March 11, 2013 6:46:06 PM > Subject: Re: [Engine-devel] new engine watchdog version > > > > ----- Original Message ----- > > From: "Omer Frenkel" > > To: "Laszlo Hornyak" > > Cc: "engine-devel" > > Sent: Monday, March 11, 2013 1:25:39 PM > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > ----- Original Message ----- > > > From: "Laszlo Hornyak" > > > To: "Omer Frenkel" > > > Cc: "engine-devel" > > > Sent: Monday, March 11, 2013 12:15:39 PM > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Omer Frenkel" > > > > To: "Laszlo Hornyak" > > > > Cc: "engine-devel" > > > > Sent: Monday, March 11, 2013 11:12:48 AM > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Laszlo Hornyak" > > > > > To: "Omer Frenkel" > > > > > Cc: "engine-devel" > > > > > Sent: Monday, March 11, 2013 9:59:53 AM > > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Omer Frenkel" > > > > > > To: "Laszlo Hornyak" > > > > > > Cc: "engine-devel" > > > > > > Sent: Sunday, March 10, 2013 8:36:46 AM > > > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Laszlo Hornyak" > > > > > > > To: "engine-devel" > > > > > > > Sent: Friday, March 8, 2013 7:18:59 PM > > > > > > > Subject: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I uploaded a new version of the watchdog patch. This > > > > > > > patch > > > > > > > is > > > > > > > still > > > > > > > a > > > > > > > work in progress, it adds audit log alerts to the > > > > > > > functionality. > > > > > > > http://gerrit.ovirt.org/12419/ > > > > > > > > > > > > > > Feature page: > > > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > > > > > > > Laszlo > > > > > > > _______________________________________________ > > > > > > > Engine-devel mailing list > > > > > > > Engine-devel at ovirt.org > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > Hi, > > > > > > i looked at the patch and there is something i don't > > > > > > understand, > > > > > > i see you are treating the watchdog as a vm device, which > > > > > > is > > > > > > great, > > > > > > so why do we need to save the device details in vm_static > > > > > > table > > > > > > in > > > > > > addition to the vm_devices? > > > > > > i think its even not used at all (only setting the device > > > > > > in > > > > > > command > > > > > > which could be parameters, no need to persist) > > > > > > > > > > > > > > > > Hi Omer, > > > > > > > > > > Thanks, I hoped someone will come up with that question :) > > > > > The > > > > > answer > > > > > is that I followed the established design patterns in the > > > > > backend. > > > > > See smartcard and memory balloon, probably others. The > > > > > motivation > > > > > for this pattern could be that in case of these devices, you > > > > > must > > > > > have the settings in the VM data, not separately in the > > > > > devices. > > > > > Also when vdsbroker builds the devices list, it just asks the > > > > > device > > > > > list. The redundancy is already there, we can make it > > > > > differently > > > > > in > > > > > this case but that will present the readers with a puzzle: > > > > > why > > > > > this > > > > > pattern in feature X, why that pattern in feature Y... > > > > > So I would recommend to leave it like this for now and > > > > > schedule > > > > > a > > > > > cleanup on device handling. Devices deserve a cleanup. > > > > > > > > > > Thx, > > > > > Laszlo > > > > > > > > > > > > > i agree there is a mess that requires clean-up, > > > > but i don't think its a good thing to keep piling up the mess, > > > > i don't like it that smartcard is there, but some other devices > > > > are > > > > ok (balloon and payload) > > > > so we already have 2 'patterns', lets go with the right one.. > > > > and answering also @Doron's question - yes the device data > > > > should > > > > be > > > > kept with the device > > > > > > > > > > Ok, I may have missed the other pattern, could you explain which > > > one > > > do you mean? > > > Balloon does not very different from smartcard, it is there in > > > VM. > > > > > > > the difference is that balloon is not in vm_static table at all > > (the > > only place in the db for it is in vm_devices) > > and smartcard has 'is_smartcard_enabled' field in vm_static in > > addition to vm_devices (which is not needed..) > > Ok, so what you want is that > - the engine should query the devices each time the VM record is set > (from DAO's or Action) > XOR > - the client code (rest-api and frontend) should query the devices to > figure out if the watchdog is there > i prefer this approach, as we do with other sub-collections of vms (disks,networks..) but if we don't expose devices from the engine, so we need some other way of doing it (client specific query for "is XXX device enabled?" or engine set it in the VM record as you suggested. > > > > the way i think we (currently) need to work with devices is: > > add a parameter for it in the parameters, and use it in add/update > > (/run-once?) (as done for balloon) > > run once for watchdog? why? > for watchdog probably not, i meant in general with devices > > i don't know what is the use of the field balloonEnabled in VM, i > > don't see any use of it.. > > It is a write-only property. > > > > > going forward we need to think if we want to expose devices to > > frontend, > > so then we can drop the encapsulation and just use list of devices > > in > > VmBase or something like that > > > > From lhornyak at redhat.com Tue Mar 12 14:03:39 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Tue, 12 Mar 2013 10:03:39 -0400 (EDT) Subject: [Engine-devel] new engine watchdog version In-Reply-To: <501438656.18651166.1363095698175.JavaMail.root@redhat.com> Message-ID: <1381911890.9005780.1363097019399.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Omer Frenkel" > To: "Laszlo Hornyak" > Cc: "engine-devel" > Sent: Tuesday, March 12, 2013 2:41:38 PM > Subject: Re: [Engine-devel] new engine watchdog version > > > > ----- Original Message ----- > > From: "Laszlo Hornyak" > > To: "Omer Frenkel" > > Cc: "engine-devel" > > Sent: Monday, March 11, 2013 6:46:06 PM > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > ----- Original Message ----- > > > From: "Omer Frenkel" > > > To: "Laszlo Hornyak" > > > Cc: "engine-devel" > > > Sent: Monday, March 11, 2013 1:25:39 PM > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Laszlo Hornyak" > > > > To: "Omer Frenkel" > > > > Cc: "engine-devel" > > > > Sent: Monday, March 11, 2013 12:15:39 PM > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Omer Frenkel" > > > > > To: "Laszlo Hornyak" > > > > > Cc: "engine-devel" > > > > > Sent: Monday, March 11, 2013 11:12:48 AM > > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Laszlo Hornyak" > > > > > > To: "Omer Frenkel" > > > > > > Cc: "engine-devel" > > > > > > Sent: Monday, March 11, 2013 9:59:53 AM > > > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Omer Frenkel" > > > > > > > To: "Laszlo Hornyak" > > > > > > > Cc: "engine-devel" > > > > > > > Sent: Sunday, March 10, 2013 8:36:46 AM > > > > > > > Subject: Re: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Laszlo Hornyak" > > > > > > > > To: "engine-devel" > > > > > > > > Sent: Friday, March 8, 2013 7:18:59 PM > > > > > > > > Subject: [Engine-devel] new engine watchdog version > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I uploaded a new version of the watchdog patch. This > > > > > > > > patch > > > > > > > > is > > > > > > > > still > > > > > > > > a > > > > > > > > work in progress, it adds audit log alerts to the > > > > > > > > functionality. > > > > > > > > http://gerrit.ovirt.org/12419/ > > > > > > > > > > > > > > > > Feature page: > > > > > > > > http://www.ovirt.org/Features/Watchdog_engine_support > > > > > > > > > > > > > > > > Laszlo > > > > > > > > _______________________________________________ > > > > > > > > Engine-devel mailing list > > > > > > > > Engine-devel at ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > i looked at the patch and there is something i don't > > > > > > > understand, > > > > > > > i see you are treating the watchdog as a vm device, which > > > > > > > is > > > > > > > great, > > > > > > > so why do we need to save the device details in vm_static > > > > > > > table > > > > > > > in > > > > > > > addition to the vm_devices? > > > > > > > i think its even not used at all (only setting the device > > > > > > > in > > > > > > > command > > > > > > > which could be parameters, no need to persist) > > > > > > > > > > > > > > > > > > > Hi Omer, > > > > > > > > > > > > Thanks, I hoped someone will come up with that question :) > > > > > > The > > > > > > answer > > > > > > is that I followed the established design patterns in the > > > > > > backend. > > > > > > See smartcard and memory balloon, probably others. The > > > > > > motivation > > > > > > for this pattern could be that in case of these devices, > > > > > > you > > > > > > must > > > > > > have the settings in the VM data, not separately in the > > > > > > devices. > > > > > > Also when vdsbroker builds the devices list, it just asks > > > > > > the > > > > > > device > > > > > > list. The redundancy is already there, we can make it > > > > > > differently > > > > > > in > > > > > > this case but that will present the readers with a puzzle: > > > > > > why > > > > > > this > > > > > > pattern in feature X, why that pattern in feature Y... > > > > > > So I would recommend to leave it like this for now and > > > > > > schedule > > > > > > a > > > > > > cleanup on device handling. Devices deserve a cleanup. > > > > > > > > > > > > Thx, > > > > > > Laszlo > > > > > > > > > > > > > > > > i agree there is a mess that requires clean-up, > > > > > but i don't think its a good thing to keep piling up the > > > > > mess, > > > > > i don't like it that smartcard is there, but some other > > > > > devices > > > > > are > > > > > ok (balloon and payload) > > > > > so we already have 2 'patterns', lets go with the right one.. > > > > > and answering also @Doron's question - yes the device data > > > > > should > > > > > be > > > > > kept with the device > > > > > > > > > > > > > Ok, I may have missed the other pattern, could you explain > > > > which > > > > one > > > > do you mean? > > > > Balloon does not very different from smartcard, it is there in > > > > VM. > > > > > > > > > > the difference is that balloon is not in vm_static table at all > > > (the > > > only place in the db for it is in vm_devices) > > > and smartcard has 'is_smartcard_enabled' field in vm_static in > > > addition to vm_devices (which is not needed..) > > > > Ok, so what you want is that > > - the engine should query the devices each time the VM record is > > set > > (from DAO's or Action) > > XOR > > - the client code (rest-api and frontend) should query the devices > > to > > figure out if the watchdog is there > > > > i prefer this approach, as we do with other sub-collections of vms > (disks,networks..) You get these sub-collections with another http request. E.g. /api/vms//disks and then /api/vms//notworks The difference is that watchdog is not a sub-collection, it is in the VM structure. So I guess I would have to add some extra query to the mapping code of the rest-api. Michael? Is this ok for you? > but if we don't expose devices from the engine, so we need some other > way of doing it > (client specific query for "is XXX device enabled?" or engine set it > in the VM record as you suggested. > > > > > > > the way i think we (currently) need to work with devices is: > > > add a parameter for it in the parameters, and use it in > > > add/update > > > (/run-once?) (as done for balloon) > > > > run once for watchdog? why? > > > > for watchdog probably not, i meant in general with devices ok, that's in the SEP-field for now > > > > i don't know what is the use of the field balloonEnabled in VM, i > > > don't see any use of it.. > > > > It is a write-only property. > > > > > > > > going forward we need to think if we want to expose devices to > > > frontend, > > > so then we can drop the encapsulation and just use list of > > > devices > > > in > > > VmBase or something like that > > > > > > > > From dfediuck at redhat.com Tue Mar 12 14:12:42 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Tue, 12 Mar 2013 10:12:42 -0400 (EDT) Subject: [Engine-devel] Got some troubles when I want to modify oVirt GUI In-Reply-To: <513F2E11.4060101@redhat.com> Message-ID: <534694914.18682685.1363097562308.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: engine-devel at ovirt.org > Sent: Tuesday, March 12, 2013 3:30:57 PM > Subject: Re: [Engine-devel] Got some troubles when I want to modify oVirt GUI > > On 03/12/2013 12:57 PM, Vojtech Szocs wrote: > > Hi, > > > > first of all, did you consider submitting this as RFE in oVirt > > bugzilla? Maybe it could be useful to have it in oVirt. > > (Implementing this via UI plugin would be far too complicated, as > > UI code is tightly coupled with UiCommon code in case of VM > > dialog.)> > > my understanding this is a full blown feature, not a plugin. > > Wei D - please note UI is to help the user to not make mistakes, but > validations must also happen at engine side to cover rest api, etc. > +1. Also, a detailed wiki page may help both developer and readers to get a better understanding of how it should look and work. For example, how do you plan to implement the REST API changes? Wei D, I know that Gang Wei started: http://www.ovirt.org/Trusted_compute_pools But as you can see, it does not mention your original intention to implement the UI as a plugin, while as you can see it would be better to have it as an internal UI addition. Also, as mentioned REST parts are missing and a more detailed design for the engine is missing here. Wei D, is there a reason why not top have a detailed page similar to: http://www.ovirt.org/Features/Watchdog_engine_support ? > > > Regarding UI code changes, the general idea is to implement > > business logic in UiCommon models (VmListModel, UnitVmModel, etc.) > > and have UI code bind to these models. It would be best if you > > just send a patch (diff) instead of specific files, it's really > > hard to see what changes you made, but based on the files you > > sent, here are my comments: > > > > * Changes in UnitVmModel look good, you basically added two new > > fields [privateRunVMOnSpecificHost, privateRunVMOnTrustedHost], > > hooked up their *_EntityChanged methods, and implemented logic for > > handling field value changes in these methods > > > > * Changes in VmListModel look good, you used newly added > > UnitVmModel fields in onSave [I assume > > setTrustedHostFlag/setDedicatedVmForVds are new fields for VM > > entity?], note - you might also want to update > > UpdateActionAvailability disable migrating VM when > > RunVMOnTrustedHost=true, etc. > > > > * AbstractVmPopupWidget already has specificHost radio button & > > drop-down on Host dialog tab, and I assume you want to reuse the > > drop-down (host list) for trustedHost, so just add new radio > > button there: > > > > AbstractVmPopupWidget.ui.xml line 331 > > > > > > > ui:field="specificHost" > > addStyleNames="{style.radioButtonSpecificHost}" /> > > > ui:field="trustedHost" > > addStyleNames="{style.radioButtonSpecificHost}" /> > > > text="{constants.specificVmPopup}" /> > > > > > > > > * In AbstractVmPopupWidget you to bind newly added RadioButton: > > > > @UiField(provided = true) > > @Ignore > > @WithElementId("trustedHost") > > public RadioButton trustedHost; > > > > You create trustedHost widget in constructor, and in > > initTabAvailabilityListeners you just add > > trustedHost.addValueChangeHandler(...) to have logic when > > trustedHost gets selected. > > > > Regards, > > Vojtech > > > > > > ----- Original Message ----- > > From: "Wei D Chen" > > To: engine-devel at ovirt.org > > Sent: Tuesday, March 12, 2013 9:48:34 AM > > Subject: [Engine-devel] Got some troubles when I want to modify > > oVirt GUI > > > > Hi, > > In order to add new feature to Ovirt, that is user can choose > > virtual machine whether on trusted machine or not when it runs > > up, we modified the relative files. > > Our goal is when the user click the trusted button, Run/Migration > > options are disabled. But unfortunately, we haven?t succeeded in > > graphic interface. > > I modified these files, I can?t see Host Tab, can you give me some > > help? Maybe we need modify more files. We did the following > > efforts: > > (1) add a trusted radio button. > > (2) Modify AbstractVmPopupWidget.ui.xml > > > > > > > ui:field="runVMOnTrustedHostEditor" > > addStyleNames="{style.radioButton}" /> > > > > (3) Modify AbstractVmPopupWidget.java > > @UiField(provided = true) > > @Path(value = "runVMOnTrustedHost.entity") > > @WithElementId("runVMOnTrustedHost") > > public EntityModelRadioButtonEditor runVMOnTrustedHostEditor; > > > > initListeners method: > > object.getIsAutoAssign().getPropertyChangedEvent().addListener(new > > IEventListener() { > > @Override > > public void eventRaised(Event ev, Object sender, > > EventArgs args) { > > boolean isAutoAssign = (Boolean) > > object.getIsAutoAssign().getEntity(); > > boolean runVMOnTrustedHost = (Boolean) > > object.getRunVMOnTrustedHost().getEntity(); > > defaultHostEditor.setEnabled(!isAutoAssign && > > !runVMOnTrustedHost); > > //defaultHostEditor.setEnabled(!isAutoAssign); > > // only this is not bind to the model, so needs to > > listen to the change explicitly > > specificHost.setValue(!isAutoAssign && > > !runVMOnTrustedHost); > > //specificHost.setValue(!isAutoAssign); > > } > > }); > > isAutoAssignEditor.addDomHandler(new ClickHandler() { > > @Override > > public void onClick(ClickEvent event) { > > defaultHostEditor.setEnabled(false); > > } > > }, ClickEvent.getType()); > > vm.getIsAutoAssign().getEntityChangedEvent().addListener(new > > IEventListener() { > > @Override > > public void eventRaised(Event ev, Object sender, > > EventArgs args) { > > if (!isAutoAssignEditor.asRadioButton().getValue() > > && > > !runVMOnTrustedHostEditor.asRadioButton().getValue()) > > { > > specificHost.setValue(true, true); > > } > > } > > }); > > runVMOnTrustedHostEditor.addDomHandler(new ClickHandler() > > { > > @Override > > public void onClick(ClickEvent event) { > > defaultHostEditor.setEnabled(false); > > } > > }, ClickEvent.getType()); > > vm.getRunVMOnTrustedHost().getEntityChangedEvent().addListener(new > > IEventListener() { > > @Override > > public void eventRaised(Event ev, Object sender, > > EventArgs args) { > > if > > (!runVMOnTrustedHostEditor.asRadioButton().getValue() > > && > > !isAutoAssignEditor.asRadioButton().getValue()) > > { > > specificHost.setValue(true, true); > > } > > } > > }); > > (4) Modify UnitVmModel.java > > private void RunVMOnTrustedHost_EntityChanged(Object sender, > > EventArgs args) > > { > > if ((Boolean) getRunVMOnTrustedHost().getEntity() == true) > > { > > clearAndDisable(getRunVMOnSpecificHost()); > > clearAndDisable(getHostCpu()); > > } > > else > > { > > getRunVMOnSpecificHost().setIsChangable(true); > > } > > behavior.updateCpuPinningVisibility(); > > ??} > > > > > > _______________________________________________ > > 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 lhornyak at redhat.com Tue Mar 12 14:37:41 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Tue, 12 Mar 2013 10:37:41 -0400 (EDT) Subject: [Engine-devel] VmDynamic kvm_enable In-Reply-To: <728162885.8986402.1363094756983.JavaMail.root@redhat.com> Message-ID: <817960170.9029223.1363099061219.JavaMail.root@redhat.com> Hi, I came across a VmDynamic property 'kvm_enable'. It sounds strange for me, because ovirt is very colsely integrated with kvm. So a short dig into this flag... There is a similar thing for the VDS, it is set to true by vdsm is the host CPU has a VT flag. It is actually used to check if the host is OK to run VMS. But the one for Vm it looks like a distributed logical loop in vdsm: it is set when constructing a VM object (vdsm/vm.py:~343) from the data sent by the client (engine) and then reported back in vm stats, so it is just a roundtrip between vdsm and it's client. In the engine side, it is just keeps sending it between the frontend DB and vdsm, never part of a decision. Is this still needed here? Can I remove? VDSM guys? Thx, Laszlo From danken at redhat.com Tue Mar 12 15:07:09 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 12 Mar 2013 17:07:09 +0200 Subject: [Engine-devel] VmDynamic kvm_enable In-Reply-To: <817960170.9029223.1363099061219.JavaMail.root@redhat.com> References: <728162885.8986402.1363094756983.JavaMail.root@redhat.com> <817960170.9029223.1363099061219.JavaMail.root@redhat.com> Message-ID: <20130312150709.GH17723@redhat.com> On Tue, Mar 12, 2013 at 10:37:41AM -0400, Laszlo Hornyak wrote: > Hi, > > I came across a VmDynamic property 'kvm_enable'. It sounds strange for me, because ovirt is very colsely integrated with kvm. So a short dig into this flag... > There is a similar thing for the VDS, it is set to true by vdsm is the host CPU has a VT flag. It is actually used to check if the host is OK to run VMS. > > But the one for Vm it looks like a distributed logical loop in vdsm: it is set when constructing a VM object (vdsm/vm.py:~343) from the data sent by the client (engine) and then reported back in vm stats, so it is just a roundtrip between vdsm and it's client. > In the engine side, it is just keeps sending it between the frontend DB and vdsm, never part of a decision. > > Is this still needed here? Can I remove? > VDSM guys? I have a vague memeory that once upon at time, qemu occasionally failed to enable kvm support - even though it was asked to. I then silently switched to emulated mode, which was grindingly slow. Engine wanted to know about such occasions. I believe that a better technical approach would have been to kill the violating process, and not let it run at all (unless qemu emulation was strictly requested by management). Anyway, as you have noted, this has rotten away throuh the years, and unless older Engine versions are expecting this value in any way, I am all for dropping it. Dan. From vszocs at redhat.com Tue Mar 12 17:43:10 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Tue, 12 Mar 2013 13:43:10 -0400 (EDT) Subject: [Engine-devel] Some notes on UI composition In-Reply-To: <1869170273.13737360.1363102717283.JavaMail.root@redhat.com> Message-ID: <2138720842.13814889.1363110190186.JavaMail.root@redhat.com> Hi guys, I've encountered an interesting pattern while working on a recent patch: some View classes actually embed other View classes, and add those embedded Views to the (top-level) View. For example, ImportVmPopupView has a field "ImportVmGeneralSubTabView generalView", which is created as part of constructor and added to ImportVmPopupView's layout. The bottom line is, please don't use this pattern. Views are architectural components in Model-View-Presenter which are living in a particular scope (e.g. singleton/non-singleton), so UI composition should be always done on Widget level, instead of View level. In other words, ImportVmPopupView shouldn't embed ImportVmGeneralSubTabView, but instead embed UI (Widgets) similar to ImportVmGeneralSubTabView. In case embedded View's UI is complex, we can just create a reusable widget that would be used in both ImportVmPopupView and ImportVmGeneralSubTabView. Otherwise, we could run into problems, especially since ImportVmPopupView is dialog-specific (non-singleton) and ImportVmGeneralSubTabView is sub-tab-specific (singleton). In Model-View-Presenter, View != immediate Widget, View == MVP component wrapping UI (Widget) and bound to a specific scope, so that's the reason why UI composition should be always done on Widget level (on the other hand, subclassing Views is perfectly OK). Sorry for being police man here .. it's just a note to keep in mind for future :) Regards, Vojtech From iheim at redhat.com Tue Mar 12 22:58:44 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 13 Mar 2013 00:58:44 +0200 Subject: [Engine-devel] VmDynamic kvm_enable In-Reply-To: <20130312150709.GH17723@redhat.com> References: <728162885.8986402.1363094756983.JavaMail.root@redhat.com> <817960170.9029223.1363099061219.JavaMail.root@redhat.com> <20130312150709.GH17723@redhat.com> Message-ID: <513FB324.6030108@redhat.com> On 03/12/2013 05:07 PM, Dan Kenigsberg wrote: > On Tue, Mar 12, 2013 at 10:37:41AM -0400, Laszlo Hornyak wrote: >> Hi, >> >> I came across a VmDynamic property 'kvm_enable'. It sounds strange for me, because ovirt is very colsely integrated with kvm. So a short dig into this flag... >> There is a similar thing for the VDS, it is set to true by vdsm is the host CPU has a VT flag. It is actually used to check if the host is OK to run VMS. >> >> But the one for Vm it looks like a distributed logical loop in vdsm: it is set when constructing a VM object (vdsm/vm.py:~343) from the data sent by the client (engine) and then reported back in vm stats, so it is just a roundtrip between vdsm and it's client. >> In the engine side, it is just keeps sending it between the frontend DB and vdsm, never part of a decision. >> >> Is this still needed here? Can I remove? >> VDSM guys? > > I have a vague memeory that once upon at time, qemu occasionally failed > to enable kvm support - even though it was asked to. I then silently > switched to emulated mode, which was grindingly slow. Engine wanted to > know about such occasions. > > I believe that a better technical approach would have been to kill the > violating process, and not let it run at all (unless qemu emulation was > strictly requested by management). > > Anyway, as you have noted, this has rotten away throuh the years, and > unless older Engine versions are expecting this value in any way, I am > all for dropping it. I think this was about something else - the kvmEnable flag was used to launch installations of guests not correctly supported by kvm that required real mode or something like that. hopefully not relevant any more, but need to validate won't break older engines indeed. From wei.d.chen at intel.com Wed Mar 13 02:51:45 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Wed, 13 Mar 2013 02:51:45 +0000 Subject: [Engine-devel] Got some troubles when I want to modify oVirt GUI In-Reply-To: <534694914.18682685.1363097562308.JavaMail.root@redhat.com> References: <513F2E11.4060101@redhat.com> <534694914.18682685.1363097562308.JavaMail.root@redhat.com> Message-ID: Thanks Doron & Vojetch & Itamar, we will update our design wiki page ASAP, and also, REST API is in pipeline. Best Regards, Dave Chen > -----Original Message----- > From: Doron Fediuck [mailto:dfediuck at redhat.com] > Sent: Tuesday, March 12, 2013 10:13 PM > To: Chen, Wei D > Cc: engine-devel at ovirt.org; Vojtech Szocs; Itamar Heim > Subject: Re: [Engine-devel] Got some troubles when I want to modify oVirt GUI > > > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Vojtech Szocs" > > Cc: engine-devel at ovirt.org > > Sent: Tuesday, March 12, 2013 3:30:57 PM > > Subject: Re: [Engine-devel] Got some troubles when I want to modify > > oVirt GUI > > > > On 03/12/2013 12:57 PM, Vojtech Szocs wrote: > > > Hi, > > > > > > first of all, did you consider submitting this as RFE in oVirt > > > bugzilla? Maybe it could be useful to have it in oVirt. > > > (Implementing this via UI plugin would be far too complicated, as UI > > > code is tightly coupled with UiCommon code in case of VM dialog.)> > > > > my understanding this is a full blown feature, not a plugin. > > > > Wei D - please note UI is to help the user to not make mistakes, but > > validations must also happen at engine side to cover rest api, etc. > > > > +1. > Also, a detailed wiki page may help both developer and readers to get a better > understanding of how it should look and work. > For example, how do you plan to implement the REST API changes? > > Wei D, I know that Gang Wei started: > http://www.ovirt.org/Trusted_compute_pools But as you can see, it does not > mention your original intention to implement the UI as a plugin, while as you > can see it would be better to have it as an internal UI addition. Also, as > mentioned REST parts are missing and a more detailed design for the engine is > missing here. > > Wei D, is there a reason why not top have a detailed page similar > to: http://www.ovirt.org/Features/Watchdog_engine_support ? > > > > > > Regarding UI code changes, the general idea is to implement business > > > logic in UiCommon models (VmListModel, UnitVmModel, etc.) and have > > > UI code bind to these models. It would be best if you just send a > > > patch (diff) instead of specific files, it's really hard to see what > > > changes you made, but based on the files you sent, here are my > > > comments: > > > > > > * Changes in UnitVmModel look good, you basically added two new > > > fields [privateRunVMOnSpecificHost, privateRunVMOnTrustedHost], > > > hooked up their *_EntityChanged methods, and implemented logic for > > > handling field value changes in these methods > > > > > > * Changes in VmListModel look good, you used newly added UnitVmModel > > > fields in onSave [I assume setTrustedHostFlag/setDedicatedVmForVds > > > are new fields for VM entity?], note - you might also want to update > > > UpdateActionAvailability disable migrating VM when > > > RunVMOnTrustedHost=true, etc. > > > > > > * AbstractVmPopupWidget already has specificHost radio button & > > > drop-down on Host dialog tab, and I assume you want to reuse the > > > drop-down (host list) for trustedHost, so just add new radio button > > > there: > > > > > > AbstractVmPopupWidget.ui.xml line 331 > > > > > > > > > > > ui:field="specificHost" > > > addStyleNames="{style.radioButtonSpecificHost}" /> > > > > > ui:field="trustedHost" > > > addStyleNames="{style.radioButtonSpecificHost}" /> > > > > > text="{constants.specificVmPopup}" /> > > > > > > > > > > > > * In AbstractVmPopupWidget you to bind newly added RadioButton: > > > > > > @UiField(provided = true) > > > @Ignore > > > @WithElementId("trustedHost") > > > public RadioButton trustedHost; > > > > > > You create trustedHost widget in constructor, and in > > > initTabAvailabilityListeners you just add > > > trustedHost.addValueChangeHandler(...) to have logic when > > > trustedHost gets selected. > > > > > > Regards, > > > Vojtech > > > > > > > > > ----- Original Message ----- > > > From: "Wei D Chen" > > > To: engine-devel at ovirt.org > > > Sent: Tuesday, March 12, 2013 9:48:34 AM > > > Subject: [Engine-devel] Got some troubles when I want to modify > > > oVirt GUI > > > > > > Hi, > > > In order to add new feature to Ovirt, that is user can choose > > > virtual machine whether on trusted machine or not when it runs > > > up, we modified the relative files. > > > Our goal is when the user click the trusted button, Run/Migration > > > options are disabled. But unfortunately, we haven?t succeeded in > > > graphic interface. > > > I modified these files, I can?t see Host Tab, can you give me some > > > help? Maybe we need modify more files. We did the following > > > efforts: > > > (1) add a trusted radio button. > > > (2) Modify AbstractVmPopupWidget.ui.xml > > verticalAlignment='ALIGN_MIDDLE'> > > > > > > > > ui:field="runVMOnTrustedHostEditor" > > > addStyleNames="{style.radioButton}" /> > > > > > > (3) Modify AbstractVmPopupWidget.java @UiField(provided = true) > > > @Path(value = "runVMOnTrustedHost.entity") > > > @WithElementId("runVMOnTrustedHost") > > > public EntityModelRadioButtonEditor runVMOnTrustedHostEditor; > > > > > > initListeners method: > > > object.getIsAutoAssign().getPropertyChangedEvent().addListener(new > > > IEventListener() { > > > @Override > > > public void eventRaised(Event ev, Object sender, > > > EventArgs args) { > > > boolean isAutoAssign = (Boolean) > > > object.getIsAutoAssign().getEntity(); > > > boolean runVMOnTrustedHost = (Boolean) > > > object.getRunVMOnTrustedHost().getEntity(); > > > defaultHostEditor.setEnabled(!isAutoAssign && > > > !runVMOnTrustedHost); > > > //defaultHostEditor.setEnabled(!isAutoAssign); > > > // only this is not bind to the model, so needs to > > > listen to the change explicitly > > > specificHost.setValue(!isAutoAssign && > > > !runVMOnTrustedHost); > > > //specificHost.setValue(!isAutoAssign); > > > } > > > }); > > > isAutoAssignEditor.addDomHandler(new ClickHandler() { > > > @Override > > > public void onClick(ClickEvent event) { > > > defaultHostEditor.setEnabled(false); > > > } > > > }, ClickEvent.getType()); > > > > vm.getIsAutoAssign().getEntityChangedEvent().addListener(new > > > IEventListener() { > > > @Override > > > public void eventRaised(Event ev, Object sender, > > > EventArgs args) { > > > if (!isAutoAssignEditor.asRadioButton().getValue() > > > && > > > !runVMOnTrustedHostEditor.asRadioButton().getValu > e()) > > > { > > > specificHost.setValue(true, true); > > > } > > > } > > > }); > > > runVMOnTrustedHostEditor.addDomHandler(new > ClickHandler() > > > { > > > @Override > > > public void onClick(ClickEvent event) { > > > defaultHostEditor.setEnabled(false); > > > } > > > }, ClickEvent.getType()); > > > > vm.getRunVMOnTrustedHost().getEntityChangedEvent().addListener(new > > > IEventListener() { > > > @Override > > > public void eventRaised(Event ev, Object sender, > > > EventArgs args) { > > > if > > > > (!runVMOnTrustedHostEditor.asRadioButton().getValue() > > > && > > > !isAutoAssignEditor.asRadioButton().getValue()) > > > { > > > specificHost.setValue(true, true); > > > } > > > } > > > }); > > > (4) Modify UnitVmModel.java > > > private void RunVMOnTrustedHost_EntityChanged(Object sender, > > > EventArgs args) > > > { > > > if ((Boolean) getRunVMOnTrustedHost().getEntity() == true) > > > { > > > clearAndDisable(getRunVMOnSpecificHost()); > > > clearAndDisable(getHostCpu()); > > > } > > > else > > > { > > > getRunVMOnSpecificHost().setIsChangable(true); > > > } > > > behavior.updateCpuPinningVisibility(); > > > ??} > > > > > > > > > _______________________________________________ > > > 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 lhornyak at redhat.com Wed Mar 13 09:13:06 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Wed, 13 Mar 2013 05:13:06 -0400 (EDT) Subject: [Engine-devel] engine watchdog support - new version in gerrit In-Reply-To: <1408644151.9317535.1363165754949.JavaMail.root@redhat.com> Message-ID: <861528542.9318240.1363165985999.JavaMail.root@redhat.com> hi, A new version of the engine watchdog support is available in gerrit. This version finished the rest-api support by adding the capabilities resources. The features listed in the feature page are ready, so if you have enough time and courage, please give it a try! I have left the patch with [wip] because I am waiting for the end of some discussions about the technical background. http://gerrit.ovirt.org/#/c/12419/ Thx, Laszlo From danken at redhat.com Wed Mar 13 09:22:58 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 13 Mar 2013 11:22:58 +0200 Subject: [Engine-devel] VmDynamic kvm_enable In-Reply-To: <513FB324.6030108@redhat.com> References: <728162885.8986402.1363094756983.JavaMail.root@redhat.com> <817960170.9029223.1363099061219.JavaMail.root@redhat.com> <20130312150709.GH17723@redhat.com> <513FB324.6030108@redhat.com> Message-ID: <20130313092258.GF9339@redhat.com> On Wed, Mar 13, 2013 at 12:58:44AM +0200, Itamar Heim wrote: > On 03/12/2013 05:07 PM, Dan Kenigsberg wrote: > >On Tue, Mar 12, 2013 at 10:37:41AM -0400, Laszlo Hornyak wrote: > >>Hi, > >> > >>I came across a VmDynamic property 'kvm_enable'. It sounds strange for me, because ovirt is very colsely integrated with kvm. So a short dig into this flag... > >>There is a similar thing for the VDS, it is set to true by vdsm is the host CPU has a VT flag. It is actually used to check if the host is OK to run VMS. > >> > >>But the one for Vm it looks like a distributed logical loop in vdsm: it is set when constructing a VM object (vdsm/vm.py:~343) from the data sent by the client (engine) and then reported back in vm stats, so it is just a roundtrip between vdsm and it's client. > >>In the engine side, it is just keeps sending it between the frontend DB and vdsm, never part of a decision. > >> > >>Is this still needed here? Can I remove? > >>VDSM guys? > > > >I have a vague memeory that once upon at time, qemu occasionally failed > >to enable kvm support - even though it was asked to. I then silently > >switched to emulated mode, which was grindingly slow. Engine wanted to > >know about such occasions. > > > >I believe that a better technical approach would have been to kill the > >violating process, and not let it run at all (unless qemu emulation was > >strictly requested by management). > > > >Anyway, as you have noted, this has rotten away throuh the years, and > >unless older Engine versions are expecting this value in any way, I am > >all for dropping it. > > I think this was about something else - the kvmEnable flag was used > to launch installations of guests not correctly supported by kvm > that required real mode or something like that. You are now speaking about kvmEnable sent by Engine to Vdsm. Laszlo was speaking about a supposedly-dynamically-changing kvmEnable that is reported back, in getVmStats. > hopefully not relevant any more, but need to validate won't break > older engines indeed. From smizrahi at redhat.com Wed Mar 13 21:15:18 2013 From: smizrahi at redhat.com (Saggi Mizrahi) Date: Wed, 13 Mar 2013 17:15:18 -0400 (EDT) Subject: [Engine-devel] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <51387942.606@redhat.com> Message-ID: <241690339.14553747.1363209318441.JavaMail.root@redhat.com> I am completely against this. It make the return value differ according to input which is a big no no when talking about type safe APIs. The only reason we have this problem is because there is this thing against making multiple calls. Just split it up. getVmRuntimeStats() - transient things like mem and cpu% getVmInformation() - (semi)static things like disk\networking layout etc. Each updated at different intervals. ----- Original Message ----- > From: "Vinzenz Feenstra" > To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org > Sent: Thursday, March 7, 2013 6:25:54 AM > Subject: [Engine-devel] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization > > > Please find the prettier version on the wiki: > http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > > Proposal VDSM - Engine Data Statistics Retrieval > VDSM <=> Engine data retrieval optimization > Motivation: > > > Currently the RHEVM engine is polling the a lot of data from VDSM > every 15 seconds. This should be optimized and the amount of data > requested should be more specific. > > For each VM the data currently contains much more information than > actually needed which blows up the size of the XML content quite > big. We could optimize this by splitting the reply on the getVmStats > based on the request of the engine into sections. For this reason > Omer Frenkel and me have split up the data into parts based on their > usage. > > This data can and usually does change during the lifetime of the VM. > Rarely Changed: > > > This data is change not very frequent and it should be enough to > update this only once in a while. Most commonly this data changes > after changes made in the UI or after a migration of the VM to > another Host. Status = Running acpiEnable = true vmType = kvm > guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 > kvmEnable = true # this should be constant and never changed > pauseCode = NOERR monitorResponse = 0 session = Locked # unused > netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', > 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': ['10.34.60.148'], > 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', > 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 3.2.2', > 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 > 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB > 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = 11314 > guestIPs = 10.34.60.148 # duplicated info displayIp = 0 displayPort > = 5902 displaySecurePort = 5903 username = user at W864GUESTAGENTT > clientIp = lastLogin = 1361976900.67 Often Changed: > > > This data is changed quite often however it is not necessary to > update this data every 15 seconds. As this is cumulative data and > reflects the current status, and it does not need to be snapshotted > every 15 seconds to retrieve statistics. The data can be retrieved > in much more generous time slices. (e.g. Every 5 minutes) network = > {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', > 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': '0.0', > 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': > 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': '64055406592', > 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': > '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset = 14422 > elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09 # > unused Often Changed but unused > > > This data does not seem to be used in the engine at all. It is not > even used in the data warehouse. memoryStats = {'swap_out': '0', > 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', 'pageflt': > '0', 'mem_total': '2096736', 'mem_unused': '1466884'} balloonInfo = > {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = {'vda': > {'readLatency': '0', 'apparentsize': '64424509440', 'writeLatency': > '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', > 'flushLatency': '156549', 'readRate': '0.00', 'truesize': > '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': '0', > 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', > 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very > frequent uppdates needed by webadmin portal: > > > This data is mostly needed for the webadmin portal and might be > required to be updated quite often. An exception here is the > statsAge field, which seems to be unused by the Engine. This data > could be requested every 15 seconds to keep things as they are now. > cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution for > VDSM & Engine: > > > We will introduce new optional parameters to getVmStats, > getAllVmStats and list to allow a finer grained specification of > data which should be included. > > Parameter: statsType = (getVmStats, getAllVmStats only) > Allowed values: > > * full (default to keep backwards compatibility) > * app-list (Just send the application list) > * rare (include everything from rarely changed to very frequent) > * often (include everything from often changed to very frequent) > * frequent (only send the very frequently changed items) > > > > Parameter: clientId = The client id is specified by the > client and should be unique however constantly used. > > Parameter: diff = In combination with the clientId VDSM > will send only differences to the previous request from the named > clientId. (if diff=true) > > > Additional Change: > > > Besides the introduction of the new parameters for list, getVmStats > and getAllVmStats it might make sense to include a hash for the > appList into the rarely changed section of the response which would > allow to identify changes and avoid having to sent the complete > appList every so often and only if the hash known to the client is > outdated. > > Note: The appList (Application List) reported by the guest agent > could be fully implemented on request only, as long as the guest > agent installed supports this. As there seems to be a request to > have the complete list of installed applications on all guests this > data could be quite extensive and a huge list. On the other hand > this data is only rarely visible and therefore it should not be > requested all the time and only on demand. Improvement of the Guest > Agent: > > > As part of the proposed solution it is necessary to improve the guest > agent as well. For the full application list there should be > implemented a caching system which will be fully reactive and should > not poll the application list for example all the time. The guest > can create a prepared data file containing all data in the JSON > format (as used for the communication with VDSM via VIO) and just > have to read that file from disk and directly sends it to VDSM. > However it is quite possible that this list is to big and it might > have to be chunked into pieces. (Multiple messages, which would have > to be supported by VDSM then as well) The solution for this is to > make VDSM request this data and it will retrieve the data necessary > on request only. -- > Regards, > > Vinzenz Feenstra | Senior Software Engineer > RedHat Engineering Virtualization R & D > Phone: +420 532 294 625 > IRC: vfeenstr or evilissimo > > Better technology. Faster innovation. Powered by community > collaboration. > See how it works at redhat.com > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From abaron at redhat.com Wed Mar 13 21:39:24 2013 From: abaron at redhat.com (Ayal Baron) Date: Wed, 13 Mar 2013 17:39:24 -0400 (EDT) Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <241690339.14553747.1363209318441.JavaMail.root@redhat.com> Message-ID: <336597232.7636487.1363210764912.JavaMail.root@redhat.com> ----- Original Message ----- > I am completely against this. > It make the return value differ according to input which > is a big no no when talking about type safe APIs. > > The only reason we have this problem is because there is this > thing against making multiple calls. > > Just split it up. > getVmRuntimeStats() - transient things like mem and cpu% > getVmInformation() - (semi)static things like disk\networking layout > etc. > Each updated at different intervals. +1 on splitting the data up into 2 separate API calls. You could potentially add a checksum (md5, or any other way) of the "static" data to getVmRuntimeStats and not bother even with polling the VmInformation if this hasn't changed. Then you could poll as often as you'd like the stats and immediately see if you also need to retrieve VmInfo or not (you rarely would). > > ----- Original Message ----- > > From: "Vinzenz Feenstra" > > To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org > > Sent: Thursday, March 7, 2013 6:25:54 AM > > Subject: [Engine-devel] Proposal VDSM <=> Engine Data Statistics > > Retrieval Optimization > > > > > > Please find the prettier version on the wiki: > > http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > > > > Proposal VDSM - Engine Data Statistics Retrieval > > VDSM <=> Engine data retrieval optimization > > Motivation: > > > > > > Currently the RHEVM engine is polling the a lot of data from VDSM > > every 15 seconds. This should be optimized and the amount of data > > requested should be more specific. > > > > For each VM the data currently contains much more information than > > actually needed which blows up the size of the XML content quite > > big. We could optimize this by splitting the reply on the > > getVmStats > > based on the request of the engine into sections. For this reason > > Omer Frenkel and me have split up the data into parts based on > > their > > usage. > > > > This data can and usually does change during the lifetime of the > > VM. > > Rarely Changed: > > > > > > This data is change not very frequent and it should be enough to > > update this only once in a while. Most commonly this data changes > > after changes made in the UI or after a migration of the VM to > > another Host. Status = Running acpiEnable = true vmType = kvm > > guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 > > kvmEnable = true # this should be constant and never changed > > pauseCode = NOERR monitorResponse = 0 session = Locked # unused > > netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', > > 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': ['10.34.60.148'], > > 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', > > 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 > > 3.2.2', > > 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 > > 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB > > 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = 11314 > > guestIPs = 10.34.60.148 # duplicated info displayIp = 0 displayPort > > = 5902 displaySecurePort = 5903 username = user at W864GUESTAGENTT > > clientIp = lastLogin = 1361976900.67 Often Changed: > > > > > > This data is changed quite often however it is not necessary to > > update this data every 15 seconds. As this is cumulative data and > > reflects the current status, and it does not need to be snapshotted > > every 15 seconds to retrieve statistics. The data can be retrieved > > in much more generous time slices. (e.g. Every 5 minutes) network = > > {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', > > 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': > > '0.0', > > 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': > > 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': '64055406592', > > 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': > > '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset = > > 14422 > > elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09 # > > unused Often Changed but unused > > > > > > This data does not seem to be used in the engine at all. It is not > > even used in the data warehouse. memoryStats = {'swap_out': '0', > > 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', 'pageflt': > > '0', 'mem_total': '2096736', 'mem_unused': '1466884'} balloonInfo = > > {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = {'vda': > > {'readLatency': '0', 'apparentsize': '64424509440', 'writeLatency': > > '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', > > 'flushLatency': '156549', 'readRate': '0.00', 'truesize': > > '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': '0', > > 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', > > 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very > > frequent uppdates needed by webadmin portal: > > > > > > This data is mostly needed for the webadmin portal and might be > > required to be updated quite often. An exception here is the > > statsAge field, which seems to be unused by the Engine. This data > > could be requested every 15 seconds to keep things as they are now. > > cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution for > > VDSM & Engine: > > > > > > We will introduce new optional parameters to getVmStats, > > getAllVmStats and list to allow a finer grained specification of > > data which should be included. > > > > Parameter: statsType = (getVmStats, getAllVmStats only) > > Allowed values: > > > > * full (default to keep backwards compatibility) > > * app-list (Just send the application list) > > * rare (include everything from rarely changed to very > > frequent) > > * often (include everything from often changed to very > > frequent) > > * frequent (only send the very frequently changed items) > > > > > > > > Parameter: clientId = The client id is specified by the > > client and should be unique however constantly used. > > > > Parameter: diff = In combination with the clientId VDSM > > will send only differences to the previous request from the named > > clientId. (if diff=true) > > > > > > Additional Change: > > > > > > Besides the introduction of the new parameters for list, getVmStats > > and getAllVmStats it might make sense to include a hash for the > > appList into the rarely changed section of the response which would > > allow to identify changes and avoid having to sent the complete > > appList every so often and only if the hash known to the client is > > outdated. > > > > Note: The appList (Application List) reported by the guest agent > > could be fully implemented on request only, as long as the guest > > agent installed supports this. As there seems to be a request to > > have the complete list of installed applications on all guests this > > data could be quite extensive and a huge list. On the other hand > > this data is only rarely visible and therefore it should not be > > requested all the time and only on demand. Improvement of the Guest > > Agent: > > > > > > As part of the proposed solution it is necessary to improve the > > guest > > agent as well. For the full application list there should be > > implemented a caching system which will be fully reactive and > > should > > not poll the application list for example all the time. The guest > > can create a prepared data file containing all data in the JSON > > format (as used for the communication with VDSM via VIO) and just > > have to read that file from disk and directly sends it to VDSM. > > However it is quite possible that this list is to big and it might > > have to be chunked into pieces. (Multiple messages, which would > > have > > to be supported by VDSM then as well) The solution for this is to > > make VDSM request this data and it will retrieve the data necessary > > on request only. -- > > Regards, > > > > Vinzenz Feenstra | Senior Software Engineer > > RedHat Engineering Virtualization R & D > > Phone: +420 532 294 625 > > IRC: vfeenstr or evilissimo > > > > Better technology. Faster innovation. Powered by community > > collaboration. > > See how it works at redhat.com > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > From smizrahi at redhat.com Wed Mar 13 21:50:49 2013 From: smizrahi at redhat.com (Saggi Mizrahi) Date: Wed, 13 Mar 2013 17:50:49 -0400 (EDT) Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <336597232.7636487.1363210764912.JavaMail.root@redhat.com> Message-ID: <1824380735.14562758.1363211449756.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ayal Baron" > To: "Saggi Mizrahi" > Cc: engine-devel at ovirt.org, vdsm-devel at lists.fedorahosted.org, "Vinzenz Feenstra" > Sent: Wednesday, March 13, 2013 5:39:24 PM > Subject: Re: [vdsm] [Engine-devel] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization > > > > ----- Original Message ----- > > I am completely against this. > > It make the return value differ according to input which > > is a big no no when talking about type safe APIs. > > > > The only reason we have this problem is because there is this > > thing against making multiple calls. > > > > Just split it up. > > getVmRuntimeStats() - transient things like mem and cpu% > > getVmInformation() - (semi)static things like disk\networking > > layout > > etc. > > Each updated at different intervals. > > +1 on splitting the data up into 2 separate API calls. > You could potentially add a checksum (md5, or any other way) of the > "static" data to getVmRuntimeStats and not bother even with polling > the VmInformation if this hasn't changed. Then you could poll as > often as you'd like the stats and immediately see if you also need > to retrieve VmInfo or not (you rarely would). +1 To Ayal's suggestion except that instead of the engine hashing the data VDSM sends the key which is opaque to the engine. This can be a local timestap or a generation number. But, we might want to consider that when we add events polling becomes (much) less frequent so maybe it'll be an overkill. > > > > > ----- Original Message ----- > > > From: "Vinzenz Feenstra" > > > To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org > > > Sent: Thursday, March 7, 2013 6:25:54 AM > > > Subject: [Engine-devel] Proposal VDSM <=> Engine Data Statistics > > > Retrieval Optimization > > > > > > > > > Please find the prettier version on the wiki: > > > http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > > > > > > Proposal VDSM - Engine Data Statistics Retrieval > > > VDSM <=> Engine data retrieval optimization > > > Motivation: > > > > > > > > > Currently the RHEVM engine is polling the a lot of data from VDSM > > > every 15 seconds. This should be optimized and the amount of data > > > requested should be more specific. > > > > > > For each VM the data currently contains much more information > > > than > > > actually needed which blows up the size of the XML content quite > > > big. We could optimize this by splitting the reply on the > > > getVmStats > > > based on the request of the engine into sections. For this reason > > > Omer Frenkel and me have split up the data into parts based on > > > their > > > usage. > > > > > > This data can and usually does change during the lifetime of the > > > VM. > > > Rarely Changed: > > > > > > > > > This data is change not very frequent and it should be enough to > > > update this only once in a while. Most commonly this data changes > > > after changes made in the UI or after a migration of the VM to > > > another Host. Status = Running acpiEnable = true vmType = kvm > > > guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 > > > kvmEnable = true # this should be constant and never changed > > > pauseCode = NOERR monitorResponse = 0 session = Locked # unused > > > netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', > > > 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': > > > ['10.34.60.148'], > > > 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', > > > 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 > > > 3.2.2', > > > 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 > > > 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB > > > 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = 11314 > > > guestIPs = 10.34.60.148 # duplicated info displayIp = 0 > > > displayPort > > > = 5902 displaySecurePort = 5903 username = user at W864GUESTAGENTT > > > clientIp = lastLogin = 1361976900.67 Often Changed: > > > > > > > > > This data is changed quite often however it is not necessary to > > > update this data every 15 seconds. As this is cumulative data and > > > reflects the current status, and it does not need to be > > > snapshotted > > > every 15 seconds to retrieve statistics. The data can be > > > retrieved > > > in much more generous time slices. (e.g. Every 5 minutes) network > > > = > > > {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', > > > 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': > > > '0.0', > > > 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': > > > 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': '64055406592', > > > 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': > > > '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset = > > > 14422 > > > elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09 # > > > unused Often Changed but unused > > > > > > > > > This data does not seem to be used in the engine at all. It is > > > not > > > even used in the data warehouse. memoryStats = {'swap_out': '0', > > > 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', 'pageflt': > > > '0', 'mem_total': '2096736', 'mem_unused': '1466884'} balloonInfo > > > = > > > {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = {'vda': > > > {'readLatency': '0', 'apparentsize': '64424509440', > > > 'writeLatency': > > > '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', > > > 'flushLatency': '156549', 'readRate': '0.00', 'truesize': > > > '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': > > > '0', > > > 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', > > > 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very > > > frequent uppdates needed by webadmin portal: > > > > > > > > > This data is mostly needed for the webadmin portal and might be > > > required to be updated quite often. An exception here is the > > > statsAge field, which seems to be unused by the Engine. This data > > > could be requested every 15 seconds to keep things as they are > > > now. > > > cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution for > > > VDSM & Engine: > > > > > > > > > We will introduce new optional parameters to getVmStats, > > > getAllVmStats and list to allow a finer grained specification of > > > data which should be included. > > > > > > Parameter: statsType = (getVmStats, getAllVmStats only) > > > Allowed values: > > > > > > * full (default to keep backwards compatibility) > > > * app-list (Just send the application list) > > > * rare (include everything from rarely changed to very > > > frequent) > > > * often (include everything from often changed to very > > > frequent) > > > * frequent (only send the very frequently changed items) > > > > > > > > > > > > Parameter: clientId = The client id is specified by the > > > client and should be unique however constantly used. > > > > > > Parameter: diff = In combination with the clientId VDSM > > > will send only differences to the previous request from the named > > > clientId. (if diff=true) > > > > > > > > > Additional Change: > > > > > > > > > Besides the introduction of the new parameters for list, > > > getVmStats > > > and getAllVmStats it might make sense to include a hash for the > > > appList into the rarely changed section of the response which > > > would > > > allow to identify changes and avoid having to sent the complete > > > appList every so often and only if the hash known to the client > > > is > > > outdated. > > > > > > Note: The appList (Application List) reported by the guest agent > > > could be fully implemented on request only, as long as the guest > > > agent installed supports this. As there seems to be a request to > > > have the complete list of installed applications on all guests > > > this > > > data could be quite extensive and a huge list. On the other hand > > > this data is only rarely visible and therefore it should not be > > > requested all the time and only on demand. Improvement of the > > > Guest > > > Agent: > > > > > > > > > As part of the proposed solution it is necessary to improve the > > > guest > > > agent as well. For the full application list there should be > > > implemented a caching system which will be fully reactive and > > > should > > > not poll the application list for example all the time. The guest > > > can create a prepared data file containing all data in the JSON > > > format (as used for the communication with VDSM via VIO) and just > > > have to read that file from disk and directly sends it to VDSM. > > > However it is quite possible that this list is to big and it > > > might > > > have to be chunked into pieces. (Multiple messages, which would > > > have > > > to be supported by VDSM then as well) The solution for this is to > > > make VDSM request this data and it will retrieve the data > > > necessary > > > on request only. -- > > > Regards, > > > > > > Vinzenz Feenstra | Senior Software Engineer > > > RedHat Engineering Virtualization R & D > > > Phone: +420 532 294 625 > > > IRC: vfeenstr or evilissimo > > > > > > Better technology. Faster innovation. Powered by community > > > collaboration. > > > See how it works at redhat.com > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > _______________________________________________ > > vdsm-devel mailing list > > vdsm-devel at lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > From abaron at redhat.com Wed Mar 13 21:55:22 2013 From: abaron at redhat.com (Ayal Baron) Date: Wed, 13 Mar 2013 17:55:22 -0400 (EDT) Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <1824380735.14562758.1363211449756.JavaMail.root@redhat.com> Message-ID: <25893083.7640290.1363211722007.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Ayal Baron" > > To: "Saggi Mizrahi" > > Cc: engine-devel at ovirt.org, vdsm-devel at lists.fedorahosted.org, > > "Vinzenz Feenstra" > > Sent: Wednesday, March 13, 2013 5:39:24 PM > > Subject: Re: [vdsm] [Engine-devel] Proposal VDSM <=> Engine Data > > Statistics Retrieval Optimization > > > > > > > > ----- Original Message ----- > > > I am completely against this. > > > It make the return value differ according to input which > > > is a big no no when talking about type safe APIs. > > > > > > The only reason we have this problem is because there is this > > > thing against making multiple calls. > > > > > > Just split it up. > > > getVmRuntimeStats() - transient things like mem and cpu% > > > getVmInformation() - (semi)static things like disk\networking > > > layout > > > etc. > > > Each updated at different intervals. > > > > +1 on splitting the data up into 2 separate API calls. > > You could potentially add a checksum (md5, or any other way) of the > > "static" data to getVmRuntimeStats and not bother even with polling > > the VmInformation if this hasn't changed. Then you could poll as > > often as you'd like the stats and immediately see if you also need > > to retrieve VmInfo or not (you rarely would). > +1 To Ayal's suggestion > except that instead of the engine hashing the data VDSM sends the > key which is opaque to the engine. > This can be a local timestap or a generation number. Of course vdsm does the hash, otherwise you'd need to pass all the data to engine which would beat the purpose. > > But, we might want to consider that when we add events polling > becomes (much) less frequent so maybe it'll be an overkill. You'd still need to compare versions of the data in vdsm and send only if it changed. If you don't persist what was received last then potentially you could have a monday morning effect where upon on system startup you'd be sending everything. So I still think you'd want to have the hash. > > > > > > > > > ----- Original Message ----- > > > > From: "Vinzenz Feenstra" > > > > To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org > > > > Sent: Thursday, March 7, 2013 6:25:54 AM > > > > Subject: [Engine-devel] Proposal VDSM <=> Engine Data > > > > Statistics > > > > Retrieval Optimization > > > > > > > > > > > > Please find the prettier version on the wiki: > > > > http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > > > > > > > > Proposal VDSM - Engine Data Statistics Retrieval > > > > VDSM <=> Engine data retrieval optimization > > > > Motivation: > > > > > > > > > > > > Currently the RHEVM engine is polling the a lot of data from > > > > VDSM > > > > every 15 seconds. This should be optimized and the amount of > > > > data > > > > requested should be more specific. > > > > > > > > For each VM the data currently contains much more information > > > > than > > > > actually needed which blows up the size of the XML content > > > > quite > > > > big. We could optimize this by splitting the reply on the > > > > getVmStats > > > > based on the request of the engine into sections. For this > > > > reason > > > > Omer Frenkel and me have split up the data into parts based on > > > > their > > > > usage. > > > > > > > > This data can and usually does change during the lifetime of > > > > the > > > > VM. > > > > Rarely Changed: > > > > > > > > > > > > This data is change not very frequent and it should be enough > > > > to > > > > update this only once in a while. Most commonly this data > > > > changes > > > > after changes made in the UI or after a migration of the VM to > > > > another Host. Status = Running acpiEnable = true vmType = kvm > > > > guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 > > > > kvmEnable = true # this should be constant and never changed > > > > pauseCode = NOERR monitorResponse = 0 session = Locked # unused > > > > netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', > > > > 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': > > > > ['10.34.60.148'], > > > > 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', > > > > 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 > > > > 3.2.2', > > > > 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 > > > > 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB > > > > 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = > > > > 11314 > > > > guestIPs = 10.34.60.148 # duplicated info displayIp = 0 > > > > displayPort > > > > = 5902 displaySecurePort = 5903 username = user at W864GUESTAGENTT > > > > clientIp = lastLogin = 1361976900.67 Often Changed: > > > > > > > > > > > > This data is changed quite often however it is not necessary to > > > > update this data every 15 seconds. As this is cumulative data > > > > and > > > > reflects the current status, and it does not need to be > > > > snapshotted > > > > every 15 seconds to retrieve statistics. The data can be > > > > retrieved > > > > in much more generous time slices. (e.g. Every 5 minutes) > > > > network > > > > = > > > > {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', > > > > 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': > > > > '0.0', > > > > 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': > > > > 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': > > > > '64055406592', > > > > 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': > > > > '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset = > > > > 14422 > > > > elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09 > > > > # > > > > unused Often Changed but unused > > > > > > > > > > > > This data does not seem to be used in the engine at all. It is > > > > not > > > > even used in the data warehouse. memoryStats = {'swap_out': > > > > '0', > > > > 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', > > > > 'pageflt': > > > > '0', 'mem_total': '2096736', 'mem_unused': '1466884'} > > > > balloonInfo > > > > = > > > > {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = > > > > {'vda': > > > > {'readLatency': '0', 'apparentsize': '64424509440', > > > > 'writeLatency': > > > > '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', > > > > 'flushLatency': '156549', 'readRate': '0.00', 'truesize': > > > > '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': > > > > '0', > > > > 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', > > > > 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very > > > > frequent uppdates needed by webadmin portal: > > > > > > > > > > > > This data is mostly needed for the webadmin portal and might be > > > > required to be updated quite often. An exception here is the > > > > statsAge field, which seems to be unused by the Engine. This > > > > data > > > > could be requested every 15 seconds to keep things as they are > > > > now. > > > > cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution > > > > for > > > > VDSM & Engine: > > > > > > > > > > > > We will introduce new optional parameters to getVmStats, > > > > getAllVmStats and list to allow a finer grained specification > > > > of > > > > data which should be included. > > > > > > > > Parameter: statsType = (getVmStats, getAllVmStats > > > > only) > > > > Allowed values: > > > > > > > > * full (default to keep backwards compatibility) > > > > * app-list (Just send the application list) > > > > * rare (include everything from rarely changed to very > > > > frequent) > > > > * often (include everything from often changed to very > > > > frequent) > > > > * frequent (only send the very frequently changed items) > > > > > > > > > > > > > > > > Parameter: clientId = The client id is specified by > > > > the > > > > client and should be unique however constantly used. > > > > > > > > Parameter: diff = In combination with the clientId > > > > VDSM > > > > will send only differences to the previous request from the > > > > named > > > > clientId. (if diff=true) > > > > > > > > > > > > Additional Change: > > > > > > > > > > > > Besides the introduction of the new parameters for list, > > > > getVmStats > > > > and getAllVmStats it might make sense to include a hash for the > > > > appList into the rarely changed section of the response which > > > > would > > > > allow to identify changes and avoid having to sent the complete > > > > appList every so often and only if the hash known to the client > > > > is > > > > outdated. > > > > > > > > Note: The appList (Application List) reported by the guest > > > > agent > > > > could be fully implemented on request only, as long as the > > > > guest > > > > agent installed supports this. As there seems to be a request > > > > to > > > > have the complete list of installed applications on all guests > > > > this > > > > data could be quite extensive and a huge list. On the other > > > > hand > > > > this data is only rarely visible and therefore it should not be > > > > requested all the time and only on demand. Improvement of the > > > > Guest > > > > Agent: > > > > > > > > > > > > As part of the proposed solution it is necessary to improve the > > > > guest > > > > agent as well. For the full application list there should be > > > > implemented a caching system which will be fully reactive and > > > > should > > > > not poll the application list for example all the time. The > > > > guest > > > > can create a prepared data file containing all data in the JSON > > > > format (as used for the communication with VDSM via VIO) and > > > > just > > > > have to read that file from disk and directly sends it to VDSM. > > > > However it is quite possible that this list is to big and it > > > > might > > > > have to be chunked into pieces. (Multiple messages, which would > > > > have > > > > to be supported by VDSM then as well) The solution for this is > > > > to > > > > make VDSM request this data and it will retrieve the data > > > > necessary > > > > on request only. -- > > > > Regards, > > > > > > > > Vinzenz Feenstra | Senior Software Engineer > > > > RedHat Engineering Virtualization R & D > > > > Phone: +420 532 294 625 > > > > IRC: vfeenstr or evilissimo > > > > > > > > Better technology. Faster innovation. Powered by community > > > > collaboration. > > > > See how it works at redhat.com > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > _______________________________________________ > > > vdsm-devel mailing list > > > vdsm-devel at lists.fedorahosted.org > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > From sabose at redhat.com Thu Mar 14 05:53:15 2013 From: sabose at redhat.com (Sahina Bose) Date: Thu, 14 Mar 2013 11:23:15 +0530 Subject: [Engine-devel] Async Task Manager improvements In-Reply-To: <1031458467.4691292.1362996502278.JavaMail.root@redhat.com> References: <1031458467.4691292.1362996502278.JavaMail.root@redhat.com> Message-ID: <514165CB.9090000@redhat.com> Hi Yair, Thanks for the detailed design. Had some questions 1. Can we think about introducing some DI framework in the Task Management package. This could be used to inject the DAL, VDS Broker, Commons etc dependencies. Even the list of providers and TaskStatusEvent handlers could be registered using this framework. 2. You mention "Several providers that refer to instances of the same external system type have the same ProviderLogic object. " I'm not sure I understand this. Could you clarify? 3. Will TaskManager also talk to Job entity and update/end Job if necessary? 4. Are we planning to support custom actions on tasks? That is, depending on status of task, task can be paused/ resumed/ aborted /custom action performed etc thanks sahina On 03/11/2013 03:38 PM, Yair Zaslavsky wrote: > Hi all, > > I would like to present you a document I'm working on (still in draft/working-in-progress mode) of changes to be done at the engine async task manager. > > Regarding the detailed design - > > The suggested design breaks the task management into two modules - task management/polling part + command management (in context of completion of tasks/commands). > The current status of the design is that the design of task management is provided (needs some polishing) - the command management design will be provided soon. > > In addition, we already have some ideas for an alternative design for the task management part (as suggested by Saggi Mizrahi). > After converging , we will present the complete design. > The reason we're sending the Wiki now is that community members will be aware mainly to the motivations behind the changes > > (Perhaps we should create separate documents for the design and for the motivation/requirements) > > http://www.ovirt.org/Wiki/AsyncTaskManagerChanges > > > Yair > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From yzaslavs at redhat.com Thu Mar 14 06:01:35 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 14 Mar 2013 02:01:35 -0400 (EDT) Subject: [Engine-devel] Async Task Manager improvements In-Reply-To: <514165CB.9090000@redhat.com> Message-ID: <855488892.7239862.1363240895215.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Sahina Bose" > To: engine-devel at ovirt.org > Sent: Thursday, March 14, 2013 7:53:15 AM > Subject: Re: [Engine-devel] Async Task Manager improvements > > Hi Yair, > > Thanks for the detailed design. Hi Sahina, we're going to change the detailed design, to be more flexible and loose coupled. > Had some questions > > 1. Can we think about introducing some DI framework in the Task > Management package. This could be used to inject the DAL, VDS Broker, > Commons etc dependencies. Even the list of providers and > TaskStatusEvent > handlers could be registered using this framework. I think that at this point it's too early to talk about DI at the new task mgmt framework, but that's a possibility. We're aiming to a more general framework for scheduling operations + providing a mechanism to signal objects when the operations are ended. > > 2. You mention "Several providers that refer to instances of the same > external system type have the same ProviderLogic object. " I'm not > sure > I understand this. Could you clarify? This is still a draft and may change. I wanted to distinguish for example between an instance of SPM or gluster host and the logic to handle their task-related issues - so, you may have several instances of "task provider", but you have one logic per task provider type. > > 3. Will TaskManager also talk to Job entity and update/end Job if > necessary? Yes, this was not addressed at this point. > > 4. Are we planning to support custom actions on tasks? That is, > depending on status of task, task can be paused/ resumed/ aborted > /custom action performed etc Yes, the next phase of the design we're working on will be more flexible, and you will be able to have more flexibility. > > thanks > sahina > > > > On 03/11/2013 03:38 PM, Yair Zaslavsky wrote: > > Hi all, > > > > I would like to present you a document I'm working on (still in > > draft/working-in-progress mode) of changes to be done at the > > engine async task manager. > > > > Regarding the detailed design - > > > > The suggested design breaks the task management into two modules - > > task management/polling part + command management (in context of > > completion of tasks/commands). > > The current status of the design is that the design of task > > management is provided (needs some polishing) - the command > > management design will be provided soon. > > > > In addition, we already have some ideas for an alternative design > > for the task management part (as suggested by Saggi Mizrahi). > > After converging , we will present the complete design. > > The reason we're sending the Wiki now is that community members > > will be aware mainly to the motivations behind the changes > > > > (Perhaps we should create separate documents for the design and for > > the motivation/requirements) > > > > http://www.ovirt.org/Wiki/AsyncTaskManagerChanges > > > > > > Yair > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From eedri at redhat.com Thu Mar 14 08:20:33 2013 From: eedri at redhat.com (Eyal Edri) Date: Thu, 14 Mar 2013 04:20:33 -0400 (EDT) Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3737 - Still Unstable! In-Reply-To: <803978046.1529.1363213931141.JavaMail.jenkins@jenkins.ovirt.org> Message-ID: <1131399568.18390822.1363249233435.JavaMail.root@redhat.com> Latest commit introduced new NORMAL findbugs, please fix. eyal. infra team. ----- Original Message ----- > From: "Jenkins ci oVirt Server" > To: eedri at redhat.com, engine-patches at ovirt.org, oliel at redhat.com, yzaslavs at redhat.com, dcaro at redhat.com, > gerrit2 at gerrit.ovirt.org > Sent: Thursday, March 14, 2013 12:32:10 AM > Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 3737 - Still Unstable! > > Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/ > Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/3737/ > Build Number: 3737 > Build Status: Still Unstable > Triggered By: Started by an SCM change > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #3733 > [Michael Kublin] engine: Making all internal actions to have same > correlationId > > > Changes for Build #3734 > [Gerrit Code Review] webadmin: Attach disk - verify valid selection > > [Gerrit Code Review] webadmin: Make Template dialog - style > modifications > > [Gerrit Code Review] webadmin: About dialog - remove redundant code > > > Changes for Build #3735 > [Allon Mureinik] core: AuditLogableBaseTest synthetic access > > [Allon Mureinik] core: TestAuditLoggableBase serial warning > > > Changes for Build #3736 > [Kiril Nesenko] webadmin: Change default doc path. > > > Changes for Build #3737 > [Gerrit Code Review] db: do not write to dbscripts after installation > > > > > ----------------- > Failed Tests: > ----------------- > No tests ran. > > From alourie at redhat.com Thu Mar 14 10:13:39 2013 From: alourie at redhat.com (Alex Lourie) Date: Thu, 14 Mar 2013 06:13:39 -0400 (EDT) Subject: [Engine-devel] Migrating engine-setup to otopi In-Reply-To: <51417FD1.1010209@redhat.com> Message-ID: <1312946802.45687257.1363256019367.JavaMail.root@redhat.com> Hi All Recent development of the otopi [1] framework allows us to migrate the engine-setup, upgrade and cleanup (and potentially other) utilities to implementation as an otopi plugin. Potential benefits of such a move are: 1. Be able to port engine to other distributions. 2. Be able to install engine in a development mode. 3. Be able to customize installation easily. 4. Share installation of components (reports, dwh). 5. Modular implementation, reduce maintenance costs. 6. Code reuse of installer code for multiple purposes (host-deploy, enigne-setup). Currently we are in the process of creating a 'setup' plugin for the otopi, and the progress can be monitored at [2]. The current roadmap for the feature is as follows: 1. Recreate the configuration utilities as plugins in otopi. 2. Support side-by side installation using both the old and the new utilities. 3. Switch to the new utility when the confidence that it is on-par with an old one is high. Our goal is to have the new utilities ready for 3.3 release (at least for the step 2 in the roadmap). We'd like to hear as much feedback as possible, so we could address it as soon as possible. Thanks! [1] http://gerrit.ovirt.org/#/q/project:otopi,n,z [2] http://www.ovirt.org/Features/Otopi_Infra_Migration From alonbl at redhat.com Thu Mar 14 10:40:03 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 14 Mar 2013 06:40:03 -0400 (EDT) Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <20130314113846.63464d80.jbelka@redhat.com> Message-ID: <2070641947.6743330.1363257603382.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Jiri Belka" > To: "Alex Lourie" > Cc: engine-devel at ovirt.org, users at ovirt.org > Sent: Thursday, March 14, 2013 12:38:46 PM > Subject: Re: [Users] Migrating engine-setup to otopi > > On Thu, 14 Mar 2013 06:13:39 -0400 (EDT) > Alex Lourie wrote: > > > Hi All > > > > Recent development of the otopi [1] framework allows us to migrate > > the engine-setup, > > upgrade and cleanup (and potentially other) utilities to > > implementation as an otopi > > plugin. > > > > Potential benefits of such a move are: > > > > 1. Be able to port engine to other distributions. > > Really? Beside this topic I see hardcoded usernames in scripts... This is going away soon. > > http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified > > Anyway, everything what is not RPM/YUM specific and more portable > is good way... > > jbelka > _______________________________________________ > Users mailing list > Users at ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > From alourie at redhat.com Thu Mar 14 11:06:04 2013 From: alourie at redhat.com (Alex Lourie) Date: Thu, 14 Mar 2013 07:06:04 -0400 (EDT) Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <20130314113846.63464d80.jbelka@redhat.com> Message-ID: <168103289.45698009.1363259164677.JavaMail.root@redhat.com> Hi Jiri ----- Original Message ----- > From: "Jiri Belka" > To: "Alex Lourie" > Cc: engine-devel at ovirt.org, users at ovirt.org > Sent: Thursday, March 14, 2013 12:38:46 PM > Subject: Re: [Users] Migrating engine-setup to otopi > > On Thu, 14 Mar 2013 06:13:39 -0400 (EDT) > Alex Lourie wrote: > > > Hi All > > > > Recent development of the otopi [1] framework allows us to migrate > > the engine-setup, > > upgrade and cleanup (and potentially other) utilities to > > implementation as an otopi > > plugin. > > > > Potential benefits of such a move are: > > > > 1. Be able to port engine to other distributions. > > Really? Beside this topic I see hardcoded usernames in scripts... > > http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified These usernames are not hard-coded. There are default values present which are kept for local installations, but with remote DB setup the user is prompted to provide a username of her/his own. > > Anyway, everything what is not RPM/YUM specific and more portable > is good way... > Thanks! > jbelka > -- Best regards, Alex Lourie Software Developer in Integration Red Hat From alonbl at redhat.com Thu Mar 14 11:52:31 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 14 Mar 2013 07:52:31 -0400 (EDT) Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <20130314124712.7add99a6.jbelka@redhat.com> Message-ID: <609241786.6750153.1363261951706.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Jiri Belka" > To: "Alex Lourie" > Cc: engine-devel at ovirt.org, users at ovirt.org > Sent: Thursday, March 14, 2013 1:47:12 PM > Subject: Re: [Users] Migrating engine-setup to otopi > > On Thu, 14 Mar 2013 07:06:04 -0400 (EDT) > Alex Lourie wrote: > > > > > 1. Be able to port engine to other distributions. > > > > > > Really? Beside this topic I see hardcoded usernames in scripts... > > > > > > http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified > > > > These usernames are not hard-coded. There are default values > > present which are kept for > > local installations, but with remote DB setup the user is prompted > > to provide a username > > of her/his own. > > Not everywhere are postgresql dirs owned by postgres, on some BSDs it > is > _postgresql. Right, as I said this is going away. I am porting this first to Gentoo, which is the most complex, then I will be able to provide debian based. For the postgres issue, I am against assuming local database and the configuration of the database it-self (hba, etc). Like in other products, the dba will create a user and a database with the user as an owner and provide us the user/password and database name, this method does not require privileged database user for product installation and working locally or remotely, and is portable. We will keep the functionality of system provisioning as an optional component exists in some distribution. Regards, Alon Bar-Lev From mpastern at redhat.com Thu Mar 14 12:04:21 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 14 Mar 2013 14:04:21 +0200 Subject: [Engine-devel] engine watchdog support - new version in gerrit In-Reply-To: <861528542.9318240.1363165985999.JavaMail.root@redhat.com> References: <861528542.9318240.1363165985999.JavaMail.root@redhat.com> Message-ID: <5141BCC5.1000206@redhat.com> Hi Laszlo, i did a review for the api part, please take a look. On 03/13/2013 11:13 AM, Laszlo Hornyak wrote: > hi, > > A new version of the engine watchdog support is available in gerrit. This version finished the rest-api support by adding the capabilities resources. The features listed in the feature page are ready, so if you have enough time and courage, please give it a try! > > I have left the patch with [wip] because I am waiting for the end of some discussions about the technical background. > > http://gerrit.ovirt.org/#/c/12419/ > > Thx, > Laszlo > _______________________________________________ > 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 ewoud+ovirt at kohlvanwijngaarden.nl Thu Mar 14 12:06:01 2013 From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Thu, 14 Mar 2013 13:06:01 +0100 Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <609241786.6750153.1363261951706.JavaMail.root@redhat.com> References: <20130314124712.7add99a6.jbelka@redhat.com> <609241786.6750153.1363261951706.JavaMail.root@redhat.com> Message-ID: <20130314120601.GQ28496@bogey.xentower.nl> On Thu, Mar 14, 2013 at 07:52:31AM -0400, Alon Bar-Lev wrote: > > > ----- Original Message ----- > > From: "Jiri Belka" > > To: "Alex Lourie" > > Cc: engine-devel at ovirt.org, users at ovirt.org > > Sent: Thursday, March 14, 2013 1:47:12 PM > > Subject: Re: [Users] Migrating engine-setup to otopi > > > > On Thu, 14 Mar 2013 07:06:04 -0400 (EDT) > > Alex Lourie wrote: > > > > > > > 1. Be able to port engine to other distributions. > > > > > > > > Really? Beside this topic I see hardcoded usernames in scripts... > > > > > > > > http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified > > > > > > These usernames are not hard-coded. There are default values > > > present which are kept for > > > local installations, but with remote DB setup the user is prompted > > > to provide a username > > > of her/his own. > > > > Not everywhere are postgresql dirs owned by postgres, on some BSDs it > > is > > _postgresql. > > Right, as I said this is going away. > > I am porting this first to Gentoo, which is the most complex, then I > will be able to provide debian based. Would it be useful to start to provide an ovirt-overlay for this? I already started https://github.com/ekohl/ovirt-overlay where I packaged ovirt-shell and its dependencies (including ovirt-sdk-python). I'd be happy to extend this with more packages based on the info available on http://wiki.gentoo.org/wiki/OVirt. From alonbl at redhat.com Thu Mar 14 12:08:52 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 14 Mar 2013 08:08:52 -0400 (EDT) Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <20130314120601.GQ28496@bogey.xentower.nl> Message-ID: <211496039.6752524.1363262932435.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ewoud Kohl van Wijngaarden" > To: "Alon Bar-Lev" > Cc: "Jiri Belka" , engine-devel at ovirt.org, users at ovirt.org > Sent: Thursday, March 14, 2013 2:06:01 PM > Subject: Re: [Engine-devel] [Users] Migrating engine-setup to otopi > > On Thu, Mar 14, 2013 at 07:52:31AM -0400, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > > > From: "Jiri Belka" > > > To: "Alex Lourie" > > > Cc: engine-devel at ovirt.org, users at ovirt.org > > > Sent: Thursday, March 14, 2013 1:47:12 PM > > > Subject: Re: [Users] Migrating engine-setup to otopi > > > > > > On Thu, 14 Mar 2013 07:06:04 -0400 (EDT) > > > Alex Lourie wrote: > > > > > > > > > 1. Be able to port engine to other distributions. > > > > > > > > > > Really? Beside this topic I see hardcoded usernames in > > > > > scripts... > > > > > > > > > > http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified > > > > > > > > These usernames are not hard-coded. There are default values > > > > present which are kept for > > > > local installations, but with remote DB setup the user is > > > > prompted > > > > to provide a username > > > > of her/his own. > > > > > > Not everywhere are postgresql dirs owned by postgres, on some > > > BSDs it > > > is > > > _postgresql. > > > > Right, as I said this is going away. > > > > I am porting this first to Gentoo, which is the most complex, then > > I > > will be able to provide debian based. > > Would it be useful to start to provide an ovirt-overlay for this? I > already started https://github.com/ekohl/ovirt-overlay where I > packaged > ovirt-shell and its dependencies (including ovirt-sdk-python). I'd be > happy to extend this with more packages based on the info available > on > http://wiki.gentoo.org/wiki/OVirt. > Working on this[1] for some time, until I realized we need to rewrite the whole packaging... I will update you when I have something working. The gentoo wiki instruction should simply go aware, as it is manual installation. [1] https://github.com/alonbl/ovirt-overlay From alourie at redhat.com Thu Mar 14 12:10:25 2013 From: alourie at redhat.com (Alex Lourie) Date: Thu, 14 Mar 2013 12:12:25 +0002 Subject: [Engine-devel] Features requests for the setup/configuration utilities - feedback requested Message-ID: <201303141210.r2ECAQhq005626@int-mx10.intmail.prod.int.phx2.redhat.com> Hi All As we are working on the configuration utilities (engine-setup, engine-upgrade and engine-cleanup), we would like to get as much community involvement as possible. As such, we'd like to hear the wishes of the community in regards with those tools. I've created a wiki page [1] where we will keep the list of feature requests. We would appreciate adding features to the list of by replying to this thread directly. Please do not bugs to that list - the bugs should be resolved in due course according to their priorities and should not affect the features that we would like to implement. Thank you. [1]?http://www.ovirt.org/Features/Engine-Config-Utilities -- Alex Lourie Software Engineer in RHEVM Integration Red Hat From alonbl at redhat.com Thu Mar 14 12:57:39 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 14 Mar 2013 08:57:39 -0400 (EDT) Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <20130314134644.17cf7058.jbelka@redhat.com> Message-ID: <1693962559.6761651.1363265859228.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Jiri Belka" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org, users at ovirt.org > Sent: Thursday, March 14, 2013 2:46:44 PM > Subject: Re: [Engine-devel] [Users] Migrating engine-setup to otopi > > On Thu, 14 Mar 2013 08:08:52 -0400 (EDT) > Alon Bar-Lev wrote: > > > > Working on this[1] for some time, until I realized we need to > > rewrite the whole packaging... > > > > I will update you when I have something working. > > The gentoo wiki instruction should simply go aware, as it is manual > > installation. > > > > [1] https://github.com/alonbl/ovirt-overlay > > Please remove absolute symlinks too, it's totally stupid. Some > packaging tools scream a lot about symlinks pointing outside of fake > root during packaging. > > I had to do stupid kung-fu for my WIP OpenBSD port[1] :D > Not sure I agree... switching to relative symlinks is not doing a great work either, especially if we take the location from 3rd party, such as systemd or cron. From alonbl at redhat.com Thu Mar 14 12:59:37 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 14 Mar 2013 08:59:37 -0400 (EDT) Subject: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested In-Reply-To: <20130314135231.7530f037.jbelka@redhat.com> Message-ID: <1042755037.6761920.1363265977255.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Jiri Belka" > To: "Alex Lourie" > Cc: engine-devel at ovirt.org, Users at ovirt.org > Sent: Thursday, March 14, 2013 2:52:31 PM > Subject: Re: [Users] Features requests for the setup/configuration utilities - feedback requested > > On Thu, 14 Mar 2013 12:12:25 +0002 > Alex Lourie wrote: > > > Hi All > > > > As we are working on the configuration utilities (engine-setup, > > engine-upgrade and engine-cleanup), we would like to get as much > > community involvement as possible. As such, we'd like to hear the > > wishes of the community in regards with those tools. > > 1. do not think yum is everywhere, make package upgrade extensible > by some subclasses (apt-get, pkg_add...) Right. > 2. usernames are not same everywhere > postgres is not everywhere Right. > 3. do not make absolute symlinks, some packaging tools scream I replied to this one, I don't fully agree, relative symlinks have their own issues, and hard to convert absolute to relative when 3rd party components are involved. > 4. do not use #!/bin/bash but #!/bin/sh, in 99,9% people are not > using > anything special from bash anyway This is out of scope, we will depend on bash for now... too much legacy. We can attend to that in future. I can promise that no new code will be written in bash. Thanks! > > jbelka > _______________________________________________ > Users mailing list > Users at ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > From alourie at redhat.com Thu Mar 14 13:09:54 2013 From: alourie at redhat.com (Alex Lourie) Date: Thu, 14 Mar 2013 13:11:54 +0002 Subject: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested In-Reply-To: <1042755037.6761920.1363265977255.JavaMail.root@redhat.com> References: <1042755037.6761920.1363265977255.JavaMail.root@redhat.com> Message-ID: <201303141309.r2ED9t5r015764@int-mx01.intmail.prod.int.phx2.redhat.com> > > ----- Original Message ----- >> From: "Jiri Belka" >> To: "Alex Lourie" >> Cc: engine-devel at ovirt.org, Users at ovirt.org >> Sent: Thursday, March 14, 2013 2:52:31 PM >> Subject: Re: [Users] Features requests for the setup/configuration >> utilities - feedback requested >> >> On Thu, 14 Mar 2013 12:12:25 +0002 >> Alex Lourie wrote: >> >> > Hi All >> > >> > As we are working on the configuration utilities (engine-setup, >> > engine-upgrade and engine-cleanup), we would like to get as much >> > community involvement as possible. As such, we'd like to hear the >> > wishes of the community in regards with those tools. >> >> 1. do not think yum is everywhere, make package upgrade extensible >> by some subclasses (apt-get, pkg_add...) >> > Right. > >> 2. usernames are not same everywhere >> postgres is not everywhere >> > Right. > >> 3. do not make absolute symlinks, some packaging tools scream >> > I replied to this one, I don't fully agree, relative symlinks have > their own issues, and hard to convert absolute to relative when 3rd > party components are involved. > >> 4. do not use #!/bin/bash but #!/bin/sh, in 99,9% people are not >> using >> anything special from bash anyway >> > This is out of scope, we will depend on bash for now... too much > legacy. > We can attend to that in future. > I can promise that no new code will be written in bash. > > Thanks! > >> >> jbelka >> _______________________________________________ >> Users mailing list >> Users at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> > Wiki updated. Thanks! From alourie at redhat.com Thu Mar 14 14:42:48 2013 From: alourie at redhat.com (Alex Lourie) Date: Thu, 14 Mar 2013 14:44:48 +0002 Subject: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested In-Reply-To: <20130314153026.63504074.jbelka@redhat.com> References: <201303141210.r2ECAQhq005626@int-mx10.intmail.prod.int.phx2.redhat.com> <20130314153026.63504074.jbelka@redhat.com> Message-ID: <201303141442.r2EEgo8p003511@int-mx01.intmail.prod.int.phx2.redhat.com> Hi Jiri On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka wrote: > I'll talk about RHEVM but it's probably related to oVirt too. > > As rhevm installs all deps, I'm curious why versionlock.list is > populated after rhevm-setup and _not_dirrectly during installation > (maybe because you would need to hardcode versions into rhevm > package?). It took me tens of minutes to figure out why is upgrade > working differently now, just because I did _NOT_ do rhevm-setup after > clean install because I was thinking I know what files are important > and was restoring them from a tarball. > > I think running rhevm-setup if you just want to restore is stupid. If > we would know 100% which files are involved, just install, restore > from > backup, restore DB should be sufficient, without loosing time with > rhevm-setup which just writes there and here... :) > I don't really follow you here. What are you restoring with rhevm-setup? > > jbelka > From eedri at redhat.com Thu Mar 14 19:43:11 2013 From: eedri at redhat.com (Eyal Edri) Date: Thu, 14 Mar 2013 15:43:11 -0400 (EDT) Subject: [Engine-devel] [EL6 RPMS] new nightly ovirt rpms In-Reply-To: <1314235116.19013868.1363290145754.JavaMail.root@redhat.com> Message-ID: <1696084005.19013999.1363290191664.JavaMail.root@redhat.com> fyi, EL6 rpms for various ovirt project are now available via the nightly repos: http://resources.ovirt.org/releases/nightly/rpm/EL/6/noarch/ Eyal. From jbelka at redhat.com Thu Mar 14 10:38:46 2013 From: jbelka at redhat.com (Jiri Belka) Date: Thu, 14 Mar 2013 11:38:46 +0100 Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <1312946802.45687257.1363256019367.JavaMail.root@redhat.com> References: <51417FD1.1010209@redhat.com> <1312946802.45687257.1363256019367.JavaMail.root@redhat.com> Message-ID: <20130314113846.63464d80.jbelka@redhat.com> On Thu, 14 Mar 2013 06:13:39 -0400 (EDT) Alex Lourie wrote: > Hi All > > Recent development of the otopi [1] framework allows us to migrate the engine-setup, > upgrade and cleanup (and potentially other) utilities to implementation as an otopi > plugin. > > Potential benefits of such a move are: > > 1. Be able to port engine to other distributions. Really? Beside this topic I see hardcoded usernames in scripts... http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified Anyway, everything what is not RPM/YUM specific and more portable is good way... jbelka From jbelka at redhat.com Thu Mar 14 11:47:12 2013 From: jbelka at redhat.com (Jiri Belka) Date: Thu, 14 Mar 2013 12:47:12 +0100 Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <168103289.45698009.1363259164677.JavaMail.root@redhat.com> References: <20130314113846.63464d80.jbelka@redhat.com> <168103289.45698009.1363259164677.JavaMail.root@redhat.com> Message-ID: <20130314124712.7add99a6.jbelka@redhat.com> On Thu, 14 Mar 2013 07:06:04 -0400 (EDT) Alex Lourie wrote: > > > 1. Be able to port engine to other distributions. > > > > Really? Beside this topic I see hardcoded usernames in scripts... > > > > http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified > > These usernames are not hard-coded. There are default values present which are kept for > local installations, but with remote DB setup the user is prompted to provide a username > of her/his own. Not everywhere are postgresql dirs owned by postgres, on some BSDs it is _postgresql. jbelka From jbelka at redhat.com Thu Mar 14 12:46:44 2013 From: jbelka at redhat.com (Jiri Belka) Date: Thu, 14 Mar 2013 13:46:44 +0100 Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <211496039.6752524.1363262932435.JavaMail.root@redhat.com> References: <20130314120601.GQ28496@bogey.xentower.nl> <211496039.6752524.1363262932435.JavaMail.root@redhat.com> Message-ID: <20130314134644.17cf7058.jbelka@redhat.com> On Thu, 14 Mar 2013 08:08:52 -0400 (EDT) Alon Bar-Lev wrote: > > Working on this[1] for some time, until I realized we need to rewrite the whole packaging... > > I will update you when I have something working. > The gentoo wiki instruction should simply go aware, as it is manual installation. > > [1] https://github.com/alonbl/ovirt-overlay Please remove absolute symlinks too, it's totally stupid. Some packaging tools scream a lot about symlinks pointing outside of fake root during packaging. I had to do stupid kung-fu for my WIP OpenBSD port[1] :D # make symlinks relative cd ${WRKDIST}/usr/local && \ for link in `find . -type l`; do \ dest=`stat -f %Y $${link}`; \ depth=`dirname $${link} | \ perl -p -e 's|^./||;s|[^/]+|..|g;'`; \ newdest=`echo $${dest} | \ perl -pe "s#/usr/local#$${depth}#;"`; \ ln -sf $${newdest} $${link}; \ done [1] https://github.com/jirib/openbsd-mystuff/blob/master/sysutils/ovirt/engine/Makefile From jbelka at redhat.com Thu Mar 14 12:52:31 2013 From: jbelka at redhat.com (Jiri Belka) Date: Thu, 14 Mar 2013 13:52:31 +0100 Subject: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested In-Reply-To: <201303141210.r2ECAQhq005626@int-mx10.intmail.prod.int.phx2.redhat.com> References: <201303141210.r2ECAQhq005626@int-mx10.intmail.prod.int.phx2.redhat.com> Message-ID: <20130314135231.7530f037.jbelka@redhat.com> On Thu, 14 Mar 2013 12:12:25 +0002 Alex Lourie wrote: > Hi All > > As we are working on the configuration utilities (engine-setup, > engine-upgrade and engine-cleanup), we would like to get as much > community involvement as possible. As such, we'd like to hear the > wishes of the community in regards with those tools. 1. do not think yum is everywhere, make package upgrade extensible by some subclasses (apt-get, pkg_add...) 2. usernames are not same everywhere postgres is not everywhere 3. do not make absolute symlinks, some packaging tools scream 4. do not use #!/bin/bash but #!/bin/sh, in 99,9% people are not using anything special from bash anyway jbelka From jbelka at redhat.com Thu Mar 14 14:30:26 2013 From: jbelka at redhat.com (Jiri Belka) Date: Thu, 14 Mar 2013 15:30:26 +0100 Subject: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested In-Reply-To: <201303141210.r2ECAQhq005626@int-mx10.intmail.prod.int.phx2.redhat.com> References: <201303141210.r2ECAQhq005626@int-mx10.intmail.prod.int.phx2.redhat.com> Message-ID: <20130314153026.63504074.jbelka@redhat.com> I'll talk about RHEVM but it's probably related to oVirt too. As rhevm installs all deps, I'm curious why versionlock.list is populated after rhevm-setup and _not_dirrectly during installation (maybe because you would need to hardcode versions into rhevm package?). It took me tens of minutes to figure out why is upgrade working differently now, just because I did _NOT_ do rhevm-setup after clean install because I was thinking I know what files are important and was restoring them from a tarball. I think running rhevm-setup if you just want to restore is stupid. If we would know 100% which files are involved, just install, restore from backup, restore DB should be sufficient, without loosing time with rhevm-setup which just writes there and here... :) jbelka From jbelka at redhat.com Thu Mar 14 14:55:16 2013 From: jbelka at redhat.com (Jiri Belka) Date: Thu, 14 Mar 2013 15:55:16 +0100 Subject: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested In-Reply-To: <201303141442.r2EEgo8p003511@int-mx01.intmail.prod.int.phx2.redhat.com> References: <201303141210.r2ECAQhq005626@int-mx10.intmail.prod.int.phx2.redhat.com> <20130314153026.63504074.jbelka@redhat.com> <201303141442.r2EEgo8p003511@int-mx01.intmail.prod.int.phx2.redhat.com> Message-ID: <20130314155516.0c70a3f1.jbelka@redhat.com> On Thu, 14 Mar 2013 14:44:48 +0002 Alex Lourie wrote: > Hi Jiri > > On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka wrote: > > I'll talk about RHEVM but it's probably related to oVirt too. > > > > As rhevm installs all deps, I'm curious why versionlock.list is > > populated after rhevm-setup and _not_dirrectly during installation > > (maybe because you would need to hardcode versions into rhevm > > package?). It took me tens of minutes to figure out why is upgrade > > working differently now, just because I did _NOT_ do rhevm-setup after > > clean install because I was thinking I know what files are important > > and was restoring them from a tarball. > > > > I think running rhevm-setup if you just want to restore is stupid. If > > we would know 100% which files are involved, just install, restore > > from > > backup, restore DB should be sufficient, without loosing time with > > rhevm-setup which just writes there and here... :) > > > > I don't really follow you here. What are you restoring with rhevm-setup? My previous (wrong) procedure to restore old version was: rhevm-cleanup, yum remove rhevm\*, rm -rf $dirs, yum install rhevm\*, tar xvzpf /backup.tgz, ./restore.sh for DB... which was not fully correct as I haven't known /etc/yum/plugin.d/versionlock.list is touched by rhevm-setup as well and thus yum was working very strange during next normal upgrade. From iheim at redhat.com Fri Mar 15 08:30:19 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 15 Mar 2013 10:30:19 +0200 Subject: [Engine-devel] DB Performance Monitoring In-Reply-To: <849230385.8462464.1361867410043.JavaMail.root@redhat.com> References: <849230385.8462464.1361867410043.JavaMail.root@redhat.com> Message-ID: <5142DC1B.5060408@redhat.com> On 02/26/2013 10:30 AM, Yair Zaslavsky wrote: >> The next step is, by my opinion, is start to use cache for not often >> >changed object, VdsGroup is classical example of >> >such object. > +1 - and another issue I wanted to take a look into - Please notice we have entities representing views. > I have a feeling we abuse VM (for example) too much - we use AuditLoggableBase to "cache" vm - but still - I bet that in some flows > we don't need the entire VM -> we might need only static (or dynamic part) of it. > We should take a look into this as well . Getting vm dynamic from db instead of vm means less joins. > Same applies for vds and storage_domains lets be careful with adding caches - I'm not sure lightweight queries to the db, which probably has this in its cache are a critical bottleneck, while adding caches adds potential for bugs, and will make it harder to scale out. From iheim at redhat.com Fri Mar 15 09:46:05 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 15 Mar 2013 11:46:05 +0200 Subject: [Engine-devel] Error during "Create new VM" [SOLVED] In-Reply-To: <5135EBD2.9090909@linux.vnet.ibm.com> References: <5135E211.6040303@linux.vnet.ibm.com> <5135E676.9000306@linux.vnet.ibm.com> <5135EBD2.9090909@linux.vnet.ibm.com> Message-ID: <5142EDDD.7000400@redhat.com> On 03/05/2013 02:57 PM, Deepak C Shetty wrote: > On 03/05/2013 06:05 PM, Deepak C Shetty wrote: >> On 03/05/2013 05:46 PM, Deepak C Shetty wrote: >>> Hi, >>> I get the following error in the engine web gui while trying to >>> create a new VM (server or desktop) >>> >>> Error: >>> >>> gvm: >>> >>> Cannot add VM if custom VM properties are in invalid format. >>> Please check the input. >>> >>> >>> Whats custom property is it talking about ? >>> Under 'Custom Property' in new VM Dialog.. it has nothing.. it says >>> "no properties" >>> >>> I am on a git based engine setup.... trying to validate gluster >>> storage domain, but unable to proceed from this step. >>> >>> Any workarounds/inputs appreciate >> >> I see the foll. WARN msgs in my engine log (standalone.sh console) >> >> 2013-03-05 18:02:57,584 INFO >> [org.ovirt.engine.core.bll.AddVmFromScratchCommand] >> (http--0.0.0.0-8700-4) [1ec0c6a5] Lock Acquired to object EngineLock >> [exclusiveLocks= key: adsa value: VM_NAME >> , sharedLocks= ] >> 2013-03-05 18:02:57,589 WARN >> [org.ovirt.engine.core.bll.AddVmFromScratchCommand] >> (http--0.0.0.0-8700-4) [1ec0c6a5] CanDoAction of action >> AddVmFromScratch failed. >> Reasons:VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_FAILED_INVALID_CUSTOM_VM_PROPERTIES_INVALID_SYNTAX >> >> 2013-03-05 18:02:57,592 INFO >> [org.ovirt.engine.core.bll.AddVmFromScratchCommand] >> (http--0.0.0.0-8700-4) [1ec0c6a5] Lock freed to object EngineLock >> [exclusiveLocks= key: adsa value: VM_NAME >> , sharedLocks= ] >> 2013-03-05 18:02:59,561 INFO >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] >> (DefaultQuartzScheduler_Worker-4) No string for UNASSIGNED type. Use >> default Log >> 2013-03-05 18:03:04,229 INFO >> [org.ovirt.engine.core.bll.AddVmFromScratchCommand] >> (http--0.0.0.0-8700-4) [479a4c15] Lock Acquired to object EngineLock >> [exclusiveLocks= key: adsa value: VM_NAME >> , sharedLocks= ] >> 2013-03-05 18:03:04,239 WARN >> [org.ovirt.engine.core.bll.AddVmFromScratchCommand] >> (http--0.0.0.0-8700-4) [479a4c15] CanDoAction of action >> AddVmFromScratch failed. >> Reasons:VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_FAILED_INVALID_CUSTOM_VM_PROPERTIES_INVALID_SYNTAX >> >> 2013-03-05 18:03:04,241 INFO >> [org.ovirt.engine.core.bll.AddVmFromScratchCommand] >> (http--0.0.0.0-8700-4) [479a4c15] Lock freed to object EngineLock >> [exclusiveLocks= key: adsa value: VM_NAME >> , sharedLocks= ] >> >> > > Looks like some UI bug... > > i clicked on '+' then the custom property combo chnaged to "Pls select > key" from "no keys available", then create VM works ! > can you reproduce this? open a bug to get it fixed? Thanks, Itamar From iheim at redhat.com Fri Mar 15 10:19:53 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 15 Mar 2013 12:19:53 +0200 Subject: [Engine-devel] Best place for new interfaces used by bll In-Reply-To: <51377566.6070604@redhat.com> References: <51377566.6070604@redhat.com> Message-ID: <5142F5C9.60804@redhat.com> On 03/06/2013 06:57 PM, Ravi Nori wrote: > Hi, > > I am working on refactoring some of the backend code in bll and need to > create interfaces so that I can eliminate the dependency between bll and > the new module. > > Currently I created the interfaces in > org.ovirt.engine.core.common.interfaces, but from what I understand this > module is used by both frontend and backend. The new interfaces will > only be used by the backend. What would be the best place to put these > new interfaces? > 1. i agree with alissa and alon on the larger refactoring. 2. not all of common today is used by gwt, specifically, interfaces are shared/common, but backendinterfaces are limited to backend. since we are trying to refactor the frontend to not use common at all by moving to the restapi, I'm not sure i'd bother we'd splitting common "more" by shared/not-shared with frontend. but i would focus on making things in their own packages. i.e., I'd like to see ovirt-engine for gluster-only having to deploy/build/pull only what's relevant for them, not the 'virt' stuff for example. (easier for bll. a bit more work for db/common) Thanks, Itamar From iheim at redhat.com Fri Mar 15 11:00:03 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 15 Mar 2013 13:00:03 +0200 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <20130307221120.GE14400@redhat.com> References: <51387942.606@redhat.com> <20130307221120.GE14400@redhat.com> Message-ID: <5142FF33.9010803@redhat.com> On 03/08/2013 12:11 AM, Dan Kenigsberg wrote: >> This data is change not very frequent and it should be enough to >> >update this only once in a while. Most commonly this data changes >> >after changes made in the UI or after a migration of the VM to >> >another Host. >> > >> > *Status* = Running > Status does not change much, but when it does, it is important to report > that quickly. > actually, status and one other field are polled every 3 seconds iirc regardless of getAllVmStats (list table or something like that) From iheim at redhat.com Fri Mar 15 11:04:18 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 15 Mar 2013 13:04:18 +0200 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <25893083.7640290.1363211722007.JavaMail.root@redhat.com> References: <25893083.7640290.1363211722007.JavaMail.root@redhat.com> Message-ID: <51430032.7070302@redhat.com> On 03/13/2013 11:55 PM, Ayal Baron wrote: ... >>>> The only reason we have this problem is because there is this >>>> thing against making multiple calls. >>>> >>>> Just split it up. >>>> getVmRuntimeStats() - transient things like mem and cpu% >>>> getVmInformation() - (semi)static things like disk\networking >>>> layout >>>> etc. >>>> Each updated at different intervals. >>> >>> +1 on splitting the data up into 2 separate API calls. >>> You could potentially add a checksum (md5, or any other way) of the >>> "static" data to getVmRuntimeStats and not bother even with polling >>> the VmInformation if this hasn't changed. Then you could poll as >>> often as you'd like the stats and immediately see if you also need >>> to retrieve VmInfo or not (you rarely would). >> +1 To Ayal's suggestion >> except that instead of the engine hashing the data VDSM sends the >> key which is opaque to the engine. >> This can be a local timestap or a generation number. > > Of course vdsm does the hash, otherwise you'd need to pass all the data to engine which would beat the purpose. I thought you meant engine will be sending the hash of previous requests per VM to vdsm, then vdsm will reply back with vm's removed, vm's added, and the details for vm's that changed (i.e., engine would be doing something like if-modified-since-checksum per vm). benefit is reducing a round trip. but first would need to split to calls of stats (always changing) and slowly/never changing data. > >> >> But, we might want to consider that when we add events polling >> becomes (much) less frequent so maybe it'll be an overkill. > > You'd still need to compare versions of the data in vdsm and send only if it changed. If you don't persist what was received last then potentially you could have a monday morning effect where upon on system startup you'd be sending everything. So I still think you'd want to have the hash. > > >> >>> >>>> >>>> ----- Original Message ----- >>>>> From: "Vinzenz Feenstra" >>>>> To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org >>>>> Sent: Thursday, March 7, 2013 6:25:54 AM >>>>> Subject: [Engine-devel] Proposal VDSM <=> Engine Data >>>>> Statistics >>>>> Retrieval Optimization >>>>> >>>>> >>>>> Please find the prettier version on the wiki: >>>>> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval >>>>> >>>>> Proposal VDSM - Engine Data Statistics Retrieval >>>>> VDSM <=> Engine data retrieval optimization >>>>> Motivation: >>>>> >>>>> >>>>> Currently the RHEVM engine is polling the a lot of data from >>>>> VDSM >>>>> every 15 seconds. This should be optimized and the amount of >>>>> data >>>>> requested should be more specific. >>>>> >>>>> For each VM the data currently contains much more information >>>>> than >>>>> actually needed which blows up the size of the XML content >>>>> quite >>>>> big. We could optimize this by splitting the reply on the >>>>> getVmStats >>>>> based on the request of the engine into sections. For this >>>>> reason >>>>> Omer Frenkel and me have split up the data into parts based on >>>>> their >>>>> usage. >>>>> >>>>> This data can and usually does change during the lifetime of >>>>> the >>>>> VM. >>>>> Rarely Changed: >>>>> >>>>> >>>>> This data is change not very frequent and it should be enough >>>>> to >>>>> update this only once in a while. Most commonly this data >>>>> changes >>>>> after changes made in the UI or after a migration of the VM to >>>>> another Host. Status = Running acpiEnable = true vmType = kvm >>>>> guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 >>>>> kvmEnable = true # this should be constant and never changed >>>>> pauseCode = NOERR monitorResponse = 0 session = Locked # unused >>>>> netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', >>>>> 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': >>>>> ['10.34.60.148'], >>>>> 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', >>>>> 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 >>>>> 3.2.2', >>>>> 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 >>>>> 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB >>>>> 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = >>>>> 11314 >>>>> guestIPs = 10.34.60.148 # duplicated info displayIp = 0 >>>>> displayPort >>>>> = 5902 displaySecurePort = 5903 username = user at W864GUESTAGENTT >>>>> clientIp = lastLogin = 1361976900.67 Often Changed: >>>>> >>>>> >>>>> This data is changed quite often however it is not necessary to >>>>> update this data every 15 seconds. As this is cumulative data >>>>> and >>>>> reflects the current status, and it does not need to be >>>>> snapshotted >>>>> every 15 seconds to retrieve statistics. The data can be >>>>> retrieved >>>>> in much more generous time slices. (e.g. Every 5 minutes) >>>>> network >>>>> = >>>>> {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', >>>>> 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': >>>>> '0.0', >>>>> 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': >>>>> 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': >>>>> '64055406592', >>>>> 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': >>>>> '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset = >>>>> 14422 >>>>> elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09 >>>>> # >>>>> unused Often Changed but unused >>>>> >>>>> >>>>> This data does not seem to be used in the engine at all. It is >>>>> not >>>>> even used in the data warehouse. memoryStats = {'swap_out': >>>>> '0', >>>>> 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', >>>>> 'pageflt': >>>>> '0', 'mem_total': '2096736', 'mem_unused': '1466884'} >>>>> balloonInfo >>>>> = >>>>> {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = >>>>> {'vda': >>>>> {'readLatency': '0', 'apparentsize': '64424509440', >>>>> 'writeLatency': >>>>> '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', >>>>> 'flushLatency': '156549', 'readRate': '0.00', 'truesize': >>>>> '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': >>>>> '0', >>>>> 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', >>>>> 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very >>>>> frequent uppdates needed by webadmin portal: >>>>> >>>>> >>>>> This data is mostly needed for the webadmin portal and might be >>>>> required to be updated quite often. An exception here is the >>>>> statsAge field, which seems to be unused by the Engine. This >>>>> data >>>>> could be requested every 15 seconds to keep things as they are >>>>> now. >>>>> cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution >>>>> for >>>>> VDSM & Engine: >>>>> >>>>> >>>>> We will introduce new optional parameters to getVmStats, >>>>> getAllVmStats and list to allow a finer grained specification >>>>> of >>>>> data which should be included. >>>>> >>>>> Parameter: statsType = (getVmStats, getAllVmStats >>>>> only) >>>>> Allowed values: >>>>> >>>>> * full (default to keep backwards compatibility) >>>>> * app-list (Just send the application list) >>>>> * rare (include everything from rarely changed to very >>>>> frequent) >>>>> * often (include everything from often changed to very >>>>> frequent) >>>>> * frequent (only send the very frequently changed items) >>>>> >>>>> >>>>> >>>>> Parameter: clientId = The client id is specified by >>>>> the >>>>> client and should be unique however constantly used. >>>>> >>>>> Parameter: diff = In combination with the clientId >>>>> VDSM >>>>> will send only differences to the previous request from the >>>>> named >>>>> clientId. (if diff=true) >>>>> >>>>> >>>>> Additional Change: >>>>> >>>>> >>>>> Besides the introduction of the new parameters for list, >>>>> getVmStats >>>>> and getAllVmStats it might make sense to include a hash for the >>>>> appList into the rarely changed section of the response which >>>>> would >>>>> allow to identify changes and avoid having to sent the complete >>>>> appList every so often and only if the hash known to the client >>>>> is >>>>> outdated. >>>>> >>>>> Note: The appList (Application List) reported by the guest >>>>> agent >>>>> could be fully implemented on request only, as long as the >>>>> guest >>>>> agent installed supports this. As there seems to be a request >>>>> to >>>>> have the complete list of installed applications on all guests >>>>> this >>>>> data could be quite extensive and a huge list. On the other >>>>> hand >>>>> this data is only rarely visible and therefore it should not be >>>>> requested all the time and only on demand. Improvement of the >>>>> Guest >>>>> Agent: >>>>> >>>>> >>>>> As part of the proposed solution it is necessary to improve the >>>>> guest >>>>> agent as well. For the full application list there should be >>>>> implemented a caching system which will be fully reactive and >>>>> should >>>>> not poll the application list for example all the time. The >>>>> guest >>>>> can create a prepared data file containing all data in the JSON >>>>> format (as used for the communication with VDSM via VIO) and >>>>> just >>>>> have to read that file from disk and directly sends it to VDSM. >>>>> However it is quite possible that this list is to big and it >>>>> might >>>>> have to be chunked into pieces. (Multiple messages, which would >>>>> have >>>>> to be supported by VDSM then as well) The solution for this is >>>>> to >>>>> make VDSM request this data and it will retrieve the data >>>>> necessary >>>>> on request only. -- >>>>> Regards, >>>>> >>>>> Vinzenz Feenstra | Senior Software Engineer >>>>> RedHat Engineering Virtualization R & D >>>>> Phone: +420 532 294 625 >>>>> IRC: vfeenstr or evilissimo >>>>> >>>>> Better technology. Faster innovation. Powered by community >>>>> collaboration. >>>>> See how it works at redhat.com >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>> _______________________________________________ >>>> vdsm-devel mailing list >>>> vdsm-devel at lists.fedorahosted.org >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >>>> >>> >> > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > From iheim at redhat.com Fri Mar 15 11:06:38 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 15 Mar 2013 13:06:38 +0200 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <51387942.606@redhat.com> References: <51387942.606@redhat.com> Message-ID: <514300BE.60905@redhat.com> On 03/07/2013 01:25 PM, Vinzenz Feenstra wrote: > > Often Changed but unused > > This data does not seem to be used in the engine at all. It is *not* > even used in the data warehouse. > > *memoryStats* = {'swap_out': '0', 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', 'pageflt': '0', 'mem_total': '2096736', 'mem_unused': '1466884'} > *balloonInfo* = {'balloon_max': 2097152, 'balloon_cur': 2097152} these were added for better balloon control iirc. so api needs them for mom probbaly. not sure if engine needs them or not. > > *disks* = {'vda': {'readLatency': '0', 'apparentsize': '64424509440', 'writeLatency': '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', 'flushLatency': '156549', 'readRate': '0.00', 'truesize': '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': '0', 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} these i remember we added per request to the system - are you sure they are not in the dwh? From iheim at redhat.com Fri Mar 15 11:24:25 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 15 Mar 2013 13:24:25 +0200 Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <609241786.6750153.1363261951706.JavaMail.root@redhat.com> References: <609241786.6750153.1363261951706.JavaMail.root@redhat.com> Message-ID: <514304E9.2000503@redhat.com> On 03/14/2013 01:52 PM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Jiri Belka" >> To: "Alex Lourie" >> Cc: engine-devel at ovirt.org, users at ovirt.org >> Sent: Thursday, March 14, 2013 1:47:12 PM >> Subject: Re: [Users] Migrating engine-setup to otopi >> >> On Thu, 14 Mar 2013 07:06:04 -0400 (EDT) >> Alex Lourie wrote: >> >>>>> 1. Be able to port engine to other distributions. >>>> >>>> Really? Beside this topic I see hardcoded usernames in scripts... >>>> >>>> http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified >>> >>> These usernames are not hard-coded. There are default values >>> present which are kept for >>> local installations, but with remote DB setup the user is prompted >>> to provide a username >>> of her/his own. >> >> Not everywhere are postgresql dirs owned by postgres, on some BSDs it >> is >> _postgresql. > > Right, as I said this is going away. > > I am porting this first to Gentoo, which is the most complex, then I will be able to provide debian based. > > For the postgres issue, I am against assuming local database and the configuration of the database it-self (hba, etc). > > Like in other products, the dba will create a user and a database with the user as an owner and provide us the user/password and database name, this method does not require privileged database user for product installation and working locally or remotely, and is portable. actually, I'm against assuming we need a dba for a local install. we need to keep deployment easy, not assume user should worry about the db at all (other than providing the password for it, since it is needed later). can you pleas explain the concern, and the suggested solution on how it will look to run engine-setup/engine-upgrade in your approach? Thanks, Itamar > > We will keep the functionality of system provisioning as an optional component exists in some distribution. > > Regards, > Alon Bar-Lev > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Fri Mar 15 11:27:32 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 15 Mar 2013 13:27:32 +0200 Subject: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested In-Reply-To: <20130314155516.0c70a3f1.jbelka@redhat.com> References: <201303141210.r2ECAQhq005626@int-mx10.intmail.prod.int.phx2.redhat.com> <20130314153026.63504074.jbelka@redhat.com> <201303141442.r2EEgo8p003511@int-mx01.intmail.prod.int.phx2.redhat.com> <20130314155516.0c70a3f1.jbelka@redhat.com> Message-ID: <514305A4.6070803@redhat.com> On 03/14/2013 04:55 PM, Jiri Belka wrote: > On Thu, 14 Mar 2013 14:44:48 +0002 > Alex Lourie wrote: > >> Hi Jiri >> >> On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka wrote: >>> I'll talk about RHEVM but it's probably related to oVirt too. >>> >>> As rhevm installs all deps, I'm curious why versionlock.list is >>> populated after rhevm-setup and _not_dirrectly during installation >>> (maybe because you would need to hardcode versions into rhevm >>> package?). It took me tens of minutes to figure out why is upgrade >>> working differently now, just because I did _NOT_ do rhevm-setup after >>> clean install because I was thinking I know what files are important >>> and was restoring them from a tarball. >>> >>> I think running rhevm-setup if you just want to restore is stupid. If >>> we would know 100% which files are involved, just install, restore >>> from >>> backup, restore DB should be sufficient, without loosing time with >>> rhevm-setup which just writes there and here... :) >>> >> >> I don't really follow you here. What are you restoring with rhevm-setup? > > My previous (wrong) procedure to restore old version was: > > rhevm-cleanup, yum remove rhevm\*, rm -rf $dirs, yum install rhevm\*, > tar xvzpf /backup.tgz, ./restore.sh for DB... > > which was not fully correct as I haven't > known /etc/yum/plugin.d/versionlock.list is touched by rhevm-setup as > well and thus yum was working very strange during next normal > upgrade. > _______________________________________________ > Users mailing list > Users at ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > moran/ofer - i remember some discussions on moving from version lock to a yum plugin. i.e., yum will not update the packages if not getting some parameter from engine-upgrade (but will show updates exist), but they will behave normally other than that? From alonbl at redhat.com Fri Mar 15 18:07:21 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Fri, 15 Mar 2013 14:07:21 -0400 (EDT) Subject: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested In-Reply-To: <514305A4.6070803@redhat.com> Message-ID: <1985267630.7169027.1363370841010.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Jiri Belka" > Cc: engine-devel at ovirt.org, Users at ovirt.org > Sent: Friday, March 15, 2013 1:27:32 PM > Subject: Re: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested > > On 03/14/2013 04:55 PM, Jiri Belka wrote: > > On Thu, 14 Mar 2013 14:44:48 +0002 > > Alex Lourie wrote: > > > >> Hi Jiri > >> > >> On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka > >> wrote: > >>> I'll talk about RHEVM but it's probably related to oVirt too. > >>> > >>> As rhevm installs all deps, I'm curious why versionlock.list is > >>> populated after rhevm-setup and _not_dirrectly during > >>> installation > >>> (maybe because you would need to hardcode versions into rhevm > >>> package?). It took me tens of minutes to figure out why is > >>> upgrade > >>> working differently now, just because I did _NOT_ do rhevm-setup > >>> after > >>> clean install because I was thinking I know what files are > >>> important > >>> and was restoring them from a tarball. > >>> > >>> I think running rhevm-setup if you just want to restore is > >>> stupid. If > >>> we would know 100% which files are involved, just install, > >>> restore > >>> from > >>> backup, restore DB should be sufficient, without loosing time > >>> with > >>> rhevm-setup which just writes there and here... :) > >>> > >> > >> I don't really follow you here. What are you restoring with > >> rhevm-setup? > > > > My previous (wrong) procedure to restore old version was: > > > > rhevm-cleanup, yum remove rhevm\*, rm -rf $dirs, yum install > > rhevm\*, > > tar xvzpf /backup.tgz, ./restore.sh for DB... > > > > which was not fully correct as I haven't > > known /etc/yum/plugin.d/versionlock.list is touched by rhevm-setup > > as > > well and thus yum was working very strange during next normal > > upgrade. > > _______________________________________________ > > Users mailing list > > Users at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > > moran/ofer - i remember some discussions on moving from version lock > to > a yum plugin. i.e., yum will not update the packages if not getting > some > parameter from engine-upgrade (but will show updates exist), but they > will behave normally other than that? We cannot mention yum specific features in setup context any more... this is part of the mission. We should reconsider the locking of version - no product uses this. After upgrade of packages, product should either know not to start or upgrade the database when restarted, or better know to work with older schema. The version lock should be removed as soon as possible. Alon From vszocs at redhat.com Fri Mar 15 18:09:07 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 15 Mar 2013 14:09:07 -0400 (EDT) Subject: [Engine-devel] restapi - domains In-Reply-To: <513DA73D.2000304@redhat.com> Message-ID: <2094442572.15445667.1363370947146.JavaMail.root@redhat.com> Hi, in WebAdmin/UserPortal GUI, it's possible to enter 'username at domain' into User Name input field. After doing this, Domain drop-down becomes disabled. This is actually how auto-login works from GUI perspective. So GetDomainList public query + Domain drop-down aren't really necessary for performing user login in GUI.. Vojtech ----- Original Message ----- From: "Itamar Heim" To: "Michael Pasternak" Cc: "Shireesh Anjal" , engine-devel at ovirt.org Sent: Monday, March 11, 2013 10:43:25 AM Subject: Re: [Engine-devel] restapi - domains On 03/11/2013 10:37 AM, Michael Pasternak wrote: > On 03/11/2013 10:19 AM, Shireesh Anjal wrote: >> On 03/09/2013 12:52 AM, Itamar Heim wrote: >>> On 03/08/2013 06:04 AM, Shireesh Anjal wrote: >>>> On 03/07/2013 01:05 PM, Aravinda wrote: >>>>> We can have only two fields in login screen, username and password. >>>>> Username will include domain name(username at domain). >>>>> >>>>> Default domain name can be "internal" if user didn't enter the domain >>>>> name as part of username then we can append the default value and >>>>> validate. >>>>> >>>>> Note: We use username at domain as username when we connect through >>>>> /api >>>> >>>> The idea is to *not* have the user type in the domain name, but rather >>>> let him/her choose one, just like what happens in webadmin. We should >>>> try and minimize typing as much as possible when it comes to mobile apps. >>> >>> I think this was done on purpose for some reason to not provide a public api for the rest api, but i could be wrong and don't remember the detail. >>> as the concepts of multi tenancy and multiple domains grow, providing the list of domains is considered an issue, >> >> Is it an issue specific to restapi? For we *do show* the list of domains in webadmin login screen. yes, but we may want to remove that going forward and not show the domains, as most sites don't, which allows using more domains, without exposing them to other users. > > indeed, UI using public query for that, while in api each request has to be authenticated, > as workaround, i suggest creating internal user for this purpose and using it in the app > (internally) to fetch entities that should not require explicit authentication from the > application PoV. i assume rest api can use the public queries as well if we go that way? > >> >>> and most systems today require user to provide their full user/domain (well, usually in the form of their email address). >>> >>>> >>>>> >>>>> -- >>>>> regards >>>>> Aravinda >>>>> >>>>> On 03/07/2013 11:15 AM, Shireesh Anjal wrote: >>>>>> Hi, >>>>>> >>>>>> We are trying to develop a simple android app to monitor and manage >>>>>> gluster clusters by consuming the restapi exposed by engine. The >>>>>> first screen is the login screen, which is similar to the webadmin >>>>>> login screen. Here, we want to populate the combo box of "domains" by >>>>>> fetching it from the restapi. However, the domains api cannot be >>>>>> invoked without authentication! So we have a sort of a >>>>>> chicken-and-egg problem. >>>>>> >>>>>> Any suggestions on how to tackle this? I feel the "domains" api >>>>>> should be "public", in the sense it should not expect authentication. >>>>>> >>>>>> Regards, >>>>>> Shireesh >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel at ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel at ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From alonbl at redhat.com Fri Mar 15 22:21:29 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Fri, 15 Mar 2013 18:21:29 -0400 (EDT) Subject: [Engine-devel] [Users] Migrating engine-setup to otopi In-Reply-To: <514304E9.2000503@redhat.com> Message-ID: <686373368.7216932.1363386089629.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: "Jiri Belka" , engine-devel at ovirt.org, users at ovirt.org > Sent: Friday, March 15, 2013 1:24:25 PM > Subject: Re: [Engine-devel] [Users] Migrating engine-setup to otopi > > On 03/14/2013 01:52 PM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > >> From: "Jiri Belka" > >> To: "Alex Lourie" > >> Cc: engine-devel at ovirt.org, users at ovirt.org > >> Sent: Thursday, March 14, 2013 1:47:12 PM > >> Subject: Re: [Users] Migrating engine-setup to otopi > >> > >> On Thu, 14 Mar 2013 07:06:04 -0400 (EDT) > >> Alex Lourie wrote: > >> > >>>>> 1. Be able to port engine to other distributions. > >>>> > >>>> Really? Beside this topic I see hardcoded usernames in > >>>> scripts... > >>>> > >>>> http://gerrit.ovirt.org/#/c/12551/2/backend/manager/dbscripts/dbfunctions.sh,unified > >>> > >>> These usernames are not hard-coded. There are default values > >>> present which are kept for > >>> local installations, but with remote DB setup the user is > >>> prompted > >>> to provide a username > >>> of her/his own. > >> > >> Not everywhere are postgresql dirs owned by postgres, on some BSDs > >> it > >> is > >> _postgresql. > > > > Right, as I said this is going away. > > > > I am porting this first to Gentoo, which is the most complex, then > > I will be able to provide debian based. > > > > For the postgres issue, I am against assuming local database and > > the configuration of the database it-self (hba, etc). > > > > Like in other products, the dba will create a user and a database > > with the user as an owner and provide us the user/password and > > database name, this method does not require privileged database > > user for product installation and working locally or remotely, and > > is portable. > > actually, I'm against assuming we need a dba for a local install. > we need to keep deployment easy, not assume user should worry about > the > db at all (other than providing the password for it, since it is > needed > later). > > can you pleas explain the concern, and the suggested solution on how > it > will look to run engine-setup/engine-upgrade in your approach? Let's start from the end... there will be no change (accept of maybe be one/two more prompts during installation) at rhel/centos/fedora. Now... People who wrote the current installation confused between host provisioning and database interaction. Another confusion out there is the wrong assumption that ovirt-engine owns the system it installed on, and can perform changes to shared system components such as apache and postgres. Both of these should not leak into other distributions as we port, oh well, as much as we can, in our current state. Host provisioning: 1. Check if postgres is installed on host. 2. Check if postgres already initialized its database and optionally perform initdb. 3. Start postgres service. 4. Mark postgres service to start at boot. 5. Open network access to postgres. 6. Set network authentication (pg_hba). 7. Set the dba (postgres) user password. 8. Create user for engine database. 9. Create database for engine. Database interaction: 1. Accept application user/password. Either: a2. Create schema. a3. Import data. Or: b2: Upgrade database. Now, let's assume we are going to support oracle or db2, will we do the host provisioning as part of our setup? well, we can provide a script to do that, but most likely the dba already know how to install and configure his database to be ready for the database interaction phase. Another issue is that in case of remote database, we are unable to perform the host provisioning anyway, making the local vs remote installation procedure different, so installation documentation becomes even more complex. And of course there is the issue of permissions, we cannot assume the user that is installing ovirt-engine have dba permissions to the database, especially if the database is remote. Well behaved database application will skip the host provisioning and perform the database interaction only. While the user will configure database and create the database for the product. We are going to be well behaved, this is mandatory for porting. There can be host provisioning plugin to optionally perform the provisioning phase, this is distribution dependent plugin, which will run only on supported distributions and the database is installed locally. Currently we will support the currently supported distributions, I am not sure it is wroth the effort to port this module. Example for user visible change if provisioning module is enabled: --- Database host [localhost]: localhost You have selected local database, setup can configure the database for ovirt-engine use, this includes system configuration and database creation. Do you wish installer to configure database, or you prefer to do so manually (configure, manual) [configure]: manual Please configure database to accept network password connections at pg_hba.conf: host all all 127.0.0.1/32 password host all all ::1/128 password Then create user and database, example: create user engine password 'engine'; create database engine owner engine; Database user: Database user password: Database name: --- Of course the provisioning module can be enforced to "configure", skipping this question, this can be done by installing configuration file as part of the branding. Comments? Alon From djasa at redhat.com Sat Mar 16 19:47:17 2013 From: djasa at redhat.com (David =?UTF-8?Q?Ja=C5=A1a?=) Date: Sat, 16 Mar 2013 20:47:17 +0100 Subject: [Engine-devel] restapi - domains In-Reply-To: <2094442572.15445667.1363370947146.JavaMail.root@redhat.com> References: <2094442572.15445667.1363370947146.JavaMail.root@redhat.com> Message-ID: <1363463237.24469.3.camel@cihla.usersys.redhat.com> Vojtech Szocs p??e v P? 15. 03. 2013 v 14:09 -0400: > Hi, > > in WebAdmin/UserPortal GUI, it's possible to enter 'username at domain' into User Name input field. After doing this, Domain drop-down becomes disabled. This is actually how auto-login works from GUI perspective. > > So GetDomainList public query + Domain drop-down aren't really necessary for performing user login in GUI.. Yeah, but you have to type domain name precisely instead of just choosing familiar one... David > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Michael Pasternak" > Cc: "Shireesh Anjal" , engine-devel at ovirt.org > Sent: Monday, March 11, 2013 10:43:25 AM > Subject: Re: [Engine-devel] restapi - domains > > On 03/11/2013 10:37 AM, Michael Pasternak wrote: > > On 03/11/2013 10:19 AM, Shireesh Anjal wrote: > >> On 03/09/2013 12:52 AM, Itamar Heim wrote: > >>> On 03/08/2013 06:04 AM, Shireesh Anjal wrote: > >>>> On 03/07/2013 01:05 PM, Aravinda wrote: > >>>>> We can have only two fields in login screen, username and password. > >>>>> Username will include domain name(username at domain). > >>>>> > >>>>> Default domain name can be "internal" if user didn't enter the domain > >>>>> name as part of username then we can append the default value and > >>>>> validate. > >>>>> > >>>>> Note: We use username at domain as username when we connect through > >>>>> /api > >>>> > >>>> The idea is to *not* have the user type in the domain name, but rather > >>>> let him/her choose one, just like what happens in webadmin. We should > >>>> try and minimize typing as much as possible when it comes to mobile apps. > >>> > >>> I think this was done on purpose for some reason to not provide a public api for the rest api, but i could be wrong and don't remember the detail. > >>> as the concepts of multi tenancy and multiple domains grow, providing the list of domains is considered an issue, > >> > >> Is it an issue specific to restapi? For we *do show* the list of domains in webadmin login screen. > > yes, but we may want to remove that going forward and not show the > domains, as most sites don't, which allows using more domains, without > exposing them to other users. > > > > > indeed, UI using public query for that, while in api each request has to be authenticated, > > as workaround, i suggest creating internal user for this purpose and using it in the app > > (internally) to fetch entities that should not require explicit authentication from the > > application PoV. > > i assume rest api can use the public queries as well if we go that way? > > > > >> > >>> and most systems today require user to provide their full user/domain (well, usually in the form of their email address). > >>> > >>>> > >>>>> > >>>>> -- > >>>>> regards > >>>>> Aravinda > >>>>> > >>>>> On 03/07/2013 11:15 AM, Shireesh Anjal wrote: > >>>>>> Hi, > >>>>>> > >>>>>> We are trying to develop a simple android app to monitor and manage > >>>>>> gluster clusters by consuming the restapi exposed by engine. The > >>>>>> first screen is the login screen, which is similar to the webadmin > >>>>>> login screen. Here, we want to populate the combo box of "domains" by > >>>>>> fetching it from the restapi. However, the domains api cannot be > >>>>>> invoked without authentication! So we have a sort of a > >>>>>> chicken-and-egg problem. > >>>>>> > >>>>>> Any suggestions on how to tackle this? I feel the "domains" api > >>>>>> should be "public", in the sense it should not expect authentication. > >>>>>> > >>>>>> Regards, > >>>>>> Shireesh > >>>>>> _______________________________________________ > >>>>>> Engine-devel mailing list > >>>>>> Engine-devel at ovirt.org > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>> > >>>>> _______________________________________________ > >>>>> Engine-devel mailing list > >>>>> Engine-devel at ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>> > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel at ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > _______________________________________________ > 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 -- David Ja?a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 From mkolesni at redhat.com Sun Mar 17 08:46:37 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Sun, 17 Mar 2013 04:46:37 -0400 (EDT) Subject: [Engine-devel] Generic "name is used" message Message-ID: <1898563294.1894360.1363509997820.JavaMail.root@redhat.com> Hi, Lately I had to add an error message that "name is already used". I looked in the translations files and saw many messages for specific entity types in the system that looked much the same: VDS_TRY_CREATE_WITH_EXISTING_PARAMS=Cannot ${action} ${type}. Host with the same name already exists ACTION_TYPE_FAILED_VM_ALREADY_EXIST = Cannot $ { action } $ { type }. VM with the same name already exists . etc.. What I decided to do is not add another "X with the same name already exists" message, but instead add a generic message for this condition. You can review the patch here : http://gerrit.ovirt.org/#/c/12361 I also went the extra mile to change the current messages that look like this to use this message: http://gerrit.ovirt.org/#/c/13063/ It is not a full coverage, since some commands don't fill the $action $type replacements, and the required change is a bit bigger than this patch scope, but it's a good start. FYI, and if you see other generic messages repeating themselves, don't hesitate to squash them. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkolesni at redhat.com Sun Mar 17 09:30:35 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Sun, 17 Mar 2013 05:30:35 -0400 (EDT) Subject: [Engine-devel] Better testing for ValidationResults using ValidationResultMatchers In-Reply-To: <818321091.1894972.1363510165088.JavaMail.root@redhat.com> Message-ID: <1623021709.1902202.1363512635976.JavaMail.root@redhat.com> Hi, If you don't know what ValidationResult is, check out http://www.ovirt.org/ValidationResult In a gist, I added a new way to test this using JUnit's assertThat syntax: // Test that validation result is valid assertThat(someValidation(), isValid()); // Test that validation result is invalid assertThat(someValidation(), failsWith(VdcBllMessages.SOME_ERROR)); // Test that validation result is invalid and has replacement assertThat(someValidation(), both(failsWith(VdcBllMessages.SOME_ERROR)).and(replacements(hasItem(EXPECTED_REPLACEMENT)))); You need to statically import ValidationResultMatchers (and the basic JUnit matchers) for this to work. The rest I documented in the aforementioned wiki. Check out the patch: http://gerrit.ovirt.org/#/c/13061 Or how to use it: http://gerrit.ovirt.org/#/c/13062 Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From yzaslavs at redhat.com Sun Mar 17 10:01:37 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 17 Mar 2013 06:01:37 -0400 (EDT) Subject: [Engine-devel] CreateComputerAccount - do we really need it? Message-ID: <1219730683.8611099.1363514497670.JavaMail.root@redhat.com> Hi all, Do we need CreateComputerAccountCommand and its correspoding ldap broker LdapCreateComputerAccountCommand? Thanks, Yair From ofrenkel at redhat.com Sun Mar 17 10:08:14 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Sun, 17 Mar 2013 06:08:14 -0400 (EDT) Subject: [Engine-devel] CreateComputerAccount - do we really need it? In-Reply-To: <1219730683.8611099.1363514497670.JavaMail.root@redhat.com> Message-ID: <1451654039.21010440.1363514894705.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Yair Zaslavsky" > To: engine-devel at ovirt.org > Sent: Sunday, March 17, 2013 12:01:37 PM > Subject: [Engine-devel] CreateComputerAccount - do we really need it? > > Hi all, > Do we need CreateComputerAccountCommand and its correspoding ldap > broker LdapCreateComputerAccountCommand? > is it exposed by any of the front-ends? (rest/user portal/webadmin)? > > Thanks, > Yair > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From rgolan at redhat.com Sun Mar 17 10:08:34 2013 From: rgolan at redhat.com (Roy Golan) Date: Sun, 17 Mar 2013 12:08:34 +0200 Subject: [Engine-devel] CreateComputerAccount - do we really need it? In-Reply-To: <1219730683.8611099.1363514497670.JavaMail.root@redhat.com> References: <1219730683.8611099.1363514497670.JavaMail.root@redhat.com> Message-ID: <51459622.3080201@redhat.com> On 03/17/2013 12:01 PM, Yair Zaslavsky wrote: > Hi all, > Do we need CreateComputerAccountCommand and its correspoding ldap broker LdapCreateComputerAccountCommand? > > > Thanks, > Yair > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel Smells like legacy AD thing and I'm not aware of any flow needing this. From yzaslavs at redhat.com Sun Mar 17 10:12:21 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 17 Mar 2013 06:12:21 -0400 (EDT) Subject: [Engine-devel] CreateComputerAccount - do we really need it? In-Reply-To: <1451654039.21010440.1363514894705.JavaMail.root@redhat.com> Message-ID: <474026630.8611263.1363515141789.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Omer Frenkel" > To: "Yair Zaslavsky" > Cc: engine-devel at ovirt.org > Sent: Sunday, March 17, 2013 12:08:14 PM > Subject: Re: [Engine-devel] CreateComputerAccount - do we really need it? > > > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > To: engine-devel at ovirt.org > > Sent: Sunday, March 17, 2013 12:01:37 PM > > Subject: [Engine-devel] CreateComputerAccount - do we really need > > it? > > > > Hi all, > > Do we need CreateComputerAccountCommand and its correspoding ldap > > broker LdapCreateComputerAccountCommand? > > > > is it exposed by any of the front-ends? (rest/user portal/webadmin)? No. > > > > > Thanks, > > Yair > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From amureini at redhat.com Sun Mar 17 12:13:15 2013 From: amureini at redhat.com (Allon Mureinik) Date: Sun, 17 Mar 2013 08:13:15 -0400 (EDT) Subject: [Engine-devel] CreateComputerAccount - do we really need it? In-Reply-To: <474026630.8611263.1363515141789.JavaMail.root@redhat.com> Message-ID: <1158554415.19776095.1363522395800.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Omer Frenkel" > Cc: engine-devel at ovirt.org > Sent: Sunday, March 17, 2013 12:12:21 PM > Subject: Re: [Engine-devel] CreateComputerAccount - do we really need it? > > > > ----- Original Message ----- > > From: "Omer Frenkel" > > To: "Yair Zaslavsky" > > Cc: engine-devel at ovirt.org > > Sent: Sunday, March 17, 2013 12:08:14 PM > > Subject: Re: [Engine-devel] CreateComputerAccount - do we really > > need it? > > > > > > > > ----- Original Message ----- > > > From: "Yair Zaslavsky" > > > To: engine-devel at ovirt.org > > > Sent: Sunday, March 17, 2013 12:01:37 PM > > > Subject: [Engine-devel] CreateComputerAccount - do we really need > > > it? > > > > > > Hi all, > > > Do we need CreateComputerAccountCommand and its correspoding ldap > > > broker LdapCreateComputerAccountCommand? > > > > > > > is it exposed by any of the front-ends? (rest/user > > portal/webadmin)? > > No. git grep shows no-one uses it. Yair - are you sending a patch to remove it? > > > > > > > > > Thanks, > > > Yair > > > _______________________________________________ > > > 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 Sun Mar 17 12:29:12 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 17 Mar 2013 08:29:12 -0400 (EDT) Subject: [Engine-devel] CreateComputerAccount - do we really need it? In-Reply-To: <1158554415.19776095.1363522395800.JavaMail.root@redhat.com> Message-ID: <412795027.8615819.1363523352184.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Allon Mureinik" > To: "Yair Zaslavsky" > Cc: engine-devel at ovirt.org, "Omer Frenkel" > Sent: Sunday, March 17, 2013 2:13:15 PM > Subject: Re: [Engine-devel] CreateComputerAccount - do we really need it? > > > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > To: "Omer Frenkel" > > Cc: engine-devel at ovirt.org > > Sent: Sunday, March 17, 2013 12:12:21 PM > > Subject: Re: [Engine-devel] CreateComputerAccount - do we really > > need it? > > > > > > > > ----- Original Message ----- > > > From: "Omer Frenkel" > > > To: "Yair Zaslavsky" > > > Cc: engine-devel at ovirt.org > > > Sent: Sunday, March 17, 2013 12:08:14 PM > > > Subject: Re: [Engine-devel] CreateComputerAccount - do we really > > > need it? > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Yair Zaslavsky" > > > > To: engine-devel at ovirt.org > > > > Sent: Sunday, March 17, 2013 12:01:37 PM > > > > Subject: [Engine-devel] CreateComputerAccount - do we really > > > > need > > > > it? > > > > > > > > Hi all, > > > > Do we need CreateComputerAccountCommand and its correspoding > > > > ldap > > > > broker LdapCreateComputerAccountCommand? > > > > > > > > > > is it exposed by any of the front-ends? (rest/user > > > portal/webadmin)? > > > > No. > git grep shows no-one uses it. > Yair - are you sending a patch to remove it? Yes. > > > > > > > > > > > > > > Thanks, > > > > Yair > > > > _______________________________________________ > > > > 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 abaron at redhat.com Sun Mar 17 13:13:09 2013 From: abaron at redhat.com (Ayal Baron) Date: Sun, 17 Mar 2013 09:13:09 -0400 (EDT) Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <51430032.7070302@redhat.com> Message-ID: <744223384.9185834.1363525989695.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/13/2013 11:55 PM, Ayal Baron wrote: > ... > >>>> The only reason we have this problem is because there is this > >>>> thing against making multiple calls. > >>>> > >>>> Just split it up. > >>>> getVmRuntimeStats() - transient things like mem and cpu% > >>>> getVmInformation() - (semi)static things like disk\networking > >>>> layout > >>>> etc. > >>>> Each updated at different intervals. > >>> > >>> +1 on splitting the data up into 2 separate API calls. > >>> You could potentially add a checksum (md5, or any other way) of > >>> the > >>> "static" data to getVmRuntimeStats and not bother even with > >>> polling > >>> the VmInformation if this hasn't changed. Then you could poll as > >>> often as you'd like the stats and immediately see if you also > >>> need > >>> to retrieve VmInfo or not (you rarely would). > >> +1 To Ayal's suggestion > >> except that instead of the engine hashing the data VDSM sends the > >> key which is opaque to the engine. > >> This can be a local timestap or a generation number. > > > > Of course vdsm does the hash, otherwise you'd need to pass all the > > data to engine which would beat the purpose. > > I thought you meant engine will be sending the hash of previous > requests > per VM to vdsm, then vdsm will reply back with vm's removed, vm's > added, > and the details for vm's that changed (i.e., engine would be doing > something like if-modified-since-checksum per vm). > benefit is reducing a round trip. > but first would need to split to calls of stats (always changing) and > slowly/never changing data. If vdms accepts the hash then in your method engine would have to periodically call getVmInfo(hash). What I was suggesting is that getVmStats would return vmInfo hash so that we could avoid calling getVmInfo altogether. The stats *always* change so there is no need for checking if that info has changed. What we could do is avoid the split into 2 verbs by calling getVmStats(hash) and then have getVmStats return everything if the hash has changed or only the stats if it hasn't. This would be the least number of roundtrips and avoid the split. If you don't pass a hash it would return everything so this way it's also fully backward compatible. > > > > >> > >> But, we might want to consider that when we add events polling > >> becomes (much) less frequent so maybe it'll be an overkill. > > > > You'd still need to compare versions of the data in vdsm and send > > only if it changed. If you don't persist what was received last > > then potentially you could have a monday morning effect where upon > > on system startup you'd be sending everything. So I still think > > you'd want to have the hash. > > > > > >> > >>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Vinzenz Feenstra" > >>>>> To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org > >>>>> Sent: Thursday, March 7, 2013 6:25:54 AM > >>>>> Subject: [Engine-devel] Proposal VDSM <=> Engine Data > >>>>> Statistics > >>>>> Retrieval Optimization > >>>>> > >>>>> > >>>>> Please find the prettier version on the wiki: > >>>>> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > >>>>> > >>>>> Proposal VDSM - Engine Data Statistics Retrieval > >>>>> VDSM <=> Engine data retrieval optimization > >>>>> Motivation: > >>>>> > >>>>> > >>>>> Currently the RHEVM engine is polling the a lot of data from > >>>>> VDSM > >>>>> every 15 seconds. This should be optimized and the amount of > >>>>> data > >>>>> requested should be more specific. > >>>>> > >>>>> For each VM the data currently contains much more information > >>>>> than > >>>>> actually needed which blows up the size of the XML content > >>>>> quite > >>>>> big. We could optimize this by splitting the reply on the > >>>>> getVmStats > >>>>> based on the request of the engine into sections. For this > >>>>> reason > >>>>> Omer Frenkel and me have split up the data into parts based on > >>>>> their > >>>>> usage. > >>>>> > >>>>> This data can and usually does change during the lifetime of > >>>>> the > >>>>> VM. > >>>>> Rarely Changed: > >>>>> > >>>>> > >>>>> This data is change not very frequent and it should be enough > >>>>> to > >>>>> update this only once in a while. Most commonly this data > >>>>> changes > >>>>> after changes made in the UI or after a migration of the VM to > >>>>> another Host. Status = Running acpiEnable = true vmType = kvm > >>>>> guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 > >>>>> kvmEnable = true # this should be constant and never changed > >>>>> pauseCode = NOERR monitorResponse = 0 session = Locked # unused > >>>>> netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', > >>>>> 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': > >>>>> ['10.34.60.148'], > >>>>> 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', > >>>>> 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 > >>>>> 3.2.2', > >>>>> 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 > >>>>> 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB > >>>>> 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = > >>>>> 11314 > >>>>> guestIPs = 10.34.60.148 # duplicated info displayIp = 0 > >>>>> displayPort > >>>>> = 5902 displaySecurePort = 5903 username = user at W864GUESTAGENTT > >>>>> clientIp = lastLogin = 1361976900.67 Often Changed: > >>>>> > >>>>> > >>>>> This data is changed quite often however it is not necessary to > >>>>> update this data every 15 seconds. As this is cumulative data > >>>>> and > >>>>> reflects the current status, and it does not need to be > >>>>> snapshotted > >>>>> every 15 seconds to retrieve statistics. The data can be > >>>>> retrieved > >>>>> in much more generous time slices. (e.g. Every 5 minutes) > >>>>> network > >>>>> = > >>>>> {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', > >>>>> 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': > >>>>> '0.0', > >>>>> 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': > >>>>> 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': > >>>>> '64055406592', > >>>>> 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': > >>>>> '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset = > >>>>> 14422 > >>>>> elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09 > >>>>> # > >>>>> unused Often Changed but unused > >>>>> > >>>>> > >>>>> This data does not seem to be used in the engine at all. It is > >>>>> not > >>>>> even used in the data warehouse. memoryStats = {'swap_out': > >>>>> '0', > >>>>> 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', > >>>>> 'pageflt': > >>>>> '0', 'mem_total': '2096736', 'mem_unused': '1466884'} > >>>>> balloonInfo > >>>>> = > >>>>> {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = > >>>>> {'vda': > >>>>> {'readLatency': '0', 'apparentsize': '64424509440', > >>>>> 'writeLatency': > >>>>> '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', > >>>>> 'flushLatency': '156549', 'readRate': '0.00', 'truesize': > >>>>> '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': > >>>>> '0', > >>>>> 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', > >>>>> 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very > >>>>> frequent uppdates needed by webadmin portal: > >>>>> > >>>>> > >>>>> This data is mostly needed for the webadmin portal and might be > >>>>> required to be updated quite often. An exception here is the > >>>>> statsAge field, which seems to be unused by the Engine. This > >>>>> data > >>>>> could be requested every 15 seconds to keep things as they are > >>>>> now. > >>>>> cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution > >>>>> for > >>>>> VDSM & Engine: > >>>>> > >>>>> > >>>>> We will introduce new optional parameters to getVmStats, > >>>>> getAllVmStats and list to allow a finer grained specification > >>>>> of > >>>>> data which should be included. > >>>>> > >>>>> Parameter: statsType = (getVmStats, getAllVmStats > >>>>> only) > >>>>> Allowed values: > >>>>> > >>>>> * full (default to keep backwards compatibility) > >>>>> * app-list (Just send the application list) > >>>>> * rare (include everything from rarely changed to very > >>>>> frequent) > >>>>> * often (include everything from often changed to very > >>>>> frequent) > >>>>> * frequent (only send the very frequently changed items) > >>>>> > >>>>> > >>>>> > >>>>> Parameter: clientId = The client id is specified by > >>>>> the > >>>>> client and should be unique however constantly used. > >>>>> > >>>>> Parameter: diff = In combination with the clientId > >>>>> VDSM > >>>>> will send only differences to the previous request from the > >>>>> named > >>>>> clientId. (if diff=true) > >>>>> > >>>>> > >>>>> Additional Change: > >>>>> > >>>>> > >>>>> Besides the introduction of the new parameters for list, > >>>>> getVmStats > >>>>> and getAllVmStats it might make sense to include a hash for the > >>>>> appList into the rarely changed section of the response which > >>>>> would > >>>>> allow to identify changes and avoid having to sent the complete > >>>>> appList every so often and only if the hash known to the client > >>>>> is > >>>>> outdated. > >>>>> > >>>>> Note: The appList (Application List) reported by the guest > >>>>> agent > >>>>> could be fully implemented on request only, as long as the > >>>>> guest > >>>>> agent installed supports this. As there seems to be a request > >>>>> to > >>>>> have the complete list of installed applications on all guests > >>>>> this > >>>>> data could be quite extensive and a huge list. On the other > >>>>> hand > >>>>> this data is only rarely visible and therefore it should not be > >>>>> requested all the time and only on demand. Improvement of the > >>>>> Guest > >>>>> Agent: > >>>>> > >>>>> > >>>>> As part of the proposed solution it is necessary to improve the > >>>>> guest > >>>>> agent as well. For the full application list there should be > >>>>> implemented a caching system which will be fully reactive and > >>>>> should > >>>>> not poll the application list for example all the time. The > >>>>> guest > >>>>> can create a prepared data file containing all data in the JSON > >>>>> format (as used for the communication with VDSM via VIO) and > >>>>> just > >>>>> have to read that file from disk and directly sends it to VDSM. > >>>>> However it is quite possible that this list is to big and it > >>>>> might > >>>>> have to be chunked into pieces. (Multiple messages, which would > >>>>> have > >>>>> to be supported by VDSM then as well) The solution for this is > >>>>> to > >>>>> make VDSM request this data and it will retrieve the data > >>>>> necessary > >>>>> on request only. -- > >>>>> Regards, > >>>>> > >>>>> Vinzenz Feenstra | Senior Software Engineer > >>>>> RedHat Engineering Virtualization R & D > >>>>> Phone: +420 532 294 625 > >>>>> IRC: vfeenstr or evilissimo > >>>>> > >>>>> Better technology. Faster innovation. Powered by community > >>>>> collaboration. > >>>>> See how it works at redhat.com > >>>>> _______________________________________________ > >>>>> Engine-devel mailing list > >>>>> Engine-devel at ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>> > >>>> _______________________________________________ > >>>> vdsm-devel mailing list > >>>> vdsm-devel at lists.fedorahosted.org > >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >>>> > >>> > >> > > _______________________________________________ > > vdsm-devel mailing list > > vdsm-devel at lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > From ykaul at redhat.com Sun Mar 17 13:38:45 2013 From: ykaul at redhat.com (Yaniv Kaul) Date: Sun, 17 Mar 2013 15:38:45 +0200 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <744223384.9185834.1363525989695.JavaMail.root@redhat.com> References: <744223384.9185834.1363525989695.JavaMail.root@redhat.com> Message-ID: <5145C765.9020602@redhat.com> On 17/03/13 15:13, Ayal Baron wrote: > > ----- Original Message ----- >> On 03/13/2013 11:55 PM, Ayal Baron wrote: >> ... >>>>>> The only reason we have this problem is because there is this >>>>>> thing against making multiple calls. >>>>>> >>>>>> Just split it up. >>>>>> getVmRuntimeStats() - transient things like mem and cpu% >>>>>> getVmInformation() - (semi)static things like disk\networking >>>>>> layout >>>>>> etc. >>>>>> Each updated at different intervals. >>>>> +1 on splitting the data up into 2 separate API calls. >>>>> You could potentially add a checksum (md5, or any other way) of >>>>> the >>>>> "static" data to getVmRuntimeStats and not bother even with >>>>> polling >>>>> the VmInformation if this hasn't changed. Then you could poll as >>>>> often as you'd like the stats and immediately see if you also >>>>> need >>>>> to retrieve VmInfo or not (you rarely would). >>>> +1 To Ayal's suggestion >>>> except that instead of the engine hashing the data VDSM sends the >>>> key which is opaque to the engine. >>>> This can be a local timestap or a generation number. >>> Of course vdsm does the hash, otherwise you'd need to pass all the >>> data to engine which would beat the purpose. >> I thought you meant engine will be sending the hash of previous >> requests >> per VM to vdsm, then vdsm will reply back with vm's removed, vm's >> added, >> and the details for vm's that changed (i.e., engine would be doing >> something like if-modified-since-checksum per vm). >> benefit is reducing a round trip. >> but first would need to split to calls of stats (always changing) and >> slowly/never changing data. > If vdms accepts the hash then in your method engine would have to periodically call getVmInfo(hash). > What I was suggesting is that getVmStats would return vmInfo hash so that we could avoid calling getVmInfo altogether. > The stats *always* change so there is no need for checking if that info has changed. > What we could do is avoid the split into 2 verbs by calling getVmStats(hash) and then have getVmStats return everything if the hash has changed or only the stats if it hasn't. This would be the least number of roundtrips and avoid the split. If you don't pass a hash it would return everything so this way it's also fully backward compatible. For the 'static' data, why is there a need for a hash? If VDSM sends in each update a timestamp, can't RHEVM just use if-modified-since with the last timestamp it got from VDSM? Is it cheaper for VDSM to calculate the hash, than update the timestamp per change in any of the fields? It doesn't really need to update the timestamp per change, only for the first change since last update sent actually (so 'dirty' flag in a way, to signify data that RHEVM hasn't seen yet). Y. > >>>> But, we might want to consider that when we add events polling >>>> becomes (much) less frequent so maybe it'll be an overkill. >>> You'd still need to compare versions of the data in vdsm and send >>> only if it changed. If you don't persist what was received last >>> then potentially you could have a monday morning effect where upon >>> on system startup you'd be sending everything. So I still think >>> you'd want to have the hash. >>> >>> >>>>>> ----- Original Message ----- >>>>>>> From: "Vinzenz Feenstra" >>>>>>> To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org >>>>>>> Sent: Thursday, March 7, 2013 6:25:54 AM >>>>>>> Subject: [Engine-devel] Proposal VDSM <=> Engine Data >>>>>>> Statistics >>>>>>> Retrieval Optimization >>>>>>> >>>>>>> >>>>>>> Please find the prettier version on the wiki: >>>>>>> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval >>>>>>> >>>>>>> Proposal VDSM - Engine Data Statistics Retrieval >>>>>>> VDSM <=> Engine data retrieval optimization >>>>>>> Motivation: >>>>>>> >>>>>>> >>>>>>> Currently the RHEVM engine is polling the a lot of data from >>>>>>> VDSM >>>>>>> every 15 seconds. This should be optimized and the amount of >>>>>>> data >>>>>>> requested should be more specific. >>>>>>> >>>>>>> For each VM the data currently contains much more information >>>>>>> than >>>>>>> actually needed which blows up the size of the XML content >>>>>>> quite >>>>>>> big. We could optimize this by splitting the reply on the >>>>>>> getVmStats >>>>>>> based on the request of the engine into sections. For this >>>>>>> reason >>>>>>> Omer Frenkel and me have split up the data into parts based on >>>>>>> their >>>>>>> usage. >>>>>>> >>>>>>> This data can and usually does change during the lifetime of >>>>>>> the >>>>>>> VM. >>>>>>> Rarely Changed: >>>>>>> >>>>>>> >>>>>>> This data is change not very frequent and it should be enough >>>>>>> to >>>>>>> update this only once in a while. Most commonly this data >>>>>>> changes >>>>>>> after changes made in the UI or after a migration of the VM to >>>>>>> another Host. Status = Running acpiEnable = true vmType = kvm >>>>>>> guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 >>>>>>> kvmEnable = true # this should be constant and never changed >>>>>>> pauseCode = NOERR monitorResponse = 0 session = Locked # unused >>>>>>> netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', >>>>>>> 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': >>>>>>> ['10.34.60.148'], >>>>>>> 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', >>>>>>> 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 >>>>>>> 3.2.2', >>>>>>> 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 >>>>>>> 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', 'RHEV-USB >>>>>>> 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = >>>>>>> 11314 >>>>>>> guestIPs = 10.34.60.148 # duplicated info displayIp = 0 >>>>>>> displayPort >>>>>>> = 5902 displaySecurePort = 5903 username = user at W864GUESTAGENTT >>>>>>> clientIp = lastLogin = 1361976900.67 Often Changed: >>>>>>> >>>>>>> >>>>>>> This data is changed quite often however it is not necessary to >>>>>>> update this data every 15 seconds. As this is cumulative data >>>>>>> and >>>>>>> reflects the current status, and it does not need to be >>>>>>> snapshotted >>>>>>> every 15 seconds to retrieve statistics. The data can be >>>>>>> retrieved >>>>>>> in much more generous time slices. (e.g. Every 5 minutes) >>>>>>> network >>>>>>> = >>>>>>> {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', >>>>>>> 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': >>>>>>> '0.0', >>>>>>> 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': >>>>>>> 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': >>>>>>> '64055406592', >>>>>>> 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', 'total': >>>>>>> '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset = >>>>>>> 14422 >>>>>>> elapsedTime = 68591 hash = 2335461227228498964 statsAge = 0.09 >>>>>>> # >>>>>>> unused Often Changed but unused >>>>>>> >>>>>>> >>>>>>> This data does not seem to be used in the engine at all. It is >>>>>>> not >>>>>>> even used in the data warehouse. memoryStats = {'swap_out': >>>>>>> '0', >>>>>>> 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', >>>>>>> 'pageflt': >>>>>>> '0', 'mem_total': '2096736', 'mem_unused': '1466884'} >>>>>>> balloonInfo >>>>>>> = >>>>>>> {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = >>>>>>> {'vda': >>>>>>> {'readLatency': '0', 'apparentsize': '64424509440', >>>>>>> 'writeLatency': >>>>>>> '1754496', 'imageID': '28abb923-7b89-4638-84f8-1700f0b76482', >>>>>>> 'flushLatency': '156549', 'readRate': '0.00', 'truesize': >>>>>>> '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': >>>>>>> '0', >>>>>>> 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': '0', >>>>>>> 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} Very >>>>>>> frequent uppdates needed by webadmin portal: >>>>>>> >>>>>>> >>>>>>> This data is mostly needed for the webadmin portal and might be >>>>>>> required to be updated quite often. An exception here is the >>>>>>> statsAge field, which seems to be unused by the Engine. This >>>>>>> data >>>>>>> could be requested every 15 seconds to keep things as they are >>>>>>> now. >>>>>>> cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution >>>>>>> for >>>>>>> VDSM & Engine: >>>>>>> >>>>>>> >>>>>>> We will introduce new optional parameters to getVmStats, >>>>>>> getAllVmStats and list to allow a finer grained specification >>>>>>> of >>>>>>> data which should be included. >>>>>>> >>>>>>> Parameter: statsType = (getVmStats, getAllVmStats >>>>>>> only) >>>>>>> Allowed values: >>>>>>> >>>>>>> * full (default to keep backwards compatibility) >>>>>>> * app-list (Just send the application list) >>>>>>> * rare (include everything from rarely changed to very >>>>>>> frequent) >>>>>>> * often (include everything from often changed to very >>>>>>> frequent) >>>>>>> * frequent (only send the very frequently changed items) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Parameter: clientId = The client id is specified by >>>>>>> the >>>>>>> client and should be unique however constantly used. >>>>>>> >>>>>>> Parameter: diff = In combination with the clientId >>>>>>> VDSM >>>>>>> will send only differences to the previous request from the >>>>>>> named >>>>>>> clientId. (if diff=true) >>>>>>> >>>>>>> >>>>>>> Additional Change: >>>>>>> >>>>>>> >>>>>>> Besides the introduction of the new parameters for list, >>>>>>> getVmStats >>>>>>> and getAllVmStats it might make sense to include a hash for the >>>>>>> appList into the rarely changed section of the response which >>>>>>> would >>>>>>> allow to identify changes and avoid having to sent the complete >>>>>>> appList every so often and only if the hash known to the client >>>>>>> is >>>>>>> outdated. >>>>>>> >>>>>>> Note: The appList (Application List) reported by the guest >>>>>>> agent >>>>>>> could be fully implemented on request only, as long as the >>>>>>> guest >>>>>>> agent installed supports this. As there seems to be a request >>>>>>> to >>>>>>> have the complete list of installed applications on all guests >>>>>>> this >>>>>>> data could be quite extensive and a huge list. On the other >>>>>>> hand >>>>>>> this data is only rarely visible and therefore it should not be >>>>>>> requested all the time and only on demand. Improvement of the >>>>>>> Guest >>>>>>> Agent: >>>>>>> >>>>>>> >>>>>>> As part of the proposed solution it is necessary to improve the >>>>>>> guest >>>>>>> agent as well. For the full application list there should be >>>>>>> implemented a caching system which will be fully reactive and >>>>>>> should >>>>>>> not poll the application list for example all the time. The >>>>>>> guest >>>>>>> can create a prepared data file containing all data in the JSON >>>>>>> format (as used for the communication with VDSM via VIO) and >>>>>>> just >>>>>>> have to read that file from disk and directly sends it to VDSM. >>>>>>> However it is quite possible that this list is to big and it >>>>>>> might >>>>>>> have to be chunked into pieces. (Multiple messages, which would >>>>>>> have >>>>>>> to be supported by VDSM then as well) The solution for this is >>>>>>> to >>>>>>> make VDSM request this data and it will retrieve the data >>>>>>> necessary >>>>>>> on request only. -- >>>>>>> Regards, >>>>>>> >>>>>>> Vinzenz Feenstra | Senior Software Engineer >>>>>>> RedHat Engineering Virtualization R & D >>>>>>> Phone: +420 532 294 625 >>>>>>> IRC: vfeenstr or evilissimo >>>>>>> >>>>>>> Better technology. Faster innovation. Powered by community >>>>>>> collaboration. >>>>>>> See how it works at redhat.com >>>>>>> _______________________________________________ >>>>>>> Engine-devel mailing list >>>>>>> Engine-devel at ovirt.org >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>> >>>>>> _______________________________________________ >>>>>> vdsm-devel mailing list >>>>>> vdsm-devel at lists.fedorahosted.org >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >>>>>> >>> _______________________________________________ >>> vdsm-devel mailing list >>> vdsm-devel at lists.fedorahosted.org >>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >>> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From yzaslavs at redhat.com Sun Mar 17 14:11:14 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Sun, 17 Mar 2013 10:11:14 -0400 (EDT) Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <744223384.9185834.1363525989695.JavaMail.root@redhat.com> Message-ID: <973080706.8620230.1363529474975.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ayal Baron" > To: "Itamar Heim" > Cc: engine-devel at ovirt.org, vdsm-devel at lists.fedorahosted.org > Sent: Sunday, March 17, 2013 3:13:09 PM > Subject: Re: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization > > > > ----- Original Message ----- > > On 03/13/2013 11:55 PM, Ayal Baron wrote: > > ... > > >>>> The only reason we have this problem is because there is this > > >>>> thing against making multiple calls. > > >>>> > > >>>> Just split it up. > > >>>> getVmRuntimeStats() - transient things like mem and cpu% > > >>>> getVmInformation() - (semi)static things like disk\networking > > >>>> layout > > >>>> etc. > > >>>> Each updated at different intervals. > > >>> > > >>> +1 on splitting the data up into 2 separate API calls. > > >>> You could potentially add a checksum (md5, or any other way) of > > >>> the > > >>> "static" data to getVmRuntimeStats and not bother even with > > >>> polling > > >>> the VmInformation if this hasn't changed. Then you could poll > > >>> as > > >>> often as you'd like the stats and immediately see if you also > > >>> need > > >>> to retrieve VmInfo or not (you rarely would). > > >> +1 To Ayal's suggestion > > >> except that instead of the engine hashing the data VDSM sends > > >> the > > >> key which is opaque to the engine. > > >> This can be a local timestap or a generation number. > > > > > > Of course vdsm does the hash, otherwise you'd need to pass all > > > the > > > data to engine which would beat the purpose. > > > > I thought you meant engine will be sending the hash of previous > > requests > > per VM to vdsm, then vdsm will reply back with vm's removed, vm's > > added, > > and the details for vm's that changed (i.e., engine would be doing > > something like if-modified-since-checksum per vm). > > benefit is reducing a round trip. > > but first would need to split to calls of stats (always changing) > > and > > slowly/never changing data. > > If vdms accepts the hash then in your method engine would have to > periodically call getVmInfo(hash). > What I was suggesting is that getVmStats would return vmInfo hash so > that we could avoid calling getVmInfo altogether. > The stats *always* change so there is no need for checking if that > info has changed. > What we could do is avoid the split into 2 verbs by calling > getVmStats(hash) and then have getVmStats return everything if the > hash has changed or only the stats if it hasn't. This would be the > least number of roundtrips and avoid the split. If you don't pass a > hash it would return everything so this way it's also fully backward > compatible. Actually, I assume we can pass hash 0 (to have vdsm return "everything"). I assume that the chances for md5 on "real data" (i.e - real data that is known to engine) to be 0 are very slim. > > > > > > > > >> > > >> But, we might want to consider that when we add events polling > > >> becomes (much) less frequent so maybe it'll be an overkill. > > > > > > You'd still need to compare versions of the data in vdsm and send > > > only if it changed. If you don't persist what was received last > > > then potentially you could have a monday morning effect where > > > upon > > > on system startup you'd be sending everything. So I still think > > > you'd want to have the hash. > > > > > > > > >> > > >>> > > >>>> > > >>>> ----- Original Message ----- > > >>>>> From: "Vinzenz Feenstra" > > >>>>> To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org > > >>>>> Sent: Thursday, March 7, 2013 6:25:54 AM > > >>>>> Subject: [Engine-devel] Proposal VDSM <=> Engine Data > > >>>>> Statistics > > >>>>> Retrieval Optimization > > >>>>> > > >>>>> > > >>>>> Please find the prettier version on the wiki: > > >>>>> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > > >>>>> > > >>>>> Proposal VDSM - Engine Data Statistics Retrieval > > >>>>> VDSM <=> Engine data retrieval optimization > > >>>>> Motivation: > > >>>>> > > >>>>> > > >>>>> Currently the RHEVM engine is polling the a lot of data from > > >>>>> VDSM > > >>>>> every 15 seconds. This should be optimized and the amount of > > >>>>> data > > >>>>> requested should be more specific. > > >>>>> > > >>>>> For each VM the data currently contains much more information > > >>>>> than > > >>>>> actually needed which blows up the size of the XML content > > >>>>> quite > > >>>>> big. We could optimize this by splitting the reply on the > > >>>>> getVmStats > > >>>>> based on the request of the engine into sections. For this > > >>>>> reason > > >>>>> Omer Frenkel and me have split up the data into parts based > > >>>>> on > > >>>>> their > > >>>>> usage. > > >>>>> > > >>>>> This data can and usually does change during the lifetime of > > >>>>> the > > >>>>> VM. > > >>>>> Rarely Changed: > > >>>>> > > >>>>> > > >>>>> This data is change not very frequent and it should be enough > > >>>>> to > > >>>>> update this only once in a while. Most commonly this data > > >>>>> changes > > >>>>> after changes made in the UI or after a migration of the VM > > >>>>> to > > >>>>> another Host. Status = Running acpiEnable = true vmType = kvm > > >>>>> guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 > > >>>>> kvmEnable = true # this should be constant and never changed > > >>>>> pauseCode = NOERR monitorResponse = 0 session = Locked # > > >>>>> unused > > >>>>> netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', > > >>>>> 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': > > >>>>> ['10.34.60.148'], > > >>>>> 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', > > >>>>> 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 > > >>>>> 3.2.2', > > >>>>> 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 > > >>>>> 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', > > >>>>> 'RHEV-USB > > >>>>> 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = > > >>>>> 11314 > > >>>>> guestIPs = 10.34.60.148 # duplicated info displayIp = 0 > > >>>>> displayPort > > >>>>> = 5902 displaySecurePort = 5903 username = > > >>>>> user at W864GUESTAGENTT > > >>>>> clientIp = lastLogin = 1361976900.67 Often Changed: > > >>>>> > > >>>>> > > >>>>> This data is changed quite often however it is not necessary > > >>>>> to > > >>>>> update this data every 15 seconds. As this is cumulative data > > >>>>> and > > >>>>> reflects the current status, and it does not need to be > > >>>>> snapshotted > > >>>>> every 15 seconds to retrieve statistics. The data can be > > >>>>> retrieved > > >>>>> in much more generous time slices. (e.g. Every 5 minutes) > > >>>>> network > > >>>>> = > > >>>>> {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', > > >>>>> 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': > > >>>>> '0.0', > > >>>>> 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': > > >>>>> 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': > > >>>>> '64055406592', > > >>>>> 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', > > >>>>> 'total': > > >>>>> '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset > > >>>>> = > > >>>>> 14422 > > >>>>> elapsedTime = 68591 hash = 2335461227228498964 statsAge = > > >>>>> 0.09 > > >>>>> # > > >>>>> unused Often Changed but unused > > >>>>> > > >>>>> > > >>>>> This data does not seem to be used in the engine at all. It > > >>>>> is > > >>>>> not > > >>>>> even used in the data warehouse. memoryStats = {'swap_out': > > >>>>> '0', > > >>>>> 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', > > >>>>> 'pageflt': > > >>>>> '0', 'mem_total': '2096736', 'mem_unused': '1466884'} > > >>>>> balloonInfo > > >>>>> = > > >>>>> {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = > > >>>>> {'vda': > > >>>>> {'readLatency': '0', 'apparentsize': '64424509440', > > >>>>> 'writeLatency': > > >>>>> '1754496', 'imageID': > > >>>>> '28abb923-7b89-4638-84f8-1700f0b76482', > > >>>>> 'flushLatency': '156549', 'readRate': '0.00', 'truesize': > > >>>>> '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': > > >>>>> '0', > > >>>>> 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': > > >>>>> '0', > > >>>>> 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} > > >>>>> Very > > >>>>> frequent uppdates needed by webadmin portal: > > >>>>> > > >>>>> > > >>>>> This data is mostly needed for the webadmin portal and might > > >>>>> be > > >>>>> required to be updated quite often. An exception here is the > > >>>>> statsAge field, which seems to be unused by the Engine. This > > >>>>> data > > >>>>> could be requested every 15 seconds to keep things as they > > >>>>> are > > >>>>> now. > > >>>>> cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution > > >>>>> for > > >>>>> VDSM & Engine: > > >>>>> > > >>>>> > > >>>>> We will introduce new optional parameters to getVmStats, > > >>>>> getAllVmStats and list to allow a finer grained specification > > >>>>> of > > >>>>> data which should be included. > > >>>>> > > >>>>> Parameter: statsType = (getVmStats, getAllVmStats > > >>>>> only) > > >>>>> Allowed values: > > >>>>> > > >>>>> * full (default to keep backwards compatibility) > > >>>>> * app-list (Just send the application list) > > >>>>> * rare (include everything from rarely changed to very > > >>>>> frequent) > > >>>>> * often (include everything from often changed to very > > >>>>> frequent) > > >>>>> * frequent (only send the very frequently changed items) > > >>>>> > > >>>>> > > >>>>> > > >>>>> Parameter: clientId = The client id is specified by > > >>>>> the > > >>>>> client and should be unique however constantly used. > > >>>>> > > >>>>> Parameter: diff = In combination with the clientId > > >>>>> VDSM > > >>>>> will send only differences to the previous request from the > > >>>>> named > > >>>>> clientId. (if diff=true) > > >>>>> > > >>>>> > > >>>>> Additional Change: > > >>>>> > > >>>>> > > >>>>> Besides the introduction of the new parameters for list, > > >>>>> getVmStats > > >>>>> and getAllVmStats it might make sense to include a hash for > > >>>>> the > > >>>>> appList into the rarely changed section of the response which > > >>>>> would > > >>>>> allow to identify changes and avoid having to sent the > > >>>>> complete > > >>>>> appList every so often and only if the hash known to the > > >>>>> client > > >>>>> is > > >>>>> outdated. > > >>>>> > > >>>>> Note: The appList (Application List) reported by the guest > > >>>>> agent > > >>>>> could be fully implemented on request only, as long as the > > >>>>> guest > > >>>>> agent installed supports this. As there seems to be a request > > >>>>> to > > >>>>> have the complete list of installed applications on all > > >>>>> guests > > >>>>> this > > >>>>> data could be quite extensive and a huge list. On the other > > >>>>> hand > > >>>>> this data is only rarely visible and therefore it should not > > >>>>> be > > >>>>> requested all the time and only on demand. Improvement of the > > >>>>> Guest > > >>>>> Agent: > > >>>>> > > >>>>> > > >>>>> As part of the proposed solution it is necessary to improve > > >>>>> the > > >>>>> guest > > >>>>> agent as well. For the full application list there should be > > >>>>> implemented a caching system which will be fully reactive and > > >>>>> should > > >>>>> not poll the application list for example all the time. The > > >>>>> guest > > >>>>> can create a prepared data file containing all data in the > > >>>>> JSON > > >>>>> format (as used for the communication with VDSM via VIO) and > > >>>>> just > > >>>>> have to read that file from disk and directly sends it to > > >>>>> VDSM. > > >>>>> However it is quite possible that this list is to big and it > > >>>>> might > > >>>>> have to be chunked into pieces. (Multiple messages, which > > >>>>> would > > >>>>> have > > >>>>> to be supported by VDSM then as well) The solution for this > > >>>>> is > > >>>>> to > > >>>>> make VDSM request this data and it will retrieve the data > > >>>>> necessary > > >>>>> on request only. -- > > >>>>> Regards, > > >>>>> > > >>>>> Vinzenz Feenstra | Senior Software Engineer > > >>>>> RedHat Engineering Virtualization R & D > > >>>>> Phone: +420 532 294 625 > > >>>>> IRC: vfeenstr or evilissimo > > >>>>> > > >>>>> Better technology. Faster innovation. Powered by community > > >>>>> collaboration. > > >>>>> See how it works at redhat.com > > >>>>> _______________________________________________ > > >>>>> Engine-devel mailing list > > >>>>> Engine-devel at ovirt.org > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>>>> > > >>>> _______________________________________________ > > >>>> vdsm-devel mailing list > > >>>> vdsm-devel at lists.fedorahosted.org > > >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > >>>> > > >>> > > >> > > > _______________________________________________ > > > vdsm-devel mailing list > > > vdsm-devel at lists.fedorahosted.org > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From abaron at redhat.com Sun Mar 17 14:12:55 2013 From: abaron at redhat.com (Ayal Baron) Date: Sun, 17 Mar 2013 10:12:55 -0400 (EDT) Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. In-Reply-To: <513D9EFD.7000305@linux.vnet.ibm.com> Message-ID: <819999290.9188868.1363529575167.JavaMail.root@redhat.com> ----- Original Message ----- > > Hi guys, > > Currently, ISO domain is only supported on NFS storage. It could > improve the ease of use if it allows other types > of file based storage to store ISO images. After an investigation, I > found there's not any restriction on this idea. > So the whole work is removing the limitation on engine side. That > means engine should allow ISO domain could > have different storage type from the data center it's attached, like > what we do with nfs ISO domain in SAN DC. > > I start this idea with localfs. I know local storage can't be seen in > cluster level. But it also provides a choice if no > NFS available. VMs can be created on the host which has the ISO repo, > and then be migrated to any other host in the cluster. > I have done the initial patches: allow creation ISO domain on localfs > [1] and support import ISO domain on localfs [2] > I don't have much experience in java/j2ee/web development and engine > architecture. The patches just work for me. > I am not sure if it will bring some potential problems. So any > feedback on the patch or the idea will be appreciated very much. Haven't looked at the patches yet, but wrt the idea, I agree on the need (being able to attach ISOs from anywhere and not just nfs) but I think the way to do this should be by getting rid of the ISO domain type altogether. Basically what we need is: 1. a way to connect to file based storage (let's leave block aside for now) - this already exists via the connectStorageServer verb 2. a way to list and present a file system tree in gui (give an arbitrary path to vdsm and list content) and possibly filter results by type (vfd, iso) - does not exist today. Possibly some security aspects here that need hashing out. 3. a way to specify a path to a file when attaching an iso/vfd to a VM - this is the way it works today This would devoid the need for isoUploader and allow users to simply manage an nfs export with files. Next step would be to make connectStorageServer support httpfs [1] and then we'd be able to mount ISOs directly over http (hopefully this would be sufficient to support ISOs stored on S3, swift, glance, etc). [1] http://httpfs.sourceforge.net/ > > > Mark. > > [1] http://gerrit.ovirt.org/#/c/12687/ > [2] http://gerrit.ovirt.org/#/c/12916/ > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From abaron at redhat.com Sun Mar 17 14:28:15 2013 From: abaron at redhat.com (Ayal Baron) Date: Sun, 17 Mar 2013 10:28:15 -0400 (EDT) Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <5145C765.9020602@redhat.com> Message-ID: <113426756.9189427.1363530495950.JavaMail.root@redhat.com> ----- Original Message ----- > On 17/03/13 15:13, Ayal Baron wrote: > > > > ----- Original Message ----- > >> On 03/13/2013 11:55 PM, Ayal Baron wrote: > >> ... > >>>>>> The only reason we have this problem is because there is this > >>>>>> thing against making multiple calls. > >>>>>> > >>>>>> Just split it up. > >>>>>> getVmRuntimeStats() - transient things like mem and cpu% > >>>>>> getVmInformation() - (semi)static things like disk\networking > >>>>>> layout > >>>>>> etc. > >>>>>> Each updated at different intervals. > >>>>> +1 on splitting the data up into 2 separate API calls. > >>>>> You could potentially add a checksum (md5, or any other way) of > >>>>> the > >>>>> "static" data to getVmRuntimeStats and not bother even with > >>>>> polling > >>>>> the VmInformation if this hasn't changed. Then you could poll > >>>>> as > >>>>> often as you'd like the stats and immediately see if you also > >>>>> need > >>>>> to retrieve VmInfo or not (you rarely would). > >>>> +1 To Ayal's suggestion > >>>> except that instead of the engine hashing the data VDSM sends > >>>> the > >>>> key which is opaque to the engine. > >>>> This can be a local timestap or a generation number. > >>> Of course vdsm does the hash, otherwise you'd need to pass all > >>> the > >>> data to engine which would beat the purpose. > >> I thought you meant engine will be sending the hash of previous > >> requests > >> per VM to vdsm, then vdsm will reply back with vm's removed, vm's > >> added, > >> and the details for vm's that changed (i.e., engine would be doing > >> something like if-modified-since-checksum per vm). > >> benefit is reducing a round trip. > >> but first would need to split to calls of stats (always changing) > >> and > >> slowly/never changing data. > > If vdms accepts the hash then in your method engine would have to > > periodically call getVmInfo(hash). > > What I was suggesting is that getVmStats would return vmInfo hash > > so that we could avoid calling getVmInfo altogether. > > The stats *always* change so there is no need for checking if that > > info has changed. > > What we could do is avoid the split into 2 verbs by calling > > getVmStats(hash) and then have getVmStats return everything if the > > hash has changed or only the stats if it hasn't. This would be > > the least number of roundtrips and avoid the split. If you don't > > pass a hash it would return everything so this way it's also fully > > backward compatible. > > For the 'static' data, why is there a need for a hash? > If VDSM sends in each update a timestamp, can't RHEVM just use > if-modified-since with the last timestamp it got from VDSM? > Is it cheaper for VDSM to calculate the hash, than update the > timestamp > per change in any of the fields? It doesn't really need to update the > timestamp per change, only for the first change since last update > sent > actually (so 'dirty' flag in a way, to signify data that RHEVM hasn't > seen yet). > Y. As Saggi mentioned: "VDSM sends the key which is opaque to the engine. This can be a local timestap or a generation number." The content doesn't matter, what matters is that it has changed. timestamp assumes that vdsm will track changes and send only delta. Although possible this would be an overkill (for every value in the dict you'd have to hold a timestamp of last change and send only those which have changed since the timestamp which was passed by the user). Either way, I don't care what the 'hash' is, the point was that there is a simple way to keep a single API call, keep BC and toggle returning all data or just statistics (data that changes frequently) since last time user checked while minimizing API calls. > > > > >>>> But, we might want to consider that when we add events polling > >>>> becomes (much) less frequent so maybe it'll be an overkill. > >>> You'd still need to compare versions of the data in vdsm and send > >>> only if it changed. If you don't persist what was received last > >>> then potentially you could have a monday morning effect where > >>> upon > >>> on system startup you'd be sending everything. So I still think > >>> you'd want to have the hash. > >>> > >>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Vinzenz Feenstra" > >>>>>>> To: vdsm-devel at lists.fedorahosted.org, engine-devel at ovirt.org > >>>>>>> Sent: Thursday, March 7, 2013 6:25:54 AM > >>>>>>> Subject: [Engine-devel] Proposal VDSM <=> Engine Data > >>>>>>> Statistics > >>>>>>> Retrieval Optimization > >>>>>>> > >>>>>>> > >>>>>>> Please find the prettier version on the wiki: > >>>>>>> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > >>>>>>> > >>>>>>> Proposal VDSM - Engine Data Statistics Retrieval > >>>>>>> VDSM <=> Engine data retrieval optimization > >>>>>>> Motivation: > >>>>>>> > >>>>>>> > >>>>>>> Currently the RHEVM engine is polling the a lot of data from > >>>>>>> VDSM > >>>>>>> every 15 seconds. This should be optimized and the amount of > >>>>>>> data > >>>>>>> requested should be more specific. > >>>>>>> > >>>>>>> For each VM the data currently contains much more information > >>>>>>> than > >>>>>>> actually needed which blows up the size of the XML content > >>>>>>> quite > >>>>>>> big. We could optimize this by splitting the reply on the > >>>>>>> getVmStats > >>>>>>> based on the request of the engine into sections. For this > >>>>>>> reason > >>>>>>> Omer Frenkel and me have split up the data into parts based > >>>>>>> on > >>>>>>> their > >>>>>>> usage. > >>>>>>> > >>>>>>> This data can and usually does change during the lifetime of > >>>>>>> the > >>>>>>> VM. > >>>>>>> Rarely Changed: > >>>>>>> > >>>>>>> > >>>>>>> This data is change not very frequent and it should be enough > >>>>>>> to > >>>>>>> update this only once in a while. Most commonly this data > >>>>>>> changes > >>>>>>> after changes made in the UI or after a migration of the VM > >>>>>>> to > >>>>>>> another Host. Status = Running acpiEnable = true vmType = kvm > >>>>>>> guestName = W864GUESTAGENTT displayType = qxl guestOs = Win 8 > >>>>>>> kvmEnable = true # this should be constant and never changed > >>>>>>> pauseCode = NOERR monitorResponse = 0 session = Locked # > >>>>>>> unused > >>>>>>> netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet NIC', > >>>>>>> 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': > >>>>>>> ['10.34.60.148'], > >>>>>>> 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', > >>>>>>> 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', 'RHEV-Network64 > >>>>>>> 3.2.2', > >>>>>>> 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', 'RHEV-Balloon64 > >>>>>>> 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', > >>>>>>> 'RHEV-USB > >>>>>>> 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = > >>>>>>> 11314 > >>>>>>> guestIPs = 10.34.60.148 # duplicated info displayIp = 0 > >>>>>>> displayPort > >>>>>>> = 5902 displaySecurePort = 5903 username = > >>>>>>> user at W864GUESTAGENTT > >>>>>>> clientIp = lastLogin = 1361976900.67 Often Changed: > >>>>>>> > >>>>>>> > >>>>>>> This data is changed quite often however it is not necessary > >>>>>>> to > >>>>>>> update this data every 15 seconds. As this is cumulative data > >>>>>>> and > >>>>>>> reflects the current status, and it does not need to be > >>>>>>> snapshotted > >>>>>>> every 15 seconds to retrieve statistics. The data can be > >>>>>>> retrieved > >>>>>>> in much more generous time slices. (e.g. Every 5 minutes) > >>>>>>> network > >>>>>>> = > >>>>>>> {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': '0', > >>>>>>> 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', 'rxRate': > >>>>>>> '0.0', > >>>>>>> 'txErrors': '0', 'state': 'unknown', 'speed': '100', 'name': > >>>>>>> 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': > >>>>>>> '64055406592', > >>>>>>> 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', > >>>>>>> 'total': > >>>>>>> '3490912256', 'fs': 'UDF', 'used': '3490912256'}] timeOffset > >>>>>>> = > >>>>>>> 14422 > >>>>>>> elapsedTime = 68591 hash = 2335461227228498964 statsAge = > >>>>>>> 0.09 > >>>>>>> # > >>>>>>> unused Often Changed but unused > >>>>>>> > >>>>>>> > >>>>>>> This data does not seem to be used in the engine at all. It > >>>>>>> is > >>>>>>> not > >>>>>>> even used in the data warehouse. memoryStats = {'swap_out': > >>>>>>> '0', > >>>>>>> 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', > >>>>>>> 'pageflt': > >>>>>>> '0', 'mem_total': '2096736', 'mem_unused': '1466884'} > >>>>>>> balloonInfo > >>>>>>> = > >>>>>>> {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = > >>>>>>> {'vda': > >>>>>>> {'readLatency': '0', 'apparentsize': '64424509440', > >>>>>>> 'writeLatency': > >>>>>>> '1754496', 'imageID': > >>>>>>> '28abb923-7b89-4638-84f8-1700f0b76482', > >>>>>>> 'flushLatency': '156549', 'readRate': '0.00', 'truesize': > >>>>>>> '18855059456', 'writeRate': '952.05'}, 'hdc': {'readLatency': > >>>>>>> '0', > >>>>>>> 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': > >>>>>>> '0', > >>>>>>> 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} > >>>>>>> Very > >>>>>>> frequent uppdates needed by webadmin portal: > >>>>>>> > >>>>>>> > >>>>>>> This data is mostly needed for the webadmin portal and might > >>>>>>> be > >>>>>>> required to be updated quite often. An exception here is the > >>>>>>> statsAge field, which seems to be unused by the Engine. This > >>>>>>> data > >>>>>>> could be requested every 15 seconds to keep things as they > >>>>>>> are > >>>>>>> now. > >>>>>>> cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed Solution > >>>>>>> for > >>>>>>> VDSM & Engine: > >>>>>>> > >>>>>>> > >>>>>>> We will introduce new optional parameters to getVmStats, > >>>>>>> getAllVmStats and list to allow a finer grained specification > >>>>>>> of > >>>>>>> data which should be included. > >>>>>>> > >>>>>>> Parameter: statsType = (getVmStats, getAllVmStats > >>>>>>> only) > >>>>>>> Allowed values: > >>>>>>> > >>>>>>> * full (default to keep backwards compatibility) > >>>>>>> * app-list (Just send the application list) > >>>>>>> * rare (include everything from rarely changed to very > >>>>>>> frequent) > >>>>>>> * often (include everything from often changed to very > >>>>>>> frequent) > >>>>>>> * frequent (only send the very frequently changed > >>>>>>> items) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Parameter: clientId = The client id is specified by > >>>>>>> the > >>>>>>> client and should be unique however constantly used. > >>>>>>> > >>>>>>> Parameter: diff = In combination with the clientId > >>>>>>> VDSM > >>>>>>> will send only differences to the previous request from the > >>>>>>> named > >>>>>>> clientId. (if diff=true) > >>>>>>> > >>>>>>> > >>>>>>> Additional Change: > >>>>>>> > >>>>>>> > >>>>>>> Besides the introduction of the new parameters for list, > >>>>>>> getVmStats > >>>>>>> and getAllVmStats it might make sense to include a hash for > >>>>>>> the > >>>>>>> appList into the rarely changed section of the response which > >>>>>>> would > >>>>>>> allow to identify changes and avoid having to sent the > >>>>>>> complete > >>>>>>> appList every so often and only if the hash known to the > >>>>>>> client > >>>>>>> is > >>>>>>> outdated. > >>>>>>> > >>>>>>> Note: The appList (Application List) reported by the guest > >>>>>>> agent > >>>>>>> could be fully implemented on request only, as long as the > >>>>>>> guest > >>>>>>> agent installed supports this. As there seems to be a request > >>>>>>> to > >>>>>>> have the complete list of installed applications on all > >>>>>>> guests > >>>>>>> this > >>>>>>> data could be quite extensive and a huge list. On the other > >>>>>>> hand > >>>>>>> this data is only rarely visible and therefore it should not > >>>>>>> be > >>>>>>> requested all the time and only on demand. Improvement of the > >>>>>>> Guest > >>>>>>> Agent: > >>>>>>> > >>>>>>> > >>>>>>> As part of the proposed solution it is necessary to improve > >>>>>>> the > >>>>>>> guest > >>>>>>> agent as well. For the full application list there should be > >>>>>>> implemented a caching system which will be fully reactive and > >>>>>>> should > >>>>>>> not poll the application list for example all the time. The > >>>>>>> guest > >>>>>>> can create a prepared data file containing all data in the > >>>>>>> JSON > >>>>>>> format (as used for the communication with VDSM via VIO) and > >>>>>>> just > >>>>>>> have to read that file from disk and directly sends it to > >>>>>>> VDSM. > >>>>>>> However it is quite possible that this list is to big and it > >>>>>>> might > >>>>>>> have to be chunked into pieces. (Multiple messages, which > >>>>>>> would > >>>>>>> have > >>>>>>> to be supported by VDSM then as well) The solution for this > >>>>>>> is > >>>>>>> to > >>>>>>> make VDSM request this data and it will retrieve the data > >>>>>>> necessary > >>>>>>> on request only. -- > >>>>>>> Regards, > >>>>>>> > >>>>>>> Vinzenz Feenstra | Senior Software Engineer > >>>>>>> RedHat Engineering Virtualization R & D > >>>>>>> Phone: +420 532 294 625 > >>>>>>> IRC: vfeenstr or evilissimo > >>>>>>> > >>>>>>> Better technology. Faster innovation. Powered by community > >>>>>>> collaboration. > >>>>>>> See how it works at redhat.com > >>>>>>> _______________________________________________ > >>>>>>> Engine-devel mailing list > >>>>>>> Engine-devel at ovirt.org > >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> vdsm-devel mailing list > >>>>>> vdsm-devel at lists.fedorahosted.org > >>>>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >>>>>> > >>> _______________________________________________ > >>> vdsm-devel mailing list > >>> vdsm-devel at lists.fedorahosted.org > >>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > >>> > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From abaron at redhat.com Sun Mar 17 14:29:18 2013 From: abaron at redhat.com (Ayal Baron) Date: Sun, 17 Mar 2013 10:29:18 -0400 (EDT) Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <973080706.8620230.1363529474975.JavaMail.root@redhat.com> Message-ID: <1104888652.9189452.1363530558465.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Ayal Baron" > > To: "Itamar Heim" > > Cc: engine-devel at ovirt.org, vdsm-devel at lists.fedorahosted.org > > Sent: Sunday, March 17, 2013 3:13:09 PM > > Subject: Re: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data > > Statistics Retrieval Optimization > > > > > > > > ----- Original Message ----- > > > On 03/13/2013 11:55 PM, Ayal Baron wrote: > > > ... > > > >>>> The only reason we have this problem is because there is > > > >>>> this > > > >>>> thing against making multiple calls. > > > >>>> > > > >>>> Just split it up. > > > >>>> getVmRuntimeStats() - transient things like mem and cpu% > > > >>>> getVmInformation() - (semi)static things like > > > >>>> disk\networking > > > >>>> layout > > > >>>> etc. > > > >>>> Each updated at different intervals. > > > >>> > > > >>> +1 on splitting the data up into 2 separate API calls. > > > >>> You could potentially add a checksum (md5, or any other way) > > > >>> of > > > >>> the > > > >>> "static" data to getVmRuntimeStats and not bother even with > > > >>> polling > > > >>> the VmInformation if this hasn't changed. Then you could > > > >>> poll > > > >>> as > > > >>> often as you'd like the stats and immediately see if you also > > > >>> need > > > >>> to retrieve VmInfo or not (you rarely would). > > > >> +1 To Ayal's suggestion > > > >> except that instead of the engine hashing the data VDSM sends > > > >> the > > > >> key which is opaque to the engine. > > > >> This can be a local timestap or a generation number. > > > > > > > > Of course vdsm does the hash, otherwise you'd need to pass all > > > > the > > > > data to engine which would beat the purpose. > > > > > > I thought you meant engine will be sending the hash of previous > > > requests > > > per VM to vdsm, then vdsm will reply back with vm's removed, vm's > > > added, > > > and the details for vm's that changed (i.e., engine would be > > > doing > > > something like if-modified-since-checksum per vm). > > > benefit is reducing a round trip. > > > but first would need to split to calls of stats (always changing) > > > and > > > slowly/never changing data. > > > > If vdms accepts the hash then in your method engine would have to > > periodically call getVmInfo(hash). > > What I was suggesting is that getVmStats would return vmInfo hash > > so > > that we could avoid calling getVmInfo altogether. > > The stats *always* change so there is no need for checking if that > > info has changed. > > What we could do is avoid the split into 2 verbs by calling > > getVmStats(hash) and then have getVmStats return everything if the > > hash has changed or only the stats if it hasn't. This would be the > > least number of roundtrips and avoid the split. If you don't pass > > a > > hash it would return everything so this way it's also fully > > backward > > compatible. > > Actually, I assume we can pass hash 0 (to have vdsm return > "everything"). I assume that the chances for md5 on "real data" (i.e > - > real data that is known to engine) to be 0 are very slim. We'd need to support hash=None to keep backward compatibility, plus there are no assumptions this way on hash algorithm so why bother with hash=0? > > > > > > > > > > > > > >> > > > >> But, we might want to consider that when we add events polling > > > >> becomes (much) less frequent so maybe it'll be an overkill. > > > > > > > > You'd still need to compare versions of the data in vdsm and > > > > send > > > > only if it changed. If you don't persist what was received > > > > last > > > > then potentially you could have a monday morning effect where > > > > upon > > > > on system startup you'd be sending everything. So I still > > > > think > > > > you'd want to have the hash. > > > > > > > > > > > >> > > > >>> > > > >>>> > > > >>>> ----- Original Message ----- > > > >>>>> From: "Vinzenz Feenstra" > > > >>>>> To: vdsm-devel at lists.fedorahosted.org, > > > >>>>> engine-devel at ovirt.org > > > >>>>> Sent: Thursday, March 7, 2013 6:25:54 AM > > > >>>>> Subject: [Engine-devel] Proposal VDSM <=> Engine Data > > > >>>>> Statistics > > > >>>>> Retrieval Optimization > > > >>>>> > > > >>>>> > > > >>>>> Please find the prettier version on the wiki: > > > >>>>> http://www.ovirt.org/Proposal_VDSM_-_Engine_Data_Statistics_Retrieval > > > >>>>> > > > >>>>> Proposal VDSM - Engine Data Statistics Retrieval > > > >>>>> VDSM <=> Engine data retrieval optimization > > > >>>>> Motivation: > > > >>>>> > > > >>>>> > > > >>>>> Currently the RHEVM engine is polling the a lot of data > > > >>>>> from > > > >>>>> VDSM > > > >>>>> every 15 seconds. This should be optimized and the amount > > > >>>>> of > > > >>>>> data > > > >>>>> requested should be more specific. > > > >>>>> > > > >>>>> For each VM the data currently contains much more > > > >>>>> information > > > >>>>> than > > > >>>>> actually needed which blows up the size of the XML content > > > >>>>> quite > > > >>>>> big. We could optimize this by splitting the reply on the > > > >>>>> getVmStats > > > >>>>> based on the request of the engine into sections. For this > > > >>>>> reason > > > >>>>> Omer Frenkel and me have split up the data into parts based > > > >>>>> on > > > >>>>> their > > > >>>>> usage. > > > >>>>> > > > >>>>> This data can and usually does change during the lifetime > > > >>>>> of > > > >>>>> the > > > >>>>> VM. > > > >>>>> Rarely Changed: > > > >>>>> > > > >>>>> > > > >>>>> This data is change not very frequent and it should be > > > >>>>> enough > > > >>>>> to > > > >>>>> update this only once in a while. Most commonly this data > > > >>>>> changes > > > >>>>> after changes made in the UI or after a migration of the VM > > > >>>>> to > > > >>>>> another Host. Status = Running acpiEnable = true vmType = > > > >>>>> kvm > > > >>>>> guestName = W864GUESTAGENTT displayType = qxl guestOs = Win > > > >>>>> 8 > > > >>>>> kvmEnable = true # this should be constant and never > > > >>>>> changed > > > >>>>> pauseCode = NOERR monitorResponse = 0 session = Locked # > > > >>>>> unused > > > >>>>> netIfaces = [{'name': 'Realtek RTL8139C+ Fast Ethernet > > > >>>>> NIC', > > > >>>>> 'inet6': ['fe80::490c:92bb:bbcc:9f87'], 'inet': > > > >>>>> ['10.34.60.148'], > > > >>>>> 'hw': '00:1a:4a:22:3c:db'}] appsList = ['RHEV-Tools 3.2.4', > > > >>>>> 'RHEV-Agent64 3.2.3', 'RHEV-Serial64 3.2.3', > > > >>>>> 'RHEV-Network64 > > > >>>>> 3.2.2', > > > >>>>> 'RHEV-Network64 3.2.3', 'RHEV-Block64 3.2.3', > > > >>>>> 'RHEV-Balloon64 > > > >>>>> 3.2.3', 'RHEV-Balloon64 3.2.2', 'RHEV-Agent64 3.2.2', > > > >>>>> 'RHEV-USB > > > >>>>> 3.2.3', 'RHEV-Block64 3.2.2', 'RHEV-Serial64 3.2.2'] pid = > > > >>>>> 11314 > > > >>>>> guestIPs = 10.34.60.148 # duplicated info displayIp = 0 > > > >>>>> displayPort > > > >>>>> = 5902 displaySecurePort = 5903 username = > > > >>>>> user at W864GUESTAGENTT > > > >>>>> clientIp = lastLogin = 1361976900.67 Often Changed: > > > >>>>> > > > >>>>> > > > >>>>> This data is changed quite often however it is not > > > >>>>> necessary > > > >>>>> to > > > >>>>> update this data every 15 seconds. As this is cumulative > > > >>>>> data > > > >>>>> and > > > >>>>> reflects the current status, and it does not need to be > > > >>>>> snapshotted > > > >>>>> every 15 seconds to retrieve statistics. The data can be > > > >>>>> retrieved > > > >>>>> in much more generous time slices. (e.g. Every 5 minutes) > > > >>>>> network > > > >>>>> = > > > >>>>> {'vnet1': {'macAddr': '00:1a:4a:22:3c:db', 'rxDropped': > > > >>>>> '0', > > > >>>>> 'txDropped': '0', 'rxErrors': '0', 'txRate': '0.0', > > > >>>>> 'rxRate': > > > >>>>> '0.0', > > > >>>>> 'txErrors': '0', 'state': 'unknown', 'speed': '100', > > > >>>>> 'name': > > > >>>>> 'vnet1'}} disksUsage = [{'path': 'c:\\', 'total': > > > >>>>> '64055406592', > > > >>>>> 'fs': 'NTFS', 'used': '19223846912'}, {'path': 'd:\\', > > > >>>>> 'total': > > > >>>>> '3490912256', 'fs': 'UDF', 'used': '3490912256'}] > > > >>>>> timeOffset > > > >>>>> = > > > >>>>> 14422 > > > >>>>> elapsedTime = 68591 hash = 2335461227228498964 statsAge = > > > >>>>> 0.09 > > > >>>>> # > > > >>>>> unused Often Changed but unused > > > >>>>> > > > >>>>> > > > >>>>> This data does not seem to be used in the engine at all. It > > > >>>>> is > > > >>>>> not > > > >>>>> even used in the data warehouse. memoryStats = {'swap_out': > > > >>>>> '0', > > > >>>>> 'majflt': '0', 'mem_free': '1466884', 'swap_in': '0', > > > >>>>> 'pageflt': > > > >>>>> '0', 'mem_total': '2096736', 'mem_unused': '1466884'} > > > >>>>> balloonInfo > > > >>>>> = > > > >>>>> {'balloon_max': 2097152, 'balloon_cur': 2097152} disks = > > > >>>>> {'vda': > > > >>>>> {'readLatency': '0', 'apparentsize': '64424509440', > > > >>>>> 'writeLatency': > > > >>>>> '1754496', 'imageID': > > > >>>>> '28abb923-7b89-4638-84f8-1700f0b76482', > > > >>>>> 'flushLatency': '156549', 'readRate': '0.00', 'truesize': > > > >>>>> '18855059456', 'writeRate': '952.05'}, 'hdc': > > > >>>>> {'readLatency': > > > >>>>> '0', > > > >>>>> 'apparentsize': '0', 'writeLatency': '0', 'flushLatency': > > > >>>>> '0', > > > >>>>> 'readRate': '0.00', 'truesize': '0', 'writeRate': '0.00'}} > > > >>>>> Very > > > >>>>> frequent uppdates needed by webadmin portal: > > > >>>>> > > > >>>>> > > > >>>>> This data is mostly needed for the webadmin portal and > > > >>>>> might > > > >>>>> be > > > >>>>> required to be updated quite often. An exception here is > > > >>>>> the > > > >>>>> statsAge field, which seems to be unused by the Engine. > > > >>>>> This > > > >>>>> data > > > >>>>> could be requested every 15 seconds to keep things as they > > > >>>>> are > > > >>>>> now. > > > >>>>> cpuSys = 2.32 cpuUser = 1.34 memUsage = 30 Proposed > > > >>>>> Solution > > > >>>>> for > > > >>>>> VDSM & Engine: > > > >>>>> > > > >>>>> > > > >>>>> We will introduce new optional parameters to getVmStats, > > > >>>>> getAllVmStats and list to allow a finer grained > > > >>>>> specification > > > >>>>> of > > > >>>>> data which should be included. > > > >>>>> > > > >>>>> Parameter: statsType = (getVmStats, getAllVmStats > > > >>>>> only) > > > >>>>> Allowed values: > > > >>>>> > > > >>>>> * full (default to keep backwards compatibility) > > > >>>>> * app-list (Just send the application list) > > > >>>>> * rare (include everything from rarely changed to very > > > >>>>> frequent) > > > >>>>> * often (include everything from often changed to very > > > >>>>> frequent) > > > >>>>> * frequent (only send the very frequently changed > > > >>>>> items) > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> Parameter: clientId = The client id is specified > > > >>>>> by > > > >>>>> the > > > >>>>> client and should be unique however constantly used. > > > >>>>> > > > >>>>> Parameter: diff = In combination with the > > > >>>>> clientId > > > >>>>> VDSM > > > >>>>> will send only differences to the previous request from the > > > >>>>> named > > > >>>>> clientId. (if diff=true) > > > >>>>> > > > >>>>> > > > >>>>> Additional Change: > > > >>>>> > > > >>>>> > > > >>>>> Besides the introduction of the new parameters for list, > > > >>>>> getVmStats > > > >>>>> and getAllVmStats it might make sense to include a hash for > > > >>>>> the > > > >>>>> appList into the rarely changed section of the response > > > >>>>> which > > > >>>>> would > > > >>>>> allow to identify changes and avoid having to sent the > > > >>>>> complete > > > >>>>> appList every so often and only if the hash known to the > > > >>>>> client > > > >>>>> is > > > >>>>> outdated. > > > >>>>> > > > >>>>> Note: The appList (Application List) reported by the guest > > > >>>>> agent > > > >>>>> could be fully implemented on request only, as long as the > > > >>>>> guest > > > >>>>> agent installed supports this. As there seems to be a > > > >>>>> request > > > >>>>> to > > > >>>>> have the complete list of installed applications on all > > > >>>>> guests > > > >>>>> this > > > >>>>> data could be quite extensive and a huge list. On the other > > > >>>>> hand > > > >>>>> this data is only rarely visible and therefore it should > > > >>>>> not > > > >>>>> be > > > >>>>> requested all the time and only on demand. Improvement of > > > >>>>> the > > > >>>>> Guest > > > >>>>> Agent: > > > >>>>> > > > >>>>> > > > >>>>> As part of the proposed solution it is necessary to improve > > > >>>>> the > > > >>>>> guest > > > >>>>> agent as well. For the full application list there should > > > >>>>> be > > > >>>>> implemented a caching system which will be fully reactive > > > >>>>> and > > > >>>>> should > > > >>>>> not poll the application list for example all the time. The > > > >>>>> guest > > > >>>>> can create a prepared data file containing all data in the > > > >>>>> JSON > > > >>>>> format (as used for the communication with VDSM via VIO) > > > >>>>> and > > > >>>>> just > > > >>>>> have to read that file from disk and directly sends it to > > > >>>>> VDSM. > > > >>>>> However it is quite possible that this list is to big and > > > >>>>> it > > > >>>>> might > > > >>>>> have to be chunked into pieces. (Multiple messages, which > > > >>>>> would > > > >>>>> have > > > >>>>> to be supported by VDSM then as well) The solution for this > > > >>>>> is > > > >>>>> to > > > >>>>> make VDSM request this data and it will retrieve the data > > > >>>>> necessary > > > >>>>> on request only. -- > > > >>>>> Regards, > > > >>>>> > > > >>>>> Vinzenz Feenstra | Senior Software Engineer > > > >>>>> RedHat Engineering Virtualization R & D > > > >>>>> Phone: +420 532 294 625 > > > >>>>> IRC: vfeenstr or evilissimo > > > >>>>> > > > >>>>> Better technology. Faster innovation. Powered by community > > > >>>>> collaboration. > > > >>>>> See how it works at redhat.com > > > >>>>> _______________________________________________ > > > >>>>> Engine-devel mailing list > > > >>>>> Engine-devel at ovirt.org > > > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > >>>>> > > > >>>> _______________________________________________ > > > >>>> vdsm-devel mailing list > > > >>>> vdsm-devel at lists.fedorahosted.org > > > >>>> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > >>>> > > > >>> > > > >> > > > > _______________________________________________ > > > > vdsm-devel mailing list > > > > vdsm-devel at lists.fedorahosted.org > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From danken at redhat.com Sun Mar 17 15:30:38 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Sun, 17 Mar 2013 17:30:38 +0200 Subject: [Engine-devel] [vdsm] Proposal VDSM <=> Engine Data Statistics Retrieval Optimization In-Reply-To: <113426756.9189427.1363530495950.JavaMail.root@redhat.com> References: <5145C765.9020602@redhat.com> <113426756.9189427.1363530495950.JavaMail.root@redhat.com> Message-ID: <20130317153038.GB4891@redhat.com> On Sun, Mar 17, 2013 at 10:28:15AM -0400, Ayal Baron wrote: > > > ----- Original Message ----- > > On 17/03/13 15:13, Ayal Baron wrote: > > > > > > ----- Original Message ----- > > >> On 03/13/2013 11:55 PM, Ayal Baron wrote: > > >> ... > > >>>>>> The only reason we have this problem is because there is this > > >>>>>> thing against making multiple calls. > > >>>>>> > > >>>>>> Just split it up. > > >>>>>> getVmRuntimeStats() - transient things like mem and cpu% > > >>>>>> getVmInformation() - (semi)static things like disk\networking > > >>>>>> layout > > >>>>>> etc. > > >>>>>> Each updated at different intervals. > > >>>>> +1 on splitting the data up into 2 separate API calls. > > >>>>> You could potentially add a checksum (md5, or any other way) of > > >>>>> the > > >>>>> "static" data to getVmRuntimeStats and not bother even with > > >>>>> polling > > >>>>> the VmInformation if this hasn't changed. Then you could poll > > >>>>> as > > >>>>> often as you'd like the stats and immediately see if you also > > >>>>> need > > >>>>> to retrieve VmInfo or not (you rarely would). > > >>>> +1 To Ayal's suggestion > > >>>> except that instead of the engine hashing the data VDSM sends > > >>>> the > > >>>> key which is opaque to the engine. > > >>>> This can be a local timestap or a generation number. > > >>> Of course vdsm does the hash, otherwise you'd need to pass all > > >>> the > > >>> data to engine which would beat the purpose. > > >> I thought you meant engine will be sending the hash of previous > > >> requests > > >> per VM to vdsm, then vdsm will reply back with vm's removed, vm's > > >> added, > > >> and the details for vm's that changed (i.e., engine would be doing > > >> something like if-modified-since-checksum per vm). > > >> benefit is reducing a round trip. > > >> but first would need to split to calls of stats (always changing) > > >> and > > >> slowly/never changing data. > > > If vdms accepts the hash then in your method engine would have to > > > periodically call getVmInfo(hash). > > > What I was suggesting is that getVmStats would return vmInfo hash > > > so that we could avoid calling getVmInfo altogether. > > > The stats *always* change so there is no need for checking if that > > > info has changed. > > > What we could do is avoid the split into 2 verbs by calling > > > getVmStats(hash) and then have getVmStats return everything if the > > > hash has changed or only the stats if it hasn't. This would be > > > the least number of roundtrips and avoid the split. If you don't > > > pass a hash it would return everything so this way it's also fully > > > backward compatible. > > > > For the 'static' data, why is there a need for a hash? > > If VDSM sends in each update a timestamp, can't RHEVM just use > > if-modified-since with the last timestamp it got from VDSM? > > Is it cheaper for VDSM to calculate the hash, than update the > > timestamp > > per change in any of the fields? It doesn't really need to update the > > timestamp per change, only for the first change since last update > > sent > > actually (so 'dirty' flag in a way, to signify data that RHEVM hasn't > > seen yet). > > Y. > > As Saggi mentioned: "VDSM sends the key which is opaque to the engine. This can be a local timestap or a generation number." > > The content doesn't matter, what matters is that it has changed. > timestamp assumes that vdsm will track changes and send only delta. > Although possible this would be an overkill (for every value in the > dict you'd have to hold a timestamp of last change and send only those > which have changed since the timestamp which was passed by the user). If we're in the spirit of quoting Saggi, this suggestion is not compatible with "...mak[ing] the return value differ according to input ... is a big no no when talking about type safe APIs.". Dan. From wudxw at linux.vnet.ibm.com Mon Mar 18 03:30:42 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Mon, 18 Mar 2013 11:30:42 +0800 Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. In-Reply-To: <819999290.9188868.1363529575167.JavaMail.root@redhat.com> References: <513D9EFD.7000305@linux.vnet.ibm.com> <819999290.9188868.1363529575167.JavaMail.root@redhat.com> Message-ID: <51468A62.2010602@linux.vnet.ibm.com> On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: > > > ----- Original Message ----- >> >> Hi guys, >> >> Currently, ISO domain is only supported on NFS storage. It could >> improve the ease of use if it allows other types >> of file based storage to store ISO images. After an investigation, I >> found there's not any restriction on this idea. >> So the whole work is removing the limitation on engine side. That >> means engine should allow ISO domain could >> have different storage type from the data center it's attached, like >> what we do with nfs ISO domain in SAN DC. >> >> I start this idea with localfs. I know local storage can't be seen in >> cluster level. But it also provides a choice if no >> NFS available. VMs can be created on the host which has the ISO repo, >> and then be migrated to any other host in the cluster. >> I have done the initial patches: allow creation ISO domain on localfs >> [1] and support import ISO domain on localfs [2] >> I don't have much experience in java/j2ee/web development and engine >> architecture. The patches just work for me. >> I am not sure if it will bring some potential problems. So any >> feedback on the patch or the idea will be appreciated very much. > > Haven't looked at the patches yet, but wrt the idea, I agree on the need (being able to attach ISOs from anywhere and not just nfs) but I think the way to do this should be by getting rid of the ISO domain type altogether. I think ISO domain on localfs is useful for a simple setup or demo, such as oVirt all-in-one. > Basically what we need is: > 1. a way to connect to file based storage (let's leave block aside for now) - this already exists via the connectStorageServer verb > 2. a way to list and present a file system tree in gui (give an arbitrary path to vdsm and list content) and possibly filter results by type (vfd, iso) - does not exist today. Possibly some security aspects here that need hashing out. > 3. a way to specify a path to a file when attaching an iso/vfd to a VM - this is the way it works today > > This would devoid the need for isoUploader and allow users to simply manage an nfs export with files. > Next step would be to make connectStorageServer support httpfs [1] and then we'd be able to mount ISOs directly over http (hopefully this would be sufficient to support ISOs stored on S3, swift, glance, etc). Actually, we could use the qemu curl backend image support directly. That means we don't need mount the place storing ISO images. We can just maintain a list of ISO image with its link, which could be http, ftp and ssh. > > [1] http://httpfs.sourceforge.net/ > >> >> >> Mark. >> >> [1] http://gerrit.ovirt.org/#/c/12687/ >> [2] http://gerrit.ovirt.org/#/c/12916/ >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > From sanjal at redhat.com Mon Mar 18 06:28:14 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Mon, 18 Mar 2013 11:58:14 +0530 Subject: [Engine-devel] FeatureSupported and compatibility versions Message-ID: <5146B3FE.1010905@redhat.com> Hi all, The current mechanism in oVirt to check whether a feature is supported in a particular compatibility version is to use the FeatureSupported class. e.g. FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) Checks whether the "network linking" feature is supported for the the VM's cluster compatibility version. This internally checks whether the value of the corresponding config (NetworkLinkingSupported) for the given compatibility version is true/false. I'm not sure if this is a good idea, since a feature is typically supported "from" a particular version. E.g. Gluster support was introduced in 3.1, and it continues to be available in all subsequent versions. So I see no point in adding configuration for every version indicating whether the feature is supported in that version or not. I suggest to use either of the following options: 1) Instead of using a boolean config for each version, use a single string config that indicates the "supported from" version e.g. GlusterSupportedFrom = 3.1. There could be rare cases where a feature, for some reason, is removed in some release. In such cases, we could use one additional config for the "supported to" version. 2) Continue with the boolean approach, but do not have entries for every version; rather make use of the "default value" for majority of cases, and add the explicit version mapping for the minority e.g. GlusterSupported = true by default, and false in case of 3.0 (only one config required for 3.0) Thoughts? Regards, Shireesh From abaron at redhat.com Mon Mar 18 06:51:03 2013 From: abaron at redhat.com (Ayal Baron) Date: Mon, 18 Mar 2013 02:51:03 -0400 (EDT) Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. In-Reply-To: <51468A62.2010602@linux.vnet.ibm.com> Message-ID: <411572396.9297119.1363589463150.JavaMail.root@redhat.com> ----- Original Message ----- > On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: > > > > > > ----- Original Message ----- > >> > >> Hi guys, > >> > >> Currently, ISO domain is only supported on NFS storage. It could > >> improve the ease of use if it allows other types > >> of file based storage to store ISO images. After an investigation, > >> I > >> found there's not any restriction on this idea. > >> So the whole work is removing the limitation on engine side. That > >> means engine should allow ISO domain could > >> have different storage type from the data center it's attached, > >> like > >> what we do with nfs ISO domain in SAN DC. > >> > >> I start this idea with localfs. I know local storage can't be seen > >> in > >> cluster level. But it also provides a choice if no > >> NFS available. VMs can be created on the host which has the ISO > >> repo, > >> and then be migrated to any other host in the cluster. > >> I have done the initial patches: allow creation ISO domain on > >> localfs > >> [1] and support import ISO domain on localfs [2] > >> I don't have much experience in java/j2ee/web development and > >> engine > >> architecture. The patches just work for me. > >> I am not sure if it will bring some potential problems. So any > >> feedback on the patch or the idea will be appreciated very much. > > > > Haven't looked at the patches yet, but wrt the idea, I agree on the > > need (being able to attach ISOs from anywhere and not just nfs) > > but I think the way to do this should be by getting rid of the ISO > > domain type altogether. > > I think ISO domain on localfs is useful for a simple setup or demo, > such as oVirt all-in-one. As I said above, I totally agree that we need to be able to attach ISOs on local host, what I'm saying is that we don't need a local ISO *domain*. All we need is the ability to list the content of a directory on the local host (to be able to choose the ISO) and attach it to the VM. Since the attach part already exists then the gap is just the listing issue. > > > Basically what we need is: > > 1. a way to connect to file based storage (let's leave block aside > > for now) - this already exists via the connectStorageServer verb > > 2. a way to list and present a file system tree in gui (give an > > arbitrary path to vdsm and list content) and possibly filter > > results by type (vfd, iso) - does not exist today. Possibly some > > security aspects here that need hashing out. > > 3. a way to specify a path to a file when attaching an iso/vfd to a > > VM - this is the way it works today > > > > This would devoid the need for isoUploader and allow users to > > simply manage an nfs export with files. > > Next step would be to make connectStorageServer support httpfs [1] > > and then we'd be able to mount ISOs directly over http (hopefully > > this would be sufficient to support ISOs stored on S3, swift, > > glance, etc). > > Actually, we could use the qemu curl backend image support directly. > That means we don't need mount the place storing ISO images. We can > just maintain a list of ISO image with its link, which could be http, > ftp and ssh. even better! > > > > > [1] http://httpfs.sourceforge.net/ > > > >> > >> > >> Mark. > >> > >> [1] http://gerrit.ovirt.org/#/c/12687/ > >> [2] http://gerrit.ovirt.org/#/c/12916/ > >> > >> _______________________________________________ > >> 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 Mar 18 07:11:20 2013 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Mon, 18 Mar 2013 15:11:20 +0800 Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. In-Reply-To: <51468A62.2010602@linux.vnet.ibm.com> References: <513D9EFD.7000305@linux.vnet.ibm.com> <819999290.9188868.1363529575167.JavaMail.root@redhat.com> <51468A62.2010602@linux.vnet.ibm.com> Message-ID: <5146BE18.2000306@linux.vnet.ibm.com> Mark Wu : > On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: >> >> >> ----- Original Message ----- >>> >>> Hi guys, >>> >>> Currently, ISO domain is only supported on NFS storage. It could >>> improve the ease of use if it allows other types >>> of file based storage to store ISO images. After an investigation, I >>> found there's not any restriction on this idea. >>> So the whole work is removing the limitation on engine side. That >>> means engine should allow ISO domain could >>> have different storage type from the data center it's attached, like >>> what we do with nfs ISO domain in SAN DC. >>> >>> I start this idea with localfs. I know local storage can't be seen in >>> cluster level. But it also provides a choice if no >>> NFS available. VMs can be created on the host which has the ISO repo, >>> and then be migrated to any other host in the cluster. >>> I have done the initial patches: allow creation ISO domain on localfs >>> [1] and support import ISO domain on localfs [2] >>> I don't have much experience in java/j2ee/web development and engine >>> architecture. The patches just work for me. >>> I am not sure if it will bring some potential problems. So any >>> feedback on the patch or the idea will be appreciated very much. >> >> Haven't looked at the patches yet, but wrt the idea, I agree on the >> need (being able to attach ISOs from anywhere and not just nfs) but I >> think the way to do this should be by getting rid of the ISO domain >> type altogether. > > I think ISO domain on localfs is useful for a simple setup or demo, > such as oVirt all-in-one. > >> Basically what we need is: >> 1. a way to connect to file based storage (let's leave block aside >> for now) - this already exists via the connectStorageServer verb >> 2. a way to list and present a file system tree in gui (give an >> arbitrary path to vdsm and list content) and possibly filter results >> by type (vfd, iso) - does not exist today. Possibly some security >> aspects here that need hashing out. >> 3. a way to specify a path to a file when attaching an iso/vfd to a >> VM - this is the way it works today >> >> This would devoid the need for isoUploader and allow users to simply >> manage an nfs export with files. >> Next step would be to make connectStorageServer support httpfs [1] >> and then we'd be able to mount ISOs directly over http (hopefully >> this would be sufficient to support ISOs stored on S3, swift, glance, >> etc). > > Actually, we could use the qemu curl backend image support directly. > That means we don't need mount the place storing ISO images. We can > just maintain a list of ISO image with its link, which could be http, > ftp and ssh. That will be fine to start a VM on a existing extern ISO image. I also would like to maintain a ISO image cache on the local host to avoid to re-streaming the ISO image from the ISO image repositories every time. That will be helpful for people who is suffered from the network bottleneck. > >> >> [1] http://httpfs.sourceforge.net/ >> >>> >>> >>> Mark. >>> >>> [1] http://gerrit.ovirt.org/#/c/12687/ >>> [2] http://gerrit.ovirt.org/#/c/12916/ >>> >>> _______________________________________________ >>> 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 > -- --- ?? Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or shuming at linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC From kmayilsa at redhat.com Mon Mar 18 07:20:43 2013 From: kmayilsa at redhat.com (Kanagaraj Mayilsamy) Date: Mon, 18 Mar 2013 03:20:43 -0400 (EDT) Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <5146B3FE.1010905@redhat.com> Message-ID: <1888604775.475534.1363591243741.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Shireesh Anjal" > To: engine-devel at ovirt.org > Sent: Monday, March 18, 2013 11:58:14 AM > Subject: [Engine-devel] FeatureSupported and compatibility versions > > Hi all, > > The current mechanism in oVirt to check whether a feature is > supported > in a particular compatibility version is to use the FeatureSupported > class. e.g. > > FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) > > Checks whether the "network linking" feature is supported for the the > VM's cluster compatibility version. This internally checks whether > the > value of the corresponding config (NetworkLinkingSupported) for the > given compatibility version is true/false. > > I'm not sure if this is a good idea, since a feature is typically > supported "from" a particular version. E.g. Gluster support was > introduced in 3.1, and it continues to be available in all subsequent > versions. So I see no point in adding configuration for every version > indicating whether the feature is supported in that version or not. I > suggest to use either of the following options: > > 1) Instead of using a boolean config for each version, use a single > string config that indicates the "supported from" version e.g. > GlusterSupportedFrom = 3.1. There could be rare cases where a > feature, > for some reason, is removed in some release. In such cases, we could > use > one additional config for the "supported to" version. > > 2) Continue with the boolean approach, but do not have entries for > every > version; rather make use of the "default value" for majority of > cases, > and add the explicit version mapping for the minority e.g. > GlusterSupported = true by default, and false in case of 3.0 (only > one > config required for 3.0) I think we can slightly modify this approach to make it better. I will start with an example. Lets say a feature 'XyzFeature' is introduced in 3.2 and available till 3.5. And in 3.6, 'XyzFeature' is removed because of something better is available. We can have the following configuration. ('XyzFeatureSupported','true','3.2') ('XyzFeatureSupported','false','3.6') And the above will be interpreted as 'XyzFeature' is supported from 3.2 onwards and not-supported from 3.6 onwards. Thanks, Kanagaraj > > Thoughts? > > Regards, > Shireesh > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mkolesni at redhat.com Mon Mar 18 07:29:34 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Mon, 18 Mar 2013 03:29:34 -0400 (EDT) Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <5146B3FE.1010905@redhat.com> Message-ID: <1886045500.2100242.1363591774667.JavaMail.root@redhat.com> ----- Original Message ----- > Hi all, > > The current mechanism in oVirt to check whether a feature is > supported > in a particular compatibility version is to use the FeatureSupported > class. e.g. > > FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) > > Checks whether the "network linking" feature is supported for the the > VM's cluster compatibility version. This internally checks whether > the > value of the corresponding config (NetworkLinkingSupported) for the > given compatibility version is true/false. > > I'm not sure if this is a good idea, since a feature is typically > supported "from" a particular version. E.g. Gluster support was > introduced in 3.1, and it continues to be available in all subsequent > versions. So I see no point in adding configuration for every version > indicating whether the feature is supported in that version or not. I > suggest to use either of the following options: You can "merge" the configs into a single config when older versions go out of the supported versions for the system. i.e. in 4.0 you can have upgrade script that merges all GlusterFeatureSupported to one entry instead of several. > > 1) Instead of using a boolean config for each version, use a single > string config that indicates the "supported from" version e.g. > GlusterSupportedFrom = 3.1. There could be rare cases where a > feature, > for some reason, is removed in some release. In such cases, we could > use > one additional config for the "supported to" version. > > 2) Continue with the boolean approach, but do not have entries for > every > version; rather make use of the "default value" for majority of > cases, > and add the explicit version mapping for the minority e.g. > GlusterSupported = true by default, and false in case of 3.0 (only > one > config required for 3.0) I'm not sure why we would want to complicate this simple mechanism? Is there much to gain? > > Thoughts? > > Regards, > Shireesh > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From sanjal at redhat.com Mon Mar 18 07:41:33 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Mon, 18 Mar 2013 13:11:33 +0530 Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <1886045500.2100242.1363591774667.JavaMail.root@redhat.com> References: <1886045500.2100242.1363591774667.JavaMail.root@redhat.com> Message-ID: <5146C52D.2090903@redhat.com> On 03/18/2013 12:59 PM, Mike Kolesnik wrote: > ----- Original Message ----- >> Hi all, >> >> The current mechanism in oVirt to check whether a feature is >> supported >> in a particular compatibility version is to use the FeatureSupported >> class. e.g. >> >> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) >> >> Checks whether the "network linking" feature is supported for the the >> VM's cluster compatibility version. This internally checks whether >> the >> value of the corresponding config (NetworkLinkingSupported) for the >> given compatibility version is true/false. >> >> I'm not sure if this is a good idea, since a feature is typically >> supported "from" a particular version. E.g. Gluster support was >> introduced in 3.1, and it continues to be available in all subsequent >> versions. So I see no point in adding configuration for every version >> indicating whether the feature is supported in that version or not. I >> suggest to use either of the following options: > You can "merge" the configs into a single config when older versions go out of the supported versions for the system. > > i.e. in 4.0 you can have upgrade script that merges all GlusterFeatureSupported to one entry instead of several. > >> 1) Instead of using a boolean config for each version, use a single >> string config that indicates the "supported from" version e.g. >> GlusterSupportedFrom = 3.1. There could be rare cases where a >> feature, >> for some reason, is removed in some release. In such cases, we could >> use >> one additional config for the "supported to" version. >> >> 2) Continue with the boolean approach, but do not have entries for >> every >> version; rather make use of the "default value" for majority of >> cases, >> and add the explicit version mapping for the minority e.g. >> GlusterSupported = true by default, and false in case of 3.0 (only >> one >> config required for 3.0) > I'm not sure why we would want to complicate this simple mechanism? > > Is there much to gain? I think option 1 suggested above is simpler - to implement as well as to understand. Let me give you an example of why I don't like current mechanism. I introduce a version check for a feature that was introduced in 3.1. I'm being asked now to add three entries in config 3.0 - false 3.1 - true 3.2 - true It will also mean that when 3.3 goes out, someone has to make sure that another entry is added for 3.3-true. I think it is not logical as well as scalable if you have more versions. And it sounds far more complex (to maintain) than just having SupportedFrom = 3.1 So I would like to know if there are any objections to my proposal. I intend to use this for at least the gluster related features. >> Thoughts? >> >> Regards, >> Shireesh >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From yzaslavs at redhat.com Mon Mar 18 07:59:07 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 18 Mar 2013 03:59:07 -0400 (EDT) Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <5146C52D.2090903@redhat.com> Message-ID: <560962357.8848218.1363593547120.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Shireesh Anjal" > To: "Mike Kolesnik" > Cc: engine-devel at ovirt.org > Sent: Monday, March 18, 2013 9:41:33 AM > Subject: Re: [Engine-devel] FeatureSupported and compatibility versions > > On 03/18/2013 12:59 PM, Mike Kolesnik wrote: > > ----- Original Message ----- > >> Hi all, > >> > >> The current mechanism in oVirt to check whether a feature is > >> supported > >> in a particular compatibility version is to use the > >> FeatureSupported > >> class. e.g. > >> > >> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) > >> > >> Checks whether the "network linking" feature is supported for the > >> the > >> VM's cluster compatibility version. This internally checks whether > >> the > >> value of the corresponding config (NetworkLinkingSupported) for > >> the > >> given compatibility version is true/false. > >> > >> I'm not sure if this is a good idea, since a feature is typically > >> supported "from" a particular version. E.g. Gluster support was > >> introduced in 3.1, and it continues to be available in all > >> subsequent > >> versions. So I see no point in adding configuration for every > >> version > >> indicating whether the feature is supported in that version or > >> not. I > >> suggest to use either of the following options: > > You can "merge" the configs into a single config when older > > versions go out of the supported versions for the system. > > > > i.e. in 4.0 you can have upgrade script that merges all > > GlusterFeatureSupported to one entry instead of several. > > > >> 1) Instead of using a boolean config for each version, use a > >> single > >> string config that indicates the "supported from" version e.g. > >> GlusterSupportedFrom = 3.1. There could be rare cases where a > >> feature, > >> for some reason, is removed in some release. In such cases, we > >> could > >> use > >> one additional config for the "supported to" version. > >> > >> 2) Continue with the boolean approach, but do not have entries for > >> every > >> version; rather make use of the "default value" for majority of > >> cases, > >> and add the explicit version mapping for the minority e.g. > >> GlusterSupported = true by default, and false in case of 3.0 (only > >> one > >> config required for 3.0) > > I'm not sure why we would want to complicate this simple mechanism? > > > > Is there much to gain? > > I think option 1 suggested above is simpler - to implement as well as > to > understand. > > Let me give you an example of why I don't like current mechanism. I > introduce a version check for a feature that was introduced in 3.1. > I'm > being asked now to add three entries in config > > 3.0 - false > 3.1 - true > 3.2 - true > > It will also mean that when 3.3 goes out, someone has to make sure > that > another entry is added for 3.3-true. I think it is not logical as > well > as scalable if you have more versions. And it sounds far more complex > (to maintain) than just having I think we should look at it from two directions - a. the Java API we provide - Config and Feature classes b. The database. I personally also had thoughts that the current mechanism is lacking, in sense of defining "ranges of versions" for features. We should have a concept of "starts with version" and "supported until version". I think the logic for that should be implemented at db and at the Config class. I think the API provided by featureSupported should be kept. > > SupportedFrom = 3.1 > > So I would like to know if there are any objections to my proposal. I > intend to use this for at least the gluster related features. > > >> Thoughts? > >> > >> Regards, > >> Shireesh > >> _______________________________________________ > >> 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 ofrenkel at redhat.com Mon Mar 18 08:00:13 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Mon, 18 Mar 2013 04:00:13 -0400 (EDT) Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <5146B3FE.1010905@redhat.com> Message-ID: <411669739.21262216.1363593613422.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Shireesh Anjal" > To: engine-devel at ovirt.org > Sent: Monday, March 18, 2013 8:28:14 AM > Subject: [Engine-devel] FeatureSupported and compatibility versions > > Hi all, > > The current mechanism in oVirt to check whether a feature is > supported > in a particular compatibility version is to use the FeatureSupported > class. e.g. > > FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) > > Checks whether the "network linking" feature is supported for the the > VM's cluster compatibility version. This internally checks whether > the > value of the corresponding config (NetworkLinkingSupported) for the > given compatibility version is true/false. > > I'm not sure if this is a good idea, since a feature is typically > supported "from" a particular version. E.g. Gluster support was > introduced in 3.1, and it continues to be available in all subsequent > versions. So I see no point in adding configuration for every version > indicating whether the feature is supported in that version or not. I > suggest to use either of the following options: > > 1) Instead of using a boolean config for each version, use a single > string config that indicates the "supported from" version e.g. > GlusterSupportedFrom = 3.1. There could be rare cases where a > feature, > for some reason, is removed in some release. In such cases, we could > use > one additional config for the "supported to" version. > > 2) Continue with the boolean approach, but do not have entries for > every > version; rather make use of the "default value" for majority of > cases, > and add the explicit version mapping for the minority e.g. > GlusterSupported = true by default, and false in case of 3.0 (only > one > config required for 3.0) > i like this approach better, if one add new feature for 3.3 he should add it as 'true' in the config to be used as default, and explicitly add it as false for other unsupported versions. if we do go this way, we need to make sure it works because i vaguely remember we had a bug in configuration, making us explicitly specify value for all versions. > Thoughts? > > Regards, > Shireesh > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From qyddbear at 163.com Mon Mar 18 08:18:28 2013 From: qyddbear at 163.com (qyddbear) Date: Mon, 18 Mar 2013 16:18:28 +0800 (CST) Subject: [Engine-devel] make rpm error: No targets specified and no makefile found. Stop Message-ID: Hi, I am a green learner, I tried to make ovirt-engine rpm from compiled source code. when I run make rpm, and the log as follows. Can anyone tell me what's the matter? Thanks! [root at localhost ovirt-engine-3.1.0]# make rpm sed -e 's/@PACKAGE_VERSION@/3.1.0/g' \ -e 's/@PACKAGE_RELEASE@/3.26/g' packaging/fedora/spec/ovirt-engine.spec.in > ovirt-engine.spec git ls-files | tar --files-from /proc/self/fd/0 -czf ovirt-engine-3.1.0.tar.gz ovirt-engine.spec rm -f ovirt-engine.spec You can use rpmbuild -tb ovirt-engine-3.1.0.tar.gz to produce rpms rm -rf /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild mkdir -p /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,BUILDROOT} mkdir -p output rpmbuild -ts --define="_topdir /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild" ovirt-engine-3.1.0.tar.gz Wrote: /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SRPMS/ovirt-engine-3.1.0-3.26.el6.src.rpm mv /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SRPMS/*.rpm output rm -rf /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild srpm is ready at output rm -rf /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild mkdir -p /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,BUILDROOT} mkdir -p output rpmbuild --define="_topdir /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild" --rebuild output/ovirt-engine-3.1.0*.src.rpm Installing output/ovirt-engine-3.1.0-3.26.el6.src.rpm Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.3JQHHM + umask 022 + cd /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD + LANG=C + export LANG + unset DISPLAY + cd /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD + rm -rf ovirt-engine-3.1.0 + /bin/mkdir -p ovirt-engine-3.1.0 + cd ovirt-engine-3.1.0 + /bin/tar -xf - + /usr/bin/gzip -dc /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SOURCES/ovirt-engine-3.1.0.tar.gz + STATUS=0 + '[' 0 -ne 0 ']' + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.qesWT3 + umask 022 + cd /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD + cd ovirt-engine-3.1.0 + LANG=C + export LANG + unset DISPLAY + make -j1 PACKAGE_NAME=ovirt-engine ENGINE_NAME=ovirt-engine LOCALSTATE_DIR=/var ENGINE_STATE=/var/lib/ovirt-engine PREFIX=/usr SYSCONF_DIR=/etc BIN_DIR=/usr/bin DATAROOT_DIR=/usr/share MAN_DIR=/usr/share/man PYTHON=/usr/bin/python PYTHON_DIR=/usr/lib/python2.6/site-packages JAVA_DIR=/usr/share/java MAVENPOM_DIR=/usr/share/maven2/poms PKG_JAVA_DIR=/usr/share/java/ovirt-engine PKG_SYSCONF_DIR=/etc/ovirt-engine PKG_EAR_DIR=/usr/share/ovirt-engine/engine.ear PKG_PKI_DIR=/etc/pki/ovirt-engine PKG_JBOSS_MODULES=/usr/share/ovirt-engine/modules make[1]: Entering directory `/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0' make[1]: *** No targets specified and no makefile found. Stop. make[1]: Leaving directory `/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0' error: Bad exit status from /var/tmp/rpm-tmp.qesWT3 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.qesWT3 (%build) make: *** [rpm] Error 1 There is a ovirt-engine.spec under /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alonbl at redhat.com Mon Mar 18 08:26:01 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 18 Mar 2013 04:26:01 -0400 (EDT) Subject: [Engine-devel] make rpm error: No targets specified and no makefile found. Stop In-Reply-To: Message-ID: <375152531.7320546.1363595161254.JavaMail.root@redhat.com> Please try: $ make dist $ rpmbuild -tb ----- Original Message ----- > From: "qyddbear" > To: engine-devel at ovirt.org > Sent: Monday, March 18, 2013 10:18:28 AM > Subject: [Engine-devel] make rpm error: No targets specified and no makefile found. Stop > > > > > > Hi, I am a green learner, I tried to make ovirt-engine rpm from > compiled source code. when I run make rpm, and the log as follows. > Can anyone tell me what's the matter? Thanks! > > > [root at localhost ovirt-engine-3.1.0]# make rpm > sed -e 's/@PACKAGE_VERSION@/3.1.0/g' \ > -e 's/@PACKAGE_RELEASE@/3.26/g' > packaging/fedora/spec/ovirt-engine.spec.in > ovirt-engine.spec > git ls-files | tar --files-from /proc/self/fd/0 -czf > ovirt-engine-3.1.0.tar.gz ovirt-engine.spec > rm -f ovirt-engine.spec > > > You can use rpmbuild -tb ovirt-engine-3.1.0.tar.gz to produce rpms > > > rm -rf /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild > mkdir -p > /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,BUILDROOT} > mkdir -p output > rpmbuild -ts --define="_topdir > /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild" ovirt-engine-3.1.0.tar.gz > Wrote: > /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SRPMS/ovirt-engine-3.1.0-3.26.el6.src.rpm > mv /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SRPMS/*.rpm output > rm -rf /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild > > > srpm is ready at output > > > rm -rf /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild > mkdir -p > /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,BUILDROOT} > mkdir -p output > rpmbuild --define="_topdir /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild" > --rebuild ou tput/ovirt-engine-3.1.0*.src.rpm > Installing output/ovirt-engine-3.1.0-3.26.el6.src.rpm > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.3JQHHM > + umask 022 > + cd /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD > + LANG=C > + export LANG > + unset DISPLAY > + cd /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD > + rm -rf ovirt-engine-3.1.0 > + /bin/mkdir -p ovirt-engine-3.1.0 > + cd ovirt-engine-3.1.0 > + /bin/tar -xf - > + /usr/bin/gzip -dc > /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SOURCES/ovirt-engine-3.1.0.tar.gz > + STATUS=0 > + '[' 0 -ne 0 ']' > + /bin/chmod -Rf a+rX,u+w,g-w,o-w . > + exit 0 > Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.qesWT3 > + umask 022 > + cd /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD > + cd ovirt-engine-3.1.0 > + LANG=C > + export LANG > + unset DISPLAY > + make -j1 PACKAGE_NAME=ovirt-engine ENGINE_NAME=ovirt-engine > LOCALSTATE_DIR=/var ENGINE_STATE=/var/lib/ovirt-engine PREFIX=/usr > SYSCONF_DIR=/etc BIN_DIR=/usr/bin DATAROOT_DIR=/usr/share > MAN_DIR=/usr/share/man PYTHON=/usr/bin/python > PYTHON_DIR=/usr/lib/python2.6/site-packages JAVA_DIR=/usr/share/java > MAVENPOM_DIR=/usr/share/maven2/poms > PKG_JAVA_DIR=/usr/share/java/ovirt-engine > PKG_SYSCONF_DIR=/etc/ovirt-engine > PKG_EAR_DIR=/usr/share/ovirt-engine/engine.ear > PKG_PKI_DIR=/etc/pki/ovirt-e ngine > PKG_JBOSS_MODULES=/usr/share/ovirt-engine/modules > make[1]: Entering directory > `/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0' > make[1]: *** No targets specified and no makefile found. Stop. > make[1]: Leaving directory > `/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0' > error: Bad exit status from /var/tmp/rpm-tmp.qesWT3 (%build) > > > > > RPM build errors: > Bad exit status from / var/tmp/rpm-tmp.qesWT3 (%build) > make: *** [rpm] Error 1 > > > > > There is a ovirt-engine.spec under > /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0 > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From wudxw at linux.vnet.ibm.com Mon Mar 18 08:36:44 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Mon, 18 Mar 2013 16:36:44 +0800 Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. In-Reply-To: <411572396.9297119.1363589463150.JavaMail.root@redhat.com> References: <411572396.9297119.1363589463150.JavaMail.root@redhat.com> Message-ID: <5146D21C.3050300@linux.vnet.ibm.com> On 03/18/2013 02:51 PM, Ayal Baron wrote: > > ----- Original Message ----- >> On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: >>> >>> ----- Original Message ----- >>>> Hi guys, >>>> >>>> Currently, ISO domain is only supported on NFS storage. It could >>>> improve the ease of use if it allows other types >>>> of file based storage to store ISO images. After an investigation, >>>> I >>>> found there's not any restriction on this idea. >>>> So the whole work is removing the limitation on engine side. That >>>> means engine should allow ISO domain could >>>> have different storage type from the data center it's attached, >>>> like >>>> what we do with nfs ISO domain in SAN DC. >>>> >>>> I start this idea with localfs. I know local storage can't be seen >>>> in >>>> cluster level. But it also provides a choice if no >>>> NFS available. VMs can be created on the host which has the ISO >>>> repo, >>>> and then be migrated to any other host in the cluster. >>>> I have done the initial patches: allow creation ISO domain on >>>> localfs >>>> [1] and support import ISO domain on localfs [2] >>>> I don't have much experience in java/j2ee/web development and >>>> engine >>>> architecture. The patches just work for me. >>>> I am not sure if it will bring some potential problems. So any >>>> feedback on the patch or the idea will be appreciated very much. >>> Haven't looked at the patches yet, but wrt the idea, I agree on the >>> need (being able to attach ISOs from anywhere and not just nfs) >>> but I think the way to do this should be by getting rid of the ISO >>> domain type altogether. >> I think ISO domain on localfs is useful for a simple setup or demo, >> such as oVirt all-in-one. > As I said above, I totally agree that we need to be able to attach ISOs on local host, what I'm saying is that we don't need a local ISO *domain*. All we need is the ability to list the content of a directory on the local host (to be able to choose the ISO) and attach it to the VM. Since the attach part already exists then the gap is just the listing issue. Got it. Thanks for your explanation! > >>> Basically what we need is: >>> 1. a way to connect to file based storage (let's leave block aside >>> for now) - this already exists via the connectStorageServer verb >>> 2. a way to list and present a file system tree in gui (give an >>> arbitrary path to vdsm and list content) and possibly filter >>> results by type (vfd, iso) - does not exist today. Possibly some >>> security aspects here that need hashing out. >>> 3. a way to specify a path to a file when attaching an iso/vfd to a >>> VM - this is the way it works today >>> >>> This would devoid the need for isoUploader and allow users to >>> simply manage an nfs export with files. >>> Next step would be to make connectStorageServer support httpfs [1] >>> and then we'd be able to mount ISOs directly over http (hopefully >>> this would be sufficient to support ISOs stored on S3, swift, >>> glance, etc). >> Actually, we could use the qemu curl backend image support directly. >> That means we don't need mount the place storing ISO images. We can >> just maintain a list of ISO image with its link, which could be http, >> ftp and ssh. > even better! > >>> [1] http://httpfs.sourceforge.net/ >>> >>>> >>>> Mark. >>>> >>>> [1] http://gerrit.ovirt.org/#/c/12687/ >>>> [2] http://gerrit.ovirt.org/#/c/12916/ >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> >> From qyddbear at 163.com Mon Mar 18 08:42:36 2013 From: qyddbear at 163.com (qyddbear) Date: Mon, 18 Mar 2013 16:42:36 +0800 (CST) Subject: [Engine-devel] make rpm error: No targets specified and no makefile found. Stop In-Reply-To: <375152531.7320546.1363595161254.JavaMail.root@redhat.com> References: <375152531.7320546.1363595161254.JavaMail.root@redhat.com> Message-ID: <6c044d2.13414.13d7caa1e54.Coremail.qyddbear@163.com> Thanks, but the problem still exists. There is no dist rule be wrote in Makefile, so run make dist, the result is make: *** No rule to make target `dist'. Stop. run rpmbuild -tb ovirt-engine-3.1.0.tar.gz, the log is the same as former. At 2013-03-18 16:26:01,"Alon Bar-Lev" wrote: >Please try: > >$ make dist >$ rpmbuild -tb > > >----- Original Message ----- >> From: "qyddbear" >> To: engine-devel at ovirt.org >> Sent: Monday, March 18, 2013 10:18:28 AM >> Subject: [Engine-devel] make rpm error: No targets specified and no makefile found. Stop >> >> >> >> >> >> Hi, I am a green learner, I tried to make ovirt-engine rpm from >> compiled source code. when I run make rpm, and the log as follows. >> Can anyone tell me what's the matter? Thanks! >> >> >> [root at localhost ovirt-engine-3.1.0]# make rpm >> sed -e 's/@PACKAGE_VERSION@/3.1.0/g' \ >> -e 's/@PACKAGE_RELEASE@/3.26/g' >> packaging/fedora/spec/ovirt-engine.spec.in > ovirt-engine.spec >> git ls-files | tar --files-from /proc/self/fd/0 -czf >> ovirt-engine-3.1.0.tar.gz ovirt-engine.spec >> rm -f ovirt-engine.spec >> >> >> You can use rpmbuild -tb ovirt-engine-3.1.0.tar.gz to produce rpms >> >> >> rm -rf /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild >> mkdir -p >> /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,BUILDROOT} >> mkdir -p output >> rpmbuild -ts --define="_topdir >> /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild" ovirt-engine-3.1.0.tar.gz >> Wrote: >> /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SRPMS/ovirt-engine-3.1.0-3.26.el6.src.rpm >> mv /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SRPMS/*.rpm output >> rm -rf /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild >> >> >> srpm is ready at output >> >> >> rm -rf /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild >> mkdir -p >> /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,BUILDROOT} >> mkdir -p output >> rpmbuild --define="_topdir /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild" >> --rebuild ou tput/ovirt-engine-3.1.0*.src.rpm >> Installing output/ovirt-engine-3.1.0-3.26.el6.src.rpm >> Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.3JQHHM >> + umask 022 >> + cd /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD >> + LANG=C >> + export LANG >> + unset DISPLAY >> + cd /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD >> + rm -rf ovirt-engine-3.1.0 >> + /bin/mkdir -p ovirt-engine-3.1.0 >> + cd ovirt-engine-3.1.0 >> + /bin/tar -xf - >> + /usr/bin/gzip -dc >> /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SOURCES/ovirt-engine-3.1.0.tar.gz >> + STATUS=0 >> + '[' 0 -ne 0 ']' >> + /bin/chmod -Rf a+rX,u+w,g-w,o-w . >> + exit 0 >> Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.qesWT3 >> + umask 022 >> + cd /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD >> + cd ovirt-engine-3.1.0 >> + LANG=C >> + export LANG >> + unset DISPLAY >> + make -j1 PACKAGE_NAME=ovirt-engine ENGINE_NAME=ovirt-engine >> LOCALSTATE_DIR=/var ENGINE_STATE=/var/lib/ovirt-engine PREFIX=/usr >> SYSCONF_DIR=/etc BIN_DIR=/usr/bin DATAROOT_DIR=/usr/share >> MAN_DIR=/usr/share/man PYTHON=/usr/bin/python >> PYTHON_DIR=/usr/lib/python2.6/site-packages JAVA_DIR=/usr/share/java >> MAVENPOM_DIR=/usr/share/maven2/poms >> PKG_JAVA_DIR=/usr/share/java/ovirt-engine >> PKG_SYSCONF_DIR=/etc/ovirt-engine >> PKG_EAR_DIR=/usr/share/ovirt-engine/engine.ear >> PKG_PKI_DIR=/etc/pki/ovirt-e ngine >> PKG_JBOSS_MODULES=/usr/share/ovirt-engine/modules >> make[1]: Entering directory >> `/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0' >> make[1]: *** No targets specified and no makefile found. Stop. >> make[1]: Leaving directory >> `/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0' >> error: Bad exit status from /var/tmp/rpm-tmp.qesWT3 (%build) >> >> >> >> >> RPM build errors: >> Bad exit status from / var/tmp/rpm-tmp.qesWT3 (%build) >> make: *** [rpm] Error 1 >> >> >> >> >> There is a ovirt-engine.spec under >> /home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0 >> >> >> >> >> >> >> _______________________________________________ >> 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: From alonbl at redhat.com Mon Mar 18 08:43:29 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 18 Mar 2013 04:43:29 -0400 (EDT) Subject: [Engine-devel] make rpm error: No targets specified and no makefile found. Stop In-Reply-To: <6c044d2.13414.13d7caa1e54.Coremail.qyddbear@163.com> Message-ID: <910280182.7322349.1363596209400.JavaMail.root@redhat.com> Which version/branch are you using? ----- Original Message ----- > From: "qyddbear" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org > Sent: Monday, March 18, 2013 10:42:36 AM > Subject: Re:Re: [Engine-devel] make rpm error: No targets specified and no makefile found. Stop > > > Thanks, but the problem still exists. > There is no dist rule be wrote in Makefile, so run make dist, the > result is make: *** No rule to make target `dist'. Stop. > run rpmbuild -tb ovirt-engine-3.1.0.tar.gz, the log is the same as > former. > > > > > > At?2013-03-18?16:26:01,"Alon?Bar-Lev"??wrote: > >Please?try: > > > >$?make?dist > >$?rpmbuild?-tb? > > > > > >-----?Original?Message?----- > >>?From:?"qyddbear"? > >>?To:?engine-devel at ovirt.org > >>?Sent:?Monday,?March?18,?2013?10:18:28?AM > >>?Subject:?[Engine-devel]?make?rpm?error:?No?targets?specified?and > >>??no?makefile found.?Stop > >>? > >>? > >>? > >>? > >>? > >>?Hi,?I?am?a?green?learner,?I?tried?to?make?ovirt-engine?rpm?from > >>?compiled?source?code.?when?I?run?make?rpm,?and?the?log?as?follows. > >>?Can?anyone?tell?me?what's?the?matter??Thanks! > >>? > >>? > >>?[root at localhost?ovirt-engine-3.1.0]#?make?rpm > >>?sed?-e?'s/@PACKAGE_VERSION@/3.1.0/g'?\ > >>?-e?'s/@PACKAGE_RELEASE@/3.26/g' > >>?packaging/fedora/spec/ovirt-engine.spec.in?>?ovirt-engine.spec > >>?git?ls-files?|?tar?--files-from?/proc/self/fd/0?-czf > >>?ovirt-engine-3.1.0.tar.gz?ovirt-engine.spec > >>?rm?-f?ovirt-engine.spec > >>? > >>? > >>?You?can?use?rpmbuild?-tb?ovirt-engine-3.1.0.tar.gz?to?produce?rpms > >>? > >>? > >>?rm?-rf?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild > >>?mkdir?-p > >>?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,BUILDROOT} > >>?mkdir?-p?output > >>?rpmbuild?-ts?--define="_topdir > >>?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild" > >>??ovirt-engine-3.1.0.tar.gz > >>?Wrote: > >>?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SRPMS/ovirt-engine-3.1.0-3.26.el6.src.rpm > >>?mv?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SRPMS/*.rpm?output > >>?rm?-rf?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild > >>? > >>? > >>?srpm?is?ready?at?output > >>? > >>? > >>?rm?-rf?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild > >>?mkdir?-p > >>?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/{SPECS,RPMS,SRPMS,SOURCES,BUILD,BUILDROOT} > >>?mkdir?-p?output > >>?rpmbuild?--define="_topdir > >>??/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild" > >>?--rebuild?ou?tput/ovirt-engine-3.1.0*.src.rpm > >>?Installing?output/ovirt-engine-3.1.0-3.26.el6.src.rpm > >>?Executing(%prep):?/bin/sh?-e?/var/tmp/rpm-tmp.3JQHHM > >>?+?umask?022 > >>?+?cd?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD > >>?+?LANG=C > >>?+?export?LANG > >>?+?unset?DISPLAY > >>?+?cd?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD > >>?+?rm?-rf?ovirt-engine-3.1.0 > >>?+?/bin/mkdir?-p?ovirt-engine-3.1.0 > >>?+?cd?ovirt-engine-3.1.0 > >>?+?/bin/tar?-xf?- > >>?+?/usr/bin/gzip?-dc > >>?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/SOURCES/ovirt-engine-3.1.0.tar.gz > >>?+?STATUS=0 > >>?+?'['?0?-ne?0?']' > >>?+?/bin/chmod?-Rf?a+rX,u+w,g-w,o-w?. > >>?+?exit?0 > >>?Executing(%build):?/bin/sh?-e?/var/tmp/rpm-tmp.qesWT3 > >>?+?umask?022 > >>?+?cd?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD > >>?+?cd?ovirt-engine-3.1.0 > >>?+?LANG=C > >>?+?export?LANG > >>?+?unset?DISPLAY > >>?+?make?-j1?PACKAGE_NAME=ovirt-engine?ENGINE_NAME=ovirt-engine > >>?LOCALSTATE_DIR=/var?ENGINE_STATE=/var/lib/ovirt-engine?PREFIX=/usr > >>?SYSCONF_DIR=/etc?BIN_DIR=/usr/bin?DATAROOT_DIR=/usr/share > >>?MAN_DIR=/usr/share/man?PYTHON=/usr/bin/python > >>?PYTHON_DIR=/usr/lib/python2.6/site-packages > >>??JAVA_DIR=/usr/share/java > >>?MAVENPOM_DIR=/usr/share/maven2/poms > >>?PKG_JAVA_DIR=/usr/share/java/ovirt-engine > >>?PKG_SYSCONF_DIR=/etc/ovirt-engine > >>?PKG_EAR_DIR=/usr/share/ovirt-engine/engine.ear > >>?PKG_PKI_DIR=/etc/pki/ovirt-e?ngine > >>?PKG_JBOSS_MODULES=/usr/share/ovirt-engine/modules > >>?make[1]:?Entering?directory > >>?`/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0' > >>?make[1]:?***?No?targets?specified?and?no?makefile?found.?Stop. > >>?make[1]:?Leaving?directory > >>?`/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0' > >>?error:?Bad?exit?status?from?/var/tmp/rpm-tmp.qesWT3?(%build) > >>? > >>? > >>? > >>? > >>?RPM?build?errors: > >>?Bad?exit?status?from?/?var/tmp/rpm-tmp.qesWT3?(%build) > >>?make:?***?[rpm]?Error?1 > >>? > >>? > >>? > >>? > >>?There?is?a?ovirt-engine.spec?under > >>?/home/wqx/ovirt-engine-3.1.0/tmp.rpmbuild/BUILD/ovirt-engine-3.1.0 > >>? > >>? > >>? > >>? > >>? > >>? > >>?_______________________________________________ > >>?Engine-devel?mailing?list > >>?Engine-devel at ovirt.org > >>?http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > From abaron at redhat.com Mon Mar 18 08:43:08 2013 From: abaron at redhat.com (Ayal Baron) Date: Mon, 18 Mar 2013 04:43:08 -0400 (EDT) Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. In-Reply-To: <5146BE18.2000306@linux.vnet.ibm.com> Message-ID: <1599625604.9482831.1363596188030.JavaMail.root@redhat.com> ----- Original Message ----- > Mark Wu : > > On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: > >> > >> > >> ----- Original Message ----- > >>> > >>> Hi guys, > >>> > >>> Currently, ISO domain is only supported on NFS storage. It could > >>> improve the ease of use if it allows other types > >>> of file based storage to store ISO images. After an > >>> investigation, I > >>> found there's not any restriction on this idea. > >>> So the whole work is removing the limitation on engine side. That > >>> means engine should allow ISO domain could > >>> have different storage type from the data center it's attached, > >>> like > >>> what we do with nfs ISO domain in SAN DC. > >>> > >>> I start this idea with localfs. I know local storage can't be > >>> seen in > >>> cluster level. But it also provides a choice if no > >>> NFS available. VMs can be created on the host which has the ISO > >>> repo, > >>> and then be migrated to any other host in the cluster. > >>> I have done the initial patches: allow creation ISO domain on > >>> localfs > >>> [1] and support import ISO domain on localfs [2] > >>> I don't have much experience in java/j2ee/web development and > >>> engine > >>> architecture. The patches just work for me. > >>> I am not sure if it will bring some potential problems. So any > >>> feedback on the patch or the idea will be appreciated very much. > >> > >> Haven't looked at the patches yet, but wrt the idea, I agree on > >> the > >> need (being able to attach ISOs from anywhere and not just nfs) > >> but I > >> think the way to do this should be by getting rid of the ISO > >> domain > >> type altogether. > > > > I think ISO domain on localfs is useful for a simple setup or demo, > > such as oVirt all-in-one. > > > >> Basically what we need is: > >> 1. a way to connect to file based storage (let's leave block aside > >> for now) - this already exists via the connectStorageServer verb > >> 2. a way to list and present a file system tree in gui (give an > >> arbitrary path to vdsm and list content) and possibly filter > >> results > >> by type (vfd, iso) - does not exist today. Possibly some security > >> aspects here that need hashing out. > >> 3. a way to specify a path to a file when attaching an iso/vfd to > >> a > >> VM - this is the way it works today > >> > >> This would devoid the need for isoUploader and allow users to > >> simply > >> manage an nfs export with files. > >> Next step would be to make connectStorageServer support httpfs [1] > >> and then we'd be able to mount ISOs directly over http (hopefully > >> this would be sufficient to support ISOs stored on S3, swift, > >> glance, > >> etc). > > > > Actually, we could use the qemu curl backend image support > > directly. > > That means we don't need mount the place storing ISO images. We can > > just maintain a list of ISO image with its link, which could be > > http, > > ftp and ssh. > > That will be fine to start a VM on a existing extern ISO image. I > also > would like to maintain a ISO image cache on the local host to avoid > to > re-streaming the ISO image from the ISO image repositories every > time. > That will be helpful for people who is suffered from the network > bottleneck. We have a similar requirement for glance support (not limited to ISOs, rather to all read-only images) so that should be tackled with a broader solution. > > > > >> > >> [1] http://httpfs.sourceforge.net/ > >> > >>> > >>> > >>> Mark. > >>> > >>> [1] http://gerrit.ovirt.org/#/c/12687/ > >>> [2] http://gerrit.ovirt.org/#/c/12916/ > >>> > >>> _______________________________________________ > >>> 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 > > > > > -- > --- > ?? Shu Ming > Open Virtualization Engineerning; CSTL, IBM Corp. > Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or > shuming at linux.vnet.ibm.com > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian > District, Beijing 100193, PRC > > > From wudxw at linux.vnet.ibm.com Mon Mar 18 08:47:43 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Mon, 18 Mar 2013 16:47:43 +0800 Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. In-Reply-To: <5146BE18.2000306@linux.vnet.ibm.com> References: <513D9EFD.7000305@linux.vnet.ibm.com> <819999290.9188868.1363529575167.JavaMail.root@redhat.com> <51468A62.2010602@linux.vnet.ibm.com> <5146BE18.2000306@linux.vnet.ibm.com> Message-ID: <5146D4AF.2080505@linux.vnet.ibm.com> On 03/18/2013 03:11 PM, Shu Ming wrote: > Mark Wu : >> On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: >>> >>> >>> ----- Original Message ----- >>>> >>>> Hi guys, >>>> >>>> Currently, ISO domain is only supported on NFS storage. It could >>>> improve the ease of use if it allows other types >>>> of file based storage to store ISO images. After an investigation, I >>>> found there's not any restriction on this idea. >>>> So the whole work is removing the limitation on engine side. That >>>> means engine should allow ISO domain could >>>> have different storage type from the data center it's attached, like >>>> what we do with nfs ISO domain in SAN DC. >>>> >>>> I start this idea with localfs. I know local storage can't be seen in >>>> cluster level. But it also provides a choice if no >>>> NFS available. VMs can be created on the host which has the ISO repo, >>>> and then be migrated to any other host in the cluster. >>>> I have done the initial patches: allow creation ISO domain on localfs >>>> [1] and support import ISO domain on localfs [2] >>>> I don't have much experience in java/j2ee/web development and engine >>>> architecture. The patches just work for me. >>>> I am not sure if it will bring some potential problems. So any >>>> feedback on the patch or the idea will be appreciated very much. >>> >>> Haven't looked at the patches yet, but wrt the idea, I agree on the >>> need (being able to attach ISOs from anywhere and not just nfs) but >>> I think the way to do this should be by getting rid of the ISO >>> domain type altogether. >> >> I think ISO domain on localfs is useful for a simple setup or demo, >> such as oVirt all-in-one. >> >>> Basically what we need is: >>> 1. a way to connect to file based storage (let's leave block aside >>> for now) - this already exists via the connectStorageServer verb >>> 2. a way to list and present a file system tree in gui (give an >>> arbitrary path to vdsm and list content) and possibly filter results >>> by type (vfd, iso) - does not exist today. Possibly some security >>> aspects here that need hashing out. >>> 3. a way to specify a path to a file when attaching an iso/vfd to a >>> VM - this is the way it works today >>> >>> This would devoid the need for isoUploader and allow users to simply >>> manage an nfs export with files. >>> Next step would be to make connectStorageServer support httpfs [1] >>> and then we'd be able to mount ISOs directly over http (hopefully >>> this would be sufficient to support ISOs stored on S3, swift, >>> glance, etc). >> >> Actually, we could use the qemu curl backend image support directly. >> That means we don't need mount the place storing ISO images. We can >> just maintain a list of ISO image with its link, which could be http, >> ftp and ssh. > > That will be fine to start a VM on a existing extern ISO image. I also > would like to maintain a ISO image cache on the local host to avoid to > re-streaming the ISO image from the ISO image repositories every time. > That will be helpful for people who is suffered from the network > bottleneck. I think this problem could be avoided by using VM template. It will significantly reduce the number of access on remote ISO images. > >> >>> >>> [1] http://httpfs.sourceforge.net/ >>> >>>> >>>> >>>> Mark. >>>> >>>> [1] http://gerrit.ovirt.org/#/c/12687/ >>>> [2] http://gerrit.ovirt.org/#/c/12916/ >>>> >>>> _______________________________________________ >>>> 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 Mon Mar 18 09:14:42 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Mon, 18 Mar 2013 17:14:42 +0800 Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. In-Reply-To: <1599625604.9482831.1363596188030.JavaMail.root@redhat.com> References: <1599625604.9482831.1363596188030.JavaMail.root@redhat.com> Message-ID: <5146DB02.2030006@linux.vnet.ibm.com> On 03/18/2013 04:43 PM, Ayal Baron wrote: > > ----- Original Message ----- >> Mark Wu : >>> On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: >>>> >>>> ----- Original Message ----- >>>>> Hi guys, >>>>> >>>>> Currently, ISO domain is only supported on NFS storage. It could >>>>> improve the ease of use if it allows other types >>>>> of file based storage to store ISO images. After an >>>>> investigation, I >>>>> found there's not any restriction on this idea. >>>>> So the whole work is removing the limitation on engine side. That >>>>> means engine should allow ISO domain could >>>>> have different storage type from the data center it's attached, >>>>> like >>>>> what we do with nfs ISO domain in SAN DC. >>>>> >>>>> I start this idea with localfs. I know local storage can't be >>>>> seen in >>>>> cluster level. But it also provides a choice if no >>>>> NFS available. VMs can be created on the host which has the ISO >>>>> repo, >>>>> and then be migrated to any other host in the cluster. >>>>> I have done the initial patches: allow creation ISO domain on >>>>> localfs >>>>> [1] and support import ISO domain on localfs [2] >>>>> I don't have much experience in java/j2ee/web development and >>>>> engine >>>>> architecture. The patches just work for me. >>>>> I am not sure if it will bring some potential problems. So any >>>>> feedback on the patch or the idea will be appreciated very much. >>>> Haven't looked at the patches yet, but wrt the idea, I agree on >>>> the >>>> need (being able to attach ISOs from anywhere and not just nfs) >>>> but I >>>> think the way to do this should be by getting rid of the ISO >>>> domain >>>> type altogether. >>> I think ISO domain on localfs is useful for a simple setup or demo, >>> such as oVirt all-in-one. >>> >>>> Basically what we need is: >>>> 1. a way to connect to file based storage (let's leave block aside >>>> for now) - this already exists via the connectStorageServer verb >>>> 2. a way to list and present a file system tree in gui (give an >>>> arbitrary path to vdsm and list content) and possibly filter >>>> results >>>> by type (vfd, iso) - does not exist today. Possibly some security >>>> aspects here that need hashing out. >>>> 3. a way to specify a path to a file when attaching an iso/vfd to >>>> a >>>> VM - this is the way it works today >>>> >>>> This would devoid the need for isoUploader and allow users to >>>> simply >>>> manage an nfs export with files. >>>> Next step would be to make connectStorageServer support httpfs [1] >>>> and then we'd be able to mount ISOs directly over http (hopefully >>>> this would be sufficient to support ISOs stored on S3, swift, >>>> glance, >>>> etc). >>> Actually, we could use the qemu curl backend image support >>> directly. >>> That means we don't need mount the place storing ISO images. We can >>> just maintain a list of ISO image with its link, which could be >>> http, >>> ftp and ssh. >> That will be fine to start a VM on a existing extern ISO image. I >> also >> would like to maintain a ISO image cache on the local host to avoid >> to >> re-streaming the ISO image from the ISO image repositories every >> time. >> That will be helpful for people who is suffered from the network >> bottleneck. > We have a similar requirement for glance support (not limited to ISOs, rather to all read-only images) so that should be tackled with a broader solution. In that case, I suppose qemu's copy-on-read + httpfs (you mentioned above) could help. It can avoid accessing the same backing file sectors repeatedly. But the copied content can't be shared by multiple VM using the same backend image. > >>>> [1] http://httpfs.sourceforge.net/ >>>> >>>>> >>>>> Mark. >>>>> >>>>> [1] http://gerrit.ovirt.org/#/c/12687/ >>>>> [2] http://gerrit.ovirt.org/#/c/12916/ >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> -- >> --- >> ?? Shu Ming >> Open Virtualization Engineerning; CSTL, IBM Corp. >> Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or >> shuming at linux.vnet.ibm.com >> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian >> District, Beijing 100193, PRC >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From abaron at redhat.com Mon Mar 18 10:11:48 2013 From: abaron at redhat.com (Ayal Baron) Date: Mon, 18 Mar 2013 06:11:48 -0400 (EDT) Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. In-Reply-To: <5146DB02.2030006@linux.vnet.ibm.com> Message-ID: <359707274.9513714.1363601508250.JavaMail.root@redhat.com> ----- Original Message ----- > > On 03/18/2013 04:43 PM, Ayal Baron wrote: > > > ----- Original Message ----- > > Mark Wu : > > On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: > > ----- Original Message ----- > > Hi guys, > > Currently, ISO domain is only supported on NFS storage. It could > improve the ease of use if it allows other types > of file based storage to store ISO images. After an > investigation, I > found there's not any restriction on this idea. > So the whole work is removing the limitation on engine side. That > means engine should allow ISO domain could > have different storage type from the data center it's attached, > like > what we do with nfs ISO domain in SAN DC. > > I start this idea with localfs. I know local storage can't be > seen in > cluster level. But it also provides a choice if no > NFS available. VMs can be created on the host which has the ISO > repo, > and then be migrated to any other host in the cluster. > I have done the initial patches: allow creation ISO domain on > localfs > [1] and support import ISO domain on localfs [2] > I don't have much experience in java/j2ee/web development and > engine > architecture. The patches just work for me. > I am not sure if it will bring some potential problems. So any > feedback on the patch or the idea will be appreciated very much. > Haven't looked at the patches yet, but wrt the idea, I agree on > the > need (being able to attach ISOs from anywhere and not just nfs) > but I > think the way to do this should be by getting rid of the ISO > domain > type altogether. I think ISO domain on localfs is useful for a simple > setup or demo, > such as oVirt all-in-one. > > Basically what we need is: > 1. a way to connect to file based storage (let's leave block aside > for now) - this already exists via the connectStorageServer verb > 2. a way to list and present a file system tree in gui (give an > arbitrary path to vdsm and list content) and possibly filter > results > by type (vfd, iso) - does not exist today. Possibly some security > aspects here that need hashing out. > 3. a way to specify a path to a file when attaching an iso/vfd to > a > VM - this is the way it works today > > This would devoid the need for isoUploader and allow users to > simply > manage an nfs export with files. > Next step would be to make connectStorageServer support httpfs [1] > and then we'd be able to mount ISOs directly over http (hopefully > this would be sufficient to support ISOs stored on S3, swift, > glance, > etc). Actually, we could use the qemu curl backend image support > directly. > That means we don't need mount the place storing ISO images. We can > just maintain a list of ISO image with its link, which could be > http, > ftp and ssh. That will be fine to start a VM on a existing extern ISO > image. I > also > would like to maintain a ISO image cache on the local host to avoid > to > re-streaming the ISO image from the ISO image repositories every > time. > That will be helpful for people who is suffered from the network > bottleneck. We have a similar requirement for glance support (not > limited to ISOs, rather to all read-only images) so that should be > tackled with a broader solution. In that case, I suppose qemu's > copy-on-read + httpfs (you mentioned above) could help. It can avoid > accessing the same backing file sectors repeatedly. > But the copied content can't be shared by multiple VM using the same > backend image. Sounds like an rfe for qemu. Basically we need to try and split the storage part in qemu to a separate process to enable such capabilities. > > > > > > > > > > [1] http://httpfs.sourceforge.net/ > > Mark. > > [1] http://gerrit.ovirt.org/#/c/12687/ [2] > http://gerrit.ovirt.org/#/c/12916/ > _______________________________________________ > 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 -- > --- > ?? Shu Ming > Open Virtualization Engineerning; CSTL, IBM Corp. > Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming at cn.ibm.com or > shuming at linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun > Software Park, Haidian > District, Beijing 100193, PRC > From alonbl at redhat.com Mon Mar 18 11:08:00 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 18 Mar 2013 07:08:00 -0400 (EDT) Subject: [Engine-devel] [ATTANTION] NetworkManager - STP In-Reply-To: <1999047671.7341241.1363604718353.JavaMail.root@redhat.com> Message-ID: <1544131180.7341394.1363604880936.JavaMail.root@redhat.com> Hello, On recent fedora-18 NetworkManager started to set default STP for the bridges to on, this is a change in the default of distribution, which up until now was off, I opened a bug[1]. If you experiencing disconnect of hosts from network due to STP detection, a workaround is available. Simply add: --- STP="off" --- To the wired interfaces (eth0, em1...) before host deployment, this will be copied to the management bridge and will prevent NetworkManager to use its default. Regards, Alon Bar-Lev. [1] https://bugzilla.redhat.com/show_bug.cgi?id=922702 From vszocs at redhat.com Mon Mar 18 12:24:23 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 18 Mar 2013 08:24:23 -0400 (EDT) Subject: [Engine-devel] restapi - domains In-Reply-To: <1363463237.24469.3.camel@cihla.usersys.redhat.com> Message-ID: <412140053.15942054.1363609463159.JavaMail.root@redhat.com> Hi, > Yeah, but you have to type domain name precisely instead of just choosing familiar one... Yes.. Just like having to type user name precisely :) it depends on what users feel more comfortable with.. Vojtech ----- Original Message ----- From: "David Ja?a" To: engine-devel at ovirt.org Sent: Saturday, March 16, 2013 8:47:17 PM Subject: Re: [Engine-devel] restapi - domains Vojtech Szocs p??e v P? 15. 03. 2013 v 14:09 -0400: > Hi, > > in WebAdmin/UserPortal GUI, it's possible to enter 'username at domain' into User Name input field. After doing this, Domain drop-down becomes disabled. This is actually how auto-login works from GUI perspective. > > So GetDomainList public query + Domain drop-down aren't really necessary for performing user login in GUI.. Yeah, but you have to type domain name precisely instead of just choosing familiar one... David > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Michael Pasternak" > Cc: "Shireesh Anjal" , engine-devel at ovirt.org > Sent: Monday, March 11, 2013 10:43:25 AM > Subject: Re: [Engine-devel] restapi - domains > > On 03/11/2013 10:37 AM, Michael Pasternak wrote: > > On 03/11/2013 10:19 AM, Shireesh Anjal wrote: > >> On 03/09/2013 12:52 AM, Itamar Heim wrote: > >>> On 03/08/2013 06:04 AM, Shireesh Anjal wrote: > >>>> On 03/07/2013 01:05 PM, Aravinda wrote: > >>>>> We can have only two fields in login screen, username and password. > >>>>> Username will include domain name(username at domain). > >>>>> > >>>>> Default domain name can be "internal" if user didn't enter the domain > >>>>> name as part of username then we can append the default value and > >>>>> validate. > >>>>> > >>>>> Note: We use username at domain as username when we connect through > >>>>> /api > >>>> > >>>> The idea is to *not* have the user type in the domain name, but rather > >>>> let him/her choose one, just like what happens in webadmin. We should > >>>> try and minimize typing as much as possible when it comes to mobile apps. > >>> > >>> I think this was done on purpose for some reason to not provide a public api for the rest api, but i could be wrong and don't remember the detail. > >>> as the concepts of multi tenancy and multiple domains grow, providing the list of domains is considered an issue, > >> > >> Is it an issue specific to restapi? For we *do show* the list of domains in webadmin login screen. > > yes, but we may want to remove that going forward and not show the > domains, as most sites don't, which allows using more domains, without > exposing them to other users. > > > > > indeed, UI using public query for that, while in api each request has to be authenticated, > > as workaround, i suggest creating internal user for this purpose and using it in the app > > (internally) to fetch entities that should not require explicit authentication from the > > application PoV. > > i assume rest api can use the public queries as well if we go that way? > > > > >> > >>> and most systems today require user to provide their full user/domain (well, usually in the form of their email address). > >>> > >>>> > >>>>> > >>>>> -- > >>>>> regards > >>>>> Aravinda > >>>>> > >>>>> On 03/07/2013 11:15 AM, Shireesh Anjal wrote: > >>>>>> Hi, > >>>>>> > >>>>>> We are trying to develop a simple android app to monitor and manage > >>>>>> gluster clusters by consuming the restapi exposed by engine. The > >>>>>> first screen is the login screen, which is similar to the webadmin > >>>>>> login screen. Here, we want to populate the combo box of "domains" by > >>>>>> fetching it from the restapi. However, the domains api cannot be > >>>>>> invoked without authentication! So we have a sort of a > >>>>>> chicken-and-egg problem. > >>>>>> > >>>>>> Any suggestions on how to tackle this? I feel the "domains" api > >>>>>> should be "public", in the sense it should not expect authentication. > >>>>>> > >>>>>> Regards, > >>>>>> Shireesh > >>>>>> _______________________________________________ > >>>>>> Engine-devel mailing list > >>>>>> Engine-devel at ovirt.org > >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>> > >>>>> _______________________________________________ > >>>>> Engine-devel mailing list > >>>>> Engine-devel at ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>> > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel at ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > _______________________________________________ > 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 -- David Ja?a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 _______________________________________________ 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 Mar 18 14:56:59 2013 From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty) Date: Mon, 18 Mar 2013 20:26:59 +0530 Subject: [Engine-devel] vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case In-Reply-To: <51472A85.9000607@linux.vnet.ibm.com> References: <51472A85.9000607@linux.vnet.ibm.com> Message-ID: <51472B3B.3090602@linux.vnet.ibm.com> I by mistake sent this earlier to users at ovirt I think the right list is engine-devel, hence resending. Sorry for the mispost earlier. -------- Original Message -------- Subject: vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case Date: Mon, 18 Mar 2013 20:23:57 +0530 From: Deepak C Shetty Organization: IBM India Pvt. Ltd. To: users at ovirt.org , Sharad Mishra Hi All, I am validating GLUSTERFS Storage domain engine patches (worked on by Sharad, in Cc) as posted here... http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:glusterfs,n,z against VDSM Glusterfs domain support (already upstream in VDSM) I see the below issue as part of me creatign a new Gluster Storage DOmain in the UI Engine logs... 2013-03-18 13:27:29,149 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (http--0.0.0.0-8700-1) [4b751967] START, ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: null, vfsType: glusterfs, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d VDSM Logs... Thread-77::INFO::2013-03-18 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=None)*--> Notice no vfs_type here !!!* VDSM doesn't recv. the vfs_type in the conList dict !!! I had this small chat with Saggi of VDSM, just to confirm that there isn't a possibility that VDSM might be stripping args that are recd. from Engine.. and it doesn't. --------------------------------------------------------------------------------------------------------------------- saggi, Hi deepakcs: hi saggi, Is it possible that VDSM might strip down some of the connparams that are recd. as part of connectStorageServer ? saggi, In engine log for GLUSTERFS_DOMAIN i see vfsType being passed, but connectStorageServer log doesn't show vfs_type in the params dict saggi, so wodering where vfs_type is getting dropped in this whole process Probably not being sent if it's not being logged saggi, engine log has this.... 2013-03-18 13:27:29,149 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (http--0.0.0.0-8700-1) [4b751967] START, ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: null, vfsType: glusterfs, mountOptions: null, nfsVersion: nul l, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d saggi, on VDSM side i see this... Thread-77::INFO::2013-03-18 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', 'port': ''}], options=None) --> Notice no vfs_type here !!! Then you are not sending the correct connection type saggi, 'you' means the engine side of code ? engine patches is being done by Sharad, and I amtrying to work with them on this issue saggi, domType=7 is GLUSTERFS_DOMAIN, so its correct on that front If it show nfsRetrans you are using nfs which doesn't have a vfs_type argument saggi, but engine log says storageType = GLUSTERFS saggi, maybe i can send mail to users at ovirt list to see if anybody can provide more clues saggi, but definitely this doesn't looks like a vdsm side of issue rite ? We log the params as we get them saggi, right, thats what i also see.. just wanted to confirm once with you, before i sent mail to ovirt folks --------------------------------------------------------------------------------------------------------------------- Can someone help provide any clues on what might be the issue here ? Because VDSM doesn't see vfs_type, the connectStorageServer fails and hence new SD cannot be created ! thanx, deepak -------------- next part -------------- An HTML attachment was scrubbed... URL: From kroberts at redhat.com Mon Mar 18 15:13:24 2013 From: kroberts at redhat.com (Keith Robertson) Date: Mon, 18 Mar 2013 11:13:24 -0400 Subject: [Engine-devel] Kiril Nesenko as a tools maintainer Message-ID: <51472F14.7000805@redhat.com> I would like to propose that we add Kiril Nesenko as a maintainer for the Ovirt ISO Uploader, Image Uploader and Log Collector. He has been enormously helpful with the maintenance of the tools. Thanks, Keith Robertson From kroberts at redhat.com Mon Mar 18 15:16:34 2013 From: kroberts at redhat.com (Keith Robertson) Date: Mon, 18 Mar 2013 11:16:34 -0400 Subject: [Engine-devel] Sandro Bonazzola as a tools maintainer Message-ID: <51472FD2.7020806@redhat.com> I would like to propose that we add Sandro Bonazzola as a maintainer for the Ovirt ISO Uploader, Image Uploader and Log Collector. He too has been enormously helpful with the maintenance of the tools. Thanks, Keith Robertson From sbonazzo at redhat.com Mon Mar 18 15:37:30 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Mon, 18 Mar 2013 16:37:30 +0100 Subject: [Engine-devel] Kiril Nesenko as a tools maintainer In-Reply-To: <51472F14.7000805@redhat.com> References: <51472F14.7000805@redhat.com> Message-ID: <514734BA.9000209@redhat.com> +1 Il 18/03/2013 16:13, Keith Robertson ha scritto: > I would like to propose that we add Kiril Nesenko as a maintainer for > the Ovirt ISO Uploader, Image Uploader and Log Collector. He has been > enormously helpful with the maintenance of the tools. > > Thanks, > Keith Robertson > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From mgoldboi at redhat.com Mon Mar 18 15:56:05 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Mon, 18 Mar 2013 17:56:05 +0200 Subject: [Engine-devel] Kiril Nesenko as a tools maintainer In-Reply-To: <51472F14.7000805@redhat.com> References: <51472F14.7000805@redhat.com> Message-ID: <51473915.3030801@redhat.com> On 03/18/2013 05:13 PM, Keith Robertson wrote: > I would like to propose that we add Kiril Nesenko as a maintainer for > the Ovirt ISO Uploader, Image Uploader and Log Collector. He has been > enormously helpful with the maintenance of the tools. > > Thanks, > Keith Robertson +1 here, i think many of the last issues faced on tools build system were enhanced and dealt in the last few months succesfully by kiril. From mgoldboi at redhat.com Mon Mar 18 15:58:18 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Mon, 18 Mar 2013 17:58:18 +0200 Subject: [Engine-devel] Sandro Bonazzola as a tools maintainer In-Reply-To: <51472FD2.7020806@redhat.com> References: <51472FD2.7020806@redhat.com> Message-ID: <5147399A.6010304@redhat.com> On 03/18/2013 05:16 PM, Keith Robertson wrote: > I would like to propose that we add Sandro Bonazzola as a maintainer > for the Ovirt ISO Uploader, Image Uploader and Log Collector. He too > has been enormously helpful with the maintenance of the tools. > > Thanks, > Keith Robertson +1 - Sandro has been taking responsibility on that area and been at the top committers for tools in the last several months. From eedri at redhat.com Mon Mar 18 17:23:09 2013 From: eedri at redhat.com (Eyal Edri) Date: Mon, 18 Mar 2013 13:23:09 -0400 (EDT) Subject: [Engine-devel] Sandro Bonazzola as a tools maintainer In-Reply-To: <51472FD2.7020806@redhat.com> Message-ID: <1895081042.20447734.1363627389778.JavaMail.root@redhat.com> +1, i know sandro and familiar with his major contribution in the past few months to the tools code. Eyal. ----- Original Message ----- > From: "Keith Robertson" > To: engine-devel at ovirt.org > Sent: Monday, March 18, 2013 5:16:34 PM > Subject: [Engine-devel] Sandro Bonazzola as a tools maintainer > > I would like to propose that we add Sandro Bonazzola as a maintainer > for > the Ovirt ISO Uploader, Image Uploader and Log Collector. He too has > been enormously helpful with the maintenance of the tools. > > Thanks, > Keith Robertson > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From eedri at redhat.com Mon Mar 18 18:30:40 2013 From: eedri at redhat.com (Eyal Edri) Date: Mon, 18 Mar 2013 14:30:40 -0400 (EDT) Subject: [Engine-devel] Kiril Nesenko as a tools maintainer In-Reply-To: <51472F14.7000805@redhat.com> Message-ID: <1301644333.20478393.1363631440328.JavaMail.root@redhat.com> +1, kiril has been building and contributing to these oVirt tools for some time now. ----- Original Message ----- > From: "Keith Robertson" > To: engine-devel at ovirt.org > Cc: "Kiril Nesenko" > Sent: Monday, March 18, 2013 5:13:24 PM > Subject: [Engine-devel] Kiril Nesenko as a tools maintainer > > I would like to propose that we add Kiril Nesenko as a maintainer for > the Ovirt ISO Uploader, Image Uploader and Log Collector. He has > been > enormously helpful with the maintenance of the tools. > > Thanks, > Keith Robertson > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From wudxw at linux.vnet.ibm.com Tue Mar 19 02:45:24 2013 From: wudxw at linux.vnet.ibm.com (Mark Wu) Date: Tue, 19 Mar 2013 10:45:24 +0800 Subject: [Engine-devel] vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case In-Reply-To: <51472B3B.3090602@linux.vnet.ibm.com> References: <51472A85.9000607@linux.vnet.ibm.com> <51472B3B.3090602@linux.vnet.ibm.com> Message-ID: <5147D144.9050504@linux.vnet.ibm.com> Deepak, I suspect it's related to the following code snippet. // storage_pool can be null when discovering iscsi send targets or when connecting // through vds which has no storage pool if (storage_pool == null || Config. GetValue(ConfigValues.AdvancedNFSOptionsEnabled, storage_pool.getcompatibility_version().getValue())) { // For mnt_options, vfs_type, and protocol_version - if they are null // or empty we should not send a key with an empty value ... con.putIfNotEmpty("vfs_type", connection.getVfsType()); ... } If my understanding is correct, AdvancedNFSOptionsEnabled is true only for DC 3.1 and 3.2. What's your DC version? It should be 3.2, otherwise it could not be compatible with glusterfs domain. Anyway, you could add some debugging code to see if the 'vfsType' options is added to parameters. You also could use wireshark confirm if it's sent by ovirt-engine. Of course, you need disable SSL at first before capturing packets. Don't blame me if it doesn't help at all. :-) Mark. On Mon 18 Mar 2013 10:56:59 PM CST, Deepak C Shetty wrote: > I by mistake sent this earlier to users at ovirt > I think the right list is engine-devel, hence resending. Sorry for the > mispost earlier. > > > -------- Original Message -------- > Subject: vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN > case > Date: Mon, 18 Mar 2013 20:23:57 +0530 > From: Deepak C Shetty > Organization: IBM India Pvt. Ltd. > To: users at ovirt.org , Sharad Mishra > > > > > Hi All, > I am validating GLUSTERFS Storage domain engine patches (worked on > by Sharad, in Cc) as posted here... > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:glusterfs,n,z > against VDSM Glusterfs domain support (already upstream in VDSM) > > I see the below issue as part of me creatign a new Gluster Storage > DOmain in the UI > > Engine logs... > > 2013-03-18 13:27:29,149 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] > (http--0.0.0.0-8700-1) [4b751967] START, > ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = > c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = > 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, > connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: > null, vfsType: glusterfs, mountOptions: null, nfsVersion: null, > nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d > > VDSM Logs... > > Thread-77::INFO::2013-03-18 > 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: > connectStorageServer(domType=7, > spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': > 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', > 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', > 'port': ''}], options=None)*--> Notice no vfs_type here !!!* > > VDSM doesn't recv. the vfs_type in the conList dict !!! > > I had this small chat with Saggi of VDSM, just to confirm that there > isn't a possibility that VDSM might be stripping args that are recd. > from Engine.. and it doesn't. > > > --------------------------------------------------------------------------------------------------------------------- > saggi, Hi > deepakcs: hi > > saggi, Is it possible that VDSM might strip down some of > the connparams that are recd. as part of connectStorageServer ? > saggi, In engine log for GLUSTERFS_DOMAIN i see vfsType > being passed, but connectStorageServer log doesn't show vfs_type in > the params dict > saggi, so wodering where vfs_type is getting dropped in > this whole process > Probably not being sent > if it's not being logged > saggi, engine log has this.... > 2013-03-18 13:27:29,149 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] > (http--0.0.0.0-8700-1) [4b751967] START, > ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = > c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = > 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, > connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: > null, vfsType: glusterfs, mountOptions: null, nfsVersion: nul > l, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d > saggi, on VDSM side i see this... > Thread-77::INFO::2013-03-18 > 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: > connectStorageServer(domType=7, > spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': > 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', > 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', > 'port': ''}], options=None) --> Notice no vfs_type here !!! > Then you are not sending the correct connection type > > saggi, 'you' means the engine side of code ? engine patches > is being done by Sharad, and I amtrying to work with them on this issue > > saggi, domType=7 is GLUSTERFS_DOMAIN, so its correct on > that front > If it show nfsRetrans you are using nfs which doesn't have a > vfs_type argument > saggi, but engine log says storageType = GLUSTERFS > saggi, maybe i can send mail to users at ovirt list to see if > anybody can provide more clues > saggi, but definitely this doesn't looks like a vdsm side > of issue rite ? > We log the params as we get them > > saggi, right, thats what i also see.. just wanted to > confirm once with you, before i sent mail to ovirt folks > > --------------------------------------------------------------------------------------------------------------------- > > > Can someone help provide any clues on what might be the issue here ? > Because VDSM doesn't see vfs_type, the connectStorageServer fails and > hence new SD cannot be created ! > > thanx, > deepak > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From snmishra at us.ibm.com Tue Mar 19 03:46:05 2013 From: snmishra at us.ibm.com (Sharad Mishra) Date: Mon, 18 Mar 2013 20:46:05 -0700 Subject: [Engine-devel] vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case In-Reply-To: <5147D144.9050504@linux.vnet.ibm.com> References: <51472A85.9000607@linux.vnet.ibm.com> <51472B3B.3090602@linux.vnet.ibm.com> <5147D144.9050504@linux.vnet.ibm.com> Message-ID: Mark, You are correct. The issue was with that piece of code. A patch has been posted to fix it - http://gerrit.ovirt.org/#/c/13155/ Thanks Sharad Mishra Open Virtualization Linux Technology Center IBM From: Mark Wu To: Deepak C Shetty , Cc: "engine-devel at ovirt.org" , Sharad Mishra/Beaverton/IBM at IBMUS Date: 03/18/13 07:45 PM Subject: Re: [Engine-devel] vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN case Deepak, I suspect it's related to the following code snippet. // storage_pool can be null when discovering iscsi send targets or when connecting // through vds which has no storage pool if (storage_pool == null || Config. GetValue(ConfigValues.AdvancedNFSOptionsEnabled, storage_pool.getcompatibility_version().getValue())) { // For mnt_options, vfs_type, and protocol_version - if they are null // or empty we should not send a key with an empty value ... con.putIfNotEmpty("vfs_type", connection.getVfsType()); ... } If my understanding is correct, AdvancedNFSOptionsEnabled is true only for DC 3.1 and 3.2. What's your DC version? It should be 3.2, otherwise it could not be compatible with glusterfs domain. Anyway, you could add some debugging code to see if the 'vfsType' options is added to parameters. You also could use wireshark confirm if it's sent by ovirt-engine. Of course, you need disable SSL at first before capturing packets. Don't blame me if it doesn't help at all. :-) Mark. On Mon 18 Mar 2013 10:56:59 PM CST, Deepak C Shetty wrote: > I by mistake sent this earlier to users at ovirt > I think the right list is engine-devel, hence resending. Sorry for the > mispost earlier. > > > -------- Original Message -------- > Subject: vfs_type not being sent by engine to VDSM for GLUSTER DOMAIN > case > Date: Mon, 18 Mar 2013 20:23:57 +0530 > From: Deepak C Shetty > Organization: IBM India Pvt. Ltd. > To: users at ovirt.org , Sharad Mishra > > > > > Hi All, > I am validating GLUSTERFS Storage domain engine patches (worked on > by Sharad, in Cc) as posted here... > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine +branch:master+topic:glusterfs,n,z > against VDSM Glusterfs domain support (already upstream in VDSM) > > I see the below issue as part of me creatign a new Gluster Storage > DOmain in the UI > > Engine logs... > > 2013-03-18 13:27:29,149 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] > (http--0.0.0.0-8700-1) [4b751967] START, > ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = > c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = > 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, > connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: > null, vfsType: glusterfs, mountOptions: null, nfsVersion: null, > nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d > > VDSM Logs... > > Thread-77::INFO::2013-03-18 > 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: > connectStorageServer(domType=7, > spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': > 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', > 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', > 'port': ''}], options=None)*--> Notice no vfs_type here !!!* > > VDSM doesn't recv. the vfs_type in the conList dict !!! > > I had this small chat with Saggi of VDSM, just to confirm that there > isn't a possibility that VDSM might be stripping args that are recd. > from Engine.. and it doesn't. > > > --------------------------------------------------------------------------------------------------------------------- > saggi, Hi > deepakcs: hi > > saggi, Is it possible that VDSM might strip down some of > the connparams that are recd. as part of connectStorageServer ? > saggi, In engine log for GLUSTERFS_DOMAIN i see vfsType > being passed, but connectStorageServer log doesn't show vfs_type in > the params dict > saggi, so wodering where vfs_type is getting dropped in > this whole process > Probably not being sent > if it's not being logged > saggi, engine log has this.... > 2013-03-18 13:27:29,149 INFO > [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] > (http--0.0.0.0-8700-1) [4b751967] START, > ConnectStorageServerVDSCommand(HostName = vm-vdsm-de-1, HostId = > c0ff5edc-4e30-4553-9125-2d1cee9f19ec, storagePoolId = > 00000000-0000-0000-0000-000000000000, storageType = GLUSTERFS, > connectionList = [{ id: null, connection: vm-vdsm-de-1:dpkvol4, iqn: > null, vfsType: glusterfs, mountOptions: null, nfsVersion: nul > l, nfsRetrans: null, nfsTimeo: null };]), log id: f88d42d > saggi, on VDSM side i see this... > Thread-77::INFO::2013-03-18 > 13:32:35,541::logUtils::44::dispatcher::(wrapper) Run and protect: > connectStorageServer(domType=7, > spUUID='00000000-0000-0000-0000-000000000000', conList=[{'connection': > 'vm-vdsm-de-1:dpkvol4', 'iqn': '', 'portal': '', 'user': '', > 'password': '******', 'id': '00000000-0000-0000-0000-000000000000', > 'port': ''}], options=None) --> Notice no vfs_type here !!! > Then you are not sending the correct connection type > > saggi, 'you' means the engine side of code ? engine patches > is being done by Sharad, and I amtrying to work with them on this issue > > saggi, domType=7 is GLUSTERFS_DOMAIN, so its correct on > that front > If it show nfsRetrans you are using nfs which doesn't have a > vfs_type argument > saggi, but engine log says storageType = GLUSTERFS > saggi, maybe i can send mail to users at ovirt list to see if > anybody can provide more clues > saggi, but definitely this doesn't looks like a vdsm side > of issue rite ? > We log the params as we get them > > saggi, right, thats what i also see.. just wanted to > confirm once with you, before i sent mail to ovirt folks > > --------------------------------------------------------------------------------------------------------------------- > > > Can someone help provide any clues on what might be the issue here ? > Because VDSM doesn't see vfs_type, the connectStorageServer fails and > hence new SD cannot be created ! > > thanx, > deepak > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From vszocs at redhat.com Tue Mar 19 16:30:36 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Tue, 19 Mar 2013 12:30:36 -0400 (EDT) Subject: [Engine-devel] Controlling GWT compiler JVM arguments In-Reply-To: <1705149775.16608600.1363710236522.JavaMail.root@redhat.com> Message-ID: <2124972237.16611375.1363710636390.JavaMail.root@redhat.com> Hi guys, for those of you getting "Exception: java.lang.OutOfMemoryError" or similar errors during GWT compilation of WebAdmin/UserPortal, it's now possible to override default JVM arguments for GWT compiler via command line. For example: $ mvn clean install -Pdep,gwt-admin,gwt-user -Dgwt-plugin.extraJvmArgs="-Xms1024M -Xmx2048M -XX:PermSize=256M -XX:MaxPermSize=512M" Note: you can find default "gwt-plugin.extraJvmArgs" value in $OVIRT_HOME/frontend/webadmin/modules/pom.xml Regards, Vojtech From grawert at b1-systems.de Tue Mar 19 17:44:17 2013 From: grawert at b1-systems.de (Uwe Grawert) Date: Tue, 19 Mar 2013 18:44:17 +0100 Subject: [Engine-devel] Adding support for OpenLDAP to oVirt Message-ID: <660E0DFF-5540-4F7F-A0BE-12A77D612CEE@b1-systems.de> Hello together, regarding support for OpenLDAP as domain provider I found this mail from last year on ovirt-users list :http://lists.ovirt.org/pipermail/users/2012-July/002791.html I would like to add support for OpenLDAP to oVirt. As a start I had a look at ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/adbroker/ITDS* which seems to be very similar to the RHDS classes. I simply copied all ITDS*.java files to OpenLdap*.java and changed class names and so forth from ITDS/itds to OpenLdap/openLdap. I also changed user and group attributes to make sense for OpenLDAP. Additionally I enhanced the LdapQueryMetadataFactoryImpl class, again copying mostly from ITDS and others. To the very last I enhanced the enum at ovirt-engine/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/ldap/LdapProviderType.java with an OpenLDAP entry. Right now I do not oversee the whole LDAPBroker code. Especially I do not know how enum at LdapProviderType.java is related the code found at bll/adbroker/*. Could you please give me some guidance and advise, if I am on the right track? I could also send a diff of all changes to the list, if that is helpful. Thanks very much. From iheim at redhat.com Tue Mar 19 21:48:51 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 19 Mar 2013 23:48:51 +0200 Subject: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested In-Reply-To: <1985267630.7169027.1363370841010.JavaMail.root@redhat.com> References: <1985267630.7169027.1363370841010.JavaMail.root@redhat.com> Message-ID: <5148DD43.6020605@redhat.com> On 03/15/2013 08:07 PM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Jiri Belka" >> Cc: engine-devel at ovirt.org, Users at ovirt.org >> Sent: Friday, March 15, 2013 1:27:32 PM >> Subject: Re: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested >> >> On 03/14/2013 04:55 PM, Jiri Belka wrote: >>> On Thu, 14 Mar 2013 14:44:48 +0002 >>> Alex Lourie wrote: >>> >>>> Hi Jiri >>>> >>>> On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka >>>> wrote: >>>>> I'll talk about RHEVM but it's probably related to oVirt too. >>>>> >>>>> As rhevm installs all deps, I'm curious why versionlock.list is >>>>> populated after rhevm-setup and _not_dirrectly during >>>>> installation >>>>> (maybe because you would need to hardcode versions into rhevm >>>>> package?). It took me tens of minutes to figure out why is >>>>> upgrade >>>>> working differently now, just because I did _NOT_ do rhevm-setup >>>>> after >>>>> clean install because I was thinking I know what files are >>>>> important >>>>> and was restoring them from a tarball. >>>>> >>>>> I think running rhevm-setup if you just want to restore is >>>>> stupid. If >>>>> we would know 100% which files are involved, just install, >>>>> restore >>>>> from >>>>> backup, restore DB should be sufficient, without loosing time >>>>> with >>>>> rhevm-setup which just writes there and here... :) >>>>> >>>> >>>> I don't really follow you here. What are you restoring with >>>> rhevm-setup? >>> >>> My previous (wrong) procedure to restore old version was: >>> >>> rhevm-cleanup, yum remove rhevm\*, rm -rf $dirs, yum install >>> rhevm\*, >>> tar xvzpf /backup.tgz, ./restore.sh for DB... >>> >>> which was not fully correct as I haven't >>> known /etc/yum/plugin.d/versionlock.list is touched by rhevm-setup >>> as >>> well and thus yum was working very strange during next normal >>> upgrade. >>> _______________________________________________ >>> Users mailing list >>> Users at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> >> moran/ofer - i remember some discussions on moving from version lock >> to >> a yum plugin. i.e., yum will not update the packages if not getting >> some >> parameter from engine-upgrade (but will show updates exist), but they >> will behave normally other than that? > > We cannot mention yum specific features in setup context any more... this is part of the mission. > > We should reconsider the locking of version - no product uses this. > > After upgrade of packages, product should either know not to start or upgrade the database when restarted, or better know to work with older schema. > > The version lock should be removed as soon as possible. > > Alon > I think we can remove the version lock (after relevant preparations/changes) I still think a yum plugin to not yum update rpms which are part of the engine without a special script/yum paramter invoking them) is worthwhile, since i don't like the concept of someone running yum update, only to find out the upgrade had an issue a week later when restarting the service. From alonbl at redhat.com Tue Mar 19 21:54:20 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 19 Mar 2013 17:54:20 -0400 (EDT) Subject: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested In-Reply-To: <5148DD43.6020605@redhat.com> Message-ID: <112177286.7867896.1363730060030.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org, Users at ovirt.org, "Jiri Belka" > Sent: Tuesday, March 19, 2013 11:48:51 PM > Subject: Re: [Engine-devel] [Users] Features requests for the setup/configuration utilities - feedback requested > > On 03/15/2013 08:07 PM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > >> From: "Itamar Heim" > >> To: "Jiri Belka" > >> Cc: engine-devel at ovirt.org, Users at ovirt.org > >> Sent: Friday, March 15, 2013 1:27:32 PM > >> Subject: Re: [Engine-devel] [Users] Features requests for the > >> setup/configuration utilities - feedback requested > >> > >> On 03/14/2013 04:55 PM, Jiri Belka wrote: > >>> On Thu, 14 Mar 2013 14:44:48 +0002 > >>> Alex Lourie wrote: > >>> > >>>> Hi Jiri > >>>> > >>>> On Thu, Mar 14, 2013 at 4:30 PM, Jiri Belka > >>>> wrote: > >>>>> I'll talk about RHEVM but it's probably related to oVirt too. > >>>>> > >>>>> As rhevm installs all deps, I'm curious why versionlock.list is > >>>>> populated after rhevm-setup and _not_dirrectly during > >>>>> installation > >>>>> (maybe because you would need to hardcode versions into rhevm > >>>>> package?). It took me tens of minutes to figure out why is > >>>>> upgrade > >>>>> working differently now, just because I did _NOT_ do > >>>>> rhevm-setup > >>>>> after > >>>>> clean install because I was thinking I know what files are > >>>>> important > >>>>> and was restoring them from a tarball. > >>>>> > >>>>> I think running rhevm-setup if you just want to restore is > >>>>> stupid. If > >>>>> we would know 100% which files are involved, just install, > >>>>> restore > >>>>> from > >>>>> backup, restore DB should be sufficient, without loosing time > >>>>> with > >>>>> rhevm-setup which just writes there and here... :) > >>>>> > >>>> > >>>> I don't really follow you here. What are you restoring with > >>>> rhevm-setup? > >>> > >>> My previous (wrong) procedure to restore old version was: > >>> > >>> rhevm-cleanup, yum remove rhevm\*, rm -rf $dirs, yum install > >>> rhevm\*, > >>> tar xvzpf /backup.tgz, ./restore.sh for DB... > >>> > >>> which was not fully correct as I haven't > >>> known /etc/yum/plugin.d/versionlock.list is touched by > >>> rhevm-setup > >>> as > >>> well and thus yum was working very strange during next normal > >>> upgrade. > >>> _______________________________________________ > >>> Users mailing list > >>> Users at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/users > >>> > >> > >> moran/ofer - i remember some discussions on moving from version > >> lock > >> to > >> a yum plugin. i.e., yum will not update the packages if not > >> getting > >> some > >> parameter from engine-upgrade (but will show updates exist), but > >> they > >> will behave normally other than that? > > > > We cannot mention yum specific features in setup context any > > more... this is part of the mission. > > > > We should reconsider the locking of version - no product uses this. > > > > After upgrade of packages, product should either know not to start > > or upgrade the database when restarted, or better know to work > > with older schema. > > > > The version lock should be removed as soon as possible. > > > > Alon > > > > I think we can remove the version lock (after relevant > preparations/changes) Great! > I still think a yum plugin to not yum update rpms which are part of > the > engine without a special script/yum paramter invoking them) is > worthwhile, since i don't like the concept of someone running yum > update, only to find out the upgrade had an issue a week later when > restarting the service. If we do not want to stop engine service on rpm installation, we can have some kind of notification in engine that the software was updated and a restart is required. Alon From yzaslavs at redhat.com Wed Mar 20 07:24:26 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Wed, 20 Mar 2013 03:24:26 -0400 (EDT) Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <660E0DFF-5540-4F7F-A0BE-12A77D612CEE@b1-systems.de> Message-ID: <1306212127.11402563.1363764266120.JavaMail.root@redhat.com> Hi Uwe, Bare in mind we have some plans for refactoring/changing the authentication module. However, for the meanwhile - we will be very happy if you can assist in adding this support. I would like to introduce you to a Wiki that Oved Ourfali has written about the subject - http://www.ovirt.org/DomainInfrastructure Please let us know if this helps you with your questions. kind regards, Yair ----- Original Message ----- > From: "Uwe Grawert" > To: engine-devel at ovirt.org > Sent: Tuesday, March 19, 2013 7:44:17 PM > Subject: [Engine-devel] Adding support for OpenLDAP to oVirt > > Hello together, > > regarding support for OpenLDAP as domain provider I found this mail > from last year on ovirt-users list > :http://lists.ovirt.org/pipermail/users/2012-July/002791.html > > I would like to add support for OpenLDAP to oVirt. As a start I had a > look at > ovirt-engine/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/adbroker/ITDS* > which seems to be very similar to the RHDS classes. > > I simply copied all ITDS*.java files to OpenLdap*.java and changed > class names and so forth from ITDS/itds to OpenLdap/openLdap. I also > changed user and group attributes to make sense for OpenLDAP. > Additionally I enhanced the LdapQueryMetadataFactoryImpl class, > again copying mostly from ITDS and others. > > To the very last I enhanced the enum at > ovirt-engine/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/ldap/LdapProviderType.java > with an OpenLDAP entry. > > Right now I do not oversee the whole LDAPBroker code. Especially I do > not know how enum at LdapProviderType.java is related the code found > at bll/adbroker/*. > > Could you please give me some guidance and advise, if I am on the > right track? I could also send a diff of all changes to the list, if > that is helpful. Thanks very much. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alourie at redhat.com Wed Mar 20 10:32:38 2013 From: alourie at redhat.com (Alex Lourie) Date: Wed, 20 Mar 2013 10:34:38 +0002 Subject: [Engine-devel] Kiril Nesenko as a tools maintainer In-Reply-To: <1301644333.20478393.1363631440328.JavaMail.root@redhat.com> References: <1301644333.20478393.1363631440328.JavaMail.root@redhat.com> Message-ID: <201303201032.r2KAWc7Z029726@int-mx12.intmail.prod.int.phx2.redhat.com> +1 Kiril had considerably contributed to the maintenance and build process of these tools. From alourie at redhat.com Wed Mar 20 10:33:28 2013 From: alourie at redhat.com (Alex Lourie) Date: Wed, 20 Mar 2013 10:35:28 +0002 Subject: [Engine-devel] Sandro Bonazzola as a tools maintainer In-Reply-To: <1895081042.20447734.1363627389778.JavaMail.root@redhat.com> References: <1895081042.20447734.1363627389778.JavaMail.root@redhat.com> Message-ID: <201303201033.r2KAXScd017564@int-mx10.intmail.prod.int.phx2.redhat.com> +1 Sandro knows the tools well and he's a great collaborator. From oschreib at redhat.com Wed Mar 20 14:23:49 2013 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 20 Mar 2013 10:23:49 -0400 (EDT) Subject: [Engine-devel] Sandro Bonazzola as a tools maintainer In-Reply-To: <51472FD2.7020806@redhat.com> Message-ID: <1127688207.3914753.1363789429350.JavaMail.root@redhat.com> +1 ----- Original Message ----- > I would like to propose that we add Sandro Bonazzola as a maintainer > for > the Ovirt ISO Uploader, Image Uploader and Log Collector. He too has > been enormously helpful with the maintenance of the tools. > > Thanks, > Keith Robertson > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From oschreib at redhat.com Wed Mar 20 14:24:04 2013 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 20 Mar 2013 10:24:04 -0400 (EDT) Subject: [Engine-devel] Kiril Nesenko as a tools maintainer In-Reply-To: <51472F14.7000805@redhat.com> Message-ID: <186002530.3914823.1363789444573.JavaMail.root@redhat.com> +1 ----- Original Message ----- > I would like to propose that we add Kiril Nesenko as a maintainer for > the Ovirt ISO Uploader, Image Uploader and Log Collector. He has > been > enormously helpful with the maintenance of the tools. > > Thanks, > Keith Robertson > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From sanjal at redhat.com Wed Mar 20 14:47:08 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Wed, 20 Mar 2013 20:17:08 +0530 Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <5146C52D.2090903@redhat.com> References: <1886045500.2100242.1363591774667.JavaMail.root@redhat.com> <5146C52D.2090903@redhat.com> Message-ID: <5149CBEC.9050507@redhat.com> On 03/18/2013 01:11 PM, Shireesh Anjal wrote: > On 03/18/2013 12:59 PM, Mike Kolesnik wrote: >> ----- Original Message ----- >>> Hi all, >>> >>> The current mechanism in oVirt to check whether a feature is >>> supported >>> in a particular compatibility version is to use the FeatureSupported >>> class. e.g. >>> >>> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) >>> >>> >>> Checks whether the "network linking" feature is supported for the the >>> VM's cluster compatibility version. This internally checks whether >>> the >>> value of the corresponding config (NetworkLinkingSupported) for the >>> given compatibility version is true/false. >>> >>> I'm not sure if this is a good idea, since a feature is typically >>> supported "from" a particular version. E.g. Gluster support was >>> introduced in 3.1, and it continues to be available in all subsequent >>> versions. So I see no point in adding configuration for every version >>> indicating whether the feature is supported in that version or not. I >>> suggest to use either of the following options: >> You can "merge" the configs into a single config when older versions >> go out of the supported versions for the system. >> >> i.e. in 4.0 you can have upgrade script that merges all >> GlusterFeatureSupported to one entry instead of several. Why are we even storing this information in config? Is this something that can be "configured" at customer site? >> >>> 1) Instead of using a boolean config for each version, use a single >>> string config that indicates the "supported from" version e.g. >>> GlusterSupportedFrom = 3.1. There could be rare cases where a >>> feature, >>> for some reason, is removed in some release. In such cases, we could >>> use >>> one additional config for the "supported to" version. >>> >>> 2) Continue with the boolean approach, but do not have entries for >>> every >>> version; rather make use of the "default value" for majority of >>> cases, >>> and add the explicit version mapping for the minority e.g. >>> GlusterSupported = true by default, and false in case of 3.0 (only >>> one >>> config required for 3.0) >> I'm not sure why we would want to complicate this simple mechanism? >> >> Is there much to gain? > > I think option 1 suggested above is simpler - to implement as well as > to understand. > > Let me give you an example of why I don't like current mechanism. I > introduce a version check for a feature that was introduced in 3.1. > I'm being asked now to add three entries in config > > 3.0 - false > 3.1 - true > 3.2 - true > > It will also mean that when 3.3 goes out, someone has to make sure > that another entry is added for 3.3-true. I think it is not logical as > well as scalable if you have more versions. And it sounds far more > complex (to maintain) than just having > > SupportedFrom = 3.1 > > So I would like to know if there are any objections to my proposal. I > intend to use this for at least the gluster related features. > >>> Thoughts? >>> >>> Regards, >>> Shireesh >>> _______________________________________________ >>> 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 Wed Mar 20 14:50:45 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Wed, 20 Mar 2013 10:50:45 -0400 (EDT) Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <5149CBEC.9050507@redhat.com> Message-ID: <1321805680.12000513.1363791045560.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Shireesh Anjal" > To: "Mike Kolesnik" > Cc: engine-devel at ovirt.org > Sent: Wednesday, March 20, 2013 4:47:08 PM > Subject: Re: [Engine-devel] FeatureSupported and compatibility versions > > On 03/18/2013 01:11 PM, Shireesh Anjal wrote: > > On 03/18/2013 12:59 PM, Mike Kolesnik wrote: > >> ----- Original Message ----- > >>> Hi all, > >>> > >>> The current mechanism in oVirt to check whether a feature is > >>> supported > >>> in a particular compatibility version is to use the > >>> FeatureSupported > >>> class. e.g. > >>> > >>> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) > >>> > >>> > >>> Checks whether the "network linking" feature is supported for the > >>> the > >>> VM's cluster compatibility version. This internally checks > >>> whether > >>> the > >>> value of the corresponding config (NetworkLinkingSupported) for > >>> the > >>> given compatibility version is true/false. > >>> > >>> I'm not sure if this is a good idea, since a feature is typically > >>> supported "from" a particular version. E.g. Gluster support was > >>> introduced in 3.1, and it continues to be available in all > >>> subsequent > >>> versions. So I see no point in adding configuration for every > >>> version > >>> indicating whether the feature is supported in that version or > >>> not. I > >>> suggest to use either of the following options: > >> You can "merge" the configs into a single config when older > >> versions > >> go out of the supported versions for the system. > >> > >> i.e. in 4.0 you can have upgrade script that merges all > >> GlusterFeatureSupported to one entry instead of several. > > Why are we even storing this information in config? Is this something > that can be "configured" at customer site? As previously explained (but off list :) ) , Config gives you the ability to have a cachable "map" of entry (i.e - "feature name") per version and value. I guess it was convinient for the developers to use that. I also mentioned that customers/oVirt users should config the entries of vdc_options using engine-config tool only. Not all entries are exposed via engine-config.properties (and no, not just "is feature supported" entries are hidden). > > >> > >>> 1) Instead of using a boolean config for each version, use a > >>> single > >>> string config that indicates the "supported from" version e.g. > >>> GlusterSupportedFrom = 3.1. There could be rare cases where a > >>> feature, > >>> for some reason, is removed in some release. In such cases, we > >>> could > >>> use > >>> one additional config for the "supported to" version. > >>> > >>> 2) Continue with the boolean approach, but do not have entries > >>> for > >>> every > >>> version; rather make use of the "default value" for majority of > >>> cases, > >>> and add the explicit version mapping for the minority e.g. > >>> GlusterSupported = true by default, and false in case of 3.0 > >>> (only > >>> one > >>> config required for 3.0) > >> I'm not sure why we would want to complicate this simple > >> mechanism? > >> > >> Is there much to gain? > > > > I think option 1 suggested above is simpler - to implement as well > > as > > to understand. > > > > Let me give you an example of why I don't like current mechanism. I > > introduce a version check for a feature that was introduced in 3.1. > > I'm being asked now to add three entries in config > > > > 3.0 - false > > 3.1 - true > > 3.2 - true > > > > It will also mean that when 3.3 goes out, someone has to make sure > > that another entry is added for 3.3-true. I think it is not logical > > as > > well as scalable if you have more versions. And it sounds far more > > complex (to maintain) than just having > > > > SupportedFrom = 3.1 > > > > So I would like to know if there are any objections to my proposal. > > I > > intend to use this for at least the gluster related features. > > > >>> Thoughts? > >>> > >>> Regards, > >>> Shireesh > >>> _______________________________________________ > >>> 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 dfediuck at redhat.com Wed Mar 20 14:50:57 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Wed, 20 Mar 2013 10:50:57 -0400 (EDT) Subject: [Engine-devel] Kiril Nesenko as a tools maintainer In-Reply-To: <186002530.3914823.1363789444573.JavaMail.root@redhat.com> Message-ID: <859734079.22546211.1363791057068.JavaMail.root@redhat.com> +1 and wishing Kiril all the best as a maintainer; Your success it the project's success. ----- Original Message ----- > From: "Ofer Schreiber" > To: "Keith Robertson" > Cc: "Kiril Nesenko" , engine-devel at ovirt.org > Sent: Wednesday, March 20, 2013 4:24:04 PM > Subject: Re: [Engine-devel] Kiril Nesenko as a tools maintainer > > +1 > > ----- Original Message ----- > > I would like to propose that we add Kiril Nesenko as a maintainer > > for > > the Ovirt ISO Uploader, Image Uploader and Log Collector. He has > > been > > enormously helpful with the maintenance of the tools. > > > > Thanks, > > Keith Robertson > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lhornyak at redhat.com Thu Mar 21 10:38:27 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 21 Mar 2013 06:38:27 -0400 (EDT) Subject: [Engine-devel] watchdog patchset Message-ID: <1025088859.12517948.1363862307745.JavaMail.root@redhat.com> Hi, The watchdog patch was broken down into a patchset: http://gerrit.ovirt.org/13057 http://gerrit.ovirt.org/13058 http://gerrit.ovirt.org/13059 http://gerrit.ovirt.org/13060 You are welcome to review it, it is working, however due to internal changes it is being completely rewritten. Laszlo From deepakcs at linux.vnet.ibm.com Thu Mar 21 11:00:11 2013 From: deepakcs at linux.vnet.ibm.com (Deepak C Shetty) Date: Thu, 21 Mar 2013 16:30:11 +0530 Subject: [Engine-devel] Error during "Create new VM" [SOLVED] In-Reply-To: <5142EDDD.7000400@redhat.com> References: <5135E211.6040303@linux.vnet.ibm.com> <5135E676.9000306@linux.vnet.ibm.com> <5135EBD2.9090909@linux.vnet.ibm.com> <5142EDDD.7000400@redhat.com> Message-ID: <514AE83B.3010807@linux.vnet.ibm.com> >> >> Looks like some UI bug... >> >> i clicked on '+' then the custom property combo chnaged to "Pls select >> key" from "no keys available", then create VM works ! >> > > can you reproduce this? open a bug to get it fixed? Opened with screenshots... https://bugzilla.redhat.com/show_bug.cgi?id=924201 > > Thanks, > Itamar > > From grawert at b1-systems.de Thu Mar 21 14:49:03 2013 From: grawert at b1-systems.de (Uwe Grawert) Date: Thu, 21 Mar 2013 15:49:03 +0100 Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <1306212127.11402563.1363764266120.JavaMail.root@redhat.com> References: <1306212127.11402563.1363764266120.JavaMail.root@redhat.com> Message-ID: <0E20C646-755F-4F5E-9E79-DD0CFBA8CA05@b1-systems.de> Hello Yair, Am 20.03.2013 um 08:24 schrieb Yair Zaslavsky: > Hi Uwe, > Bare in mind we have some plans for refactoring/changing the authentication module. > However, for the meanwhile - we will be very happy if you can assist in adding this support. > I would like to introduce you to a Wiki that Oved Ourfali has written about the subject - > good to know. Refactoring will probably take some time, so I hope it's still worth the effort. > http://www.ovirt.org/DomainInfrastructure > Please let us know if this helps you with your questions. So far I am simply copying what has been done for ITDS and adopting things to OpenLdap. I am using the git tag "ovirt-engine-3.2.1", since I am getting the following error when using HEAD: [root at ovirt-nightly ~]# engine-manage-domains -action=list Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1 at org.ovirt.engine.core.domains.DomainsConfigurationEntry.(DomainsConfigurationEntry.java:23) at org.ovirt.engine.core.domains.ManageDomains.getConfiguration(ManageDomains.java:423) at org.ovirt.engine.core.domains.ManageDomains.runCommand(ManageDomains.java:293) at org.ovirt.engine.core.domains.ManageDomains.main(ManageDomains.java:180) 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:601) at org.jboss.modules.Module.run(Module.java:260) at org.jboss.modules.Main.main(Main.java:291) I created only ovirt-engine RPMs and installed them with --nodeps. Might be that I am missing some dependency here. Anyways, ovirt-engine-3.2.1 release tag is working, and diffs will very likely apply to HEAD as well. From yzaslavs at redhat.com Thu Mar 21 16:31:32 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 21 Mar 2013 12:31:32 -0400 (EDT) Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <0E20C646-755F-4F5E-9E79-DD0CFBA8CA05@b1-systems.de> Message-ID: <1978058588.12589985.1363883492213.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Uwe Grawert" > To: "Yair Zaslavsky" > Cc: engine-devel at ovirt.org > Sent: Thursday, March 21, 2013 4:49:03 PM > Subject: Re: [Engine-devel] Adding support for OpenLDAP to oVirt > > Hello Yair, > > Am 20.03.2013 um 08:24 schrieb Yair Zaslavsky: > > > Hi Uwe, > > Bare in mind we have some plans for refactoring/changing the > > authentication module. > > However, for the meanwhile - we will be very happy if you can > > assist in adding this support. > > I would like to introduce you to a Wiki that Oved Ourfali has > > written about the subject - > > > good to know. Refactoring will probably take some time, so I hope > it's still worth the effort. > > > http://www.ovirt.org/DomainInfrastructure > > Please let us know if this helps you with your questions. > > So far I am simply copying what has been done for ITDS and adopting > things to OpenLdap. I am using the git tag "ovirt-engine-3.2.1", > since I am getting the following error when using HEAD: Do you still have by any chance backup of the db + environment that caused this exception? There is something I would like you to examine on the db of the "faulty installation" if possible. > > [root at ovirt-nightly ~]# engine-manage-domains -action=list > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: > 1 > at > org.ovirt.engine.core.domains.DomainsConfigurationEntry.(DomainsConfigurationEntry.java:23) > at > org.ovirt.engine.core.domains.ManageDomains.getConfiguration(ManageDomains.java:423) > at > org.ovirt.engine.core.domains.ManageDomains.runCommand(ManageDomains.java:293) > at > org.ovirt.engine.core.domains.ManageDomains.main(ManageDomains.java:180) > 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:601) > at org.jboss.modules.Module.run(Module.java:260) > at org.jboss.modules.Main.main(Main.java:291) > > I created only ovirt-engine RPMs and installed them with --nodeps. > Might be that I am missing some dependency here. Anyways, > ovirt-engine-3.2.1 release tag is working, and diffs will very > likely apply to HEAD as well. From grawert at b1-systems.de Thu Mar 21 16:36:59 2013 From: grawert at b1-systems.de (Uwe Grawert) Date: Thu, 21 Mar 2013 17:36:59 +0100 Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <1978058588.12589985.1363883492213.JavaMail.root@redhat.com> References: <1978058588.12589985.1363883492213.JavaMail.root@redhat.com> Message-ID: <6EE387F1-8169-4001-A1B8-6030C81600B8@b1-systems.de> Hello Yair, Am 21.03.2013 um 17:31 schrieb Yair Zaslavsky: > Do you still have by any chance backup of the db + environment that caused this exception? > There is something I would like you to examine on the db of the "faulty installation" if possible. > yes I have. What would you like to have? >> >> [root at ovirt-nightly ~]# engine-manage-domains -action=list >> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: >> 1 >> at >> org.ovirt.engine.core.domains.DomainsConfigurationEntry.(DomainsConfigurationEntry.java:23) >> at >> org.ovirt.engine.core.domains.ManageDomains.getConfiguration(ManageDomains.java:423) >> at >> org.ovirt.engine.core.domains.ManageDomains.runCommand(ManageDomains.java:293) >> at >> org.ovirt.engine.core.domains.ManageDomains.main(ManageDomains.java:180) >> 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:601) >> at org.jboss.modules.Module.run(Module.java:260) >> at org.jboss.modules.Main.main(Main.java:291) >> >> I created only ovirt-engine RPMs and installed them with --nodeps. >> Might be that I am missing some dependency here. Anyways, >> ovirt-engine-3.2.1 release tag is working, and diffs will very >> likely apply to HEAD as well. From yzaslavs at redhat.com Thu Mar 21 16:48:31 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 21 Mar 2013 12:48:31 -0400 (EDT) Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <6EE387F1-8169-4001-A1B8-6030C81600B8@b1-systems.de> Message-ID: <977363808.12595631.1363884511303.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Uwe Grawert" > To: "Yair Zaslavsky" > Cc: engine-devel at ovirt.org > Sent: Thursday, March 21, 2013 6:36:59 PM > Subject: Re: [Engine-devel] Adding support for OpenLDAP to oVirt > > Hello Yair, > > Am 21.03.2013 um 17:31 schrieb Yair Zaslavsky: > > Do you still have by any chance backup of the db + environment that > > caused this exception? > > There is something I would like you to examine on the db of the > > "faulty installation" if possible. > > > yes I have. What would you like to have? Cool! Please provide output for - select * from vdc_options where option_name in ('AdUserName','AdUserPassword','DomainName','LdapServers','LDAPProviderTypes'); > > >> > >> [root at ovirt-nightly ~]# engine-manage-domains -action=list > >> Exception in thread "main" > >> java.lang.ArrayIndexOutOfBoundsException: > >> 1 > >> at > >> org.ovirt.engine.core.domains.DomainsConfigurationEntry.(DomainsConfigurationEntry.java:23) > >> at > >> org.ovirt.engine.core.domains.ManageDomains.getConfiguration(ManageDomains.java:423) > >> at > >> org.ovirt.engine.core.domains.ManageDomains.runCommand(ManageDomains.java:293) > >> at > >> org.ovirt.engine.core.domains.ManageDomains.main(ManageDomains.java:180) > >> 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:601) > >> at org.jboss.modules.Module.run(Module.java:260) > >> at org.jboss.modules.Main.main(Main.java:291) > >> > >> I created only ovirt-engine RPMs and installed them with --nodeps. > >> Might be that I am missing some dependency here. Anyways, > >> ovirt-engine-3.2.1 release tag is working, and diffs will very > >> likely apply to HEAD as well. > > > From grawert at b1-systems.de Thu Mar 21 16:53:42 2013 From: grawert at b1-systems.de (Uwe Grawert) Date: Thu, 21 Mar 2013 17:53:42 +0100 Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <977363808.12595631.1363884511303.JavaMail.root@redhat.com> References: <977363808.12595631.1363884511303.JavaMail.root@redhat.com> Message-ID: Am 21.03.2013 um 17:48 schrieb Yair Zaslavsky: > > > ----- Original Message ----- >> From: "Uwe Grawert" >> To: "Yair Zaslavsky" >> Cc: engine-devel at ovirt.org >> Sent: Thursday, March 21, 2013 6:36:59 PM >> Subject: Re: [Engine-devel] Adding support for OpenLDAP to oVirt >> >> Hello Yair, >> >> Am 21.03.2013 um 17:31 schrieb Yair Zaslavsky: >>> Do you still have by any chance backup of the db + environment that >>> caused this exception? >>> There is something I would like you to examine on the db of the >>> "faulty installation" if possible. >>> >> yes I have. What would you like to have? > > Cool! > > Please provide output for - > > select * from vdc_options where option_name in ('AdUserName','AdUserPassword','DomainName','LdapServers','LDAPProviderTypes'); engine=# select * from vdc_options where option_name in ('AdUserName','AdUserPassword','DomainName','LdapServers','LDAPProviderTypes'); option_id | option_name | option_value | version -----------+-------------------+--------------+--------- 10 | AdUserName | | general 11 | AdUserPassword | | general 56 | DomainName | | general 126 | LdapServers | | general 127 | LDAPProviderTypes | | general (5 rows) I haven't added any domains, yet. From yzaslavs at redhat.com Thu Mar 21 16:59:31 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 21 Mar 2013 12:59:31 -0400 (EDT) Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: Message-ID: <142338912.12614223.1363885171157.JavaMail.root@redhat.com> Hmm... Well, there is nothing in your db in the values of these fields, but it should not have failed engine-manage-domains. Can you send me the commit hash you built against , so I will be able to reproduce exactly you issue? Many thanks, Yair ----- Original Message ----- > From: "Uwe Grawert" > To: "Yair Zaslavsky" > Cc: engine-devel at ovirt.org > Sent: Thursday, March 21, 2013 6:53:42 PM > Subject: Re: [Engine-devel] Adding support for OpenLDAP to oVirt > > Am 21.03.2013 um 17:48 schrieb Yair Zaslavsky: > > > > > > > ----- Original Message ----- > >> From: "Uwe Grawert" > >> To: "Yair Zaslavsky" > >> Cc: engine-devel at ovirt.org > >> Sent: Thursday, March 21, 2013 6:36:59 PM > >> Subject: Re: [Engine-devel] Adding support for OpenLDAP to oVirt > >> > >> Hello Yair, > >> > >> Am 21.03.2013 um 17:31 schrieb Yair Zaslavsky: > >>> Do you still have by any chance backup of the db + environment > >>> that > >>> caused this exception? > >>> There is something I would like you to examine on the db of the > >>> "faulty installation" if possible. > >>> > >> yes I have. What would you like to have? > > > > Cool! > > > > Please provide output for - > > > > select * from vdc_options where option_name in > > ('AdUserName','AdUserPassword','DomainName','LdapServers','LDAPProviderTypes'); > > engine=# select * from vdc_options where option_name in > ('AdUserName','AdUserPassword','DomainName','LdapServers','LDAPProviderTypes'); > option_id | option_name | option_value | version > -----------+-------------------+--------------+--------- > 10 | AdUserName | | general > 11 | AdUserPassword | | general > 56 | DomainName | | general > 126 | LdapServers | | general > 127 | LDAPProviderTypes | | general > (5 rows) > > I haven't added any domains, yet. From jhernand at redhat.com Thu Mar 21 16:59:40 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Thu, 21 Mar 2013 17:59:40 +0100 Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <0E20C646-755F-4F5E-9E79-DD0CFBA8CA05@b1-systems.de> References: <1306212127.11402563.1363764266120.JavaMail.root@redhat.com> <0E20C646-755F-4F5E-9E79-DD0CFBA8CA05@b1-systems.de> Message-ID: <514B3C7C.7040009@redhat.com> On 03/21/2013 03:49 PM, Uwe Grawert wrote: > Hello Yair, > > Am 20.03.2013 um 08:24 schrieb Yair Zaslavsky: > >> Hi Uwe, >> Bare in mind we have some plans for refactoring/changing the authentication module. >> However, for the meanwhile - we will be very happy if you can assist in adding this support. >> I would like to introduce you to a Wiki that Oved Ourfali has written about the subject - >> > good to know. Refactoring will probably take some time, so I hope it's still worth the effort. > >> http://www.ovirt.org/DomainInfrastructure >> Please let us know if this helps you with your questions. > > So far I am simply copying what has been done for ITDS and adopting things to OpenLdap. I am using the git tag "ovirt-engine-3.2.1", since I am getting the following error when using HEAD: > > [root at ovirt-nightly ~]# engine-manage-domains -action=list > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1 > at org.ovirt.engine.core.domains.DomainsConfigurationEntry.(DomainsConfigurationEntry.java:23) > at org.ovirt.engine.core.domains.ManageDomains.getConfiguration(ManageDomains.java:423) > at org.ovirt.engine.core.domains.ManageDomains.runCommand(ManageDomains.java:293) > at org.ovirt.engine.core.domains.ManageDomains.main(ManageDomains.java:180) > 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:601) > at org.jboss.modules.Module.run(Module.java:260) > at org.jboss.modules.Main.main(Main.java:291) > > I created only ovirt-engine RPMs and installed them with --nodeps. Might be that I am missing some dependency here. Anyways, ovirt-engine-3.2.1 release tag is working, and diffs will very likely apply to HEAD as well. Note that we recently fixed an issue with how engine-config uses the log and the standard output which had this same symptom. You may want to apply this patch (already merged in the master branch) and then try again: http://gerrit.ovirt.org/12987 -- 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 grawert at b1-systems.de Thu Mar 21 17:02:21 2013 From: grawert at b1-systems.de (Uwe Grawert) Date: Thu, 21 Mar 2013 18:02:21 +0100 Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <142338912.12614223.1363885171157.JavaMail.root@redhat.com> References: <142338912.12614223.1363885171157.JavaMail.root@redhat.com> Message-ID: Am 21.03.2013 um 17:59 schrieb Yair Zaslavsky: > Hmm... > Well, there is nothing in your db in the values of these fields, but it should not have failed engine-manage-domains. > > Can you send me the commit hash you built against , so I will be able to reproduce exactly you issue? [root at ovirt-nightly ovirt-engine]# git log -1 commit 7546d98680d50a103bd01c04756cfe72e6e14a1b Author: Lior Vernia Date: Wed Feb 27 17:25:06 2013 +0200 core: Changed Bond constructor for backwards compatibility Before the Bond subclass was implemented, the old way to check whether a VdsNetworkInterface was to check the value of its "bonded" field. This is now preserved, so that any Bond object would still comply with older code. Change-Id: I93d970df3fe1e22e8116d0b5683e82851037f6c8 Signed-off-by: Lior Vernia From yzaslavs at redhat.com Thu Mar 21 17:03:06 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 21 Mar 2013 13:03:06 -0400 (EDT) Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <514B3C7C.7040009@redhat.com> Message-ID: <2002630506.12615437.1363885386797.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Juan Hernandez" > To: "Uwe Grawert" > Cc: "Yair Zaslavsky" , engine-devel at ovirt.org > Sent: Thursday, March 21, 2013 6:59:40 PM > Subject: Re: [Engine-devel] Adding support for OpenLDAP to oVirt > > On 03/21/2013 03:49 PM, Uwe Grawert wrote: > > Hello Yair, > > > > Am 20.03.2013 um 08:24 schrieb Yair Zaslavsky: > > > >> Hi Uwe, > >> Bare in mind we have some plans for refactoring/changing the > >> authentication module. > >> However, for the meanwhile - we will be very happy if you can > >> assist in adding this support. > >> I would like to introduce you to a Wiki that Oved Ourfali has > >> written about the subject - > >> > > good to know. Refactoring will probably take some time, so I hope > > it's still worth the effort. > > > >> http://www.ovirt.org/DomainInfrastructure > >> Please let us know if this helps you with your questions. > > > > So far I am simply copying what has been done for ITDS and adopting > > things to OpenLdap. I am using the git tag "ovirt-engine-3.2.1", > > since I am getting the following error when using HEAD: > > > > [root at ovirt-nightly ~]# engine-manage-domains -action=list > > Exception in thread "main" > > java.lang.ArrayIndexOutOfBoundsException: 1 > > at > > org.ovirt.engine.core.domains.DomainsConfigurationEntry.(DomainsConfigurationEntry.java:23) > > at > > org.ovirt.engine.core.domains.ManageDomains.getConfiguration(ManageDomains.java:423) > > at > > org.ovirt.engine.core.domains.ManageDomains.runCommand(ManageDomains.java:293) > > at > > org.ovirt.engine.core.domains.ManageDomains.main(ManageDomains.java:180) > > 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:601) > > at org.jboss.modules.Module.run(Module.java:260) > > at org.jboss.modules.Main.main(Main.java:291) > > > > I created only ovirt-engine RPMs and installed them with --nodeps. > > Might be that I am missing some dependency here. Anyways, > > ovirt-engine-3.2.1 release tag is working, and diffs will very > > likely apply to HEAD as well. > > Note that we recently fixed an issue with how engine-config uses the > log > and the standard output which had this same symptom. You may want to > apply this patch (already merged in the master branch) and then try > again: > > http://gerrit.ovirt.org/12987 Actually, I think Juan is right, and I saw this error myself when the patch he mentioned was not applied. > > -- > 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 Thu Mar 21 17:06:06 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 21 Mar 2013 13:06:06 -0400 (EDT) Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <2002630506.12615437.1363885386797.JavaMail.root@redhat.com> Message-ID: <1535374812.12619816.1363885566830.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Juan Hernandez" > Cc: engine-devel at ovirt.org > Sent: Thursday, March 21, 2013 7:03:06 PM > Subject: Re: [Engine-devel] Adding support for OpenLDAP to oVirt > > > ----- Original Message ----- > > From: "Juan Hernandez" > > To: "Uwe Grawert" > > Cc: "Yair Zaslavsky" , engine-devel at ovirt.org > > Sent: Thursday, March 21, 2013 6:59:40 PM > > Subject: Re: [Engine-devel] Adding support for OpenLDAP to oVirt > > > > On 03/21/2013 03:49 PM, Uwe Grawert wrote: > > > Hello Yair, > > > > > > Am 20.03.2013 um 08:24 schrieb Yair Zaslavsky: > > > > > >> Hi Uwe, > > >> Bare in mind we have some plans for refactoring/changing the > > >> authentication module. > > >> However, for the meanwhile - we will be very happy if you can > > >> assist in adding this support. > > >> I would like to introduce you to a Wiki that Oved Ourfali has > > >> written about the subject - > > >> > > > good to know. Refactoring will probably take some time, so I hope > > > it's still worth the effort. > > > > > >> http://www.ovirt.org/DomainInfrastructure > > >> Please let us know if this helps you with your questions. > > > > > > So far I am simply copying what has been done for ITDS and > > > adopting > > > things to OpenLdap. I am using the git tag "ovirt-engine-3.2.1", > > > since I am getting the following error when using HEAD: > > > > > > [root at ovirt-nightly ~]# engine-manage-domains -action=list > > > Exception in thread "main" > > > java.lang.ArrayIndexOutOfBoundsException: 1 > > > at > > > org.ovirt.engine.core.domains.DomainsConfigurationEntry.(DomainsConfigurationEntry.java:23) > > > at > > > org.ovirt.engine.core.domains.ManageDomains.getConfiguration(ManageDomains.java:423) > > > at > > > org.ovirt.engine.core.domains.ManageDomains.runCommand(ManageDomains.java:293) > > > at > > > org.ovirt.engine.core.domains.ManageDomains.main(ManageDomains.java:180) > > > 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:601) > > > at org.jboss.modules.Module.run(Module.java:260) > > > at org.jboss.modules.Main.main(Main.java:291) > > > > > > I created only ovirt-engine RPMs and installed them with > > > --nodeps. > > > Might be that I am missing some dependency here. Anyways, > > > ovirt-engine-3.2.1 release tag is working, and diffs will very > > > likely apply to HEAD as well. > > > > Note that we recently fixed an issue with how engine-config uses > > the > > log > > and the standard output which had this same symptom. You may want > > to > > apply this patch (already merged in the master branch) and then try > > again: > > > > http://gerrit.ovirt.org/12987 > > Actually, I think Juan is right, and I saw this error myself when the > patch he mentioned was not applied. Juan's patch was introduced *after* the commit hash you mentioned was introduced. Please rebase again or at least apply his patch. > > > > > > -- > > 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 grawert at b1-systems.de Thu Mar 21 17:38:41 2013 From: grawert at b1-systems.de (Uwe Grawert) Date: Thu, 21 Mar 2013 18:38:41 +0100 Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <1535374812.12619816.1363885566830.JavaMail.root@redhat.com> References: <1535374812.12619816.1363885566830.JavaMail.root@redhat.com> Message-ID: <066DE414-F56D-4994-898F-5BD68AB7B636@b1-systems.de> Am 21.03.2013 um 18:06 schrieb Yair Zaslavsky: > > > ----- Original Message ----- >> From: "Yair Zaslavsky" >> To: "Juan Hernandez" >> Cc: engine-devel at ovirt.org >> Sent: Thursday, March 21, 2013 7:03:06 PM >> Subject: Re: [Engine-devel] Adding support for OpenLDAP to oVirt >> >> >> ----- Original Message ----- >>> From: "Juan Hernandez" >>> To: "Uwe Grawert" >>> Cc: "Yair Zaslavsky" , engine-devel at ovirt.org >>> Sent: Thursday, March 21, 2013 6:59:40 PM >>> Subject: Re: [Engine-devel] Adding support for OpenLDAP to oVirt >>> >>> On 03/21/2013 03:49 PM, Uwe Grawert wrote: >>>> Hello Yair, >>>> >>>> Am 20.03.2013 um 08:24 schrieb Yair Zaslavsky: >>>> >>>>> Hi Uwe, >>>>> Bare in mind we have some plans for refactoring/changing the >>>>> authentication module. >>>>> However, for the meanwhile - we will be very happy if you can >>>>> assist in adding this support. >>>>> I would like to introduce you to a Wiki that Oved Ourfali has >>>>> written about the subject - >>>>> >>>> good to know. Refactoring will probably take some time, so I hope >>>> it's still worth the effort. >>>> >>>>> http://www.ovirt.org/DomainInfrastructure >>>>> Please let us know if this helps you with your questions. >>>> >>>> So far I am simply copying what has been done for ITDS and >>>> adopting >>>> things to OpenLdap. I am using the git tag "ovirt-engine-3.2.1", >>>> since I am getting the following error when using HEAD: >>>> >>>> [root at ovirt-nightly ~]# engine-manage-domains -action=list >>>> Exception in thread "main" >>>> java.lang.ArrayIndexOutOfBoundsException: 1 >>>> at >>>> org.ovirt.engine.core.domains.DomainsConfigurationEntry.(DomainsConfigurationEntry.java:23) >>>> at >>>> org.ovirt.engine.core.domains.ManageDomains.getConfiguration(ManageDomains.java:423) >>>> at >>>> org.ovirt.engine.core.domains.ManageDomains.runCommand(ManageDomains.java:293) >>>> at >>>> org.ovirt.engine.core.domains.ManageDomains.main(ManageDomains.java:180) >>>> 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:601) >>>> at org.jboss.modules.Module.run(Module.java:260) >>>> at org.jboss.modules.Main.main(Main.java:291) >>>> >>>> I created only ovirt-engine RPMs and installed them with >>>> --nodeps. >>>> Might be that I am missing some dependency here. Anyways, >>>> ovirt-engine-3.2.1 release tag is working, and diffs will very >>>> likely apply to HEAD as well. >>> >>> Note that we recently fixed an issue with how engine-config uses >>> the >>> log >>> and the standard output which had this same symptom. You may want >>> to >>> apply this patch (already merged in the master branch) and then try >>> again: >>> >>> http://gerrit.ovirt.org/12987 >> >> Actually, I think Juan is right, and I saw this error myself when the >> patch he mentioned was not applied. > > Juan's patch was introduced *after* the commit hash you mentioned was introduced. > Please rebase again or at least apply his patch. Right. I was quite old. Now I'm current and it works well. [root at ovirt-nightly ovirt-engine]# git log -1 commit c743bf9f0e7a20b8c69423aef80079c6e7ffbf80 Author: Libor Spevak Date: Thu Mar 21 12:35:33 2013 +0100 [root at ovirt-nightly ovirt-engine]# engine-manage-domains -action=list Manage Domains completed successfully From sanjal at redhat.com Fri Mar 22 07:07:56 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Fri, 22 Mar 2013 12:37:56 +0530 Subject: [Engine-devel] Best place for new interfaces used by bll In-Reply-To: <5142F5C9.60804@redhat.com> References: <51377566.6070604@redhat.com> <5142F5C9.60804@redhat.com> Message-ID: <514C034C.3000006@redhat.com> On 03/15/2013 03:49 PM, Itamar Heim wrote: > On 03/06/2013 06:57 PM, Ravi Nori wrote: >> Hi, >> >> I am working on refactoring some of the backend code in bll and need to >> create interfaces so that I can eliminate the dependency between bll and >> the new module. >> >> Currently I created the interfaces in >> org.ovirt.engine.core.common.interfaces, but from what I understand this >> module is used by both frontend and backend. The new interfaces will >> only be used by the backend. What would be the best place to put these >> new interfaces? >> > > 1. i agree with alissa and alon on the larger refactoring. > 2. not all of common today is used by gwt, specifically, interfaces > are shared/common, but backendinterfaces are limited to backend. > > since we are trying to refactor the frontend to not use common at all > by moving to the restapi, I'm not sure i'd bother we'd splitting > common "more" by shared/not-shared with frontend. > but i would focus on making things in their own packages. > i.e., I'd like to see ovirt-engine for gluster-only having to > deploy/build/pull only what's relevant for them, not the 'virt' stuff > for example. > (easier for bll. a bit more work for db/common) +1 Happy to see we're finally talking about it seriously :) > > Thanks, > Itamar > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From wei.d.chen at intel.com Fri Mar 22 09:34:55 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Fri, 22 Mar 2013 09:34:55 +0000 Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review Message-ID: Hi all, Before submitting this patch set, we has updated our design page, and new feature about VM template has added to this patchset. In patchset a lot of frontend changes has been imported. Welcome to review our patchset and thanks advance for your suggestion. Detailed description: http://wiki.ovirt.org/Trusted_compute_pools In this patch set, follow changes has been introduced: 1. GUI changes to support for creating a trusted VM on a trusted physical host. 2. View/Edit VM changes to enable end user switch between three run on options. 3. Template relevant changes to support end user create a trusted VM template and create trusted VM based on this template afterwards. 4. Bug fixing and code cleanup. 5. wiki design page update. Best Regards, Dave Chen From wei.d.chen at intel.com Tue Mar 26 03:50:40 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Tue, 26 Mar 2013 03:50:40 +0000 Subject: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment? Message-ID: Hi, We notice that ovirt-engine's version (rpm package and source code) has updated from 3.2.0 to 3.2.1. As our development process is always based on 3.2.0. Is there any way to re-setup 3.2.0 running environment? Besides, we also cannot setup 3.2.1 ovrit-engine running environment as its dependent package glusterfs-3.4 cannot be found from ovirt repo or fedora18 repo. How can I fix this issue? Thanks. Best Regards, Dave Chen From grawert at b1-systems.de Tue Mar 26 12:10:46 2013 From: grawert at b1-systems.de (Uwe Grawert) Date: Tue, 26 Mar 2013 13:10:46 +0100 Subject: [Engine-devel] Adding support for OpenLDAP to oVirt In-Reply-To: <066DE414-F56D-4994-898F-5BD68AB7B636@b1-systems.de> References: <1535374812.12619816.1363885566830.JavaMail.root@redhat.com> <066DE414-F56D-4994-898F-5BD68AB7B636@b1-systems.de> Message-ID: Hallo together, adding support for OpenLDAP has been working fine so far, but before bringing it to the review process, I would like to discuss the following issue. When querying the RootDSE most of the attributes are defined as operational attributes, and standard says, those must be requested explicitly. Among them is namingContexts, which for OpenLDAP, has to be requested. Therefore I had to change the searchControl and define the attributes to return. This could be affecting other directory servers. So far the test classes have run fine, and I could successfully test adding and authenticating against ActiveDirectory and IPA. RHDS and ITDS have not been tested. So the question is, could the following patch break something? diff --git a/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/ldap/RootDSEQueryInfo.java b/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/ldap/RootDSEQueryInfo.java index 01294c6..60033ff 100644 --- a/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/ldap/RootDSEQueryInfo.java +++ b/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/ldap/RootDSEQueryInfo.java @@ -21,8 +21,10 @@ public class RootDSEQueryInfo { * @return */ public static SearchControls createSearchControls() { + String[] returnAttributes = {NAMING_CONTEXTS_RESULT_ATTRIBUTE, DEFAULT_NAMING_CONTEXT_RESULT_ATTRIBUTE}; SearchControls searchControls = new SearchControls(); searchControls.setSearchScope(SearchControls.OBJECT_SCOPE); + searchControls.setReturningAttributes(returnAttributes); // Added this in order to prevent a warning saying: "the returning obj flag wasn't set, setting it to true" searchControls.setReturningObjFlag(true); return searchControls; From jhernand at redhat.com Tue Mar 26 17:34:04 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Tue, 26 Mar 2013 18:34:04 +0100 Subject: [Engine-devel] Move SQL out of stored procedures Message-ID: <5151DC0C.2040909@redhat.com> Hello, I would like to start a discussion about the subject. I think this is something we need to do if one day we want to be able to use any database other than PostgreSQL. I did an small example of what it takes and how it looks like to have the SQL code into the DAOs: http://gerrit.ovirt.org/13347 It isn't rocket science, it isn't an exciting task, it isn't fun, but something I think we should eventually do. I appreciate any comment about how and when to do this, including those saying that instead of this primitive approach we should use this or that ORM framework. 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. From alonbl at redhat.com Tue Mar 26 18:39:16 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 26 Mar 2013 14:39:16 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <5151DC0C.2040909@redhat.com> Message-ID: <209251507.9203475.1364323156605.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Juan Hernandez" > To: engine-devel at ovirt.org > Sent: Tuesday, March 26, 2013 7:34:04 PM > Subject: [Engine-devel] Move SQL out of stored procedures > > Hello, > > I would like to start a discussion about the subject. I think this is > something we need to do if one day we want to be able to use any > database other than PostgreSQL. Hello, I think that database layer is a software interface like any other software interface, if done properly, a dba can convert the stored procedure to any other database without any code change. This way the database specific implementation lives within the database and maintained by the designated dba. Fixups and optimizations can be done in database without touching the code. Backward compatibility layer is much simpler to implement based on stored procedures than complex set of views and tables. Also, accessing the database via different technologies is simpler if there is maintained database interface (stored procedures). I've seen hibernate based java applications that promised to be database independent but at the edges when performance counts, the DAO became HQL, then a special dialect and finally database specific SQLS. Regards, Alon Bar-Lev. From mperina at redhat.com Wed Mar 27 05:59:00 2013 From: mperina at redhat.com (Martin Perina) Date: Wed, 27 Mar 2013 01:59:00 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <209251507.9203475.1364323156605.JavaMail.root@redhat.com> Message-ID: <1050936377.24270432.1364363940352.JavaMail.root@redhat.com> Hello, according to my experiences Hibernate/JPA is the best solution for application which has to support multiple databases. Even when I was part of the team who migrated application with business login written in Oracle PL/SQL procedures to JBoss using Hibernate (application ran only on Oracle), it became much easier to maintain this applications and also customer was pleased that application ran much better. Now imagine the scenario, that for example Postgresql, MySQL, Oracle and MS SQL would be supported. I you need to change some stored procedure you should do this on 4 places using 4 different database dialects. Like any other technologies, Hibernate/JPA has some drawbacks, but when it's used properly and database objects are redesigned to fit Hibernate and portability needs, it works fine. Martin Perina ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Juan Hernandez" > Cc: engine-devel at ovirt.org > Sent: Tuesday, March 26, 2013 7:39:16 PM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > ----- Original Message ----- > > From: "Juan Hernandez" > > To: engine-devel at ovirt.org > > Sent: Tuesday, March 26, 2013 7:34:04 PM > > Subject: [Engine-devel] Move SQL out of stored procedures > > > > Hello, > > > > I would like to start a discussion about the subject. I think this > > is > > something we need to do if one day we want to be able to use any > > database other than PostgreSQL. > > Hello, > > I think that database layer is a software interface like any other > software interface, if done properly, a dba can convert the stored > procedure to any other database without any code change. > > This way the database specific implementation lives within the > database and maintained by the designated dba. > > Fixups and optimizations can be done in database without touching the > code. > > Backward compatibility layer is much simpler to implement based on > stored procedures than complex set of views and tables. > > Also, accessing the database via different technologies is simpler if > there is maintained database interface (stored procedures). > > I've seen hibernate based java applications that promised to be > database independent but at the edges when performance counts, the > DAO became HQL, then a special dialect and finally database specific > SQLS. > > Regards, > Alon Bar-Lev. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From jhernand at redhat.com Wed Mar 27 07:52:35 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 27 Mar 2013 08:52:35 +0100 Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <209251507.9203475.1364323156605.JavaMail.root@redhat.com> References: <209251507.9203475.1364323156605.JavaMail.root@redhat.com> Message-ID: <5152A543.80909@redhat.com> On 03/26/2013 07:39 PM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Juan Hernandez" >> To: engine-devel at ovirt.org >> Sent: Tuesday, March 26, 2013 7:34:04 PM >> Subject: [Engine-devel] Move SQL out of stored procedures >> >> Hello, >> >> I would like to start a discussion about the subject. I think this is >> something we need to do if one day we want to be able to use any >> database other than PostgreSQL. > > Hello, > > I think that database layer is a software interface like any other software interface, if done properly, a dba can convert the stored procedure to any other database without any code change. > You probably mean "any other database that supports stored procedures", which is not the same that "any other database". It is very clear what is the interface of a relational database: a set of relations with a set of restrictions. > This way the database specific implementation lives within the database and maintained by the designated dba. I don't now exactly what you mean by "dba", but if you mean "database administrator" I really don't see typical database administrators rewriting stored procedures provided by a product to suite their own database management system. Maybe by "dba" you mean "the developer of the persistence layer". Will your proposal be maintaining different sets of stored procedures, written in different languages for different database management systems? > Fixups and optimizations can be done in database without touching the code. Seems that you think that stored procedures aren't "code". What are they then? > Backward compatibility layer is much simpler to implement based on stored procedures than complex set of views and tables. > > Also, accessing the database via different technologies is simpler if there is maintained database interface (stored procedures). > It also means that you make the database a procedural system, and it shouldn't be. A database should not contain logic, only data. Logic changes quite frequently and data needs to survive for a long long time. > I've seen hibernate based java applications that promised to be database independent but at the edges when performance counts, the DAO became HQL, then a special dialect and finally database specific SQLS. I've seen exactly the opposite, if that matters. -- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 - Red Hat S.L. From lspevak at redhat.com Wed Mar 27 08:09:22 2013 From: lspevak at redhat.com (Libor Spevak) Date: Wed, 27 Mar 2013 09:09:22 +0100 Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <5151DC0C.2040909@redhat.com> References: <5151DC0C.2040909@redhat.com> Message-ID: <5152A932.6050707@redhat.com> Hi, I would recommend always to avoid hard coding SQL into Java code. It is very hard to maintain and read. If there is something, which prevents using JPA/Hibernate, e.g. the database relational model doesn't reflect the object-oriented domain very well or we have to live with many stored procedures concurrently, I would choose a framework, which enables to externalize the SQL code (into XML). I worked on a larger project(s) with a lot of PL/SQL code, we moved to myBatis (previously iBatis) very soon for Java backend: https://code.google.com/p/mybatis/ Libor On 26.3.2013 18:34, Juan Hernandez wrote: > Hello, > > I would like to start a discussion about the subject. I think this is > something we need to do if one day we want to be able to use any > database other than PostgreSQL. > > I did an small example of what it takes and how it looks like to have > the SQL code into the DAOs: > > http://gerrit.ovirt.org/13347 > > It isn't rocket science, it isn't an exciting task, it isn't fun, but > something I think we should eventually do. > > I appreciate any comment about how and when to do this, including > those saying that instead of this primitive approach we should use > this or that ORM framework. > > Regards, > Juan Hernandez From alonbl at redhat.com Wed Mar 27 08:19:17 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 27 Mar 2013 04:19:17 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <5152A543.80909@redhat.com> Message-ID: <1931093125.9298000.1364372357468.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Juan Hernandez" > To: "Alon Bar-Lev" > Cc: engine-devel at ovirt.org, "Eli Mesika" , "Yair Zaslavsky" > Sent: Wednesday, March 27, 2013 9:52:35 AM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > On 03/26/2013 07:39 PM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > >> From: "Juan Hernandez" > >> To: engine-devel at ovirt.org > >> Sent: Tuesday, March 26, 2013 7:34:04 PM > >> Subject: [Engine-devel] Move SQL out of stored procedures > >> > >> Hello, > >> > >> I would like to start a discussion about the subject. I think this > >> is > >> something we need to do if one day we want to be able to use any > >> database other than PostgreSQL. > > > > Hello, > > > > I think that database layer is a software interface like any other > > software interface, if done properly, a dba can convert the stored > > procedure to any other database without any code change. > > > > You probably mean "any other database that supports stored > procedures", > which is not the same that "any other database". Right. > > It is very clear what is the interface of a relational database: a > set > of relations with a set of restrictions. We can find a lot of definitions, there is a trend no of nosql... which falls into the above... > > > This way the database specific implementation lives within the > > database and maintained by the designated dba. > > I don't now exactly what you mean by "dba", but if you mean "database > administrator" I really don't see typical database administrators > rewriting stored procedures provided by a product to suite their own > database management system. > > Maybe by "dba" you mean "the developer of the persistence layer". > Will > your proposal be maintaining different sets of stored procedures, > written in different languages for different database management > systems? Yes, this what I mean. > > > Fixups and optimizations can be done in database without touching > > the code. > > Seems that you think that stored procedures aren't "code". What are > they > then? Yes they are, stored procedure are code, which is database dependent, with pre-defined interface to the external world. The language you chose depends on database capabilities, for Oracle and DB2 you can write stored procedure in Java... This code is part of application, it is maintained within the same release milestones, commits etc. > > > Backward compatibility layer is much simpler to implement based on > > stored procedures than complex set of views and tables. > > > > Also, accessing the database via different technologies is simpler > > if there is maintained database interface (stored procedures). > > > > It also means that you make the database a procedural system, and it > shouldn't be. A database should not contain logic, only data. Logic > changes quite frequently and data needs to survive for a long long > time. This is your definition... I think the opposite... database should contain logic, it is procedural system. Implementing the logic within database enable you to enjoy the performance provided by the database, and simplifying your application. This logic is part of your code, a change in application derives a change in the database layer as well, nothing prevents you in changing logic. > > > I've seen hibernate based java applications that promised to be > > database independent but at the edges when performance counts, the > > DAO became HQL, then a special dialect and finally database > > specific SQLS. > > I've seen exactly the opposite, if that matters. Yes, I've seen the opposite in simple applications. And I understand the need of the developers to control everything, not distributing logic to other components and technologies which are out of reach of the common developer. The undesired dependency with dba (data model layer developer) for every change in schema or entity. When optimization, porting or backward/forward compatibility is required the problem falls at the developer's side and usually solved with less knowledge or flexibility. Just wanted to step in and write that... As I know what most of the Java developer will probably prefer. Bottom line, it is all a question of how complex our data model is, and what performance we need out of the data layer. If the model is simple and the performance are insignificant, by all mean, use hibernate. While we discuss that, I think that best if statistics (or any data which is rolling) will be written to nosql database instead of sql database as there is much less overhead, storage and the need for vacuum and such, it is not a matter of postgesql/mysql I have experience with Oracle and DB2 not coping with rolling data. Thanks, Alon. From lhornyak at redhat.com Wed Mar 27 08:27:48 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Wed, 27 Mar 2013 04:27:48 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <5151DC0C.2040909@redhat.com> Message-ID: <301910051.15225341.1364372868410.JavaMail.root@redhat.com> Hi, I agree with the idea. The stored procedures/UDF's are just one more place to go when trying to find out what is really happening. It is not a good solution for database portability. Laszlo ----- Original Message ----- > From: "Juan Hernandez" > To: engine-devel at ovirt.org > Sent: Tuesday, March 26, 2013 6:34:04 PM > Subject: [Engine-devel] Move SQL out of stored procedures > > Hello, > > I would like to start a discussion about the subject. I think this is > something we need to do if one day we want to be able to use any > database other than PostgreSQL. > > I did an small example of what it takes and how it looks like to have > the SQL code into the DAOs: > > http://gerrit.ovirt.org/13347 > > It isn't rocket science, it isn't an exciting task, it isn't fun, but > something I think we should eventually do. > > I appreciate any comment about how and when to do this, including > those > saying that instead of this primitive approach we should use this or > that ORM framework. > > 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 sanjal at redhat.com Wed Mar 27 08:52:35 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Wed, 27 Mar 2013 14:22:35 +0530 Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <1321805680.12000513.1363791045560.JavaMail.root@redhat.com> References: <1321805680.12000513.1363791045560.JavaMail.root@redhat.com> Message-ID: <5152B353.9050804@redhat.com> On 03/20/2013 08:20 PM, Yair Zaslavsky wrote: > > ----- Original Message ----- >> From: "Shireesh Anjal" >> To: "Mike Kolesnik" >> Cc: engine-devel at ovirt.org >> Sent: Wednesday, March 20, 2013 4:47:08 PM >> Subject: Re: [Engine-devel] FeatureSupported and compatibility versions >> >> On 03/18/2013 01:11 PM, Shireesh Anjal wrote: >>> On 03/18/2013 12:59 PM, Mike Kolesnik wrote: >>>> ----- Original Message ----- >>>>> Hi all, >>>>> >>>>> The current mechanism in oVirt to check whether a feature is >>>>> supported >>>>> in a particular compatibility version is to use the >>>>> FeatureSupported >>>>> class. e.g. >>>>> >>>>> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) >>>>> >>>>> >>>>> Checks whether the "network linking" feature is supported for the >>>>> the >>>>> VM's cluster compatibility version. This internally checks >>>>> whether >>>>> the >>>>> value of the corresponding config (NetworkLinkingSupported) for >>>>> the >>>>> given compatibility version is true/false. >>>>> >>>>> I'm not sure if this is a good idea, since a feature is typically >>>>> supported "from" a particular version. E.g. Gluster support was >>>>> introduced in 3.1, and it continues to be available in all >>>>> subsequent >>>>> versions. So I see no point in adding configuration for every >>>>> version >>>>> indicating whether the feature is supported in that version or >>>>> not. I >>>>> suggest to use either of the following options: >>>> You can "merge" the configs into a single config when older >>>> versions >>>> go out of the supported versions for the system. >>>> >>>> i.e. in 4.0 you can have upgrade script that merges all >>>> GlusterFeatureSupported to one entry instead of several. >> Why are we even storing this information in config? Is this something >> that can be "configured" at customer site? > As previously explained (but off list :) ) , Config gives you the ability to have a cachable "map" of entry (i.e - "feature name") per version and value. > I guess it was convinient for the developers to use that. > I also mentioned that customers/oVirt users should config the entries of vdc_options using engine-config tool only. > Not all entries are exposed via engine-config.properties (and no, not just "is feature supported" entries are hidden). > > > > >>>>> 1) Instead of using a boolean config for each version, use a >>>>> single >>>>> string config that indicates the "supported from" version e.g. >>>>> GlusterSupportedFrom = 3.1. There could be rare cases where a >>>>> feature, >>>>> for some reason, is removed in some release. In such cases, we >>>>> could >>>>> use >>>>> one additional config for the "supported to" version. >>>>> >>>>> 2) Continue with the boolean approach, but do not have entries >>>>> for >>>>> every >>>>> version; rather make use of the "default value" for majority of >>>>> cases, >>>>> and add the explicit version mapping for the minority e.g. >>>>> GlusterSupported = true by default, and false in case of 3.0 >>>>> (only >>>>> one >>>>> config required for 3.0) >>>> I'm not sure why we would want to complicate this simple >>>> mechanism? >>>> >>>> Is there much to gain? >>> I think option 1 suggested above is simpler - to implement as well >>> as >>> to understand. >>> >>> Let me give you an example of why I don't like current mechanism. I >>> introduce a version check for a feature that was introduced in 3.1. >>> I'm being asked now to add three entries in config >>> >>> 3.0 - false >>> 3.1 - true >>> 3.2 - true >>> >>> It will also mean that when 3.3 goes out, someone has to make sure >>> that another entry is added for 3.3-true. I think it is not logical >>> as >>> well as scalable if you have more versions. And it sounds far more >>> complex (to maintain) than just having >>> >>> SupportedFrom = 3.1 >>> >>> So I would like to know if there are any objections to my proposal. >>> I >>> intend to use this for at least the gluster related features. I've sent a patch (http://gerrit.ovirt.org/12970) with following changes: 1) Introduced CompatibilityUtils that provides utility methods for checking if a given feature is supported in the config. One method to check based on boolean values (as is being done today for virt features), and nother to check based on a range (from, to) which I would like to use for gluster features. 2) Renamed FeatureSupported to VirtFeatureSupported, and made it use the first utility method from CompatibilityUtils 3) Introduced GlusterFeatureSupported for gluster features, which uses the second utility method from CompatibilityUtils Key advantage here is that - we don't have to touch any virt specifc source for adding compatibility checks for gluster features - virt features continue to use the existing boolean config check Any comments / suggestions / reviews will be highly appreciated :) >>>>> Thoughts? >>>>> >>>>> Regards, >>>>> Shireesh >>>>> _______________________________________________ >>>>> 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 tnisan at redhat.com Wed Mar 27 09:19:49 2013 From: tnisan at redhat.com (Tal Nisan) Date: Wed, 27 Mar 2013 11:19:49 +0200 Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <5151DC0C.2040909@redhat.com> References: <5151DC0C.2040909@redhat.com> Message-ID: <5152B9B5.2030401@redhat.com> Removing the stored procedures is indeed a blessing, but the implementation you offered seems a bit too oldschool (i.e. coding sql into the code), in my opinion if we go towards a joint effort to refactor the DAO layer we should go the extra mile and move to Hibernate (Take II :) ) On 03/26/2013 07:34 PM, Juan Hernandez wrote: > Hello, > > I would like to start a discussion about the subject. I think this is > something we need to do if one day we want to be able to use any > database other than PostgreSQL. > > I did an small example of what it takes and how it looks like to have > the SQL code into the DAOs: > > http://gerrit.ovirt.org/13347 > > It isn't rocket science, it isn't an exciting task, it isn't fun, but > something I think we should eventually do. > > I appreciate any comment about how and when to do this, including > those saying that instead of this primitive approach we should use > this or that ORM framework. > > Regards, > Juan Hernandez From jhernand at redhat.com Wed Mar 27 09:34:31 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 27 Mar 2013 10:34:31 +0100 Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <1931093125.9298000.1364372357468.JavaMail.root@redhat.com> References: <1931093125.9298000.1364372357468.JavaMail.root@redhat.com> Message-ID: <5152BD27.4030508@redhat.com> On 03/27/2013 09:19 AM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Juan Hernandez" >> To: "Alon Bar-Lev" >> Cc: engine-devel at ovirt.org, "Eli Mesika" , "Yair Zaslavsky" >> Sent: Wednesday, March 27, 2013 9:52:35 AM >> Subject: Re: [Engine-devel] Move SQL out of stored procedures >> >> On 03/26/2013 07:39 PM, Alon Bar-Lev wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Juan Hernandez" >>>> To: engine-devel at ovirt.org >>>> Sent: Tuesday, March 26, 2013 7:34:04 PM >>>> Subject: [Engine-devel] Move SQL out of stored procedures >>>> >>>> Hello, >>>> >>>> I would like to start a discussion about the subject. I think this >>>> is >>>> something we need to do if one day we want to be able to use any >>>> database other than PostgreSQL. >>> >>> Hello, >>> >>> I think that database layer is a software interface like any other >>> software interface, if done properly, a dba can convert the stored >>> procedure to any other database without any code change. >>> >> >> You probably mean "any other database that supports stored >> procedures", >> which is not the same that "any other database". > > Right. > >> >> It is very clear what is the interface of a relational database: a >> set >> of relations with a set of restrictions. > > We can find a lot of definitions, there is a trend no of nosql... which falls into the above... > I talking about relational databases, most self called nosql databases are not relational. >> >>> This way the database specific implementation lives within the >>> database and maintained by the designated dba. >> >> I don't now exactly what you mean by "dba", but if you mean "database >> administrator" I really don't see typical database administrators >> rewriting stored procedures provided by a product to suite their own >> database management system. >> >> Maybe by "dba" you mean "the developer of the persistence layer". >> Will >> your proposal be maintaining different sets of stored procedures, >> written in different languages for different database management >> systems? > > Yes, this what I mean. > In my opinion doing that is a waste of resources when you can do just one persistence layer with standard SQL. >> >>> Fixups and optimizations can be done in database without touching >>> the code. >> >> Seems that you think that stored procedures aren't "code". What are >> they >> then? > > Yes they are, stored procedure are code, which is database dependent, with pre-defined interface to the external world. > It doesn't need to be database dependent. In fact most of the stored procedures that we use today are just plain wrappers for SQL statements that are perfectly standard SQL (there are exceptions, of course). The pre-defined interface of the database to the external world should be well structured data, with restrictions that ensure consistency. > The language you chose depends on database capabilities, for Oracle and DB2 you can write stored procedure in Java... So it would be acceptable to write that logic in Java and deploy it inside the database, but it isn't acceptable to write that same logic in java and deploy it inside the application? > This code is part of application, it is maintained within the same release milestones, commits etc. Yes, the n versions of the stored procedures are maintained and kept in sync. Far from ideal. >> >>> Backward compatibility layer is much simpler to implement based on >>> stored procedures than complex set of views and tables. >>> >>> Also, accessing the database via different technologies is simpler >>> if there is maintained database interface (stored procedures). >>> >> >> It also means that you make the database a procedural system, and it >> shouldn't be. A database should not contain logic, only data. Logic >> changes quite frequently and data needs to survive for a long long >> time. > > This is your definition... I think the opposite... database should contain logic, it is procedural system. Implementing the logic within database enable you to enjoy the performance provided by the database, and simplifying your application. > > This logic is part of your code, a change in application derives a change in the database layer as well, nothing prevents you in changing logic. > That is very wrong, in my opinion. A relational database is not a place for your logic and it is not a procedural system. The SQL language is a declarative language, not procedural, and the nature of the querying concept, even without the SQL language, is declarative, not procedural. The procedural languages have been added to relational databases as after thought extensions, and they have proven to be very good tools to lock users to their database vendors. Ask anyone who has tried to escape from Oracle's PL/SQL (or any other similar thing). Regarding performance it is much more relevant to reduce the number of queries sent to the database and to improve the performance of complex queries than having/not having them in stored procedures. Regarding complexity, I don't really see how a SQL query is more complex than a call to a stored procedure than in turns executes the same SQL query, I would say the opposite: the stored procedure is just an additional step, an additional thing to maintain, so it increases complexity. Anyhow, look at most of the stored procedures that we currently have and you will see that they just wrap a plain SQL statement. And when something is changed, adding a new column, for example, a lot of things have to change: the call from the data access layer, the signature of the procedure, and the query inside. Most of the time this stored procedures just get in the middle without any added value. >> >>> I've seen hibernate based java applications that promised to be >>> database independent but at the edges when performance counts, the >>> DAO became HQL, then a special dialect and finally database >>> specific SQLS. >> >> I've seen exactly the opposite, if that matters. > > Yes, I've seen the opposite in simple applications. > I've seen the opposite in very complex applications, when it comes to performance and scalability. > And I understand the need of the developers to control everything, not distributing logic to other components and technologies which are out of reach of the common developer. The undesired dependency with dba (data model layer developer) for every change in schema or entity. The fact that SQL statements are out of stored procedures doesn't mean that they have to be maintained by a different type of developer. If they are currently maintained by relational database specialists they can continue to be maintained by relational database specialists once they are outside of the stored procedures. > > When optimization, porting or backward/forward compatibility is required the problem falls at the developer's side and usually solved with less knowledge or flexibility. > > Just wanted to step in and write that... > > As I know what most of the Java developer will probably prefer. > > Bottom line, it is all a question of how complex our data model is, and what performance we need out of the data layer. If the model is simple and the performance are insignificant, by all mean, use hibernate. > This is wrong. Hibernate is a good solution exactly when it comes to performance and scalability, there is where it shines, if used correctly. Anyhow, the subject is not Hibernate (or any other ORM solution) versus stored procedures, it is moving the SQL code out of stored procedures, with or without Hibernate. > While we discuss that, I think that best if statistics (or any data which is rolling) will be written to nosql database instead of sql database as there is much less overhead, storage and the need for vacuum and such, it is not a matter of postgesql/mysql I have experience with Oracle and DB2 not coping with rolling data. > > Thanks, > Alon. > -- 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 sanjal at redhat.com Wed Mar 27 10:08:33 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Wed, 27 Mar 2013 15:38:33 +0530 Subject: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment? In-Reply-To: References: Message-ID: <5152C521.9090302@redhat.com> On 03/26/2013 09:20 AM, Chen, Wei D wrote: > Hi, > > We notice that ovirt-engine's version (rpm package and source code) has updated from 3.2.0 to 3.2.1. As our development process is always based on 3.2.0. Is there any way to re-setup 3.2.0 running environment? > > Besides, we also cannot setup 3.2.1 ovrit-engine running environment as its dependent package glusterfs-3.4 cannot be found from ovirt repo or fedora18 repo. How can I fix this issue? Thanks. glusterfs-3.4.0alph2 packages can be obtained from following yum repo: http://bits.gluster.org/pub/gluster/glusterfs/stage/ This is required only if the cluster in which you are adding the host has gluster service enabled. > > Best Regards, > Dave Chen > > > _______________________________________________ > 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: From jhernand at redhat.com Wed Mar 27 13:35:03 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 27 Mar 2013 14:35:03 +0100 Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <1333423756.7053414.1364387816813.JavaMail.root@redhat.com> References: <1333423756.7053414.1364387816813.JavaMail.root@redhat.com> Message-ID: <5152F587.3080403@redhat.com> On 03/27/2013 01:36 PM, Mike Kolesnik wrote: > ----- Original Message ----- >> Hello, >> >> according to my experiences Hibernate/JPA is the best solution for >> application >> which has to support multiple databases. > > +1 > > JPA would be much easier to maintain than the current approach. > In most cases the stored procedures we use are for CRUD operations, > and can be easily replaced. > The exceptions can be dealt with when necessary, but generally it > seems like an excellent direction to me. > >> Even when I was part of the >> team who >> migrated application with business login written in Oracle PL/SQL >> procedures >> to JBoss using Hibernate (application ran only on Oracle), it became >> much easier >> to maintain this applications and also customer was pleased that >> application >> ran much better. >> >> Now imagine the scenario, that for example Postgresql, MySQL, Oracle >> and MS SQL would be >> supported. I you need to change some stored procedure you should do >> this on 4 places using >> 4 different database dialects. >> >> Like any other technologies, Hibernate/JPA has some drawbacks, but >> when it's used properly >> and database objects are redesigned to fit Hibernate and portability >> needs, it works fine. > > I don't think our DB/POJO design is very problematic in this regard.. > I think we can replace most of the existing DAOs with ORM backed > implementations with very little work. > > What we need to make sure is not break the DAO API. > For example, if I fetch an entity from a Session, > it would reflect any change that happens to it automatically to the DB. > This is not how the current API works, so this feature should be disabled > or otherwise we would have a hard time hunting the bugs that will spawn > from this change of behavior. > This is in my opinion the main disadvantage of using Hibernate (or any other JPA implementation) with our current architecture. However Hibernate provides the stateless session concept, which is not standard but could help. >> >> >> >> Martin Perina >> >> >> ----- Original Message ----- >>> From: "Alon Bar-Lev" >>> To: "Juan Hernandez" >>> Cc: engine-devel at ovirt.org >>> Sent: Tuesday, March 26, 2013 7:39:16 PM >>> Subject: Re: [Engine-devel] Move SQL out of stored procedures >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Juan Hernandez" >>>> To: engine-devel at ovirt.org >>>> Sent: Tuesday, March 26, 2013 7:34:04 PM >>>> Subject: [Engine-devel] Move SQL out of stored procedures >>>> >>>> Hello, >>>> >>>> I would like to start a discussion about the subject. I think >>>> this >>>> is >>>> something we need to do if one day we want to be able to use any >>>> database other than PostgreSQL. >>> >>> Hello, >>> >>> I think that database layer is a software interface like any other >>> software interface, if done properly, a dba can convert the stored >>> procedure to any other database without any code change. >>> >>> This way the database specific implementation lives within the >>> database and maintained by the designated dba. >>> >>> Fixups and optimizations can be done in database without touching >>> the >>> code. >>> >>> Backward compatibility layer is much simpler to implement based on >>> stored procedures than complex set of views and tables. >>> >>> Also, accessing the database via different technologies is simpler >>> if >>> there is maintained database interface (stored procedures). >>> >>> I've seen hibernate based java applications that promised to be >>> database independent but at the edges when performance counts, the >>> DAO became HQL, then a special dialect and finally database >>> specific >>> SQLS. >>> >>> Regards, >>> Alon Bar-Lev. >>> _______________________________________________ >>> 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 iheim at redhat.com Wed Mar 27 12:53:45 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 27 Mar 2013 14:53:45 +0200 Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <209251507.9203475.1364323156605.JavaMail.root@redhat.com> References: <209251507.9203475.1364323156605.JavaMail.root@redhat.com> Message-ID: <5152EBD9.5050404@redhat.com> On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Juan Hernandez" >> To: engine-devel at ovirt.org >> Sent: Tuesday, March 26, 2013 7:34:04 PM >> Subject: [Engine-devel] Move SQL out of stored procedures >> >> Hello, >> >> I would like to start a discussion about the subject. I think this is >> something we need to do if one day we want to be able to use any >> database other than PostgreSQL. > > Hello, > > I think that database layer is a software interface like any other software interface, if done properly, a dba can convert the stored procedure to any other database without any code change. > > This way the database specific implementation lives within the database and maintained by the designated dba. > > Fixups and optimizations can be done in database without touching the code. > > Backward compatibility layer is much simpler to implement based on stored procedures than complex set of views and tables. > > Also, accessing the database via different technologies is simpler if there is maintained database interface (stored procedures). > > I've seen hibernate based java applications that promised to be database independent but at the edges when performance counts, the DAO became HQL, then a special dialect and finally database specific SQLS. there may be db specific optimization/logic, but I don't see why we need STPs for 80% (if not more) of the CRUD and basic queries. I also agree with Tal later in the thread that its a good question if we can't find a better solution than re-writing the sql's in the code From iheim at redhat.com Wed Mar 27 12:39:03 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 27 Mar 2013 14:39:03 +0200 Subject: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment? In-Reply-To: References: Message-ID: <5152E867.4070108@redhat.com> On 03/26/2013 05:50 AM, Chen, Wei D wrote: > Hi, > > We notice that ovirt-engine's version (rpm package and source code) has updated from 3.2.0 to 3.2.1. As our development process is always based on 3.2.0. Is there any way to re-setup 3.2.0 running environment? re-setup as in destroy and re-install, or just upgrade (engine-upgrade should take care of that for you) > > Besides, we also cannot setup 3.2.1 ovrit-engine running environment as its dependent package glusterfs-3.4 cannot be found from ovirt repo or fedora18 repo. How can I fix this issue? Thanks. > > Best Regards, > Dave Chen > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mkolesni at redhat.com Wed Mar 27 14:04:50 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Wed, 27 Mar 2013 10:04:50 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <5152F587.3080403@redhat.com> Message-ID: <884500025.7114834.1364393089993.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/27/2013 01:36 PM, Mike Kolesnik wrote: > > ----- Original Message ----- > >> Hello, > >> > >> according to my experiences Hibernate/JPA is the best solution for > >> application > >> which has to support multiple databases. > > > > +1 > > > > JPA would be much easier to maintain than the current approach. > > In most cases the stored procedures we use are for CRUD operations, > > and can be easily replaced. > > The exceptions can be dealt with when necessary, but generally it > > seems like an excellent direction to me. > > > >> Even when I was part of the > >> team who > >> migrated application with business login written in Oracle PL/SQL > >> procedures > >> to JBoss using Hibernate (application ran only on Oracle), it > >> became > >> much easier > >> to maintain this applications and also customer was pleased that > >> application > >> ran much better. > >> > >> Now imagine the scenario, that for example Postgresql, MySQL, > >> Oracle > >> and MS SQL would be > >> supported. I you need to change some stored procedure you should > >> do > >> this on 4 places using > >> 4 different database dialects. > >> > >> Like any other technologies, Hibernate/JPA has some drawbacks, but > >> when it's used properly > >> and database objects are redesigned to fit Hibernate and > >> portability > >> needs, it works fine. > > > > I don't think our DB/POJO design is very problematic in this > > regard.. > > I think we can replace most of the existing DAOs with ORM backed > > implementations with very little work. > > > > What we need to make sure is not break the DAO API. > > For example, if I fetch an entity from a Session, > > it would reflect any change that happens to it automatically to the > > DB. > > This is not how the current API works, so this feature should be > > disabled > > or otherwise we would have a hard time hunting the bugs that will > > spawn > > from this change of behavior. > > > > This is in my opinion the main disadvantage of using Hibernate (or > any > other JPA implementation) with our current architecture. However > Hibernate provides the stateless session concept, which is not > standard > but could help. Alternatively, we could detach from session on fetch, and re-attach on save/update. Anyway, it still adds the benefit of ORM which would still simplify much of the code, and provide the desired portability. Also I think if we move to the direction of ORM, it would be easier to change the rest of the application code to behave differently, should we choose to do it. > > >> > >> > >> > >> Martin Perina > >> > >> > >> ----- Original Message ----- > >>> From: "Alon Bar-Lev" > >>> To: "Juan Hernandez" > >>> Cc: engine-devel at ovirt.org > >>> Sent: Tuesday, March 26, 2013 7:39:16 PM > >>> Subject: Re: [Engine-devel] Move SQL out of stored procedures > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Juan Hernandez" > >>>> To: engine-devel at ovirt.org > >>>> Sent: Tuesday, March 26, 2013 7:34:04 PM > >>>> Subject: [Engine-devel] Move SQL out of stored procedures > >>>> > >>>> Hello, > >>>> > >>>> I would like to start a discussion about the subject. I think > >>>> this > >>>> is > >>>> something we need to do if one day we want to be able to use any > >>>> database other than PostgreSQL. > >>> > >>> Hello, > >>> > >>> I think that database layer is a software interface like any > >>> other > >>> software interface, if done properly, a dba can convert the > >>> stored > >>> procedure to any other database without any code change. > >>> > >>> This way the database specific implementation lives within the > >>> database and maintained by the designated dba. > >>> > >>> Fixups and optimizations can be done in database without touching > >>> the > >>> code. > >>> > >>> Backward compatibility layer is much simpler to implement based > >>> on > >>> stored procedures than complex set of views and tables. > >>> > >>> Also, accessing the database via different technologies is > >>> simpler > >>> if > >>> there is maintained database interface (stored procedures). > >>> > >>> I've seen hibernate based java applications that promised to be > >>> database independent but at the edges when performance counts, > >>> the > >>> DAO became HQL, then a special dialect and finally database > >>> specific > >>> SQLS. > >>> > >>> Regards, > >>> Alon Bar-Lev. > >>> _______________________________________________ > >>> 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 abonas at redhat.com Wed Mar 27 15:01:11 2013 From: abonas at redhat.com (Alissa Bonas) Date: Wed, 27 Mar 2013 11:01:11 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <5152EBD9.5050404@redhat.com> Message-ID: <694252132.61298986.1364396471514.JavaMail.root@redhat.com> I suggest that there should be 2 different (though related) issues to consider here in this thread: 1. How the code works with database in runtime (CRUD) - and this is what the Hibernate/JPA/etc. discussion is so far about. 2. Maintenance/upgrade/modification of the database schema - which is also very important, done pretty frequently in this project, and is also sometimes database vendor sensitive (for example - column types/indexes differ, syntax differs a bit). Doing changes in the database structure is not done in runtime, but should be still very easy and maintainable for the developers (and transparent to them wherever possible to hide vendor differences). I had good experience with Liquibase for creating/upgrading database schemas so I propose to evaluate it. http://www.liquibase.org/ ----- Original Message ----- > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: "Juan Hernandez" , engine-devel at ovirt.org > Sent: Wednesday, March 27, 2013 2:53:45 PM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > >> From: "Juan Hernandez" > >> To: engine-devel at ovirt.org > >> Sent: Tuesday, March 26, 2013 7:34:04 PM > >> Subject: [Engine-devel] Move SQL out of stored procedures > >> > >> Hello, > >> > >> I would like to start a discussion about the subject. I think this > >> is > >> something we need to do if one day we want to be able to use any > >> database other than PostgreSQL. > > > > Hello, > > > > I think that database layer is a software interface like any other > > software interface, if done properly, a dba can convert the stored > > procedure to any other database without any code change. > > > > This way the database specific implementation lives within the > > database and maintained by the designated dba. > > > > Fixups and optimizations can be done in database without touching > > the code. > > > > Backward compatibility layer is much simpler to implement based on > > stored procedures than complex set of views and tables. > > > > Also, accessing the database via different technologies is simpler > > if there is maintained database interface (stored procedures). > > > > I've seen hibernate based java applications that promised to be > > database independent but at the edges when performance counts, the > > DAO became HQL, then a special dialect and finally database > > specific SQLS. > > there may be db specific optimization/logic, but I don't see why we > need > STPs for 80% (if not more) of the CRUD and basic queries. > > I also agree with Tal later in the thread that its a good question if > we > can't find a better solution than re-writing the sql's in the code > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mkolesni at redhat.com Wed Mar 27 12:36:56 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Wed, 27 Mar 2013 08:36:56 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <1050936377.24270432.1364363940352.JavaMail.root@redhat.com> Message-ID: <1333423756.7053414.1364387816813.JavaMail.root@redhat.com> ----- Original Message ----- > Hello, > > according to my experiences Hibernate/JPA is the best solution for > application > which has to support multiple databases. +1 JPA would be much easier to maintain than the current approach. In most cases the stored procedures we use are for CRUD operations, and can be easily replaced. The exceptions can be dealt with when necessary, but generally it seems like an excellent direction to me. > Even when I was part of the > team who > migrated application with business login written in Oracle PL/SQL > procedures > to JBoss using Hibernate (application ran only on Oracle), it became > much easier > to maintain this applications and also customer was pleased that > application > ran much better. > > Now imagine the scenario, that for example Postgresql, MySQL, Oracle > and MS SQL would be > supported. I you need to change some stored procedure you should do > this on 4 places using > 4 different database dialects. > > Like any other technologies, Hibernate/JPA has some drawbacks, but > when it's used properly > and database objects are redesigned to fit Hibernate and portability > needs, it works fine. I don't think our DB/POJO design is very problematic in this regard.. I think we can replace most of the existing DAOs with ORM backed implementations with very little work. What we need to make sure is not break the DAO API. For example, if I fetch an entity from a Session, it would reflect any change that happens to it automatically to the DB. This is not how the current API works, so this feature should be disabled or otherwise we would have a hard time hunting the bugs that will spawn from this change of behavior. > > > > Martin Perina > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Juan Hernandez" > > Cc: engine-devel at ovirt.org > > Sent: Tuesday, March 26, 2013 7:39:16 PM > > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > > > > > > > ----- Original Message ----- > > > From: "Juan Hernandez" > > > To: engine-devel at ovirt.org > > > Sent: Tuesday, March 26, 2013 7:34:04 PM > > > Subject: [Engine-devel] Move SQL out of stored procedures > > > > > > Hello, > > > > > > I would like to start a discussion about the subject. I think > > > this > > > is > > > something we need to do if one day we want to be able to use any > > > database other than PostgreSQL. > > > > Hello, > > > > I think that database layer is a software interface like any other > > software interface, if done properly, a dba can convert the stored > > procedure to any other database without any code change. > > > > This way the database specific implementation lives within the > > database and maintained by the designated dba. > > > > Fixups and optimizations can be done in database without touching > > the > > code. > > > > Backward compatibility layer is much simpler to implement based on > > stored procedures than complex set of views and tables. > > > > Also, accessing the database via different technologies is simpler > > if > > there is maintained database interface (stored procedures). > > > > I've seen hibernate based java applications that promised to be > > database independent but at the edges when performance counts, the > > DAO became HQL, then a special dialect and finally database > > specific > > SQLS. > > > > Regards, > > Alon Bar-Lev. > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mkolesni at redhat.com Wed Mar 27 12:18:38 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Wed, 27 Mar 2013 08:18:38 -0400 (EDT) Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <5152B353.9050804@redhat.com> Message-ID: <36623975.7044697.1364386718971.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/20/2013 08:20 PM, Yair Zaslavsky wrote: > > > > ----- Original Message ----- > >> From: "Shireesh Anjal" > >> To: "Mike Kolesnik" > >> Cc: engine-devel at ovirt.org > >> Sent: Wednesday, March 20, 2013 4:47:08 PM > >> Subject: Re: [Engine-devel] FeatureSupported and compatibility > >> versions > >> > >> On 03/18/2013 01:11 PM, Shireesh Anjal wrote: > >>> On 03/18/2013 12:59 PM, Mike Kolesnik wrote: > >>>> ----- Original Message ----- > >>>>> Hi all, > >>>>> > >>>>> The current mechanism in oVirt to check whether a feature is > >>>>> supported > >>>>> in a particular compatibility version is to use the > >>>>> FeatureSupported > >>>>> class. e.g. > >>>>> > >>>>> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) > >>>>> > >>>>> > >>>>> Checks whether the "network linking" feature is supported for > >>>>> the > >>>>> the > >>>>> VM's cluster compatibility version. This internally checks > >>>>> whether > >>>>> the > >>>>> value of the corresponding config (NetworkLinkingSupported) for > >>>>> the > >>>>> given compatibility version is true/false. > >>>>> > >>>>> I'm not sure if this is a good idea, since a feature is > >>>>> typically > >>>>> supported "from" a particular version. E.g. Gluster support was > >>>>> introduced in 3.1, and it continues to be available in all > >>>>> subsequent > >>>>> versions. So I see no point in adding configuration for every > >>>>> version > >>>>> indicating whether the feature is supported in that version or > >>>>> not. I > >>>>> suggest to use either of the following options: > >>>> You can "merge" the configs into a single config when older > >>>> versions > >>>> go out of the supported versions for the system. > >>>> > >>>> i.e. in 4.0 you can have upgrade script that merges all > >>>> GlusterFeatureSupported to one entry instead of several. > >> Why are we even storing this information in config? Is this > >> something > >> that can be "configured" at customer site? > > As previously explained (but off list :) ) , Config gives you the > > ability to have a cachable "map" of entry (i.e - "feature name") > > per version and value. > > I guess it was convinient for the developers to use that. > > I also mentioned that customers/oVirt users should config the > > entries of vdc_options using engine-config tool only. > > Not all entries are exposed via engine-config.properties (and no, > > not just "is feature supported" entries are hidden). > > > > > > > > > >>>>> 1) Instead of using a boolean config for each version, use a > >>>>> single > >>>>> string config that indicates the "supported from" version e.g. > >>>>> GlusterSupportedFrom = 3.1. There could be rare cases where a > >>>>> feature, > >>>>> for some reason, is removed in some release. In such cases, we > >>>>> could > >>>>> use > >>>>> one additional config for the "supported to" version. > >>>>> > >>>>> 2) Continue with the boolean approach, but do not have entries > >>>>> for > >>>>> every > >>>>> version; rather make use of the "default value" for majority of > >>>>> cases, > >>>>> and add the explicit version mapping for the minority e.g. > >>>>> GlusterSupported = true by default, and false in case of 3.0 > >>>>> (only > >>>>> one > >>>>> config required for 3.0) > >>>> I'm not sure why we would want to complicate this simple > >>>> mechanism? > >>>> > >>>> Is there much to gain? > >>> I think option 1 suggested above is simpler - to implement as > >>> well > >>> as > >>> to understand. > >>> > >>> Let me give you an example of why I don't like current mechanism. > >>> I > >>> introduce a version check for a feature that was introduced in > >>> 3.1. > >>> I'm being asked now to add three entries in config > >>> > >>> 3.0 - false > >>> 3.1 - true > >>> 3.2 - true > >>> > >>> It will also mean that when 3.3 goes out, someone has to make > >>> sure > >>> that another entry is added for 3.3-true. I think it is not > >>> logical > >>> as > >>> well as scalable if you have more versions. And it sounds far > >>> more > >>> complex (to maintain) than just having > >>> > >>> SupportedFrom = 3.1 > >>> > >>> So I would like to know if there are any objections to my > >>> proposal. > >>> I > >>> intend to use this for at least the gluster related features. > > I've sent a patch (http://gerrit.ovirt.org/12970) with following > changes: > > 1) Introduced CompatibilityUtils that provides utility methods for > checking if a given feature is supported in the config. One method to > check based on boolean values (as is being done today for virt > features), and nother to check based on a range (from, to) which I > would > like to use for gluster features. > 2) Renamed FeatureSupported to VirtFeatureSupported, and made it use > the > first utility method from CompatibilityUtils > 3) Introduced GlusterFeatureSupported for gluster features, which > uses > the second utility method from CompatibilityUtils > > Key advantage here is that > - we don't have to touch any virt specifc source for adding > compatibility checks for gluster features > - virt features continue to use the existing boolean config check > > Any comments / suggestions / reviews will be highly appreciated :) I think splitting to two classes is OK, but the underlying mechanism IMO should be as Omer suggested: Use the default value from the java config file, and if in the DB there is a version specific value then use it for that version only. I don't think "From, To, etc" is a good design, it's not a standard way and is very restrictive. > > >>>>> Thoughts? > >>>>> > >>>>> Regards, > >>>>> Shireesh From wei.d.chen at intel.com Thu Mar 28 01:14:53 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Thu, 28 Mar 2013 01:14:53 +0000 Subject: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment? In-Reply-To: <5152E867.4070108@redhat.com> References: <5152E867.4070108@redhat.com> Message-ID: Just want to setup 3.2.0 or 3.2.1 ovirt engine running environment. Thanks. Best Regards, Dave Chen -----Original Message----- From: Itamar Heim [mailto:iheim at redhat.com] Sent: Wednesday, March 27, 2013 8:39 PM To: Chen, Wei D Cc: engine-devel at ovirt.org Subject: Re: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment? On 03/26/2013 05:50 AM, Chen, Wei D wrote: > Hi, > > We notice that ovirt-engine's version (rpm package and source code) has updated from 3.2.0 to 3.2.1. As our development process is always based on 3.2.0. Is there any way to re-setup 3.2.0 running environment? re-setup as in destroy and re-install, or just upgrade (engine-upgrade should take care of that for you) > > Besides, we also cannot setup 3.2.1 ovrit-engine running environment as its dependent package glusterfs-3.4 cannot be found from ovirt repo or fedora18 repo. How can I fix this issue? Thanks. > > Best Regards, > Dave Chen > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mperina at redhat.com Thu Mar 28 08:48:07 2013 From: mperina at redhat.com (Martin Perina) Date: Thu, 28 Mar 2013 04:48:07 -0400 (EDT) Subject: [Engine-devel] Adding JCommander library to projects In-Reply-To: <393753761.434679.1364459766962.JavaMail.root@redhat.com> Message-ID: <237699408.438976.1364460487813.JavaMail.root@redhat.com> Hi, I'm currently working on bug 904029, support for POSIX parameters and values in engine-manage-domains. I think there are two possible solutions: 1) Write custom parser (similar to EngineConfigCLIParser used for engine-config) 2) Add CLI parsing library to project and use it for all command line clients (first implementation could be for engine-manage-domains) I think 2) is much better approach, but I'm not sure about the process of adding new library to project. Personally I like JCommander ( http://jcommander.org ), using annotation for parameter specification is great. JCommander is licensed with Apache 2.0 license, so the addition shouldn't be a problem. So, would it be possible to add JCommander library to project? Martin Perina From alonbl at redhat.com Thu Mar 28 09:18:19 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 28 Mar 2013 05:18:19 -0400 (EDT) Subject: [Engine-devel] Adding JCommander library to projects In-Reply-To: <237699408.438976.1364460487813.JavaMail.root@redhat.com> Message-ID: <1204349569.9636953.1364462299744.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Martin Perina" > To: engine-devel at ovirt.org > Sent: Thursday, March 28, 2013 10:48:07 AM > Subject: [Engine-devel] Adding JCommander library to projects > > Hi, > > I'm currently working on bug 904029, support for POSIX parameters and > values > in engine-manage-domains. I think there are two possible solutions: > > 1) Write custom parser (similar to EngineConfigCLIParser used for > engine-config) > 2) Add CLI parsing library to project and use it for all command > line clients > (first implementation could be for engine-manage-domains) > > I think 2) is much better approach, but I'm not sure about the > process of adding new > library to project. > > Personally I like JCommander ( http://jcommander.org ), using > annotation for parameter > specification is great. JCommander is licensed with Apache 2.0 > license, so the addition > shouldn't be a problem. > > So, would it be possible to add JCommander library to project? I believe that any other solution will be better than current situation. However, I recommend of horizontal change when such introduced, leaving hybrid implementation in tree will just make maintenance cost higher when introducing new dependency. It should not be that difficult to port all current implementation to the new dependency when selected. Regards, Alon. From mperina at redhat.com Thu Mar 28 10:01:45 2013 From: mperina at redhat.com (Martin Perina) Date: Thu, 28 Mar 2013 06:01:45 -0400 (EDT) Subject: [Engine-devel] Adding JCommander library to projects In-Reply-To: <1204349569.9636953.1364462299744.JavaMail.root@redhat.com> Message-ID: <1926043947.473389.1364464905560.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Martin Perina" > Cc: engine-devel at ovirt.org > Sent: Thursday, March 28, 2013 10:18:19 AM > Subject: Re: [Engine-devel] Adding JCommander library to projects > > > > ----- Original Message ----- > > From: "Martin Perina" > > To: engine-devel at ovirt.org > > Sent: Thursday, March 28, 2013 10:48:07 AM > > Subject: [Engine-devel] Adding JCommander library to projects > > > > Hi, > > > > I'm currently working on bug 904029, support for POSIX parameters > > and > > values > > in engine-manage-domains. I think there are two possible solutions: > > > > 1) Write custom parser (similar to EngineConfigCLIParser used for > > engine-config) > > 2) Add CLI parsing library to project and use it for all command > > line clients > > (first implementation could be for engine-manage-domains) > > > > I think 2) is much better approach, but I'm not sure about the > > process of adding new > > library to project. > > > > Personally I like JCommander ( http://jcommander.org ), using > > annotation for parameter > > specification is great. JCommander is licensed with Apache 2.0 > > license, so the addition > > shouldn't be a problem. > > > > So, would it be possible to add JCommander library to project? > > I believe that any other solution will be better than current > situation. > > However, I recommend of horizontal change when such introduced, > leaving hybrid implementation in tree will just make maintenance > cost higher when introducing new dependency. It should not be that > difficult to port all current implementation to the new dependency > when selected. > > Regards, > Alon. > Sure, reference implementation will be for engine-manage-domains and after that I will implement this solution for the rest of commands. Martin From omasad at redhat.com Thu Mar 28 10:05:02 2013 From: omasad at redhat.com (Ofri Masad) Date: Thu, 28 Mar 2013 06:05:02 -0400 (EDT) Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review In-Reply-To: Message-ID: <60519417.9696375.1364465102897.JavaMail.root@redhat.com> Hi Dave, I would like to raise again the question of the full cache flash for each stale cache entry found. This method can cause two unwanted situations: 1. Choosing untrusted host: lets say, for example that you have 1000 host in your pool. you look at the first host in the cache and find that its attestation hat expired. you refresh the entire pool (there are 1000 host, that must take some time). by the the time the last host was refreshed in the pool, the first host may already be expired again. but since you already checked it - you keep on with your flow and select that host, even so it has expired and may as well be untrusted. 2. infinite loop: lets say we'll try to fix what I've described in 1. then, we need to check again if the host has expired before we select it. if it is, the entire refresh process starts again. this could potentially go on forever (unless I'm missing something, and the expiration is much longer then the full re-cache process). Instead of re-caching the full cache we can do as follows: - hold the cache entries sorted by expiration (if the expiration time is the same for all hosts, so a queue is enough). - each time we need a new trusted host - select from the unexpired hosts, refresh all expired hosts (in one query). - if all hosts are expired - we can wait for the first host to be defined trusted by the attestation server and select that host. Ofri ----- Original Message ----- > From: "Wei D Chen" > To: engine-devel at ovirt.org > Sent: Friday, March 22, 2013 11:34:55 AM > Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your > review > > Hi all, > > Before submitting this patch set, we has updated our design page, and > new feature about VM template has added to this patchset. In > patchset a lot of frontend changes has been imported. > Welcome to review our patchset and thanks advance for your > suggestion. > > > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools > > In this patch set, follow changes has been introduced: > > 1. GUI changes to support for creating a trusted VM on a trusted > physical host. > 2. View/Edit VM changes to enable end user switch between three run > on options. > 3. Template relevant changes to support end user create a trusted VM > template and create trusted VM based on this template afterwards. > 4. Bug fixing and code cleanup. > 5. wiki design page update. > > > > Best Regards, > Dave Chen > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From sanjal at redhat.com Thu Mar 28 12:47:49 2013 From: sanjal at redhat.com (Shireesh Anjal) Date: Thu, 28 Mar 2013 18:17:49 +0530 Subject: [Engine-devel] FeatureSupported and compatibility versions In-Reply-To: <36623975.7044697.1364386718971.JavaMail.root@redhat.com> References: <36623975.7044697.1364386718971.JavaMail.root@redhat.com> Message-ID: <51543BF5.3050505@redhat.com> On 03/27/2013 05:48 PM, Mike Kolesnik wrote: > ----- Original Message ----- >> On 03/20/2013 08:20 PM, Yair Zaslavsky wrote: >>> ----- Original Message ----- >>>> From: "Shireesh Anjal" >>>> To: "Mike Kolesnik" >>>> Cc: engine-devel at ovirt.org >>>> Sent: Wednesday, March 20, 2013 4:47:08 PM >>>> Subject: Re: [Engine-devel] FeatureSupported and compatibility >>>> versions >>>> >>>> On 03/18/2013 01:11 PM, Shireesh Anjal wrote: >>>>> On 03/18/2013 12:59 PM, Mike Kolesnik wrote: >>>>>> ----- Original Message ----- >>>>>>> Hi all, >>>>>>> >>>>>>> The current mechanism in oVirt to check whether a feature is >>>>>>> supported >>>>>>> in a particular compatibility version is to use the >>>>>>> FeatureSupported >>>>>>> class. e.g. >>>>>>> >>>>>>> FeatureSupported.networkLinking(getVm().getVdsGroupCompatibilityVersion()) >>>>>>> >>>>>>> >>>>>>> Checks whether the "network linking" feature is supported for >>>>>>> the >>>>>>> the >>>>>>> VM's cluster compatibility version. This internally checks >>>>>>> whether >>>>>>> the >>>>>>> value of the corresponding config (NetworkLinkingSupported) for >>>>>>> the >>>>>>> given compatibility version is true/false. >>>>>>> >>>>>>> I'm not sure if this is a good idea, since a feature is >>>>>>> typically >>>>>>> supported "from" a particular version. E.g. Gluster support was >>>>>>> introduced in 3.1, and it continues to be available in all >>>>>>> subsequent >>>>>>> versions. So I see no point in adding configuration for every >>>>>>> version >>>>>>> indicating whether the feature is supported in that version or >>>>>>> not. I >>>>>>> suggest to use either of the following options: >>>>>> You can "merge" the configs into a single config when older >>>>>> versions >>>>>> go out of the supported versions for the system. >>>>>> >>>>>> i.e. in 4.0 you can have upgrade script that merges all >>>>>> GlusterFeatureSupported to one entry instead of several. >>>> Why are we even storing this information in config? Is this >>>> something >>>> that can be "configured" at customer site? >>> As previously explained (but off list :) ) , Config gives you the >>> ability to have a cachable "map" of entry (i.e - "feature name") >>> per version and value. >>> I guess it was convinient for the developers to use that. >>> I also mentioned that customers/oVirt users should config the >>> entries of vdc_options using engine-config tool only. >>> Not all entries are exposed via engine-config.properties (and no, >>> not just "is feature supported" entries are hidden). >>> >>> >>> >>> >>>>>>> 1) Instead of using a boolean config for each version, use a >>>>>>> single >>>>>>> string config that indicates the "supported from" version e.g. >>>>>>> GlusterSupportedFrom = 3.1. There could be rare cases where a >>>>>>> feature, >>>>>>> for some reason, is removed in some release. In such cases, we >>>>>>> could >>>>>>> use >>>>>>> one additional config for the "supported to" version. >>>>>>> >>>>>>> 2) Continue with the boolean approach, but do not have entries >>>>>>> for >>>>>>> every >>>>>>> version; rather make use of the "default value" for majority of >>>>>>> cases, >>>>>>> and add the explicit version mapping for the minority e.g. >>>>>>> GlusterSupported = true by default, and false in case of 3.0 >>>>>>> (only >>>>>>> one >>>>>>> config required for 3.0) >>>>>> I'm not sure why we would want to complicate this simple >>>>>> mechanism? >>>>>> >>>>>> Is there much to gain? >>>>> I think option 1 suggested above is simpler - to implement as >>>>> well >>>>> as >>>>> to understand. >>>>> >>>>> Let me give you an example of why I don't like current mechanism. >>>>> I >>>>> introduce a version check for a feature that was introduced in >>>>> 3.1. >>>>> I'm being asked now to add three entries in config >>>>> >>>>> 3.0 - false >>>>> 3.1 - true >>>>> 3.2 - true >>>>> >>>>> It will also mean that when 3.3 goes out, someone has to make >>>>> sure >>>>> that another entry is added for 3.3-true. I think it is not >>>>> logical >>>>> as >>>>> well as scalable if you have more versions. And it sounds far >>>>> more >>>>> complex (to maintain) than just having >>>>> >>>>> SupportedFrom = 3.1 >>>>> >>>>> So I would like to know if there are any objections to my >>>>> proposal. >>>>> I >>>>> intend to use this for at least the gluster related features. >> I've sent a patch (http://gerrit.ovirt.org/12970) with following >> changes: >> >> 1) Introduced CompatibilityUtils that provides utility methods for >> checking if a given feature is supported in the config. One method to >> check based on boolean values (as is being done today for virt >> features), and nother to check based on a range (from, to) which I >> would >> like to use for gluster features. >> 2) Renamed FeatureSupported to VirtFeatureSupported, and made it use >> the >> first utility method from CompatibilityUtils >> 3) Introduced GlusterFeatureSupported for gluster features, which >> uses >> the second utility method from CompatibilityUtils >> >> Key advantage here is that >> - we don't have to touch any virt specifc source for adding >> compatibility checks for gluster features >> - virt features continue to use the existing boolean config check >> >> Any comments / suggestions / reviews will be highly appreciated :) > I think splitting to two classes is OK, but the underlying mechanism IMO should be as Omer suggested: > Use the default value from the java config file, and if in the DB there is a version specific value then use it for that version only. Review comments here are on the contrary: http://gerrit.ovirt.org/#/c/12970/5/backend/manager/dbscripts/upgrade/pre_upgrade/0000_config.sql > I don't think "From, To, etc" is a good design, it's not a standard way and is very restrictive. Can you please explain in what way is it restrictive? Also, what is the "etc" you are referring to? > >>>>>>> Thoughts? >>>>>>> >>>>>>> Regards, >>>>>>> Shireesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfediuck at redhat.com Thu Mar 28 14:43:19 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Thu, 28 Mar 2013 10:43:19 -0400 (EDT) Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review In-Reply-To: <60519417.9696375.1364465102897.JavaMail.root@redhat.com> Message-ID: <1014066770.26313104.1364481799434.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ofri Masad" > To: "Wei D Chen" > Cc: engine-devel at ovirt.org > Sent: Thursday, March 28, 2013 12:05:02 PM > Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your > review > > Hi Dave, > > I would like to raise again the question of the full cache flash for > each stale cache entry found. > This method can cause two unwanted situations: > 1. Choosing untrusted host: lets say, for example that you have 1000 > host in your pool. you look at the first host in the cache and find > that its attestation hat expired. you refresh the entire pool > (there are 1000 host, that must take some time). by the the time > the last host was refreshed in the pool, the first host may already > be expired again. but since you already checked it - you keep on > with your flow and select that host, even so it has expired and may > as well be untrusted. > > 2. infinite loop: lets say we'll try to fix what I've described in > 1. then, we need to check again if the host has expired before we > select it. if it is, the entire refresh process starts again. this > could potentially go on forever (unless I'm missing something, and > the expiration is much longer then the full re-cache process). > > Instead of re-caching the full cache we can do as follows: > - hold the cache entries sorted by expiration (if the expiration > time is the same for all hosts, so a queue is enough). > - each time we need a new trusted host - select from the unexpired > hosts, refresh all expired hosts (in one query). > - if all hosts are expired - we can wait for the first host to be > defined trusted by the attestation server and select that host. > > Ofri > > Dave, adding another suggestion on top of Ofri's; Generally speaking, a cluster of hosts defines many joint features (such as CPU level), which means that in the same cluster we would expect to be able to freely migrate a VM from one host to another. Current trust-pools design is breaking this concept, as you introduce a state where a VM cannot migrate from a 'safe' host into an 'unsafe' host. This leads me to the suggestion of having attestation as a cluster policy rather than a VM-level property. It means that all hosts in this cluster are constantly being monitored to be safe. If a host is declared as unsafe in the Attestation server, it will become non-operational in the engine. This will simplify the implementation since you have everything ready for you once you have a 'safe' cluster and no need to do any VM-level changes. So in this way you keep current concepts while simplifying the implementation with very little worries of performance issues. Can you please share your thoughts on this suggestion? > ----- Original Message ----- > > From: "Wei D Chen" > > To: engine-devel at ovirt.org > > Sent: Friday, March 22, 2013 11:34:55 AM > > Subject: [Engine-devel] Open Attestation integration with oVirt > > engine proposal has submitted patchset5 for your > > review > > > > Hi all, > > > > Before submitting this patch set, we has updated our design page, > > and > > new feature about VM template has added to this patchset. In > > patchset a lot of frontend changes has been imported. > > Welcome to review our patchset and thanks advance for your > > suggestion. > > > > > > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools > > > > In this patch set, follow changes has been introduced: > > > > 1. GUI changes to support for creating a trusted VM on a trusted > > physical host. > > 2. View/Edit VM changes to enable end user switch between three run > > on options. > > 3. Template relevant changes to support end user create a trusted > > VM > > template and create trusted VM based on this template afterwards. > > 4. Bug fixing and code cleanup. > > 5. wiki design page update. > > > > > > > > Best Regards, > > Dave Chen > > > > From lspevak at redhat.com Thu Mar 28 15:04:20 2013 From: lspevak at redhat.com (Libor Spevak) Date: Thu, 28 Mar 2013 16:04:20 +0100 Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <5152EBD9.5050404@redhat.com> References: <209251507.9203475.1364323156605.JavaMail.root@redhat.com> <5152EBD9.5050404@redhat.com> Message-ID: <51545BF4.20204@redhat.com> Hi, apart from SQL vs. stored procedures discussion, I am trying to understand what we can get if we support more databases... Some points: 1. Is there a real need by end-users/customers to run it on e.g. Oracle only? (performance, stability, easier administration). What is the future of PostgreSQL? 2. Is it decided by architectural board, what kind of databases we would like to support? (cannot support any db) 3. Are we talking about the Engine only, or there will be a need to rewrite ETL mappings and upgrade DWH database, or maybe modify JasperReports templates (simply, some DB types behave differently)? Maybe we can look at JasperSoft solution, they support more databases. 4. Current full/incremental upgrade process of PostgreSQL is IMHO very good tuned (it is similar to dbmaintain.org tool - Java implementation - I used successfully on one project - after some changes of course). I do not believe we can use or easily develop general upgrade/migration tool, and XML based (I am sorry Alissa, not sure about Liquibase, I haven't studied it deeply, but there is a need to incrementally change db objects, but sometimes also to migrate data to new structures, the most flexible and quickest is to do it using native SQL, but yes, it depends on the project needs...). 5. As a developer, with every new column I need to write upgrade scripts, prepare test environments and test all scenarios several times on different databases, so time-consuming. On 27.3.2013 13:53, Itamar Heim wrote: > On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: >> >> >> ----- Original Message ----- >>> From: "Juan Hernandez" >>> To: engine-devel at ovirt.org >>> Sent: Tuesday, March 26, 2013 7:34:04 PM >>> Subject: [Engine-devel] Move SQL out of stored procedures >>> >>> Hello, >>> >>> I would like to start a discussion about the subject. I think this is >>> something we need to do if one day we want to be able to use any >>> database other than PostgreSQL. >> >> Hello, >> >> I think that database layer is a software interface like any other >> software interface, if done properly, a dba can convert the stored >> procedure to any other database without any code change. >> >> This way the database specific implementation lives within the >> database and maintained by the designated dba. >> >> Fixups and optimizations can be done in database without touching the >> code. >> >> Backward compatibility layer is much simpler to implement based on >> stored procedures than complex set of views and tables. >> >> Also, accessing the database via different technologies is simpler if >> there is maintained database interface (stored procedures). >> >> I've seen hibernate based java applications that promised to be >> database independent but at the edges when performance counts, the >> DAO became HQL, then a special dialect and finally database specific >> SQLS. > > there may be db specific optimization/logic, but I don't see why we > need STPs for 80% (if not more) of the CRUD and basic queries. > > I also agree with Tal later in the thread that its a good question if > we can't find a better solution than re-writing the sql's in the code > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From vszocs at redhat.com Thu Mar 28 15:24:59 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 28 Mar 2013 11:24:59 -0400 (EDT) Subject: [Engine-devel] UI Plugin API improvements In-Reply-To: <1401998609.20784520.1364483303436.JavaMail.root@redhat.com> Message-ID: <678163471.20791553.1364484299073.JavaMail.root@redhat.com> Hi guys, I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new. Modal dialog API ================ Function improved: showDialog New signature: showDialog(title, dialogToken, contentUrl, width, height [, options]) Example usage: showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { // Default value = empty array (no buttons) buttons: [ { label: 'Do stuff', onClick: function() { alert('Bump!'); } } ], // Default value = false resizeEnabled: true, // Default value = true closeIconVisible: true, // Default value = true closeOnEscKey: true }); Notable changes: * modal dialogs now look & feel the same as standard WebAdmin dialogs * width & height are strings containing CSS units * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!) -- New function: setDialogContentUrl New signature: setDialogContentUrl(dialogToken, contentUrl) Example usage: setDialogContentUrl('my-dialog', 'http://www.example.com/') -- New function: closeDialog New signature: closeDialog(dialogToken) Example usage: closeDialog('my-dialog') Tab API ======= Functions improved: addMainTab & addSubTab New signatures: addMainTab(label, historyToken, contentUrl [, options]) addSubTab(entityTypeName, label, historyToken, contentUrl [, options]) Example usage: // Tab is left-aligned by default addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/'); // Tab is right-aligned via options object addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { alignRight: true }); -- Regards, Vojtech From lhornyak at redhat.com Thu Mar 28 15:31:34 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 28 Mar 2013 11:31:34 -0400 (EDT) Subject: [Engine-devel] Move SQL out of stored procedures In-Reply-To: <51545BF4.20204@redhat.com> Message-ID: <1442496988.16060758.1364484694306.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Libor Spevak" > To: "Itamar Heim" > Cc: "Juan Hernandez" , engine-devel at ovirt.org > Sent: Thursday, March 28, 2013 4:04:20 PM > Subject: Re: [Engine-devel] Move SQL out of stored procedures > > Hi, > > apart from SQL vs. stored procedures discussion, I am trying to > understand what we can get if we support more databases... > > Some points: > 1. Is there a real need by end-users/customers to run it on e.g. > Oracle > only? (performance, stability, easier administration). Usually companies have one database and they are trying to stick to that one. Having two doubles the resource needs, you need one more DBA team, care for mirrors, backups. So it almost doubles the costs. This is why I frequently hear people asking if we plan to support XyDB in the future. PostgreSQL is cool, but those who already use MySQL/MariaDB, they just do not want one more. > What is the future of PostgreSQL? > > 2. Is it decided by architectural board, what kind of databases we > would > like to support? (cannot support any db) With a JPA we could support most mainstream relational databases, but in my opinion 99 percent of people run oracle, mysql/mariadb or postgresql. So maybe we do not have to think in big number of database engines. This is theoretical since JPA is still on wishlist :( > > 3. Are we talking about the Engine only, or there will be a need to > rewrite ETL mappings and upgrade DWH database, or maybe modify > JasperReports templates (simply, some DB types behave differently)? > Maybe we can look at JasperSoft solution, they support more > databases. > > 4. Current full/incremental upgrade process of PostgreSQL is IMHO > very > good tuned (it is similar to dbmaintain.org tool - Java > implementation - > I used successfully on one project - after some changes of course). I > do > not believe we can use or easily develop general upgrade/migration > tool, > and XML based (I am sorry Alissa, not sure about Liquibase, I haven't > studied it deeply, but there is a need to incrementally change db > objects, but sometimes also to migrate data to new structures, the > most > flexible and quickest is to do it using native SQL, but yes, it > depends > on the project needs...). > > 5. As a developer, with every new column I need to write upgrade > scripts, prepare test environments and test all scenarios several > times > on different databases, so time-consuming. > > > On 27.3.2013 13:53, Itamar Heim wrote: > > On 03/26/2013 08:39 PM, Alon Bar-Lev wrote: > >> > >> > >> ----- Original Message ----- > >>> From: "Juan Hernandez" > >>> To: engine-devel at ovirt.org > >>> Sent: Tuesday, March 26, 2013 7:34:04 PM > >>> Subject: [Engine-devel] Move SQL out of stored procedures > >>> > >>> Hello, > >>> > >>> I would like to start a discussion about the subject. I think > >>> this is > >>> something we need to do if one day we want to be able to use any > >>> database other than PostgreSQL. > >> > >> Hello, > >> > >> I think that database layer is a software interface like any other > >> software interface, if done properly, a dba can convert the stored > >> procedure to any other database without any code change. > >> > >> This way the database specific implementation lives within the > >> database and maintained by the designated dba. > >> > >> Fixups and optimizations can be done in database without touching > >> the > >> code. > >> > >> Backward compatibility layer is much simpler to implement based on > >> stored procedures than complex set of views and tables. > >> > >> Also, accessing the database via different technologies is simpler > >> if > >> there is maintained database interface (stored procedures). > >> > >> I've seen hibernate based java applications that promised to be > >> database independent but at the edges when performance counts, the > >> DAO became HQL, then a special dialect and finally database > >> specific > >> SQLS. > > > > there may be db specific optimization/logic, but I don't see why we > > need STPs for 80% (if not more) of the CRUD and basic queries. > > > > I also agree with Tal later in the thread that its a good question > > if > > we can't find a better solution than re-writing the sql's in the > > code > > > > _______________________________________________ > > 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 Thu Mar 28 19:27:20 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 28 Mar 2013 21:27:20 +0200 Subject: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment? In-Reply-To: References: <5152E867.4070108@redhat.com> Message-ID: <51549998.90205@redhat.com> On 03/28/2013 03:14 AM, Chen, Wei D wrote: > Just want to setup 3.2.0 or 3.2.1 ovirt engine running environment. Thanks. if you already have 3.2.0 installed, I suggest running engine-upgrade. if its a clean system, just install 3.2.1. > > Best Regards, > Dave Chen > > -----Original Message----- > From: Itamar Heim [mailto:iheim at redhat.com] > Sent: Wednesday, March 27, 2013 8:39 PM > To: Chen, Wei D > Cc: engine-devel at ovirt.org > Subject: Re: [Engine-devel] Any way to setup ovirt engine 3.2.0 or 3.2.1 running enviroment? > > On 03/26/2013 05:50 AM, Chen, Wei D wrote: >> Hi, >> >> We notice that ovirt-engine's version (rpm package and source code) has updated from 3.2.0 to 3.2.1. As our development process is always based on 3.2.0. Is there any way to re-setup 3.2.0 running environment? > > re-setup as in destroy and re-install, or just upgrade (engine-upgrade should take care of that for you) > >> >> Besides, we also cannot setup 3.2.1 ovrit-engine running environment as its dependent package glusterfs-3.4 cannot be found from ovirt repo or fedora18 repo. How can I fix this issue? Thanks. >> >> Best Regards, >> Dave Chen >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > From gpadgett at redhat.com Thu Mar 28 23:35:23 2013 From: gpadgett at redhat.com (Greg Padgett) Date: Thu, 28 Mar 2013 19:35:23 -0400 Subject: [Engine-devel] Cloud-Init integration Message-ID: <5154D3BB.7080004@redhat.com> Hi Everyone, I'd like to propose a feature we've been doing some investigation into, which is to integrate cloud-init support into oVirt. Cloud-init is used to help provision new Linux systems by setting the hostname, ip, ssh keys, timezone, injecting files, and more. It's used by OpenStack (amongst others) now, and has a lot of features that may be helpful to our users. Details are still evolving, but for more info please see the wiki page: http://www.ovirt.org/Features/Cloud-Init_Integration All feedback is welcome! Thanks, Greg From alonbl at redhat.com Thu Mar 28 23:37:44 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 28 Mar 2013 19:37:44 -0400 (EDT) Subject: [Engine-devel] [ANN] Development environment and Gentoo packaging (preview) In-Reply-To: <962713205.9922993.1364510721308.JavaMail.root@redhat.com> Message-ID: <1822214342.9928213.1364513864623.JavaMail.root@redhat.com> Hello All, We[1] are working to rewrite the current installer to something more portable and flexible. Currently two milestones had been reached: 1. Ability to install almost fully functioning ovirt-engine at $HOME for development environment. 2. Porting ovirt-engine to run on different distribution, Gentoo. We will be glad to receive feedback on either. Code is located at github[2] for now, at otopi branch. Instructions for setting up development environment are available[3]. Gentoo overlay for live ebuilds is available[4], the following packages are valid: - app-emulation/otopi - app-emulation/ovirt-host-deploy - app-emulation/ovirt-jboss-bin - app-emulation/ovirt-engine Why Gentoo first? because source based distributions demands the highest level of customization, solving the complex issue ease to continue porting to binary based distributions. Please remember that this is work in progress, and not guarantee to be stable or even work... The installer was re-written from scratch so expect issues at this point. Any feedback is welcomed, we are focusing first in providing the functionality of the existing installer to be able to replace it entirely before going into new adventures. Regards, Alon Bar-Lev. [1] Alex Lourie, Sandro Bonazzola, Alon Bar-Lev [2] https://github.com/alonbl/ovirt-engine [3] https://github.com/alonbl/ovirt-engine/blob/otopi/README.developer [4] https://github.com/alonbl/ovirt-overlay From wei.d.chen at intel.com Fri Mar 29 02:00:55 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Fri, 29 Mar 2013 02:00:55 +0000 Subject: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review In-Reply-To: <1014066770.26313104.1364481799434.JavaMail.root@redhat.com> References: <60519417.9696375.1364465102897.JavaMail.root@redhat.com> <1014066770.26313104.1364481799434.JavaMail.root@redhat.com> Message-ID: Thanks Doron & Ofri, As to the question of cache flash, we already have our consideration and wrote them on our design page. I have no doubt that your suggestion is more reasonable, we just keep in mind that expiration is much longer that the time needed to poll all of hosts, so this is really a potential issue we ignored. Let's make estimation at first, we will have a try if our schedule is okay. Doron, we have reserved some effort to research about cluster-level policy. As ovirt is complete new to our engineers, would we finished our current features (such as ovf and rest api.) in pipeline at first? After these basic features are ready and we still have some buffer, we will make some improvement. Is this acceptable? Thanks again to Doron and Ofri. Best Regards, Dave Chen -----Original Message----- From: Doron Fediuck [mailto:dfediuck at redhat.com] Sent: Thursday, March 28, 2013 10:43 PM To: Ofri Masad Cc: engine-devel at ovirt.org; Chen, Wei D Subject: Re: [Engine-devel] Open Attestation integration with oVirt engine proposal has submitted patchset5 for your review ----- Original Message ----- > From: "Ofri Masad" > To: "Wei D Chen" > Cc: engine-devel at ovirt.org > Sent: Thursday, March 28, 2013 12:05:02 PM > Subject: Re: [Engine-devel] Open Attestation integration with oVirt > engine proposal has submitted patchset5 for your review > > Hi Dave, > > I would like to raise again the question of the full cache flash for > each stale cache entry found. > This method can cause two unwanted situations: > 1. Choosing untrusted host: lets say, for example that you have 1000 > host in your pool. you look at the first host in the cache and find > that its attestation hat expired. you refresh the entire pool (there > are 1000 host, that must take some time). by the the time the last > host was refreshed in the pool, the first host may already be expired > again. but since you already checked it - you keep on with your flow > and select that host, even so it has expired and may as well be > untrusted. > > 2. infinite loop: lets say we'll try to fix what I've described in > 1. then, we need to check again if the host has expired before we > select it. if it is, the entire refresh process starts again. this > could potentially go on forever (unless I'm missing something, and > the expiration is much longer then the full re-cache process). > > Instead of re-caching the full cache we can do as follows: > - hold the cache entries sorted by expiration (if the expiration > time is the same for all hosts, so a queue is enough). > - each time we need a new trusted host - select from the unexpired > hosts, refresh all expired hosts (in one query). > - if all hosts are expired - we can wait for the first host to be > defined trusted by the attestation server and select that host. > > Ofri > > Dave, adding another suggestion on top of Ofri's; Generally speaking, a cluster of hosts defines many joint features (such as CPU level), which means that in the same cluster we would expect to be able to freely migrate a VM from one host to another. Current trust-pools design is breaking this concept, as you introduce a state where a VM cannot migrate from a 'safe' host into an 'unsafe' host. This leads me to the suggestion of having attestation as a cluster policy rather than a VM-level property. It means that all hosts in this cluster are constantly being monitored to be safe. If a host is declared as unsafe in the Attestation server, it will become non-operational in the engine. This will simplify the implementation since you have everything ready for you once you have a 'safe' cluster and no need to do any VM-level changes. So in this way you keep current concepts while simplifying the implementation with very little worries of performance issues. Can you please share your thoughts on this suggestion? > ----- Original Message ----- > > From: "Wei D Chen" > > To: engine-devel at ovirt.org > > Sent: Friday, March 22, 2013 11:34:55 AM > > Subject: [Engine-devel] Open Attestation integration with oVirt > > engine proposal has submitted patchset5 for your review > > > > Hi all, > > > > Before submitting this patch set, we has updated our design page, > > and new feature about VM template has added to this patchset. In > > patchset a lot of frontend changes has been imported. > > Welcome to review our patchset and thanks advance for your > > suggestion. > > > > > > Detailed description: http://wiki.ovirt.org/Trusted_compute_pools > > > > In this patch set, follow changes has been introduced: > > > > 1. GUI changes to support for creating a trusted VM on a trusted > > physical host. > > 2. View/Edit VM changes to enable end user switch between three run > > on options. > > 3. Template relevant changes to support end user create a trusted VM > > template and create trusted VM based on this template afterwards. > > 4. Bug fixing and code cleanup. > > 5. wiki design page update. > > > > > > > > Best Regards, > > Dave Chen > > > > From lhornyak at redhat.com Fri Mar 29 07:14:39 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Fri, 29 Mar 2013 03:14:39 -0400 (EDT) Subject: [Engine-devel] Cloud-Init integration In-Reply-To: <5154D3BB.7080004@redhat.com> Message-ID: <34408131.16330075.1364541279473.JavaMail.root@redhat.com> Hi Greg, Cool feature :) Some questions: - Maybe the IP (and probably the hostname) should be enforced to be unique on the same network? Or at least warning if duplicates found? - Let's say if the IP is set by cloud-init, then you may also have it in the guest agent info if the guest agent is installed. This may make life a bit more difficult for the developers who build on rest-api. Is there a nice solution for this? - for authorized keys, it would be a pain to copy-paste the public key each time you install a guest. Could a default be stored let's say in the user's data? - the hostname set for the guest could default to the VM name? Thank you, Laszlo ----- Original Message ----- > From: "Greg Padgett" > To: "engine-devel" > Sent: Friday, March 29, 2013 12:35:23 AM > Subject: [Engine-devel] Cloud-Init integration > > Hi Everyone, > > I'd like to propose a feature we've been doing some investigation > into, > which is to integrate cloud-init support into oVirt. > > Cloud-init is used to help provision new Linux systems by setting the > hostname, ip, ssh keys, timezone, injecting files, and more. It's > used by > OpenStack (amongst others) now, and has a lot of features that may be > helpful to our users. > > Details are still evolving, but for more info please see the wiki > page: > > http://www.ovirt.org/Features/Cloud-Init_Integration > > All feedback is welcome! > > Thanks, > Greg > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From jvlcek at redhat.com Fri Mar 29 12:06:25 2013 From: jvlcek at redhat.com (Joseph VLcek) Date: Fri, 29 Mar 2013 08:06:25 -0400 Subject: [Engine-devel] Cloud-Init integration In-Reply-To: <34408131.16330075.1364541279473.JavaMail.root@redhat.com> References: <34408131.16330075.1364541279473.JavaMail.root@redhat.com> Message-ID: <893A2D15-6182-4952-9236-AC2E9462A921@redhat.com> Hey Greg I'm not saying not to use cloud-init I just wanted to point out that one downside to cloud-init it that it is a fairly heavy package with a fair number of dependancies. Just something to keep in mind if requiring it to be built into launching instance. Joe On Mar 29, 2013, at 3:14 AM, Laszlo Hornyak wrote: > Hi Greg, > > Cool feature :) Some questions: > - Maybe the IP (and probably the hostname) should be enforced to be unique on the same network? Or at least warning if duplicates found? > - Let's say if the IP is set by cloud-init, then you may also have it in the guest agent info if the guest agent is installed. This may make life a bit more difficult for the developers who build on rest-api. Is there a nice solution for this? > - for authorized keys, it would be a pain to copy-paste the public key each time you install a guest. Could a default be stored let's say in the user's data? > - the hostname set for the guest could default to the VM name? > > Thank you, > Laszlo > > ----- Original Message ----- >> From: "Greg Padgett" >> To: "engine-devel" >> Sent: Friday, March 29, 2013 12:35:23 AM >> Subject: [Engine-devel] Cloud-Init integration >> >> Hi Everyone, >> >> I'd like to propose a feature we've been doing some investigation >> into, >> which is to integrate cloud-init support into oVirt. >> >> Cloud-init is used to help provision new Linux systems by setting the >> hostname, ip, ssh keys, timezone, injecting files, and more. It's >> used by >> OpenStack (amongst others) now, and has a lot of features that may be >> helpful to our users. >> >> Details are still evolving, but for more info please see the wiki >> page: >> >> http://www.ovirt.org/Features/Cloud-Init_Integration >> >> All feedback is welcome! >> >> Thanks, >> Greg >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From ovedo at redhat.com Fri Mar 29 13:18:13 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Fri, 29 Mar 2013 09:18:13 -0400 (EDT) Subject: [Engine-devel] Cloud-Init integration In-Reply-To: <34408131.16330075.1364541279473.JavaMail.root@redhat.com> Message-ID: <725327293.92916816.1364563093706.JavaMail.root@redhat.com> ----- Laszlo Hornyak wrote: > Hi Greg, > > Cool feature :) Some questions: > - Maybe the IP (and probably the hostname) should be enforced to be unique on the same network? Or at least warning if duplicates found? If we will persist it then we can warn for duplicated, but looks like cloud init is mainly used for one time initialization, so in that case we won't persist it, thus we won't have this information in the engine. > - Let's say if the IP is set by cloud-init, then you may also have it in the guest agent info if the guest agent is installed. This may make life a bit more difficult for the developers who build on rest-api. Is there a nice solution for this? Can you elaborate on that? What would be hard on developers? > - for authorized keys, it would be a pain to copy-paste the public key each time you install a guest. Could a default be stored let's say in the user's data? We might store those in the engine, allowing users to select one they have permissions on. Not sure we would do it in the first phase, though. > - the hostname set for the guest could default to the VM name? > That can indeed be nice. > Thank you, > Laszlo > > ----- Original Message ----- > > From: "Greg Padgett" > > To: "engine-devel" > > Sent: Friday, March 29, 2013 12:35:23 AM > > Subject: [Engine-devel] Cloud-Init integration > > > > Hi Everyone, > > > > I'd like to propose a feature we've been doing some investigation > > into, > > which is to integrate cloud-init support into oVirt. > > > > Cloud-init is used to help provision new Linux systems by setting the > > hostname, ip, ssh keys, timezone, injecting files, and more. It's > > used by > > OpenStack (amongst others) now, and has a lot of features that may be > > helpful to our users. > > > > Details are still evolving, but for more info please see the wiki > > page: > > > > http://www.ovirt.org/Features/Cloud-Init_Integration > > > > All feedback is welcome! > > > > Thanks, > > Greg > > _______________________________________________ > > 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 Fri Mar 29 13:27:51 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 29 Mar 2013 09:27:51 -0400 (EDT) Subject: [Engine-devel] No need to compile for all browsers when debugging oVirt Frontend applications Message-ID: <2113488610.21049007.1364563671317.JavaMail.root@redhat.com> Hi guys, I've just learned that it's not necessary to do GWT compilation for *all browsers* in order to debug given oVirt Frontend application (WebAdmin or UserPortal). Full oVirt build & deploy to Engine is still recommended, but you can use "gwt.userAgent" property to restrict GWT compilation only for a couple of browsers: $ mvn clean install -Pdep,gwt-admin,gwt-user -Dgwt.userAgent=gecko1_8,ie8 The example above means "compile only for Firefox and IE8". I suspect it's because of GWT permutation selector script (*.nocache.js) being optimized-out in case you perform compilation for a single browser, which might interfere with the way how GWT plugin connects to Development Mode. Regards, Vojtech From vszocs at redhat.com Fri Mar 29 14:08:32 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 29 Mar 2013 10:08:32 -0400 (EDT) Subject: [Engine-devel] UI Plugins: addMainTabActionButton API improved In-Reply-To: <1517582075.21054015.1364565868375.JavaMail.root@redhat.com> Message-ID: <1352702484.21054742.1364566112112.JavaMail.root@redhat.com> Hi guys, it's now possible to specify location (representation) of buttons added via addMainTabActionButton API. For example: api.addMainTabActionButton('Host', 'My Button', { location: 'OnlyFromContext', onClick: function() { ... }, ... }); Supported values for button location: * 'OnlyFromContext' - button available only from context menu * 'OnlyFromToolBar' - button available only from toolbar (action panel) * 'ContextAndToolBar' (default) - button available from both context menu and toolbar (action panel) Regards, Vojtech From vszocs at redhat.com Fri Mar 29 14:32:42 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 29 Mar 2013 10:32:42 -0400 (EDT) Subject: [Engine-devel] oVirt web GUI no longer supports Microsoft Internet Explorer 6 and 7 In-Reply-To: <703226391.21056354.1364567027420.JavaMail.root@redhat.com> Message-ID: <2140140430.21057751.1364567562354.JavaMail.root@redhat.com> Hello everyone, please be advised that oVirt web GUI (WebAdmin & UserPortal) no longer supports Microsoft Internet Explorer 6 and 7. It's still possible to use Internet Explorer 8, although it has known performance issues which impact overall application performance. For WebAdmin, it's recommended to use Internet Explorer 9 or above. We decided to drop support for Internet Explorer 6 and 7 mainly because of poor JavaScript & rendering engine performance and poor compliance to HTML5 standards. Regards, Vojtech From iheim at redhat.com Fri Mar 29 17:37:22 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 29 Mar 2013 20:37:22 +0300 Subject: [Engine-devel] Kiril Nesenko as a tools maintainer In-Reply-To: <51472F14.7000805@redhat.com> References: <51472F14.7000805@redhat.com> Message-ID: <5155D152.3090400@redhat.com> On 03/18/2013 05:13 PM, Keith Robertson wrote: > I would like to propose that we add Kiril Nesenko as a maintainer for > the Ovirt ISO Uploader, Image Uploader and Log Collector. He has been > enormously helpful with the maintenance of the tools. > > Thanks, > Keith Robertson > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel Added Kiril. From iheim at redhat.com Fri Mar 29 17:42:29 2013 From: iheim at redhat.com (Itamar Heim) Date: Fri, 29 Mar 2013 20:42:29 +0300 Subject: [Engine-devel] Kiril Nesenko as a tools maintainer In-Reply-To: <5155D152.3090400@redhat.com> References: <51472F14.7000805@redhat.com> <5155D152.3090400@redhat.com> Message-ID: <5155D285.2030904@redhat.com> On 03/29/2013 08:37 PM, Itamar Heim wrote: > On 03/18/2013 05:13 PM, Keith Robertson wrote: >> I would like to propose that we add Kiril Nesenko as a maintainer for >> the Ovirt ISO Uploader, Image Uploader and Log Collector. He has been >> enormously helpful with the maintenance of the tools. >> >> Thanks, >> Keith Robertson >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > Added Kiril. while at it - i suggest that when updating the subprojects page, the image-uploader, iso-uplaoder and log-collector will be split from the engine-tools section (ovirt-engine-config and ovirt-engine-notification) From vszocs at redhat.com Fri Mar 29 22:47:03 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 29 Mar 2013 18:47:03 -0400 (EDT) Subject: [Engine-devel] webadmin: UI plugin dialog API improved In-Reply-To: <1450224943.8028207.1364498078962.JavaMail.root@redhat.com> Message-ID: <600787412.21114712.1364597223517.JavaMail.root@redhat.com> Hi Daniel, these are excellent questions! I'm CC'ing engine-devel to reach out to everyone who might be interested in them. > why dialogToken is mandatory? (wouldn't it be more convenience to make it optional?) dialogToken is used to work with the dialog once it's displayed via showDialog API function. For example, there are no buttons defined for the dialog by default, so you might want to define at least a "Close" button: api.showDialog('My Dialog', 'my-dialog', 'http://www.abc.com/', '800px', '600px', { buttons: [ { label: 'Close', onClick: function() { api.closeDialog('my-dialog'); } } ] }); As you can see, you need dialogToken at least to close the dialog :) another example of a dialog button: { label: 'Load different content', onClick: function() { api.setDialogContentUrl('my-dialog', 'http://www.xyz.com/'); } } (The above are just simple examples, you can put whatever code you like into onClick function.) > what are dialogToken's restrictions (no-spaces?/etc...) Unlike historyToken in custom tab API (addMainTab/addSubTab/etc.), dialogToken doesn't have any restrictions. It's recommended to use "token-string-lowercase-without-spaces" syntax, but it's just a recommendation. As for historyToken in custom tab API, the "token-string-lowercase-without-spaces" syntax is preferred, because historyToken value will be part of WebAdmin URL (e.g. WebAdmin.html#my-main-tab) when navigating to the given custom tab. Regards, Vojtech ----- Original Message ----- From: "Daniel Erez" To: "Vojtech Szocs" Sent: Thursday, March 28, 2013 8:14:38 PM Subject: webadmin: UI plugin dialog API improved Hi Voj, Some qqs about showDialog api: * why dialogToken is mandatory? (wouldn't it be more convenience to make it optional?) * what are dialogToken's restrictions (no-spaces?/etc...) 10x, Daniel From r.koch at ovido.at Sat Mar 30 12:12:53 2013 From: r.koch at ovido.at (=?utf-8?Q?Ren=C3=A9_Koch?=) Date: Sat, 30 Mar 2013 13:12:53 +0100 Subject: [Engine-devel] UI Plugin API improvements In-Reply-To: <678163471.20791553.1364484299073.JavaMail.root@redhat.com> References: <678163471.20791553.1364484299073.JavaMail.root@redhat.com> Message-ID: Hi Vojtech, Thanks a lot for the information. Are these changes already available in latest nightly repository or do I have to fetch them from git? As UI API gets more and more features I was wondering if I can get the UI plugin API version with a JavaScript call like api.getVersion(). I think it could sometimes be useful for UI plugin development to get the version of UI API to be able to use the right API call - at the moment only oVirt 3.2 is available which supports UI plugins, but in future there will be more oVirt version and hopefully RHEV will also support UI plugins (at least as tech preview). What do you think? Thanks, Ren? -----Original message----- > From:Vojtech Szocs > Sent: Thursday 28th March 2013 16:25 > To: engine-devel > Cc: Keith Robertson ; Spenser Shumaker ; Christopher Morrissey ; Ren? Koch > Subject: UI Plugin API improvements > > Hi guys, > > I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new. > > > Modal dialog API > ================ > > Function improved: showDialog > > New signature: > showDialog(title, dialogToken, contentUrl, width, height [, options]) > > Example usage: > showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { > // Default value = empty array (no buttons) > buttons: [ > { > label: 'Do stuff', > onClick: function() { > alert('Bump!'); > } > } > ], > > // Default value = false > resizeEnabled: true, > > // Default value = true > closeIconVisible: true, > > // Default value = true > closeOnEscKey: true > }); > > Notable changes: > * modal dialogs now look & feel the same as standard WebAdmin dialogs > * width & height are strings containing CSS units > * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!) > > -- > > New function: setDialogContentUrl > > New signature: > setDialogContentUrl(dialogToken, contentUrl) > > Example usage: > setDialogContentUrl('my-dialog', 'http://www.example.com/') > > -- > > New function: closeDialog > > New signature: > closeDialog(dialogToken) > > Example usage: > closeDialog('my-dialog') > > > Tab API > ======= > > Functions improved: addMainTab & addSubTab > > New signatures: > addMainTab(label, historyToken, contentUrl [, options]) > addSubTab(entityTypeName, label, historyToken, contentUrl [, options]) > > Example usage: > > // Tab is left-aligned by default > addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/'); > > // Tab is right-aligned via options object > addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { > alignRight: true > }); > > -- > > Regards, > Vojtech > From iheim at redhat.com Sat Mar 30 22:30:49 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 31 Mar 2013 01:30:49 +0300 Subject: [Engine-devel] UI Plugin API improvements In-Reply-To: References: <678163471.20791553.1364484299073.JavaMail.root@redhat.com> Message-ID: <51576799.8070206@redhat.com> On 03/30/2013 03:12 PM, Ren? Koch wrote: > Hi Vojtech, > > Thanks a lot for the information. > Are these changes already available in latest nightly repository or do I have to fetch them from git? > > As UI API gets more and more features I was wondering if I can get the UI plugin API version with a JavaScript call like api.getVersion(). > I think it could sometimes be useful for UI plugin development to get the version of UI API to be able to use the right API call - at the moment only oVirt 3.2 is available which supports UI plugins, but in future there will be more oVirt version and hopefully RHEV will also support UI plugins (at least as tech preview). > What do you think? interesting point. maybe less of an issue if the ui plugin is distributed in rpm form, and can validate minimal version. but if a single codebase for the uiplugin is to support multiple versions for deployment, it may want to make some features available only if engine version is X or >X. so just wondering: - do you see uiplugins distributed as rpms or some other way? - do you see uiplugin codebase trying to accomodate multiple versions, or branch/version similar to supported engine, and one needs latest engine for latest uiplugin, etc. Thanks, Itamar > > > Thanks, > Ren? > > > > -----Original message----- >> From:Vojtech Szocs >> Sent: Thursday 28th March 2013 16:25 >> To: engine-devel >> Cc: Keith Robertson ; Spenser Shumaker ; Christopher Morrissey ; Ren? Koch >> Subject: UI Plugin API improvements >> >> Hi guys, >> >> I've just merged some UI Plugin patches that improve existing API functions, as well as add some new API functions. Please read on to learn what's new. >> >> >> Modal dialog API >> ================ >> >> Function improved: showDialog >> >> New signature: >> showDialog(title, dialogToken, contentUrl, width, height [, options]) >> >> Example usage: >> showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px', '600px', { >> // Default value = empty array (no buttons) >> buttons: [ >> { >> label: 'Do stuff', >> onClick: function() { >> alert('Bump!'); >> } >> } >> ], >> >> // Default value = false >> resizeEnabled: true, >> >> // Default value = true >> closeIconVisible: true, >> >> // Default value = true >> closeOnEscKey: true >> }); >> >> Notable changes: >> * modal dialogs now look & feel the same as standard WebAdmin dialogs >> * width & height are strings containing CSS units >> * the reason why buttons default to empty array is to give plugin authors the choice to provide custom buttons (or similar input elements) via dialog content (iframe), and use HTML5 window.postMessage to call the plugin (coming soon!) >> >> -- >> >> New function: setDialogContentUrl >> >> New signature: >> setDialogContentUrl(dialogToken, contentUrl) >> >> Example usage: >> setDialogContentUrl('my-dialog', 'http://www.example.com/') >> >> -- >> >> New function: closeDialog >> >> New signature: >> closeDialog(dialogToken) >> >> Example usage: >> closeDialog('my-dialog') >> >> >> Tab API >> ======= >> >> Functions improved: addMainTab & addSubTab >> >> New signatures: >> addMainTab(label, historyToken, contentUrl [, options]) >> addSubTab(entityTypeName, label, historyToken, contentUrl [, options]) >> >> Example usage: >> >> // Tab is left-aligned by default >> addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/'); >> >> // Tab is right-aligned via options object >> addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab', 'http://www.bar.com/', { >> alignRight: true >> }); >> >> -- >> >> Regards, >> Vojtech >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alourie at redhat.com Sun Mar 31 09:30:39 2013 From: alourie at redhat.com (Alex Lourie) Date: Sun, 31 Mar 2013 09:33:39 +0003 Subject: [Engine-devel] Generatic Mac Pool Ranges - feedback requested Message-ID: <201303310930.r2V9UdWO025660@int-mx09.intmail.prod.int.phx2.redhat.com> Hi In a current setup flow there are 3 ways of generating mac pool ranges: 1.?Generated from the second and third parts of the first non-local IP: ?{base MAC}:{IP part2}:{IP part3}:00-{base MAC}:{IP part2}:{IP part3}:ff 2. If (1) could not be done for some reason, we have default values in setup. 3. If (2) didn't work for some reason, the values are ?left as created during DB creation. Assuming that we want (1) to work the best way possible, and to create "random" enough values for Mac Pool ranges, I would ask for an opinion for a better way. I am considering creating random int values instead of fetching the IP as it's simpler and safer than parsing 'ip a' output. Thanks. Alex Lourie Software Engineer in Integration Red Hat.