Re: [Engine-devel] oVirt UI technology stack upgrade complete
- Original Message - > From: "Vojtech Szocs" > To: "Allon Mureinik" > Cc: "engine-devel" > Sent: Monday, August 19, 2013 3:46:56 PM > Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete > > > - Original Message - > > From: "Allon Mureinik" > > To: "Vojtech Szocs" > > Cc: "engine-devel" > > Sent: Thursday, August 15, 2013 12:52:55 PM > > Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete > > > > Thanks for the detailed explanation on the field initialization issues, > > Vojtech. > > > > > > Looking at the common and compat packages, there a dozens of such > > initializers. Some are probably redundant anyway and can safely be ignored, > > but some (most?) have a purpose. > > > > My incline is always to prevent such issues from happening, and not rely on > > developers having to remember to move their initializers. > > Here's my take on the issue (patchset available for review at [1]): > > - Move all member initializers to constructors > > - Add a checkstyle check to ensure that new members aren't initialized > > inline > > Nice work, Allon. I agree with your point not to rely solely on developers > (having to remember GWT-specific limitations) but solving this issue > globally in common & compat modules. > > I went over patches at [1] that aren't fully-acked yet, they looked good to > me. Patchset was merged. A bug thank you to all the reviewers! > > > > > Reviews are welcome, thanks! > > > > -Allon > > > > [1] > > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:no-member-init,n,z > > > > - Original Message - > > > From: "Vojtech Szocs" > > > To: "engine-devel" > > > Sent: Wednesday, July 31, 2013 4:17:30 PM > > > Subject: [Engine-devel] oVirt UI technology stack upgrade complete > > > > > > 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 communicatio
Re: [Engine-devel] Dynamic resource loading in GWT
On 08/07/2013 08:10 AM, Tomas Jelinek wrote:
Hey Roy,
well, I'm not a fan of using the dictionary - it is an associative array and
opens a door to
mistakes which will not be handled by compiler like locales.get("naem") will
not return me the name :)
At least not for data we know how will look like (e.g. for the os info)
We already embed some info into the host page and use it on the client using
JavaScript Overlay Types [4].
You can have a look for example at GwtDynamicHostPageServlet:
request.setAttribute(MD5Attributes.ATTR_USER_INFO.getKey(),
getUserInfoObject(loggedInUser));
and on the FE side the overlay type is: AutoLoginData
But I would be careful how much info do we want to embed into the host page -
it can make it significantly big
and influence the performance (for example we are using code splitting [5] to
download only the parts of the app
we actually need when we need them). To embed too much info which is not always
needed is a step to the opposite
direction. I don't say it is wrong, it just has to be considered.
Tomas
[4]:
http://googlewebtoolkit.blogspot.cz/2008/08/getting-to-really-know-gwt-part-2.html
[5]: http://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.html
there is still the point of having multiple files, which seems like an
easy win by merging to a single file, and if needed, using pre-compile
to create the cloned files
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Gluster Volume asynchronous tasks
On 08/12/2013 06:09 AM, Sahina Bose wrote: On 08/12/2013 03:28 PM, Yair Zaslavsky wrote: - Original Message - From: "Sahina Bose" To: "Eli Mesika" Cc: "engine-devel" , a...@ovirt.org Sent: Monday, August 12, 2013 11:51:15 AM Subject: Re: [Engine-devel] Gluster Volume asynchronous tasks On 08/12/2013 01:21 PM, Eli Mesika wrote: - Original Message - From: "Sahina Bose" To: "engine-devel" , a...@ovirt.org, "Michael Pasternak" Sent: Monday, August 12, 2013 8:41:55 AM Subject: [Engine-devel] Gluster Volume asynchronous tasks Hi all, We are working on a feature to add support to start and monitor gluster volume asynchronous tasks (like rebalancing a gluster volume, removing brick from volume ) from the oVirt engine. The operations can be started from the Volumes tab or the Bricks sub-tab using the Rebalance, Remove options. These are long running operations which can be monitored using a task id returned from Gluster. We are planning to add the monitoring in the existing Task sub tab The feature description and User flows are at http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management The detailed design (including REST API design) is at http://www.ovirt.org/Features/Detailed_Gluster_Volume_Asynchronous_Tasks_Management. I would really appreciate if you could review and provide your valuable feedback. I Sahina Why not using 6the External Tasks feature introduced for 3.3 for those Gluster tasks ??? http://www.ovirt.org/Features/Design/DetailedExternalTasks Hi Eli, We still want to be able to start and stop these operations from the engine. So, when a user wants to say, rebalance a volume, they would go select the volume and click on Rebalance Start. This would then call the BLL command to start rebalance which will invoke the corresponding vdsm verb to start the rebalance on the volume. This is the same as existing flow for other commands. The only difference is the vdsm verb will return the task id from gluster, for the rebalance operation that was started. And we will monitor the progress of the task using the gluster task id (by calling a gluster command) I'm not sure how ExternalTasks would fit in here? I was thinking of using ExternalTask support for adding Job/Steps to engine when the operation is started outside of engine, that is, from Gluster CLI. Please correct me if I'm missing something. Does this mean that from Gluster CLI you will not try and invoke the rebalance command ? (I mean, I should either use Gluster CLI or Engine's REST API?) Rebalance volume command could be invoked in any of the following ways: 1. From the console UI (clicking on Rebalance as shown in http://www.ovirt.org/Features/Gluster_Volume_Asynchronous_Tasks_Management#Rebalance_Volume) 2. Using REST API 3. Outside of engine, from Gluster CLI - In such cases, the engine should detect that a user has triggered rebalance operation outside the engine, and allow the user to monitor progress of this from the engine. This is where, we need support to add a Job for an operation that was started externally, so that it can be seen in the Tasks tab. and still, it should be considered an internal task, since the engine is managing it / detected it. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] Jenkins job to run networking functional tests
+1 Giuseppe is our go to guy as far as networking tests go! - Original Message - From: "Sandro Bonazzola" To: "Eyal Edri" Cc: "engine-devel" , "vdsm-devel" , "infra" Sent: Monday, August 19, 2013 2:20:36 PM Subject: Re: [vdsm] Jenkins job to run networking functional tests Il 19/08/2013 11:26, Eyal Edri ha scritto: > [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. +1 from me too. Sandro > > - Original Message - >> From: "Giuseppe Vallarelli" >> To: "infra" >> 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" >> | To: "Giuseppe Vallarelli" >> | Cc: "infra" >> | 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" >> | > To: "infra" >> | > Sent: Friday, August 16, 2013 12:28:43 PM >> | > Subject: Fwd: running network functional tests >> | > >> | > - Forwarded Message - >> | > | From: "Giuseppe Vallarelli" >> | > | To: "infra" >> | > | Cc: "David Caro Estevez" >> | > | 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 >> | > in...@ovirt.org >> | > http://lists.ovirt.org/mailman/listinfo/infra >> | > >> | >> ___ >> Infra mailing list >> in...@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra >> > ___ > vdsm-devel mailing list > vdsm-de...@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ vdsm-devel mailing list vdsm-de...@lists.fedorahosted.org https:/
[Engine-devel] New patches for IBM POWER support
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 alternative architectures 18220 - core: New OS for IBM POWER support 17855 - core: Architecture related queries 18226 - core, engine, webadmin: Cluster and architecture related changes 18227 - core, webadmin, engine: Added architecture support for VM and Template 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, engine: 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 features, in order to enhance the review process. We avoided modifying the change #16700 too much, because the reviewers had already started giving their feedback on it. 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. Regards, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] oVirt UI technology stack upgrade complete
- Original Message - > From: "Allon Mureinik" > To: "Vojtech Szocs" > Cc: "engine-devel" > Sent: Thursday, August 15, 2013 12:52:55 PM > Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete > > Thanks for the detailed explanation on the field initialization issues, > Vojtech. > > > Looking at the common and compat packages, there a dozens of such > initializers. Some are probably redundant anyway and can safely be ignored, > but some (most?) have a purpose. > > My incline is always to prevent such issues from happening, and not rely on > developers having to remember to move their initializers. > Here's my take on the issue (patchset available for review at [1]): > - Move all member initializers to constructors > - Add a checkstyle check to ensure that new members aren't initialized inline Nice work, Allon. I agree with your point not to rely solely on developers (having to remember GWT-specific limitations) but solving this issue globally in common & compat modules. I went over patches at [1] that aren't fully-acked yet, they looked good to me. > > Reviews are welcome, thanks! > > -Allon > > [1] > http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:no-member-init,n,z > > - Original Message - > > From: "Vojtech Szocs" > > To: "engine-devel" > > Sent: Wednesday, July 31, 2013 4:17:30 PM > > Subject: [Engine-devel] oVirt UI technology stack upgrade complete > > > > 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.gwt
Re: [Engine-devel] [vdsm] Jenkins job to run networking functional tests
Il 19/08/2013 11:26, Eyal Edri ha scritto: > [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. +1 from me too. Sandro > > - Original Message - >> From: "Giuseppe Vallarelli" >> To: "infra" >> 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" >> | To: "Giuseppe Vallarelli" >> | Cc: "infra" >> | 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" >> | > To: "infra" >> | > Sent: Friday, August 16, 2013 12:28:43 PM >> | > Subject: Fwd: running network functional tests >> | > >> | > - Forwarded Message - >> | > | From: "Giuseppe Vallarelli" >> | > | To: "infra" >> | > | Cc: "David Caro Estevez" >> | > | 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 >> | > in...@ovirt.org >> | > http://lists.ovirt.org/mailman/listinfo/infra >> | > >> | >> ___ >> Infra mailing list >> in...@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra >> > ___ > vdsm-devel mailing list > vdsm-de...@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Jenkins job to run networking functional tests
[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" > To: "infra" > 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" > | To: "Giuseppe Vallarelli" > | Cc: "infra" > | 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" > | > To: "infra" > | > Sent: Friday, August 16, 2013 12:28:43 PM > | > Subject: Fwd: running network functional tests > | > > | > - Forwarded Message - > | > | From: "Giuseppe Vallarelli" > | > | To: "infra" > | > | Cc: "David Caro Estevez" > | > | 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 > | > in...@ovirt.org > | > http://lists.ovirt.org/mailman/listinfo/infra > | > > | > ___ > Infra mailing list > in...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
