- Devel - oVirt List Archives

[Engine-devel] Issues with IBM POWER support in oVirt engine
by Vitor de Lima 20 Aug '13

20 Aug '13

--_000_B2CAFC4D5E2D574A883EF61ACD5ADE330180A712SERV070corpeldo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, I wrote some code to run a VM on a IBM POWER host, but I stumbled in some i= ssues that will need a little bit of refactoring in the current code and I = would like some feedback. The first issue is that KVM on POWER requires a special SCSI interface (cal= led SPAPR), which is not available in x86-64. Currently I'm solving this pr= oblem by using (in the VmInfoBuilder class): if (vm.getArchitecture().equals(ArchitectureType.ppc64)) { Map<String, Object> struct =3D new HashMap<String, Object>(); struct.put(VdsProperties.Type, VmDeviceType.CONTROLLER.getName(= )); struct.put(VdsProperties.Device, VdsProperties.Scsi); // Create a controller in the index 1, the VirtIO_SCSI interface= is in index 0 struct.put(VdsProperties.Index, "1"); Map<String, String> spaprAddress =3D new HashMap<String, String= >(); spaprAddress.put("type", "spapr-vio"); struct.put(VdsProperties.Address, spaprAddress); devices.add(struct); } But this is a poor solution, because this class would be polluted by archit= ectural differences. Another thing to notice is that since in IBM POWER the= re are two SCSI controllers, all the SCSI devices must have their SCSI addr= ess explicitly defined (it was not needed before, since there was just one = controller before). It was proposed that a "strategy" class could solve the= problem, but I would like to have some feedback on which package it should= be, since it will also be used in the bll package to validate other stuff. The second issue is that the CD-ROM interface is SCSI on POWER guests (and = must be attached to the SPAPR interface) and IDE on the x86_64, this inform= ation could be retrieved from the osinfo (by creating a property there) or = It could be hard-coded in the strategy class. Which would be the best way to handle this difference? The third and final issue is that when the VNC protocol is used in a VM, by= default a Cirrus Logic VGA device is created. This device is not supported= on POWER guests, but the standard VGA device is. I made a workaround, but = the issue is where to put this association between the device type and the = display protocol. Should it also be a property in the osinfo? Or it should be handled in the = strategy class? --_000_B2CAFC4D5E2D574A883EF61ACD5ADE330180A712SERV070corpeldo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"PT-BR" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi everyone,<o:p></o:p><= /p> <o:p> </o:p> I wrote some code to run a VM o= n a IBM POWER host, but I stumbled in some issues that will need a little b= it of refactoring in the current code and I would like some feedback.<o:p><= /o:p> <o:p> </o:p> The first issue is that KVM on = POWER requires a special SCSI interface (called SPAPR), which is not availa= ble in x86-64. Currently I’m solving this problem by using (in the Vm= InfoBuilder class):<o:p></o:p> <o:p> </o:p> if (vm.getArchitecture().equals= (ArchitectureType.ppc64)) {<o:p></o:p>      &= nbsp;     Map<String, Object> struct =3D new= HashMap<String, Object>();<o:p></o:p>      &= nbsp;      struct.put(VdsProperties.Type, VmDevice= Type.CONTROLLER.getName());<o:p></o:p>      &= nbsp;      struct.put(VdsProperties.Device, VdsPro= perties.Scsi);<o:p></o:p> <o:p> </o:p>      &= nbsp;     // Create a controller in the index 1, the Vi= rtIO_SCSI interface is in index 0<o:p></o:p>      &= nbsp;      struct.put(VdsProperties.Index, "1= ");<o:p></o:p> <o:p> </o:p>      &= nbsp;      Map<String, String> spaprAddress = =3D new HashMap<String, String>();<o:p></o:p> <o:p> </o:p>      &= nbsp;      spaprAddress.put("type", &quo= t;spapr-vio");<o:p></o:p> <o:p> </o:p>      &= nbsp;      struct.put(VdsProperties.Address, spapr= Address);<o:p></o:p>      &= nbsp;       devices.add(struct);<o:p></o:p></= span> }<o:p></o:p> <o:p> </o:p> But this is a poor solution, be= cause this class would be polluted by architectural differences. Another th= ing to notice is that since in IBM POWER there are two SCSI controllers, al= l the SCSI devices must have their SCSI address explicitly defined (it was not needed before, since there was just= one controller before). It was proposed that a “strategy” clas= s could solve the problem, but I would like to have some feedback on which = package it should be, since it will also be used in the bll package to validate other stuff.<o:p></o:p> <o:p> </o:p> The second issue is that the CD= -ROM interface is SCSI on POWER guests (and must be attached to the SPAPR i= nterface) and IDE on the x86_64, this information could be retrieved from t= he osinfo (by creating a property there) or It could be hard-coded in the strategy class.<o:p></o:p> Which would be the best way to = handle this difference?<o:p></o:p> <o:p> </o:p> The third and final issue is th= at when the VNC protocol is used in a VM, by default a Cirrus Logic VGA dev= ice is created. This device is not supported on POWER guests, but the stand= ard VGA device is. I made a workaround, but the issue is where to put this association between the device type and= the display protocol.<o:p></o:p> Should it also be a property in= the osinfo? Or it should be handled in the strategy class?<o:p></o:p></spa= n> <o:p> </o:p> </div> </body> </html> --_000_B2CAFC4D5E2D574A883EF61ACD5ADE330180A712SERV070corpeldo_--

2 1

[Engine-devel] Rebuild ovirt 3.2.1 success, but lost i18n support
by An Yang 20 Aug '13

20 Aug '13

Hi all, I just rebuild ovirt-engine 3.2.1 according to http://www.ovirt.org/Building_oVirt_engine , it work fine, but I could not choose the language, it always display U.S. English UI. Could you give me a hand, how can I enable GWT's i18n support, or something is wrong in my building ENV? Thanks in advance. -- Bests, An Yang

2 2

Re: [Engine-devel] Jenkins job to run networking functional tests
by Eyal Edri 20 Aug '13

20 Aug '13

[adding devel lists] Usually to get power user privileges you need get +1 community (mostly relevant people in your team/project). saying you're familiar with jenkins and the project and is cabaple of adding jobs to the project. I personally give +1 since i know you're contribution and experience. Eyal. ----- Original Message ----- > From: "Giuseppe Vallarelli" <gvallare(a)redhat.com> > To: "infra" <infra(a)ovirt.org> > Sent: Monday, August 19, 2013 10:19:46 AM > Subject: Jenkins job to run networking functional tests > > Hello everybody, following the previous discussion with Eyal, > I need to get rights in order to create a jenkins job to > achieve what stated in the subject. > > Is it the right place for such request? > > Cheers, Giuseppe > > ----- Forwarded Message ----- > | From: "Eyal Edri" <eedri(a)redhat.com> > | To: "Giuseppe Vallarelli" <gvallare(a)redhat.com> > | Cc: "infra" <infra(a)ovirt.org> > | Sent: Sunday, August 18, 2013 2:06:22 PM > | Subject: Re: running network functional tests > | > | Hi, > | > | Usually in these cases when a new job is requested to a specific > | project/component, > | A 'power user' for the relevant team (in your case network), is given > | privileges on the Jenkins machine > | to add any job required. > | > | I would propose the following: > | 1. request power user access to jenkins.ovirt.org (if you don't already > | have) > | 2. add a new job with your functional test per commit (not per patch for > | starts) > | any infra member can assist you with the labels for slaves / os /etc... > | 3. once that job is running properly, you can contact infra to assist in > | converting it to a per-patch job > | with the topic / field verification logic done. > | 4. not sure if this is relevant to your tests, but all existing jenkins > | slaves are VMs and not bare-metal. > | > | i hope this helps. > | > | Eyal. > | > | ----- Original Message ----- > | > From: "Giuseppe Vallarelli" <gvallare(a)redhat.com> > | > To: "infra" <infra(a)ovirt.org> > | > Sent: Friday, August 16, 2013 12:28:43 PM > | > Subject: Fwd: running network functional tests > | > > | > ----- Forwarded Message ----- > | > | From: "Giuseppe Vallarelli" <gvallare(a)redhat.com> > | > | To: "infra" <infra(a)ovirt.org> > | > | Cc: "David Caro Estevez" <dcaroest(a)redhat.com> > | > | Sent: Monday, August 12, 2013 10:58:04 AM > | > | Subject: running network functional tests > | > | > | > | Hello everbody! > | > | Just recently we added networking functional tests and we would like > | > | to have them running when we submit patches network related, i.e. > | > | going to affect network modules. Displaying success or failure > | > | as it happens with the current unittests. > | > | > | > | Requirements/ideas: > | > | > | > | - OS Fedora 19/RHEL6.4 should not matter. > | > | > | > | - Kernel module used: bonding, dummy. > | > | > | > | - No more than one 'instance' of networkTests should run > | > | on a specific host, simply because we use some global > | > | constants to identify network name vlan id and so on. > | > | > | > | - Ideally we can use a previously proposed idea of commit tag > | > | where for example @networking is provided in the commit msg > | > | title to identify the need of running also the network > | > | functional tests. > | > | > | > | - We should be able to run at the same time functional networking > | > | tests and unit tests - I don't expect any conflicts. > | > | > | > | Would be cool to have a test run before -1s all networking patches > | > | in case of problems :-) > | > | > | > | Let me know if more information are needed. > | > | > | > | > | > | Cheers, Giuseppe > | > > | > Is there any update on the subject? > | > > | > Any estimate to have functional network tests running? > | > I mind that we can run network functional tests upstream > | > that will speed up our workflow and possibly decrease the > | > regressions. > | > > | > Thanks Giuseppe > | > _______________________________________________ > | > Infra mailing list > | > Infra(a)ovirt.org > | > http://lists.ovirt.org/mailman/listinfo/infra > | > > | > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra >

3 3

[Engine-devel] oVirt UI technology stack upgrade complete
by Vojtech Szocs 20 Aug '13

20 Aug '13

Hello everyone, last week, we merged a patch that upgrades oVirt UI technology stack to use the latest version of Google Web Toolkit SDK and related modules [1]. This patch includes all "essential" upgrade changes as described in [2]. After merging the above mentioned patch, we faced some issues related to GWT RPC serialization, involving classes shared between frontend and backend. Please read on to learn more about these issues and ways to fix them. -- (A) NullPointerException at server-side (GWT RPC servlet) when serializing backend business entity into RPC response payload Symptoms * exception in server.log -> Exception while dispatching incoming RPC call: java.lang.NullPointerException * error dialog in web UI with status code 500 (internal server error) Root cause * fields such as "private X field = Y;" of the given entity are not included in GWT RPC serialization policy * this happens when entity constructor isn't referenced in UI code -> GWT compiler marks the constructor and instance initializer as dead code * since instance initializer takes care of adding such fields to given type (entity) in generated JavaScript, such fields won't be added at all Workaround * for each field such as "private X field = Y;" 1, change field declaration to "private X field;" 2, add "field = Y;" statement to constructor Consequence * even though constructor and instance initializer are marked as dead code, fields such as "private X field;" are still added to given type (entity) in generated JavaScript * this is due to how generated JavaScript works, i.e. fields without initialization statement such as "private X field;" are always added, whereas fields with initialization statement such as "private X field = Y;" are added via instance initializer (which might be removed if it's marked as dead code) References * patch [http://gerrit.ovirt.org/#/c/17352/] for RepoImage entity -- (B) Instance field(s) with null values at server-side after deserializing RPC request payload Symptoms * object passed from client contains field(s) with null values, despite client initializing fields before making RPC call Root cause * client uses RPC method signature that works with type A, i.e. VdcActionParametersBase * type A meets GWT RPC serialization rules, as defined in [3] section "Serializable User-defined Classes" * client uses type B (extends A) when calling given RPC method at runtime, i.e. MyCustomParameters * type B does NOT meet GWT RPC serialization rules, i.e. missing no-arg constructor * back at server-side, GWT RPC servlet fails to deserialize type B properly Workaround * ensure all types participating in GWT RPC communication meet GWT RPC serialization rules 1, assignable to IsSerializable or Serializable interface 2, all non-final & non-transient instance fields meet GWT RPC serialization rules 3, contains no-arg constructor (in order to create instance during deserialization) References * patch [http://gerrit.ovirt.org/#/c/17368/] for Gluster Parameter classes -- Regards, Vojtech [1] http://gerrit.ovirt.org/#/c/16739/ [2] http://www.ovirt.org/Features/GWT_Platform_Upgrade [3] http://www.gwtproject.org/doc/latest/DevGuideServerCommunication.html#DevGu…

2 3

[Engine-devel] Rebuild ovirt 3.2.1 success, but lost i18n support
by An Yang 20 Aug '13

20 Aug '13

--=-idC09TPR8Ct/GVyk0dLv Content-Type: multipart/alternative; boundary="=-umgPw/+YnaaGimIE+IJT" --=-umgPw/+YnaaGimIE+IJT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I just rebuild ovirt-engine 3.2.1 aaccording to http://www.ovirt.org/Building_oVirt_engine , it work fine, but I could not choose the language, it always display U.S. English UI. Could you give me a hand, how can I enable GWT's i18n support, or something is wrong in my building ENV?=20 Thanks in advance. An Yang --=-umgPw/+YnaaGimIE+IJT Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8"> <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/4.2.2"> </HEAD> <BODY> Hi all, I just rebuild ovirt-engine 3.2.1 aaccording to <A HREF=3D"http://www.ovirt= .org/Building_oVirt_engine">http://www.ovirt.org/Building_oVirt_engine</A> = , it work fine, but I could not choose the language, it always display U.S.= English UI. Could you give me a hand, how can I enable GWT's i18n support, or something= is wrong in my building ENV? Thanks in advance. An Yang </BODY> </HTML> --=-umgPw/+YnaaGimIE+IJT-- --=-idC09TPR8Ct/GVyk0dLv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAABAgAGBQJSEs0tAAoJEIzlWTTXdxmtmnYIAKlGCEvwHxNNYGeUSH/zPz6C 2CdDyDTzKtTY/L0+Di1Z1z/hwpxNdna18W/OCr9cFlcBwSXM9e9dC3F2FdvIOxFU SL77W81PSJgsbaoYB7vfjA7mwDFxpzpp7n0mMgDPStoJZ5PSxWuRUl0ow5RGDBpk ev7NAhEdpbNLlOrgIIkeYgBEfUZWyZXqodKUELqJ5rrF6Yy5W1M/sBWu4P42XCNc ndwtkXwSnOEaWzoV4FOqtcf2x8oA69DG4Vor64YV030MsFlD2e902FbVwsEQ7BCq pPpHmuGRmQlVt6hksZA4Pjus3J1LX040WmZAynfnx66jVUe5jS96+rj5wl6GB4I= =4yAp -----END PGP SIGNATURE----- --=-idC09TPR8Ct/GVyk0dLv--

1 0

[Engine-devel] Dynamic resource loading in GWT
by Roy Golan 20 Aug '13

20 Aug '13

Painful issue here - we all know the regular drill of maintaining messages in many places, I18N files and so on. Also there's a patch to make all available timezone an java enum and by that share it for free with the UI. its a way better than a backend Query. But this is all hard-coded, not flexible, hard to maintain, we all know. Why won't we make GWT load a javascript dictionary/dictionaries from a servlet or our host page html[1] using GWT Dictionary[3]? that way the configuration is shared with the engine, it relies on the disk, customers and GSS can change it on-site and so on. | index.html | -> | file servlet | -> |read /etc/ovirt-engine/conf/...| ^ | | GWT loads Dictionary | candidates for dynamic resources * I18N resources AppErrors... * config ( just the UI subset ) * osinfo ? [1] host page html - http://www.gwtproject.org/doc/latest/DevGuideOrganizingProjects.html#DevGui… [2] Dynamic string internationalisation - http://www.gwtproject.org/doc/latest/DevGuideI18n.html#DevGuideDynamicStrin… [3] http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/Diction… Thanks, Roy

6 10

[Engine-devel] New patches for IBM POWER support
by Leonardo Bianconi 19 Aug '13

19 Aug '13

--_000_50EB20226B72D6419356FC320AB62B871917274FSERV070corpeldo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone! This is the dependency tree of the patches (along with their IDs on gerrit)= that will enable IBM POWER support for the oVirt engine (more patches will= be submitted later): 17853 - core: Add POWER 7 to the CPU list 16700 - core, engine, webadmin: Initial support for alterna= tive architectures 18220 - core: New OS for IBM POWER support 17855 - core: Architecture r= elated queries 18226 - core= , engine, webadmin: Cluster and architecture related changes = 18227 - core, webadmin, engine: Added architecture support for VM and T= emplate 17885 - webadmin: Show only = supported displays 17964 - core, webadmin: Show= only supported disk interfaces 17972 - webadmin: Show only = compatible OSes 18221 - core, webadmin: Show= only supported watchdogs 18227 - core, webadmin, engi= ne: Added architecture support for VM and Template 18150 - engine: Display type validation 18042 - engine: Vnic interface validation We divided the previous patchset into smaller patches with specific feature= s, in order to enhance the review process. We avoided modifying the change = #16700 too much, because the reviewers had already started giving their fee= dback on it. Looking at the tree, the other patches are highly dependent on changes #178= 53/#16700/#1822, and the change #16700 is the largest one. If there is some= thing to do to help the review process, please, let us know. Regards, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa --_000_50EB20226B72D6419356FC320AB62B871917274FSERV070corpeldo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"PT-BR" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi everyone!<o:p></o:p><= /p> <o:p> </o:p> This is the dependency tree of = the patches (along with their IDs on gerrit) that will enable IBM POWER sup= port for the oVirt engine (more patches will be submitted later):<o:p></o:p= > <o:p> </o:p> 17853 - core: Add POWER 7 to th= e CPU list<o:p></o:p>      &= nbsp;          16700 - core, e= ngine, webadmin: Initial support for alternative architectures<o:p></o:p></= span>      &= nbsp;           &nbs= p;             = 18220 - core: New OS for IBM POWER support<o:p></o:p>      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    17855 - core: Architecture related queries<o:p></o:p><= /span>      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =        18226 - core, engine, webadmin: C= luster and architecture related changes<o:p></o:p>      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;           18227 - core= , webadmin, engine: Added architecture support for VM and Template<o:p></o:= p>      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    17885 - webadmin: Show only supported displays<o:p></o= :p>      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    17964 - core, webadmin: Show only supported disk inter= faces<o:p></o:p>      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    17972 - webadmin: Show only compatible OSes<o:p></o:p>=      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    18221 - core, webadmin: Show only supported watchdogs<= o:p></o:p>      &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    18227 - core, webadmin, engine: Added architecture sup= port for VM and Template<o:p></o:p> 18150 - engine: Display type va= lidation<o:p></o:p> 18042 - engine: Vnic interface = validation<o:p></o:p> <o:p> </o:p> We divided the previous patchse= t into smaller patches with specific features, in order to enhance the revi= ew process. We avoided modifying the change #16700 too much, because the re= viewers had already started giving their feedback on it.<o:p></o:p> Looking at the tree, the other = patches are highly dependent on changes #17853/#16700/#1822, and the change= #16700 is the largest one. If there is something to do to help the review = process, please, let us know.<o:p></o:p> <o:p> </o:p> Regards,<o:p></o:p> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa<o:p>= </o:p> <o:p> </o:p> </div> </body> </html> --_000_50EB20226B72D6419356FC320AB62B871917274FSERV070corpeldo_--

1 0

[Engine-devel] [oVirt/RHEV 3.3 Localization Question #13] "${ENTITIES_USING_VNIC_PROFILE_COUNTER}"
by Yuko Katabami 15 Aug '13

15 Aug '13

This is a multi-part message in MIME format. --------------000503080408070808020902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I would like to ask for your help again with the following questions: *File:* AppErrors *Resource ID: *ACTION_TYPE_FAILED_VNIC_PROFILE_IN_USE *Strings:***Cannot ${action} ${type}. Several ${entities} (${ENTITIES_USING_VNIC_PROFILE_COUNTER}) are using this VM network interface profile: ${ENTITIES_USING_VNIC_PROFILE} - Please remove it from all ${entities} that are using it and try again. *Question:* Is "${ENTITIES_USING_VNIC_PROFILE_COUNTER}" representing the number of entities using the VNIC profile? Is it always greater than 1 or could it be 1 in some cases? Is ${ENTITIES_USING_VNIC_PROFILE} representing the name(s) of entities using the the VNIC profile? Thank you, Yuko -- Regards, Yuko Katabami (?????) Technical Translator II NAATI Accredited Professional Translator (English into Japanese) #28138 RHCSA #111-119-244 *Mobile:* +61 415 847 352 *Email:* ykatabam(a)redhat.com Red Hat *Red Hat, Asia-Pacific Pty Ltd* Level 1, 193 North Quay Brisbane 4000 *Office:* +61 7 3514 8100 *Fax:* +61 7 3514 8199 *Website:* www.redhat.com <http://www.redhat.com> *Facebook:* Red Hat APAC <http://www.facebook.com/redhatapac> | Red Hat Japan <http://www.facebook.com/redhatjapan> | Red Hat Korea <http://www.facebook.com/redhatkorea> | JBoss APAC <http://www.facebook.com/JBossAPAC> *Twitter:* Red Hat APAC <http://www.twitter.com/red_hat_apac> | Red Hat ANZ <http://www.twitter.com/redhatanz> *LinkedIn:* Red Hat APAC <http://www.linkedin.com/groups?gid=3124596> | JBoss APAC <http://www.linkedin.com/groups?gid=4068303> --------------000503080408070808020902 Content-Type: multipart/related; boundary="------------010200040905090003050701" --------------010200040905090003050701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi all, I would like to ask for your help again with the following questions: File: AppErrors <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> Resource ID: ACTION_TYPE_FAILED_VNIC_PROFILE_IN_USE Strings: Cannot ${action} ${type}. Several ${entities} (${ENTITIES_USING_VNIC_PROFILE_COUNTER}) are using this VM network interface profile: ${ENTITIES_USING_VNIC_PROFILE}  - Please remove it from all ${entities} that are using it and try again. Question: Is "${ENTITIES_USING_VNIC_PROFILE_COUNTER}" representing the number of entities using the VNIC profile? Is it always greater than 1 or could it be 1 in some cases? Is ${ENTITIES_USING_VNIC_PROFILE} representing the name(s) of entities using the the VNIC profile? Thank you, Yuko <div class="moz-signature">-- Regards, Yuko Katabami (方波見裕子) Technical Translator II NAATI Accredited Professional Translator (English into Japanese) #28138 RHCSA #111-119-244 Mobile: +61 415 847 352 Email: <a class="moz-txt-link-abbreviated" href="mailto:ykatabam@redhat.com">ykatabam(a)redhat.com</a> <a target="_blank"><img src="cid:part1.06060308.09030902@redhat.com" alt="Red Hat" border="0" height="42" width="128"></a> Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: <a href="http://www.redhat.com" target="_blank">www.redhat.com</a> Facebook: <a href="http://www.facebook.com/redhatapac" target="_blank">Red Hat APAC</a> | <a href="http://www.facebook.com/redhatjapan" target="_blank">Red Hat Japan</a> | <a href="http://www.facebook.com/redhatkorea" target="_blank">Red Hat Korea</a> | <a href="http://www.facebook.com/JBossAPAC" target="_blank">JBoss APAC</a> Twitter: <a href="http://www.twitter.com/red_hat_apac" target="_blank">Red Hat APAC</a> | <a href="http://www.twitter.com/redhatanz" target="_blank">Red Hat ANZ</a> LinkedIn: <a href="http://www.linkedin.com/groups?gid=3124596" target="_blank">Red Hat APAC</a> | <a href="http://www.linkedin.com/groups?gid=4068303" target="_blank">JBoss APAC</a> </div> </body> </html> --------------010200040905090003050701 Content-Type: image/png; name="redhat-logo.png" Content-Transfer-Encoding: base64 Content-ID: <part1.06060308.09030902(a)redhat.com> Content-Disposition: inline; filename="redhat-logo.png" iVBORw0KGgoAAAANSUhEUgAAAIAAAAApCAYAAAD9LSHtAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAA6NpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tl dCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1l dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUu MC1jMDYxIDY0LjE0MDk0OSwgMjAxMC8xMi8wNy0xMDo1NzowMSAgICAgICAgIj4gPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt bnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxl bWVudHMvMS4xLyIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpDMTM3NDQ3MkZCQzExMUUw OTQzNzk0QTNCNkFFNjg1RCIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpDMTM3NDQ3MUZC QzExMUUwOTQzNzk0QTNCNkFFNjg1RCIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBJbGx1c3Ry YXRvciBDUzMiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0idXVpZDpD QzZBQjQzODY4MDNERDExOENBRDk2OTlCQTZCNjM4OSIgc3RSZWY6ZG9jdW1lbnRJRD0idXVp ZDpDQjZBQjQzODY4MDNERDExOENBRDk2OTlCQTZCNjM4OSIvPiA8ZGM6dGl0bGU+IDxyZGY6 QWx0PiA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPnJlZGhhdF9jbXlrX2xvZ288L3Jk ZjpsaT4gPC9yZGY6QWx0PiA8L2RjOnRpdGxlPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6 UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv93CnUAAA4OSURBVHja7FwL dBTVGf5ms49kySYkgSQkIZCkvKLyCCAIEQRFLdIiqPUN4qsitmhFQKgWKlpRQT1HsEINePBR hfr2+ECUtAoICCggGEKCEEkC5EFeu9nN7vS/s/+SyWR2s4mBgGf/cz4ye+femdn7f/d/3Vkk tE0MhPMJowgXEXoRkgidCDJBItgJxYQCwhbCRsL3BBdCcs5KLGEGYSuhgZUdLDyE3YQ5hITQ VJ5bEk54kFe03A4oJywgRIWm9uyX4YRdzZVo0EBSwffZ11fSfD6FPMKloSnuOJFaOC/M/RKC RT0kMtyM0amJSDYZ4ZJlFLvcOFJrR62rARFGI/pEWTHYYkKiLMFEIwpJ9+9X1GDnkRLWexMR ruFRwuMhdZxdBHiS/XVTX0BKX9o3HVdUS6RK73AXHdUpQYEMM7W5jMCOCBnbPA04aHeid4QF 1zUY8ZzswEd5h/VIIORFwr0hlZxZCfPT/hRhtl7wPy4jBTPtJtTTpypSpIPgIqVLyllJUa2b rEKCE4iwGLD6cDE2HS1D/+RY/NFhwnqzjPJah949hxISCR+F1NKxBLiPsMjfgBtTuiLFKWGX TUZvpwERpPRwholQr1zUS4gCCh37xNpwd3wchpHFsJFLkOMikFta7u/yQ9gqbQyppmNcwEjC hqY+v1GMYQa83bsXdhg9WLD7IKZk9kQ8tZW4Pagh9LUYMbHaADMp2kO2QJDDopBCWArvzTwG YKqjAj8cPe7PFQi5mvBeSD1n1gJYCW8RuvvjSjqt5NskK+JIk9tNEjYUknk/Vo4Kj4yqBjec hjAMMxgR4ZGUyE4UCoSLaOArCHXHyAaUdzZhy7HKQAQQ7uB1Ql1IRWeOADMJUwMZi4GJcbhG NiO6QUJWdARORFsxJzkB96MTbjFaMV4mJ+CmGMC/YhViJJDV+KTejjpnQ6CCk5DPz8E5FYmP qIpWn0sEiCesaizMeEO6xmMv0mKjcLXHhJOk4FiXhIlEhuR6KNmAk/4Vpl5u4YZuMTtuA76L MiG/vDqQFcgkrCVUnGME6AxvpfR6tqYi4Ck9Wx/WyH9vJiT7FJ4SG40R8Z3Rx2xEJBFBdDrs cSMnvwiv9UrFzdVhICOAWor23S2qXF9GUGr4SeCxMYQ7CfPOMQIIIxdJGMboy2TwfSdBkMKz iQASE0A5HJmWhEWmSKQ6yI9z5GYiRa+PNqHa4cKjuw/gm949MMliwQU1EmJlr6UQxtyO4Ahh p+tlUQbR2WpBZV19ICtwHWckv5ZYIIvwCQfbW8+GBxLaG8RQFHFnVCS6U5pXTkSuFJDFXyDN 7kFql2hlyEd5R3Dn7jzcai/DgxYHVtoa8LXNAzvRqbNkUOoBgUSQJc4FdLVFonHzUHfMb3iy fi0i86LrdIbuJyzQGkLXQBZgVKPDl5SlJktNF6Wo9CXTil3YLV7ZwfnpxEmlb15JGaEc77Pl S+sai98nxGBajdewePysbHH2CCWa1nojVp/fGwcMHnxaWYvth0u8T0H3l+VTY8cQ1v/Kgm/5 DN3ncnY/DwayAMPUDWur6xQnFqZZkTXUOpxitpy4eEzN7IH46E68an07veTYjlfg+T0F2ESh ZKQkBfQ7XxrcuCrGhotrDJhWZcQqQxTm989QSs1y0+m5sB0mQqS4afC/+yjOpxJ68mqRgryu qJekEHqw32+LhPO9U/k4GKstKqbpHLcZgyCbJ9DF0tV9NxYUYYnVhWiaA2MzEsjoQi77r3UW vJqYhAcuSMOg7olKgUidNXxWX6/sB/oTcZ1xDQbcUG1QXE0FQbwlckdVGOb166ntnt6KyRV7 CdsI3xAe4Lbp8L6HUKBq80kGvHsQewg/Eg7wX2FxrmghQP07vLukeYy9hGeYQA1BBIpC/kbI JxwShpWP/+JHqV24/w8cRO4XhpQ/36jp+yq8L99M57RUFPe28/Nuhup9DGNj9N9IghV7C+DM TMNDdSalvGtXWSyR7gkk1EuYUW/C1LAo7O1rw9eSG7tr61F4sgYbj5RgfUYqLqmWUKtj7QSt kh3eCmFjeigTESRcU2XAe0Sqbxt3DsWE2hTetCyCPUP4+HtW+FLNilVXG1dxVK5V7qUMsRn2 lOa8WO0fEC7QtKeyqf1tECtZBFMb+Xn/QdjJtY874N197U+4TTPmeq7VLCPkEo6z9ZnJRTNh 3V7ivpsIBwmjOcXfwHUJk6JCwKHWRTl/6WbGYUx6MuaarcggZVX5ifANyj4AlJKvIMYJolSx xVsniHXCbxzgN4mmIPJ+k10JNHmhCOMwgLAviOGP8MoEr+TOaPr20WLCXHjfcfiCEMHt27gK Km54Lbyvuan96HqVq8hVkQw8sYJsZn5Os+aZ3lKlgWP4vj/xiryJFaKWhfBuj4sMaJ2qPZLr Nid1vve7HMuJV/PKNPMxn4lywp8L8Gulviz4GdNKS/CKza1QJ0onwvcoW8GyYsbFS4CUECCz VkJcG5Qvri1SxGK7s61xknqbsQ8rP4/N6q1cWBLyuEr5Yvcxm833Up5IdQVSHUBN1yhfuJrB PP5CdhulQQR/NVx1der0WcKr+/ZmnlNf+eDnFot4hG4JN0BMY2jJVR2tqMJju/NxU20pPjQ6 leAuCvqpnkep+3u3iNtSIIqia28nQ7azqLitBNA+1H5W6LPsF78lXEwYqyLMHI0iGjRuYwSv ICFTVO1VbKYPqNo2sklu6flyCLV++lTxdbKCCPB8soeLrP3aUgiq03cBjaQddXE2si+5DG99 9jHWFhXgptgYjCL/Hk00qOMS8C8VUXGsCJPxAhFObpqHikpRZRsvu1RnRY5WHRezP75ItRic 7Dpc7DNt7Ks9mgn+mAmmlS/4eTsHeK69LTy38N+/42cr85N99OIgNpH1Fwb/73cEJMDPzQNB VVTVowfeeP0NJKWk4JH5czF6zFj8efMm9I2LxlWJXTDOHYY0B1kEyVvhc6F1pl/EDp0IB8Jl LHBUY0fz18aOo20bK+IiO3Ta1UoUqeHXQVwrjoloUrV966evK0DaJem4Kj2pZmVqLXQSW6zr mRzCiqj3StxtIUBBoFzbaDQiIsIb1IZbLHjh2SW4d8YMJCalYMkHH+Jf4WEYmtIN2VYLhjgl pDi8LkJxCZL37SC3qt4nvpWJTL14RVQUmA5RwPi+qQHvFB1HSaXu5lBBkBmAXsFRz8ya23At u0b5CGDC2+Kq9M5rJ0JkJf9hcjxB+JQtWBUTtLQVLqMJAUQgc0OzWTKb4XQ6kX/wIOY9/DBe XLFSaR86bDg2bd4Mk8mMh2fPxpNPP43P848oUVNMpwhlx7CnNRxpZiOSKWiMoa8RTuvBSiwQ pWKKD2lJe1DocWM/BXt7jlagrNqOxheFm8kvqZnrxTj1qmORT/+JeSkFuMb/ONhTS7czWDlM 4gB2F6eZ9vasLGZZwsPdVqtVjo6Ols/L7CfPuOceeduWb+TVL+fIUVFRimZWrVwp68mcWbNk rh5rXgH3QrTTDMpG7iOd6mMI9Lq4GuNa8V1mq8YJX56p02e+qs8JntxgpAevet9Yf64ji02x r9+bqnNjue2SFu41n4nqq+HP5HFD/PSPZYs3Tyctrg+4F7Ds+ed39h84YKfZZB4cabMhPSMD 4RHeDGnIsAtRXV2F+2fNwrS77kJMbCwmTp7c5ALCAmRnZyMnJwclx0oR2SkSyUlJGDRoIOrs DuTm5mLAgAHontoDX36xATZbJBK6xmPxkiXBTHp+kD66NSKM1WO84uPYnN4WxDhf7j5KlR3c zhG9Wh5qObtqtfTiVX/Iz/kEtmLa2MPN7f5dg9h0ITwgB5BtW7bIr69ZIxcfPSq3h9w3fXqw vyB6opUTFYwFAPtS9X1yuZzan+sHw7lusKJpqVwp3KjHOTjFFGZ5MmcG2u/w73awAIt5nL80 bzmfn6tpv4Pb+7ZEgHhCkdxOcqiwUP7808+U4x/37ZP3/bC3yfmLR44MRvllHKWL6tkfdIKw X0KAJK7eae/ZwOPUbddpxr7ZwnOXsqXwfX63HQiQzeNe0fQTcyJ+v3GM3dMzmvNDedx8Tbuw CpMIV/lMlbjAc+1lr15esQLjrrwCg7MGYfI1k/Hdzp2NERgFlpWVQaX1/+TNjgmEiVxrDyao DSbSPsqxxWto+mvlMB2iaf2nMPur/VxXkPYW3is4Vd9qYxagruB9xSXuKVzizuES8xG2Spdz yqt9oddX4l7E+wHvsrUQtYPxhCsl1b67qHP/VyfabbWcrKjA3r17sHz5cmSkZ2DhosafGZAr wc1TvAU1CjwxsH9/9OndW4kbjCYjTp6swv4f9x8sKCwclncgv4yebxwXYz5Ayz8tH8JFHRf7 v3Vo+Z1CYSUuYzMZzRaghPcetnKlTy+/HsFmP4nP72BzX8yB4EhefcJvf8hjknkT6h0mIQIE kkIPazQ1gzFMgniOCTYwiat4oUB1L7Ve72brY+B9jWXstlw+F+DDSIJDPk0iYojMfv1OZQMi FtCTn4uKJr69bh2yBg5ESE6zaAggcN/pIsCE8eMVxQ8dMlh+ZvFif0HlAt+zXDtpUkhBHUAA gafaW/kvLV+mKH/ihAmyy+Xy1+1F9XOECNBxBBB4sr2Uv23rVjmpWzf5srFj5Mrycn/dlmuf IUSAjiWAwIz2iAm+ys2V31671t/KdxPm690/RICOJ4DAcMKu0xQW5BEu9XfvEAFOvwRTstzC lbFZnB61h4jUbAGnbRtCaji7CQDORUXx/jx4//+AbWj93rPIifdwuVKUNBdy/hqSDpTW7h+X cxFBvErd0v8TWMdl0YMI/T+BZ638X4ABALiJt5GyzHDtAAAAAElFTkSuQmCC --------------010200040905090003050701-- --------------000503080408070808020902--

2 7

[Engine-devel] Failed to execute stage 'Misc configuration'
by Michael Pasternak 13 Aug '13

13 Aug '13

Any insight? [ ERROR ] Failed to execute stage 'Misc configuration': Command '/home/mpastern/Coding/ovirt/ovirt-engine/share/ovirt-engine/dbscripts/upgrade.sh' failed to execute [WARNING] Rolling back upgrade * rebased at 20031dd61f6c6517a5e21d38485c3c3b626fd8aa -- Michael Pasternak RedHat, ENG-Virtualization R&D

3 3

[Engine-devel] Deprecating signatures/parameters in restapi (RSDL)
by Michael Pasternak 12 Aug '13

12 Aug '13

Hi All, We have added the ability to deprecate signatures/parameters in RSDL, you can mark parameter as deprecated in rsdl_metadata.yaml file this way [1], please make sure you deprecating signatures/parameters which planned to be non-maintained/removed. thanks. [1] signature parameter: =================== vm.display.type--DEPRECATED: xs:string url parameter: ============= max: {context: matrix, type: 'xs:int', value: 'max results', required: false, deprecated: true} header parameter: ================= Filter: {value: true|false, required: false, deprecated: true} entire signature: ================ - mandatoryArguments: {} optionalArguments: {action.vm.os.initRd: 'xs:string', action.vm.domain.name: 'xs:string', action.vm.placement_policy.host.id|name: 'xs:string', action.vm.placement_policy.affinity: 'xs:string', action.async: 'xs:boolean', action.vm.os.kernel: 'xs:string', action.grace_period.expiry: 'xs:long', action.vm.display.type: 'xs:string', action.vm.stateless: 'xs:boolean', action.vm.os.cmdline: 'xs:string', action.vm.domain.user.username: 'xs:string', action.pause: 'xs:boolean', action.vm.os.boot--COLLECTION: {boot.dev: 'xs:string'}, action.vm.domain.user.password: 'xs:string'} deprecated: true -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0