From wei.d.chen at intel.com Mon Jul 1 05:14:15 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Mon, 1 Jul 2013 05:14:15 +0000 Subject: [Engine-devel] Build step 'Publish FindBugs analysis results' changed build result to UNSTABLE Message-ID: Is there anyone know the reason for these error message? what can I do to fix it? [INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ engine-server-ear --- [INFO] Installing /jenkins-workspaces/ovirt_engine_find_bugs_gerrit/ovirt-engine/ear/target/engine.ear to /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear [INFO] Installing /jenkins-workspaces/ovirt_engine_find_bugs_gerrit/ovirt-engine/ear/pom.xml to /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom [INFO] [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @ engine-server-ear --- [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] ovirt-root ........................................ SUCCESS [4.719s] [INFO] oVirt Build Tools root ............................ SUCCESS [0.129s] [INFO] oVirt checkstyle .................................. SUCCESS [2.001s] [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS [39.769s] [INFO] oVirt Checkstyle Checks ........................... SUCCESS [27.944s] [INFO] oVirt Modules - backend ........................... SUCCESS [0.054s] [INFO] oVirt Manager ..................................... SUCCESS [0.052s] [INFO] oVirt DB Scripts .................................. SUCCESS [0.210s] [INFO] oVirt Engine dependencies ......................... SUCCESS [2.262s] [INFO] oVirt Modules - manager ........................... SUCCESS [1.150s] [INFO] CSharp Compatibility .............................. SUCCESS [36.770s] [INFO] Common Code ....................................... SUCCESS [1:43.000s] [INFO] Common utilities .................................. SUCCESS [1:15.054s] [INFO] Data Access Layer ................................. SUCCESS [1:45.658s] [INFO] engine scheduler bean ............................. SUCCESS [33.039s] [INFO] Vds broker ........................................ SUCCESS [1:41.045s] [INFO] Search Backend .................................... SUCCESS [48.983s] [INFO] Backend Logic @Service bean ....................... SUCCESS [3:15.813s] [INFO] oVirt RESTful API Backend Integration ............. SUCCESS [0.242s] [INFO] oVirt RESTful API interface ....................... SUCCESS [0.334s] [INFO] oVirt Engine API Definition ....................... SUCCESS [1:04.592s] [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS [0.195s] [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS [46.398s] [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS [1:06.535s] [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SUCCESS [1:45.332s] [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS [1.559s] [INFO] oVirt Engine Web Root ............................. SUCCESS [38.216s] [INFO] oVirt Engine Tools ................................ SUCCESS [54.388s] [INFO] oVirt Modules :: Frontend ......................... SUCCESS [0.034s] [INFO] oVirt Modules :: Webadmin ......................... SUCCESS [0.042s] [INFO] oVirt Modules - ui ................................ SUCCESS [0.225s] [INFO] Extensions for GWT ................................ SUCCESS [27.754s] [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS [32.946s] [INFO] Frontend for GWT UI Projects ...................... SUCCESS [42.351s] [INFO] UICommonWeb ....................................... SUCCESS [2:52.851s] [INFO] oVirt GWT UI common infrastructure ................ SUCCESS [2:30.819s] [INFO] WebAdmin .......................................... SUCCESS [3:36.038s] [INFO] UserPortal ........................................ SUCCESS [1:31.579s] [INFO] oVirt Server EAR .................................. SUCCESS [6.661s] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 31:41.803s [INFO] Finished at: Fri Jun 28 12:14:28 EDT 2013 [INFO] Final Memory: 182M/806M [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_gerrit [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/auth/target/findbugsXml.xml of module with 2 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/bll/target/findbugsXml.xml of module with 177 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/common/target/findbugsXml.xml of module with 214 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/compat/target/findbugsXml.xml of module with 15 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/dal/target/findbugsXml.xml of module with 4 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml of module with 8 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml of module with 0 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml of module with 12 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/types/target/findbugsXml.xml of module with 7 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/root/target/findbugsXml.xml of module with 0 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/scheduler/target/findbugsXml.xml of module with 0 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/searchbackend/target/findbugsXml.xml of module with 9 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/utils/target/findbugsXml.xml of module with 45 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/vdsbroker/target/findbugsXml.xml of module with 207 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/tools/target/findbugsXml.xml of module with 14 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/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_gerrit/ovirt-engine/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_gerrit/ovirt-engine/frontend/webadmin/modules/frontend/target/findbugsXml.xml of module with 31 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml of module with 58 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml of module with 0 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/uicompat/target/findbugsXml.xml of module with 43 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/userportal-gwtp/target/findbugsXml.xml of module with 7 warnings. [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/webadmin/target/findbugsXml.xml of module with 69 warnings. [FINDBUGS] Computing warning deltas based on reference build #2628 Build step 'Publish FindBugs analysis results' changed build result to UNSTABLE Finished: UNSTABLE Best Regards, Dave Chen From tjelinek at redhat.com Mon Jul 1 05:29:20 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Mon, 1 Jul 2013 01:29:20 -0400 (EDT) Subject: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST In-Reply-To: <1643373626.9902858.1372435276836.JavaMail.root@redhat.com> References: <501973842.20255318.1371648804880.JavaMail.root@redhat.com> <20130624094735.GC1849@teriyaki.cdg.redhat.com> <1210717020.2488959.1372324871664.JavaMail.root@redhat.com> <20130627093010.GC13576@teriyaki.redhat.com> <2114201154.2496221.1372326631963.JavaMail.root@redhat.com> <2874260.9314218.1372348873189.JavaMail.root@redhat.com> <856039866.2941458.1372398071424.JavaMail.root@redhat.com> <1643373626.9902858.1372435276836.JavaMail.root@redhat.com> Message-ID: <1119844308.3674080.1372656560744.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Tomas Jelinek" , "Vojtech Szocs" > Cc: "engine-devel" > Sent: Friday, June 28, 2013 6:01:16 PM > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST > > Hi Tomas, > > > IIUC the RFE addresses only UIPlugins with their metadata so > > in order to integrate this with the SPICE we nee to either > > enrich the RFE or to create a UIPlugin which will start the > > SPICE. I would vote for the second option. What others? > > using a ui-plugin that will start SPICE is an interesting approach - it > haven't crossed my mind. What I had in mind is to somewhat "generalize" the > RestApiSessionManager to provide REST-API-session-creation services to the > entire GUI (e.g. SPICE-console-opening-code), and not only to the ui-plugins > in particular. > I think that since SPICE is already quite integrated into oVirt (in our > business > logic, dialogs, ...), it would be somewhat weird to use a UI-Plugin in order > to > invoke SPICE, just in order to get the REST-API-session-creation capability. > > So I am actually in favor of enriching the RFE (i.e. "generalize" the > RestApiSessionManager), rather than treating SPICE as a UI-Plugin (in a > sense). yes, you are right. > > > Why only for SPICE? I can imagine UIPlugins which could make use of this > > option. > > the main difference between SPICE and the UIPlugins is that we know in > advance > how SPICE is going to use REST API. This is not true anymore - SPICE can add whatever it wants to it's menu and webadmin/userportal has no control about it anymore (I'm talking about the non-plugin invocation of the SPICE). > In addition, SPICE is going to do actions > (e.g. > Stop/Pause/Attach CD) on the VM only when the user chooses to do so (via the > SPICE menu), so actions will be done on behalf of the logged-in user, so it > makes > sense to provide to SPICE the same credentials as the logged-in user. > > a ui-plugin is a third-party component which we don't know in advance how it > is > going to act; moreover, the user that is logging into the web-admin doesn't > have > control on it. Imagine a ui-plugin that shuts-down/deletes all VMs > immediately > upon login to the web-admin - all VMs will be shutdown/deleted upon the first > login into the web-admin (after the ui-plugin installation on the engine > server). > If the same-credentials-approach will be used, the shutdown/deletion of all > VMs > will be done on behalf of the user that happened to be the first one logging > into > the web-admin (post ui-plugin installation), which, obviously, is not good. Well, I did not mean to give this permission to all the plugins - all I wanted to say is to make this configurable per plugin. I can imagine also a well-known UI plugin which is trusted by the admin and it does make sense to make it use the same rights as the logged in user. I did not mean that each plugin has to have this permissions. > > So to sum-up: I think that > > - the RestApiSessionManager should be "generalized" to provide > REST-API-session- > creation services to the entire GUI (e.g. SPICE-console-opening-code), and > not only > to the ui-plugins in particular. completely agree > > - RestApiSessionManager should support creation of both > same-credentials-session as > well as other-credentials-session; the same-credentials-session should be > limited to > well-known/well-integrated components (e.g. SPICE), whereas the > other-credentials-session > can be used by third-party components as well (e.g. ui-plugins). Who should decide about what is the well-known component? I would let the administrator to configure this. We can provide the defaults (e.g. the same-credentials-session will be disabled by default for ui-plugins but it will be possible to enabled it explicitly for some ui-plugins). > > [I could be wrong - would love to hear what the others GUI maintainers think] > > > > ----- Original Message ----- > > From: "Tomas Jelinek" > > Sent: Friday, June 28, 2013 1:41:11 AM > > > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Tomas Jelinek" , "Vojtech Szocs" > > > > > > Cc: "engine-devel" , "Michael Pasternak" > > > > > > Sent: Thursday, June 27, 2013 6:01:13 PM > > > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST > > > > > > Hi Tomas, > > > > > > > Yes, we can provide the sessionId to authenticate with the REST and the > > > > vm > > > > guid is not a problem. > > > > > > Note that in the web-admin, we already have code that generates REST API > > > session-ID; > > > this code is being utilized in the ui-plugins infrastructure to allow the > > > different > > > ui-plugins to communicate with the rest api. > > > [one related file is this context is RestApiSessionManager.java in the > > > web-admin, not > > > sure if there are others] > > > > Yes, I'm aware of that. This is what I had in mind when was talking about > > passing the SessionId to SPICE. > > > > > > > > maybe the RestApiSessionManager(?) can somehow be utilized for the SPICE > > > purpose as well > > > (I guess that it will require a couple of code-changes though, and maybe > > > worth moving it > > > to gwt-common, to allow its utilization from the user portal as well?) - > > > @Vojtech would > > > probably know best to advise on this. > > > > > > * Note: Today: > > > (a) a *single* REST API session-ID is generated and used across all > > > ui-plugins in the system > > > (upon user login to the web-admin). > > > > > > (b) this REST-API session-ID is generated based on the *same credentials* > > > with which the user > > > logged into the web-admin. > > > > > > both (a) and (b) will change once [1] will be addressed. > > > > Thank you for mentioning this! I was not aware of this RFE. IIUC the RFE > > addresses only > > UIPlugins with their metadata so in order to integrate this with the SPICE > > we > > nee to either > > enrich the RFE or to create a UIPlugin which will start the SPICE. I would > > vote for the second option. > > What others? > > > > > Only for the SPICE case in particular - I think that (b) should remain. > > > so > > > > Why only for SPICE? I can imagine UIPlugins which could make use of this > > option. > > > > > maybe worth allowing > > > both same-credentials-login and different-credentials-login in the > > > REST-API-Session-ID-generation > > > code in the GUI. > > > > This option might make sense also for other UIPlugins so maybe the SPICE > > integration will not be anything special, just a UIPlugin. > > > > > > > > ---- > > > Thanks, > > > Einav > > > > > > [1] Bug 962863 - RFE: Improve REST API integration for UI Plugins > > > https://bugzilla.redhat.com/show_bug.cgi?id=962863 > > > some of the planned changes (from the BZ description): > > > """ > > > ... > > > - each UI plugin will have its own dedicated REST API session, unrelated > > > to > > > GUI (admin) > > > user credentials > > > ... > > > """ > > > > > > > ----- Original Message ----- > > > > From: "Tomas Jelinek" > > > > Sent: Thursday, June 27, 2013 5:50:31 AM > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Christophe Fergeau" > > > > > To: "Tomas Jelinek" > > > > > Cc: "Michal Skrivanek" , "Itamar Heim" > > > > > , > > > > > spice-devel at lists.freedesktop.org, "engine-devel" > > > > > , > > > > > "Marc-Andr? Lureau" > > > > > Sent: Thursday, June 27, 2013 11:30:10 AM > > > > > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using > > > > > REST > > > > > > > > > > Hey, > > > > > > > > > > On Thu, Jun 27, 2013 at 05:21:11AM -0400, Tomas Jelinek wrote: > > > > > > well, it seems that everyone agree that the decision what to add to > > > > > > the > > > > > > menu is the client responsibility. It means there is no additional > > > > > > work > > > > > > needed on the > > > > > > oVirt engine side - going to remove the feature page. > > > > > > > > > > If we go the REST API way to handle foreign menu, we need additional > > > > > info > > > > > in the .vv files: some way to auth with the REST API, and the guid of > > > > > the > > > > > VM to act on. > > > > Yes, we can provide the sessionId to authenticate with the REST and the > > > > vm > > > > guid is not a problem. > > > > > > > > > > > > > > Christophe > > > > > > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > From lpeer at redhat.com Mon Jul 1 05:39:30 2013 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 01 Jul 2013 08:39:30 +0300 Subject: [Engine-devel] VNIC profiles In-Reply-To: <1774330631.5017188.1372627142805.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <1774330631.5017188.1372627142805.JavaMail.root@redhat.com> Message-ID: <51D11612.1030909@redhat.com> On 07/01/2013 12:19 AM, Eli Mesika wrote: > > > ----- Original Message ----- >> From: "Livnat Peer" >> To: "engine-devel" , "Ofri Masad" >> Sent: Sunday, June 30, 2013 3:59:37 PM >> Subject: [Engine-devel] VNIC profiles >> >> Hi, >> >> We are working on adding VNIC profiles as part of the work to add VNIC QoS. >> >> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles >> >> We need to define some of the system behavior followed by this change, >> here is my take - >> >> Editing a profile - >> -------------------- >> A user should be able to edit the profile properties (including profile >> name) while VMs are attached and are using this Profile (reference >> should be done by id). >> >> Changing the network though is a bit more tricky as long as we don't >> have a way to distinguish between running and current configurations I >> think it could be very confusing to the user. Especially since we >> support dynamic wiring so the behavior IMO is unpredictable. >> I think it should be blocked at this point. >> >> >> Edit a VNIC / change a VNIC profile - >> ------------------------------------ >> Changing the profile a VM is using while the VM is running should behave >> like dynamic wiring (changing the VM network while it is running). >> >> >> Remove a Profile - >> ------------------- >> Is only valid if all VMs that are using this profile are in status down. > > What about HA VMs , are they forced to be down as well for this operation? > If you want to remove the profile you can remove it from the HA VM (hot unplug NIC for example) and then delete the profile. You can do that when the VM is up and running. >> It should update all VMs to point to no profile which should behave like >> none network today. >> >> I see no reason to support a profile on a none network at this point. >> >> The above is also relevant for upgrade flow (upgrading none network to >> point to no profile) >> >> >> Removing a Network - >> ---------------------- >> should remove all profiles on that network >> >> >> VM snapshot/import/export - >> -------------------------- >> We should handle VMs that are pointing to a network directly for b/w >> compatibility. >> we need to select first profile that is on that network that the user >> has permissions on. >> >> >> I assume there are more, comments are welcome >> >> Thanks, Livnat >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From lpeer at redhat.com Mon Jul 1 06:04:16 2013 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 01 Jul 2013 09:04:16 +0300 Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <2036896830.10266657.1372610122917.JavaMail.root@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <1695008076.4096833.1372337319955.JavaMail.root@redhat.com> <12227690.29409642.1372344197624.JavaMail.root@redhat.com> <1625820710.4175423.1372344929287.JavaMail.root@redhat.com> <687362379.9364944.1372354295556.JavaMail.root@redhat.com> <2036896830.10266657.1372610122917.JavaMail.root@redhat.com> Message-ID: <51D11BE0.6000809@redhat.com> On 06/30/2013 07:35 PM, Barak Azulay wrote: > > > ----- Original Message ----- >> From: "Barak Azulay" >> To: "Martin Perina" >> Cc: "Yair Zaslavsky" , engine-devel at ovirt.org, "Eli Mesika" >> Sent: Thursday, June 27, 2013 8:31:35 PM >> Subject: Re: SSH Soft Fencing >> >> >> >> ----- Original Message ----- >>> From: "Eli Mesika" >>> To: "Yair Zaslavsky" >>> Cc: "Martin Perina" , engine-devel at ovirt.org, "Barak >>> Azulay" >>> Sent: Thursday, June 27, 2013 5:55:29 PM >>> Subject: Re: SSH Soft Fencing >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Yair Zaslavsky" >>>> To: "Eli Mesika" >>>> Cc: "Martin Perina" , engine-devel at ovirt.org, "Barak >>>> Azulay" >>>> Sent: Thursday, June 27, 2013 5:43:17 PM >>>> Subject: Re: SSH Soft Fencing >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Eli Mesika" >>>>> To: "Martin Perina" >>>>> Cc: engine-devel at ovirt.org, "Yair Zaslavsky" , >>>>> "Barak >>>>> Azulay" >>>>> Sent: Thursday, June 27, 2013 3:48:39 PM >>>>> Subject: Re: SSH Soft Fencing >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Martin Perina" >>>>>> To: engine-devel at ovirt.org >>>>>> Cc: "Yair Zaslavsky" , "Barak Azulay" >>>>>> , "Eli Mesika" >>>>>> Sent: Thursday, June 27, 2013 1:51:06 PM >>>>>> Subject: SSH Soft Fencing >>>>>> >>>>>> Hi, >>>>>> >>>>>> SSH Soft Fencing is a new feature for 3.3 and it tries to restart >>>>>> VDSM >>>>>> using SSH connection on non responsive hosts prior to real fencing. >>>>>> More info can be found at >>>>>> >>>>>> http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3 >>>>>> >>>>>> In current SSH Soft Fencing implementation the restart VDSM using SSH >>>>>> command is part of standard fencing implementation in >>>>>> VdsNotRespondingTreatmentCommand. But this command is executed only >>>>>> if a host has a valid PM configuration. If host doesn't have a valid >>>>>> PM configuration, the execution of the command is disabled and host >>>>>> state is change to Non Responsive. >>>>>> >>>>>> So my question are: >>>>>> >>>>>> 1) Should SSH Soft Fencing be executed on hosts without valid PM >>>>>> configuration? >>>>> >>>>> I think that the answer should be yes. The vdsm restart will solve most >>>>> of >>>>> problems , so why not using it whether a PM agent is defined or not. >>>> I agree. >>>> I would like to say that I also don't like the fact that >>>> VdsNotRespondingTreatment extends RestartVdsCommand. >>>> One should ask if "non responding treatment is a restart vds operation" >>>> or >>>> maybe RestartVdsCommand is just a step in the non responding treatment >>>> (inheritance vs containment/delegation). >>>> I think that VdsNotRespodingTreatment should delegate the call to >>>> RestartVdsCommand as the 2nd step after issuing the Soft Fencing command. >>>> Thoughts anyone? >>> >>> That would be a nice and needed re-factoring >> >> I would say yes - but would add it only with appropriate configuration >> (enableAutoSoftVdsmRestartWhenNoPMAvailable .... I hate the name) >> >> >> >>> >>>> >>>>> >>>>>> >>>>>> 2) Should VDSM restart using SSH command be reimplemented >>>>>> as standalone command to be usable also in other parts of engine? >>>>>> If 1) is true, I think it will have to be done anyway. >>>> >>>> I agree here. >>>>> >>>>> +1 >> >> On one hand it makes sense, but I have several questions on the above: >> - Who do we think may want to use such a command ? I believe you'll agree that right encapsulation and decoupling is part of writing a maintainable code, it is not necessarily about reusing it. >> - Should (or even can) we limit the use of such command to >> noneResponsiveTreatment ? >> At this point this command would be executed only within the noneResponsiveTreatment flow. We don't need to model this in the REST API nor in the UI, decoupling the vdsm fencing code is just an internal implementation detail. >> Having general commands available to all code when there is only one specific >> case we are using it might be a bit riskey, >> Especially when we talk about restarting something. > I am not sure what is the risk? > Martin ? Eli? Yair? > > Can you please refer to the issue above ? > > >> >> Thoughts ? >> >> >> >>>>> >>>>>> >>>>>> >>>>>> Martin Perina >>>>>> >>>>> >>>> >>> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From amureini at redhat.com Mon Jul 1 07:29:51 2013 From: amureini at redhat.com (Allon Mureinik) Date: Mon, 1 Jul 2013 03:29:51 -0400 (EDT) Subject: [Engine-devel] Guid improvements In-Reply-To: <64DD4754-E88A-4FF2-94BA-3B1F2B2D2BA5@gmail.com> References: <207761917.1453625.1372579890708.JavaMail.root@redhat.com> <1510804261.30673992.1372580036122.JavaMail.root@redhat.com> <64DD4754-E88A-4FF2-94BA-3B1F2B2D2BA5@gmail.com> Message-ID: <1721413331.1635156.1372663791629.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Liran Zelkha" > To: "Yair Zaslavsky" > Cc: "Allon Mureinik" , "engine-devel" > Sent: Sunday, June 30, 2013 11:37:26 AM > Subject: Re: [Engine-devel] Guid improvements > > Great news. > Allon - please note that GUID is being recreated from String by both DB calls > and by data received from VDSM. It is VERY useful to cache Guid > String-->Guid, and not just Empty GUID. I generally agree about the high cost of sting<->uuid operations, but I'm not sure caching is the way to go, at least not everywhere. At least for the database, there is a much easier solution - stop using strings to represent uuids. Here's an example of how it can be done: http://gerrit.ovirt.org/#/c/16281/ > > However, as the Guid class runs in GWT as well, you can't use Infinispan and > you're limited in the HashMap implementations you can use. Personally, I > don't think it's a memory leak, as GUID number in the system are finite and > not too large. What do you think? Want to add it to your patch? > > On Jun 30, 2013, at 11:13 AM, Yair Zaslavsky wrote: > > > Well done, should have been done ages ago :) > > Now, for the painful rebase of async_task_mgr changes :) > > > > > > ----- Original Message ----- > >> From: "Allon Mureinik" > >> To: "engine-devel" , "Barak Azulay" > >> > >> Cc: "Yair Zaslavsky" , "Michael Pasternak" > >> , "Tal Nisan" > >> , "Ayal Baron" > >> Sent: Sunday, June 30, 2013 11:11:30 AM > >> Subject: Guid improvements > >> > >> Hi all, > >> > >> I just merged a couple of improvements to the [N]Guid class [1] to improve > >> it's performance both CPU-wise and memory-wise, based on a set of > >> benchmarks > >> presented by Liran. > >> > >> What this patchset achieves: > >> 1. Clean up the code, so it's easier to understand and use > >> 2. Eliminate the inflation in the memory foot print caused by the > >> getValue() > >> method > >> 3. Eliminate all the heavy calls to UUID.fromString when creating a > >> new/empty > >> Guid instance as a default value > >> 4. Note that the cleanups proposed in (1) will have minor performance > >> benefits (e.g., eliminating useless conditional statements), but I doubt > >> this would be anything to write home about. > >> > >> From a developer's perspective, here's what changed: > >> 1. No more NGuid, just Guid. Both static methods to create a Guid from > >> String > >> still exist, and are named createGuidFromString and > >> createGuidFromStringDefaultEmpty. > >> 2. [N]Guid.getValue() was removed, it's no longer needed after (1) was > >> implemented > >> 3. The Guid() constructor was made private, as it forced a redundant call > >> to > >> UUID.fromString(String). If you need an empty Guid instance, just use > >> Guid.Empty > >> 4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was used > >> for > >> redundant calls to UUID.fromString. If you really, REALLY, need it, just > >> call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a > >> String. > >> 5. All sorts of ways to transform Strings to Guids were removed. If you > >> have > >> a literal you trust, just use new Guid(String). If you suspect it may be > >> null, use Guid.createGuidFromString[DefaultEmpty] > >> 6. NewGuid is now called newGuid. We're in Java, not C# :-) > >> > >> > >> Many thanks to everyone who reviewed this patchset. > >> You guys rock! > >> > >> > >> Regards, > >> Allon > >> > >> > >> [1] > >> http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:guid-cleanup,n,z > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From liran.zelkha at gmail.com Mon Jul 1 07:36:06 2013 From: liran.zelkha at gmail.com (Liran Zelkha) Date: Mon, 1 Jul 2013 10:36:06 +0300 Subject: [Engine-devel] Guid improvements In-Reply-To: <1721413331.1635156.1372663791629.JavaMail.root@redhat.com> References: <207761917.1453625.1372579890708.JavaMail.root@redhat.com> <1510804261.30673992.1372580036122.JavaMail.root@redhat.com> <64DD4754-E88A-4FF2-94BA-3B1F2B2D2BA5@gmail.com> <1721413331.1635156.1372663791629.JavaMail.root@redhat.com> Message-ID: Awesome!!! On Mon, Jul 1, 2013 at 10:29 AM, Allon Mureinik wrote: > > > ----- Original Message ----- > > From: "Liran Zelkha" > > To: "Yair Zaslavsky" > > Cc: "Allon Mureinik" , "engine-devel" < > engine-devel at ovirt.org> > > Sent: Sunday, June 30, 2013 11:37:26 AM > > Subject: Re: [Engine-devel] Guid improvements > > > > Great news. > > Allon - please note that GUID is being recreated from String by both DB > calls > > and by data received from VDSM. It is VERY useful to cache Guid > > String-->Guid, and not just Empty GUID. > I generally agree about the high cost of sting<->uuid operations, but I'm > not sure caching is the way to go, at least not everywhere. > > At least for the database, there is a much easier solution - stop using > strings to represent uuids. > Here's an example of how it can be done: > http://gerrit.ovirt.org/#/c/16281/ > > > > > > However, as the Guid class runs in GWT as well, you can't use Infinispan > and > > you're limited in the HashMap implementations you can use. Personally, I > > don't think it's a memory leak, as GUID number in the system are finite > and > > not too large. What do you think? Want to add it to your patch? > > > > On Jun 30, 2013, at 11:13 AM, Yair Zaslavsky wrote: > > > > > Well done, should have been done ages ago :) > > > Now, for the painful rebase of async_task_mgr changes :) > > > > > > > > > ----- Original Message ----- > > >> From: "Allon Mureinik" > > >> To: "engine-devel" , "Barak Azulay" > > >> > > >> Cc: "Yair Zaslavsky" , "Michael Pasternak" > > >> , "Tal Nisan" > > >> , "Ayal Baron" > > >> Sent: Sunday, June 30, 2013 11:11:30 AM > > >> Subject: Guid improvements > > >> > > >> Hi all, > > >> > > >> I just merged a couple of improvements to the [N]Guid class [1] to > improve > > >> it's performance both CPU-wise and memory-wise, based on a set of > > >> benchmarks > > >> presented by Liran. > > >> > > >> What this patchset achieves: > > >> 1. Clean up the code, so it's easier to understand and use > > >> 2. Eliminate the inflation in the memory foot print caused by the > > >> getValue() > > >> method > > >> 3. Eliminate all the heavy calls to UUID.fromString when creating a > > >> new/empty > > >> Guid instance as a default value > > >> 4. Note that the cleanups proposed in (1) will have minor performance > > >> benefits (e.g., eliminating useless conditional statements), but I > doubt > > >> this would be anything to write home about. > > >> > > >> From a developer's perspective, here's what changed: > > >> 1. No more NGuid, just Guid. Both static methods to create a Guid from > > >> String > > >> still exist, and are named createGuidFromString and > > >> createGuidFromStringDefaultEmpty. > > >> 2. [N]Guid.getValue() was removed, it's no longer needed after (1) was > > >> implemented > > >> 3. The Guid() constructor was made private, as it forced a redundant > call > > >> to > > >> UUID.fromString(String). If you need an empty Guid instance, just use > > >> Guid.Empty > > >> 4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was > used > > >> for > > >> redundant calls to UUID.fromString. If you really, REALLY, need it, > just > > >> call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a > > >> String. > > >> 5. All sorts of ways to transform Strings to Guids were removed. If > you > > >> have > > >> a literal you trust, just use new Guid(String). If you suspect it may > be > > >> null, use Guid.createGuidFromString[DefaultEmpty] > > >> 6. NewGuid is now called newGuid. We're in Java, not C# :-) > > >> > > >> > > >> Many thanks to everyone who reviewed this patchset. > > >> You guys rock! > > >> > > >> > > >> Regards, > > >> Allon > > >> > > >> > > >> [1] > > >> > http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:guid-cleanup,n,z > > >> > > > _______________________________________________ > > > 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 mperina at redhat.com Mon Jul 1 08:23:12 2013 From: mperina at redhat.com (Martin Perina) Date: Mon, 1 Jul 2013 04:23:12 -0400 (EDT) Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <51D11BE0.6000809@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <1695008076.4096833.1372337319955.JavaMail.root@redhat.com> <12227690.29409642.1372344197624.JavaMail.root@redhat.com> <1625820710.4175423.1372344929287.JavaMail.root@redhat.com> <687362379.9364944.1372354295556.JavaMail.root@redhat.com> <2036896830.10266657.1372610122917.JavaMail.root@redhat.com> <51D11BE0.6000809@redhat.com> Message-ID: <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> So let me summarize it: We have come to agreement in those questions: 1) SSH Soft Fencing logic should be extracted from VdsNotRespondingTreatment command to its own SshSoftFencingCommand 2) VdsNotRespondingCommand should be refactored so it's not inherited from VdsRestartCommand, but it should run SshSoftFencingCommand or VdsRestartCommand based on defined fencing flow These questions has not been resolved yet: 3) Should SSH Soft Fencing be executed also for hosts without PM configured? 4) Should SSH Soft Fencing execution for hosts without PM configured be enabled by default and admin can turn off these feature using configuration options SshSoftFencingWithoutPmEnabled (or something like that)? 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster wide option (can be turned off for specific cluster version) or a VDS option (it can be turned off for each host)? Personally I would suggest: ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM configured ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be enabled by default ad 5) I don't see any significant reason why someone would like to turn off SSH Soft Fencing for hosts without PM configured. But if someone would like to do that, I think he would like to turn it off only for specific hosts, so VDS level option makes sense for me Martin From yzaslavs at redhat.com Mon Jul 1 08:27:37 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 1 Jul 2013 04:27:37 -0400 (EDT) Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <1695008076.4096833.1372337319955.JavaMail.root@redhat.com> <12227690.29409642.1372344197624.JavaMail.root@redhat.com> <1625820710.4175423.1372344929287.JavaMail.root@redhat.com> <687362379.9364944.1372354295556.JavaMail.root@redhat.com> <2036896830.10266657.1372610122917.JavaMail.root@redhat.com> <51D11BE0.6000809@redhat.com> <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> Message-ID: <429008692.30913072.1372667257807.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Martin Perina" > To: engine-devel at ovirt.org > Sent: Monday, July 1, 2013 11:23:12 AM > Subject: Re: [Engine-devel] SSH Soft Fencing > > So let me summarize it: > > We have come to agreement in those questions: > > 1) SSH Soft Fencing logic should be extracted from VdsNotRespondingTreatment > command to its own SshSoftFencingCommand > > 2) VdsNotRespondingCommand should be refactored so it's not inherited from > VdsRestartCommand, but it should run SshSoftFencingCommand > or VdsRestartCommand based on defined fencing flow > > > These questions has not been resolved yet: > > 3) Should SSH Soft Fencing be executed also for hosts without PM configured? > > 4) Should SSH Soft Fencing execution for hosts without PM configured be > enabled > by default and admin can turn off these feature using configuration > options > SshSoftFencingWithoutPmEnabled (or something like that)? > > 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster wide > option (can be turned off for specific cluster version) or a VDS option > (it can be turned off for each host)? > > > Personally I would suggest: > > ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM > configured > > ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be > enabled by default > > ad 5) I don't see any significant reason why someone would like to turn off > SSH Soft Fencing > for hosts without PM configured. But if someone would like to do that, > I think > he would like to turn it off only for specific hosts, so VDS level > option makes sense > for me After re-thinking 5 - I agree. +1 on the other suggestions, but of course we need to get more consensus here. > > > Martin > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From yzaslavs at redhat.com Mon Jul 1 09:48:13 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 1 Jul 2013 05:48:13 -0400 (EDT) Subject: [Engine-devel] Cannot run ovirt engine on master - BrandingServlet issue In-Reply-To: <650234194.30956706.1372672011873.JavaMail.root@redhat.com> Message-ID: <1100821785.30957224.1372672093436.JavaMail.root@redhat.com> I get class not found issue for BrandingManager 013-07-01 12:44:25,273 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."engine.ear"."webadmin.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."engine.ear"."webadmin.war".POST_MODULE: Failed to process phase POST_MODULE of subdeployment "webadmin.war" of deployment "engine.ear" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc.jar:1.0.2.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc.jar:1.0.2.GA] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] Caused by: java.lang.RuntimeException: Error getting reflective information for class org.ovirt.engine.ui.frontend.server.gwt.BrandingServlet with ClassLoader ModuleClassLoader for Module "deployment.engine.ear.webadmin.war:main" from Service Module Loader at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:58) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:85) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:70) at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:55) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] ... 5 more Caused by: java.lang.NoClassDefFoundError: Lorg/ovirt/engine/core/utils/branding/BrandingManager; at java.lang.Class.getDeclaredFields0(Native Method) [rt.jar:1.7.0_25] at java.lang.Class.privateGetDeclaredFields(Class.java:2377) [rt.jar:1.7.0_25] I am rebased against 2a590891ea1adc5eed0c4cd43577049fb77f3752 Can someone please advise? Yair From lpeer at redhat.com Mon Jul 1 09:57:34 2013 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 01 Jul 2013 12:57:34 +0300 Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <429008692.30913072.1372667257807.JavaMail.root@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <1695008076.4096833.1372337319955.JavaMail.root@redhat.com> <12227690.29409642.1372344197624.JavaMail.root@redhat.com> <1625820710.4175423.1372344929287.JavaMail.root@redhat.com> <687362379.9364944.1372354295556.JavaMail.root@redhat.com> <2036896830.10266657.1372610122917.JavaMail.root@redhat.com> <51D11BE0.6000809@redhat.com> <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> <429008692.30913072.1372667257807.JavaMail.root@redhat.com> Message-ID: <51D1528E.5050908@redhat.com> On 07/01/2013 11:27 AM, Yair Zaslavsky wrote: > > > ----- Original Message ----- >> From: "Martin Perina" >> To: engine-devel at ovirt.org >> Sent: Monday, July 1, 2013 11:23:12 AM >> Subject: Re: [Engine-devel] SSH Soft Fencing >> >> So let me summarize it: >> >> We have come to agreement in those questions: >> >> 1) SSH Soft Fencing logic should be extracted from VdsNotRespondingTreatment >> command to its own SshSoftFencingCommand >> >> 2) VdsNotRespondingCommand should be refactored so it's not inherited from >> VdsRestartCommand, but it should run SshSoftFencingCommand >> or VdsRestartCommand based on defined fencing flow >> >> >> These questions has not been resolved yet: >> >> 3) Should SSH Soft Fencing be executed also for hosts without PM configured? >> >> 4) Should SSH Soft Fencing execution for hosts without PM configured be >> enabled >> by default and admin can turn off these feature using configuration >> options >> SshSoftFencingWithoutPmEnabled (or something like that)? >> >> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster wide >> option (can be turned off for specific cluster version) or a VDS option >> (it can be turned off for each host)? >> >> >> Personally I would suggest: >> >> ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM >> configured >> +1 >> ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be >> enabled by default >> +1 >> ad 5) I don't see any significant reason why someone would like to turn off >> SSH Soft Fencing >> for hosts without PM configured. But if someone would like to do that, >> I think >> he would like to turn it off only for specific hosts, so VDS level >> option makes sense >> for me > > After re-thinking 5 - I agree. > +1 on the other suggestions, but of course we need to get more consensus here. > I think it does not need to be configurable. >> >> >> Martin >> _______________________________________________ >> 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 Jul 1 10:02:18 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 01 Jul 2013 13:02:18 +0300 Subject: [Engine-devel] development installation issues In-Reply-To: <1449386688.13237557.1372619786067.JavaMail.root@redhat.com> References: <51CFE63A.2050505@redhat.com> <1449386688.13237557.1372619786067.JavaMail.root@redhat.com> Message-ID: <51D153AA.4060603@redhat.com> Hi Alon, On 06/30/2013 10:16 PM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" >> To: "engine-devel" >> Sent: Sunday, June 30, 2013 11:03:06 AM >> Subject: [Engine-devel] development installation issues >> >> >> does anyone faced this with new 'development installation'? > > Hi Michael, > > Can I have the output of: > > OTOPI_DEBUG=1 /home/mpastern/Coding/ovirt/ovirt-engine/bin/engine-setup-2 i made it work, it was my bad. thanks. > > Thanks! > >> >> [mpastern at lpt21-f ovirt-engine]$ >> /home/mpastern/Coding/ovirt/ovirt-engine/bin/engine-setup-2 >> [ ERROR ] Failed to execute stage 'Booting': 5 >> [ INFO ] Stage: Initializing >> Setup was run under unprivileged user this will produce development >> installation do you wish to proceed? (Yes, No) [No]: Yes >> [WARNING] engine-setup-2 is a technical preview, and yet to include all >> functionality that exists in legacy engine-setup. Specifically, >> engine-setup-2 does not support >> upgrade from previous installations. >> [mpastern at lpt21-f ovirt-engine]$ >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From yzaslavs at redhat.com Mon Jul 1 10:09:49 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 1 Jul 2013 06:09:49 -0400 (EDT) Subject: [Engine-devel] Cannot run ovirt engine on master - BrandingServlet issue In-Reply-To: <1100821785.30957224.1372672093436.JavaMail.root@redhat.com> References: <1100821785.30957224.1372672093436.JavaMail.root@redhat.com> Message-ID: <1233079938.30970727.1372673389240.JavaMail.root@redhat.com> I am using the development environment introduced by Albonl. I do have ovirt-engine/etc/ovirt-engine/branding Directory after installation. Yair ----- Original Message ----- > From: "Yair Zaslavsky" > To: "engine-devel" > Sent: Monday, July 1, 2013 12:48:13 PM > Subject: [Engine-devel] Cannot run ovirt engine on master - BrandingServlet issue > > I get class not found issue for BrandingManager > > 013-07-01 12:44:25,273 ERROR [org.jboss.msc.service.fail] (MSC service thread > 1-7) MSC000001: Failed to start service > jboss.deployment.subunit."engine.ear"."webadmin.war".POST_MODULE: > org.jboss.msc.service.StartException in service > jboss.deployment.subunit."engine.ear"."webadmin.war".POST_MODULE: Failed to > process phase POST_MODULE of subdeployment "webadmin.war" of deployment > "engine.ear" > at > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) > [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) > [jboss-msc.jar:1.0.2.GA] > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) > [jboss-msc.jar:1.0.2.GA] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_25] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > Caused by: java.lang.RuntimeException: Error getting reflective information > for class org.ovirt.engine.ui.frontend.server.gwt.BrandingServlet with > ClassLoader ModuleClassLoader for Module > "deployment.engine.ear.webadmin.war:main" from Service Module Loader > at > org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70) > [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] > at > org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:58) > at > org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:85) > at > org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:70) > at > org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:55) > at > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) > [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] > ... 5 more > Caused by: java.lang.NoClassDefFoundError: > Lorg/ovirt/engine/core/utils/branding/BrandingManager; > at java.lang.Class.getDeclaredFields0(Native Method) > [rt.jar:1.7.0_25] > at java.lang.Class.privateGetDeclaredFields(Class.java:2377) > [rt.jar:1.7.0_25] > > > > I am rebased against 2a590891ea1adc5eed0c4cd43577049fb77f3752 > > Can someone please advise? > > > Yair > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From sbonazzo at redhat.com Mon Jul 1 11:40:18 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Mon, 01 Jul 2013 13:40:18 +0200 Subject: [Engine-devel] Cannot run ovirt engine on master - BrandingServlet issue In-Reply-To: <1233079938.30970727.1372673389240.JavaMail.root@redhat.com> References: <1100821785.30957224.1372672093436.JavaMail.root@redhat.com> <1233079938.30970727.1372673389240.JavaMail.root@redhat.com> Message-ID: <51D16AA2.5070000@redhat.com> Il 01/07/2013 12:09, Yair Zaslavsky ha scritto: > Caused by: java.lang.NoClassDefFoundError: > Lorg/ovirt/engine/core/utils/branding/BrandingManager; > at java.lang.Class.getDeclaredFields0(Native Method) > [rt.jar:1.7.0_25] > at java.lang.Class.privateGetDeclaredFields(Class.java:2377) > [rt.jar:1.7.0_25] > Same issue here. But I'm not sure it's something due to devenv engine-setup-2. > > > _______________________________________________ > 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 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From yzaslavs at redhat.com Mon Jul 1 12:30:28 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 1 Jul 2013 08:30:28 -0400 (EDT) Subject: [Engine-devel] Cannot run ovirt engine on master - BrandingServlet issue In-Reply-To: <1100821785.30957224.1372672093436.JavaMail.root@redhat.com> References: <1100821785.30957224.1372672093436.JavaMail.root@redhat.com> Message-ID: <611267793.31068437.1372681828607.JavaMail.root@redhat.com> Issue of dirty clone of git repo. Had an old version of utils.jar that was copied to $HOME/ovirt-engine after git clean -dfx issue got resolved. Thanks for all those who tried to help. ----- Original Message ----- > From: "Yair Zaslavsky" > To: "engine-devel" > Sent: Monday, July 1, 2013 12:48:13 PM > Subject: [Engine-devel] Cannot run ovirt engine on master - BrandingServlet issue > > I get class not found issue for BrandingManager > > 013-07-01 12:44:25,273 ERROR [org.jboss.msc.service.fail] (MSC service thread > 1-7) MSC000001: Failed to start service > jboss.deployment.subunit."engine.ear"."webadmin.war".POST_MODULE: > org.jboss.msc.service.StartException in service > jboss.deployment.subunit."engine.ear"."webadmin.war".POST_MODULE: Failed to > process phase POST_MODULE of subdeployment "webadmin.war" of deployment > "engine.ear" > at > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) > [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) > [jboss-msc.jar:1.0.2.GA] > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) > [jboss-msc.jar:1.0.2.GA] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_25] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > Caused by: java.lang.RuntimeException: Error getting reflective information > for class org.ovirt.engine.ui.frontend.server.gwt.BrandingServlet with > ClassLoader ModuleClassLoader for Module > "deployment.engine.ear.webadmin.war:main" from Service Module Loader > at > org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70) > [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] > at > org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:58) > at > org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:85) > at > org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:70) > at > org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:55) > at > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) > [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] > ... 5 more > Caused by: java.lang.NoClassDefFoundError: > Lorg/ovirt/engine/core/utils/branding/BrandingManager; > at java.lang.Class.getDeclaredFields0(Native Method) > [rt.jar:1.7.0_25] > at java.lang.Class.privateGetDeclaredFields(Class.java:2377) > [rt.jar:1.7.0_25] > > > > I am rebased against 2a590891ea1adc5eed0c4cd43577049fb77f3752 > > Can someone please advise? > > > Yair > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ecohen at redhat.com Mon Jul 1 13:20:42 2013 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 1 Jul 2013 09:20:42 -0400 (EDT) Subject: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST In-Reply-To: <1119844308.3674080.1372656560744.JavaMail.root@redhat.com> References: <501973842.20255318.1371648804880.JavaMail.root@redhat.com> <1210717020.2488959.1372324871664.JavaMail.root@redhat.com> <20130627093010.GC13576@teriyaki.redhat.com> <2114201154.2496221.1372326631963.JavaMail.root@redhat.com> <2874260.9314218.1372348873189.JavaMail.root@redhat.com> <856039866.2941458.1372398071424.JavaMail.root@redhat.com> <1643373626.9902858.1372435276836.JavaMail.root@redhat.com> <1119844308.3674080.1372656560744.JavaMail.root@redhat.com> Message-ID: <828730502.10669676.1372684842052.JavaMail.root@redhat.com> > ----- Original Message ----- > From: "Tomas Jelinek" > Sent: Monday, July 1, 2013 1:29:20 AM > > > > ----- Original Message ----- > > From: "Einav Cohen" > > To: "Tomas Jelinek" , "Vojtech Szocs" > > > > Cc: "engine-devel" > > Sent: Friday, June 28, 2013 6:01:16 PM > > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST > > > > Hi Tomas, > > > > > IIUC the RFE addresses only UIPlugins with their metadata so > > > in order to integrate this with the SPICE we nee to either > > > enrich the RFE or to create a UIPlugin which will start the > > > SPICE. I would vote for the second option. What others? > > > > using a ui-plugin that will start SPICE is an interesting approach - it > > haven't crossed my mind. What I had in mind is to somewhat "generalize" the > > RestApiSessionManager to provide REST-API-session-creation services to the > > entire GUI (e.g. SPICE-console-opening-code), and not only to the > > ui-plugins > > in particular. > > I think that since SPICE is already quite integrated into oVirt (in our > > business > > logic, dialogs, ...), it would be somewhat weird to use a UI-Plugin in > > order > > to > > invoke SPICE, just in order to get the REST-API-session-creation > > capability. > > > > So I am actually in favor of enriching the RFE (i.e. "generalize" the > > RestApiSessionManager), rather than treating SPICE as a UI-Plugin (in a > > sense). > > yes, you are right. > > > > > > Why only for SPICE? I can imagine UIPlugins which could make use of this > > > option. > > > > the main difference between SPICE and the UIPlugins is that we know in > > advance > > how SPICE is going to use REST API. > > This is not true anymore - SPICE can add whatever it wants to it's menu and > webadmin/userportal > has no control about it anymore (I'm talking about the non-plugin invocation > of the SPICE). > > > In addition, SPICE is going to do actions > > (e.g. > > Stop/Pause/Attach CD) on the VM only when the user chooses to do so (via > > the > > SPICE menu), so actions will be done on behalf of the logged-in user, so it > > makes > > sense to provide to SPICE the same credentials as the logged-in user. > > > > a ui-plugin is a third-party component which we don't know in advance how > > it > > is > > going to act; moreover, the user that is logging into the web-admin doesn't > > have > > control on it. Imagine a ui-plugin that shuts-down/deletes all VMs > > immediately > > upon login to the web-admin - all VMs will be shutdown/deleted upon the > > first > > login into the web-admin (after the ui-plugin installation on the engine > > server). > > If the same-credentials-approach will be used, the shutdown/deletion of all > > VMs > > will be done on behalf of the user that happened to be the first one > > logging > > into > > the web-admin (post ui-plugin installation), which, obviously, is not good. > > Well, I did not mean to give this permission to all the plugins - all I > wanted to > say is to make this configurable per plugin. I can imagine > also a well-known UI plugin which is trusted by the admin and it does make > sense > to make it use the same rights as the logged in user. > I did not mean that each plugin has to have this permissions. > > > > > So to sum-up: I think that > > > > - the RestApiSessionManager should be "generalized" to provide > > REST-API-session- > > creation services to the entire GUI (e.g. SPICE-console-opening-code), and > > not only > > to the ui-plugins in particular. > > completely agree > > > > > - RestApiSessionManager should support creation of both > > same-credentials-session as > > well as other-credentials-session; the same-credentials-session should be > > limited to > > well-known/well-integrated components (e.g. SPICE), whereas the > > other-credentials-session > > can be used by third-party components as well (e.g. ui-plugins). > > Who should decide about what is the well-known component? I would let the > administrator to > configure this. We can provide the defaults (e.g. the > same-credentials-session will be disabled by > default for ui-plugins but it will be possible to enabled it explicitly for > some ui-plugins). +1 having the same-credentials-session disabled by default for ui-plugins and having the admin explicitly enabling it per plugin where necessary makes perfect sense. note that for SPICE, which is NOT a UI plugin, but is still a third-party component (but one that is well-integrated into ovirt), I think that we should use the same- credentials-session method by default (i.e. without the administrator explicitly allowing it). > > > > > [I could be wrong - would love to hear what the others GUI maintainers > > think] > > > > > > > ----- Original Message ----- > > > From: "Tomas Jelinek" > > > Sent: Friday, June 28, 2013 1:41:11 AM > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Einav Cohen" > > > > To: "Tomas Jelinek" , "Vojtech Szocs" > > > > > > > > Cc: "engine-devel" , "Michael Pasternak" > > > > > > > > Sent: Thursday, June 27, 2013 6:01:13 PM > > > > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST > > > > > > > > Hi Tomas, > > > > > > > > > Yes, we can provide the sessionId to authenticate with the REST and > > > > > the > > > > > vm > > > > > guid is not a problem. > > > > > > > > Note that in the web-admin, we already have code that generates REST > > > > API > > > > session-ID; > > > > this code is being utilized in the ui-plugins infrastructure to allow > > > > the > > > > different > > > > ui-plugins to communicate with the rest api. > > > > [one related file is this context is RestApiSessionManager.java in the > > > > web-admin, not > > > > sure if there are others] > > > > > > Yes, I'm aware of that. This is what I had in mind when was talking about > > > passing the SessionId to SPICE. > > > > > > > > > > > maybe the RestApiSessionManager(?) can somehow be utilized for the > > > > SPICE > > > > purpose as well > > > > (I guess that it will require a couple of code-changes though, and > > > > maybe > > > > worth moving it > > > > to gwt-common, to allow its utilization from the user portal as well?) > > > > - > > > > @Vojtech would > > > > probably know best to advise on this. > > > > > > > > * Note: Today: > > > > (a) a *single* REST API session-ID is generated and used across all > > > > ui-plugins in the system > > > > (upon user login to the web-admin). > > > > > > > > (b) this REST-API session-ID is generated based on the *same > > > > credentials* > > > > with which the user > > > > logged into the web-admin. > > > > > > > > both (a) and (b) will change once [1] will be addressed. > > > > > > Thank you for mentioning this! I was not aware of this RFE. IIUC the RFE > > > addresses only > > > UIPlugins with their metadata so in order to integrate this with the > > > SPICE > > > we > > > nee to either > > > enrich the RFE or to create a UIPlugin which will start the SPICE. I > > > would > > > vote for the second option. > > > What others? > > > > > > > Only for the SPICE case in particular - I think that (b) should remain. > > > > so > > > > > > Why only for SPICE? I can imagine UIPlugins which could make use of this > > > option. > > > > > > > maybe worth allowing > > > > both same-credentials-login and different-credentials-login in the > > > > REST-API-Session-ID-generation > > > > code in the GUI. > > > > > > This option might make sense also for other UIPlugins so maybe the SPICE > > > integration will not be anything special, just a UIPlugin. > > > > > > > > > > > ---- > > > > Thanks, > > > > Einav > > > > > > > > [1] Bug 962863 - RFE: Improve REST API integration for UI Plugins > > > > https://bugzilla.redhat.com/show_bug.cgi?id=962863 > > > > some of the planned changes (from the BZ description): > > > > """ > > > > ... > > > > - each UI plugin will have its own dedicated REST API session, > > > > unrelated > > > > to > > > > GUI (admin) > > > > user credentials > > > > ... > > > > """ > > > > > > > > > ----- Original Message ----- > > > > > From: "Tomas Jelinek" > > > > > Sent: Thursday, June 27, 2013 5:50:31 AM > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Christophe Fergeau" > > > > > > To: "Tomas Jelinek" > > > > > > Cc: "Michal Skrivanek" , "Itamar Heim" > > > > > > , > > > > > > spice-devel at lists.freedesktop.org, "engine-devel" > > > > > > , > > > > > > "Marc-Andr? Lureau" > > > > > > Sent: Thursday, June 27, 2013 11:30:10 AM > > > > > > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using > > > > > > REST > > > > > > > > > > > > Hey, > > > > > > > > > > > > On Thu, Jun 27, 2013 at 05:21:11AM -0400, Tomas Jelinek wrote: > > > > > > > well, it seems that everyone agree that the decision what to add > > > > > > > to > > > > > > > the > > > > > > > menu is the client responsibility. It means there is no > > > > > > > additional > > > > > > > work > > > > > > > needed on the > > > > > > > oVirt engine side - going to remove the feature page. > > > > > > > > > > > > If we go the REST API way to handle foreign menu, we need > > > > > > additional > > > > > > info > > > > > > in the .vv files: some way to auth with the REST API, and the guid > > > > > > of > > > > > > the > > > > > > VM to act on. > > > > > Yes, we can provide the sessionId to authenticate with the REST and > > > > > the > > > > > vm > > > > > guid is not a problem. > > > > > > > > > > > > > > > > > Christophe > > > > > > > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > From ecohen at redhat.com Mon Jul 1 13:47:40 2013 From: ecohen at redhat.com (Einav Cohen) Date: Mon, 1 Jul 2013 09:47:40 -0400 (EDT) Subject: [Engine-devel] Build step 'Publish FindBugs analysis results' changed build result to UNSTABLE In-Reply-To: References: Message-ID: <730548653.10698591.1372686460234.JavaMail.root@redhat.com> Hi Dave, Typically, what you would want to do with find-bugs unstable jobs is to go to the job status page ([1] in your case) and look for the new warnings (in your case there are two new warnings, one of them is a High-priority warning that should be addressed in order to stabilize the job). click on the "2 new warnings" link, and drill down to the red (high-priority) warning itself to see its details. (@Eyal - it seems that there is a problem within of finding/copying files - see [2] - not sure if related) ---- Thanks, Einav [1] http://jenkins.ovirt.org/job/ovirt_engine_find_bugs_gerrit/2928/ [2] http://jenkins.ovirt.org/job/ovirt_engine_find_bugs_gerrit/2928/findbugsResult/new/package.207693557/source.133782/#48 ----- Original Message ----- > From: "Wei D Chen" > To: "engine-devel" > Cc: "Lijuan Zhang" > Sent: Monday, July 1, 2013 1:14:15 AM > Subject: [Engine-devel] Build step 'Publish FindBugs analysis results' changed build result to UNSTABLE > > Is there anyone know the reason for these error message? what can I do to fix > it? > > > [INFO] > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > engine-server-ear --- > [INFO] Installing > /jenkins-workspaces/ovirt_engine_find_bugs_gerrit/ovirt-engine/ear/target/engine.ear > to > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > [INFO] Installing > /jenkins-workspaces/ovirt_engine_find_bugs_gerrit/ovirt-engine/ear/pom.xml > to > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > [INFO] > [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @ > engine-server-ear --- > [INFO] > ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] ovirt-root ........................................ SUCCESS [4.719s] > [INFO] oVirt Build Tools root ............................ SUCCESS [0.129s] > [INFO] oVirt checkstyle .................................. SUCCESS [2.001s] > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS [39.769s] > [INFO] oVirt Checkstyle Checks ........................... SUCCESS [27.944s] > [INFO] oVirt Modules - backend ........................... SUCCESS [0.054s] > [INFO] oVirt Manager ..................................... SUCCESS [0.052s] > [INFO] oVirt DB Scripts .................................. SUCCESS [0.210s] > [INFO] oVirt Engine dependencies ......................... SUCCESS [2.262s] > [INFO] oVirt Modules - manager ........................... SUCCESS [1.150s] > [INFO] CSharp Compatibility .............................. SUCCESS [36.770s] > [INFO] Common Code ....................................... SUCCESS > [1:43.000s] > [INFO] Common utilities .................................. SUCCESS > [1:15.054s] > [INFO] Data Access Layer ................................. SUCCESS > [1:45.658s] > [INFO] engine scheduler bean ............................. SUCCESS [33.039s] > [INFO] Vds broker ........................................ SUCCESS > [1:41.045s] > [INFO] Search Backend .................................... SUCCESS [48.983s] > [INFO] Backend Logic @Service bean ....................... SUCCESS > [3:15.813s] > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS [0.242s] > [INFO] oVirt RESTful API interface ....................... SUCCESS [0.334s] > [INFO] oVirt Engine API Definition ....................... SUCCESS > [1:04.592s] > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS [0.195s] > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS [46.398s] > [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS > [1:06.535s] > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SUCCESS > [1:45.332s] > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS [1.559s] > [INFO] oVirt Engine Web Root ............................. SUCCESS [38.216s] > [INFO] oVirt Engine Tools ................................ SUCCESS [54.388s] > [INFO] oVirt Modules :: Frontend ......................... SUCCESS [0.034s] > [INFO] oVirt Modules :: Webadmin ......................... SUCCESS [0.042s] > [INFO] oVirt Modules - ui ................................ SUCCESS [0.225s] > [INFO] Extensions for GWT ................................ SUCCESS [27.754s] > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS [32.946s] > [INFO] Frontend for GWT UI Projects ...................... SUCCESS [42.351s] > [INFO] UICommonWeb ....................................... SUCCESS > [2:52.851s] > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS > [2:30.819s] > [INFO] WebAdmin .......................................... SUCCESS > [3:36.038s] > [INFO] UserPortal ........................................ SUCCESS > [1:31.579s] > [INFO] oVirt Server EAR .................................. SUCCESS [6.661s] > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 31:41.803s > [INFO] Finished at: Fri Jun 28 12:14:28 EDT 2013 > [INFO] Final Memory: 182M/806M > [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_gerrit > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/auth/target/findbugsXml.xml > of module with 2 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/bll/target/findbugsXml.xml > of module with 177 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/common/target/findbugsXml.xml > of module with 214 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/compat/target/findbugsXml.xml > of module with 15 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/dal/target/findbugsXml.xml > of module with 4 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml > of module with 8 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml > of module with 12 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/types/target/findbugsXml.xml > of module with 7 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/root/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/scheduler/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/searchbackend/target/findbugsXml.xml > of module with 9 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/utils/target/findbugsXml.xml > of module with 45 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/vdsbroker/target/findbugsXml.xml > of module with 207 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/tools/target/findbugsXml.xml > of module with 14 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/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_gerrit/ovirt-engine/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_gerrit/ovirt-engine/frontend/webadmin/modules/frontend/target/findbugsXml.xml > of module with 31 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml > of module with 58 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml > of module with 0 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/uicompat/target/findbugsXml.xml > of module with 43 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/userportal-gwtp/target/findbugsXml.xml > of module with 7 warnings. > [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/webadmin/target/findbugsXml.xml > of module with 69 warnings. > [FINDBUGS] Computing warning deltas based on reference build #2628 > Build step 'Publish FindBugs analysis results' changed build result to > UNSTABLE > Finished: UNSTABLE > > Best Regards, > Dave Chen > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From eedri at redhat.com Mon Jul 1 14:05:36 2013 From: eedri at redhat.com (Eyal Edri) Date: Mon, 1 Jul 2013 10:05:36 -0400 (EDT) Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_find_bugs - Build # 4555 - Unstable! In-Reply-To: <56668873.9719.1372685848676.JavaMail.jenkins@jenkins.ovirt.org> References: <56668873.9719.1372685848676.JavaMail.jenkins@jenkins.ovirt.org> Message-ID: <664008311.2031382.1372687536912.JavaMail.root@redhat.com> fyi. ----- Original Message ----- > From: "Jenkins ci oVirt Server" > To: eedri at redhat.com, yzaslavs at redhat.com, dcaro at redhat.com, fkobzik at redhat.com > Sent: Monday, July 1, 2013 4:37:28 PM > Subject: [oVirt Jenkins] ovirt_engine_find_bugs - Build # 4555 - Unstable! > > Project: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/ > Build: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4555/ > Build Number: 4555 > Build Status: Unstable > Triggered By: Started by an SCM change, Started by an SCM change > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #4555 > [Frantisek Kobzik] frontend: Make VNC implementation configurable from UI > > > > > ----------------- > Failed Tests: > ----------------- > No tests ran. > > From eedri at redhat.com Mon Jul 1 14:06:49 2013 From: eedri at redhat.com (Eyal Edri) Date: Mon, 1 Jul 2013 10:06:49 -0400 (EDT) Subject: [Engine-devel] Build step 'Publish FindBugs analysis results' changed build result to UNSTABLE In-Reply-To: <730548653.10698591.1372686460234.JavaMail.root@redhat.com> References: <730548653.10698591.1372686460234.JavaMail.root@redhat.com> Message-ID: <1122958976.2031872.1372687609776.JavaMail.root@redhat.com> seems to be failing to due to last commit. frontend: Make VNC implementation configurable from UI (detail) sent seperate email on it. ----- Original Message ----- > From: "Einav Cohen" > To: "Wei D Chen" , "Eyal Edri" > Cc: "engine-devel" , "Lijuan Zhang" > Sent: Monday, July 1, 2013 4:47:40 PM > Subject: Re: [Engine-devel] Build step 'Publish FindBugs analysis results' changed build result to UNSTABLE > > Hi Dave, > > Typically, what you would want to do with find-bugs unstable jobs is to go > to the job status page ([1] in your case) and look for the new warnings (in > your case there are two new warnings, one of them is a High-priority warning > that should be addressed in order to stabilize the job). > > click on the "2 new warnings" link, and drill down to the red (high-priority) > warning itself to see its details. > > (@Eyal - it seems that there is a problem within of finding/copying files - > see [2] - not sure if related) > > ---- > Thanks, > Einav > > [1] http://jenkins.ovirt.org/job/ovirt_engine_find_bugs_gerrit/2928/ > > [2] > http://jenkins.ovirt.org/job/ovirt_engine_find_bugs_gerrit/2928/findbugsResult/new/package.207693557/source.133782/#48 > > ----- Original Message ----- > > From: "Wei D Chen" > > To: "engine-devel" > > Cc: "Lijuan Zhang" > > Sent: Monday, July 1, 2013 1:14:15 AM > > Subject: [Engine-devel] Build step 'Publish FindBugs analysis results' > > changed build result to UNSTABLE > > > > Is there anyone know the reason for these error message? what can I do to > > fix > > it? > > > > > > [INFO] > > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ > > engine-server-ear --- > > [INFO] Installing > > /jenkins-workspaces/ovirt_engine_find_bugs_gerrit/ovirt-engine/ear/target/engine.ear > > to > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.ear > > [INFO] Installing > > /jenkins-workspaces/ovirt_engine_find_bugs_gerrit/ovirt-engine/ear/pom.xml > > to > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/.repository/org/ovirt/engine/engine-server-ear/3.3.0-SNAPSHOT/engine-server-ear-3.3.0-SNAPSHOT.pom > > [INFO] > > [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (default-cli) @ > > engine-server-ear --- > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Reactor Summary: > > [INFO] > > [INFO] ovirt-root ........................................ SUCCESS [4.719s] > > [INFO] oVirt Build Tools root ............................ SUCCESS [0.129s] > > [INFO] oVirt checkstyle .................................. SUCCESS [2.001s] > > [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS > > [39.769s] > > [INFO] oVirt Checkstyle Checks ........................... SUCCESS > > [27.944s] > > [INFO] oVirt Modules - backend ........................... SUCCESS [0.054s] > > [INFO] oVirt Manager ..................................... SUCCESS [0.052s] > > [INFO] oVirt DB Scripts .................................. SUCCESS [0.210s] > > [INFO] oVirt Engine dependencies ......................... SUCCESS [2.262s] > > [INFO] oVirt Modules - manager ........................... SUCCESS [1.150s] > > [INFO] CSharp Compatibility .............................. SUCCESS > > [36.770s] > > [INFO] Common Code ....................................... SUCCESS > > [1:43.000s] > > [INFO] Common utilities .................................. SUCCESS > > [1:15.054s] > > [INFO] Data Access Layer ................................. SUCCESS > > [1:45.658s] > > [INFO] engine scheduler bean ............................. SUCCESS > > [33.039s] > > [INFO] Vds broker ........................................ SUCCESS > > [1:41.045s] > > [INFO] Search Backend .................................... SUCCESS > > [48.983s] > > [INFO] Backend Logic @Service bean ....................... SUCCESS > > [3:15.813s] > > [INFO] oVirt RESTful API Backend Integration ............. SUCCESS [0.242s] > > [INFO] oVirt RESTful API interface ....................... SUCCESS [0.334s] > > [INFO] oVirt Engine API Definition ....................... SUCCESS > > [1:04.592s] > > [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS [0.195s] > > [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS > > [46.398s] > > [INFO] oVirt RESTful API Backend Integration Type Mappers SUCCESS > > [1:06.535s] > > [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SUCCESS > > [1:45.332s] > > [INFO] oVirt RESTful API Backend Integration Webapp ...... SUCCESS [1.559s] > > [INFO] oVirt Engine Web Root ............................. SUCCESS > > [38.216s] > > [INFO] oVirt Engine Tools ................................ SUCCESS > > [54.388s] > > [INFO] oVirt Modules :: Frontend ......................... SUCCESS [0.034s] > > [INFO] oVirt Modules :: Webadmin ......................... SUCCESS [0.042s] > > [INFO] oVirt Modules - ui ................................ SUCCESS [0.225s] > > [INFO] Extensions for GWT ................................ SUCCESS > > [27.754s] > > [INFO] UI Utils Compatibility (for UICommon) ............. SUCCESS > > [32.946s] > > [INFO] Frontend for GWT UI Projects ...................... SUCCESS > > [42.351s] > > [INFO] UICommonWeb ....................................... SUCCESS > > [2:52.851s] > > [INFO] oVirt GWT UI common infrastructure ................ SUCCESS > > [2:30.819s] > > [INFO] WebAdmin .......................................... SUCCESS > > [3:36.038s] > > [INFO] UserPortal ........................................ SUCCESS > > [1:31.579s] > > [INFO] oVirt Server EAR .................................. SUCCESS [6.661s] > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] BUILD SUCCESS > > [INFO] > > ------------------------------------------------------------------------ > > [INFO] Total time: 31:41.803s > > [INFO] Finished at: Fri Jun 28 12:14:28 EDT 2013 > > [INFO] Final Memory: 182M/806M > > [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_gerrit > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/auth/target/findbugsXml.xml > > of module with 2 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/bll/target/findbugsXml.xml > > of module with 177 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/common/target/findbugsXml.xml > > of module with 214 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/compat/target/findbugsXml.xml > > of module with 15 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/dal/target/findbugsXml.xml > > of module with 4 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml > > of module with 8 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml > > of module with 0 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml > > of module with 12 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/restapi/types/target/findbugsXml.xml > > of module with 7 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/root/target/findbugsXml.xml > > of module with 0 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/scheduler/target/findbugsXml.xml > > of module with 0 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/searchbackend/target/findbugsXml.xml > > of module with 9 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/utils/target/findbugsXml.xml > > of module with 45 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/modules/vdsbroker/target/findbugsXml.xml > > of module with 207 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/backend/manager/tools/target/findbugsXml.xml > > of module with 14 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/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_gerrit/ovirt-engine/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_gerrit/ovirt-engine/frontend/webadmin/modules/frontend/target/findbugsXml.xml > > of module with 31 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/gwt-common/target/findbugsXml.xml > > of module with 58 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/gwt-extension/target/findbugsXml.xml > > of module with 0 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/uicompat/target/findbugsXml.xml > > of module with 43 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/userportal-gwtp/target/findbugsXml.xml > > of module with 7 warnings. > > [FINDBUGS] Successfully parsed file > > /home/jenkins/workspace/ovirt_engine_find_bugs_gerrit/ovirt-engine/frontend/webadmin/modules/webadmin/target/findbugsXml.xml > > of module with 69 warnings. > > [FINDBUGS] Computing warning deltas based on reference build #2628 > > Build step 'Publish FindBugs analysis results' changed build result to > > UNSTABLE > > Finished: UNSTABLE > > > > Best Regards, > > Dave Chen > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From mrao at redhat.com Mon Jul 1 18:22:57 2013 From: mrao at redhat.com (Malini Rao) Date: Mon, 1 Jul 2013 14:22:57 -0400 (EDT) Subject: [Engine-devel] VNIC profiles In-Reply-To: <51D02BB9.4090008@redhat.com> References: <51D02BB9.4090008@redhat.com> Message-ID: <1014928995.103721546.1372702977041.JavaMail.root@redhat.com> Hi Livnat, My name is Malini Rao and I am the lead interaction designer dedicated to RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan Hildeshiem who is also focused on RHEV UX. I went over your feature page and in general, the GUI proposals look great. I do have some quick feedback comments - Will there be any predefined profiles available to the users out of the box in RHEV? Or will they have to define their own? I am wondering if there are any common standard QoS levels that can be predefined and the users can get a heeadstart and use or tweak instead of defining from scratch. VNIC level QoS dialog 1. Will the Outbound and inbound values come with some defaults? Or will they be empty? Is there a need for any spinners or drop downs for frequently used values or is it ok to just have fields to type in the numeric values? Also I am assuming there is some kind of validation to ensure only numbers an be entered in these fields. 2. For custom properties, why do we have a drop down? Can custom properties defined elsewhere be accessed here and applied? If not, then I am assuming this will have to be a text field. Correct? Also, I am guessing if there is only one custom property field, the [-] icon will be disabled. Edit Network Interface Dialog 1. It will be awesome if under the Profile Field value, you can present a short summary of the profile in gray text. alternately, there can be a little info icon which will present this info on hover. This will help people who pick Gold know what that means vs silver or any other profile. Besides these specific feedback, I am wondering if any of the VM dialogs are affected by this? Will a VNIC profile field now show up on those dialogs as well? I see you have identified a bunch of open issues to work out and we will be more than happy to help you with the GUI for these flows as needed. Please feel free to reach out to Eldan and me and we can post back to the group with our work. Thanks Malini ----- Original Message ----- From: "Livnat Peer" To: "engine-devel" , "Ofri Masad" Sent: Sunday, June 30, 2013 8:59:37 AM Subject: [Engine-devel] VNIC profiles Hi, We are working on adding VNIC profiles as part of the work to add VNIC QoS. http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles We need to define some of the system behavior followed by this change, here is my take - Editing a profile - -------------------- A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id). Changing the network though is a bit more tricky as long as we don't have a way to distinguish between running and current configurations I think it could be very confusing to the user. Especially since we support dynamic wiring so the behavior IMO is unpredictable. I think it should be blocked at this point. Edit a VNIC / change a VNIC profile - ------------------------------------ Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running). Remove a Profile - ------------------- Is only valid if all VMs that are using this profile are in status down. It should update all VMs to point to no profile which should behave like none network today. I see no reason to support a profile on a none network at this point. The above is also relevant for upgrade flow (upgrading none network to point to no profile) Removing a Network - ---------------------- should remove all profiles on that network VM snapshot/import/export - -------------------------- We should handle VMs that are pointing to a network directly for b/w compatibility. we need to select first profile that is on that network that the user has permissions on. I assume there are more, comments are welcome Thanks, Livnat _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From wei.d.chen at intel.com Tue Jul 2 05:16:40 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Tue, 2 Jul 2013 05:16:40 +0000 Subject: [Engine-devel] unable to export or import template Message-ID: Hi, Export or import template seems not working in the ovirt environment built from latest ovirt source code. We tried several times but encountered with the some issue. Is there any workaround method to export or import template? reproduce the issue by follow steps: 1. create a VM (attach disk for this VM) 2. make template based on the VM 3. export the template (failed in this step) logs: 2013-07-02 13:13:20,073 INFO [org.ovirt.engine.core.bll.ExportVmTemplateCommand] (http--0.0.0.0-8080-1) [3c22672b] Lock Acquired to object EngineLock [exclusiveLocks= key: 6878fe52-5ec8-418f-b489-29cc42953153 value: REMOTE_TEMPLATE , sharedLocks= key: 6878fe52-5ec8-418f-b489-29cc42953153 value: TEMPLATE ] 2013-07-02 13:13:20,112 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageInfoVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] START, GetImageInfoVDSCommand( storagePoolId = 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false, compatabilityVersion = null, storageDomainId = 9494669b-6261-47aa-a520-c343c50ed982, imageGroupId = 4336fbfa-15db-4b29-82dc-2ba41926eefe, imageId = 6b267a89-d591-4e2c-92c5-07bc37068a12), log id: 63427705 2013-07-02 13:13:20,183 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageInfoVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] FINISH, GetImageInfoVDSCommand, return: org.ovirt.engine.core.common.businessentities.DiskImage at a6bee008, log id: 63427705 2013-07-02 13:13:20,184 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageDomainsListVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] START, GetImageDomainsListVDSCommand( storagePoolId = 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false, compatabilityVersion = null, imageGroupId = 4336fbfa-15db-4b29-82dc-2ba41926eefe), log id: 20941c2c 2013-07-02 13:13:20,189 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageDomainsListVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] Failed in GetImageDomainsListVDS method 2013-07-02 13:13:20,190 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageDomainsListVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] Error code unexpected and error message IRSGenericException: IRSErrorException: Failed to GetImageDomainsListVDS, error = Unexpected exception 2013-07-02 13:13:20,191 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (http--0.0.0.0-8080-1) [3c22672b] IrsBroker::Failed::GetImageDomainsListVDS due to: IRSErrorException: IRSGenericException: IRSErrorException: Failed to GetImageDomainsListVDS, error = Unexpected exception 2013-07-02 13:13:20,200 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStopVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] START, SpmStopVDSCommand(HostName = cubi, HostId = 3faed4b1-45e8-429e-88c4-9a3450f34bbd, storagePoolId = 5849b030-626e-47cb-ad90-3ce782d831b3), log id: 196b4e1b 2013-07-02 13:13:20,206 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStopVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] SpmStopVDSCommand::Stopping SPM on vds cubi, pool id 5849b030-626e-47cb-ad90-3ce782d831b3 2013-07-02 13:13:20,418 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStopVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] FINISH, SpmStopVDSCommand, log id: 196b4e1b 2013-07-02 13:13:20,418 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (http--0.0.0.0-8080-1) [3c22672b] Irs placed on server 3faed4b1-45e8-429e-88c4-9a3450f34bbd failed. Proceed Failover 2013-07-02 13:13:20,425 INFO [org.ovirt.engine.core.bll.storage.SetStoragePoolStatusCommand] (http--0.0.0.0-8080-1) [3c22672b] Running command: SetStoragePoolStatusCommand internal: true. Entities affected : ID: 5849b030-626e-47cb-ad90-3ce782d831b3 Type: StoragePool 2013-07-02 13:13:20,474 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (http--0.0.0.0-8080-1) [3c22672b] hostFromVds::selectedVds - onode, spmStatus Free, storage pool Default 2013-07-02 13:13:20,480 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (http--0.0.0.0-8080-1) [3c22672b] SPM Init: could not find reported vds or not up - pool:Default vds_spm_id: 1 2013-07-02 13:13:20,484 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (http--0.0.0.0-8080-1) [3c22672b] SPM selection - vds seems as spm cubi 2013-07-02 13:13:20,486 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStopVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] START, SpmStopVDSCommand(HostName = cubi, HostId = 3faed4b1-45e8-429e-88c4-9a3450f34bbd, storagePoolId = 5849b030-626e-47cb-ad90-3ce782d831b3), log id: 4fb2e437 2013-07-02 13:13:20,496 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] Command org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand return value TaskStatusListReturnForXmlRpc [mStatus=StatusForXmlRpc [mCode=654, mMessage=Not SPM]] 2013-07-02 13:13:20,499 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] HostName = cubi 2013-07-02 13:13:20,499 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] Command HSMGetAllTasksStatusesVDS execution failed. Exception: IRSNonOperationalException: IRSGenericException: IRSErrorException: IRSNonOperationalException: Not SPM 2013-07-02 13:13:20,501 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStopVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] SpmStopVDSCommand::Stopping SPM on vds cubi, pool id 5849b030-626e-47cb-ad90-3ce782d831b3 2013-07-02 13:13:20,511 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStopVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] FINISH, SpmStopVDSCommand, log id: 4fb2e437 2013-07-02 13:13:20,512 WARN [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (http--0.0.0.0-8080-1) [3c22672b] spm stop on spm failed, stopping spm selection! 2013-07-02 13:13:20,512 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.GetImageDomainsListVDSCommand] (http--0.0.0.0-8080-1) [3c22672b] FINISH, GetImageDomainsListVDSCommand, log id: 20941c2c 2013-07-02 13:13:20,513 ERROR [org.ovirt.engine.core.bll.ExportVmTemplateCommand] (http--0.0.0.0-8080-1) [3c22672b] Error during CanDoActionFailure.: org.ovirt.engine.core.common.errors.VdcBLLException: VdcBLLException: Cannot allocate IRS server (Failed with VDSM error IRS_REPOSITORY_NOT_FOUND and code 5009) at org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:125) [bll.jar:] at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.RunVdsCommand(VDSBrokerFront endImpl.java:33) [bll.jar:] at org.ovirt.engine.core.bll.MoveOrCopyTemplateCommand.checkIfDisksExist(MoveOr CopyTemplateCommand.java:208) [bll.jar:] at org.ovirt.engine.core.bll.MoveOrCopyTemplateCommand.canDoAction(MoveOrCopyTe mplateCommand.java:118) [bll.jar:] at org.ovirt.engine.core.bll.ExportVmTemplateCommand.canDoAction(ExportVmTempla teCommand.java:134) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.internalCanDoAction(CommandBase.java:6 81) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.canDoActionOnly(CommandBase.java:295) [bll.jar:] at org.ovirt.engine.core.bll.MultipleActionsRunner.Execute(MultipleActionsRunne r.java:75) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runMultipleActionsImpl(Backend.java:502) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runMultipleActionsImpl(Backend.java:517) [bll.jar:] at org.ovirt.engine.core.bll.Backend.RunMultipleActions(Backend.java:474) [bll.jar:] at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source) [:1.7.0_25] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:43) [rt.jar:1.7.0_25] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedRe ferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor Factory.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContex t.java:374) [jboss-invocation.jar:1.1.1.Final] at org.ovirt.engine.core.bll.interceptors.ThreadLocalSessionCleanerInterceptor. injectWebContextToThreadLocal(ThreadLocalSessionCleanerInterceptor.java:13) [bll.jar:] at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) [:1.7.0_25] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:43) [rt.jar:1.7.0_25] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenc eLifecycleMethodInterceptorFactory.java:123) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.j ava:53) [jboss-invocation.jar:1.1.1.Final] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvoc ation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor .java:21) [jboss-invocation.jar:1.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor .java:61) [jboss-invocation.jar:1.1.1.Final] at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.proces sInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationI nterceptor.processInvocation(SingletonComponentInstanceAssociationIntercepto r.java:53) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:211 ) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:363) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.jav a:194) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor .processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocatio n(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(Name spaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor. java:45) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor .java:61) [jboss-invocation.jar:1.1.1.Final] at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescriptio n.java:173) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation.jar:1.1.1.Final] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor .java:61) [jboss-invocation.jar:1.1.1.Final] at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandl er.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.ovirt.engine.core.common.interfaces.BackendLocal$$$view9.RunMultipleActi ons(Unknown Source) [common.jar:] at org.ovirt.engine.ui.frontend.server.gwt.GenericApiGWTServiceImpl.RunMultiple Actions(GenericApiGWTServiceImpl.java:112) at sun.reflect.GeneratedMethodAccessor163.invoke(Unknown Source) [:1.7.0_25] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:43) [rt.jar:1.7.0_25] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25] at com.google.gwt.rpc.server.RPC.invokeAndStreamResponse(RPC.java:196) at com.google.gwt.rpc.server.RpcServlet.processCall(RpcServlet.java:161) at com.google.gwt.rpc.server.RpcServlet.processPost(RpcServlet.java:222) at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractR emoteServiceServlet.java:62) at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-3.0-api.jar:1.0.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-3.0-api.jar:1.0.1.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:329) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:248) at org.ovirt.engine.ui.frontend.server.gwt.GwtCachingFilter.doFilter(GwtCaching Filter.java:132) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:248) at org.ovirt.engine.core.utils.servlet.LocaleFilter.doFilter(LocaleFilter.java: 59) [utils.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:280) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:248) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:275) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:161) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:489) at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityCon textAssociationValve.java:153) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155 ) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102 ) at org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http 11Protocol.java:671) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] 2013-07-02 13:13:20,541 INFO [org.ovirt.engine.core.bll.ExportVmTemplateCommand] (http--0.0.0.0-8080-1) [3c22672b] Lock freed to object EngineLock [exclusiveLocks= key: 6878fe52-5ec8-418f-b489-29cc42953153 value: REMOTE_TEMPLATE , sharedLocks= key: 6878fe52-5ec8-418f-b489-29cc42953153 value: TEMPLATE ] 2013-07-02 13:13:26,443 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (DefaultQuartzScheduler_Worker-48) hostFromVds::selectedVds - cubi, spmStatus Free, storage pool Default 2013-07-02 13:13:26,480 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (DefaultQuartzScheduler_Worker-48) starting spm on vds cubi, storage pool Default, prevId -1, LVER 18 2013-07-02 13:13:26,482 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-48) START, SpmStartVDSCommand(HostName = cubi, HostId = 3faed4b1-45e8-429e-88c4-9a3450f34bbd, storagePoolId = 5849b030-626e-47cb-ad90-3ce782d831b3, prevId=-1, prevLVER=18, storagePoolFormatType=V3, recoveryMode=Manual, SCSIFencing=false), log id: 7b405253 2013-07-02 13:13:26,494 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-48) spmStart polling started: taskId = dbd93116-1962-4f68-875c-c4e3afce29db 2013-07-02 13:13:27,502 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-48) spmStart polling ended: taskId = dbd93116-1962-4f68-875c-c4e3afce29db task status = finished 2013-07-02 13:13:27,510 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-48) spmStart polling ended, spm status: SPM 2013-07-02 13:13:27,512 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (DefaultQuartzScheduler_Worker-48) START, HSMClearTaskVDSCommand(HostName = cubi, HostId = 3faed4b1-45e8-429e-88c4-9a3450f34bbd, taskId=dbd93116-1962-4f68-875c-c4e3afce29db), log id: 2d49aa88 2013-07-02 13:13:27,520 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (DefaultQuartzScheduler_Worker-48) FINISH, HSMClearTaskVDSCommand, log id: 2d49aa88 2013-07-02 13:13:27,521 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-48) FINISH, SpmStartVDSCommand, return: org.ovirt.engine.core.common.businessentities.SpmStatusResult at 5901ca0e, log id: 7b405253 2013-07-02 13:13:27,546 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (DefaultQuartzScheduler_Worker-48) Initialize Irs proxy from vds: cubi.sh.intel.com 2013-07-02 13:13:27,569 INFO [org.ovirt.engine.core.bll.AsyncTaskManager] (pool-6-thread-46) Attempting to get and stop tasks on storage pool Default 2013-07-02 13:13:27,570 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMGetAllTasksInfoVDSCommand] (pool-6-thread-46) START, SPMGetAllTasksInfoVDSCommand( storagePoolId = 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false, compatabilityVersion = null), log id: 40eb5832 2013-07-02 13:13:27,680 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMGetAllTasksInfoVDSCommand] (pool-6-thread-46) -- SPMGetAllTasksInfoVDSCommand::ExecuteIrsBrokerCommand: Attempting on storage pool 5849b030-626e-47cb-ad90-3ce782d831b3 2013-07-02 13:13:27,682 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksInfoVDSCommand] (pool-6-thread-46) START, HSMGetAllTasksInfoVDSCommand(HostName = cubi, HostId = 3faed4b1-45e8-429e-88c4-9a3450f34bbd), log id: 21abca63 2013-07-02 13:13:27,690 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksInfoVDSCommand] (pool-6-thread-46) FINISH, HSMGetAllTasksInfoVDSCommand, return: [], log id: 21abca63 2013-07-02 13:13:27,691 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMGetAllTasksInfoVDSCommand] (pool-6-thread-46) FINISH, SPMGetAllTasksInfoVDSCommand, return: [], log id: 40eb5832 2013-07-02 13:13:27,692 INFO [org.ovirt.engine.core.bll.AsyncTaskManager] (pool-6-thread-46) Discovered no tasks on Storage Pool Default Any ideas? Best Regards, Dave Chen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6077 bytes Desc: not available URL: From kiril at redhat.com Tue Jul 2 05:27:43 2013 From: kiril at redhat.com (Kiril Nesenko) Date: Tue, 2 Jul 2013 01:27:43 -0400 (EDT) Subject: [Engine-devel] http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4555/ In-Reply-To: <1999410828.31594561.1372742761190.JavaMail.root@redhat.com> Message-ID: <1147396798.31594750.1372742863295.JavaMail.root@redhat.com> Hello, Seems like [1] brakes the job. Please fix. [1] Commit fd872108a581a1a81a548f6c267fe9465780639a by Frantisek Kobzik frontend: Make VNC implementation configurable from UI - Kiril From kiril at redhat.com Tue Jul 2 05:30:51 2013 From: kiril at redhat.com (Kiril Nesenko) Date: Tue, 2 Jul 2013 01:30:51 -0400 (EDT) Subject: [Engine-devel] http://jenkins.ovirt.org/job/ovirt_db_report_engine/120/console In-Reply-To: <488128163.31595398.1372743027001.JavaMail.root@redhat.com> Message-ID: <1276125193.31595462.1372743051020.JavaMail.root@redhat.com> Hello Eli, Can you take a look please why this job fails ? It fails on - Operation aborted, found duplicate version : 03030320 - Kiril From tjelinek at redhat.com Tue Jul 2 06:22:03 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Tue, 2 Jul 2013 02:22:03 -0400 (EDT) Subject: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST In-Reply-To: <828730502.10669676.1372684842052.JavaMail.root@redhat.com> References: <501973842.20255318.1371648804880.JavaMail.root@redhat.com> <20130627093010.GC13576@teriyaki.redhat.com> <2114201154.2496221.1372326631963.JavaMail.root@redhat.com> <2874260.9314218.1372348873189.JavaMail.root@redhat.com> <856039866.2941458.1372398071424.JavaMail.root@redhat.com> <1643373626.9902858.1372435276836.JavaMail.root@redhat.com> <1119844308.3674080.1372656560744.JavaMail.root@redhat.com> <828730502.10669676.1372684842052.JavaMail.root@redhat.com> Message-ID: <621284614.4294561.1372746123050.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Einav Cohen" > To: "Vojtech Szocs" , "Tomas Jelinek" > Cc: "engine-devel" > Sent: Monday, July 1, 2013 3:20:42 PM > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST > > > ----- Original Message ----- > > From: "Tomas Jelinek" > > Sent: Monday, July 1, 2013 1:29:20 AM > > > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Tomas Jelinek" , "Vojtech Szocs" > > > > > > Cc: "engine-devel" > > > Sent: Friday, June 28, 2013 6:01:16 PM > > > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST > > > > > > Hi Tomas, > > > > > > > IIUC the RFE addresses only UIPlugins with their metadata so > > > > in order to integrate this with the SPICE we nee to either > > > > enrich the RFE or to create a UIPlugin which will start the > > > > SPICE. I would vote for the second option. What others? > > > > > > using a ui-plugin that will start SPICE is an interesting approach - it > > > haven't crossed my mind. What I had in mind is to somewhat "generalize" > > > the > > > RestApiSessionManager to provide REST-API-session-creation services to > > > the > > > entire GUI (e.g. SPICE-console-opening-code), and not only to the > > > ui-plugins > > > in particular. > > > I think that since SPICE is already quite integrated into oVirt (in our > > > business > > > logic, dialogs, ...), it would be somewhat weird to use a UI-Plugin in > > > order > > > to > > > invoke SPICE, just in order to get the REST-API-session-creation > > > capability. > > > > > > So I am actually in favor of enriching the RFE (i.e. "generalize" the > > > RestApiSessionManager), rather than treating SPICE as a UI-Plugin (in a > > > sense). > > > > yes, you are right. > > > > > > > > > Why only for SPICE? I can imagine UIPlugins which could make use of > > > > this > > > > option. > > > > > > the main difference between SPICE and the UIPlugins is that we know in > > > advance > > > how SPICE is going to use REST API. > > > > This is not true anymore - SPICE can add whatever it wants to it's menu and > > webadmin/userportal > > has no control about it anymore (I'm talking about the non-plugin > > invocation > > of the SPICE). > > > > > In addition, SPICE is going to do actions > > > (e.g. > > > Stop/Pause/Attach CD) on the VM only when the user chooses to do so (via > > > the > > > SPICE menu), so actions will be done on behalf of the logged-in user, so > > > it > > > makes > > > sense to provide to SPICE the same credentials as the logged-in user. > > > > > > a ui-plugin is a third-party component which we don't know in advance how > > > it > > > is > > > going to act; moreover, the user that is logging into the web-admin > > > doesn't > > > have > > > control on it. Imagine a ui-plugin that shuts-down/deletes all VMs > > > immediately > > > upon login to the web-admin - all VMs will be shutdown/deleted upon the > > > first > > > login into the web-admin (after the ui-plugin installation on the engine > > > server). > > > If the same-credentials-approach will be used, the shutdown/deletion of > > > all > > > VMs > > > will be done on behalf of the user that happened to be the first one > > > logging > > > into > > > the web-admin (post ui-plugin installation), which, obviously, is not > > > good. > > > > Well, I did not mean to give this permission to all the plugins - all I > > wanted to > > say is to make this configurable per plugin. I can imagine > > also a well-known UI plugin which is trusted by the admin and it does make > > sense > > to make it use the same rights as the logged in user. > > I did not mean that each plugin has to have this permissions. > > > > > > > > So to sum-up: I think that > > > > > > - the RestApiSessionManager should be "generalized" to provide > > > REST-API-session- > > > creation services to the entire GUI (e.g. SPICE-console-opening-code), > > > and > > > not only > > > to the ui-plugins in particular. > > > > completely agree > > > > > > > > - RestApiSessionManager should support creation of both > > > same-credentials-session as > > > well as other-credentials-session; the same-credentials-session should be > > > limited to > > > well-known/well-integrated components (e.g. SPICE), whereas the > > > other-credentials-session > > > can be used by third-party components as well (e.g. ui-plugins). > > > > Who should decide about what is the well-known component? I would let the > > administrator to > > configure this. We can provide the defaults (e.g. the > > same-credentials-session will be disabled by > > default for ui-plugins but it will be possible to enabled it explicitly for > > some ui-plugins). > > +1 > having the same-credentials-session disabled by default for ui-plugins and > having > the admin explicitly enabling it per plugin where necessary makes perfect > sense. > > note that for SPICE, which is NOT a UI plugin, but is still a third-party > component > (but one that is well-integrated into ovirt), I think that we should use the > same- > credentials-session method by default (i.e. without the administrator > explicitly > allowing it). +1 > > > > > > > > > [I could be wrong - would love to hear what the others GUI maintainers > > > think] > > > > > > > > > > ----- Original Message ----- > > > > From: "Tomas Jelinek" > > > > Sent: Friday, June 28, 2013 1:41:11 AM > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Einav Cohen" > > > > > To: "Tomas Jelinek" , "Vojtech Szocs" > > > > > > > > > > Cc: "engine-devel" , "Michael Pasternak" > > > > > > > > > > Sent: Thursday, June 27, 2013 6:01:13 PM > > > > > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using > > > > > REST > > > > > > > > > > Hi Tomas, > > > > > > > > > > > Yes, we can provide the sessionId to authenticate with the REST and > > > > > > the > > > > > > vm > > > > > > guid is not a problem. > > > > > > > > > > Note that in the web-admin, we already have code that generates REST > > > > > API > > > > > session-ID; > > > > > this code is being utilized in the ui-plugins infrastructure to allow > > > > > the > > > > > different > > > > > ui-plugins to communicate with the rest api. > > > > > [one related file is this context is RestApiSessionManager.java in > > > > > the > > > > > web-admin, not > > > > > sure if there are others] > > > > > > > > Yes, I'm aware of that. This is what I had in mind when was talking > > > > about > > > > passing the SessionId to SPICE. > > > > > > > > > > > > > > maybe the RestApiSessionManager(?) can somehow be utilized for the > > > > > SPICE > > > > > purpose as well > > > > > (I guess that it will require a couple of code-changes though, and > > > > > maybe > > > > > worth moving it > > > > > to gwt-common, to allow its utilization from the user portal as > > > > > well?) > > > > > - > > > > > @Vojtech would > > > > > probably know best to advise on this. > > > > > > > > > > * Note: Today: > > > > > (a) a *single* REST API session-ID is generated and used across all > > > > > ui-plugins in the system > > > > > (upon user login to the web-admin). > > > > > > > > > > (b) this REST-API session-ID is generated based on the *same > > > > > credentials* > > > > > with which the user > > > > > logged into the web-admin. > > > > > > > > > > both (a) and (b) will change once [1] will be addressed. > > > > > > > > Thank you for mentioning this! I was not aware of this RFE. IIUC the > > > > RFE > > > > addresses only > > > > UIPlugins with their metadata so in order to integrate this with the > > > > SPICE > > > > we > > > > nee to either > > > > enrich the RFE or to create a UIPlugin which will start the SPICE. I > > > > would > > > > vote for the second option. > > > > What others? > > > > > > > > > Only for the SPICE case in particular - I think that (b) should > > > > > remain. > > > > > so > > > > > > > > Why only for SPICE? I can imagine UIPlugins which could make use of > > > > this > > > > option. > > > > > > > > > maybe worth allowing > > > > > both same-credentials-login and different-credentials-login in the > > > > > REST-API-Session-ID-generation > > > > > code in the GUI. > > > > > > > > This option might make sense also for other UIPlugins so maybe the > > > > SPICE > > > > integration will not be anything special, just a UIPlugin. > > > > > > > > > > > > > > ---- > > > > > Thanks, > > > > > Einav > > > > > > > > > > [1] Bug 962863 - RFE: Improve REST API integration for UI Plugins > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=962863 > > > > > some of the planned changes (from the BZ description): > > > > > """ > > > > > ... > > > > > - each UI plugin will have its own dedicated REST API session, > > > > > unrelated > > > > > to > > > > > GUI (admin) > > > > > user credentials > > > > > ... > > > > > """ > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Tomas Jelinek" > > > > > > Sent: Thursday, June 27, 2013 5:50:31 AM > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Christophe Fergeau" > > > > > > > To: "Tomas Jelinek" > > > > > > > Cc: "Michal Skrivanek" , "Itamar > > > > > > > Heim" > > > > > > > , > > > > > > > spice-devel at lists.freedesktop.org, "engine-devel" > > > > > > > , > > > > > > > "Marc-Andr? Lureau" > > > > > > > Sent: Thursday, June 27, 2013 11:30:10 AM > > > > > > > Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu > > > > > > > Using > > > > > > > REST > > > > > > > > > > > > > > Hey, > > > > > > > > > > > > > > On Thu, Jun 27, 2013 at 05:21:11AM -0400, Tomas Jelinek wrote: > > > > > > > > well, it seems that everyone agree that the decision what to > > > > > > > > add > > > > > > > > to > > > > > > > > the > > > > > > > > menu is the client responsibility. It means there is no > > > > > > > > additional > > > > > > > > work > > > > > > > > needed on the > > > > > > > > oVirt engine side - going to remove the feature page. > > > > > > > > > > > > > > If we go the REST API way to handle foreign menu, we need > > > > > > > additional > > > > > > > info > > > > > > > in the .vv files: some way to auth with the REST API, and the > > > > > > > guid > > > > > > > of > > > > > > > the > > > > > > > VM to act on. > > > > > > Yes, we can provide the sessionId to authenticate with the REST and > > > > > > the > > > > > > vm > > > > > > guid is not a problem. > > > > > > > > > > > > > > > > > > > > Christophe > > > > > > > > > > > > > _______________________________________________ > > > > > > Engine-devel mailing list > > > > > > Engine-devel at ovirt.org > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From lpeer at redhat.com Tue Jul 2 06:00:03 2013 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 02 Jul 2013 09:00:03 +0300 Subject: [Engine-devel] VNIC profiles In-Reply-To: <1014928995.103721546.1372702977041.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <1014928995.103721546.1372702977041.JavaMail.root@redhat.com> Message-ID: <51D26C63.8040004@redhat.com> On 07/01/2013 09:22 PM, Malini Rao wrote: > Hi Livnat, > > My name is Malini Rao and I am the lead interaction designer dedicated to RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan Hildeshiem who is also focused on RHEV UX. Hi Malini - nice to e-meet you :) > I went over your feature page and in general, the GUI proposals look great. I do have some quick feedback comments - Just a small credit correction - the feature page is Ofri's feature page, I added some feedback of my own :) > > Will there be any predefined profiles available to the users out of the box in RHEV? Or will they have to define their own? If you start with a clean install setup there are no predefined vNICs profiles. Profiles can be generated in two flows, a user can explicitly generate a profile or when admin network creates a new network he can mark create a profile for this network** in a single action. A VNIC profile is the link between the abstract network entity and the VM which consumes this network. If you upgrade existing setup, in the upgrade process profiles will be created per network and will be attached to the VNICs that are currently using the network. **This is not accurate, the user would be able to check all relevant VNIC-QoS-entities and for each one we need to create a profile. > I am wondering if there are any common standard QoS levels that can be predefined and the users can get a heeadstart and use or tweak instead of defining from scratch. That's a very good point. The wiki page is not fully up to date, I think. Ofri wanted to add an entity of VNIC QoS which would be linked from within the VNIC profile. The VNIC QoS entity is located in the entities hierarchy under Data Center. The point you made, I think, is will we have predefined VNIC QoS entities. The Qos entity is tight to the hardware you have in your DC. If you have 10G or 1G Ethernet links the QoS entities would look very different, so I'm not sure what predefined values would look like. > > VNIC level QoS dialog > > 1. Will the Outbound and inbound values come with some defaults? Or will they be empty? Is there a need for any spinners or drop downs for frequently used values or is it ok to just have fields to type in the numeric values? Also I am assuming there is some kind of validation to ensure only numbers an be entered in these fields. > > 2. For custom properties, why do we have a drop down? Can custom properties defined elsewhere be accessed here and applied? If not, then I am assuming this will have to be a text field. Correct? Also, I am guessing if there is only one custom property field, the [-] icon will be disabled. > > Edit Network Interface Dialog > 1. It will be awesome if under the Profile Field value, you can present a short summary of the profile in gray text. alternately, there can be a little info icon which will present this info on hover. This will help people who pick Gold know what that means vs silver or any other profile. > > Besides these specific feedback, I am wondering if any of the VM dialogs are affected by this? Will a VNIC profile field now show up on those dialogs as well? > > I see you have identified a bunch of open issues to work out and we will be more than happy to help you with the GUI for these flows as needed. Please feel free to reach out to Eldan and me and we can post back to the group with our work. > Thank you Malini for the above feedback, I think these are good questions. Ofri - can you comment on the above ? Livnat > Thanks > Malini > > > > > ----- Original Message ----- > From: "Livnat Peer" > To: "engine-devel" , "Ofri Masad" > Sent: Sunday, June 30, 2013 8:59:37 AM > Subject: [Engine-devel] VNIC profiles > > Hi, > > We are working on adding VNIC profiles as part of the work to add VNIC QoS. > > http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles > > We need to define some of the system behavior followed by this change, > here is my take - > > Editing a profile - > -------------------- > A user should be able to edit the profile properties (including profile > name) while VMs are attached and are using this Profile (reference > should be done by id). > > Changing the network though is a bit more tricky as long as we don't > have a way to distinguish between running and current configurations I > think it could be very confusing to the user. Especially since we > support dynamic wiring so the behavior IMO is unpredictable. > I think it should be blocked at this point. > > > Edit a VNIC / change a VNIC profile - > ------------------------------------ > Changing the profile a VM is using while the VM is running should behave > like dynamic wiring (changing the VM network while it is running). > > > Remove a Profile - > ------------------- > Is only valid if all VMs that are using this profile are in status down. > It should update all VMs to point to no profile which should behave like > none network today. > > I see no reason to support a profile on a none network at this point. > > The above is also relevant for upgrade flow (upgrading none network to > point to no profile) > > > Removing a Network - > ---------------------- > should remove all profiles on that network > > > VM snapshot/import/export - > -------------------------- > We should handle VMs that are pointing to a network directly for b/w > compatibility. > we need to select first profile that is on that network that the user > has permissions on. > > > I assume there are more, comments are welcome > > Thanks, Livnat > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From fkobzik at redhat.com Tue Jul 2 07:04:37 2013 From: fkobzik at redhat.com (Frantisek Kobzik) Date: Tue, 2 Jul 2013 03:04:37 -0400 (EDT) Subject: [Engine-devel] http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4555/ In-Reply-To: <1147396798.31594750.1372742863295.JavaMail.root@redhat.com> References: <1147396798.31594750.1372742863295.JavaMail.root@redhat.com> Message-ID: <1366452668.31771680.1372748677182.JavaMail.root@redhat.com> Hi, sorry for that, should be fixed now. Thanks, F. ----- Original Message ----- From: "Kiril Nesenko" To: "Frantisek Kobzik" Cc: engine-devel at ovirt.org, "Eyal Edri" Sent: Tuesday, July 2, 2013 7:27:43 AM Subject: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4555/ Hello, Seems like [1] brakes the job. Please fix. [1] Commit fd872108a581a1a81a548f6c267fe9465780639a by Frantisek Kobzik frontend: Make VNC implementation configurable from UI - Kiril From rgolan at redhat.com Tue Jul 2 07:14:21 2013 From: rgolan at redhat.com (Roy Golan) Date: Tue, 02 Jul 2013 10:14:21 +0300 Subject: [Engine-devel] [ANN] VM's OS info in ovirt engine Message-ID: <51D27DCD.3000407@redhat.com> Hi all, Recently I merged the os info [1] patches. Its main responsibility is to make our OS-bounded configuration file-based rather than combination of hard-coded enum (VmOsType) and db config values. What is there to configure? * available OS types - what you see in the drop-down selection for the os e.g os.RHEL6.name = Red Hat Enterprise Linux 6 * recommended min/max memory per os os.Unassigned.resources.maximum.ram.value = 64000 * supported network devices - this will actually set the drop-down of nic types in new Interface dialog os.Windows7.devices.network.value = rtl8139_pv, rtl8139, e1000, pv * compat version values os.Fedora12.devices.audio.value = ich6 os.Fedora12.devices.audio.value.3.2 = ac97 * inheritance - DRY :) os.RHEL5.derivedFrom.value = RHEL4 os.RHEL4.family = linux * cpu Arch - currently we support only x86 but this will come handy for supporting powerPC arch or arm etc after cross-matching with the cluster arch. os.Other.cpuArchetecture.value = x86 The file is located at /etc/ovirt-engine/osinfo.conf.d/00-osinfo-defaults.properties and is symlinked to /usr/share/ovirt-engine/conf/osinfo-defaults.properties If you want to overide the values or just add your setup more OSs just add 10-osinfo.properties under osinfo.conf.d Bare in mind, If you ever have to add logic against OSs pls don't add it to vdc_options. Use the osinfo instead. Cleanups from ConfigValues and vdc_options will soon follow as well as treatment for custom icon images for OSs. Thanks, Roy [1] http://www.ovirt.org/OS_info From emesika at redhat.com Tue Jul 2 08:44:34 2013 From: emesika at redhat.com (Eli Mesika) Date: Tue, 2 Jul 2013 04:44:34 -0400 (EDT) Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <51D1528E.5050908@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <1625820710.4175423.1372344929287.JavaMail.root@redhat.com> <687362379.9364944.1372354295556.JavaMail.root@redhat.com> <2036896830.10266657.1372610122917.JavaMail.root@redhat.com> <51D11BE0.6000809@redhat.com> <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> <429008692.30913072.1372667257807.JavaMail.root@redhat.com> <51D1528E.5050908@redhat.com> Message-ID: <230315749.1320462.1372754674527.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Livnat Peer" > To: "Yair Zaslavsky" > Cc: engine-devel at ovirt.org > Sent: Monday, July 1, 2013 12:57:34 PM > Subject: Re: [Engine-devel] SSH Soft Fencing > > On 07/01/2013 11:27 AM, Yair Zaslavsky wrote: > > > > > > ----- Original Message ----- > >> From: "Martin Perina" > >> To: engine-devel at ovirt.org > >> Sent: Monday, July 1, 2013 11:23:12 AM > >> Subject: Re: [Engine-devel] SSH Soft Fencing > >> > >> So let me summarize it: > >> > >> We have come to agreement in those questions: > >> > >> 1) SSH Soft Fencing logic should be extracted from > >> VdsNotRespondingTreatment > >> command to its own SshSoftFencingCommand > >> > >> 2) VdsNotRespondingCommand should be refactored so it's not inherited from > >> VdsRestartCommand, but it should run SshSoftFencingCommand > >> or VdsRestartCommand based on defined fencing flow > >> > >> > >> These questions has not been resolved yet: > >> > >> 3) Should SSH Soft Fencing be executed also for hosts without PM > >> configured? > >> > >> 4) Should SSH Soft Fencing execution for hosts without PM configured be > >> enabled > >> by default and admin can turn off these feature using configuration > >> options > >> SshSoftFencingWithoutPmEnabled (or something like that)? > >> > >> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster > >> wide > >> option (can be turned off for specific cluster version) or a VDS option > >> (it can be turned off for each host)? > >> > >> > >> Personally I would suggest: > >> > >> ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM > >> configured > >> > > > +1 > > >> ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be > >> enabled by default > >> > > +1 > > >> ad 5) I don't see any significant reason why someone would like to turn > >> off > >> SSH Soft Fencing > >> for hosts without PM configured. But if someone would like to do > >> that, > >> I think > >> he would like to turn it off only for specific hosts, so VDS level > >> option makes sense > >> for me > > > > After re-thinking 5 - I agree. > > +1 on the other suggestions, but of course we need to get more consensus > > here. > > > > I think it does not need to be configurable. +1 on all above as well > > >> > >> > >> Martin > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From eedri at redhat.com Tue Jul 2 13:41:35 2013 From: eedri at redhat.com (Eyal Edri) Date: Tue, 2 Jul 2013 09:41:35 -0400 (EDT) Subject: [Engine-devel] [JENKINS][ANN] disabling jenkins gerrit job for findbugs In-Reply-To: <1373211990.2589597.1372772322233.JavaMail.root@redhat.com> Message-ID: <1828484724.2592045.1372772495179.JavaMail.root@redhat.com> fyi, due to multiple errors lately with the jenkins jobs that runs per patch on gerrit patches for engine, infra team has disabled the job for now and enabled a basic compilation job instead. [1] this is caused by a slow jenkins slave that doesn't have the capacity to handle the load of patches. we're working hard on adding new and powerful jenkins slaves soon and hopefully by next week we can start using them. for now, if you have a patch that has -1 from the 'gerrit findbugs' job you can: 1. contact gerrit admin (dcaro) to remove the jenkins user from that patch 2. if you'll send a new patchset, it will be removed automaticly. 3. contact infra at ovirt.org if need help/info sorry for the noise, hopefully we'll be able to enable it back soon with newer infra. Eyal. oVirt infra team. [1] http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_sanity_compile_checkstyle_gerrit/ From wei.d.chen at intel.com Wed Jul 3 03:01:33 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Wed, 3 Jul 2013 03:01:33 +0000 Subject: [Engine-devel] conflict detected in LocalizedEnums.properties Message-ID: Found confliction in LocalizedEnums.properties, someone may want to take care of it. code path: frontend/webadmin/modules/uicompat/src/main/resources/org/ovirt/engine/ui/ui compat/LocalizedEnums.properties 292 <<<<<<< HEAD 293 VdcActionType___RefreshGlusterHook=Refresh Gluster Hook 294 ======= 295 VdcActionType___ManageGlusterService=Manage Service 296 >>>>>>> gluster: bll command to start/stop/restart service Best Regards, Dave Chen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6077 bytes Desc: not available URL: From shtripat at redhat.com Wed Jul 3 03:15:01 2013 From: shtripat at redhat.com (Shubhendu Tripathi) Date: Wed, 03 Jul 2013 08:45:01 +0530 Subject: [Engine-devel] conflict detected in LocalizedEnums.properties In-Reply-To: References: Message-ID: <51D39735.902@redhat.com> Hi Chen, I have raised the patch http://gerrit.ovirt.org/#/c/16364/ to correct the same. Thanks and Regards, Shubhendu Tripathi On 07/03/2013 08:31 AM, Chen, Wei D wrote: > Found confliction in LocalizedEnums.properties, someone may want to take > care of it. > > code path: > frontend/webadmin/modules/uicompat/src/main/resources/org/ovirt/engine/ui/ui > compat/LocalizedEnums.properties > > 292 <<<<<<< HEAD > 293 VdcActionType___RefreshGlusterHook=Refresh Gluster Hook > 294 ======= > 295 VdcActionType___ManageGlusterService=Manage Service > 296 >>>>>>> gluster: bll command to start/stop/restart service > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: shtripat.vcf Type: text/x-vcard Size: 138 bytes Desc: not available URL: From gang.wei at intel.com Wed Jul 3 05:59:51 2013 From: gang.wei at intel.com (Wei, Gang) Date: Wed, 3 Jul 2013 05:59:51 +0000 Subject: [Engine-devel] engine-setup-2 failed while Updating database schema Message-ID: Based on master commit e66de882722d0af33d936d72a5df680be908a97d, when I try to build and deploy dev env according to http://www.ovirt.org/OVirt_Engine_Development_Environment, bin/engine-setup-2 will always fail while updating database schema: [ INFO ] Backing up database to '/home/jimmy/ovirt-engine/var/lib/ovirt-engine/backups/engine-20130703133814 .uqYcj3.sql'. [ INFO ] Updating database schema [WARNING] Rolling back upgrade [ ERROR ] Failed to execute stage 'Misc configuration': Command '/home/jimmy/ovirt-engine/share/ovirt-engine/dbscripts/upgrade.sh' failed to execute [ INFO ] Stage: Clean up Log file is located at /tmp/ovirt-engine-setup-20130703133726.log Log file is attached. How can we fix it? Is there a known working recent commit in master I can try to build dev env based on it? Thanks Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-engine-setup-20130703133726.log Type: application/octet-stream Size: 320734 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 8586 bytes Desc: not available URL: From gang.wei at intel.com Wed Jul 3 06:48:12 2013 From: gang.wei at intel.com (Wei, Gang) Date: Wed, 3 Jul 2013 06:48:12 +0000 Subject: [Engine-devel] engine-setup-2 failed while Updating database schema In-Reply-To: References: Message-ID: Finally found it is caused by staled file under share/ovirt-engine/dbscripts/upgrade folder. Jimmy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 8586 bytes Desc: not available URL: From wei.d.chen at intel.com Wed Jul 3 08:54:12 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Wed, 3 Jul 2013 08:54:12 +0000 Subject: [Engine-devel] fail to setup engine Message-ID: Hi, We cannot setup engine based on today's source code, any ideas? $HOME/ovirt-engine/bin/engine-setup-2 [ ERROR ] Failed to execute stage 'Booting': 5 [ INFO ] Stage: Initializing Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: Yes [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. Specifically, engine-setup-2 does not support upgrade from previous installations. Best Regards, Dave Chen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6077 bytes Desc: not available URL: From sbonazzo at redhat.com Wed Jul 3 08:57:50 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Wed, 03 Jul 2013 10:57:50 +0200 Subject: [Engine-devel] fail to setup engine In-Reply-To: References: Message-ID: <51D3E78E.70607@redhat.com> Il 03/07/2013 10:54, Chen, Wei D ha scritto: > Hi, > > We cannot setup engine based on today's source code, any ideas? > > > $HOME/ovirt-engine/bin/engine-setup-2 > [ ERROR ] Failed to execute stage 'Booting': 5 > [ INFO ] Stage: Initializing > Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: > Yes > [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. > Specifically, engine-setup-2 does not support upgrade from previous installations. > > Best Regards, > Dave Chen > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel Can you attach the log file? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wei.d.chen at intel.com Wed Jul 3 08:59:40 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Wed, 3 Jul 2013 08:59:40 +0000 Subject: [Engine-devel] fail to setup engine In-Reply-To: <51D3E78E.70607@redhat.com> References: <51D3E78E.70607@redhat.com> Message-ID: where is the log file? engine.log and server.log have not created yet. Best Regards, Dave Chen From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] Sent: Wednesday, July 03, 2013 4:58 PM To: Chen, Wei D Cc: engine-devel; Zhang, Lijuan; Liu, DanqingX Subject: Re: [Engine-devel] fail to setup engine Il 03/07/2013 10:54, Chen, Wei D ha scritto: Hi, We cannot setup engine based on today's source code, any ideas? $HOME/ovirt-engine/bin/engine-setup-2 [ ERROR ] Failed to execute stage 'Booting': 5 [ INFO ] Stage: Initializing Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: Yes [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. Specifically, engine-setup-2 does not support upgrade from previous installations. Best Regards, Dave Chen _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Can you attach the log file? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6077 bytes Desc: not available URL: From sbonazzo at redhat.com Wed Jul 3 09:07:41 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Wed, 03 Jul 2013 11:07:41 +0200 Subject: [Engine-devel] fail to setup engine In-Reply-To: References: <51D3E78E.70607@redhat.com> Message-ID: <51D3E9DD.3070904@redhat.com> If the setup log is not created (it's usually in tmp directory) can you attach the output of OTOPI_DEBUG=1 $HOME/ovirt-engine/bin/engine-setup-2 ? Il 03/07/2013 10:59, Chen, Wei D ha scritto: > where is the log file? engine.log and server.log have not created yet. > > > > > > Best Regards, > > Dave Chen > > > > From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] > Sent: Wednesday, July 03, 2013 4:58 PM > To: Chen, Wei D > Cc: engine-devel; Zhang, Lijuan; Liu, DanqingX > Subject: Re: [Engine-devel] fail to setup engine > > > > Il 03/07/2013 10:54, Chen, Wei D ha scritto: > > Hi, > > We cannot setup engine based on today's source code, any ideas? > > > $HOME/ovirt-engine/bin/engine-setup-2 > [ ERROR ] Failed to execute stage 'Booting': 5 > [ INFO ] Stage: Initializing > Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: > Yes > [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. > Specifically, engine-setup-2 does not support upgrade from previous installations. > > Best Regards, > Dave Chen > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > Can you attach the log file? > > > > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From sbonazzo at redhat.com Wed Jul 3 09:39:02 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Wed, 03 Jul 2013 11:39:02 +0200 Subject: [Engine-devel] fail to setup engine In-Reply-To: <32933DF08985CE44BE5477C232AF07370268DFBA@SHSMSX104.ccr.corp.intel.com> References: <51D3E78E.70607@redhat.com> <51D3E9DD.3070904@redhat.com> <32933DF08985CE44BE5477C232AF07370268DFBA@SHSMSX104.ccr.corp.intel.com> Message-ID: <51D3F136.5040202@redhat.com> > Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: No You aborted the setup answering no. Il 03/07/2013 11:23, Liu, DanqingX ha scritto: > This attachment is the log > > -----Original Message----- > From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] > Sent: Wednesday, July 03, 2013 5:08 PM > To: Chen, Wei D > Cc: engine-devel; Zhang, Lijuan; Liu, DanqingX > Subject: Re: [Engine-devel] fail to setup engine > > If the setup log is not created (it's usually in tmp directory) can you attach the output of > > OTOPI_DEBUG=1 $HOME/ovirt-engine/bin/engine-setup-2 ? > > > Il 03/07/2013 10:59, Chen, Wei D ha scritto: >> where is the log file? engine.log and server.log have not created yet. >> >> >> >> >> >> Best Regards, >> >> Dave Chen >> >> >> >> From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] >> Sent: Wednesday, July 03, 2013 4:58 PM >> To: Chen, Wei D >> Cc: engine-devel; Zhang, Lijuan; Liu, DanqingX >> Subject: Re: [Engine-devel] fail to setup engine >> >> >> >> Il 03/07/2013 10:54, Chen, Wei D ha scritto: >> >> Hi, >> >> We cannot setup engine based on today's source code, any ideas? >> >> >> $HOME/ovirt-engine/bin/engine-setup-2 >> [ ERROR ] Failed to execute stage 'Booting': 5 [ INFO ] Stage: >> Initializing >> Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: >> Yes >> [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. >> Specifically, engine-setup-2 does not support upgrade from previous installations. >> >> Best Regards, >> Dave Chen >> >> >> >> >> >> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> >> >> Can you attach the log file? >> >> >> >> > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From wei.d.chen at intel.com Wed Jul 3 09:49:00 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Wed, 3 Jul 2013 09:49:00 +0000 Subject: [Engine-devel] fail to setup engine In-Reply-To: <51D3F136.5040202@redhat.com> References: <51D3E78E.70607@redhat.com> <51D3E9DD.3070904@redhat.com> <32933DF08985CE44BE5477C232AF07370268DFBA@SHSMSX104.ccr.corp.intel.com> <51D3F136.5040202@redhat.com> Message-ID: I have not performed this operation. We have tried to setup both on fedora 18 and fedora 19, fedora 18 failed to setup while fedora 19 can setup successfully. Best Regards, Dave Chen > -----Original Message----- > From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] > Sent: Wednesday, July 03, 2013 5:39 PM > To: Liu, DanqingX > Cc: Chen, Wei D; engine-devel; Zhang, Lijuan > Subject: Re: [Engine-devel] fail to setup engine > > > Setup was run under unprivileged user this will produce development > installation do you wish to proceed? (Yes, No) [No]: No > > You aborted the setup answering no. > > > > > > Il 03/07/2013 11:23, Liu, DanqingX ha scritto: > > This attachment is the log > > > > -----Original Message----- > > From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] > > Sent: Wednesday, July 03, 2013 5:08 PM > > To: Chen, Wei D > > Cc: engine-devel; Zhang, Lijuan; Liu, DanqingX > > Subject: Re: [Engine-devel] fail to setup engine > > > > If the setup log is not created (it's usually in tmp directory) can you attach the output of > > > > OTOPI_DEBUG=1 $HOME/ovirt-engine/bin/engine-setup-2 ? > > > > > > Il 03/07/2013 10:59, Chen, Wei D ha scritto: > >> where is the log file? engine.log and server.log have not created yet. > >> > >> > >> > >> > >> > >> Best Regards, > >> > >> Dave Chen > >> > >> > >> > >> From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] > >> Sent: Wednesday, July 03, 2013 4:58 PM > >> To: Chen, Wei D > >> Cc: engine-devel; Zhang, Lijuan; Liu, DanqingX > >> Subject: Re: [Engine-devel] fail to setup engine > >> > >> > >> > >> Il 03/07/2013 10:54, Chen, Wei D ha scritto: > >> > >> Hi, > >> > >> We cannot setup engine based on today's source code, any ideas? > >> > >> > >> $HOME/ovirt-engine/bin/engine-setup-2 > >> [ ERROR ] Failed to execute stage 'Booting': 5 [ INFO ] Stage: > >> Initializing > >> Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: > >> Yes > >> [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. > >> Specifically, engine-setup-2 does not support upgrade from previous installations. > >> > >> Best Regards, > >> Dave Chen > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel at ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > >> > >> Can you attach the log file? > >> > >> > >> > >> > > > > -- > > Sandro Bonazzola > > Better technology. Faster innovation. Powered by community collaboration. > > See how it works at redhat.com > > > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: engine-setup.log Type: application/octet-stream Size: 14933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6077 bytes Desc: not available URL: From sbonazzo at redhat.com Wed Jul 3 09:56:27 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Wed, 03 Jul 2013 11:56:27 +0200 Subject: [Engine-devel] fail to setup engine In-Reply-To: References: <51D3E78E.70607@redhat.com> <51D3E9DD.3070904@redhat.com> <32933DF08985CE44BE5477C232AF07370268DFBA@SHSMSX104.ccr.corp.intel.com> <51D3F136.5040202@redhat.com> Message-ID: <51D3F54B.3000406@redhat.com> I can't reproduce your issue with e9ef0ce577d76ab08b21ae5a11791551d69e0fab without hitting enter (accepting default No) or answering explicitly No to the question. For installing the dev env the answer here has to be Yes. The question is asked when running as unprivileged user and not asked when running as root. Il 03/07/2013 11:49, Chen, Wei D ha scritto: > I have not performed this operation. > We have tried to setup both on fedora 18 and fedora 19, fedora 18 failed to setup while fedora 19 can setup successfully. > > > Best Regards, > Dave Chen > > >> -----Original Message----- >> From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] >> Sent: Wednesday, July 03, 2013 5:39 PM >> To: Liu, DanqingX >> Cc: Chen, Wei D; engine-devel; Zhang, Lijuan >> Subject: Re: [Engine-devel] fail to setup engine >> >>> Setup was run under unprivileged user this will produce development >> installation do you wish to proceed? (Yes, No) [No]: No >> >> You aborted the setup answering no. >> >> >> >> >> >> Il 03/07/2013 11:23, Liu, DanqingX ha scritto: >>> This attachment is the log >>> >>> -----Original Message----- >>> From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] >>> Sent: Wednesday, July 03, 2013 5:08 PM >>> To: Chen, Wei D >>> Cc: engine-devel; Zhang, Lijuan; Liu, DanqingX >>> Subject: Re: [Engine-devel] fail to setup engine >>> >>> If the setup log is not created (it's usually in tmp directory) can you attach the output of >>> >>> OTOPI_DEBUG=1 $HOME/ovirt-engine/bin/engine-setup-2 ? >>> >>> >>> Il 03/07/2013 10:59, Chen, Wei D ha scritto: >>>> where is the log file? engine.log and server.log have not created yet. >>>> >>>> >>>> >>>> >>>> >>>> Best Regards, >>>> >>>> Dave Chen >>>> >>>> >>>> >>>> From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] >>>> Sent: Wednesday, July 03, 2013 4:58 PM >>>> To: Chen, Wei D >>>> Cc: engine-devel; Zhang, Lijuan; Liu, DanqingX >>>> Subject: Re: [Engine-devel] fail to setup engine >>>> >>>> >>>> >>>> Il 03/07/2013 10:54, Chen, Wei D ha scritto: >>>> >>>> Hi, >>>> >>>> We cannot setup engine based on today's source code, any ideas? >>>> >>>> >>>> $HOME/ovirt-engine/bin/engine-setup-2 >>>> [ ERROR ] Failed to execute stage 'Booting': 5 [ INFO ] Stage: >>>> Initializing >>>> Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) > [No]: >>>> Yes >>>> [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. >>>> Specifically, engine-setup-2 does not support upgrade from previous installations. >>>> >>>> Best Regards, >>>> Dave Chen >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>>> >>>> Can you attach the log file? >>>> >>>> >>>> >>>> >>> -- >>> Sandro Bonazzola >>> Better technology. Faster innovation. Powered by community collaboration. >>> See how it works at redhat.com >>> >> >> -- >> Sandro Bonazzola >> Better technology. Faster innovation. Powered by community collaboration. >> See how it works at redhat.com -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From michal.skrivanek at redhat.com Wed Jul 3 10:03:13 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Wed, 3 Jul 2013 12:03:13 +0200 Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <230315749.1320462.1372754674527.JavaMail.root@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <1625820710.4175423.1372344929287.JavaMail.root@redhat.com> <687362379.9364944.1372354295556.JavaMail.root@redhat.com> <2036896830.10266657.1372610122917.JavaMail.root@redhat.com> <51D11BE0.6000809@redhat.com> <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> <429008692.30913072.1372667257807.JavaMail.root@redhat.com> <51D1528E.5050908@redhat.com> <230315749.1320462.1372754674527.JavaMail.root@redhat.com> Message-ID: <762BDFC8-7094-4C84-9EF3-DEBA88A06336@redhat.com> On Jul 2, 2013, at 10:44 , Eli Mesika wrote: > > > ----- Original Message ----- >> From: "Livnat Peer" >> To: "Yair Zaslavsky" >> Cc: engine-devel at ovirt.org >> Sent: Monday, July 1, 2013 12:57:34 PM >> Subject: Re: [Engine-devel] SSH Soft Fencing >> >> On 07/01/2013 11:27 AM, Yair Zaslavsky wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Martin Perina" >>>> To: engine-devel at ovirt.org >>>> Sent: Monday, July 1, 2013 11:23:12 AM >>>> Subject: Re: [Engine-devel] SSH Soft Fencing >>>> >>>> So let me summarize it: >>>> >>>> We have come to agreement in those questions: >>>> >>>> 1) SSH Soft Fencing logic should be extracted from >>>> VdsNotRespondingTreatment >>>> command to its own SshSoftFencingCommand >>>> >>>> 2) VdsNotRespondingCommand should be refactored so it's not inherited from >>>> VdsRestartCommand, but it should run SshSoftFencingCommand >>>> or VdsRestartCommand based on defined fencing flow >>>> >>>> >>>> These questions has not been resolved yet: >>>> >>>> 3) Should SSH Soft Fencing be executed also for hosts without PM >>>> configured? >>>> >>>> 4) Should SSH Soft Fencing execution for hosts without PM configured be >>>> enabled >>>> by default and admin can turn off these feature using configuration >>>> options >>>> SshSoftFencingWithoutPmEnabled (or something like that)? >>>> >>>> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster >>>> wide >>>> option (can be turned off for specific cluster version) or a VDS option >>>> (it can be turned off for each host)? >>>> >>>> >>>> Personally I would suggest: >>>> >>>> ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM >>>> configured >>>> >> >> >> +1 >> >>>> ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be >>>> enabled by default >>>> >> >> +1 >> >>>> ad 5) I don't see any significant reason why someone would like to turn >>>> off >>>> SSH Soft Fencing >>>> for hosts without PM configured. But if someone would like to do >>>> that, >>>> I think >>>> he would like to turn it off only for specific hosts, so VDS level >>>> option makes sense >>>> for me >>> >>> After re-thinking 5 - I agree. >>> +1 on the other suggestions, but of course we need to get more consensus >>> here. >>> >> >> I think it does not need to be configurable. I think a configuration option, as cumbersome and confusing as it can be, is still better than no choice. Especially if it means to restore the previous behavior. If it only can happen in a theoretical problem at customer where vdsm restart cause issues for whatever theoretical reason?.it would be of great help then. And if you don't understand the parameter - just don't touch it, I hope that's a general rule:-) > > > +1 on all above as well > >> >>>> >>>> >>>> Martin >>>> _______________________________________________ >>>> 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 liran.zelkha at gmail.com Wed Jul 3 10:08:08 2013 From: liran.zelkha at gmail.com (Liran Zelkha) Date: Wed, 3 Jul 2013 13:08:08 +0300 Subject: [Engine-devel] BatchUpdates and VdsUpdateRuntimeInfo Message-ID: <5AC1CD58-AC29-4C29-BE06-F03364135AEA@gmail.com> Hi all, Batch updates are now merged, so please start using it. As usage example, please check VdsUpdateRuntimeInfo code. Attached doc shows performance benefits from using batch over regular update. -------------- next part -------------- A non-text attachment was scrubbed... Name: Batch Updates in VdsUpdateRuntimeInfo.pdf Type: application/pdf Size: 49548 bytes Desc: not available URL: From bazulay at redhat.com Wed Jul 3 11:15:51 2013 From: bazulay at redhat.com (Barak Azulay) Date: Wed, 3 Jul 2013 07:15:51 -0400 (EDT) Subject: [Engine-devel] BatchUpdates and VdsUpdateRuntimeInfo In-Reply-To: <5AC1CD58-AC29-4C29-BE06-F03364135AEA@gmail.com> References: <5AC1CD58-AC29-4C29-BE06-F03364135AEA@gmail.com> Message-ID: <953568559.12426558.1372850151135.JavaMail.root@redhat.com> Liran, It is worth mentioning the environment and duration these measurements were taken. Thanks Barak Azulay ----- Original Message ----- > From: "Liran Zelkha" > To: "engine-devel" > Cc: "Itamar Heim" , "Barak Azulay" , "Allon Mureinik" > Sent: Wednesday, July 3, 2013 1:08:08 PM > Subject: BatchUpdates and VdsUpdateRuntimeInfo > > Hi all, > > Batch updates are now merged, so please start using it. As usage example, > please check VdsUpdateRuntimeInfo code. Attached doc shows performance > benefits from using batch over regular update. From mskrivan at redhat.com Wed Jul 3 11:45:03 2013 From: mskrivan at redhat.com (Michal Skrivanek) Date: Wed, 3 Jul 2013 07:45:03 -0400 (EDT) Subject: [Engine-devel] [rhevm-staff] Fwd: BatchUpdates and VdsUpdateRuntimeInfo In-Reply-To: <266544720.12425080.1372849991817.JavaMail.root@redhat.com> References: <5AC1CD58-AC29-4C29-BE06-F03364135AEA@gmail.com> <266544720.12425080.1372849991817.JavaMail.root@redhat.com> Message-ID: <1A7F0BF8-2C46-48E3-B1BE-B311A5BEEBEA@redhat.com> > > ----- Forwarded Message ----- >> From: "Liran Zelkha" >> To: "engine-devel" >> Cc: "Itamar Heim" , "Barak Azulay" , "Allon Mureinik" >> Sent: Wednesday, July 3, 2013 1:08:08 PM >> Subject: BatchUpdates and VdsUpdateRuntimeInfo >> >> Hi all, >> >> Batch updates are now merged, so please start using it. As usage example, >> please check VdsUpdateRuntimeInfo code. Attached doc shows performance >> benefits from using batch over regular update. > Is the percentage per each VM update? Or a loaded "average" system? From liran.zelkha at gmail.com Wed Jul 3 11:47:16 2013 From: liran.zelkha at gmail.com (Liran Zelkha) Date: Wed, 3 Jul 2013 14:47:16 +0300 Subject: [Engine-devel] [rhevm-staff] Fwd: BatchUpdates and VdsUpdateRuntimeInfo In-Reply-To: <1A7F0BF8-2C46-48E3-B1BE-B311A5BEEBEA@redhat.com> References: <5AC1CD58-AC29-4C29-BE06-F03364135AEA@gmail.com> <266544720.12425080.1372849991817.JavaMail.root@redhat.com> <1A7F0BF8-2C46-48E3-B1BE-B311A5BEEBEA@redhat.com> Message-ID: Loaded average of a system that only runs update runtime info On Jul 3, 2013 2:45 PM, "Michal Skrivanek" wrote: > > > > > ----- Forwarded Message ----- > >> From: "Liran Zelkha" > >> To: "engine-devel" > >> Cc: "Itamar Heim" , "Barak Azulay" < > bazulay at redhat.com>, "Allon Mureinik" > >> Sent: Wednesday, July 3, 2013 1:08:08 PM > >> Subject: BatchUpdates and VdsUpdateRuntimeInfo > >> > >> Hi all, > >> > >> Batch updates are now merged, so please start using it. As usage > example, > >> please check VdsUpdateRuntimeInfo code. Attached doc shows performance > >> benefits from using batch over regular update. > > > > Is the percentage per each VM update? Or a loaded "average" system? > _______________________________________________ > 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 mperina at redhat.com Wed Jul 3 11:55:00 2013 From: mperina at redhat.com (Martin Perina) Date: Wed, 3 Jul 2013 07:55:00 -0400 (EDT) Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <762BDFC8-7094-4C84-9EF3-DEBA88A06336@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <2036896830.10266657.1372610122917.JavaMail.root@redhat.com> <51D11BE0.6000809@redhat.com> <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> <429008692.30913072.1372667257807.JavaMail.root@redhat.com> <51D1528E.5050908@redhat.com> <230315749.1320462.1372754674527.JavaMail.root@redhat.com> <762BDFC8-7094-4C84-9EF3-DEBA88A06336@redhat.com> Message-ID: <324529653.3123453.1372852500150.JavaMail.root@redhat.com> Let's summarize again, SSH Soft Fencing patches has been merged yesterday with following functionality: 1) For hosts with power management configured, SSH Soft Fencing is the 1st fencing stage. If it doesn't help, real fencing will be executed. 2) For hosts without power management configured, SSH Soft Fencing is the only fencing stage. If it doesn't help, host will become non responsive. 3) SSH Soft Fencing is enabled by default, there's no configuration option to disable it 4) SshSoftFencingCommand option is used to define what command is executed during SSH Soft Fencing. It can only be changed manually in database. The whole fencing process in oVirt 3.3 is decribed at http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3 Martin Perina ----- Original Message ----- > From: "Michal Skrivanek" > To: engine-devel at ovirt.org > Sent: Wednesday, July 3, 2013 12:03:13 PM > Subject: Re: [Engine-devel] SSH Soft Fencing > > > On Jul 2, 2013, at 10:44 , Eli Mesika wrote: > > > > > > > ----- Original Message ----- > >> From: "Livnat Peer" > >> To: "Yair Zaslavsky" > >> Cc: engine-devel at ovirt.org > >> Sent: Monday, July 1, 2013 12:57:34 PM > >> Subject: Re: [Engine-devel] SSH Soft Fencing > >> > >> On 07/01/2013 11:27 AM, Yair Zaslavsky wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Martin Perina" > >>>> To: engine-devel at ovirt.org > >>>> Sent: Monday, July 1, 2013 11:23:12 AM > >>>> Subject: Re: [Engine-devel] SSH Soft Fencing > >>>> > >>>> So let me summarize it: > >>>> > >>>> We have come to agreement in those questions: > >>>> > >>>> 1) SSH Soft Fencing logic should be extracted from > >>>> VdsNotRespondingTreatment > >>>> command to its own SshSoftFencingCommand > >>>> > >>>> 2) VdsNotRespondingCommand should be refactored so it's not inherited > >>>> from > >>>> VdsRestartCommand, but it should run SshSoftFencingCommand > >>>> or VdsRestartCommand based on defined fencing flow > >>>> > >>>> > >>>> These questions has not been resolved yet: > >>>> > >>>> 3) Should SSH Soft Fencing be executed also for hosts without PM > >>>> configured? > >>>> > >>>> 4) Should SSH Soft Fencing execution for hosts without PM configured be > >>>> enabled > >>>> by default and admin can turn off these feature using configuration > >>>> options > >>>> SshSoftFencingWithoutPmEnabled (or something like that)? > >>>> > >>>> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster > >>>> wide > >>>> option (can be turned off for specific cluster version) or a VDS > >>>> option > >>>> (it can be turned off for each host)? > >>>> > >>>> > >>>> Personally I would suggest: > >>>> > >>>> ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM > >>>> configured > >>>> > >> > >> > >> +1 > >> > >>>> ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be > >>>> enabled by default > >>>> > >> > >> +1 > >> > >>>> ad 5) I don't see any significant reason why someone would like to turn > >>>> off > >>>> SSH Soft Fencing > >>>> for hosts without PM configured. But if someone would like to do > >>>> that, > >>>> I think > >>>> he would like to turn it off only for specific hosts, so VDS level > >>>> option makes sense > >>>> for me > >>> > >>> After re-thinking 5 - I agree. > >>> +1 on the other suggestions, but of course we need to get more consensus > >>> here. > >>> > >> > >> I think it does not need to be configurable. > > I think a configuration option, as cumbersome and confusing as it can be, is > still better than no choice. Especially if it means to restore the previous > behavior. > If it only can happen in a theoretical problem at customer where vdsm restart > cause issues for whatever theoretical reason?.it would be of great help > then. > And if you don't understand the parameter - just don't touch it, I hope > that's a general rule:-) > From rgolan at redhat.com Wed Jul 3 12:02:38 2013 From: rgolan at redhat.com (Roy Golan) Date: Wed, 03 Jul 2013 15:02:38 +0300 Subject: [Engine-devel] build a single maven project with make Message-ID: <51D412DE.8000406@redhat.com> For those of us of dream of clean install a single project like maven please note that mvn has a flag which enables you to build a specific artifact even if your not at that directory mvn -pl groupID:artifactId so say you modified a single class in vdsbroker do this: /make clean install-dev PREFIX=$HOME/ovirt-engine DEV_EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:vdsbroker" EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:vdsbroker"/ note: the usage of DEV_EXTRA_BUILD_FLAGS and EXTRA_BUILD_FLAGS is not a mistake. the "clean" target uses EXTRA_BUILD_FLAGS - please review http://gerrit.ovirt.org/16395 to rectify that. now make the ear: /make clean install-dev PREFIX=$HOME/ovirt-engine DEV_EXTRA_BUILD_FLAGS="-pl org.ovirt.engine:engine-server-ear" EXTRA_BUILD_FLAGS="-pl org.ovirt.engine:engine-server-ear"/ now your updated artifact is in place. Thanks, Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpeer at redhat.com Wed Jul 3 12:32:16 2013 From: lpeer at redhat.com (Livnat Peer) Date: Wed, 03 Jul 2013 15:32:16 +0300 Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <324529653.3123453.1372852500150.JavaMail.root@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <2036896830.10266657.1372610122917.JavaMail.root@redhat.com> <51D11BE0.6000809@redhat.com> <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> <429008692.30913072.1372667257807.JavaMail.root@redhat.com> <51D1528E.5050908@redhat.com> <230315749.1320462.1372754674527.JavaMail.root@redhat.com> <762BDFC8-7094-4C84-9EF3-DEBA88A06336@redhat.com> <324529653.3123453.1372852500150.JavaMail.root@redhat.com> Message-ID: <51D419D0.7070407@redhat.com> Hi Martin, I have some more questions, - Do we persist the host root password for this feature? - If we do, is this feature limited for new hosts, can I provide it for already existing hosts? - Do we encrypt this value when storing in the DB? Thanks, Livnat On 07/03/2013 02:55 PM, Martin Perina wrote: > Let's summarize again, SSH Soft Fencing patches has been merged yesterday > with following functionality: > > 1) For hosts with power management configured, SSH Soft Fencing is the 1st > fencing stage. If it doesn't help, real fencing will be executed. > > 2) For hosts without power management configured, SSH Soft Fencing is the only > fencing stage. If it doesn't help, host will become non responsive. > > 3) SSH Soft Fencing is enabled by default, there's no configuration option > to disable it > > 4) SshSoftFencingCommand option is used to define what command is executed > during SSH Soft Fencing. It can only be changed manually in database. > > The whole fencing process in oVirt 3.3 is decribed at > > http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3 > > > > Martin Perina > > > ----- Original Message ----- >> From: "Michal Skrivanek" >> To: engine-devel at ovirt.org >> Sent: Wednesday, July 3, 2013 12:03:13 PM >> Subject: Re: [Engine-devel] SSH Soft Fencing >> >> >> On Jul 2, 2013, at 10:44 , Eli Mesika wrote: >> >>> >>> >>> ----- Original Message ----- >>>> From: "Livnat Peer" >>>> To: "Yair Zaslavsky" >>>> Cc: engine-devel at ovirt.org >>>> Sent: Monday, July 1, 2013 12:57:34 PM >>>> Subject: Re: [Engine-devel] SSH Soft Fencing >>>> >>>> On 07/01/2013 11:27 AM, Yair Zaslavsky wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Martin Perina" >>>>>> To: engine-devel at ovirt.org >>>>>> Sent: Monday, July 1, 2013 11:23:12 AM >>>>>> Subject: Re: [Engine-devel] SSH Soft Fencing >>>>>> >>>>>> So let me summarize it: >>>>>> >>>>>> We have come to agreement in those questions: >>>>>> >>>>>> 1) SSH Soft Fencing logic should be extracted from >>>>>> VdsNotRespondingTreatment >>>>>> command to its own SshSoftFencingCommand >>>>>> >>>>>> 2) VdsNotRespondingCommand should be refactored so it's not inherited >>>>>> from >>>>>> VdsRestartCommand, but it should run SshSoftFencingCommand >>>>>> or VdsRestartCommand based on defined fencing flow >>>>>> >>>>>> >>>>>> These questions has not been resolved yet: >>>>>> >>>>>> 3) Should SSH Soft Fencing be executed also for hosts without PM >>>>>> configured? >>>>>> >>>>>> 4) Should SSH Soft Fencing execution for hosts without PM configured be >>>>>> enabled >>>>>> by default and admin can turn off these feature using configuration >>>>>> options >>>>>> SshSoftFencingWithoutPmEnabled (or something like that)? >>>>>> >>>>>> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster >>>>>> wide >>>>>> option (can be turned off for specific cluster version) or a VDS >>>>>> option >>>>>> (it can be turned off for each host)? >>>>>> >>>>>> >>>>>> Personally I would suggest: >>>>>> >>>>>> ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM >>>>>> configured >>>>>> >>>> >>>> >>>> +1 >>>> >>>>>> ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be >>>>>> enabled by default >>>>>> >>>> >>>> +1 >>>> >>>>>> ad 5) I don't see any significant reason why someone would like to turn >>>>>> off >>>>>> SSH Soft Fencing >>>>>> for hosts without PM configured. But if someone would like to do >>>>>> that, >>>>>> I think >>>>>> he would like to turn it off only for specific hosts, so VDS level >>>>>> option makes sense >>>>>> for me >>>>> >>>>> After re-thinking 5 - I agree. >>>>> +1 on the other suggestions, but of course we need to get more consensus >>>>> here. >>>>> >>>> >>>> I think it does not need to be configurable. >> >> I think a configuration option, as cumbersome and confusing as it can be, is >> still better than no choice. Especially if it means to restore the previous >> behavior. >> If it only can happen in a theoretical problem at customer where vdsm restart >> cause issues for whatever theoretical reason?.it would be of great help >> then. >> And if you don't understand the parameter - just don't touch it, I hope >> that's a general rule:-) >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mperina at redhat.com Wed Jul 3 12:39:20 2013 From: mperina at redhat.com (Martin Perina) Date: Wed, 3 Jul 2013 08:39:20 -0400 (EDT) Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <51D419D0.7070407@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> <429008692.30913072.1372667257807.JavaMail.root@redhat.com> <51D1528E.5050908@redhat.com> <230315749.1320462.1372754674527.JavaMail.root@redhat.com> <762BDFC8-7094-4C84-9EF3-DEBA88A06336@redhat.com> <324529653.3123453.1372852500150.JavaMail.root@redhat.com> <51D419D0.7070407@redhat.com> Message-ID: <575629698.3146125.1372855160574.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Livnat Peer" > To: "Martin Perina" > Cc: engine-devel at ovirt.org > Sent: Wednesday, July 3, 2013 2:32:16 PM > Subject: Re: [Engine-devel] SSH Soft Fencing > > Hi Martin, > I have some more questions, > - Do we persist the host root password for this feature? > - If we do, is this feature limited for new hosts, can I provide it for > already existing hosts? > - Do we encrypt this value when storing in the DB? > > Thanks, Livnat > Well, SSH connection uses engine default SSH key, no password. So I think this is usable for all hosts. > > On 07/03/2013 02:55 PM, Martin Perina wrote: > > Let's summarize again, SSH Soft Fencing patches has been merged yesterday > > with following functionality: > > > > 1) For hosts with power management configured, SSH Soft Fencing is the 1st > > fencing stage. If it doesn't help, real fencing will be executed. > > > > 2) For hosts without power management configured, SSH Soft Fencing is the > > only > > fencing stage. If it doesn't help, host will become non responsive. > > > > 3) SSH Soft Fencing is enabled by default, there's no configuration option > > to disable it > > > > 4) SshSoftFencingCommand option is used to define what command is executed > > during SSH Soft Fencing. It can only be changed manually in database. > > > > The whole fencing process in oVirt 3.3 is decribed at > > > > http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3 > > > > > > > > Martin Perina > > > > > > ----- Original Message ----- > >> From: "Michal Skrivanek" > >> To: engine-devel at ovirt.org > >> Sent: Wednesday, July 3, 2013 12:03:13 PM > >> Subject: Re: [Engine-devel] SSH Soft Fencing > >> > >> > >> On Jul 2, 2013, at 10:44 , Eli Mesika wrote: > >> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Livnat Peer" > >>>> To: "Yair Zaslavsky" > >>>> Cc: engine-devel at ovirt.org > >>>> Sent: Monday, July 1, 2013 12:57:34 PM > >>>> Subject: Re: [Engine-devel] SSH Soft Fencing > >>>> > >>>> On 07/01/2013 11:27 AM, Yair Zaslavsky wrote: > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Martin Perina" > >>>>>> To: engine-devel at ovirt.org > >>>>>> Sent: Monday, July 1, 2013 11:23:12 AM > >>>>>> Subject: Re: [Engine-devel] SSH Soft Fencing > >>>>>> > >>>>>> So let me summarize it: > >>>>>> > >>>>>> We have come to agreement in those questions: > >>>>>> > >>>>>> 1) SSH Soft Fencing logic should be extracted from > >>>>>> VdsNotRespondingTreatment > >>>>>> command to its own SshSoftFencingCommand > >>>>>> > >>>>>> 2) VdsNotRespondingCommand should be refactored so it's not inherited > >>>>>> from > >>>>>> VdsRestartCommand, but it should run SshSoftFencingCommand > >>>>>> or VdsRestartCommand based on defined fencing flow > >>>>>> > >>>>>> > >>>>>> These questions has not been resolved yet: > >>>>>> > >>>>>> 3) Should SSH Soft Fencing be executed also for hosts without PM > >>>>>> configured? > >>>>>> > >>>>>> 4) Should SSH Soft Fencing execution for hosts without PM configured > >>>>>> be > >>>>>> enabled > >>>>>> by default and admin can turn off these feature using configuration > >>>>>> options > >>>>>> SshSoftFencingWithoutPmEnabled (or something like that)? > >>>>>> > >>>>>> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a > >>>>>> cluster > >>>>>> wide > >>>>>> option (can be turned off for specific cluster version) or a VDS > >>>>>> option > >>>>>> (it can be turned off for each host)? > >>>>>> > >>>>>> > >>>>>> Personally I would suggest: > >>>>>> > >>>>>> ad 3) Yes, SSH Soft Fencing should be executed also for hosts without > >>>>>> PM > >>>>>> configured > >>>>>> > >>>> > >>>> > >>>> +1 > >>>> > >>>>>> ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be > >>>>>> enabled by default > >>>>>> > >>>> > >>>> +1 > >>>> > >>>>>> ad 5) I don't see any significant reason why someone would like to > >>>>>> turn > >>>>>> off > >>>>>> SSH Soft Fencing > >>>>>> for hosts without PM configured. But if someone would like to do > >>>>>> that, > >>>>>> I think > >>>>>> he would like to turn it off only for specific hosts, so VDS > >>>>>> level > >>>>>> option makes sense > >>>>>> for me > >>>>> > >>>>> After re-thinking 5 - I agree. > >>>>> +1 on the other suggestions, but of course we need to get more > >>>>> consensus > >>>>> here. > >>>>> > >>>> > >>>> I think it does not need to be configurable. > >> > >> I think a configuration option, as cumbersome and confusing as it can be, > >> is > >> still better than no choice. Especially if it means to restore the > >> previous > >> behavior. > >> If it only can happen in a theoretical problem at customer where vdsm > >> restart > >> cause issues for whatever theoretical reason?.it would be of great help > >> then. > >> And if you don't understand the parameter - just don't touch it, I hope > >> that's a general rule:-) > >> > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > From mlipchuk at redhat.com Wed Jul 3 12:54:22 2013 From: mlipchuk at redhat.com (Maor Lipchuk) Date: Wed, 03 Jul 2013 15:54:22 +0300 Subject: [Engine-devel] build a single maven project with make In-Reply-To: <51D412DE.8000406@redhat.com> References: <51D412DE.8000406@redhat.com> Message-ID: <51D41EFE.5010209@redhat.com> Nice one!!!! On 07/03/2013 03:02 PM, Roy Golan wrote: > For those of us of dream of clean install a single project like maven > please note that > mvn has a flag which enables you to build a specific artifact even if > your not at that directory > > mvn -pl groupID:artifactId > > so say you modified a single class in vdsbroker do this: > > /make clean install-dev PREFIX=$HOME/ovirt-engine > DEV_EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:vdsbroker" > EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:vdsbroker"/ > > note: the usage of DEV_EXTRA_BUILD_FLAGS and EXTRA_BUILD_FLAGS is not a > mistake. the "clean" target uses EXTRA_BUILD_FLAGS - please review > http://gerrit.ovirt.org/16395 to rectify that. > > now make the ear: > > /make clean install-dev PREFIX=$HOME/ovirt-engine > DEV_EXTRA_BUILD_FLAGS="-pl org.ovirt.engine:engine-server-ear" > EXTRA_BUILD_FLAGS="-pl org.ovirt.engine:engine-server-ear"/ > > > now your updated artifact is in place. > > Thanks, > Roy > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From danqingx.liu at intel.com Wed Jul 3 09:23:14 2013 From: danqingx.liu at intel.com (Liu, DanqingX) Date: Wed, 3 Jul 2013 09:23:14 +0000 Subject: [Engine-devel] fail to setup engine In-Reply-To: <51D3E9DD.3070904@redhat.com> References: <51D3E78E.70607@redhat.com> <51D3E9DD.3070904@redhat.com> Message-ID: <32933DF08985CE44BE5477C232AF07370268DFBA@SHSMSX104.ccr.corp.intel.com> This attachment is the log -----Original Message----- From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] Sent: Wednesday, July 03, 2013 5:08 PM To: Chen, Wei D Cc: engine-devel; Zhang, Lijuan; Liu, DanqingX Subject: Re: [Engine-devel] fail to setup engine If the setup log is not created (it's usually in tmp directory) can you attach the output of OTOPI_DEBUG=1 $HOME/ovirt-engine/bin/engine-setup-2 ? Il 03/07/2013 10:59, Chen, Wei D ha scritto: > where is the log file? engine.log and server.log have not created yet. > > > > > > Best Regards, > > Dave Chen > > > > From: Sandro Bonazzola [mailto:sbonazzo at redhat.com] > Sent: Wednesday, July 03, 2013 4:58 PM > To: Chen, Wei D > Cc: engine-devel; Zhang, Lijuan; Liu, DanqingX > Subject: Re: [Engine-devel] fail to setup engine > > > > Il 03/07/2013 10:54, Chen, Wei D ha scritto: > > Hi, > > We cannot setup engine based on today's source code, any ideas? > > > $HOME/ovirt-engine/bin/engine-setup-2 > [ ERROR ] Failed to execute stage 'Booting': 5 [ INFO ] Stage: > Initializing > Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: > Yes > [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. > Specifically, engine-setup-2 does not support upgrade from previous installations. > > Best Regards, > Dave Chen > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > Can you attach the log file? > > > > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: engine-setup.log Type: application/octet-stream Size: 15069 bytes Desc: engine-setup.log URL: From bazulay at redhat.com Wed Jul 3 14:24:21 2013 From: bazulay at redhat.com (Barak Azulay) Date: Wed, 3 Jul 2013 10:24:21 -0400 (EDT) Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <575629698.3146125.1372855160574.JavaMail.root@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <429008692.30913072.1372667257807.JavaMail.root@redhat.com> <51D1528E.5050908@redhat.com> <230315749.1320462.1372754674527.JavaMail.root@redhat.com> <762BDFC8-7094-4C84-9EF3-DEBA88A06336@redhat.com> <324529653.3123453.1372852500150.JavaMail.root@redhat.com> <51D419D0.7070407@redhat.com> <575629698.3146125.1372855160574.JavaMail.root@redhat.com> Message-ID: <1617635627.12611349.1372861461201.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Martin Perina" > To: engine-devel at ovirt.org > Sent: Wednesday, July 3, 2013 3:39:20 PM > Subject: Re: [Engine-devel] SSH Soft Fencing > > > > ----- Original Message ----- > > From: "Livnat Peer" > > To: "Martin Perina" > > Cc: engine-devel at ovirt.org > > Sent: Wednesday, July 3, 2013 2:32:16 PM > > Subject: Re: [Engine-devel] SSH Soft Fencing > > > > Hi Martin, > > I have some more questions, > > - Do we persist the host root password for this feature? > > - If we do, is this feature limited for new hosts, can I provide it for > > already existing hosts? > > - Do we encrypt this value when storing in the DB? > > > > Thanks, Livnat > > > > Well, SSH connection uses engine default SSH key, no password. So I think > this is usable for all hosts. correct, SSH public key is deployed as a part of bootstrap & host-deploy from day one. So no need to save the password anywhere. Marin - Where do you take the username (currently only root is supported), but we intend to move away from it, Actually Yaniv.B as added it to the DB as first stage - just making sure you'll use that. Thanks Barak > > > > > > On 07/03/2013 02:55 PM, Martin Perina wrote: > > > Let's summarize again, SSH Soft Fencing patches has been merged yesterday > > > with following functionality: > > > > > > 1) For hosts with power management configured, SSH Soft Fencing is the > > > 1st > > > fencing stage. If it doesn't help, real fencing will be executed. > > > > > > 2) For hosts without power management configured, SSH Soft Fencing is the > > > only > > > fencing stage. If it doesn't help, host will become non responsive. > > > > > > 3) SSH Soft Fencing is enabled by default, there's no configuration > > > option > > > to disable it > > > > > > 4) SshSoftFencingCommand option is used to define what command is > > > executed > > > during SSH Soft Fencing. It can only be changed manually in database. > > > > > > The whole fencing process in oVirt 3.3 is decribed at > > > > > > http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3 > > > > > > > > > > > > Martin Perina > > > > > > > > > ----- Original Message ----- > > >> From: "Michal Skrivanek" > > >> To: engine-devel at ovirt.org > > >> Sent: Wednesday, July 3, 2013 12:03:13 PM > > >> Subject: Re: [Engine-devel] SSH Soft Fencing > > >> > > >> > > >> On Jul 2, 2013, at 10:44 , Eli Mesika wrote: > > >> > > >>> > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Livnat Peer" > > >>>> To: "Yair Zaslavsky" > > >>>> Cc: engine-devel at ovirt.org > > >>>> Sent: Monday, July 1, 2013 12:57:34 PM > > >>>> Subject: Re: [Engine-devel] SSH Soft Fencing > > >>>> > > >>>> On 07/01/2013 11:27 AM, Yair Zaslavsky wrote: > > >>>>> > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> From: "Martin Perina" > > >>>>>> To: engine-devel at ovirt.org > > >>>>>> Sent: Monday, July 1, 2013 11:23:12 AM > > >>>>>> Subject: Re: [Engine-devel] SSH Soft Fencing > > >>>>>> > > >>>>>> So let me summarize it: > > >>>>>> > > >>>>>> We have come to agreement in those questions: > > >>>>>> > > >>>>>> 1) SSH Soft Fencing logic should be extracted from > > >>>>>> VdsNotRespondingTreatment > > >>>>>> command to its own SshSoftFencingCommand > > >>>>>> > > >>>>>> 2) VdsNotRespondingCommand should be refactored so it's not > > >>>>>> inherited > > >>>>>> from > > >>>>>> VdsRestartCommand, but it should run SshSoftFencingCommand > > >>>>>> or VdsRestartCommand based on defined fencing flow > > >>>>>> > > >>>>>> > > >>>>>> These questions has not been resolved yet: > > >>>>>> > > >>>>>> 3) Should SSH Soft Fencing be executed also for hosts without PM > > >>>>>> configured? > > >>>>>> > > >>>>>> 4) Should SSH Soft Fencing execution for hosts without PM configured > > >>>>>> be > > >>>>>> enabled > > >>>>>> by default and admin can turn off these feature using > > >>>>>> configuration > > >>>>>> options > > >>>>>> SshSoftFencingWithoutPmEnabled (or something like that)? > > >>>>>> > > >>>>>> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a > > >>>>>> cluster > > >>>>>> wide > > >>>>>> option (can be turned off for specific cluster version) or a VDS > > >>>>>> option > > >>>>>> (it can be turned off for each host)? > > >>>>>> > > >>>>>> > > >>>>>> Personally I would suggest: > > >>>>>> > > >>>>>> ad 3) Yes, SSH Soft Fencing should be executed also for hosts > > >>>>>> without > > >>>>>> PM > > >>>>>> configured > > >>>>>> > > >>>> > > >>>> > > >>>> +1 > > >>>> > > >>>>>> ad 4) Yes, SSH Soft Fencing for hosts without PM configured should > > >>>>>> be > > >>>>>> enabled by default > > >>>>>> > > >>>> > > >>>> +1 > > >>>> > > >>>>>> ad 5) I don't see any significant reason why someone would like to > > >>>>>> turn > > >>>>>> off > > >>>>>> SSH Soft Fencing > > >>>>>> for hosts without PM configured. But if someone would like to > > >>>>>> do > > >>>>>> that, > > >>>>>> I think > > >>>>>> he would like to turn it off only for specific hosts, so VDS > > >>>>>> level > > >>>>>> option makes sense > > >>>>>> for me > > >>>>> > > >>>>> After re-thinking 5 - I agree. > > >>>>> +1 on the other suggestions, but of course we need to get more > > >>>>> consensus > > >>>>> here. > > >>>>> > > >>>> > > >>>> I think it does not need to be configurable. > > >> > > >> I think a configuration option, as cumbersome and confusing as it can > > >> be, > > >> is > > >> still better than no choice. Especially if it means to restore the > > >> previous > > >> behavior. > > >> If it only can happen in a theoretical problem at customer where vdsm > > >> restart > > >> cause issues for whatever theoretical reason?.it would be of great help > > >> then. > > >> And if you don't understand the parameter - just don't touch it, I hope > > >> that's a general rule:-) > > >> > > > _______________________________________________ > > > 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 Jul 3 14:44:54 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Wed, 3 Jul 2013 10:44:54 -0400 (EDT) Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <1617635627.12611349.1372861461201.JavaMail.root@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <51D1528E.5050908@redhat.com> <230315749.1320462.1372754674527.JavaMail.root@redhat.com> <762BDFC8-7094-4C84-9EF3-DEBA88A06336@redhat.com> <324529653.3123453.1372852500150.JavaMail.root@redhat.com> <51D419D0.7070407@redhat.com> <575629698.3146125.1372855160574.JavaMail.root@redhat.com> <1617635627.12611349.1372861461201.JavaMail.root@redhat.com> Message-ID: <910101324.33079456.1372862694152.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Barak Azulay" > To: "Martin Perina" , "Yaniv Bronheim" > Cc: engine-devel at ovirt.org > Sent: Wednesday, July 3, 2013 5:24:21 PM > Subject: Re: [Engine-devel] SSH Soft Fencing > > > > ----- Original Message ----- > > From: "Martin Perina" > > To: engine-devel at ovirt.org > > Sent: Wednesday, July 3, 2013 3:39:20 PM > > Subject: Re: [Engine-devel] SSH Soft Fencing > > > > > > > > ----- Original Message ----- > > > From: "Livnat Peer" > > > To: "Martin Perina" > > > Cc: engine-devel at ovirt.org > > > Sent: Wednesday, July 3, 2013 2:32:16 PM > > > Subject: Re: [Engine-devel] SSH Soft Fencing > > > > > > Hi Martin, > > > I have some more questions, > > > - Do we persist the host root password for this feature? > > > - If we do, is this feature limited for new hosts, can I provide it for > > > already existing hosts? > > > - Do we encrypt this value when storing in the DB? > > > > > > Thanks, Livnat > > > > > > > Well, SSH connection uses engine default SSH key, no password. So I think > > this is usable for all hosts. > > correct, SSH public key is deployed as a part of bootstrap & host-deploy from > day one. > So no need to save the password anywhere. > > Marin - Where do you take the username (currently only root is supported), > but we intend to move away from it, > Actually Yaniv.B as added it to the DB as first stage - just making sure > you'll use that. > > Thanks > Barak My 2 cents - Actually, Since Martin's work is merged, and Yaniv already has in one of his patches fixes to all relevant places in code he will probably need to add a fix around ssh soft fencing area (or at least coordinate this with Martin). Both Yaniv and Martin are already aware of this. Yair > > > > > > > > > > > On 07/03/2013 02:55 PM, Martin Perina wrote: > > > > Let's summarize again, SSH Soft Fencing patches has been merged > > > > yesterday > > > > with following functionality: > > > > > > > > 1) For hosts with power management configured, SSH Soft Fencing is the > > > > 1st > > > > fencing stage. If it doesn't help, real fencing will be executed. > > > > > > > > 2) For hosts without power management configured, SSH Soft Fencing is > > > > the > > > > only > > > > fencing stage. If it doesn't help, host will become non responsive. > > > > > > > > 3) SSH Soft Fencing is enabled by default, there's no configuration > > > > option > > > > to disable it > > > > > > > > 4) SshSoftFencingCommand option is used to define what command is > > > > executed > > > > during SSH Soft Fencing. It can only be changed manually in > > > > database. > > > > > > > > The whole fencing process in oVirt 3.3 is decribed at > > > > > > > > http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3 > > > > > > > > > > > > > > > > Martin Perina > > > > > > > > > > > > ----- Original Message ----- > > > >> From: "Michal Skrivanek" > > > >> To: engine-devel at ovirt.org > > > >> Sent: Wednesday, July 3, 2013 12:03:13 PM > > > >> Subject: Re: [Engine-devel] SSH Soft Fencing > > > >> > > > >> > > > >> On Jul 2, 2013, at 10:44 , Eli Mesika wrote: > > > >> > > > >>> > > > >>> > > > >>> ----- Original Message ----- > > > >>>> From: "Livnat Peer" > > > >>>> To: "Yair Zaslavsky" > > > >>>> Cc: engine-devel at ovirt.org > > > >>>> Sent: Monday, July 1, 2013 12:57:34 PM > > > >>>> Subject: Re: [Engine-devel] SSH Soft Fencing > > > >>>> > > > >>>> On 07/01/2013 11:27 AM, Yair Zaslavsky wrote: > > > >>>>> > > > >>>>> > > > >>>>> ----- Original Message ----- > > > >>>>>> From: "Martin Perina" > > > >>>>>> To: engine-devel at ovirt.org > > > >>>>>> Sent: Monday, July 1, 2013 11:23:12 AM > > > >>>>>> Subject: Re: [Engine-devel] SSH Soft Fencing > > > >>>>>> > > > >>>>>> So let me summarize it: > > > >>>>>> > > > >>>>>> We have come to agreement in those questions: > > > >>>>>> > > > >>>>>> 1) SSH Soft Fencing logic should be extracted from > > > >>>>>> VdsNotRespondingTreatment > > > >>>>>> command to its own SshSoftFencingCommand > > > >>>>>> > > > >>>>>> 2) VdsNotRespondingCommand should be refactored so it's not > > > >>>>>> inherited > > > >>>>>> from > > > >>>>>> VdsRestartCommand, but it should run SshSoftFencingCommand > > > >>>>>> or VdsRestartCommand based on defined fencing flow > > > >>>>>> > > > >>>>>> > > > >>>>>> These questions has not been resolved yet: > > > >>>>>> > > > >>>>>> 3) Should SSH Soft Fencing be executed also for hosts without PM > > > >>>>>> configured? > > > >>>>>> > > > >>>>>> 4) Should SSH Soft Fencing execution for hosts without PM > > > >>>>>> configured > > > >>>>>> be > > > >>>>>> enabled > > > >>>>>> by default and admin can turn off these feature using > > > >>>>>> configuration > > > >>>>>> options > > > >>>>>> SshSoftFencingWithoutPmEnabled (or something like that)? > > > >>>>>> > > > >>>>>> 5) Should SshSoftFencingWithoutPmEnabled be a global option or a > > > >>>>>> cluster > > > >>>>>> wide > > > >>>>>> option (can be turned off for specific cluster version) or a VDS > > > >>>>>> option > > > >>>>>> (it can be turned off for each host)? > > > >>>>>> > > > >>>>>> > > > >>>>>> Personally I would suggest: > > > >>>>>> > > > >>>>>> ad 3) Yes, SSH Soft Fencing should be executed also for hosts > > > >>>>>> without > > > >>>>>> PM > > > >>>>>> configured > > > >>>>>> > > > >>>> > > > >>>> > > > >>>> +1 > > > >>>> > > > >>>>>> ad 4) Yes, SSH Soft Fencing for hosts without PM configured should > > > >>>>>> be > > > >>>>>> enabled by default > > > >>>>>> > > > >>>> > > > >>>> +1 > > > >>>> > > > >>>>>> ad 5) I don't see any significant reason why someone would like to > > > >>>>>> turn > > > >>>>>> off > > > >>>>>> SSH Soft Fencing > > > >>>>>> for hosts without PM configured. But if someone would like > > > >>>>>> to > > > >>>>>> do > > > >>>>>> that, > > > >>>>>> I think > > > >>>>>> he would like to turn it off only for specific hosts, so VDS > > > >>>>>> level > > > >>>>>> option makes sense > > > >>>>>> for me > > > >>>>> > > > >>>>> After re-thinking 5 - I agree. > > > >>>>> +1 on the other suggestions, but of course we need to get more > > > >>>>> consensus > > > >>>>> here. > > > >>>>> > > > >>>> > > > >>>> I think it does not need to be configurable. > > > >> > > > >> I think a configuration option, as cumbersome and confusing as it can > > > >> be, > > > >> is > > > >> still better than no choice. Especially if it means to restore the > > > >> previous > > > >> behavior. > > > >> If it only can happen in a theoretical problem at customer where vdsm > > > >> restart > > > >> cause issues for whatever theoretical reason?.it would be of great > > > >> help > > > >> then. > > > >> And if you don't understand the parameter - just don't touch it, I > > > >> hope > > > >> that's a general rule:-) > > > >> > > > > _______________________________________________ > > > > 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 mrao at redhat.com Wed Jul 3 16:42:03 2013 From: mrao at redhat.com (Malini Rao) Date: Wed, 3 Jul 2013 12:42:03 -0400 (EDT) Subject: [Engine-devel] VNIC profiles In-Reply-To: <51D26C63.8040004@redhat.com> References: <51D02BB9.4090008@redhat.com> <1014928995.103721546.1372702977041.JavaMail.root@redhat.com> <51D26C63.8040004@redhat.com> Message-ID: <1236424433.109677277.1372869723904.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Livnat Peer" > To: "Malini Rao" > Cc: "engine-devel" , "Ofri Masad" , "Eldan Hildesheim" > > Sent: Tuesday, July 2, 2013 2:00:03 AM > Subject: Re: [Engine-devel] VNIC profiles > > On 07/01/2013 09:22 PM, Malini Rao wrote: > > Hi Livnat, > > > > My name is Malini Rao and I am the lead interaction designer dedicated to > > RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan > > Hildeshiem who is also focused on RHEV UX. > > Hi Malini - nice to e-meet you :) > > > I went over your feature page and in general, the GUI proposals look great. > > I do have some quick feedback comments - > > Just a small credit correction - the feature page is Ofri's feature > page, I added some feedback of my own :) Sorry about that! Ofri, I look forward to collaborating with you and I hope we can contribute to this feature from the UX/ usability perspective. > > > > > Will there be any predefined profiles available to the users out of the box > > in RHEV? Or will they have to define their own? > > If you start with a clean install setup there are no predefined vNICs > profiles. > > Profiles can be generated in two flows, a user can explicitly generate a > profile or when admin network creates a new network he can mark create a > profile for this network** in a single action. > A VNIC profile is the link between the abstract network entity and the > VM which consumes this network. > > If you upgrade existing setup, in the upgrade process profiles will be > created per network and will be attached to the VNICs that are currently > using the network. So you are saying any VNIC profiles created and the associations with VMS that already exist will be preserved during Upgrades... correct? But none of these need to be pre-defined ( as in something that was available to the user automatically and not via user action)... correct? > > **This is not accurate, the user would be able to check all relevant > VNIC-QoS-entities and for each one we need to create a profile. So there are two concepts here - VNIC-QoS-entities and VNIC Profiles? > > > > I am wondering if there are any common standard QoS levels that can be > > predefined and the users can get a heeadstart and use or tweak instead of > > defining from scratch. > > That's a very good point. > The wiki page is not fully up to date, I think. > Ofri wanted to add an entity of VNIC QoS which would be linked from > within the VNIC profile. > > The VNIC QoS entity is located in the entities hierarchy under Data Center. > > The point you made, I think, is will we have predefined VNIC QoS entities. > > The Qos entity is tight to the hardware you have in your DC. If you have > 10G or 1G Ethernet links the QoS entities would look very different, so > I'm not sure what predefined values would look like. So are you saying that we can have pre-defined VNIC Qos Entities like Gold, silver etc. but not VNIC profiles because what is gold for a 10G Ehternet is different from gold for a 1G Ethernet? But even if they are different, can the VNIC profiles not also be auto generated based on the Hardware and the VNIC Qos Entities? > > > > > VNIC level QoS dialog > > > > 1. Will the Outbound and inbound values come with some defaults? Or will > > they be empty? Is there a need for any spinners or drop downs for > > frequently used values or is it ok to just have fields to type in the > > numeric values? Also I am assuming there is some kind of validation to > > ensure only numbers an be entered in these fields. > > > > 2. For custom properties, why do we have a drop down? Can custom properties > > defined elsewhere be accessed here and applied? If not, then I am assuming > > this will have to be a text field. Correct? Also, I am guessing if there > > is only one custom property field, the [-] icon will be disabled. > > > > Edit Network Interface Dialog > > 1. It will be awesome if under the Profile Field value, you can present a > > short summary of the profile in gray text. alternately, there can be a > > little info icon which will present this info on hover. This will help > > people who pick Gold know what that means vs silver or any other profile. > > > > Besides these specific feedback, I am wondering if any of the VM dialogs > > are affected by this? Will a VNIC profile field now show up on those > > dialogs as well? > > > > I see you have identified a bunch of open issues to work out and we will be > > more than happy to help you with the GUI for these flows as needed. Please > > feel free to reach out to Eldan and me and we can post back to the group > > with our work. > > > > > Thank you Malini for the above feedback, I think these are good questions. > > Ofri - can you comment on the above ? Looking forward to some of the answers to the questions above. > > Livnat > > > Thanks > > Malini > > > > > > > > > > ----- Original Message ----- > > From: "Livnat Peer" > > To: "engine-devel" , "Ofri Masad" > > > > Sent: Sunday, June 30, 2013 8:59:37 AM > > Subject: [Engine-devel] VNIC profiles > > > > Hi, > > > > We are working on adding VNIC profiles as part of the work to add VNIC QoS. > > > > http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles > > > > We need to define some of the system behavior followed by this change, > > here is my take - > > > > Editing a profile - > > -------------------- > > A user should be able to edit the profile properties (including profile > > name) while VMs are attached and are using this Profile (reference > > should be done by id). > > > > Changing the network though is a bit more tricky as long as we don't > > have a way to distinguish between running and current configurations I > > think it could be very confusing to the user. Especially since we > > support dynamic wiring so the behavior IMO is unpredictable. > > I think it should be blocked at this point. > > > > > > Edit a VNIC / change a VNIC profile - > > ------------------------------------ > > Changing the profile a VM is using while the VM is running should behave > > like dynamic wiring (changing the VM network while it is running). > > > > > > Remove a Profile - > > ------------------- > > Is only valid if all VMs that are using this profile are in status down. > > It should update all VMs to point to no profile which should behave like > > none network today. > > > > I see no reason to support a profile on a none network at this point. > > > > The above is also relevant for upgrade flow (upgrading none network to > > point to no profile) > > > > > > Removing a Network - > > ---------------------- > > should remove all profiles on that network > > > > > > VM snapshot/import/export - > > -------------------------- > > We should handle VMs that are pointing to a network directly for b/w > > compatibility. > > we need to select first profile that is on that network that the user > > has permissions on. > > > > > > I assume there are more, comments are welcome > > > > Thanks, Livnat > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > From lpeer at redhat.com Thu Jul 4 06:02:48 2013 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 04 Jul 2013 09:02:48 +0300 Subject: [Engine-devel] VNIC profiles In-Reply-To: <1236424433.109677277.1372869723904.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <1014928995.103721546.1372702977041.JavaMail.root@redhat.com> <51D26C63.8040004@redhat.com> <1236424433.109677277.1372869723904.JavaMail.root@redhat.com> Message-ID: <51D51008.9020603@redhat.com> On 07/03/2013 07:42 PM, Malini Rao wrote: > ----- Original Message ----- >> From: "Livnat Peer" >> To: "Malini Rao" >> Cc: "engine-devel" , "Ofri Masad" , "Eldan Hildesheim" >> >> Sent: Tuesday, July 2, 2013 2:00:03 AM >> Subject: Re: [Engine-devel] VNIC profiles >> >> On 07/01/2013 09:22 PM, Malini Rao wrote: >>> Hi Livnat, >>> >>> My name is Malini Rao and I am the lead interaction designer dedicated to >>> RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan >>> Hildeshiem who is also focused on RHEV UX. >> >> Hi Malini - nice to e-meet you :) >> >>> I went over your feature page and in general, the GUI proposals look great. >>> I do have some quick feedback comments - >> >> Just a small credit correction - the feature page is Ofri's feature >> page, I added some feedback of my own :) > > Sorry about that! Ofri, I look forward to collaborating with you and I hope we can contribute to this feature from the UX/ usability perspective. > >> >>> >>> Will there be any predefined profiles available to the users out of the box >>> in RHEV? Or will they have to define their own? >> >> If you start with a clean install setup there are no predefined vNICs >> profiles. >> >> Profiles can be generated in two flows, a user can explicitly generate a >> profile or when admin network creates a new network he can mark create a >> profile for this network** in a single action. >> A VNIC profile is the link between the abstract network entity and the >> VM which consumes this network. >> >> If you upgrade existing setup, in the upgrade process profiles will be >> created per network and will be attached to the VNICs that are currently >> using the network. > > So you are saying any VNIC profiles created and the associations with VMS that already exist will be preserved during Upgrades... correct? But none of these need to be pre-defined ( as in something that was available to the user automatically and not via user action)... correct? > correct x2 >> >> **This is not accurate, the user would be able to check all relevant >> VNIC-QoS-entities and for each one we need to create a profile. > > So there are two concepts here - VNIC-QoS-entities and VNIC Profiles? > correct again :) > >> >> >>> I am wondering if there are any common standard QoS levels that can be >>> predefined and the users can get a heeadstart and use or tweak instead of >>> defining from scratch. >> >> That's a very good point. >> The wiki page is not fully up to date, I think. >> Ofri wanted to add an entity of VNIC QoS which would be linked from >> within the VNIC profile. >> >> The VNIC QoS entity is located in the entities hierarchy under Data Center. >> >> The point you made, I think, is will we have predefined VNIC QoS entities. >> >> The Qos entity is tight to the hardware you have in your DC. If you have >> 10G or 1G Ethernet links the QoS entities would look very different, so >> I'm not sure what predefined values would look like. > > So are you saying that we can have pre-defined VNIC Qos Entities like Gold, silver etc. I am saying it is something that Ofri should consider, although I personally don't think there is an added value in having a pre-defined VNIC Qos. > but not VNIC profiles because what is gold for a 10G Ehternet is different from gold for a 1G Ethernet? VNIC profile is associated with a specific Network, so technically we can't have pre-defined profiles as we don't have predefined Networks. Well, we do have the management network (which is predefined) and for that we do need to create a predefined profile - Thanks. This point out another behavior we should document, when removing the VM-network role from a network we need to remove the profiles associated with that network. (Moti, can you capture this in the VNIC profile wiki as well) > But even if they are different, can the VNIC profiles not also be auto generated based on the Hardware and the VNIC Qos Entities? > I lost you here, can you please elaborate. >> >>> >>> VNIC level QoS dialog >>> >>> 1. Will the Outbound and inbound values come with some defaults? Or will >>> they be empty? Is there a need for any spinners or drop downs for >>> frequently used values or is it ok to just have fields to type in the >>> numeric values? Also I am assuming there is some kind of validation to >>> ensure only numbers an be entered in these fields. >>> >>> 2. For custom properties, why do we have a drop down? Can custom properties >>> defined elsewhere be accessed here and applied? If not, then I am assuming >>> this will have to be a text field. Correct? Also, I am guessing if there >>> is only one custom property field, the [-] icon will be disabled. >>> >>> Edit Network Interface Dialog >>> 1. It will be awesome if under the Profile Field value, you can present a >>> short summary of the profile in gray text. alternately, there can be a >>> little info icon which will present this info on hover. This will help >>> people who pick Gold know what that means vs silver or any other profile. >>> >>> Besides these specific feedback, I am wondering if any of the VM dialogs >>> are affected by this? Will a VNIC profile field now show up on those >>> dialogs as well? >>> >>> I see you have identified a bunch of open issues to work out and we will be >>> more than happy to help you with the GUI for these flows as needed. Please >>> feel free to reach out to Eldan and me and we can post back to the group >>> with our work. >>> >> >> >> Thank you Malini for the above feedback, I think these are good questions. >> >> Ofri - can you comment on the above ? > > > Looking forward to some of the answers to the questions above. > > >> >> Livnat >> >>> Thanks >>> Malini >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: "Livnat Peer" >>> To: "engine-devel" , "Ofri Masad" >>> >>> Sent: Sunday, June 30, 2013 8:59:37 AM >>> Subject: [Engine-devel] VNIC profiles >>> >>> Hi, >>> >>> We are working on adding VNIC profiles as part of the work to add VNIC QoS. >>> >>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles >>> >>> We need to define some of the system behavior followed by this change, >>> here is my take - >>> >>> Editing a profile - >>> -------------------- >>> A user should be able to edit the profile properties (including profile >>> name) while VMs are attached and are using this Profile (reference >>> should be done by id). >>> >>> Changing the network though is a bit more tricky as long as we don't >>> have a way to distinguish between running and current configurations I >>> think it could be very confusing to the user. Especially since we >>> support dynamic wiring so the behavior IMO is unpredictable. >>> I think it should be blocked at this point. >>> >>> >>> Edit a VNIC / change a VNIC profile - >>> ------------------------------------ >>> Changing the profile a VM is using while the VM is running should behave >>> like dynamic wiring (changing the VM network while it is running). >>> >>> >>> Remove a Profile - >>> ------------------- >>> Is only valid if all VMs that are using this profile are in status down. >>> It should update all VMs to point to no profile which should behave like >>> none network today. >>> >>> I see no reason to support a profile on a none network at this point. >>> >>> The above is also relevant for upgrade flow (upgrading none network to >>> point to no profile) >>> >>> >>> Removing a Network - >>> ---------------------- >>> should remove all profiles on that network >>> >>> >>> VM snapshot/import/export - >>> -------------------------- >>> We should handle VMs that are pointing to a network directly for b/w >>> compatibility. >>> we need to select first profile that is on that network that the user >>> has permissions on. >>> >>> >>> I assume there are more, comments are welcome >>> >>> Thanks, Livnat >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From tjelinek at redhat.com Thu Jul 4 07:53:48 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Thu, 4 Jul 2013 03:53:48 -0400 (EDT) Subject: [Engine-devel] JsonMappingException on create pool In-Reply-To: <1616676839.5553423.1372922820854.JavaMail.root@redhat.com> Message-ID: <1318875933.5560395.1372924428709.JavaMail.root@redhat.com> Hey all, did anyone experienced problems creating a pool from a template with disk? Currently rebased and built engine throws: Error during CreateTask for command: org.ovirt.engine.core.bll.CreateSnapshotFromTemplateCommand. Exception org.apache.commons.lang.SerializationException: org.codehaus.jackson.map.JsonMappingException: Can not find a (Map) Key deserializer for type [simple type, class org.ovirt.engine.core.common.businessentities.VmDevice]: org.apache.commons.lang.SerializationException: org.codehaus.jackson.map.JsonMappingException: Can not find a (Map) Key deserializer for type [simple type, class org.ovirt.engine.core.common.businessentities.VmDevice] It does not happen when the template has no disks. More logs attached, thank you, Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: newPool.log Type: text/x-log Size: 39861 bytes Desc: not available URL: From yzaslavs at redhat.com Thu Jul 4 08:17:08 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 4 Jul 2013 04:17:08 -0400 (EDT) Subject: [Engine-devel] JsonMappingException on create pool In-Reply-To: <1318875933.5560395.1372924428709.JavaMail.root@redhat.com> References: <1318875933.5560395.1372924428709.JavaMail.root@redhat.com> Message-ID: <1369757615.33725328.1372925828967.JavaMail.root@redhat.com> Fixed and merged. ----- Original Message ----- > From: "Tomas Jelinek" > To: "engine-devel" > Sent: Thursday, July 4, 2013 10:53:48 AM > Subject: [Engine-devel] JsonMappingException on create pool > > Hey all, > > did anyone experienced problems creating a pool from a template with disk? > Currently rebased and built engine throws: > > Error during CreateTask for command: > org.ovirt.engine.core.bll.CreateSnapshotFromTemplateCommand. Exception > org.apache.commons.lang.SerializationException: > org.codehaus.jackson.map.JsonMappingException: Can not find a (Map) Key > deserializer for type [simple type, class > org.ovirt.engine.core.common.businessentities.VmDevice]: > org.apache.commons.lang.SerializationException: > org.codehaus.jackson.map.JsonMappingException: Can not find a (Map) Key > deserializer for type [simple type, class > org.ovirt.engine.core.common.businessentities.VmDevice] > > It does not happen when the template has no disks. > > More logs attached, > thank you, > Tomas > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From tjelinek at redhat.com Thu Jul 4 09:01:15 2013 From: tjelinek at redhat.com (Tomas Jelinek) Date: Thu, 4 Jul 2013 05:01:15 -0400 (EDT) Subject: [Engine-devel] JsonMappingException on create pool In-Reply-To: <1369757615.33725328.1372925828967.JavaMail.root@redhat.com> References: <1318875933.5560395.1372924428709.JavaMail.root@redhat.com> <1369757615.33725328.1372925828967.JavaMail.root@redhat.com> Message-ID: <1031047006.5578927.1372928475980.JavaMail.root@redhat.com> Rebased and built - works. Thank you! Tomas ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Tomas Jelinek" > Cc: "engine-devel" > Sent: Thursday, July 4, 2013 10:17:08 AM > Subject: Re: [Engine-devel] JsonMappingException on create pool > > Fixed and merged. > > > ----- Original Message ----- > > From: "Tomas Jelinek" > > To: "engine-devel" > > Sent: Thursday, July 4, 2013 10:53:48 AM > > Subject: [Engine-devel] JsonMappingException on create pool > > > > Hey all, > > > > did anyone experienced problems creating a pool from a template with disk? > > Currently rebased and built engine throws: > > > > Error during CreateTask for command: > > org.ovirt.engine.core.bll.CreateSnapshotFromTemplateCommand. Exception > > org.apache.commons.lang.SerializationException: > > org.codehaus.jackson.map.JsonMappingException: Can not find a (Map) Key > > deserializer for type [simple type, class > > org.ovirt.engine.core.common.businessentities.VmDevice]: > > org.apache.commons.lang.SerializationException: > > org.codehaus.jackson.map.JsonMappingException: Can not find a (Map) Key > > deserializer for type [simple type, class > > org.ovirt.engine.core.common.businessentities.VmDevice] > > > > It does not happen when the template has no disks. > > > > More logs attached, > > thank you, > > Tomas > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From mpastern at redhat.com Thu Jul 4 11:41:46 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 04 Jul 2013 14:41:46 +0300 Subject: [Engine-devel] [DEV-DEPLOY] [ ERROR ] Failed to execute stage 'Environment customization': Command '/bin/systemctl' failed to execute Message-ID: <51D55F7A.7040902@redhat.com> 2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd systemd.state:134 starting service firewalld 2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:366 execute: ('/bin/systemctl', 'start', 'firewalld.service'), executable='Non e', cwd='None', env=None 2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:383 execute-result: ('/bin/systemctl', 'start', 'firewalld.service'), rc=1 2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:441 execute-output: ('/bin/systemctl', 'start', 'firewalld.service') stdout: 2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:446 execute-output: ('/bin/systemctl', 'start', 'firewalld.service') stderr: Failed to issue method call: Access denied 2013-07-04 14:31:23 DEBUG otopi.context context._executeMethod:132 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 122, in _executeMethod method['method']() File "/usr/share/otopi/plugins/otopi/network/firewalld.py", line 142, in _customization self._firewalld_version = self._get_firewalld_cmd_version() File "/usr/share/otopi/plugins/otopi/network/firewalld.py", line 63, in _get_firewalld_cmd_version state=True, File "/usr/share/otopi/plugins/otopi/services/systemd.py", line 138, in state 'start' if state else 'stop' File "/usr/share/otopi/plugins/otopi/services/systemd.py", line 77, in _executeServiceCommand raiseOnError=raiseOnError File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in execute command=args[0], RuntimeError: Command '/bin/systemctl' failed to execute 2013-07-04 14:31:23 ERROR otopi.context context._executeMethod:141 Failed to execute stage 'Environment customization': Command '/bin/systemctl' failed to exec ute -- Michael Pasternak RedHat, ENG-Virtualization R&D From sbonazzo at redhat.com Thu Jul 4 12:18:53 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Thu, 04 Jul 2013 14:18:53 +0200 Subject: [Engine-devel] [DEV-DEPLOY] [ ERROR ] Failed to execute stage 'Environment customization': Command '/bin/systemctl' failed to execute In-Reply-To: <51D55F7A.7040902@redhat.com> References: <51D55F7A.7040902@redhat.com> Message-ID: <51D5682D.5010502@redhat.com> Can you try again using the [1] fix? [1] http://gerrit.ovirt.org/#/c/16397/ Il 04/07/2013 13:41, Michael Pasternak ha scritto: > 2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd systemd.state:134 starting service firewalld > 2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:366 execute: ('/bin/systemctl', 'start', 'firewalld.service'), executable='Non > e', cwd='None', env=None > 2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:383 execute-result: ('/bin/systemctl', 'start', 'firewalld.service'), rc=1 > 2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:441 execute-output: ('/bin/systemctl', 'start', 'firewalld.service') stdout: > > > 2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:446 execute-output: ('/bin/systemctl', 'start', 'firewalld.service') stderr: > Failed to issue method call: Access denied > > 2013-07-04 14:31:23 DEBUG otopi.context context._executeMethod:132 method exception > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 122, in _executeMethod > method['method']() > File "/usr/share/otopi/plugins/otopi/network/firewalld.py", line 142, in _customization > self._firewalld_version = self._get_firewalld_cmd_version() > File "/usr/share/otopi/plugins/otopi/network/firewalld.py", line 63, in _get_firewalld_cmd_version > state=True, > File "/usr/share/otopi/plugins/otopi/services/systemd.py", line 138, in state > 'start' if state else 'stop' > File "/usr/share/otopi/plugins/otopi/services/systemd.py", line 77, in _executeServiceCommand > raiseOnError=raiseOnError > File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 451, in execute > command=args[0], > RuntimeError: Command '/bin/systemctl' failed to execute > 2013-07-04 14:31:23 ERROR otopi.context context._executeMethod:141 Failed to execute stage 'Environment customization': Command '/bin/systemctl' failed to exec > ute > > -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From vszocs at redhat.com Thu Jul 4 14:07:19 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 4 Jul 2013 10:07:19 -0400 (EDT) Subject: [Engine-devel] Upgrading oVirt UI technology stack In-Reply-To: <671085824.5642168.1372946094562.JavaMail.root@redhat.com> Message-ID: <526288595.5644695.1372946839995.JavaMail.root@redhat.com> Hello everyone, I wrote a wiki page to summarize our effort to upgrade existing UI technology stack shared by oVirt web applications: http://www.ovirt.org/Features/GWT_Platform_Upgrade The wiki page divides GWT and GWTP changes into Essential and Non-essential. All Essential changes will be part of the initial upgrade patch (currently in progress), all Non-essential changes will be addressed later on, based on their priority. There's still one open issue (Essential change) related to GWTP framework, however we should come to a conclusion pretty soon. The corresponding (Essential change) patch will follow shortly after that. Any feedback is greatly appreciated, let me know what you think. Regards, Vojtech From iheim at redhat.com Thu Jul 4 18:59:40 2013 From: iheim at redhat.com (Itamar Heim) Date: Thu, 04 Jul 2013 21:59:40 +0300 Subject: [Engine-devel] Kudos to Allon Mureinik for his 1,000 patch merged Message-ID: <51D5C61C.5050403@redhat.com> While 1,000 is an arbitrary number, kudos to Allon for his 1,000 patch to ovirt-engine repo being merged[1]! (yes, a lot of these are cleanup patches, but these matter too). Thanks, Itamar [1] you can use 'git shortlog -sn' to get the full list. From lpeer at redhat.com Thu Jul 4 19:12:13 2013 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 04 Jul 2013 22:12:13 +0300 Subject: [Engine-devel] Kudos to Allon Mureinik for his 1, 000 patch merged In-Reply-To: <51D5C61C.5050403@redhat.com> References: <51D5C61C.5050403@redhat.com> Message-ID: <51D5C90D.1060601@redhat.com> Nice number, +1000 Next milestone 5k :) Livnat On 07/04/2013 09:59 PM, Itamar Heim wrote: > While 1,000 is an arbitrary number, kudos to Allon for his 1,000 patch > to ovirt-engine repo being merged[1]! > > (yes, a lot of these are cleanup patches, but these matter too). > > Thanks, > Itamar > > [1] you can use 'git shortlog -sn' to get the full list. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From dneary at redhat.com Sat Jul 6 18:31:29 2013 From: dneary at redhat.com (Dave Neary) Date: Sat, 06 Jul 2013 20:31:29 +0200 Subject: [Engine-devel] Kudos to Allon Mureinik for his 1, 000 patch merged In-Reply-To: <51D5C90D.1060601@redhat.com> References: <51D5C61C.5050403@redhat.com> <51D5C90D.1060601@redhat.com> Message-ID: <51D86281.2070208@redhat.com> Congratulations, and thanks, Allon! Dave. On 07/04/2013 09:12 PM, Livnat Peer wrote: > Nice number, +1000 > Next milestone 5k :) > > Livnat > > On 07/04/2013 09:59 PM, Itamar Heim wrote: >> While 1,000 is an arbitrary number, kudos to Allon for his 1,000 patch >> to ovirt-engine repo being merged[1]! >> >> (yes, a lot of these are cleanup patches, but these matter too). >> >> Thanks, >> Itamar >> >> [1] you can use 'git shortlog -sn' to get the full list. >> _______________________________________________ >> 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 > -- 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 laravot at redhat.com Sun Jul 7 05:41:33 2013 From: laravot at redhat.com (Liron Aravot) Date: Sun, 7 Jul 2013 01:41:33 -0400 (EDT) Subject: [Engine-devel] Kudos to Allon Mureinik for his 1, 000 patch merged In-Reply-To: <51D86281.2070208@redhat.com> References: <51D5C61C.5050403@redhat.com> <51D5C90D.1060601@redhat.com> <51D86281.2070208@redhat.com> Message-ID: <1132284338.32243.1373175693000.JavaMail.root@redhat.com> Congratulations! :) ----- Original Message ----- > From: "Dave Neary" > To: "Livnat Peer" > Cc: "engine-devel" > Sent: Saturday, July 6, 2013 9:31:29 PM > Subject: Re: [Engine-devel] Kudos to Allon Mureinik for his 1, 000 patch merged > > Congratulations, and thanks, Allon! > > Dave. > > On 07/04/2013 09:12 PM, Livnat Peer wrote: > > Nice number, +1000 > > Next milestone 5k :) > > > > Livnat > > > > On 07/04/2013 09:59 PM, Itamar Heim wrote: > >> While 1,000 is an arbitrary number, kudos to Allon for his 1,000 patch > >> to ovirt-engine repo being merged[1]! > >> > >> (yes, a lot of these are cleanup patches, but these matter too). > >> > >> Thanks, > >> Itamar > >> > >> [1] you can use 'git shortlog -sn' to get the full list. > >> _______________________________________________ > >> 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 > > > > -- > 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 amureini at redhat.com Sun Jul 7 06:53:01 2013 From: amureini at redhat.com (Allon Mureinik) Date: Sun, 7 Jul 2013 02:53:01 -0400 (EDT) Subject: [Engine-devel] Kudos to Allon Mureinik for his 1, 000 patch merged In-Reply-To: <51D5C61C.5050403@redhat.com> References: <51D5C61C.5050403@redhat.com> Message-ID: <729729239.154322.1373179981750.JavaMail.root@redhat.com> Thanks! Although I would have expected the milestone to be at 1024 :-) ----- Original Message ----- > From: "Itamar Heim" > To: "engine-devel" > Sent: Thursday, July 4, 2013 9:59:40 PM > Subject: [Engine-devel] Kudos to Allon Mureinik for his 1,000 patch merged > > While 1,000 is an arbitrary number, kudos to Allon for his 1,000 patch > to ovirt-engine repo being merged[1]! > > (yes, a lot of these are cleanup patches, but these matter too). > > Thanks, > Itamar > > [1] you can use 'git shortlog -sn' to get the full list. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From masayag at redhat.com Sun Jul 7 10:59:49 2013 From: masayag at redhat.com (Moti Asayag) Date: Sun, 7 Jul 2013 06:59:49 -0400 (EDT) Subject: [Engine-devel] VNIC profiles In-Reply-To: <51D02BB9.4090008@redhat.com> References: <51D02BB9.4090008@redhat.com> Message-ID: <1677136307.170396.1373194789480.JavaMail.root@redhat.com> Hi, I've updated the wiki with the feedbacks from this thread, added a backend section naming the affected commands and also add added few questions of my own embedded in the pastedtext below. In addition, another question here: The units within the UI mockups are Mb and Mbps. The libvirt APIs expects the units to be in kb and kbps. Which component is responsible to convert them to the expect units ? engine or VDSM ? Copied text from the wiki: Adding a Profile The network administrator could create several VNIC Profiles for each network. He could then grant a users with the permission to use (consume) each profile. The user will only be able to use profiles which he was granted access to. For example: the network admin will create two VNIC profiles for network "blue": Profile "Gold" - with better QoS and with port mirroring Profile "Silver" with lower QoS and without port mirroring. He will then define the user-group "students" as user of profile "Silver" and user-group "teachers" as user of profile "Gold". In this case the teachers will enjoy better quality of service then the students. When a teacher will add/edit a virtual NIC he could select profile "Gold" for that NIC - the VNIC will be connected to network "blue" with high QoS and with port mirroring. Question: In the same matter we allowed via the UI to grant 'NetworkUser' to 'everyone' user, wouldn't it ease the use of Profiles if we support it in this context as well? Editing a Profile A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id). Changing the network of a vNic profile will be allowed only if no VMs are using the profile. Since we have no way to distinguish between running and current configurations, the expected behavior of such a change is unpredictable and less intuitive to the user (especially since dynamic wiring is supported). The changes will seep down to all VNICs using the profile. In case VNIC using the edited profile are connected to running VMs, the change will apply only on the VM next run. Question: What about Hibernate/Suspend VM ? will the resume VM action uses the original configuration for the vnics when the VM was started ? Deleting a Profile VNIC Profiles could not be deleted from the engine as long as one or more VM/Templates are using those profiles. Reporting vNic actual configuration The engine will retrieve the actual configuration of the profile properties on the VNIC from VDSM (using the network statistics mechanism) and the networked administrator will be presented with the state of each VNIC (synched/unsynched). Editing a VNIC / Changing a VNIC profile Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running). Hot-plug of a vnic will will use will use the updated profile connected to the VNIC. Adding a Network When adding a network, a user can provide an option to create a vNic Profile for it. Question: Is it s default profile ? what are its properties ? Question: What about 'Public Use' option ? Are they still relevant in the context of adding new networks or we should eliminate them and move it only to 'Add vNic Profile' dialog? Updating a Network When a network role is modified to be a 'non-VM network', all vNic profiles associated with it should be deleted. Removing a Network Should remove all profiles on that network Adding an Empty Data-Center Currently, When creating a new Data-Center, the management network is automatically created. From 3.3, a default vNic profile will be created for the management network. VM snapshot/import/export We should handle VMs that are pointing to a network directly for backward compatibility. We need to select first profile that is on that network that the user has permissions on. Question: Do we wish to support it export from 3.3 and import to 3.2 or below? Question: A user can import/export a VM/Template even if he doesn't have permissions on the networks. Is the next flow valid ? The profile name should be saved in the OVF (in addition to the network name which is saved today). During import, if both (network name, profile name) exist on the target DC, the vnic will get the profile id. If the network exists in the Data-Center, but has no profile as specified in the OVF, the user will be notified (event log) and the VNIC will be connected to a default minimal profile defined in the system, regardless the permissions the user has on the network. If failed to find any matching vNic profile, the vnic's profile will be set with 'none'. When a Template is created from a VM the VNIC Profile will be kept along with the VNIC. When a VM is created from template the VNIC Profiles will be taken from the template's VNICs. ----- Original Message ----- > From: "Livnat Peer" > To: "engine-devel" , "Ofri Masad" > Cc: "Mike Kolesnik" , "Moti Asayag" , "Oved Ourfalli" > Sent: Sunday, June 30, 2013 3:59:37 PM > Subject: VNIC profiles > > Hi, > > We are working on adding VNIC profiles as part of the work to add VNIC QoS. > > http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles > > We need to define some of the system behavior followed by this change, > here is my take - > > Editing a profile - > -------------------- > A user should be able to edit the profile properties (including profile > name) while VMs are attached and are using this Profile (reference > should be done by id). > > Changing the network though is a bit more tricky as long as we don't > have a way to distinguish between running and current configurations I > think it could be very confusing to the user. Especially since we > support dynamic wiring so the behavior IMO is unpredictable. > I think it should be blocked at this point. > > > Edit a VNIC / change a VNIC profile - > ------------------------------------ > Changing the profile a VM is using while the VM is running should behave > like dynamic wiring (changing the VM network while it is running). > > > Remove a Profile - > ------------------- > Is only valid if all VMs that are using this profile are in status down. > It should update all VMs to point to no profile which should behave like > none network today. > > I see no reason to support a profile on a none network at this point. > > The above is also relevant for upgrade flow (upgrading none network to > point to no profile) > > > Removing a Network - > ---------------------- > should remove all profiles on that network > > > VM snapshot/import/export - > -------------------------- > We should handle VMs that are pointing to a network directly for b/w > compatibility. > we need to select first profile that is on that network that the user > has permissions on. > > > I assume there are more, comments are welcome > > Thanks, Livnat > > From kiril at redhat.com Sun Jul 7 11:02:03 2013 From: kiril at redhat.com (Kiril Nesenko) Date: Sun, 7 Jul 2013 07:02:03 -0400 (EDT) Subject: [Engine-devel] Linkedin oVirt company profile In-Reply-To: <233507200.142057.1373194648304.JavaMail.root@redhat.com> Message-ID: <506443926.142229.1373194923007.JavaMail.root@redhat.com> Hello, I would like to introduce the new company profile[1] for oVirt project. You are more than welcome to join and follow the company profile. [1] http://www.linkedin.com/company/ovirt?trk=top_nav_home - Kiril From lpeer at redhat.com Sun Jul 7 11:59:34 2013 From: lpeer at redhat.com (Livnat Peer) Date: Sun, 07 Jul 2013 14:59:34 +0300 Subject: [Engine-devel] VNIC profiles In-Reply-To: <1677136307.170396.1373194789480.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> Message-ID: <51D95826.40009@redhat.com> On 07/07/2013 01:59 PM, Moti Asayag wrote: > Hi, > > I've updated the wiki with the feedbacks from this thread, added a backend section naming the affected commands and also add added few questions of my own embedded in the pastedtext below. > Hi Moti, A good and comprehensive description of the feature behavior. See my comments bellow - > In addition, another question here: > > The units within the UI mockups are Mb and Mbps. The libvirt APIs expects the units to be in kb and kbps. Which component is responsible to convert them to the expect units ? engine or VDSM ? Giuseppe mentioned that in a previous thread on this subject. Ofri and Giuseppe agreed that the translation would be done on the engine level. > > Copied text from the wiki: > > Adding a Profile > > The network administrator could create several VNIC Profiles for each network. He could then grant a users with the permission to use (consume) each profile. The user will only be able to use profiles which he was granted access to. > > For example: the network admin will create two VNIC profiles for network "blue": > > Profile "Gold" - with better QoS and with port mirroring > Profile "Silver" with lower QoS and without port mirroring. > I would use other names for the profiles to avoid confusion. Gold and Silver are likely to be QoS object names, a more typical name for a network profile is - teachers-blue and students-blue The different profiles can have different QoS (teachers-blue would get Gold QoS while Students-blue will have Silver). > He will then define the user-group "students" as user of profile "Silver" and user-group "teachers" as user of profile "Gold". In this case the teachers will enjoy better quality of service then the students. When a teacher will add/edit a virtual NIC he could select profile "Gold" for that NIC - the VNIC will be connected to network "blue" with high QoS and with port mirroring. > > Question: In the same matter we allowed via the UI to grant 'NetworkUser' to 'everyone' user, wouldn't it ease the use of Profiles if we support it in this context as well? The ease of use could be that when creating a network we'll display in the UI all VNIC-QoS-objects and the users could tick next to the QoS they are interested in, for each QoS that was chosen a profile would be created. I would enhance that with youe suggestion above and display next to the QoS that was checked the option to mark 'Allow All users' like we have today for making a network public, this option would give permission to everyone on that profile. > > Editing a Profile > > A user should be able to edit the profile properties (including profile name) while VMs are attached and are using this Profile (reference should be done by id). > Changing the network of a vNic profile will be allowed only if no VMs are using the profile. It would be better if we can limit this to no running VM is using the profile (or more simple to implement if all VMs that are using this profile are in status down). > Since we have no way to distinguish between running and current configurations, the expected behavior of such a change is unpredictable and less intuitive to the user (especially since dynamic wiring is supported). > The changes will seep down to all VNICs using the profile. > In case VNIC using the edited profile are connected to running VMs, the change will apply only on the VM next run. > > Question: What about Hibernate/Suspend VM ? will the resume VM action uses the original configuration for the vnics when the VM was started ? Currently profile includes: network, port-mirroring, custom property, QoS Changing any of the above (except for network) requires a VM reboot, so I think that we can start with the following statement - the profile change would only apply after next VM reboot. There are 2 problems with the above: - Today we support network wiring, with VNIC profiles we are asking the users to create a new profile and attach the VMs to the new profile, I can see the RFE coming - we can report that ourselves ;) - We don't reflect with which configuration the VM is running, e.g we edited the profile QoS but I'm not sure with which QoS the VM is currently running. (The RFE for differentiating between current configuration and running configuration was already asked for by numerous users) The above is a general issue that we need to solve and I would not limit editing VNIC profiles because of it. We can mitigate this specifically for QoS like described bellow. > Deleting a Profile > > VNIC Profiles could not be deleted from the engine as long as one or more VM/Templates are using those profiles. > Reporting vNic actual configuration > > The engine will retrieve the actual configuration of the profile properties on the VNIC from VDSM (using the network statistics mechanism) and the networked administrator will be presented with the state of each VNIC (synched/unsynched). > Will the admin be able to see the actual values? I think the synced property is not enough (I'm not sure how interesting this property is to start with). > Editing a VNIC / Changing a VNIC profile > > Changing the profile a VM is using while the VM is running should behave like dynamic wiring (changing the VM network while it is running). > Hot-plug of a vnic will will use will use the updated profile connected to the VNIC. > Not sure I fully understand the sentence above. Hot plug will be fully supported, you can choose any profile (you have permissions on) while plugging a new device. > Adding a Network > > When adding a network, a user can provide an option to create a vNic Profile for it. > > Question: Is it s default profile ? what are its properties ? > Question: What about 'Public Use' option ? Are they still relevant in the context of adding new networks or we should eliminate them and move it only to 'Add vNic Profile' dialog? > see previous comments In addition when creating a profile we should have 'Allow all' for implicitly creating permissions, like we have today for network. > Updating a Network > > When a network role is modified to be a 'non-VM network', all vNic profiles associated with it should be deleted. And permissions associated with these profiles > Removing a Network > > Should remove all profiles on that network > And associated permissions > Adding an Empty Data-Center > > Currently, When creating a new Data-Center, the management network is automatically created. > From 3.3, a default vNic profile will be created for the management network. > > VM snapshot/import/export > > We should handle VMs that are pointing to a network directly for backward compatibility. > We need to select first profile that is on that network that the user has permissions on. > > Question: Do we wish to support it export from 3.3 and import to 3.2 or below? That means that when you write a VM in the OVF you need to write network in addition to profile. > Question: A user can import/export a VM/Template even if he doesn't have permissions on the networks. Is the next flow valid ? > > The profile name should be saved in the OVF (in addition to the network name which is saved today). > During import, if both (network name, profile name) exist on the target DC, the vnic will get the profile id. > If the network exists in the Data-Center, but has no profile as specified in the OVF, the user will be notified (event log) and the VNIC will be connected to a default minimal profile defined in the system, regardless the permissions the user has on the network. > What is a 'default minimal profile' ? I would rather have a VNIC with no profile associated with it. > If failed to find any matching vNic profile, the vnic's profile will be set with 'none'. > > When a Template is created from a VM the VNIC Profile will be kept along with the VNIC. When a VM is created from template the VNIC Profiles will be taken from the template's VNICs. > > ----- Original Message ----- >> From: "Livnat Peer" >> To: "engine-devel" , "Ofri Masad" >> Cc: "Mike Kolesnik" , "Moti Asayag" , "Oved Ourfalli" >> Sent: Sunday, June 30, 2013 3:59:37 PM >> Subject: VNIC profiles >> >> Hi, >> >> We are working on adding VNIC profiles as part of the work to add VNIC QoS. >> >> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles >> >> We need to define some of the system behavior followed by this change, >> here is my take - >> >> Editing a profile - >> -------------------- >> A user should be able to edit the profile properties (including profile >> name) while VMs are attached and are using this Profile (reference >> should be done by id). >> >> Changing the network though is a bit more tricky as long as we don't >> have a way to distinguish between running and current configurations I >> think it could be very confusing to the user. Especially since we >> support dynamic wiring so the behavior IMO is unpredictable. >> I think it should be blocked at this point. >> >> >> Edit a VNIC / change a VNIC profile - >> ------------------------------------ >> Changing the profile a VM is using while the VM is running should behave >> like dynamic wiring (changing the VM network while it is running). >> >> >> Remove a Profile - >> ------------------- >> Is only valid if all VMs that are using this profile are in status down. >> It should update all VMs to point to no profile which should behave like >> none network today. >> >> I see no reason to support a profile on a none network at this point. >> >> The above is also relevant for upgrade flow (upgrading none network to >> point to no profile) >> >> >> Removing a Network - >> ---------------------- >> should remove all profiles on that network >> >> >> VM snapshot/import/export - >> -------------------------- >> We should handle VMs that are pointing to a network directly for b/w >> compatibility. >> we need to select first profile that is on that network that the user >> has permissions on. >> >> >> I assume there are more, comments are welcome >> >> Thanks, Livnat >> >> From eedri at redhat.com Sun Jul 7 14:02:23 2013 From: eedri at redhat.com (Eyal Edri) Date: Sun, 7 Jul 2013 10:02:23 -0400 (EDT) Subject: [Engine-devel] [Users] Linkedin oVirt company profile In-Reply-To: <506443926.142229.1373194923007.JavaMail.root@redhat.com> References: <506443926.142229.1373194923007.JavaMail.root@redhat.com> Message-ID: <492176035.180098.1373205743663.JavaMail.root@redhat.com> +1.. great, i'm following it. who's maintaining it now? (i.e adding news/events on future workshops and such) ----- Original Message ----- > From: "Kiril Nesenko" > To: "infra" , engine-devel at ovirt.org, users at ovirt.org > Sent: Sunday, July 7, 2013 2:02:03 PM > Subject: [Users] Linkedin oVirt company profile > > Hello, > > I would like to introduce the new company profile[1] for oVirt project. > You are more than welcome to join and follow the company profile. > > [1] http://www.linkedin.com/company/ovirt?trk=top_nav_home > > - Kiril > _______________________________________________ > Users mailing list > Users at ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > From amureini at redhat.com Sun Jul 7 15:43:24 2013 From: amureini at redhat.com (Allon Mureinik) Date: Sun, 7 Jul 2013 11:43:24 -0400 (EDT) Subject: [Engine-devel] Guid improvements In-Reply-To: References: <207761917.1453625.1372579890708.JavaMail.root@redhat.com> <1510804261.30673992.1372580036122.JavaMail.root@redhat.com> <64DD4754-E88A-4FF2-94BA-3B1F2B2D2BA5@gmail.com> <1721413331.1635156.1372663791629.JavaMail.root@redhat.com> Message-ID: <1932465423.186540.1373211804413.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Liran Zelkha" > To: "Allon Mureinik" > Cc: "Yair Zaslavsky" , "engine-devel" > > Sent: Monday, July 1, 2013 10:36:06 AM > Subject: Re: [Engine-devel] Guid improvements > Awesome!!! > On Mon, Jul 1, 2013 at 10:29 AM, Allon Mureinik < amureini at redhat.com > > wrote: > > ----- Original Message ----- > > > > From: "Liran Zelkha" < liran.zelkha at gmail.com > > > > > To: "Yair Zaslavsky" < yzaslavs at redhat.com > > > > > Cc: "Allon Mureinik" < amureini at redhat.com >, "engine-devel" < > > > engine-devel at ovirt.org > > > > > Sent: Sunday, June 30, 2013 11:37:26 AM > > > > Subject: Re: [Engine-devel] Guid improvements > > > > > > > > Great news. > > > > Allon - please note that GUID is being recreated from String by both DB > > > calls > > > > and by data received from VDSM. It is VERY useful to cache Guid > > > > String-->Guid, and not just Empty GUID. > > > I generally agree about the high cost of sting<->uuid operations, but I'm > > not > > sure caching is the way to go, at least not everywhere. > > > At least for the database, there is a much easier solution - stop using > > strings to represent uuids. > > > Here's an example of how it can be done: > > > http://gerrit.ovirt.org/#/c/16281/ This patchset was merged [1]. Along with a couple of uber-neat improvements by Juan [2][3], I think we should see a real boost in performance. [1] http://gerrit.ovirt.org/#/q/status:merged+project:ovirt-engine+branch:master+topic:guid-database-improvements,n,z [2] http://gerrit.ovirt.org/#/c/16421/ [3] http://gerrit.ovirt.org/#/c/16467/ > > > > > > > > However, as the Guid class runs in GWT as well, you can't use Infinispan > > > and > > > > you're limited in the HashMap implementations you can use. Personally, I > > > > don't think it's a memory leak, as GUID number in the system are finite > > > and > > > > not too large. What do you think? Want to add it to your patch? > > > > > > > > On Jun 30, 2013, at 11:13 AM, Yair Zaslavsky wrote: > > > > > > > > > Well done, should have been done ages ago :) > > > > > Now, for the painful rebase of async_task_mgr changes :) > > > > > > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Allon Mureinik" < amureini at redhat.com > > > > > >> To: "engine-devel" < engine-devel at ovirt.org >, "Barak Azulay" > > > > >> < bazulay at redhat.com > > > > > >> Cc: "Yair Zaslavsky" < yzaslavs at redhat.com >, "Michael Pasternak" > > > > >> < mpastern at redhat.com >, "Tal Nisan" > > > > >> < tnisan at redhat.com >, "Ayal Baron" < abaron at redhat.com > > > > > >> Sent: Sunday, June 30, 2013 11:11:30 AM > > > > >> Subject: Guid improvements > > > > >> > > > > >> Hi all, > > > > >> > > > > >> I just merged a couple of improvements to the [N]Guid class [1] to > > > >> improve > > > > >> it's performance both CPU-wise and memory-wise, based on a set of > > > > >> benchmarks > > > > >> presented by Liran. > > > > >> > > > > >> What this patchset achieves: > > > > >> 1. Clean up the code, so it's easier to understand and use > > > > >> 2. Eliminate the inflation in the memory foot print caused by the > > > > >> getValue() > > > > >> method > > > > >> 3. Eliminate all the heavy calls to UUID.fromString when creating a > > > > >> new/empty > > > > >> Guid instance as a default value > > > > >> 4. Note that the cleanups proposed in (1) will have minor performance > > > > >> benefits (e.g., eliminating useless conditional statements), but I > > > >> doubt > > > > >> this would be anything to write home about. > > > > >> > > > > >> From a developer's perspective, here's what changed: > > > > >> 1. No more NGuid, just Guid. Both static methods to create a Guid from > > > > >> String > > > > >> still exist, and are named createGuidFromString and > > > > >> createGuidFromStringDefaultEmpty. > > > > >> 2. [N]Guid.getValue() was removed, it's no longer needed after (1) was > > > > >> implemented > > > > >> 3. The Guid() constructor was made private, as it forced a redundant > > > >> call > > > > >> to > > > > >> UUID.fromString(String). If you need an empty Guid instance, just use > > > > >> Guid.Empty > > > > >> 4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was > > > >> used > > > > >> for > > > > >> redundant calls to UUID.fromString. If you really, REALLY, need it, > > > >> just > > > > >> call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a > > > > >> String. > > > > >> 5. All sorts of ways to transform Strings to Guids were removed. If > > > >> you > > > > >> have > > > > >> a literal you trust, just use new Guid(String). If you suspect it may > > > >> be > > > > >> null, use Guid.createGuidFromString[DefaultEmpty] > > > > >> 6. NewGuid is now called newGuid. We're in Java, not C# :-) > > > > >> > > > > >> > > > > >> Many thanks to everyone who reviewed this patchset. > > > > >> You guys rock! > > > > >> > > > > >> > > > > >> Regards, > > > > >> Allon > > > > >> > > > > >> > > > > >> [1] > > > > >> http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:guid-cleanup,n,z > > > > >> > > > > > _______________________________________________ > > > > > Engine-devel mailing list > > > > > Engine-devel at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > From masayag at redhat.com Sun Jul 7 21:36:55 2013 From: masayag at redhat.com (Moti Asayag) Date: Sun, 7 Jul 2013 17:36:55 -0400 (EDT) Subject: [Engine-devel] VNIC profiles In-Reply-To: <51D95826.40009@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> <51D95826.40009@redhat.com> Message-ID: <562865353.219690.1373233015552.JavaMail.root@redhat.com> I've updated the wiki accordingly and added few comments inline. ----- Original Message ----- > From: "Livnat Peer" > To: "Moti Asayag" > Cc: "engine-devel" , "Ofri Masad" , "Mike Kolesnik" , > "Oved Ourfalli" > Sent: Sunday, July 7, 2013 2:59:34 PM > Subject: Re: VNIC profiles > > On 07/07/2013 01:59 PM, Moti Asayag wrote: > > Hi, > > > > I've updated the wiki with the feedbacks from this thread, added a backend > > section naming the affected commands and also add added few questions of > > my own embedded in the pastedtext below. > > > > Hi Moti, > A good and comprehensive description of the feature behavior. > See my comments bellow - > > > In addition, another question here: > > > > The units within the UI mockups are Mb and Mbps. The libvirt APIs expects > > the units to be in kb and kbps. Which component is responsible to convert > > them to the expect units ? engine or VDSM ? > > Giuseppe mentioned that in a previous thread on this subject. > Ofri and Giuseppe agreed that the translation would be done on the > engine level. > > > > > > Copied text from the wiki: > > > > Adding a Profile > > > > The network administrator could create several VNIC Profiles for each > > network. He could then grant a users with the permission to use (consume) > > each profile. The user will only be able to use profiles which he was > > granted access to. > > > > For example: the network admin will create two VNIC profiles for > > network "blue": > > > > Profile "Gold" - with better QoS and with port mirroring > > Profile "Silver" with lower QoS and without port mirroring. > > > > I would use other names for the profiles to avoid confusion. > Gold and Silver are likely to be QoS object names, a more typical name > for a network profile is - teachers-blue and students-blue > > The different profiles can have different QoS (teachers-blue would get > Gold QoS while Students-blue will have Silver). > > > > He will then define the user-group "students" as user of profile > > "Silver" and user-group "teachers" as user of profile "Gold". In this > > case the teachers will enjoy better quality of service then the > > students. When a teacher will add/edit a virtual NIC he could select > > profile "Gold" for that NIC - the VNIC will be connected to network > > "blue" with high QoS and with port mirroring. > > > > Question: In the same matter we allowed via the UI to grant 'NetworkUser' > > to 'everyone' user, wouldn't it ease the use of Profiles if we support it > > in this context as well? > > The ease of use could be that when creating a network we'll display in > the UI all VNIC-QoS-objects and the users could tick next to the QoS > they are interested in, for each QoS that was chosen a profile would be > created. > > I would enhance that with youe suggestion above and display next to the > QoS that was checked the option to mark 'Allow All users' like we have > today for making a network public, this option would give permission to > everyone on that profile. > > > > > > Editing a Profile > > > > A user should be able to edit the profile properties (including profile > > name) while VMs are attached and are using this Profile (reference > > should be done by id). > > Changing the network of a vNic profile will be allowed only if no VMs > > are using the profile. > > It would be better if we can limit this to no running VM is using the > profile (or more simple to implement if all VMs that are using this > profile are in status down). Allowing to delete a vnic profile when used by vms is asymmetric to the network removal when it is used by vms or templates. Today the update network operation is blocked for that. In addition, with the suggest simplification to remove a profile when no running vms, the user will have to find for himself if the profile is being used prior to its removal since the operation will not be blocked. If we allow to delete a vnic profile, when a vm is using it (regardless the VM status) we'll have to update the VM entity as well in that operation: since we do not support a network with 'none' profile, we'll have to delete the network as well. If we'll remove a vnic profile in 3.1 cluster, used by vms in status down, we'd find a case in which a VM is attached to a 'none' network. This is unsupported in 3.1 cluster. We can block such operation, but this is another motivation why we'd better not to allow removing a used profile. > > > Since we have no way to distinguish between running and current > > configurations, the expected behavior of such a change is > > unpredictable and less intuitive to the user (especially since > > dynamic wiring is supported). > > The changes will seep down to all VNICs using the profile. > > In case VNIC using the edited profile are connected to running VMs, > > the change will apply only on the VM next run. > > > > Question: What about Hibernate/Suspend VM ? will the resume VM action uses > > the original configuration for the vnics when the VM was started ? > > Currently profile includes: network, port-mirroring, custom property, QoS > > Changing any of the above (except for network) requires a VM reboot, so > I think that we can start with the following statement - the profile > change would only apply after next VM reboot. > > There are 2 problems with the above: > - Today we support network wiring, with VNIC profiles we are asking the > users to create a new profile and attach the VMs to the new profile, I > can see the RFE coming - we can report that ourselves ;) > > - We don't reflect with which configuration the VM is running, e.g we > edited the profile QoS but I'm not sure with which QoS the VM is > currently running. (The RFE for differentiating between current > configuration and running configuration was already asked for by > numerous users) > > The above is a general issue that we need to solve and I would not limit > editing VNIC profiles because of it. > We can mitigate this specifically for QoS like described bellow. > > > > > Deleting a Profile > > > > VNIC Profiles could not be deleted from the engine as long as one or more > > VM/Templates are using those profiles. > > > Reporting vNic actual configuration > > > > The engine will retrieve the actual configuration of the profile > > properties on the VNIC from VDSM (using the network statistics > > mechanism) and the networked administrator will be presented with the > > state of each VNIC (synched/unsynched). > > > > Will the admin be able to see the actual values? I think the synced > property is not enough (I'm not sure how interesting this property is to > start with). We can extend the VmGuestAgentInterface to contain the actual value, so they will be presented for each vnic in the 'guest data' sub-tab. > > > Editing a VNIC / Changing a VNIC profile > > > > Changing the profile a VM is using while the VM is running should > > behave like dynamic wiring (changing the VM network while it is > > running). > > Hot-plug of a vnic will will use will use the updated profile connected > > to the VNIC. > > > > Not sure I fully understand the sentence above. > Hot plug will be fully supported, you can choose any profile (you have > permissions on) while plugging a new device. > That was the intention. seems like an edgy hand syndrome :) Changed to: * Hot plug will be fully supported: the user can choose any permitted profile while plugging a new device or when activating an existing one. > > Adding a Network > > > > When adding a network, a user can provide an option to create a vNic > > Profile for it. > > > > Question: Is it s default profile ? what are its properties ? > > Question: What about 'Public Use' option ? Are they still relevant in the > > context of adding new networks or we should eliminate them and move it > > only to 'Add vNic Profile' dialog? > > > > see previous comments > In addition when creating a profile we should have 'Allow all' for > implicitly creating permissions, like we have today for network. > > > Updating a Network > > > > When a network role is modified to be a 'non-VM network', all vNic profiles > > associated with it should be deleted. > > And permissions associated with these profiles > > > Removing a Network > > > > Should remove all profiles on that network > > > > And associated permissions > > > Adding an Empty Data-Center > > > > Currently, When creating a new Data-Center, the management network is > > automatically created. > > From 3.3, a default vNic profile will be created for the management > > network. > > > > VM snapshot/import/export > > > > We should handle VMs that are pointing to a network directly for > > backward compatibility. > > We need to select first profile that is on that network that the user > > has permissions on. > > > > Question: Do we wish to support it export from 3.3 and import to 3.2 or > > below? > > That means that when you write a VM in the OVF you need to write network > in addition to profile. > The network name is already there, so when importing a vnic from 3.3 to an earlier version the profile name will be ignored. > > > Question: A user can import/export a VM/Template even if he doesn't have > > permissions on the networks. Is the next flow valid ? > > > > The profile name should be saved in the OVF (in addition to the network > > name which is saved today). > > During import, if both (network name, profile name) exist on the target > > DC, the vnic will get the profile id. > > If the network exists in the Data-Center, but has no profile as > > specified in the OVF, the user will be notified (event log) and the > > VNIC will be connected to a default minimal profile defined in the > > system, regardless the permissions the user has on the network. > > > > What is a 'default minimal profile' ? I would rather have a VNIC with no > profile associated with it. The 'default minimal profile' refers to a vnic profile with the lower average bandwidth. With the approach you've suggested, any imported VM/Template from an earlier to 3.3 version will require a manual intervention in order to configure a network to the VM. And for 3.1 we'll have to drop such vnics since network 'none' isn't supported. > > > If failed to find any matching vNic profile, the vnic's profile will be set > > with 'none'. > > > > When a Template is created from a VM the VNIC Profile will be kept > > along with the VNIC. When a VM is created from template the VNIC > > Profiles will be taken from the template's VNICs. > > > > ----- Original Message ----- > >> From: "Livnat Peer" > >> To: "engine-devel" , "Ofri Masad" > >> > >> Cc: "Mike Kolesnik" , "Moti Asayag" > >> , "Oved Ourfalli" > >> Sent: Sunday, June 30, 2013 3:59:37 PM > >> Subject: VNIC profiles > >> > >> Hi, > >> > >> We are working on adding VNIC profiles as part of the work to add VNIC > >> QoS. > >> > >> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles > >> > >> We need to define some of the system behavior followed by this change, > >> here is my take - > >> > >> Editing a profile - > >> -------------------- > >> A user should be able to edit the profile properties (including profile > >> name) while VMs are attached and are using this Profile (reference > >> should be done by id). > >> > >> Changing the network though is a bit more tricky as long as we don't > >> have a way to distinguish between running and current configurations I > >> think it could be very confusing to the user. Especially since we > >> support dynamic wiring so the behavior IMO is unpredictable. > >> I think it should be blocked at this point. > >> > >> > >> Edit a VNIC / change a VNIC profile - > >> ------------------------------------ > >> Changing the profile a VM is using while the VM is running should behave > >> like dynamic wiring (changing the VM network while it is running). > >> > >> > >> Remove a Profile - > >> ------------------- > >> Is only valid if all VMs that are using this profile are in status down. > >> It should update all VMs to point to no profile which should behave like > >> none network today. > >> > >> I see no reason to support a profile on a none network at this point. > >> > >> The above is also relevant for upgrade flow (upgrading none network to > >> point to no profile) > >> > >> > >> Removing a Network - > >> ---------------------- > >> should remove all profiles on that network > >> > >> > >> VM snapshot/import/export - > >> -------------------------- > >> We should handle VMs that are pointing to a network directly for b/w > >> compatibility. > >> we need to select first profile that is on that network that the user > >> has permissions on. > >> > >> > >> I assume there are more, comments are welcome > >> > >> Thanks, Livnat > >> > >> > > From wlbleaboy at 126.com Mon Jul 8 06:04:27 2013 From: wlbleaboy at 126.com (wlbleaboy@126) Date: Mon, 8 Jul 2013 14:04:27 +0800 Subject: [Engine-devel] about vm in vmpool Message-ID: <004c01ce7ba1$15468fa0$3fd3aee0$@com> Hi, all: I have using ovirt-sdk 3 monthes, I can use ovirt-sdk get vm's infomations like vm's name, vm's id, vm'ticket etc. but recently, I have a question about vm in vmpool, how could I get vm's information that the vm in vmpool. Especially, when a vm is at stop statuss. For example, when use UserPortal in the web-browser, no matter the vm is in the vmpool, it can be showed in the web-browser, but, I can't get vm' s information which in the vmpool via the ovirt-sdk. Leaboy thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpeer at redhat.com Mon Jul 8 07:11:15 2013 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 08 Jul 2013 10:11:15 +0300 Subject: [Engine-devel] VNIC profiles In-Reply-To: <562865353.219690.1373233015552.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> Message-ID: <51DA6613.9040903@redhat.com> On 07/08/2013 12:36 AM, Moti Asayag wrote: > I've updated the wiki accordingly and added few comments inline. > > ----- Original Message ----- >> From: "Livnat Peer" >> To: "Moti Asayag" >> Cc: "engine-devel" , "Ofri Masad" , "Mike Kolesnik" , >> "Oved Ourfalli" >> Sent: Sunday, July 7, 2013 2:59:34 PM >> Subject: Re: VNIC profiles >> >> On 07/07/2013 01:59 PM, Moti Asayag wrote: >>> Hi, >>> >>> I've updated the wiki with the feedbacks from this thread, added a backend >>> section naming the affected commands and also add added few questions of >>> my own embedded in the pastedtext below. >>> >> >> Hi Moti, >> A good and comprehensive description of the feature behavior. >> See my comments bellow - >> >>> In addition, another question here: >>> >>> The units within the UI mockups are Mb and Mbps. The libvirt APIs expects >>> the units to be in kb and kbps. Which component is responsible to convert >>> them to the expect units ? engine or VDSM ? >> >> Giuseppe mentioned that in a previous thread on this subject. >> Ofri and Giuseppe agreed that the translation would be done on the >> engine level. >> >> >>> >>> Copied text from the wiki: >>> >>> Adding a Profile >>> >>> The network administrator could create several VNIC Profiles for each >>> network. He could then grant a users with the permission to use (consume) >>> each profile. The user will only be able to use profiles which he was >>> granted access to. >>> >>> For example: the network admin will create two VNIC profiles for >>> network "blue": >>> >>> Profile "Gold" - with better QoS and with port mirroring >>> Profile "Silver" with lower QoS and without port mirroring. >>> >> >> I would use other names for the profiles to avoid confusion. >> Gold and Silver are likely to be QoS object names, a more typical name >> for a network profile is - teachers-blue and students-blue >> >> The different profiles can have different QoS (teachers-blue would get >> Gold QoS while Students-blue will have Silver). >> >> >>> He will then define the user-group "students" as user of profile >>> "Silver" and user-group "teachers" as user of profile "Gold". In this >>> case the teachers will enjoy better quality of service then the >>> students. When a teacher will add/edit a virtual NIC he could select >>> profile "Gold" for that NIC - the VNIC will be connected to network >>> "blue" with high QoS and with port mirroring. >>> >>> Question: In the same matter we allowed via the UI to grant 'NetworkUser' >>> to 'everyone' user, wouldn't it ease the use of Profiles if we support it >>> in this context as well? >> >> The ease of use could be that when creating a network we'll display in >> the UI all VNIC-QoS-objects and the users could tick next to the QoS >> they are interested in, for each QoS that was chosen a profile would be >> created. >> >> I would enhance that with youe suggestion above and display next to the >> QoS that was checked the option to mark 'Allow All users' like we have >> today for making a network public, this option would give permission to >> everyone on that profile. >> >> >>> >>> Editing a Profile >>> >>> A user should be able to edit the profile properties (including profile >>> name) while VMs are attached and are using this Profile (reference >>> should be done by id). >>> Changing the network of a vNic profile will be allowed only if no VMs >>> are using the profile. >> >> It would be better if we can limit this to no running VM is using the >> profile (or more simple to implement if all VMs that are using this >> profile are in status down). > > Allowing to delete a vnic profile when used by vms is asymmetric to the network removal > when it is used by vms or templates. Today the update network operation is blocked for that. > In addition, with the suggest simplification to remove a profile when no running vms, the user > will have to find for himself if the profile is being used prior to its removal since the > operation will not be blocked. > > If we allow to delete a vnic profile, when a vm is using it (regardless the VM status) > we'll have to update the VM entity as well in that operation: since we do not support a > network with 'none' profile, we'll have to delete the network as well. > > If we'll remove a vnic profile in 3.1 cluster, used by vms in status down, we'd find a case > in which a VM is attached to a 'none' network. This is unsupported in 3.1 cluster. We can block > such operation, but this is another motivation why we'd better not to allow removing a used profile. > The context above is about editing not deleting :) I agree with what you wrote if the context was remove. >> >>> Since we have no way to distinguish between running and current >>> configurations, the expected behavior of such a change is >>> unpredictable and less intuitive to the user (especially since >>> dynamic wiring is supported). >>> The changes will seep down to all VNICs using the profile. >>> In case VNIC using the edited profile are connected to running VMs, >>> the change will apply only on the VM next run. >>> >>> Question: What about Hibernate/Suspend VM ? will the resume VM action uses >>> the original configuration for the vnics when the VM was started ? >> >> Currently profile includes: network, port-mirroring, custom property, QoS >> >> Changing any of the above (except for network) requires a VM reboot, so >> I think that we can start with the following statement - the profile >> change would only apply after next VM reboot. >> >> There are 2 problems with the above: >> - Today we support network wiring, with VNIC profiles we are asking the >> users to create a new profile and attach the VMs to the new profile, I >> can see the RFE coming - we can report that ourselves ;) >> >> - We don't reflect with which configuration the VM is running, e.g we >> edited the profile QoS but I'm not sure with which QoS the VM is >> currently running. (The RFE for differentiating between current >> configuration and running configuration was already asked for by >> numerous users) >> >> The above is a general issue that we need to solve and I would not limit >> editing VNIC profiles because of it. >> We can mitigate this specifically for QoS like described bellow. >> >> >> >>> Deleting a Profile >>> >>> VNIC Profiles could not be deleted from the engine as long as one or more >>> VM/Templates are using those profiles. >> >>> Reporting vNic actual configuration >>> >>> The engine will retrieve the actual configuration of the profile >>> properties on the VNIC from VDSM (using the network statistics >>> mechanism) and the networked administrator will be presented with the >>> state of each VNIC (synched/unsynched). >>> >> >> Will the admin be able to see the actual values? I think the synced >> property is not enough (I'm not sure how interesting this property is to >> start with). > > We can extend the VmGuestAgentInterface to contain the actual value, so they > will be presented for each vnic in the 'guest data' sub-tab. > AFAIU this info does not come from the guest it is info we retrieve from libvirt. The VmGuestAgentInterface should be used only for information reported by the guest, information whose credibility can be questioned. >> >>> Editing a VNIC / Changing a VNIC profile >>> >>> Changing the profile a VM is using while the VM is running should >>> behave like dynamic wiring (changing the VM network while it is >>> running). >>> Hot-plug of a vnic will will use will use the updated profile connected >>> to the VNIC. >>> >> >> Not sure I fully understand the sentence above. >> Hot plug will be fully supported, you can choose any profile (you have >> permissions on) while plugging a new device. >> > > That was the intention. seems like an edgy hand syndrome :) > Changed to: > * Hot plug will be fully supported: the user can choose any permitted profile while plugging a new device or when activating an existing one. > >>> Adding a Network >>> >>> When adding a network, a user can provide an option to create a vNic >>> Profile for it. >>> >>> Question: Is it s default profile ? what are its properties ? >>> Question: What about 'Public Use' option ? Are they still relevant in the >>> context of adding new networks or we should eliminate them and move it >>> only to 'Add vNic Profile' dialog? >>> >> >> see previous comments >> In addition when creating a profile we should have 'Allow all' for >> implicitly creating permissions, like we have today for network. >> >>> Updating a Network >>> >>> When a network role is modified to be a 'non-VM network', all vNic profiles >>> associated with it should be deleted. >> >> And permissions associated with these profiles >> >>> Removing a Network >>> >>> Should remove all profiles on that network >>> >> >> And associated permissions >> >>> Adding an Empty Data-Center >>> >>> Currently, When creating a new Data-Center, the management network is >>> automatically created. >>> From 3.3, a default vNic profile will be created for the management >>> network. >>> >>> VM snapshot/import/export >>> >>> We should handle VMs that are pointing to a network directly for >>> backward compatibility. >>> We need to select first profile that is on that network that the user >>> has permissions on. >>> >>> Question: Do we wish to support it export from 3.3 and import to 3.2 or >>> below? >> >> That means that when you write a VM in the OVF you need to write network >> in addition to profile. >> > > The network name is already there, so when importing a vnic from 3.3 to an earlier version > the profile name will be ignored. > >> >>> Question: A user can import/export a VM/Template even if he doesn't have >>> permissions on the networks. Is the next flow valid ? >>> >>> The profile name should be saved in the OVF (in addition to the network >>> name which is saved today). >>> During import, if both (network name, profile name) exist on the target >>> DC, the vnic will get the profile id. >>> If the network exists in the Data-Center, but has no profile as >>> specified in the OVF, the user will be notified (event log) and the >>> VNIC will be connected to a default minimal profile defined in the >>> system, regardless the permissions the user has on the network. >>> >> >> What is a 'default minimal profile' ? I would rather have a VNIC with no >> profile associated with it. > > The 'default minimal profile' refers to a vnic profile with the lower average bandwidth. > > With the approach you've suggested, any imported VM/Template from an earlier to 3.3 version > will require a manual intervention in order to configure a network to the VM. I should have elaborated some more - If a VM has a profile then we should look up this specific profile, if such a profile does not exists then import the VM with profile none like we do today for VM's with reference to a network that does not exist on the setup. If a VM does not have a profile (3.2 and lower versions) we should look into the network name, if this network exist and we have a profile with permissions to the user then use this profile (if there is more than one choose one randomly). > And for 3.1 we'll have to drop such vnics since network 'none' isn't supported. > >> >>> If failed to find any matching vNic profile, the vnic's profile will be set >>> with 'none'. >>> >>> When a Template is created from a VM the VNIC Profile will be kept >>> along with the VNIC. When a VM is created from template the VNIC >>> Profiles will be taken from the template's VNICs. >>> >>> ----- Original Message ----- >>>> From: "Livnat Peer" >>>> To: "engine-devel" , "Ofri Masad" >>>> >>>> Cc: "Mike Kolesnik" , "Moti Asayag" >>>> , "Oved Ourfalli" >>>> Sent: Sunday, June 30, 2013 3:59:37 PM >>>> Subject: VNIC profiles >>>> >>>> Hi, >>>> >>>> We are working on adding VNIC profiles as part of the work to add VNIC >>>> QoS. >>>> >>>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles >>>> >>>> We need to define some of the system behavior followed by this change, >>>> here is my take - >>>> >>>> Editing a profile - >>>> -------------------- >>>> A user should be able to edit the profile properties (including profile >>>> name) while VMs are attached and are using this Profile (reference >>>> should be done by id). >>>> >>>> Changing the network though is a bit more tricky as long as we don't >>>> have a way to distinguish between running and current configurations I >>>> think it could be very confusing to the user. Especially since we >>>> support dynamic wiring so the behavior IMO is unpredictable. >>>> I think it should be blocked at this point. >>>> >>>> >>>> Edit a VNIC / change a VNIC profile - >>>> ------------------------------------ >>>> Changing the profile a VM is using while the VM is running should behave >>>> like dynamic wiring (changing the VM network while it is running). >>>> >>>> >>>> Remove a Profile - >>>> ------------------- >>>> Is only valid if all VMs that are using this profile are in status down. >>>> It should update all VMs to point to no profile which should behave like >>>> none network today. >>>> >>>> I see no reason to support a profile on a none network at this point. >>>> >>>> The above is also relevant for upgrade flow (upgrading none network to >>>> point to no profile) >>>> >>>> >>>> Removing a Network - >>>> ---------------------- >>>> should remove all profiles on that network >>>> >>>> >>>> VM snapshot/import/export - >>>> -------------------------- >>>> We should handle VMs that are pointing to a network directly for b/w >>>> compatibility. >>>> we need to select first profile that is on that network that the user >>>> has permissions on. >>>> >>>> >>>> I assume there are more, comments are welcome >>>> >>>> Thanks, Livnat >>>> >>>> >> >> From masayag at redhat.com Mon Jul 8 08:21:21 2013 From: masayag at redhat.com (Moti Asayag) Date: Mon, 8 Jul 2013 04:21:21 -0400 (EDT) Subject: [Engine-devel] VNIC profiles In-Reply-To: <51DA6613.9040903@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> Message-ID: <321253300.385386.1373271681521.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Livnat Peer" > To: "Moti Asayag" > Cc: "engine-devel" , "Ofri Masad" , "Mike Kolesnik" , > "Oved Ourfalli" > Sent: Monday, July 8, 2013 10:11:15 AM > Subject: Re: VNIC profiles > > On 07/08/2013 12:36 AM, Moti Asayag wrote: > > I've updated the wiki accordingly and added few comments inline. > > > > ----- Original Message ----- > >> From: "Livnat Peer" > >> To: "Moti Asayag" > >> Cc: "engine-devel" , "Ofri Masad" > >> , "Mike Kolesnik" , > >> "Oved Ourfalli" > >> Sent: Sunday, July 7, 2013 2:59:34 PM > >> Subject: Re: VNIC profiles > >> > >> On 07/07/2013 01:59 PM, Moti Asayag wrote: > >>> Hi, > >>> > >>> I've updated the wiki with the feedbacks from this thread, added a > >>> backend > >>> section naming the affected commands and also add added few questions of > >>> my own embedded in the pastedtext below. > >>> > >> > >> Hi Moti, > >> A good and comprehensive description of the feature behavior. > >> See my comments bellow - > >> > >>> In addition, another question here: > >>> > >>> The units within the UI mockups are Mb and Mbps. The libvirt APIs expects > >>> the units to be in kb and kbps. Which component is responsible to convert > >>> them to the expect units ? engine or VDSM ? > >> > >> Giuseppe mentioned that in a previous thread on this subject. > >> Ofri and Giuseppe agreed that the translation would be done on the > >> engine level. > >> > >> > >>> > >>> Copied text from the wiki: > >>> > >>> Adding a Profile > >>> > >>> The network administrator could create several VNIC Profiles for each > >>> network. He could then grant a users with the permission to use (consume) > >>> each profile. The user will only be able to use profiles which he was > >>> granted access to. > >>> > >>> For example: the network admin will create two VNIC profiles for > >>> network "blue": > >>> > >>> Profile "Gold" - with better QoS and with port mirroring > >>> Profile "Silver" with lower QoS and without port mirroring. > >>> > >> > >> I would use other names for the profiles to avoid confusion. > >> Gold and Silver are likely to be QoS object names, a more typical name > >> for a network profile is - teachers-blue and students-blue > >> > >> The different profiles can have different QoS (teachers-blue would get > >> Gold QoS while Students-blue will have Silver). > >> > >> > >>> He will then define the user-group "students" as user of profile > >>> "Silver" and user-group "teachers" as user of profile "Gold". In this > >>> case the teachers will enjoy better quality of service then the > >>> students. When a teacher will add/edit a virtual NIC he could select > >>> profile "Gold" for that NIC - the VNIC will be connected to network > >>> "blue" with high QoS and with port mirroring. > >>> > >>> Question: In the same matter we allowed via the UI to grant 'NetworkUser' > >>> to 'everyone' user, wouldn't it ease the use of Profiles if we support it > >>> in this context as well? > >> > >> The ease of use could be that when creating a network we'll display in > >> the UI all VNIC-QoS-objects and the users could tick next to the QoS > >> they are interested in, for each QoS that was chosen a profile would be > >> created. > >> > >> I would enhance that with youe suggestion above and display next to the > >> QoS that was checked the option to mark 'Allow All users' like we have > >> today for making a network public, this option would give permission to > >> everyone on that profile. > >> > >> > >>> > >>> Editing a Profile > >>> > >>> A user should be able to edit the profile properties (including > >>> profile > >>> name) while VMs are attached and are using this Profile (reference > >>> should be done by id). > >>> Changing the network of a vNic profile will be allowed only if no VMs > >>> are using the profile. > >> > >> It would be better if we can limit this to no running VM is using the > >> profile (or more simple to implement if all VMs that are using this > >> profile are in status down). > > > > Allowing to delete a vnic profile when used by vms is asymmetric to the > > network removal > > when it is used by vms or templates. Today the update network operation is > > blocked for that. > > In addition, with the suggest simplification to remove a profile when no > > running vms, the user > > will have to find for himself if the profile is being used prior to its > > removal since the > > operation will not be blocked. > > > > If we allow to delete a vnic profile, when a vm is using it (regardless the > > VM status) > > we'll have to update the VM entity as well in that operation: since we do > > not support a > > network with 'none' profile, we'll have to delete the network as well. > > > > If we'll remove a vnic profile in 3.1 cluster, used by vms in status down, > > we'd find a case > > in which a VM is attached to a 'none' network. This is unsupported in 3.1 > > cluster. We can block > > such operation, but this is another motivation why we'd better not to allow > > removing a used profile. > > > > The context above is about editing not deleting :) > I agree with what you wrote if the context was remove. > > >> > >>> Since we have no way to distinguish between running and current > >>> configurations, the expected behavior of such a change is > >>> unpredictable and less intuitive to the user (especially since > >>> dynamic wiring is supported). > >>> The changes will seep down to all VNICs using the profile. > >>> In case VNIC using the edited profile are connected to running > >>> VMs, > >>> the change will apply only on the VM next run. > >>> > >>> Question: What about Hibernate/Suspend VM ? will the resume VM action > >>> uses > >>> the original configuration for the vnics when the VM was started ? > >> > >> Currently profile includes: network, port-mirroring, custom property, QoS > >> > >> Changing any of the above (except for network) requires a VM reboot, so > >> I think that we can start with the following statement - the profile > >> change would only apply after next VM reboot. > >> > >> There are 2 problems with the above: > >> - Today we support network wiring, with VNIC profiles we are asking the > >> users to create a new profile and attach the VMs to the new profile, I > >> can see the RFE coming - we can report that ourselves ;) > >> > >> - We don't reflect with which configuration the VM is running, e.g we > >> edited the profile QoS but I'm not sure with which QoS the VM is > >> currently running. (The RFE for differentiating between current > >> configuration and running configuration was already asked for by > >> numerous users) > >> > >> The above is a general issue that we need to solve and I would not limit > >> editing VNIC profiles because of it. > >> We can mitigate this specifically for QoS like described bellow. > >> > >> > >> > >>> Deleting a Profile > >>> > >>> VNIC Profiles could not be deleted from the engine as long as one or more > >>> VM/Templates are using those profiles. > >> > >>> Reporting vNic actual configuration > >>> > >>> The engine will retrieve the actual configuration of the profile > >>> properties on the VNIC from VDSM (using the network statistics > >>> mechanism) and the networked administrator will be presented with the > >>> state of each VNIC (synched/unsynched). > >>> > >> > >> Will the admin be able to see the actual values? I think the synced > >> property is not enough (I'm not sure how interesting this property is to > >> start with). > > > > We can extend the VmGuestAgentInterface to contain the actual value, so > > they > > will be presented for each vnic in the 'guest data' sub-tab. > > > > AFAIU this info does not come from the guest it is info we retrieve from > libvirt. > The VmGuestAgentInterface should be used only for information reported > by the guest, information whose credibility can be questioned. > we'll use the vm network statistics to persist that information which will be presented to the user in new sub-tab under the vm-network-interface sub-tab. > > >> > >>> Editing a VNIC / Changing a VNIC profile > >>> > >>> Changing the profile a VM is using while the VM is running should > >>> behave like dynamic wiring (changing the VM network while it is > >>> running). > >>> Hot-plug of a vnic will will use will use the updated profile > >>> connected > >>> to the VNIC. > >>> > >> > >> Not sure I fully understand the sentence above. > >> Hot plug will be fully supported, you can choose any profile (you have > >> permissions on) while plugging a new device. > >> > > > > That was the intention. seems like an edgy hand syndrome :) > > Changed to: > > * Hot plug will be fully supported: the user can choose any permitted > > profile while plugging a new device or when activating an existing one. > > > >>> Adding a Network > >>> > >>> When adding a network, a user can provide an option to create a vNic > >>> Profile for it. > >>> > >>> Question: Is it s default profile ? what are its properties ? > >>> Question: What about 'Public Use' option ? Are they still relevant in the > >>> context of adding new networks or we should eliminate them and move it > >>> only to 'Add vNic Profile' dialog? > >>> > >> > >> see previous comments > >> In addition when creating a profile we should have 'Allow all' for > >> implicitly creating permissions, like we have today for network. > >> > >>> Updating a Network > >>> > >>> When a network role is modified to be a 'non-VM network', all vNic > >>> profiles > >>> associated with it should be deleted. > >> > >> And permissions associated with these profiles > >> > >>> Removing a Network > >>> > >>> Should remove all profiles on that network > >>> > >> > >> And associated permissions > >> > >>> Adding an Empty Data-Center > >>> > >>> Currently, When creating a new Data-Center, the management network is > >>> automatically created. > >>> From 3.3, a default vNic profile will be created for the management > >>> network. > >>> > >>> VM snapshot/import/export > >>> > >>> We should handle VMs that are pointing to a network directly for > >>> backward compatibility. > >>> We need to select first profile that is on that network that the user > >>> has permissions on. > >>> > >>> Question: Do we wish to support it export from 3.3 and import to 3.2 or > >>> below? > >> > >> That means that when you write a VM in the OVF you need to write network > >> in addition to profile. > >> > > > > The network name is already there, so when importing a vnic from 3.3 to an > > earlier version > > the profile name will be ignored. > > > >> > >>> Question: A user can import/export a VM/Template even if he doesn't have > >>> permissions on the networks. Is the next flow valid ? > >>> > >>> The profile name should be saved in the OVF (in addition to the > >>> network > >>> name which is saved today). > >>> During import, if both (network name, profile name) exist on the > >>> target > >>> DC, the vnic will get the profile id. > >>> If the network exists in the Data-Center, but has no profile as > >>> specified in the OVF, the user will be notified (event log) and the > >>> VNIC will be connected to a default minimal profile defined in the > >>> system, regardless the permissions the user has on the network. > >>> > >> > >> What is a 'default minimal profile' ? I would rather have a VNIC with no > >> profile associated with it. > > > > The 'default minimal profile' refers to a vnic profile with the lower > > average bandwidth. > > > > With the approach you've suggested, any imported VM/Template from an > > earlier to 3.3 version > > will require a manual intervention in order to configure a network to the > > VM. > > I should have elaborated some more - > > If a VM has a profile then we should look up this specific profile, if > such a profile does not exists then import the VM with profile none like > we do today for VM's with reference to a network that does not exist on > the setup. > > If a VM does not have a profile (3.2 and lower versions) we should look > into the network name, if this network exist and we have a profile with > permissions to the user then use this profile (if there is more than one > choose one randomly). > The wiki was updated with the VM/Template import logic: http://www.ovirt.org/Features/Vnic_Profiles#VM_snapshot.2Fimport.2Fexport > > > And for 3.1 we'll have to drop such vnics since network 'none' isn't > > supported. > > > >> > >>> If failed to find any matching vNic profile, the vnic's profile will be > >>> set > >>> with 'none'. > >>> > >>> When a Template is created from a VM the VNIC Profile will be kept > >>> along with the VNIC. When a VM is created from template the VNIC > >>> Profiles will be taken from the template's VNICs. > >>> > >>> ----- Original Message ----- > >>>> From: "Livnat Peer" > >>>> To: "engine-devel" , "Ofri Masad" > >>>> > >>>> Cc: "Mike Kolesnik" , "Moti Asayag" > >>>> , "Oved Ourfalli" > >>>> Sent: Sunday, June 30, 2013 3:59:37 PM > >>>> Subject: VNIC profiles > >>>> > >>>> Hi, > >>>> > >>>> We are working on adding VNIC profiles as part of the work to add VNIC > >>>> QoS. > >>>> > >>>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles > >>>> > >>>> We need to define some of the system behavior followed by this change, > >>>> here is my take - > >>>> > >>>> Editing a profile - > >>>> -------------------- > >>>> A user should be able to edit the profile properties (including profile > >>>> name) while VMs are attached and are using this Profile (reference > >>>> should be done by id). > >>>> > >>>> Changing the network though is a bit more tricky as long as we don't > >>>> have a way to distinguish between running and current configurations I > >>>> think it could be very confusing to the user. Especially since we > >>>> support dynamic wiring so the behavior IMO is unpredictable. > >>>> I think it should be blocked at this point. > >>>> > >>>> > >>>> Edit a VNIC / change a VNIC profile - > >>>> ------------------------------------ > >>>> Changing the profile a VM is using while the VM is running should behave > >>>> like dynamic wiring (changing the VM network while it is running). > >>>> > >>>> > >>>> Remove a Profile - > >>>> ------------------- > >>>> Is only valid if all VMs that are using this profile are in status down. > >>>> It should update all VMs to point to no profile which should behave like > >>>> none network today. > >>>> > >>>> I see no reason to support a profile on a none network at this point. > >>>> > >>>> The above is also relevant for upgrade flow (upgrading none network to > >>>> point to no profile) > >>>> > >>>> > >>>> Removing a Network - > >>>> ---------------------- > >>>> should remove all profiles on that network > >>>> > >>>> > >>>> VM snapshot/import/export - > >>>> -------------------------- > >>>> We should handle VMs that are pointing to a network directly for b/w > >>>> compatibility. > >>>> we need to select first profile that is on that network that the user > >>>> has permissions on. > >>>> > >>>> > >>>> I assume there are more, comments are welcome > >>>> > >>>> Thanks, Livnat > >>>> > >>>> > >> > >> > > From iheim at redhat.com Mon Jul 8 10:25:16 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 08 Jul 2013 13:25:16 +0300 Subject: [Engine-devel] about vm in vmpool In-Reply-To: <004c01ce7ba1$15468fa0$3fd3aee0$@com> References: <004c01ce7ba1$15468fa0$3fd3aee0$@com> Message-ID: <51DA938C.7020604@redhat.com> On 07/08/2013 09:04 AM, wlbleaboy at 126 wrote: > Hi, all: > > I have using ovirt-sdk 3 monthes, I can use ovirt-sdk get vm?s > infomations like > > vm?s name, vm?s id, vm?ticket etc. > > but recently, I have a question about vm in vmpool, how could > I get vm?s information > > that the vm in vmpool. Especially, when a vm is at stop statuss. > > For example, when use UserPortal in the web-browser, no matter > the vm is in the vmpool, > > it can be showed in the web-browser, but, I can?t get vm? s information > which in the vmpool via > > the ovirt-sdk. > > Leaboy > > thanks > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > I'm pretty sure the user portal is 'mocking' the appearance of the VM, based on user having permission to the pool. From mperina at redhat.com Mon Jul 8 11:58:08 2013 From: mperina at redhat.com (Martin Perina) Date: Mon, 8 Jul 2013 07:58:08 -0400 (EDT) Subject: [Engine-devel] BadPaddingException In-Reply-To: <983766685.489493.1373283853351.JavaMail.root@redhat.com> Message-ID: <457539664.500133.1373284688725.JavaMail.root@redhat.com> Hi, I've noticed that BadPaddingException has started to appear recently in engine-log: 1) The first occurrence is during engine startup: 2013-07-08 13:42:32,334 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service thread 1-4) Failed to decrypt value for property AttestationTruststorePass will be used encrypted value: javax.crypto.BadPaddingException: Data must start with zero 2) The second occurrence is after successfull login to webadmin app 2013-07-08 13:43:13,352 ERROR [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (http--0.0.0.0-8080-1) Failed to decrypt value for property LocalAdminPassword will be used encrypted value: javax.crypto.BadPaddingException: Data must start with zero Strange thing is, that I can log in as admin at internal without any problems with the password I've entered during engine-setup-2 process. Engine instance has been created using new development environment with no errors, engine.log attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: engine.log Type: text/x-log Size: 78498 bytes Desc: not available URL: From alonbl at redhat.com Mon Jul 8 12:01:56 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 8 Jul 2013 08:01:56 -0400 (EDT) Subject: [Engine-devel] BadPaddingException In-Reply-To: <457539664.500133.1373284688725.JavaMail.root@redhat.com> References: <457539664.500133.1373284688725.JavaMail.root@redhat.com> Message-ID: <415230449.154170.1373284916031.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Martin Perina" > To: engine-devel at ovirt.org > Sent: Monday, July 8, 2013 2:58:08 PM > Subject: [Engine-devel] BadPaddingException > > Hi, > > I've noticed that BadPaddingException has started to appear recently in > engine-log: > > 1) The first occurrence is during engine startup: > > 2013-07-08 13:42:32,334 ERROR > [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service > thread 1-4) Failed to decrypt value for property > AttestationTruststorePass will be used encrypted value: > javax.crypto.BadPaddingException: Data must start with zero > > > 2) The second occurrence is after successfull login to webadmin app > > 2013-07-08 13:43:13,352 ERROR > [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] > (http--0.0.0.0-8080-1) Failed to decrypt value for property > LocalAdminPassword will be used encrypted value: > javax.crypto.BadPaddingException: Data must start with zero > > > Strange thing is, that I can log in as admin at internal without any problems > with the password I've entered > during engine-setup-2 process. > > Engine instance has been created using new development environment with no > errors, engine.log attached. Right. This was always the case, the only change is that I added a stack trace for these errors. Now someone need to figure out why we would like to decrypt the default password of 123456 if I recall correctly, and fix this... :) Alon From vszocs at redhat.com Mon Jul 8 12:31:54 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 8 Jul 2013 08:31:54 -0400 (EDT) Subject: [Engine-devel] Sorting in tabs In-Reply-To: <1674644916.2967768.1372402847694.JavaMail.root@redhat.com> References: <51CBE5E1.7080900@redhat.com> <1572668253.9189415.1372340538767.JavaMail.root@redhat.com> <51CC4E4C.4030507@redhat.com> <1796469050.9281535.1372346129622.JavaMail.root@redhat.com> <51CC6512.50509@redhat.com> <422687242.9340619.1372351256617.JavaMail.root@redhat.com> <371875056.2962175.1372401917952.JavaMail.root@redhat.com> <1674644916.2967768.1372402847694.JavaMail.root@redhat.com> Message-ID: <1040248727.582587.1373286714597.JavaMail.root@redhat.com> Hi Lior, I'm revisiting this thread and posting some of my ideas on the sorting issue. Page-able data widgets like tables with paging buttons, should use server-side sorting: clicking on table column header updates the search string ("sortby ") which causes CommonModel.search() to be called and new data presented in the given table. Non-page-able data widgets like tables without paging buttons, i.e. tables bound to SearchableListModel whose "Search{Next|Previous}PageCommand" isn't available, can use client-side sorting. However, instead of manipulating UiCommon model data (items) directly and possibly breaking some hidden expectations within UiCommon code (as Tomas mentioned earlier), I'd rather do client-side sorting on model provider level. Model providers represent a layer between GUI and UiCommon: GUI <--> model provider <--> UiCommon model Model providers are adapters between GUI and UiCommon models, listening to important events fired by models and updating GUI accordingly & providing API (facade) for GUI to trigger operations on models. For client-side sorting, I think it's better to implement this feature on model provider level, i.e. inside DataBoundTabModelProvider.updateData() method: List items = (List) getModel().getItems(); // possibly use comparator to sort items As for GWT's native support for table sorting: this is already in GWT 2.3, see AbstractCellTable.addColumnSortHandler() method. It's just a handler that keeps track of current sort options, i.e. "column2 asc & column 1 desc & column 3 asc". In other words, GWT provides a mechanism to notify our code what are current sort options, but it's up to us to re-render data based on these sort options, i.e. using Comparator on UiCommon model items. Vojtech ----- Original Message ----- > From: "Tomas Jelinek" > To: "Einav Cohen" > Cc: "Lior Vernia" , "Vojtech Szocs" , "Eli Mesika" , > engine-devel at ovirt.org, "Alexander Wels" , "Daniel Erez" , "Gilad Chaplik" > , "Alona Kaplan" > Sent: Friday, June 28, 2013 9:00:47 AM > Subject: Re: [Engine-devel] Sorting in tabs > > > > ----- Original Message ----- > > From: "Tomas Jelinek" > > To: "Einav Cohen" > > Cc: "Lior Vernia" , "Vojtech Szocs" > > , "Eli Mesika" , > > engine-devel at ovirt.org, "Alexander Wels" , "Daniel Erez" > > , "Gilad Chaplik" > > , "Alona Kaplan" > > Sent: Friday, June 28, 2013 8:45:17 AM > > Subject: Re: [Engine-devel] Sorting in tabs > > > > > > > > ----- Original Message ----- > > > From: "Einav Cohen" > > > To: "Lior Vernia" > > > Cc: "Vojtech Szocs" , "Eli Mesika" > > > , > > > engine-devel at ovirt.org, "Alexander Wels" > > > , "Daniel Erez" , "Gilad Chaplik" > > > , "Alona Kaplan" > > > , "Tomas Jelinek" > > > Sent: Thursday, June 27, 2013 6:40:56 PM > > > Subject: Re: [Engine-devel] Sorting in tabs > > > > > > > ----- Original Message ----- > > > > From: "Lior Vernia" > > > > Sent: Thursday, June 27, 2013 12:15:14 PM > > > > > > > > > > > > > > > > On 27/06/13 18:15, Einav Cohen wrote: > > > > >> ----- Original Message ----- > > > > >> From: "Lior Vernia" > > > > >> Sent: Thursday, June 27, 2013 10:38:04 AM > > > > >> > > > > >> > > > > >> > > > > >> On 27/06/13 16:42, Einav Cohen wrote: > > > > >>>> ----- Original Message ----- > > > > >>>> From: "Lior Vernia" > > > > >>>> Sent: Thursday, June 27, 2013 8:53:59 AM > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On 27/06/13 15:37, Einav Cohen wrote: > > > > >>>>>> ----- Original Message ----- > > > > >>>>>> From: "Eli Mesika" > > > > >>>>>> Sent: Thursday, June 27, 2013 6:46:58 AM > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> ----- Original Message ----- > > > > >>>>>>> From: "Lior Vernia" > > > > >>>>>>> To: engine-devel at ovirt.org > > > > >>>>>>> Sent: Thursday, June 27, 2013 10:12:33 AM > > > > >>>>>>> Subject: [Engine-devel] Sorting in tabs > > > > >>>>>>> > > > > >>>>>>> Hello everyone (UI peeps in particular), > > > > >>>>>>> > > > > >>>>>>> I've pushed (not yet merged) a patch that would enable us to > > > > >>>>>>> keep > > > > >>>>>>> items > > > > >>>>>>> in tabs (main/sub) sorted at all times by setting a comparator > > > > >>>>>>> in > > > > >>>>>>> SearchableListModel: > > > > >>>>>> > > > > >>>>>> But tabs includes only 100 records and supports paging , how you > > > > >>>>>> deal > > > > >>>>>> with > > > > >>>>>> that ??? > > > > >>>>> > > > > >>>>> if this is in the GUI level, then I assume that the comparator is > > > > >>>>> simply > > > > >>>>> comparing the > > > > >>>>> items within the current page, and not "globally". > > > > >>>>> so the sorting doesn't affect the set of items that is displayed > > > > >>>>> in > > > > >>>>> the > > > > >>>>> page (it would > > > > >>>>> be the same as before the sorting) - just their order. > > > > >>>> > > > > >>>> Yes, if I understand correctly how the paging works, Einav is > > > > >>>> correct > > > > >>>> - > > > > >>>> only the items passed to the UI are sorted. > > > > >>>> > > > > >>>>> also: @Lior - what happens when the search query contains a "sort > > > > >>>>> by" > > > > >>>>> part? > > > > >>>>> there is a chance that the behaivor would be unexpected in this > > > > >>>>> case; > > > > >>>> > > > > >>>> Yes, I thought about this case, and it may result in a confusing > > > > >>>> user > > > > >>>> experience if developers aren't careful. Together with the issue > > > > >>>> of > > > > >>>> paging, this probably makes this sorting mechanism a better > > > > >>>> candidate > > > > >>>> for use within subtabs rather than main tabs. > > > > >>> > > > > >>> note that at some point, I think that we would want to introduce > > > > >>> paging > > > > >>> also to search- > > > > >>> based sub-tabs - it will be useful especially for sub-tabs that > > > > >>> potentially > > > > >>> display a > > > > >>> large number of results (e.g. Disks sub-tab in Storage main tab). > > > > >>> In addition, at some point, we would want to get rid of the paging > > > > >>> UI > > > > >>> as > > > > >>> it > > > > >>> is now > > > > >>> (i.e. "next"/"prev" buttons at the top panel) and move to paging > > > > >>> triggered > > > > >>> by scroll > > > > >>> (i.e. have a very long grid, dynamically loaded as you continue to > > > > >>> scroll > > > > >>> - > > > > >>> similar > > > > >>> to the behavior of some e-mail web-clients, for example). In this > > > > >>> case, > > > > >>> sorting on > > > > >>> the client side will make no sense at all (i.e. from the user > > > > >>> perspective, > > > > >>> only a > > > > >>> portion of a very large grid will be sorted, the other portions > > > > >>> won't > > > > >>> be). > > > > >>> > > > > >>> So for now - yes, I think it makes sense to introduce your > > > > >>> mechanism > > > > >>> to > > > > >>> all > > > > >>> sub-tabs, > > > > >>> however in the long-term - we would probably want the search-based > > > > >>> sub-tabs > > > > >>> (which > > > > >>> will support paging) to move to search-based sorting, rather than > > > > >>> GUI-based-sorting. > > > > >> > > > > >> Sounds good to me. Let me just re-iterate that it is not mandatory > > > > >> to > > > > >> set a comparator, so in technical terms it's not even necessary to > > > > >> introduce it at once to all sub-tabs, if they're already sorting > > > > >> their > > > > >> items some other way. It could happen gradually, and only if > > > > >> developers > > > > >> find it more convenient. In either case, dropping the GUI sorting > > > > >> once > > > > >> search-based sorting is implemented shouldn't be difficult. > > > > >> > > > > >>> BTW (maybe the other GUI maintainers can help me with that one) - > > > > >>> what > > > > >>> about sub-tabs > > > > >>> that are not search-based (i.e. display results from a "regular" > > > > >>> query > > > > >>> or > > > > >>> even from a > > > > >>> field within the selected item in the main grid, e.g. Applications > > > > >>> in > > > > >>> VM) > > > > >>> - > > > > >>> are these > > > > >>> managed via SearchableListModel as well? since the comparator > > > > >>> mechanism > > > > >>> *is* relevant > > > > >>> for them. > > > > >> > > > > >> As far as I've seen, some are managed via SearchableListModel and > > > > >> some > > > > >> aren't. Those that aren't are those that display non-trivial > > > > >> behaviour > > > > >> upon receipt of the items to display (setItems() method) - often > > > > >> this > > > > >> non-trivial behaviour is exactly sorting :) And if it's doing its > > > > >> job, > > > > >> then there's no necessity to change it either. But anyway, I don't > > > > >> know > > > > >> all of them, so I'd also love to hear GUI maintainers. > > > > >> > > > > >>> Also: Worth mentioning "Bug 893999 - webadmin: please allow column > > > > >>> sorting", which > > > > >>> requests to enable sorting when clicking on a grid-column header; > > > > >>> when > > > > >>> implementing > > > > >>> column-sorting, probably worth attaching your mechanism to it > > > > >>> somehow > > > > >>> (i.e. > > > > >>> clicking on > > > > >>> a column header should set the relevant comparator in the relevant > > > > >>> SearchableListModel). > > > > >> > > > > >> I didn't want to say it, because if we upgrade to a newer version of > > > > >> GWT > > > > >> then we could probably use their table column sorting. But this > > > > >> mechanism could allow us to achieve this without upgrading, and it > > > > >> was > > > > >> definitely sitting in the back of my head when I implemented it. All > > > > >> that's needed is, as you said, to listen to table header clicks in > > > > >> the > > > > >> view, and then appropriately set the comparator in the model. > > > > >> > > > > > > > > > > [Vojtech/GUI-maintainers - your input would be appreciated here] > > > > > > > > > > we are actually planning on upgrading the GWT version *really* soon > > > > > (to > > > > > GWT > > > > > 2.5), > > > > > so my question is: should we wait until the new GWT is introduced, > > > > > and > > > > > implement > > > > > client-sorting based on the GWT-grid-widget built-in mechanism > > > > > (assuming > > > > > there is > > > > > one)? > > > > > also, not sure if it is better to utilize the widget default-built-in > > > > > sorting mechanism > > > > > (which doesn't manipulate the uicommon model data at all), or if it > > > > > is > > > > > better to utilize > > > > > your comparator mechanism, which manipulates the uicommon model data, > > > > > and > > > > > the GUI-widget > > > > > just reflects this data at any given time. > > > > > thoughts? > > > > > > > > I'll just give my two cents concerning this and then let others have > > > > the > > > > stage: I don't think it really matters. > > > > > > > > Manipulating the models directly is supposedly more portable in case we > > > > ever move away from GWT, but we'd still have the pain of adding new > > > > listeners to the new framework's table headers which could be just as > > > > bad as using its sorting mechanism. > > > > > > > > Graphically, the UI might look tighter if we use GWT's mechanism. > > > > However, we could probably mimic everything using GWT's graphics (once > > > > we upgrade) even if we perform the actual sorting using the tab model > > > > and not their mechanism. > > > > > > > > My gut feeling actually says to use GWT's built-in mechanism, mainly > > > > because it will force us to put all sorting logic in the same place and > > > > to always use the same sorting mechanism (whereas currently the sorting > > > > logic is scattered and works differently in different places, even if > > > > we > > > > use this tab mechanism other widgets will differ). But it shouldn't > > > > stop > > > > us from setting a comparator for a tab where convenient. > > > > > > [again, GUI maintainers - your input would be appreciated] > > > > > > Thanks, Lior. Need to keep in mind several things: > > > > > > - we are now talking only about client-sorting, which generally we would > > > like > > > to apply only to grids that display none-"pagable"-results; for grids > > > that > > > would > > > display pagable-results, we would want to use search-based (i.e. server) > > > sorting. > > > [so the sorting logic across the application would be somewhat-scattered > > > anyway]. > > > > > > - I think that if we are choosing to utilize GWT's built-in mechanism, > > > then > > > using > > > a comparator would makes sense in case you want your results to be > > > initially > > > displayed > > > in a specific order that would not be obtainable using the column-header > > > sorting. > > > > > > e.g. (dumb example, for demonstration only) if you would want your VMs to > > > be > > > displayed > > > by default sorted alphabetically according to the VM's description (and > > > keep > > > in mind > > > that description is NOT one of the columns in the VMs grid), then you > > > would > > > probably > > > want to do that via the comparator. > > > > > > Or (perhaps a better example), if you would want your Templates to be > > > ordered > > > by default > > > in a way that "Blank" would appear first, and the rest would appear > > > sorted > > > alphabetically > > > by name, utilizing the comparator can be a good idea. > > > [After the initial load of the grid, if the user chooses to sort by name, > > > he > > > can click on > > > the "Name" column header, which will sort the Templates alphabetically > > > "regularly" (i.e. > > > not taking "Blank" into special consideration)] > > > > > > But - if, by default, we would want, for example, to sort VMs > > > alphabetically > > > by name, > > > I think that we should imitate a mouse-click on the "Name" column-header, > > > rather than > > > utilize a comparator for that (the exact same result shouldn't be > > > achieved > > > by > > > two different > > > implementations). > > > > Hi Lior, > > > > fist of all, I would be really careful about introducing something to > > UiCommon which could > > potentially cause class cast exceptions - not that your approach would be > > incorrect but the > > UiCommon has lot's of hidden expectations and it is hard to keep tract who > > expects the > > ListModel.getItems will be a list. I would be double careful about this > > kind > > of change right > > before the freeze. Maybe create a SortedSearchableListModel as a child of > > SearchableListModel > > would be a much more safe approach. > > > > About the GWT built-in vs Comparator - > > I would also go with the GWT's built in approach. > > If we are using a framework we should make use of it and not > > try to decouple too much to make it simpler to migrate to a different one. > > > > So I agree with Lior that we should go with GWT's built in approach. > > AFAIK Vojtech is already working on the GWT2.5 integration... > > > > Also I would say that we should have the same user experience regardless > > the > > table is paged or not > > e.g. the user needs to have the same button to click on and the result must > > make sense after he clicked > > it everywhere. So I would say we will have to integrate this GUI sorting > > with > > server side sorting for paged tables. > > > > But maybe this integration (however a ideal target) is a bit out of the > > scope > > of your initial intention ;) > > > > If you have a good reason to have something always sorted and it is not a > > paged table, I'm not against. > > Just please be a bit more careful in changing return types in a non-generic > > code like UiCommon. > Ooops, now I have looked into your code and realized that you return a > different type only if the comparator is set > which makes your patch much less risky - but at the same time much less > predictable. > > But this kind of implementation details should be discussed on gerrit, so if > it will be > decided that the patch should go in in some form we can continue the > discussion on gerrit. > > > > > > > > > > > > > > >>>> > > > > >>>>> > > > > >>>>> I believe that the correct thing to do is to "attach" the GUI > > > > >>>>> sorting > > > > >>>>> mechanism > > > > >>>>> to the one in the search mechanism. > > > > >>>>> > > > > >>>>> thoughts? > > > > >>>> > > > > >>>> This can be done, however I'm not sure there's much utility in it. > > > > >>>> Main > > > > >>>> tabs are always sorted according to some default ordering even if > > > > >>>> one > > > > >>>> was not entered in the search panel, and this sorting is also > > > > >>>> performed > > > > >>>> consistently with respect to paging. So maybe the right thing to > > > > >>>> do > > > > >>>> would be to just "block" the GUI sorting mechanism for main tabs > > > > >>>> (i.e. > > > > >>>> override the setter method and make it no-op)? > > > > >>> > > > > >>> yes, and related to what I mentioned above - at some point in the > > > > >>> future, > > > > >>> we'd might want > > > > >>> to block it for search-based sub-tabs as well. > > > > >>> > > > > >>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>>> > > > > >>>>>>> http://gerrit.ovirt.org/#/c/15846/ > > > > >>>>>>> > > > > >>>>>>> If a comparator isn't set, then everything should behave as > > > > >>>>>>> before. > > > > >>>>>>> If > > > > >>>>>>> a > > > > >>>>>>> comparator is set, then from that moment on the tab items will > > > > >>>>>>> be > > > > >>>>>>> kept > > > > >>>>>>> in a SortedSet, so that even if an item is added in a way that > > > > >>>>>>> doesn't > > > > >>>>>>> trigger an event (e.g. getItems().add()) the items will be kept > > > > >>>>>>> sorted > > > > >>>>>>> according to the given comparator. If the comparator is set to > > > > >>>>>>> null, > > > > >>>>>>> from that moment on the tab should revert to its old behaviour. > > > > >>>>>>> > > > > >>>>>>> You're most welcome to have a look and let me know if this > > > > >>>>>>> might > > > > >>>>>>> break > > > > >>>>>>> something (remember though that it's not obligatory to set a > > > > >>>>>>> comparator, > > > > >>>>>>> so only possible breakage should be in generic flows). > > > > >>>>>>> > > > > >>>>>>> Feel free to use it once it's merged; along with > > > > >>>>>>> SortedListModel, > > > > >>>>>>> this > > > > >>>>>>> should make sorting less painful. Just keep in mind that once > > > > >>>>>>> you > > > > >>>>>>> set > > > > >>>>>>> a > > > > >>>>>>> comparator, you can't cast getItems() to a List. This shouldn't > > > > >>>>>>> be > > > > >>>>>>> a > > > > >>>>>>> problem in general, as mostly it's as useful (and probably more > > > > >>>>>>> correct) > > > > >>>>>>> to cast to a Collection. > > > > >>>>>>> > > > > >>>>>>> Lior. > > > > >>>>>>> _______________________________________________ > > > > >>>>>>> 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 Jul 8 12:34:35 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 8 Jul 2013 08:34:35 -0400 (EDT) Subject: [Engine-devel] BadPaddingException In-Reply-To: <415230449.154170.1373284916031.JavaMail.root@redhat.com> References: <457539664.500133.1373284688725.JavaMail.root@redhat.com> <415230449.154170.1373284916031.JavaMail.root@redhat.com> Message-ID: <1603849282.583360.1373286875092.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Martin Perina" > Cc: engine-devel at ovirt.org > Sent: Monday, July 8, 2013 2:01:56 PM > Subject: Re: [Engine-devel] BadPaddingException > > > > ----- Original Message ----- > > From: "Martin Perina" > > To: engine-devel at ovirt.org > > Sent: Monday, July 8, 2013 2:58:08 PM > > Subject: [Engine-devel] BadPaddingException > > > > Hi, > > > > I've noticed that BadPaddingException has started to appear recently in > > engine-log: > > > > 1) The first occurrence is during engine startup: > > > > 2013-07-08 13:42:32,334 ERROR > > [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC service > > thread 1-4) Failed to decrypt value for property > > AttestationTruststorePass will be used encrypted value: > > javax.crypto.BadPaddingException: Data must start with zero > > > > > > 2) The second occurrence is after successfull login to webadmin app > > > > 2013-07-08 13:43:13,352 ERROR > > [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] > > (http--0.0.0.0-8080-1) Failed to decrypt value for property > > LocalAdminPassword will be used encrypted value: > > javax.crypto.BadPaddingException: Data must start with zero > > > > > > Strange thing is, that I can log in as admin at internal without any problems > > with the password I've entered > > during engine-setup-2 process. > > > > Engine instance has been created using new development environment with no > > errors, engine.log attached. > > Right. > > This was always the case, the only change is that I added a stack trace for > these errors. > > Now someone need to figure out why we would like to decrypt the default > password of 123456 if I recall correctly, and fix this... :) Maybe because Engine first assumes the password is encrypted and tries to decrypt it, otherwise it just uses the immediate value. > > Alon > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alonbl at redhat.com Mon Jul 8 12:45:53 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 8 Jul 2013 08:45:53 -0400 (EDT) Subject: [Engine-devel] BadPaddingException In-Reply-To: <1603849282.583360.1373286875092.JavaMail.root@redhat.com> References: <457539664.500133.1373284688725.JavaMail.root@redhat.com> <415230449.154170.1373284916031.JavaMail.root@redhat.com> <1603849282.583360.1373286875092.JavaMail.root@redhat.com> Message-ID: <1854716744.167431.1373287553275.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Vojtech Szocs" > To: "Alon Bar-Lev" > Cc: "Martin Perina" , engine-devel at ovirt.org > Sent: Monday, July 8, 2013 3:34:35 PM > Subject: Re: [Engine-devel] BadPaddingException > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Martin Perina" > > Cc: engine-devel at ovirt.org > > Sent: Monday, July 8, 2013 2:01:56 PM > > Subject: Re: [Engine-devel] BadPaddingException > > > > > > > > ----- Original Message ----- > > > From: "Martin Perina" > > > To: engine-devel at ovirt.org > > > Sent: Monday, July 8, 2013 2:58:08 PM > > > Subject: [Engine-devel] BadPaddingException > > > > > > Hi, > > > > > > I've noticed that BadPaddingException has started to appear recently in > > > engine-log: > > > > > > 1) The first occurrence is during engine startup: > > > > > > 2013-07-08 13:42:32,334 ERROR > > > [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] (MSC > > > service > > > thread 1-4) Failed to decrypt value for property > > > AttestationTruststorePass will be used encrypted value: > > > javax.crypto.BadPaddingException: Data must start with zero > > > > > > > > > 2) The second occurrence is after successfull login to webadmin app > > > > > > 2013-07-08 13:43:13,352 ERROR > > > [org.ovirt.engine.core.dal.dbbroker.generic.DBConfigUtils] > > > (http--0.0.0.0-8080-1) Failed to decrypt value for property > > > LocalAdminPassword will be used encrypted value: > > > javax.crypto.BadPaddingException: Data must start with zero > > > > > > > > > Strange thing is, that I can log in as admin at internal without any > > > problems > > > with the password I've entered > > > during engine-setup-2 process. > > > > > > Engine instance has been created using new development environment with > > > no > > > errors, engine.log attached. > > > > Right. > > > > This was always the case, the only change is that I added a stack trace for > > these errors. > > > > Now someone need to figure out why we would like to decrypt the default > > password of 123456 if I recall correctly, and fix this... :) > > Maybe because Engine first assumes the password is encrypted and tries to > decrypt it, otherwise it just uses the immediate value. No, it is not this case. I think that the engine is trying to use vdc_options before it was actually loaded. And the other attempt when user first login is an option question. From vszocs at redhat.com Mon Jul 8 13:38:54 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 8 Jul 2013 09:38:54 -0400 (EDT) Subject: [Engine-devel] Upgrading oVirt UI technology stack Message-ID: <502627409.625290.1373290734872.JavaMail.root@redhat.com> The following is a new meeting request: Subject: Upgrading oVirt UI technology stack Organizer: "Vojtech Szocs" Time: Tuesday, July 9, 2013, 3:00:00 PM - 4:00:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague Required: engine-devel at ovirt.org Optional: awels at redhat.com; gshereme at redhat.com; ecohen at redhat.com; derez at redhat.com; gchaplik at redhat.com; tjelinek at redhat.com; lvernia at redhat.com; kmayilsa at redhat.com; tnisan at redhat.com; alkaplan at redhat.com *~*~*~*~*~*~*~*~*~* Hello everyone, this meeting is a follow-up to our effort to upgrade existing UI technology stack shared by oVirt web applications: http://www.ovirt.org/Features/GWT_Platform_Upgrade In this meeting, I'll be going through important changes in GWT(P) that impact UI architecture. Everyone is welcome to join and share his (her) ideas, suggestions, etc. Conference call details: Intercall dial-in numbers: https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405 Intercall conference code: 712 886 7405 # Elluminate session link: https://sas.elluminate.com/m.jnlp?sid=819&password=M.132A81E7D3610CF042FB58CA335C55 Regards, Vojtech -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 3387 bytes Desc: not available URL: From mpastern at redhat.com Mon Jul 8 14:21:57 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Mon, 08 Jul 2013 17:21:57 +0300 Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.10-1 released In-Reply-To: <51CD291A.6060500@redhat.com> References: <51CD291A.6060500@redhat.com> Message-ID: <51DACB05.2080908@redhat.com> * Thu Jul 8 2013 Michael Pasternak - 1.0.0.10-1 - to cluster.add()/.update() added [trusted_service] property - implement Secure Socket Layer (SSL) host verification (CA certificate) - allow nullifying headers via passing NULL as header value More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D From eedri at redhat.com Tue Jul 9 09:38:51 2013 From: eedri at redhat.com (Eyal Edri) Date: Tue, 9 Jul 2013 05:38:51 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <533513748.1004455.1373361689722.JavaMail.root@redhat.com> Message-ID: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> Hi, You all probably know and familiar with 'ovirt-engine' git hook for commit msg template [1]. this helps understand the general area of the patch in the project but it lacks additional info that might be valuable for scaling automatic tests in Jenkins CI. Let me explain: Infra team is working hard on expanding oVirt CI infrastructure and adding more tests in jenkins (per commit/patch). Adding important meta-data per patch can significatly improve the ability to run specific tests for each patch/commit, and not waste valuable resources on Jenkins jobs that are not relevant to the code in the patch. So the idea is to add/expand current metadata per patch, in the form of: (either) 1. expanding current header template to include more data like 'network' , 'setup', 'tools', 'virt' 2. adding a new label with relevant tags for the patch, called e.g 'METADATA: network, rest, virt' Jenkins jobs will then be able to parse that data and trigger only relevant jobs for it. this can also allow us to add more jobs per patch, an option that is very problematic today considering the amount of patches coming in to engine. Once agreed on a format, we'll be able to add a git hook to verify the validity of the commit msg. (similar to bug-url). if we're not 100% sure that the tags will cover all corner cases and we feel like we need to run the code on all jobs, we can a nightly job to run all the remaining jobs (but at least it won't run on every patch/commit). [1] : thoughts? Eyal Edri. From asegurap at redhat.com Tue Jul 9 09:41:45 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Tue, 9 Jul 2013 05:41:45 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> Message-ID: <1319713272.583901.1373362905982.JavaMail.root@redhat.com> I like the idea of having a label in the bottom part of the commit that is: METADATA: network which would be your second proposal. ----- Original Message ----- > From: "Eyal Edri" > To: "engine-devel" > Cc: "infra" > Sent: Tuesday, July 9, 2013 11:38:51 AM > Subject: [Engine-devel] Proposal for new commit msg design for engine commits > > Hi, > > You all probably know and familiar with 'ovirt-engine' git hook for commit > msg template [1]. > this helps understand the general area of the patch in the project but it > lacks additional info that might > be valuable for scaling automatic tests in Jenkins CI. > > Let me explain: > > Infra team is working hard on expanding oVirt CI infrastructure and adding > more tests in jenkins (per commit/patch). > Adding important meta-data per patch can significatly improve the ability to > run specific tests for each patch/commit, > and not waste valuable resources on Jenkins jobs that are not relevant to the > code in the patch. > > So the idea is to add/expand current metadata per patch, in the form of: > (either) > 1. expanding current header template to include more data like 'network' , > 'setup', 'tools', 'virt' > 2. adding a new label with relevant tags for the patch, called e.g > 'METADATA: network, rest, virt' > > Jenkins jobs will then be able to parse that data and trigger only relevant > jobs for it. > this can also allow us to add more jobs per patch, an option that is very > problematic today considering the amount of > patches coming in to engine. > > Once agreed on a format, we'll be able to add a git hook to verify the > validity of the commit msg. (similar to bug-url). > > if we're not 100% sure that the tags will cover all corner cases and we feel > like we need to run the code on all jobs, > we can a nightly job to run all the remaining jobs (but at least it won't run > on every patch/commit). > > [1] : > > > thoughts? > > Eyal Edri. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mgoldboi at redhat.com Tue Jul 9 10:30:14 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Tue, 09 Jul 2013 13:30:14 +0300 Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1319713272.583901.1373362905982.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <1319713272.583901.1373362905982.JavaMail.root@redhat.com> Message-ID: <51DBE636.7030107@redhat.com> On 07/09/2013 12:41 PM, Antoni Segura Puimedon wrote: > I like the idea of having a label in the bottom part of the commit that is: > > METADATA: network > > which would be your second proposal. > > ----- Original Message ----- >> From: "Eyal Edri" >> To: "engine-devel" >> Cc: "infra" >> Sent: Tuesday, July 9, 2013 11:38:51 AM >> Subject: [Engine-devel] Proposal for new commit msg design for engine commits >> >> Hi, >> >> You all probably know and familiar with 'ovirt-engine' git hook for commit >> msg template [1]. >> this helps understand the general area of the patch in the project but it >> lacks additional info that might >> be valuable for scaling automatic tests in Jenkins CI. >> >> Let me explain: >> >> Infra team is working hard on expanding oVirt CI infrastructure and adding >> more tests in jenkins (per commit/patch). >> Adding important meta-data per patch can significatly improve the ability to >> run specific tests for each patch/commit, >> and not waste valuable resources on Jenkins jobs that are not relevant to the >> code in the patch. >> >> So the idea is to add/expand current metadata per patch, in the form of: >> (either) >> 1. expanding current header template to include more data like 'network' , >> 'setup', 'tools', 'virt' >> 2. adding a new label with relevant tags for the patch, called e.g >> 'METADATA: network, rest, virt' >> >> Jenkins jobs will then be able to parse that data and trigger only relevant >> jobs for it. >> this can also allow us to add more jobs per patch, an option that is very >> problematic today considering the amount of >> patches coming in to engine. >> >> Once agreed on a format, we'll be able to add a git hook to verify the >> validity of the commit msg. (similar to bug-url). >> >> if we're not 100% sure that the tags will cover all corner cases and we feel >> like we need to run the code on all jobs, >> we can a nightly job to run all the remaining jobs (but at least it won't run >> on every patch/commit). >> >> [1] : >> >> >> thoughts? >> >> Eyal Edri. >> _______________________________________________ >> 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 +1 beside of letting CI know which tests to run (main goal) it will also help people understand the scope and effect of the change on a quick look. i think that we can do feature based (live-snapshot,upgrade,live-migration...) or area base tagging (virt,storage,network..), what do you think? From danken at redhat.com Tue Jul 9 12:08:19 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 9 Jul 2013 15:08:19 +0300 Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1319713272.583901.1373362905982.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <1319713272.583901.1373362905982.JavaMail.root@redhat.com> Message-ID: <20130709120819.GG545@redhat.com> On Tue, Jul 09, 2013 at 05:41:45AM -0400, Antoni Segura Puimedon wrote: > I like the idea of having a label in the bottom part of the commit that is: > > METADATA: network > This makes sense, but I find "METADATA" as an overly general term. Even something like Region_of_Interest: network is more humanly comprehensible. Another idea would be to add a gerrit-only set of flags, where the poster or reviewers have to tick which group of tests are most important to be run. > which would be your second proposal. > > ----- Original Message ----- > > From: "Eyal Edri" > > To: "engine-devel" > > Cc: "infra" > > Sent: Tuesday, July 9, 2013 11:38:51 AM > > Subject: [Engine-devel] Proposal for new commit msg design for engine commits > > > > Hi, > > > > You all probably know and familiar with 'ovirt-engine' git hook for commit > > msg template [1]. > > this helps understand the general area of the patch in the project but it > > lacks additional info that might > > be valuable for scaling automatic tests in Jenkins CI. > > > > Let me explain: > > > > Infra team is working hard on expanding oVirt CI infrastructure and adding > > more tests in jenkins (per commit/patch). > > Adding important meta-data per patch can significatly improve the ability to > > run specific tests for each patch/commit, > > and not waste valuable resources on Jenkins jobs that are not relevant to the > > code in the patch. > > > > So the idea is to add/expand current metadata per patch, in the form of: > > (either) > > 1. expanding current header template to include more data like 'network' , > > 'setup', 'tools', 'virt' > > 2. adding a new label with relevant tags for the patch, called e.g > > 'METADATA: network, rest, virt' > > > > Jenkins jobs will then be able to parse that data and trigger only relevant > > jobs for it. > > this can also allow us to add more jobs per patch, an option that is very > > problematic today considering the amount of > > patches coming in to engine. > > > > Once agreed on a format, we'll be able to add a git hook to verify the > > validity of the commit msg. (similar to bug-url). > > > > if we're not 100% sure that the tags will cover all corner cases and we feel > > like we need to run the code on all jobs, > > we can a nightly job to run all the remaining jobs (but at least it won't run > > on every patch/commit). > > > > [1] : > > > > > > thoughts? > > > > Eyal Edri. > > _______________________________________________ > > 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 Tue Jul 9 12:33:57 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 9 Jul 2013 08:33:57 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> Message-ID: <541281197.610361.1373373237759.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eyal Edri" > To: "engine-devel" > Cc: "infra" > Sent: Tuesday, July 9, 2013 12:38:51 PM > Subject: Proposal for new commit msg design for engine commits > > Hi, > > You all probably know and familiar with 'ovirt-engine' git hook for commit > msg template [1]. > this helps understand the general area of the patch in the project but it > lacks additional info that might > be valuable for scaling automatic tests in Jenkins CI. > > Let me explain: > > Infra team is working hard on expanding oVirt CI infrastructure and adding > more tests in jenkins (per commit/patch). > Adding important meta-data per patch can significatly improve the ability to > run specific tests for each patch/commit, > and not waste valuable resources on Jenkins jobs that are not relevant to the > code in the patch. > > So the idea is to add/expand current metadata per patch, in the form of: > (either) > 1. expanding current header template to include more data like 'network' , > 'setup', 'tools', 'virt' Please do not expand header, it is too short anyway. > 2. adding a new label with relevant tags for the patch, called e.g > 'METADATA: network, rest, virt' Having: CI-Tests: xxx CI-Tests: yyy CI-Tests: zzz Is much better. However, I don't think that it is the responsibility of the committer. I suggested some time ago to have metadata information within each source. Each source should have metadata of: 1. Maintainer group. 2. Subsystem. 3. Any other relevant. This way you can act automatically using this information. Java: /* * $OVIRT_METADATA.COMPONENT= */ or: // $OVIRT_METADATA.COMPONENT= Shell/python: # $OVIRT_METADATA.COMPONENT= Well, you get the idea... This signature will allow: a. find . -type f | xargs grep '\$OVIRT_METADATA.COMPONENT=mycomponent' b. Future automation within gerrit. Regards, Alon From kroberts at redhat.com Tue Jul 9 12:35:34 2013 From: kroberts at redhat.com (Keith Robertson) Date: Tue, 9 Jul 2013 08:35:34 -0400 (EDT) Subject: [Engine-devel] Recommended mechanism to restart Jenkins In-Reply-To: <966649969.1178576.1373373102025.JavaMail.root@redhat.com> Message-ID: <693927969.1179833.1373373334743.JavaMail.root@redhat.com> What is the recommended mechanism to restart the oVirt Jenkins CI server job when it fails due to an issue unrelated to a pushed patch? Should I... a) Add some newline/space to the commit message and re-push the patch (clunky but it shd work). b) Remove/add the 'oVirt Jenkins CI Server' reviewer from the Reviewer's list and re-add? (have no idea if this actually works) c) Something else here... Keith Keith Robertson 1-919-754-4004 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yzaslavs at redhat.com Tue Jul 9 12:42:24 2013 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Tue, 9 Jul 2013 08:42:24 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <541281197.610361.1373373237759.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> Message-ID: <502026617.1247179.1373373744620.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Eyal Edri" > Cc: "engine-devel" , "infra" > Sent: Tuesday, July 9, 2013 3:33:57 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > > > ----- Original Message ----- > > From: "Eyal Edri" > > To: "engine-devel" > > Cc: "infra" > > Sent: Tuesday, July 9, 2013 12:38:51 PM > > Subject: Proposal for new commit msg design for engine commits > > > > Hi, > > > > You all probably know and familiar with 'ovirt-engine' git hook for commit > > msg template [1]. > > this helps understand the general area of the patch in the project but it > > lacks additional info that might > > be valuable for scaling automatic tests in Jenkins CI. > > > > Let me explain: > > > > Infra team is working hard on expanding oVirt CI infrastructure and adding > > more tests in jenkins (per commit/patch). > > Adding important meta-data per patch can significatly improve the ability > > to > > run specific tests for each patch/commit, > > and not waste valuable resources on Jenkins jobs that are not relevant to > > the > > code in the patch. > > > > So the idea is to add/expand current metadata per patch, in the form of: > > (either) > > 1. expanding current header template to include more data like 'network' , > > 'setup', 'tools', 'virt' > > Please do not expand header, it is too short anyway. > > > 2. adding a new label with relevant tags for the patch, called e.g > > 'METADATA: network, rest, virt' > > Having: > > CI-Tests: xxx > CI-Tests: yyy > CI-Tests: zzz > > Is much better. I'm not sure we should have CI-Test - as we might use this for something else besides CI. Region_of_Interest as Dan suggests sounds better IMHO. > > However, I don't think that it is the responsibility of the committer. > > I suggested some time ago to have metadata information within each source. > > Each source should have metadata of: > > 1. Maintainer group. Not sure if this is always relevant, what if i'm fixing some unit test that got broken? it's enough to know I'm a maintainer, no? > 2. Subsystem. > 3. Any other relevant. > > This way you can act automatically using this information. > > Java: > /* > * $OVIRT_METADATA.COMPONENT= > */ > or: > // $OVIRT_METADATA.COMPONENT= > > Shell/python: > # $OVIRT_METADATA.COMPONENT= > > Well, you get the idea... > > This signature will allow: > a. find . -type f | xargs grep '\$OVIRT_METADATA.COMPONENT=mycomponent' > b. Future automation within gerrit. > > Regards, > Alon > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alonbl at redhat.com Tue Jul 9 12:49:36 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 9 Jul 2013 08:49:36 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <502026617.1247179.1373373744620.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> Message-ID: <1808737135.614105.1373374176266.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Yair Zaslavsky" > To: "Alon Bar-Lev" > Cc: "Eyal Edri" , "engine-devel" , "infra" > Sent: Tuesday, July 9, 2013 3:42:24 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Eyal Edri" > > Cc: "engine-devel" , "infra" > > Sent: Tuesday, July 9, 2013 3:33:57 PM > > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > > commits > > > > > > > > ----- Original Message ----- > > > From: "Eyal Edri" > > > To: "engine-devel" > > > Cc: "infra" > > > Sent: Tuesday, July 9, 2013 12:38:51 PM > > > Subject: Proposal for new commit msg design for engine commits > > > > > > Hi, > > > > > > You all probably know and familiar with 'ovirt-engine' git hook for > > > commit > > > msg template [1]. > > > this helps understand the general area of the patch in the project but it > > > lacks additional info that might > > > be valuable for scaling automatic tests in Jenkins CI. > > > > > > Let me explain: > > > > > > Infra team is working hard on expanding oVirt CI infrastructure and > > > adding > > > more tests in jenkins (per commit/patch). > > > Adding important meta-data per patch can significatly improve the ability > > > to > > > run specific tests for each patch/commit, > > > and not waste valuable resources on Jenkins jobs that are not relevant to > > > the > > > code in the patch. > > > > > > So the idea is to add/expand current metadata per patch, in the form of: > > > (either) > > > 1. expanding current header template to include more data like 'network' > > > , > > > 'setup', 'tools', 'virt' > > > > Please do not expand header, it is too short anyway. > > > > > 2. adding a new label with relevant tags for the patch, called e.g > > > 'METADATA: network, rest, virt' > > > > Having: > > > > CI-Tests: xxx > > CI-Tests: yyy > > CI-Tests: zzz > > > > Is much better. > > I'm not sure we should have CI-Test - as we might use this for something else > besides CI. > Region_of_Interest as Dan suggests sounds better IMHO. I don't care how this is to be called. However, I do not think that commit message is the place for instructing CI to do anything. Commit message stays for good, it should contain information that is required a year from now. It has nothing to do with tests and such. > > > > However, I don't think that it is the responsibility of the committer. > > > > I suggested some time ago to have metadata information within each source. > > > > Each source should have metadata of: > > > > 1. Maintainer group. > > Not sure if this is always relevant, what if i'm fixing some unit test that > got broken? it's enough to know I'm a maintainer, no? Drop the maintainer, it is a suggestion of extra metadata we can add to automatically CC relevant people. Add more metadata, so that every change in that file will trigger specific tests. > > > 2. Subsystem. > > 3. Any other relevant. > > > > This way you can act automatically using this information. > > > > Java: > > /* > > * $OVIRT_METADATA.COMPONENT= > > */ > > or: > > // $OVIRT_METADATA.COMPONENT= > > > > Shell/python: > > # $OVIRT_METADATA.COMPONENT= > > > > Well, you get the idea... > > > > This signature will allow: > > a. find . -type f | xargs grep '\$OVIRT_METADATA.COMPONENT=mycomponent' > > b. Future automation within gerrit. > > > > Regards, > > Alon > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From ecohen at redhat.com Tue Jul 9 13:05:23 2013 From: ecohen at redhat.com (Einav Cohen) Date: Tue, 9 Jul 2013 09:05:23 -0400 (EDT) Subject: [Engine-devel] oVirt GUI: GWT(P) Upgrade overview session starts NOW In-Reply-To: <1971769748.1328620.1373375099907.JavaMail.root@redhat.com> Message-ID: <1780331137.1328822.1373375123082.JavaMail.root@redhat.com> to connect: Intercall dial-in numbers: https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405 Intercall conference code: 712 886 7405 # Elluminate session link: https://sas.elluminate.com/m.jnlp?sid=819&password=M.132A81E7D3610CF042FB58CA335C55 ---- Regards, Einav From eedri at redhat.com Tue Jul 9 13:44:50 2013 From: eedri at redhat.com (Eyal Edri) Date: Tue, 9 Jul 2013 09:44:50 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1373374446.2593.2.camel@fdeutsch-laptop.local> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> Message-ID: <1276415181.1184060.1373377490383.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Alon Bar-Lev" > Cc: "engine-devel" , "infra" > Sent: Tuesday, July 9, 2013 3:54:06 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > > > > > > ----- Original Message ----- > > > From: "Yair Zaslavsky" > > > To: "Alon Bar-Lev" > > > Cc: "Eyal Edri" , "engine-devel" > > , "infra" > > > Sent: Tuesday, July 9, 2013 3:42:24 PM > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > > engine commits > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Alon Bar-Lev" > > > > To: "Eyal Edri" > > > > Cc: "engine-devel" , "infra" > > > > > > Sent: Tuesday, July 9, 2013 3:33:57 PM > > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > > engine > > > > commits > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Eyal Edri" > > > > > To: "engine-devel" > > > > > Cc: "infra" > > > > > Sent: Tuesday, July 9, 2013 12:38:51 PM > > > > > Subject: Proposal for new commit msg design for engine commits > > > > > > > > > > Hi, > > > > > > > > > > You all probably know and familiar with 'ovirt-engine' git hook > > for > > > > > commit > > > > > msg template [1]. > > > > > this helps understand the general area of the patch in the > > project but it > > > > > lacks additional info that might > > > > > be valuable for scaling automatic tests in Jenkins CI. > > > > > > > > > > Let me explain: > > > > > > > > > > Infra team is working hard on expanding oVirt CI infrastructure > > and > > > > > adding > > > > > more tests in jenkins (per commit/patch). > > > > > Adding important meta-data per patch can significatly improve > > the ability > > > > > to > > > > > run specific tests for each patch/commit, > > > > > and not waste valuable resources on Jenkins jobs that are not > > relevant to > > > > > the > > > > > code in the patch. > > > > > > > > > > So the idea is to add/expand current metadata per patch, in the > > form of: > > > > > (either) > > > > > 1. expanding current header template to include more data like > > 'network' > > > > > , > > > > > 'setup', 'tools', 'virt' > > > > > > > > Please do not expand header, it is too short anyway. > > > > > > > > > 2. adding a new label with relevant tags for the patch, called > > e.g > > > > > 'METADATA: network, rest, virt' > > > > > > > > Having: > > > > > > > > CI-Tests: xxx > > > > CI-Tests: yyy > > > > CI-Tests: zzz > > > > > > > > Is much better. > > > > > > I'm not sure we should have CI-Test - as we might use this for > > something else > > > besides CI. > > > Region_of_Interest as Dan suggests sounds better IMHO. > > > > I don't care how this is to be called. > > However, I do not think that commit message is the place for > > instructing CI to do anything. > > Commit message stays for good, it should contain information that is > > required a year from now. > > It has nothing to do with tests and such. > > I agree with Alon here that the Ci informations don't belong in the > commit msg. > My opinion is that a testcase should know what it covers. This > information from the testcase can then be used by any party to determin > if the testcase should be run on a specific commit (which yields > informations about the changed paths, files, owner, author, etc ... > which might be valuable). i don't understand what you mean by "a testcase should know what it covers". of course it does. that's not the problem though. the problem is ovirt-engine has multiple components with him that apply to various fields, some patches are relevant to specific areas and not not. so a "test case" (that clones ovirt-engine repo) can't know which tests to run if he doesn't have that info somewhere in the patch. if we don't want info in the git commit msg, we can try using git notes [1] but i think that this meta-data isn't all about ci jobs, it's about additional info on what the patch touches/adds. it can also help qa testing later to pinpoint where the code was changed and perhaps enable the use of future automation scripts that can scan the commits and generate statics on coverage per subject/field. [1] https://www.kernel.org/pub/software/scm/git/docs/git-notes.html http://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html > > - fabian > > _______________________________________________ > Infra mailing list > Infra at ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > From eedri at redhat.com Tue Jul 9 14:08:01 2013 From: eedri at redhat.com (Eyal Edri) Date: Tue, 9 Jul 2013 10:08:01 -0400 (EDT) Subject: [Engine-devel] Recommended mechanism to restart Jenkins In-Reply-To: <693927969.1179833.1373373334743.JavaMail.root@redhat.com> References: <693927969.1179833.1373373334743.JavaMail.root@redhat.com> Message-ID: <1350630244.1198077.1373378881623.JavaMail.root@redhat.com> i assume you mean restarting a failing gerrit jenkins job and not the master server right? there is a special link to exactly that, no need to rebases... http://jenkins.ovirt.org/gerrit_manual_trigger/? just put in your change id or sha1, click search and trigger it. Eyal. ----- Original Message ----- > From: "Keith Robertson" > To: engine-devel at ovirt.org > Cc: "Spenser Shumaker" > Sent: Tuesday, July 9, 2013 3:35:34 PM > Subject: [Engine-devel] Recommended mechanism to restart Jenkins > > What is the recommended mechanism to restart the oVirt Jenkins CI server job > when it fails due to an issue unrelated to a pushed patch? Should I... > > a) Add some newline/space to the commit message and re-push the patch (clunky > but it shd work). > b) Remove/add the 'oVirt Jenkins CI Server' reviewer from the Reviewer's list > and re-add? (have no idea if this actually works) > c) Something else here... > > Keith > > > Keith Robertson > 1-919-754-4004 > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From gvallare at redhat.com Tue Jul 9 17:51:30 2013 From: gvallare at redhat.com (Giuseppe Vallarelli) Date: Tue, 9 Jul 2013 13:51:30 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> Message-ID: <150370571.1858298.1373392290222.JavaMail.root@redhat.com> Hi Eyal, I really appreciate your concern and desire to streamline our CI infrastructure, but I'm afraid there might be some issues worth of discussing. If I've understood correctly a developer should add some kind of tags to idenfity the impact of the patch and so the subsets of tests (impact areas) that are going to be executed. I think it might be hard in some cases to properly identify the correct 'areas' and even error prone. I think that it really depends on how much engine software components are independent from each other and developer's codebase knowledge. I think it might be useful to have a dependency graph of components let's say at package level to define which tests should be executed, perhaps this is something that can be automate. We might discover that for transitivity a component depends on the whole engine. My 2 Czech Crowns Cheers, Giuseppe ----- Original Message ----- | From: "Eyal Edri" | To: "engine-devel" | Cc: "infra" | Sent: Tuesday, July 9, 2013 11:38:51 AM | Subject: [Engine-devel] Proposal for new commit msg design for engine commits | | Hi, | | You all probably know and familiar with 'ovirt-engine' git hook for commit | msg template [1]. | this helps understand the general area of the patch in the project but it | lacks additional info that might | be valuable for scaling automatic tests in Jenkins CI. | | Let me explain: | | Infra team is working hard on expanding oVirt CI infrastructure and adding | more tests in jenkins (per commit/patch). | Adding important meta-data per patch can significatly improve the ability to | run specific tests for each patch/commit, | and not waste valuable resources on Jenkins jobs that are not relevant to the | code in the patch. | | So the idea is to add/expand current metadata per patch, in the form of: | (either) | 1. expanding current header template to include more data like 'network' , | 'setup', 'tools', 'virt' | 2. adding a new label with relevant tags for the patch, called e.g | 'METADATA: network, rest, virt' | | Jenkins jobs will then be able to parse that data and trigger only relevant | jobs for it. | this can also allow us to add more jobs per patch, an option that is very | problematic today considering the amount of | patches coming in to engine. | | Once agreed on a format, we'll be able to add a git hook to verify the | validity of the commit msg. (similar to bug-url). | | if we're not 100% sure that the tags will cover all corner cases and we feel | like we need to run the code on all jobs, | we can a nightly job to run all the remaining jobs (but at least it won't run | on every patch/commit). | | [1] : | | | thoughts? | | Eyal Edri. | _______________________________________________ | Engine-devel mailing list | Engine-devel at ovirt.org | http://lists.ovirt.org/mailman/listinfo/engine-devel | From fabiand at redhat.com Tue Jul 9 12:54:06 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Tue, 09 Jul 2013 14:54:06 +0200 Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1808737135.614105.1373374176266.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> Message-ID: <1373374446.2593.2.camel@fdeutsch-laptop.local> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > To: "Alon Bar-Lev" > > Cc: "Eyal Edri" , "engine-devel" > , "infra" > > Sent: Tuesday, July 9, 2013 3:42:24 PM > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > engine commits > > > > > > > > ----- Original Message ----- > > > From: "Alon Bar-Lev" > > > To: "Eyal Edri" > > > Cc: "engine-devel" , "infra" > > > > Sent: Tuesday, July 9, 2013 3:33:57 PM > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > engine > > > commits > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Eyal Edri" > > > > To: "engine-devel" > > > > Cc: "infra" > > > > Sent: Tuesday, July 9, 2013 12:38:51 PM > > > > Subject: Proposal for new commit msg design for engine commits > > > > > > > > Hi, > > > > > > > > You all probably know and familiar with 'ovirt-engine' git hook > for > > > > commit > > > > msg template [1]. > > > > this helps understand the general area of the patch in the > project but it > > > > lacks additional info that might > > > > be valuable for scaling automatic tests in Jenkins CI. > > > > > > > > Let me explain: > > > > > > > > Infra team is working hard on expanding oVirt CI infrastructure > and > > > > adding > > > > more tests in jenkins (per commit/patch). > > > > Adding important meta-data per patch can significatly improve > the ability > > > > to > > > > run specific tests for each patch/commit, > > > > and not waste valuable resources on Jenkins jobs that are not > relevant to > > > > the > > > > code in the patch. > > > > > > > > So the idea is to add/expand current metadata per patch, in the > form of: > > > > (either) > > > > 1. expanding current header template to include more data like > 'network' > > > > , > > > > 'setup', 'tools', 'virt' > > > > > > Please do not expand header, it is too short anyway. > > > > > > > 2. adding a new label with relevant tags for the patch, called > e.g > > > > 'METADATA: network, rest, virt' > > > > > > Having: > > > > > > CI-Tests: xxx > > > CI-Tests: yyy > > > CI-Tests: zzz > > > > > > Is much better. > > > > I'm not sure we should have CI-Test - as we might use this for > something else > > besides CI. > > Region_of_Interest as Dan suggests sounds better IMHO. > > I don't care how this is to be called. > However, I do not think that commit message is the place for > instructing CI to do anything. > Commit message stays for good, it should contain information that is > required a year from now. > It has nothing to do with tests and such. I agree with Alon here that the Ci informations don't belong in the commit msg. My opinion is that a testcase should know what it covers. This information from the testcase can then be used by any party to determin if the testcase should be run on a specific commit (which yields informations about the changed paths, files, owner, author, etc ... which might be valuable). - fabian From iheim at redhat.com Wed Jul 10 19:00:20 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 10 Jul 2013 22:00:20 +0300 Subject: [Engine-devel] Recommended mechanism to restart Jenkins In-Reply-To: <1350630244.1198077.1373378881623.JavaMail.root@redhat.com> References: <693927969.1179833.1373373334743.JavaMail.root@redhat.com> <1350630244.1198077.1373378881623.JavaMail.root@redhat.com> Message-ID: <51DDAF44.9010109@redhat.com> On 07/09/2013 05:08 PM, Eyal Edri wrote: > i assume you mean restarting a failing gerrit jenkins job and not the master server right? > > there is a special link to exactly that, no need to rebases... > > http://jenkins.ovirt.org/gerrit_manual_trigger/? > > just put in your change id or sha1, click search and trigger it. > or just hit the rebase button? > Eyal. > > ----- Original Message ----- >> From: "Keith Robertson" >> To: engine-devel at ovirt.org >> Cc: "Spenser Shumaker" >> Sent: Tuesday, July 9, 2013 3:35:34 PM >> Subject: [Engine-devel] Recommended mechanism to restart Jenkins >> >> What is the recommended mechanism to restart the oVirt Jenkins CI server job >> when it fails due to an issue unrelated to a pushed patch? Should I... >> >> a) Add some newline/space to the commit message and re-push the patch (clunky >> but it shd work). >> b) Remove/add the 'oVirt Jenkins CI Server' reviewer from the Reviewer's list >> and re-add? (have no idea if this actually works) >> c) Something else here... >> >> Keith >> >> >> Keith Robertson >> 1-919-754-4004 >> >> >> _______________________________________________ >> 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 Wed Jul 10 19:27:00 2013 From: eedri at redhat.com (Eyal Edri) Date: Wed, 10 Jul 2013 15:27:00 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1373374446.2593.2.camel@fdeutsch-laptop.local> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> Message-ID: <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Alon Bar-Lev" > Cc: "engine-devel" , "infra" > Sent: Tuesday, July 9, 2013 3:54:06 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > > > > > > ----- Original Message ----- > > > From: "Yair Zaslavsky" > > > To: "Alon Bar-Lev" > > > Cc: "Eyal Edri" , "engine-devel" > > , "infra" > > > Sent: Tuesday, July 9, 2013 3:42:24 PM > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > > engine commits > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Alon Bar-Lev" > > > > To: "Eyal Edri" > > > > Cc: "engine-devel" , "infra" > > > > > > Sent: Tuesday, July 9, 2013 3:33:57 PM > > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > > engine > > > > commits > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Eyal Edri" > > > > > To: "engine-devel" > > > > > Cc: "infra" > > > > > Sent: Tuesday, July 9, 2013 12:38:51 PM > > > > > Subject: Proposal for new commit msg design for engine commits > > > > > > > > > > Hi, > > > > > > > > > > You all probably know and familiar with 'ovirt-engine' git hook > > for > > > > > commit > > > > > msg template [1]. > > > > > this helps understand the general area of the patch in the > > project but it > > > > > lacks additional info that might > > > > > be valuable for scaling automatic tests in Jenkins CI. > > > > > > > > > > Let me explain: > > > > > > > > > > Infra team is working hard on expanding oVirt CI infrastructure > > and > > > > > adding > > > > > more tests in jenkins (per commit/patch). > > > > > Adding important meta-data per patch can significatly improve > > the ability > > > > > to > > > > > run specific tests for each patch/commit, > > > > > and not waste valuable resources on Jenkins jobs that are not > > relevant to > > > > > the > > > > > code in the patch. > > > > > > > > > > So the idea is to add/expand current metadata per patch, in the > > form of: > > > > > (either) > > > > > 1. expanding current header template to include more data like > > 'network' > > > > > , > > > > > 'setup', 'tools', 'virt' > > > > > > > > Please do not expand header, it is too short anyway. > > > > > > > > > 2. adding a new label with relevant tags for the patch, called > > e.g > > > > > 'METADATA: network, rest, virt' > > > > > > > > Having: > > > > > > > > CI-Tests: xxx > > > > CI-Tests: yyy > > > > CI-Tests: zzz > > > > > > > > Is much better. > > > > > > I'm not sure we should have CI-Test - as we might use this for > > something else > > > besides CI. > > > Region_of_Interest as Dan suggests sounds better IMHO. > > > > I don't care how this is to be called. > > However, I do not think that commit message is the place for > > instructing CI to do anything. > > Commit message stays for good, it should contain information that is > > required a year from now. > > It has nothing to do with tests and such. > > I agree with Alon here that the Ci informations don't belong in the > commit msg. > My opinion is that a testcase should know what it covers. This > information from the testcase can then be used by any party to determin > if the testcase should be run on a specific commit (which yields > informations about the changed paths, files, owner, author, etc ... > which might be valuable). i think you're missing the point here. can you explain how do you propose a test case will know "what it covers"? let's take an example: let's say a new commit comes from ovirt-engine: http://gerrit.ovirt.org/#/c/16668/ commit msg: "core: Use images instead of volumes at CDA message". now you have 1000 test cases (could be system or functional test). (let's assume that your infra can't support running 1000 tests per patch/commit). Some of these test suits checks network flow, some virt (migration/template for e.g), some host install, others storage flows and so on... ). you have one repo to clone (ovirt-engine, let's keep vdsm a side for a min), and to compile the project from for the tests. now given this scenario, please explain how will you know which test from the 1000 you have you'll run on it. do you believe that according to the author/path/filename you'll know if that patch involves storage or virt scenario? i don't think there's an alternative to a metadata to assist mapping the patch to a relevant "topic" in the code. whether it exists as a git note or a label in the commit, that's another matter and probably less important. eyal. > > - fabian > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Wed Jul 10 19:37:03 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 10 Jul 2013 22:37:03 +0300 Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> Message-ID: <51DDB7DF.4040500@redhat.com> On 07/10/2013 10:27 PM, Eyal Edri wrote: > > > ----- Original Message ----- >> From: "Fabian Deutsch" >> To: "Alon Bar-Lev" >> Cc: "engine-devel" , "infra" >> Sent: Tuesday, July 9, 2013 3:54:06 PM >> Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits >> >> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: >>> >>> >>> ----- Original Message ----- >>>> From: "Yair Zaslavsky" >>>> To: "Alon Bar-Lev" >>>> Cc: "Eyal Edri" , "engine-devel" >>> , "infra" >>>> Sent: Tuesday, July 9, 2013 3:42:24 PM >>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for >>> engine commits >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Alon Bar-Lev" >>>>> To: "Eyal Edri" >>>>> Cc: "engine-devel" , "infra" >>> >>>>> Sent: Tuesday, July 9, 2013 3:33:57 PM >>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for >>> engine >>>>> commits >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Eyal Edri" >>>>>> To: "engine-devel" >>>>>> Cc: "infra" >>>>>> Sent: Tuesday, July 9, 2013 12:38:51 PM >>>>>> Subject: Proposal for new commit msg design for engine commits >>>>>> >>>>>> Hi, >>>>>> >>>>>> You all probably know and familiar with 'ovirt-engine' git hook >>> for >>>>>> commit >>>>>> msg template [1]. >>>>>> this helps understand the general area of the patch in the >>> project but it >>>>>> lacks additional info that might >>>>>> be valuable for scaling automatic tests in Jenkins CI. >>>>>> >>>>>> Let me explain: >>>>>> >>>>>> Infra team is working hard on expanding oVirt CI infrastructure >>> and >>>>>> adding >>>>>> more tests in jenkins (per commit/patch). >>>>>> Adding important meta-data per patch can significatly improve >>> the ability >>>>>> to >>>>>> run specific tests for each patch/commit, >>>>>> and not waste valuable resources on Jenkins jobs that are not >>> relevant to >>>>>> the >>>>>> code in the patch. >>>>>> >>>>>> So the idea is to add/expand current metadata per patch, in the >>> form of: >>>>>> (either) >>>>>> 1. expanding current header template to include more data like >>> 'network' >>>>>> , >>>>>> 'setup', 'tools', 'virt' >>>>> >>>>> Please do not expand header, it is too short anyway. >>>>> >>>>>> 2. adding a new label with relevant tags for the patch, called >>> e.g >>>>>> 'METADATA: network, rest, virt' >>>>> >>>>> Having: >>>>> >>>>> CI-Tests: xxx >>>>> CI-Tests: yyy >>>>> CI-Tests: zzz >>>>> >>>>> Is much better. >>>> >>>> I'm not sure we should have CI-Test - as we might use this for >>> something else >>>> besides CI. >>>> Region_of_Interest as Dan suggests sounds better IMHO. >>> >>> I don't care how this is to be called. >>> However, I do not think that commit message is the place for >>> instructing CI to do anything. >>> Commit message stays for good, it should contain information that is >>> required a year from now. >>> It has nothing to do with tests and such. >> >> I agree with Alon here that the Ci informations don't belong in the >> commit msg. >> My opinion is that a testcase should know what it covers. This >> information from the testcase can then be used by any party to determin >> if the testcase should be run on a specific commit (which yields >> informations about the changed paths, files, owner, author, etc ... >> which might be valuable). > > i think you're missing the point here. > can you explain how do you propose a test case will know "what it covers"? > > let's take an example: > let's say a new commit comes from ovirt-engine: http://gerrit.ovirt.org/#/c/16668/ > commit msg: "core: Use images instead of volumes at CDA message". > > now you have 1000 test cases (could be system or functional test). > (let's assume that your infra can't support running 1000 tests per patch/commit). > > Some of these test suits checks network flow, some virt (migration/template for e.g), some host install, others storage flows and so on... ). > you have one repo to clone (ovirt-engine, let's keep vdsm a side for a min), and to compile the project from for the tests. > > now given this scenario, please explain how will you know which test from the 1000 you have you'll run on it. > do you believe that according to the author/path/filename you'll know if that patch involves storage or virt scenario? > > i don't think there's an alternative to a metadata to assist mapping the patch to a relevant "topic" in the code. > whether it exists as a git note or a label in the commit, that's another matter and probably less important. we could use gerrit labels per test topic? > > eyal. > >> >> - fabian >> >> _______________________________________________ >> 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 Wed Jul 10 19:50:13 2013 From: eedri at redhat.com (Eyal Edri) Date: Wed, 10 Jul 2013 15:50:13 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <51DDB7DF.4040500@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <51DDB7DF.4040500@redhat.com> Message-ID: <1683098460.2037289.1373485813726.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Eyal Edri" > Cc: "Fabian Deutsch" , "engine-devel" , "infra" > Sent: Wednesday, July 10, 2013 10:37:03 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > On 07/10/2013 10:27 PM, Eyal Edri wrote: > > > > > > ----- Original Message ----- > >> From: "Fabian Deutsch" > >> To: "Alon Bar-Lev" > >> Cc: "engine-devel" , "infra" > >> Sent: Tuesday, July 9, 2013 3:54:06 PM > >> Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > >> commits > >> > >> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Yair Zaslavsky" > >>>> To: "Alon Bar-Lev" > >>>> Cc: "Eyal Edri" , "engine-devel" > >>> , "infra" > >>>> Sent: Tuesday, July 9, 2013 3:42:24 PM > >>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > >>> engine commits > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Alon Bar-Lev" > >>>>> To: "Eyal Edri" > >>>>> Cc: "engine-devel" , "infra" > >>> > >>>>> Sent: Tuesday, July 9, 2013 3:33:57 PM > >>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > >>> engine > >>>>> commits > >>>>> > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Eyal Edri" > >>>>>> To: "engine-devel" > >>>>>> Cc: "infra" > >>>>>> Sent: Tuesday, July 9, 2013 12:38:51 PM > >>>>>> Subject: Proposal for new commit msg design for engine commits > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> You all probably know and familiar with 'ovirt-engine' git hook > >>> for > >>>>>> commit > >>>>>> msg template [1]. > >>>>>> this helps understand the general area of the patch in the > >>> project but it > >>>>>> lacks additional info that might > >>>>>> be valuable for scaling automatic tests in Jenkins CI. > >>>>>> > >>>>>> Let me explain: > >>>>>> > >>>>>> Infra team is working hard on expanding oVirt CI infrastructure > >>> and > >>>>>> adding > >>>>>> more tests in jenkins (per commit/patch). > >>>>>> Adding important meta-data per patch can significatly improve > >>> the ability > >>>>>> to > >>>>>> run specific tests for each patch/commit, > >>>>>> and not waste valuable resources on Jenkins jobs that are not > >>> relevant to > >>>>>> the > >>>>>> code in the patch. > >>>>>> > >>>>>> So the idea is to add/expand current metadata per patch, in the > >>> form of: > >>>>>> (either) > >>>>>> 1. expanding current header template to include more data like > >>> 'network' > >>>>>> , > >>>>>> 'setup', 'tools', 'virt' > >>>>> > >>>>> Please do not expand header, it is too short anyway. > >>>>> > >>>>>> 2. adding a new label with relevant tags for the patch, called > >>> e.g > >>>>>> 'METADATA: network, rest, virt' > >>>>> > >>>>> Having: > >>>>> > >>>>> CI-Tests: xxx > >>>>> CI-Tests: yyy > >>>>> CI-Tests: zzz > >>>>> > >>>>> Is much better. > >>>> > >>>> I'm not sure we should have CI-Test - as we might use this for > >>> something else > >>>> besides CI. > >>>> Region_of_Interest as Dan suggests sounds better IMHO. > >>> > >>> I don't care how this is to be called. > >>> However, I do not think that commit message is the place for > >>> instructing CI to do anything. > >>> Commit message stays for good, it should contain information that is > >>> required a year from now. > >>> It has nothing to do with tests and such. > >> > >> I agree with Alon here that the Ci informations don't belong in the > >> commit msg. > >> My opinion is that a testcase should know what it covers. This > >> information from the testcase can then be used by any party to determin > >> if the testcase should be run on a specific commit (which yields > >> informations about the changed paths, files, owner, author, etc ... > >> which might be valuable). > > > > i think you're missing the point here. > > can you explain how do you propose a test case will know "what it covers"? > > > > let's take an example: > > let's say a new commit comes from ovirt-engine: > > http://gerrit.ovirt.org/#/c/16668/ > > commit msg: "core: Use images instead of volumes at CDA message". > > > > now you have 1000 test cases (could be system or functional test). > > (let's assume that your infra can't support running 1000 tests per > > patch/commit). > > > > Some of these test suits checks network flow, some virt (migration/template > > for e.g), some host install, others storage flows and so on... ). > > you have one repo to clone (ovirt-engine, let's keep vdsm a side for a > > min), and to compile the project from for the tests. > > > > now given this scenario, please explain how will you know which test from > > the 1000 you have you'll run on it. > > do you believe that according to the author/path/filename you'll know if > > that patch involves storage or virt scenario? > > > > i don't think there's an alternative to a metadata to assist mapping the > > patch to a relevant "topic" in the code. > > whether it exists as a git note or a label in the commit, that's another > > matter and probably less important. > > we could use gerrit labels per test topic? > sure, if gerrit allows adding any metadata per commit that doesn't have to be in the commit msg and can be read via api per patch, that will work as well. > > > > eyal. > > > >> > >> - fabian > >> > >> _______________________________________________ > >> 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 Wed Jul 10 19:53:16 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 10 Jul 2013 15:53:16 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <51DDB7DF.4040500@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <51DDB7DF.4040500@redhat.com> Message-ID: <1009451043.1229898.1373485996588.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Eyal Edri" > Cc: "engine-devel" , "infra" > Sent: Wednesday, July 10, 2013 10:37:03 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > On 07/10/2013 10:27 PM, Eyal Edri wrote: > > > > > > ----- Original Message ----- > >> From: "Fabian Deutsch" > >> To: "Alon Bar-Lev" > >> Cc: "engine-devel" , "infra" > >> Sent: Tuesday, July 9, 2013 3:54:06 PM > >> Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > >> commits > >> > >> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Yair Zaslavsky" > >>>> To: "Alon Bar-Lev" > >>>> Cc: "Eyal Edri" , "engine-devel" > >>> , "infra" > >>>> Sent: Tuesday, July 9, 2013 3:42:24 PM > >>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > >>> engine commits > >>>> > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Alon Bar-Lev" > >>>>> To: "Eyal Edri" > >>>>> Cc: "engine-devel" , "infra" > >>> > >>>>> Sent: Tuesday, July 9, 2013 3:33:57 PM > >>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > >>> engine > >>>>> commits > >>>>> > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Eyal Edri" > >>>>>> To: "engine-devel" > >>>>>> Cc: "infra" > >>>>>> Sent: Tuesday, July 9, 2013 12:38:51 PM > >>>>>> Subject: Proposal for new commit msg design for engine commits > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> You all probably know and familiar with 'ovirt-engine' git hook > >>> for > >>>>>> commit > >>>>>> msg template [1]. > >>>>>> this helps understand the general area of the patch in the > >>> project but it > >>>>>> lacks additional info that might > >>>>>> be valuable for scaling automatic tests in Jenkins CI. > >>>>>> > >>>>>> Let me explain: > >>>>>> > >>>>>> Infra team is working hard on expanding oVirt CI infrastructure > >>> and > >>>>>> adding > >>>>>> more tests in jenkins (per commit/patch). > >>>>>> Adding important meta-data per patch can significatly improve > >>> the ability > >>>>>> to > >>>>>> run specific tests for each patch/commit, > >>>>>> and not waste valuable resources on Jenkins jobs that are not > >>> relevant to > >>>>>> the > >>>>>> code in the patch. > >>>>>> > >>>>>> So the idea is to add/expand current metadata per patch, in the > >>> form of: > >>>>>> (either) > >>>>>> 1. expanding current header template to include more data like > >>> 'network' > >>>>>> , > >>>>>> 'setup', 'tools', 'virt' > >>>>> > >>>>> Please do not expand header, it is too short anyway. > >>>>> > >>>>>> 2. adding a new label with relevant tags for the patch, called > >>> e.g > >>>>>> 'METADATA: network, rest, virt' > >>>>> > >>>>> Having: > >>>>> > >>>>> CI-Tests: xxx > >>>>> CI-Tests: yyy > >>>>> CI-Tests: zzz > >>>>> > >>>>> Is much better. > >>>> > >>>> I'm not sure we should have CI-Test - as we might use this for > >>> something else > >>>> besides CI. > >>>> Region_of_Interest as Dan suggests sounds better IMHO. > >>> > >>> I don't care how this is to be called. > >>> However, I do not think that commit message is the place for > >>> instructing CI to do anything. > >>> Commit message stays for good, it should contain information that is > >>> required a year from now. > >>> It has nothing to do with tests and such. > >> > >> I agree with Alon here that the Ci informations don't belong in the > >> commit msg. > >> My opinion is that a testcase should know what it covers. This > >> information from the testcase can then be used by any party to determin > >> if the testcase should be run on a specific commit (which yields > >> informations about the changed paths, files, owner, author, etc ... > >> which might be valuable). > > > > i think you're missing the point here. > > can you explain how do you propose a test case will know "what it covers"? > > > > let's take an example: > > let's say a new commit comes from ovirt-engine: > > http://gerrit.ovirt.org/#/c/16668/ > > commit msg: "core: Use images instead of volumes at CDA message". > > > > now you have 1000 test cases (could be system or functional test). > > (let's assume that your infra can't support running 1000 tests per > > patch/commit). > > > > Some of these test suits checks network flow, some virt (migration/template > > for e.g), some host install, others storage flows and so on... ). > > you have one repo to clone (ovirt-engine, let's keep vdsm a side for a > > min), and to compile the project from for the tests. > > > > now given this scenario, please explain how will you know which test from > > the 1000 you have you'll run on it. > > do you believe that according to the author/path/filename you'll know if > > that patch involves storage or virt scenario? > > > > i don't think there's an alternative to a metadata to assist mapping the > > patch to a relevant "topic" in the code. > > whether it exists as a git note or a label in the commit, that's another > > matter and probably less important. > > we could use gerrit labels per test topic? I don't think it should be by patch bases, but common logic based of metadata, if we do this within source tree maintainer can choose which tests he wish to have by simply commit metadata into the source tree. Asking for a special test can always be done in jenkins post commit, or by some generic field in gerrit. However, the standard test suites is something that should be applied via policy of the component in question using approved metadata. > > > > > eyal. > > > >> > >> - fabian > >> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > Infra mailing list > Infra at ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > From iheim at redhat.com Wed Jul 10 19:53:33 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 10 Jul 2013 22:53:33 +0300 Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1683098460.2037289.1373485813726.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <51DDB7DF.4040500@redhat.com> <1683098460.2037289.1373485813726.JavaMail.root@redhat.com> Message-ID: <51DDBBBD.3070704@redhat.com> On 07/10/2013 10:50 PM, Eyal Edri wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Eyal Edri" >> Cc: "Fabian Deutsch" , "engine-devel" , "infra" >> Sent: Wednesday, July 10, 2013 10:37:03 PM >> Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits >> >> On 07/10/2013 10:27 PM, Eyal Edri wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Fabian Deutsch" >>>> To: "Alon Bar-Lev" >>>> Cc: "engine-devel" , "infra" >>>> Sent: Tuesday, July 9, 2013 3:54:06 PM >>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for engine >>>> commits >>>> >>>> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Yair Zaslavsky" >>>>>> To: "Alon Bar-Lev" >>>>>> Cc: "Eyal Edri" , "engine-devel" >>>>> , "infra" >>>>>> Sent: Tuesday, July 9, 2013 3:42:24 PM >>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for >>>>> engine commits >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Alon Bar-Lev" >>>>>>> To: "Eyal Edri" >>>>>>> Cc: "engine-devel" , "infra" >>>>> >>>>>>> Sent: Tuesday, July 9, 2013 3:33:57 PM >>>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for >>>>> engine >>>>>>> commits >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Eyal Edri" >>>>>>>> To: "engine-devel" >>>>>>>> Cc: "infra" >>>>>>>> Sent: Tuesday, July 9, 2013 12:38:51 PM >>>>>>>> Subject: Proposal for new commit msg design for engine commits >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> You all probably know and familiar with 'ovirt-engine' git hook >>>>> for >>>>>>>> commit >>>>>>>> msg template [1]. >>>>>>>> this helps understand the general area of the patch in the >>>>> project but it >>>>>>>> lacks additional info that might >>>>>>>> be valuable for scaling automatic tests in Jenkins CI. >>>>>>>> >>>>>>>> Let me explain: >>>>>>>> >>>>>>>> Infra team is working hard on expanding oVirt CI infrastructure >>>>> and >>>>>>>> adding >>>>>>>> more tests in jenkins (per commit/patch). >>>>>>>> Adding important meta-data per patch can significatly improve >>>>> the ability >>>>>>>> to >>>>>>>> run specific tests for each patch/commit, >>>>>>>> and not waste valuable resources on Jenkins jobs that are not >>>>> relevant to >>>>>>>> the >>>>>>>> code in the patch. >>>>>>>> >>>>>>>> So the idea is to add/expand current metadata per patch, in the >>>>> form of: >>>>>>>> (either) >>>>>>>> 1. expanding current header template to include more data like >>>>> 'network' >>>>>>>> , >>>>>>>> 'setup', 'tools', 'virt' >>>>>>> >>>>>>> Please do not expand header, it is too short anyway. >>>>>>> >>>>>>>> 2. adding a new label with relevant tags for the patch, called >>>>> e.g >>>>>>>> 'METADATA: network, rest, virt' >>>>>>> >>>>>>> Having: >>>>>>> >>>>>>> CI-Tests: xxx >>>>>>> CI-Tests: yyy >>>>>>> CI-Tests: zzz >>>>>>> >>>>>>> Is much better. >>>>>> >>>>>> I'm not sure we should have CI-Test - as we might use this for >>>>> something else >>>>>> besides CI. >>>>>> Region_of_Interest as Dan suggests sounds better IMHO. >>>>> >>>>> I don't care how this is to be called. >>>>> However, I do not think that commit message is the place for >>>>> instructing CI to do anything. >>>>> Commit message stays for good, it should contain information that is >>>>> required a year from now. >>>>> It has nothing to do with tests and such. >>>> >>>> I agree with Alon here that the Ci informations don't belong in the >>>> commit msg. >>>> My opinion is that a testcase should know what it covers. This >>>> information from the testcase can then be used by any party to determin >>>> if the testcase should be run on a specific commit (which yields >>>> informations about the changed paths, files, owner, author, etc ... >>>> which might be valuable). >>> >>> i think you're missing the point here. >>> can you explain how do you propose a test case will know "what it covers"? >>> >>> let's take an example: >>> let's say a new commit comes from ovirt-engine: >>> http://gerrit.ovirt.org/#/c/16668/ >>> commit msg: "core: Use images instead of volumes at CDA message". >>> >>> now you have 1000 test cases (could be system or functional test). >>> (let's assume that your infra can't support running 1000 tests per >>> patch/commit). >>> >>> Some of these test suits checks network flow, some virt (migration/template >>> for e.g), some host install, others storage flows and so on... ). >>> you have one repo to clone (ovirt-engine, let's keep vdsm a side for a >>> min), and to compile the project from for the tests. >>> >>> now given this scenario, please explain how will you know which test from >>> the 1000 you have you'll run on it. >>> do you believe that according to the author/path/filename you'll know if >>> that patch involves storage or virt scenario? >>> >>> i don't think there's an alternative to a metadata to assist mapping the >>> patch to a relevant "topic" in the code. >>> whether it exists as a git note or a label in the commit, that's another >>> matter and probably less important. >> >> we could use gerrit labels per test topic? >> > > sure, if gerrit allows adding any metadata per commit that doesn't have to be in the commit msg > and can be read via api per patch, that will work as well. soon... (gerrit 2.6) though categories will probably be the same for all projects, so not sure its the best approach for something with more than a few. (could also be done via a review comment in gerrit i guess which is free text) From mkolesni at redhat.com Thu Jul 11 06:41:16 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Thu, 11 Jul 2013 02:41:16 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1009451043.1229898.1373485996588.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <51DDB7DF.4040500@redhat.com> <1009451043.1229898.1373485996588.JavaMail.root@redhat.com> Message-ID: <959108235.2273349.1373524876912.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Eyal Edri" > > Cc: "engine-devel" , "infra" > > Sent: Wednesday, July 10, 2013 10:37:03 PM > > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > > commits > > > > On 07/10/2013 10:27 PM, Eyal Edri wrote: > > > > > > > > > ----- Original Message ----- > > >> From: "Fabian Deutsch" > > >> To: "Alon Bar-Lev" > > >> Cc: "engine-devel" , "infra" > > >> Sent: Tuesday, July 9, 2013 3:54:06 PM > > >> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > >> engine > > >> commits > > >> > > >> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > > >>> > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Yair Zaslavsky" > > >>>> To: "Alon Bar-Lev" > > >>>> Cc: "Eyal Edri" , "engine-devel" > > >>> , "infra" > > >>>> Sent: Tuesday, July 9, 2013 3:42:24 PM > > >>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > >>> engine commits > > >>>> > > >>>> > > >>>> > > >>>> ----- Original Message ----- > > >>>>> From: "Alon Bar-Lev" > > >>>>> To: "Eyal Edri" > > >>>>> Cc: "engine-devel" , "infra" > > >>> > > >>>>> Sent: Tuesday, July 9, 2013 3:33:57 PM > > >>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > >>> engine > > >>>>> commits > > >>>>> > > >>>>> > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> From: "Eyal Edri" > > >>>>>> To: "engine-devel" > > >>>>>> Cc: "infra" > > >>>>>> Sent: Tuesday, July 9, 2013 12:38:51 PM > > >>>>>> Subject: Proposal for new commit msg design for engine commits > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> You all probably know and familiar with 'ovirt-engine' git hook > > >>> for > > >>>>>> commit > > >>>>>> msg template [1]. > > >>>>>> this helps understand the general area of the patch in the > > >>> project but it > > >>>>>> lacks additional info that might > > >>>>>> be valuable for scaling automatic tests in Jenkins CI. > > >>>>>> > > >>>>>> Let me explain: > > >>>>>> > > >>>>>> Infra team is working hard on expanding oVirt CI infrastructure > > >>> and > > >>>>>> adding > > >>>>>> more tests in jenkins (per commit/patch). > > >>>>>> Adding important meta-data per patch can significatly improve > > >>> the ability > > >>>>>> to > > >>>>>> run specific tests for each patch/commit, > > >>>>>> and not waste valuable resources on Jenkins jobs that are not > > >>> relevant to > > >>>>>> the > > >>>>>> code in the patch. > > >>>>>> > > >>>>>> So the idea is to add/expand current metadata per patch, in the > > >>> form of: > > >>>>>> (either) > > >>>>>> 1. expanding current header template to include more data like > > >>> 'network' > > >>>>>> , > > >>>>>> 'setup', 'tools', 'virt' > > >>>>> > > >>>>> Please do not expand header, it is too short anyway. > > >>>>> > > >>>>>> 2. adding a new label with relevant tags for the patch, called > > >>> e.g > > >>>>>> 'METADATA: network, rest, virt' > > >>>>> > > >>>>> Having: > > >>>>> > > >>>>> CI-Tests: xxx > > >>>>> CI-Tests: yyy > > >>>>> CI-Tests: zzz > > >>>>> > > >>>>> Is much better. > > >>>> > > >>>> I'm not sure we should have CI-Test - as we might use this for > > >>> something else > > >>>> besides CI. > > >>>> Region_of_Interest as Dan suggests sounds better IMHO. > > >>> > > >>> I don't care how this is to be called. > > >>> However, I do not think that commit message is the place for > > >>> instructing CI to do anything. > > >>> Commit message stays for good, it should contain information that is > > >>> required a year from now. > > >>> It has nothing to do with tests and such. > > >> > > >> I agree with Alon here that the Ci informations don't belong in the > > >> commit msg. > > >> My opinion is that a testcase should know what it covers. This > > >> information from the testcase can then be used by any party to determin > > >> if the testcase should be run on a specific commit (which yields > > >> informations about the changed paths, files, owner, author, etc ... > > >> which might be valuable). > > > > > > i think you're missing the point here. > > > can you explain how do you propose a test case will know "what it > > > covers"? > > > > > > let's take an example: > > > let's say a new commit comes from ovirt-engine: > > > http://gerrit.ovirt.org/#/c/16668/ > > > commit msg: "core: Use images instead of volumes at CDA message". > > > > > > now you have 1000 test cases (could be system or functional test). > > > (let's assume that your infra can't support running 1000 tests per > > > patch/commit). > > > > > > Some of these test suits checks network flow, some virt > > > (migration/template > > > for e.g), some host install, others storage flows and so on... ). > > > you have one repo to clone (ovirt-engine, let's keep vdsm a side for a > > > min), and to compile the project from for the tests. > > > > > > now given this scenario, please explain how will you know which test from > > > the 1000 you have you'll run on it. > > > do you believe that according to the author/path/filename you'll know if > > > that patch involves storage or virt scenario? > > > > > > i don't think there's an alternative to a metadata to assist mapping the > > > patch to a relevant "topic" in the code. > > > whether it exists as a git note or a label in the commit, that's another > > > matter and probably less important. > > > > we could use gerrit labels per test topic? > > I don't think it should be by patch bases, but common logic based of > metadata, if we do this within source tree maintainer can choose which tests > he wish to have by simply commit metadata into the source tree. > > Asking for a special test can always be done in jenkins post commit, or by > some generic field in gerrit. > > However, the standard test suites is something that should be applied via > policy of the component in question using approved metadata. > +1 It's up to the maintainers to decide which tests cover their code, not up to the committer. From fabiand at redhat.com Thu Jul 11 08:41:24 2013 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 11 Jul 2013 10:41:24 +0200 Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> Message-ID: <1373532084.2489.25.camel@fdeutsch-laptop.local> Am Mittwoch, den 10.07.2013, 15:27 -0400 schrieb Eyal Edri: > > ----- Original Message ----- > > From: "Fabian Deutsch" > > To: "Alon Bar-Lev" > > Cc: "engine-devel" , "infra" > > Sent: Tuesday, July 9, 2013 3:54:06 PM > > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > > > Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > > > > > > > > > ----- Original Message ----- > > > > From: "Yair Zaslavsky" > > > > To: "Alon Bar-Lev" > > > > Cc: "Eyal Edri" , "engine-devel" > > > , "infra" > > > > Sent: Tuesday, July 9, 2013 3:42:24 PM > > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > > > engine commits > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Alon Bar-Lev" > > > > > To: "Eyal Edri" > > > > > Cc: "engine-devel" , "infra" > > > > > > > > Sent: Tuesday, July 9, 2013 3:33:57 PM > > > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > > > engine > > > > > commits > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Eyal Edri" > > > > > > To: "engine-devel" > > > > > > Cc: "infra" > > > > > > Sent: Tuesday, July 9, 2013 12:38:51 PM > > > > > > Subject: Proposal for new commit msg design for engine commits > > > > > > > > > > > > Hi, > > > > > > > > > > > > You all probably know and familiar with 'ovirt-engine' git hook > > > for > > > > > > commit > > > > > > msg template [1]. > > > > > > this helps understand the general area of the patch in the > > > project but it > > > > > > lacks additional info that might > > > > > > be valuable for scaling automatic tests in Jenkins CI. > > > > > > > > > > > > Let me explain: > > > > > > > > > > > > Infra team is working hard on expanding oVirt CI infrastructure > > > and > > > > > > adding > > > > > > more tests in jenkins (per commit/patch). > > > > > > Adding important meta-data per patch can significatly improve > > > the ability > > > > > > to > > > > > > run specific tests for each patch/commit, > > > > > > and not waste valuable resources on Jenkins jobs that are not > > > relevant to > > > > > > the > > > > > > code in the patch. > > > > > > > > > > > > So the idea is to add/expand current metadata per patch, in the > > > form of: > > > > > > (either) > > > > > > 1. expanding current header template to include more data like > > > 'network' > > > > > > , > > > > > > 'setup', 'tools', 'virt' > > > > > > > > > > Please do not expand header, it is too short anyway. > > > > > > > > > > > 2. adding a new label with relevant tags for the patch, called > > > e.g > > > > > > 'METADATA: network, rest, virt' > > > > > > > > > > Having: > > > > > > > > > > CI-Tests: xxx > > > > > CI-Tests: yyy > > > > > CI-Tests: zzz > > > > > > > > > > Is much better. > > > > > > > > I'm not sure we should have CI-Test - as we might use this for > > > something else > > > > besides CI. > > > > Region_of_Interest as Dan suggests sounds better IMHO. > > > > > > I don't care how this is to be called. > > > However, I do not think that commit message is the place for > > > instructing CI to do anything. > > > Commit message stays for good, it should contain information that is > > > required a year from now. > > > It has nothing to do with tests and such. > > > > I agree with Alon here that the Ci informations don't belong in the > > commit msg. > > My opinion is that a testcase should know what it covers. This > > information from the testcase can then be used by any party to determin > > if the testcase should be run on a specific commit (which yields > > informations about the changed paths, files, owner, author, etc ... > > which might be valuable). > > i think you're missing the point here. > can you explain how do you propose a test case will know "what it covers"? > > let's take an example: > let's say a new commit comes from ovirt-engine: http://gerrit.ovirt.org/#/c/16668/ > commit msg: "core: Use images instead of volumes at CDA message". > > now you have 1000 test cases (could be system or functional test). > (let's assume that your infra can't support running 1000 tests per patch/commit). > > Some of these test suits checks network flow, some virt (migration/template for e.g), some host install, others storage flows and so on... ). > you have one repo to clone (ovirt-engine, let's keep vdsm a side for a min), and to compile the project from for the tests. > > now given this scenario, please explain how will you know which test from the 1000 you have you'll run on it. > do you believe that according to the author/path/filename you'll know if that patch involves storage or virt scenario? Hey Eyal, Yes - I would at least give it a try to decide automagically what tests to run by looking at the change. The main motivation for this is to not add another things which the committer needs to take care of and IMO we humans tend to fail (at some point) on those boring tasks like adding correct metadata (let it be a typo or just not adding the correct testsuites/topis to be run). But let's get back to your example. Basically we can use the path and filename to determin what testsuite to run. Testsuites could be bound to paths and/or filenames and/or regexes being matched against the full filename. Another approach would be to use a java package dependency tree to determine which classes are directly and indirectly affected by a change. This information can then be used to also build a set of testsuites to be run. For example: World uses Ocean uses Wale uses Cell - if Wale changes, we'll surely want to run the testsuites assigned to the classes higher up in the dependency chain (World and Ocean). For the concrete example above: Maybe there is a spell checker testcase which could be bound to the filename glob pattern *.properties. > i don't think there's an alternative to a metadata to assist mapping the patch to a relevant "topic" in the code. > whether it exists as a git note or a label in the commit, that's another matter and probably less important. The idea is to use the path/filename and dependency tree informations to model these topics. Example: WaterTestsuite(Topic): regex_in_change: .*\.fish glob_in_change: src/classes/ocean/*.java path_in_change: src/classes/water.java change_affects_depency_of: WaterClass But surely labels or meta-data in the commit msg are quicker to implement. - fabian > eyal. > > > > > - fabian > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From eedri at redhat.com Thu Jul 11 08:57:31 2013 From: eedri at redhat.com (Eyal Edri) Date: Thu, 11 Jul 2013 04:57:31 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1373532084.2489.25.camel@fdeutsch-laptop.local> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <1373532084.2489.25.camel@fdeutsch-laptop.local> Message-ID: <693107913.2226423.1373533051598.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Eyal Edri" > Cc: "Alon Bar-Lev" , "engine-devel" , "infra" > Sent: Thursday, July 11, 2013 11:41:24 AM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > Am Mittwoch, den 10.07.2013, 15:27 -0400 schrieb Eyal Edri: > > > > ----- Original Message ----- > > > From: "Fabian Deutsch" > > > To: "Alon Bar-Lev" > > > Cc: "engine-devel" , "infra" > > > Sent: Tuesday, July 9, 2013 3:54:06 PM > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > > > commits > > > > > > Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Yair Zaslavsky" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "Eyal Edri" , "engine-devel" > > > > , "infra" > > > > > Sent: Tuesday, July 9, 2013 3:42:24 PM > > > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > > > > engine commits > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Alon Bar-Lev" > > > > > > To: "Eyal Edri" > > > > > > Cc: "engine-devel" , "infra" > > > > > > > > > > Sent: Tuesday, July 9, 2013 3:33:57 PM > > > > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > > > > engine > > > > > > commits > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Eyal Edri" > > > > > > > To: "engine-devel" > > > > > > > Cc: "infra" > > > > > > > Sent: Tuesday, July 9, 2013 12:38:51 PM > > > > > > > Subject: Proposal for new commit msg design for engine commits > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > You all probably know and familiar with 'ovirt-engine' git hook > > > > for > > > > > > > commit > > > > > > > msg template [1]. > > > > > > > this helps understand the general area of the patch in the > > > > project but it > > > > > > > lacks additional info that might > > > > > > > be valuable for scaling automatic tests in Jenkins CI. > > > > > > > > > > > > > > Let me explain: > > > > > > > > > > > > > > Infra team is working hard on expanding oVirt CI infrastructure > > > > and > > > > > > > adding > > > > > > > more tests in jenkins (per commit/patch). > > > > > > > Adding important meta-data per patch can significatly improve > > > > the ability > > > > > > > to > > > > > > > run specific tests for each patch/commit, > > > > > > > and not waste valuable resources on Jenkins jobs that are not > > > > relevant to > > > > > > > the > > > > > > > code in the patch. > > > > > > > > > > > > > > So the idea is to add/expand current metadata per patch, in the > > > > form of: > > > > > > > (either) > > > > > > > 1. expanding current header template to include more data like > > > > 'network' > > > > > > > , > > > > > > > 'setup', 'tools', 'virt' > > > > > > > > > > > > Please do not expand header, it is too short anyway. > > > > > > > > > > > > > 2. adding a new label with relevant tags for the patch, called > > > > e.g > > > > > > > 'METADATA: network, rest, virt' > > > > > > > > > > > > Having: > > > > > > > > > > > > CI-Tests: xxx > > > > > > CI-Tests: yyy > > > > > > CI-Tests: zzz > > > > > > > > > > > > Is much better. > > > > > > > > > > I'm not sure we should have CI-Test - as we might use this for > > > > something else > > > > > besides CI. > > > > > Region_of_Interest as Dan suggests sounds better IMHO. > > > > > > > > I don't care how this is to be called. > > > > However, I do not think that commit message is the place for > > > > instructing CI to do anything. > > > > Commit message stays for good, it should contain information that is > > > > required a year from now. > > > > It has nothing to do with tests and such. > > > > > > I agree with Alon here that the Ci informations don't belong in the > > > commit msg. > > > My opinion is that a testcase should know what it covers. This > > > information from the testcase can then be used by any party to determin > > > if the testcase should be run on a specific commit (which yields > > > informations about the changed paths, files, owner, author, etc ... > > > which might be valuable). > > > > i think you're missing the point here. > > can you explain how do you propose a test case will know "what it covers"? > > > > let's take an example: > > let's say a new commit comes from ovirt-engine: > > http://gerrit.ovirt.org/#/c/16668/ > > commit msg: "core: Use images instead of volumes at CDA message". > > > > now you have 1000 test cases (could be system or functional test). > > (let's assume that your infra can't support running 1000 tests per > > patch/commit). > > > > Some of these test suits checks network flow, some virt (migration/template > > for e.g), some host install, others storage flows and so on... ). > > you have one repo to clone (ovirt-engine, let's keep vdsm a side for a > > min), and to compile the project from for the tests. > > > > now given this scenario, please explain how will you know which test from > > the 1000 you have you'll run on it. > > do you believe that according to the author/path/filename you'll know if > > that patch involves storage or virt scenario? > > Hey Eyal, > > Yes - I would at least give it a try to decide automagically what tests > to run by looking at the change. > The main motivation for this is to not add another things which the > committer needs to take care of and IMO we humans tend to fail (at some > point) on those boring tasks like adding correct metadata (let it be a > typo or just not adding the correct testsuites/topis to be run). this process can be fully automatic via gerrit hooks & templates: typos or mistakes can be easily handles by gerrit hooks to help the committer fix the tags. as mentions previously, this logic can be done by the project maintainer and enforced by a template or hook. so for example - if someone writes a patch with patch header "webadmin:...." , then the tags he'll get to choose from are only relevant to ui/ux. so the only task a committer will have to do is to verify the default tags are relevant. i don't believe this is too much to ask for, considering the huge benefit that we'll get (stable code, less bugs, less ci breakage, mapping of specific code to relevant topic, statistics.. etc..) > But let's get back to your example. > Basically we can use the path and filename to determin what testsuite to > run. > Testsuites could be bound to paths and/or filenames and/or regexes being > matched against the full filename. > Another approach would be to use a java package dependency tree to > determine which classes are directly and indirectly affected by a > change. This information can then be used to also build a set of > testsuites to be run. For example: > World uses Ocean uses Wale uses Cell - if Wale changes, we'll surely > want to run the testsuites assigned to the classes higher up in the > dependency chain (World and Ocean). > > For the concrete example above: Maybe there is a spell checker testcase > which could be bound to the filename glob pattern *.properties. > > > i don't think there's an alternative to a metadata to assist mapping the > > patch to a relevant "topic" in the code. > > whether it exists as a git note or a label in the commit, that's another > > matter and probably less important. > > The idea is to use the path/filename and dependency tree information to > model these topics. Example: > WaterTestsuite(Topic): > regex_in_change: .*\.fish > glob_in_change: src/classes/ocean/*.java > path_in_change: src/classes/water.java > change_affects_depency_of: WaterClass I'm not familiar that much with the names of the classes and filenames, but it sounds to me like an error prone process and very complex to start going through all the classes and file names and mapping them to a certain project/component. sounds like we'll have to enforce a naming convention for every new file/path/class name that won't break that magic detection. sure there are exceptions that will work probably, like "anything under packaging/, should trigger the 'engine-setup' or 'engine-upgrade' tests, but imo, it is not so easy with other components. if something will help, it will be splitting up ovirt-engine into subject projects (different git) Eyal. > > But surely labels or meta-data in the commit msg are quicker to > implement. > > - fabian > > > eyal. > > > > > > > > - fabian > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > From gvallare at redhat.com Thu Jul 11 09:37:56 2013 From: gvallare at redhat.com (Giuseppe Vallarelli) Date: Thu, 11 Jul 2013 05:37:56 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <693107913.2226423.1373533051598.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <1373532084.2489.25.camel@fdeutsch-laptop.local> <693107913.2226423.1373533051598.JavaMail.root@redhat.com> Message-ID: <1030504058.3107920.1373535476636.JavaMail.root@redhat.com> ----- Original Message ----- | From: "Eyal Edri" | To: "Fabian Deutsch" | Cc: "engine-devel" , "infra" | Sent: Thursday, July 11, 2013 10:57:31 AM | Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits | | | | ----- Original Message ----- | > From: "Fabian Deutsch" | > To: "Eyal Edri" | > Cc: "Alon Bar-Lev" , "engine-devel" | > , "infra" | > Sent: Thursday, July 11, 2013 11:41:24 AM | > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine | > commits | > | > Am Mittwoch, den 10.07.2013, 15:27 -0400 schrieb Eyal Edri: | > > | > > ----- Original Message ----- | > > > From: "Fabian Deutsch" | > > > To: "Alon Bar-Lev" | > > > Cc: "engine-devel" , "infra" | > > > Sent: Tuesday, July 9, 2013 3:54:06 PM | > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for | > > > engine | > > > commits | > > > | > > > Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: | > > > > | > > > > | > > > > ----- Original Message ----- | > > > > > From: "Yair Zaslavsky" | > > > > > To: "Alon Bar-Lev" | > > > > > Cc: "Eyal Edri" , "engine-devel" | > > > > , "infra" | > > > > > Sent: Tuesday, July 9, 2013 3:42:24 PM | > > > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for | > > > > engine commits | > > > > > | > > > > > | > > > > > | > > > > > ----- Original Message ----- | > > > > > > From: "Alon Bar-Lev" | > > > > > > To: "Eyal Edri" | > > > > > > Cc: "engine-devel" , "infra" | > > > > | > > > > > > Sent: Tuesday, July 9, 2013 3:33:57 PM | > > > > > > Subject: Re: [Engine-devel] Proposal for new commit msg design | > > > > > > for | > > > > engine | > > > > > > commits | > > > > > > | > > > > > > | > > > > > > | > > > > > > ----- Original Message ----- | > > > > > > > From: "Eyal Edri" | > > > > > > > To: "engine-devel" | > > > > > > > Cc: "infra" | > > > > > > > Sent: Tuesday, July 9, 2013 12:38:51 PM | > > > > > > > Subject: Proposal for new commit msg design for engine commits | > > > > > > > | > > > > > > > Hi, | > > > > > > > | > > > > > > > You all probably know and familiar with 'ovirt-engine' git hook | > > > > for | > > > > > > > commit | > > > > > > > msg template [1]. | > > > > > > > this helps understand the general area of the patch in the | > > > > project but it | > > > > > > > lacks additional info that might | > > > > > > > be valuable for scaling automatic tests in Jenkins CI. | > > > > > > > | > > > > > > > Let me explain: | > > > > > > > | > > > > > > > Infra team is working hard on expanding oVirt CI infrastructure | > > > > and | > > > > > > > adding | > > > > > > > more tests in jenkins (per commit/patch). | > > > > > > > Adding important meta-data per patch can significatly improve | > > > > the ability | > > > > > > > to | > > > > > > > run specific tests for each patch/commit, | > > > > > > > and not waste valuable resources on Jenkins jobs that are not | > > > > relevant to | > > > > > > > the | > > > > > > > code in the patch. | > > > > > > > | > > > > > > > So the idea is to add/expand current metadata per patch, in the | > > > > form of: | > > > > > > > (either) | > > > > > > > 1. expanding current header template to include more data like | > > > > 'network' | > > > > > > > , | > > > > > > > 'setup', 'tools', 'virt' | > > > > > > | > > > > > > Please do not expand header, it is too short anyway. | > > > > > > | > > > > > > > 2. adding a new label with relevant tags for the patch, called | > > > > e.g | > > > > > > > 'METADATA: network, rest, virt' | > > > > > > | > > > > > > Having: | > > > > > > | > > > > > > CI-Tests: xxx | > > > > > > CI-Tests: yyy | > > > > > > CI-Tests: zzz | > > > > > > | > > > > > > Is much better. | > > > > > | > > > > > I'm not sure we should have CI-Test - as we might use this for | > > > > something else | > > > > > besides CI. | > > > > > Region_of_Interest as Dan suggests sounds better IMHO. | > > > > | > > > > I don't care how this is to be called. | > > > > However, I do not think that commit message is the place for | > > > > instructing CI to do anything. | > > > > Commit message stays for good, it should contain information that is | > > > > required a year from now. | > > > > It has nothing to do with tests and such. | > > > | > > > I agree with Alon here that the Ci informations don't belong in the | > > > commit msg. | > > > My opinion is that a testcase should know what it covers. This | > > > information from the testcase can then be used by any party to determin | > > > if the testcase should be run on a specific commit (which yields | > > > informations about the changed paths, files, owner, author, etc ... | > > > which might be valuable). | > > | > > i think you're missing the point here. | > > can you explain how do you propose a test case will know "what it | > > covers"? | > > | > > let's take an example: | > > let's say a new commit comes from ovirt-engine: | > > http://gerrit.ovirt.org/#/c/16668/ | > > commit msg: "core: Use images instead of volumes at CDA message". | > > | > > now you have 1000 test cases (could be system or functional test). | > > (let's assume that your infra can't support running 1000 tests per | > > patch/commit). | > > | > > Some of these test suits checks network flow, some virt | > > (migration/template | > > for e.g), some host install, others storage flows and so on... ). | > > you have one repo to clone (ovirt-engine, let's keep vdsm a side for a | > > min), and to compile the project from for the tests. | > > | > > now given this scenario, please explain how will you know which test from | > > the 1000 you have you'll run on it. | > > do you believe that according to the author/path/filename you'll know if | > > that patch involves storage or virt scenario? | > | > Hey Eyal, | > | > Yes - I would at least give it a try to decide automagically what tests | > to run by looking at the change. | > The main motivation for this is to not add another things which the | > committer needs to take care of and IMO we humans tend to fail (at some | > point) on those boring tasks like adding correct metadata (let it be a | > typo or just not adding the correct testsuites/topis to be run). | | this process can be fully automatic via gerrit hooks & templates: | | typos or mistakes can be easily handles by gerrit hooks to help the committer | fix the tags. | as mentions previously, this logic can be done by the project maintainer and | enforced by a template or hook. | | so for example - if someone writes a patch with patch header "webadmin:...." | , | then the tags he'll get to choose from are only relevant to ui/ux. | | so the only task a committer will have to do is to verify the default tags | are relevant. | | i don't believe this is too much to ask for, considering the huge benefit | that we'll get | (stable code, less bugs, less ci breakage, mapping of specific code to | relevant topic, statistics.. etc..) | | > But let's get back to your example. | > Basically we can use the path and filename to determin what testsuite to | > run. | > Testsuites could be bound to paths and/or filenames and/or regexes being | > matched against the full filename. | > Another approach would be to use a java package dependency tree to | > determine which classes are directly and indirectly affected by a | > change. This information can then be used to also build a set of | > testsuites to be run. For example: | > World uses Ocean uses Wale uses Cell - if Wale changes, we'll surely | > want to run the testsuites assigned to the classes higher up in the | > dependency chain (World and Ocean). | > | > For the concrete example above: Maybe there is a spell checker testcase | > which could be bound to the filename glob pattern *.properties. | > | > > i don't think there's an alternative to a metadata to assist mapping the | > > patch to a relevant "topic" in the code. | > > whether it exists as a git note or a label in the commit, that's another | > > matter and probably less important. | > | > The idea is to use the path/filename and dependency tree information to | > model these topics. Example: | > WaterTestsuite(Topic): | > regex_in_change: .*\.fish | > glob_in_change: src/classes/ocean/*.java | > path_in_change: src/classes/water.java | > change_affects_depency_of: WaterClass | | I'm not familiar that much with the names of the classes and filenames, but | it sounds to me like an error prone process | and very complex to start going through all the classes and file names and | mapping them to a certain project/component. | sounds like we'll have to enforce a naming convention for every new | file/path/class name that won't break that magic | detection. | | sure there are exceptions that will work probably, like "anything under | packaging/, should trigger the 'engine-setup' or 'engine-upgrade' tests, | but imo, it is not so easy with other components. | | if something will help, it will be splitting up ovirt-engine into subject | projects (different git) | | Eyal. I agree with Fabian that process of tagging commits can be error prone and should be automated. Perhaps you meant an high level of tags in this case appropriate tags and associated tests should be identified this change with time and it's not a fine grained approach. In order to detect dependencies that will help us understand which tests should be triggered we might use a DSM (http://en.wikipedia.org/wiki/Design_Structure_Matrix). SonarQube (http://www.sonarqube.org/) implements this metric and many others which might be helpful for us (http://docs.codehaus.org/display/SONAR/Cycles+-+Dependency+Structure+Matrix) I'm not aware if it provides an api that can be used. Hope this helps, Giuseppe | | > | > But surely labels or meta-data in the commit msg are quicker to | > implement. | > | > - fabian | > | > > eyal. | > > | > > > | > > > - fabian | > > > | > > > _______________________________________________ | > > > 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 rgolan at redhat.com Thu Jul 11 11:49:49 2013 From: rgolan at redhat.com (Roy Golan) Date: Thu, 11 Jul 2013 14:49:49 +0300 Subject: [Engine-devel] build a single maven project with make In-Reply-To: <51D412DE.8000406@redhat.com> References: <51D412DE.8000406@redhat.com> Message-ID: <51DE9BDD.6030900@redhat.com> On 07/03/2013 03:02 PM, Roy Golan wrote: > For those of us of dream of clean install a single project like maven > please note that > mvn has a flag which enables you to build a specific artifact even if > your not at that directory > > mvn -pl groupID:artifactId > > so say you modified a single class in vdsbroker do this: > > /make clean install-dev PREFIX=$HOME/ovirt-engine > DEV_EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:vdsbroker" > EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.core:vdsbroker"/ > > note: the usage of DEV_EXTRA_BUILD_FLAGS and EXTRA_BUILD_FLAGS is not > a mistake. the "clean" target uses EXTRA_BUILD_FLAGS - please review > http://gerrit.ovirt.org/16395 to rectify that. > now its working cleaner. a one liner to re-build the frontend and the server ear which its dependent on: / make clean install-dev PREFIX=$HOME/ovirt-engine EXTRA_BUILD_FLAGS="-pl org.ovirt.engine.ui:frontend-all -amd"/ > now make the ear: > > /make clean install-dev PREFIX=$HOME/ovirt-engine > DEV_EXTRA_BUILD_FLAGS="-pl org.ovirt.engine:engine-server-ear" > EXTRA_BUILD_FLAGS="-pl org.ovirt.engine:engine-server-ear"/ > > > now your updated artifact is in place. > > Thanks, > Roy > > > _______________________________________________ > 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 ecohen at redhat.com Thu Jul 11 14:46:33 2013 From: ecohen at redhat.com (Einav Cohen) Date: Thu, 11 Jul 2013 10:46:33 -0400 (EDT) Subject: [Engine-devel] Upgrading oVirt UI technology stack - patch is ready! In-Reply-To: <526288595.5644695.1372946839995.JavaMail.root@redhat.com> References: <526288595.5644695.1372946839995.JavaMail.root@redhat.com> Message-ID: <1735062604.3333173.1373553993922.JavaMail.root@redhat.com> Hi Everyone, Following the announcement below and the changes-overview session from a couple of days ago: The patch is now ready for review: http://gerrit.ovirt.org/#/c/16739/ The patch is quite huge and touches *a lot* of files, therefore it is expected to cause a bit of a rebase nightmare; so as I am sure that we all want to move to the new GWT-and-related dependencies, your prompt feedback (in an effort to merge the patch as soon as possible) will be highly-appreciated. TIA! ---- Regards, Einav ----- Original Message ----- > From: "Vojtech Szocs" > To: "engine-devel" > Cc: "Einav Cohen" , "Itamar Heim" > Sent: Thursday, July 4, 2013 10:07:19 AM > Subject: Upgrading oVirt UI technology stack > > Hello everyone, > > I wrote a wiki page to summarize our effort to upgrade existing UI technology > stack shared by oVirt web applications: > > http://www.ovirt.org/Features/GWT_Platform_Upgrade > > The wiki page divides GWT and GWTP changes into Essential and Non-essential. > All Essential changes will be part of the initial upgrade patch (currently > in progress), all Non-essential changes will be addressed later on, based on > their priority. > > There's still one open issue (Essential change) related to GWTP framework, > however we should come to a conclusion pretty soon. The corresponding > (Essential change) patch will follow shortly after that. > > Any feedback is greatly appreciated, let me know what you think. > > Regards, > Vojtech > From kmayilsa at redhat.com Fri Jul 12 11:37:25 2013 From: kmayilsa at redhat.com (Kanagaraj) Date: Fri, 12 Jul 2013 17:07:25 +0530 Subject: [Engine-devel] Add Host(Bootstrap) fails with tar:timestamp in future error Message-ID: <51DFEA75.7050508@redhat.com> Hi All, I am facing the following issue when adding a f18 node to 3.3-master engine(nightly). I have an engine with proper time set, but my f18 node has an old time(01-01-2013) set. Then i tried adding the node to engine, but it failed with following error in the engine.log. But no error is seen in host-deploy log file. 2013-07-11 12:31:28,193 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event ID: -1, Message: Installing Host server1. Stage: Pre-termination. 2013-07-11 12:31:28,229 INFO [org.ovirt.engine.core.bll.InstallerMessages] (VdsDeploy) Installation 10.70.43.127: Retrieving installation logs to: '/var/log/ovirt-engine/host-deploy/ovirt-20130711123128-10.70.43.127-62f72352.log' 2013-07-11 12:31:28,237 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event ID: -1, Message: Installing Host server1. Retrieving installation logs to: '/var/log/ovirt-engine/host-deploy/ovirt-20130711123128-10.70.43.127-62f72352.log'. 2013-07-11 12:31:28,553 INFO [org.ovirt.engine.core.bll.InstallerMessages] (VdsDeploy) Installation 10.70.43.127: Stage: Termination 2013-07-11 12:31:28,562 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event ID: -1, Message: Installing Host server1. Stage: Termination. 2013-07-11 12:31:28,634 ERROR [org.ovirt.engine.core.utils.ssh.SSHDialog] (pool-6-thread-42) SSH stderr during command root at 10.70.43.127:'umask 0077; MYTMP="$(mktemp -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && mkdir "${MYTMP}" && tar -C "${MYTMP}" -x && "${MYTMP}"/setup DIALOG/dialect=str:machine DIALOG/customization=bool:True': stderr: tar: ./otopi: time stamp 2013-07-04 14:21:43 is 15945691.410852852 s in the future tar: ./ovirt-host-deploy: time stamp 2013-07-10 04:55:38 is 16430126.410376831 s in the future tar: ./pythonlib/otopi/miniyum.pyc: time stamp 2013-07-04 14:21:45 is 15945693.410119301 s in the future tar: ./pythonlib/otopi/__main__.pyc: time stamp 2013-07-04 14:21:45 is 15945693.410010001 s in the future tar: ./pythonlib/otopi/dialog.pyo: time stamp 2013-07-04 14:21:45 is 15945693.409909584 s in the future tar: ./pythonlib/otopi/packager.pyc: time stamp 2013-07-04 14:21:45 is 15945693.409809844 s in the future tar: ./pythonlib/otopi/packager.py: time stamp 2013-07-04 14:21:44 is 15945692.409518324 s in the future tar: ./pythonlib/otopi/common.pyo: time stamp 2013-07-04 14:21:45 is 15945693.40935584 s in the future tar: ./pythonlib/otopi/transaction.pyc: time stamp 2013-07-04 14:21:45 is 15945693.409253666 s in the future tar: ./pythonlib/otopi/miniyum.pyo: time stamp 2013-07-04 14:21:45 is 15945693.409127283 s in the future tar: ./pythonlib/otopi/plugin.py: time stamp 2013-07-04 14:21:44 is 15945692.409022969 s in the future 2013-07-11 12:31:28,641 ERROR [org.ovirt.engine.core.utils.ssh.SSHDialog] (pool-6-thread-42) SSH error running command root at 10.70.43.127:'umask 0077; MYTMP="$(mktemp -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && mkdir "${MYTMP}" && tar -C "${MYTMP}" -x && "${MYTMP}"/setup DIALOG/dialect=str:machine DIALOG/customization=bool:True': java.io.IOException: Error messages during execution at org.ovirt.engine.core.utils.ssh.SSHDialog.executeCommand(SSHDialog.java:318) [utils.jar:] After the failure, i tried doing a re-install, that went through fine without any issue and the host came up after the installation. Looks like the first time bootstrapping reset the time. Also i can see the node's time is changed to current time. Thanks, Kanagaraj From kmayilsa at redhat.com Fri Jul 12 11:40:39 2013 From: kmayilsa at redhat.com (Kanagaraj) Date: Fri, 12 Jul 2013 17:10:39 +0530 Subject: [Engine-devel] Add Host(Bootstrap) fails with tar:timestamp in future error In-Reply-To: <51DFEA75.7050508@redhat.com> References: <51DFEA75.7050508@redhat.com> Message-ID: <51DFEB37.6080309@redhat.com> On 07/12/2013 05:07 PM, Kanagaraj wrote: > Hi All, > > I am facing the following issue when adding a f18 node to 3.3-master > engine(nightly). > Also the node have recent vdsm built from master branch. Can someone please help in this regard? > I have an engine with proper time set, but my f18 node has an old > time(01-01-2013) set. Then i tried adding the node to engine, but it > failed with following error in the engine.log. But no error is seen in > host-deploy log file. > > 2013-07-11 12:31:28,193 INFO > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event > ID: -1, Message: Installing Host server1. Stage: Pre-termination. > 2013-07-11 12:31:28,229 INFO > [org.ovirt.engine.core.bll.InstallerMessages] (VdsDeploy) Installation > 10.70.43.127: Retrieving installation logs to: > '/var/log/ovirt-engine/host-deploy/ovirt-20130711123128-10.70.43.127-62f72352.log' > 2013-07-11 12:31:28,237 INFO > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event > ID: -1, Message: Installing Host server1. Retrieving installation logs > to: > '/var/log/ovirt-engine/host-deploy/ovirt-20130711123128-10.70.43.127-62f72352.log'. > 2013-07-11 12:31:28,553 INFO > [org.ovirt.engine.core.bll.InstallerMessages] (VdsDeploy) Installation > 10.70.43.127: Stage: Termination > 2013-07-11 12:31:28,562 INFO > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event > ID: -1, Message: Installing Host server1. Stage: Termination. > 2013-07-11 12:31:28,634 ERROR > [org.ovirt.engine.core.utils.ssh.SSHDialog] (pool-6-thread-42) SSH > stderr during command root at 10.70.43.127:'umask 0077; MYTMP="$(mktemp > -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null > 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && > mkdir "${MYTMP}" && tar -C "${MYTMP}" -x && "${MYTMP}"/setup > DIALOG/dialect=str:machine DIALOG/customization=bool:True': stderr: > tar: ./otopi: time stamp 2013-07-04 14:21:43 is 15945691.410852852 s > in the future > tar: ./ovirt-host-deploy: time stamp 2013-07-10 04:55:38 is > 16430126.410376831 s in the future > tar: ./pythonlib/otopi/miniyum.pyc: time stamp 2013-07-04 14:21:45 is > 15945693.410119301 s in the future > tar: ./pythonlib/otopi/__main__.pyc: time stamp 2013-07-04 14:21:45 is > 15945693.410010001 s in the future > tar: ./pythonlib/otopi/dialog.pyo: time stamp 2013-07-04 14:21:45 is > 15945693.409909584 s in the future > tar: ./pythonlib/otopi/packager.pyc: time stamp 2013-07-04 14:21:45 is > 15945693.409809844 s in the future > tar: ./pythonlib/otopi/packager.py: time stamp 2013-07-04 14:21:44 is > 15945692.409518324 s in the future > tar: ./pythonlib/otopi/common.pyo: time stamp 2013-07-04 14:21:45 is > 15945693.40935584 s in the future > tar: ./pythonlib/otopi/transaction.pyc: time stamp 2013-07-04 14:21:45 > is 15945693.409253666 s in the future > tar: ./pythonlib/otopi/miniyum.pyo: time stamp 2013-07-04 14:21:45 is > 15945693.409127283 s in the future > tar: ./pythonlib/otopi/plugin.py: time stamp 2013-07-04 14:21:44 is > 15945692.409022969 s in the future > > 2013-07-11 12:31:28,641 ERROR > [org.ovirt.engine.core.utils.ssh.SSHDialog] (pool-6-thread-42) SSH > error running command root at 10.70.43.127:'umask 0077; MYTMP="$(mktemp > -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null > 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && > mkdir "${MYTMP}" && tar -C "${MYTMP}" -x && "${MYTMP}"/setup > DIALOG/dialect=str:machine DIALOG/customization=bool:True': > java.io.IOException: Error messages during execution > at > org.ovirt.engine.core.utils.ssh.SSHDialog.executeCommand(SSHDialog.java:318) > [utils.jar:] > > > After the failure, i tried doing a re-install, that went through fine > without any issue and the host came up after the installation. Looks > like the first time bootstrapping reset the time. > Also i can see the node's time is changed to current time. > > Thanks, > Kanagaraj > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From alonbl at redhat.com Fri Jul 12 11:42:30 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Fri, 12 Jul 2013 07:42:30 -0400 (EDT) Subject: [Engine-devel] Add Host(Bootstrap) fails with tar:timestamp in future error In-Reply-To: <51DFEA75.7050508@redhat.com> References: <51DFEA75.7050508@redhat.com> Message-ID: <2030805583.1696611.1373629350944.JavaMail.root@redhat.com> the errors from the tar produce this. after 1st bootstrap the clock is sync, so the next one is ok. the following[1] fixes that. [1] http://gerrit.ovirt.org/#/c/16640/ ----- Original Message ----- > From: "Kanagaraj" > To: "engine-devel" > Sent: Friday, July 12, 2013 2:37:25 PM > Subject: [Engine-devel] Add Host(Bootstrap) fails with tar:timestamp in future error > > Hi All, > > I am facing the following issue when adding a f18 node to 3.3-master > engine(nightly). > > I have an engine with proper time set, but my f18 node has an old > time(01-01-2013) set. Then i tried adding the node to engine, but it > failed with following error in the engine.log. But no error is seen in > host-deploy log file. > > 2013-07-11 12:31:28,193 INFO > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event ID: > -1, Message: Installing Host server1. Stage: Pre-termination. > 2013-07-11 12:31:28,229 INFO > [org.ovirt.engine.core.bll.InstallerMessages] (VdsDeploy) Installation > 10.70.43.127: Retrieving installation logs to: > '/var/log/ovirt-engine/host-deploy/ovirt-20130711123128-10.70.43.127-62f72352.log' > 2013-07-11 12:31:28,237 INFO > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event ID: > -1, Message: Installing Host server1. Retrieving installation logs to: > '/var/log/ovirt-engine/host-deploy/ovirt-20130711123128-10.70.43.127-62f72352.log'. > 2013-07-11 12:31:28,553 INFO > [org.ovirt.engine.core.bll.InstallerMessages] (VdsDeploy) Installation > 10.70.43.127: Stage: Termination > 2013-07-11 12:31:28,562 INFO > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event ID: > -1, Message: Installing Host server1. Stage: Termination. > 2013-07-11 12:31:28,634 ERROR > [org.ovirt.engine.core.utils.ssh.SSHDialog] (pool-6-thread-42) SSH > stderr during command root at 10.70.43.127:'umask 0077; MYTMP="$(mktemp -t > ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; > rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && mkdir > "${MYTMP}" && tar -C "${MYTMP}" -x && "${MYTMP}"/setup > DIALOG/dialect=str:machine DIALOG/customization=bool:True': stderr: tar: > ./otopi: time stamp 2013-07-04 14:21:43 is 15945691.410852852 s in the > future > tar: ./ovirt-host-deploy: time stamp 2013-07-10 04:55:38 is > 16430126.410376831 s in the future > tar: ./pythonlib/otopi/miniyum.pyc: time stamp 2013-07-04 14:21:45 is > 15945693.410119301 s in the future > tar: ./pythonlib/otopi/__main__.pyc: time stamp 2013-07-04 14:21:45 is > 15945693.410010001 s in the future > tar: ./pythonlib/otopi/dialog.pyo: time stamp 2013-07-04 14:21:45 is > 15945693.409909584 s in the future > tar: ./pythonlib/otopi/packager.pyc: time stamp 2013-07-04 14:21:45 is > 15945693.409809844 s in the future > tar: ./pythonlib/otopi/packager.py: time stamp 2013-07-04 14:21:44 is > 15945692.409518324 s in the future > tar: ./pythonlib/otopi/common.pyo: time stamp 2013-07-04 14:21:45 is > 15945693.40935584 s in the future > tar: ./pythonlib/otopi/transaction.pyc: time stamp 2013-07-04 14:21:45 > is 15945693.409253666 s in the future > tar: ./pythonlib/otopi/miniyum.pyo: time stamp 2013-07-04 14:21:45 is > 15945693.409127283 s in the future > tar: ./pythonlib/otopi/plugin.py: time stamp 2013-07-04 14:21:44 is > 15945692.409022969 s in the future > > 2013-07-11 12:31:28,641 ERROR > [org.ovirt.engine.core.utils.ssh.SSHDialog] (pool-6-thread-42) SSH error > running command root at 10.70.43.127:'umask 0077; MYTMP="$(mktemp -t > ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; > rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && mkdir > "${MYTMP}" && tar -C "${MYTMP}" -x && "${MYTMP}"/setup > DIALOG/dialect=str:machine DIALOG/customization=bool:True': > java.io.IOException: Error messages during execution > at > org.ovirt.engine.core.utils.ssh.SSHDialog.executeCommand(SSHDialog.java:318) > [utils.jar:] > > > After the failure, i tried doing a re-install, that went through fine > without any issue and the host came up after the installation. Looks > like the first time bootstrapping reset the time. > Also i can see the node's time is changed to current time. > > Thanks, > Kanagaraj > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From kmayilsa at redhat.com Fri Jul 12 12:08:07 2013 From: kmayilsa at redhat.com (Kanagaraj) Date: Fri, 12 Jul 2013 17:38:07 +0530 Subject: [Engine-devel] Add Host(Bootstrap) fails with tar:timestamp in future error In-Reply-To: <2030805583.1696611.1373629350944.JavaMail.root@redhat.com> References: <51DFEA75.7050508@redhat.com> <2030805583.1696611.1373629350944.JavaMail.root@redhat.com> Message-ID: <51DFF1A7.7020808@redhat.com> Thanks Alon, it fixes the issue. On 07/12/2013 05:12 PM, Alon Bar-Lev wrote: > the errors from the tar produce this. > after 1st bootstrap the clock is sync, so the next one is ok. > the following[1] fixes that. > > [1] http://gerrit.ovirt.org/#/c/16640/ > > ----- Original Message ----- >> From: "Kanagaraj" >> To: "engine-devel" >> Sent: Friday, July 12, 2013 2:37:25 PM >> Subject: [Engine-devel] Add Host(Bootstrap) fails with tar:timestamp in future error >> >> Hi All, >> >> I am facing the following issue when adding a f18 node to 3.3-master >> engine(nightly). >> >> I have an engine with proper time set, but my f18 node has an old >> time(01-01-2013) set. Then i tried adding the node to engine, but it >> failed with following error in the engine.log. But no error is seen in >> host-deploy log file. >> >> 2013-07-11 12:31:28,193 INFO >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] >> (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event ID: >> -1, Message: Installing Host server1. Stage: Pre-termination. >> 2013-07-11 12:31:28,229 INFO >> [org.ovirt.engine.core.bll.InstallerMessages] (VdsDeploy) Installation >> 10.70.43.127: Retrieving installation logs to: >> '/var/log/ovirt-engine/host-deploy/ovirt-20130711123128-10.70.43.127-62f72352.log' >> 2013-07-11 12:31:28,237 INFO >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] >> (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event ID: >> -1, Message: Installing Host server1. Retrieving installation logs to: >> '/var/log/ovirt-engine/host-deploy/ovirt-20130711123128-10.70.43.127-62f72352.log'. >> 2013-07-11 12:31:28,553 INFO >> [org.ovirt.engine.core.bll.InstallerMessages] (VdsDeploy) Installation >> 10.70.43.127: Stage: Termination >> 2013-07-11 12:31:28,562 INFO >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] >> (VdsDeploy) Correlation ID: 62f72352, Call Stack: null, Custom Event ID: >> -1, Message: Installing Host server1. Stage: Termination. >> 2013-07-11 12:31:28,634 ERROR >> [org.ovirt.engine.core.utils.ssh.SSHDialog] (pool-6-thread-42) SSH >> stderr during command root at 10.70.43.127:'umask 0077; MYTMP="$(mktemp -t >> ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; >> rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && mkdir >> "${MYTMP}" && tar -C "${MYTMP}" -x && "${MYTMP}"/setup >> DIALOG/dialect=str:machine DIALOG/customization=bool:True': stderr: tar: >> ./otopi: time stamp 2013-07-04 14:21:43 is 15945691.410852852 s in the >> future >> tar: ./ovirt-host-deploy: time stamp 2013-07-10 04:55:38 is >> 16430126.410376831 s in the future >> tar: ./pythonlib/otopi/miniyum.pyc: time stamp 2013-07-04 14:21:45 is >> 15945693.410119301 s in the future >> tar: ./pythonlib/otopi/__main__.pyc: time stamp 2013-07-04 14:21:45 is >> 15945693.410010001 s in the future >> tar: ./pythonlib/otopi/dialog.pyo: time stamp 2013-07-04 14:21:45 is >> 15945693.409909584 s in the future >> tar: ./pythonlib/otopi/packager.pyc: time stamp 2013-07-04 14:21:45 is >> 15945693.409809844 s in the future >> tar: ./pythonlib/otopi/packager.py: time stamp 2013-07-04 14:21:44 is >> 15945692.409518324 s in the future >> tar: ./pythonlib/otopi/common.pyo: time stamp 2013-07-04 14:21:45 is >> 15945693.40935584 s in the future >> tar: ./pythonlib/otopi/transaction.pyc: time stamp 2013-07-04 14:21:45 >> is 15945693.409253666 s in the future >> tar: ./pythonlib/otopi/miniyum.pyo: time stamp 2013-07-04 14:21:45 is >> 15945693.409127283 s in the future >> tar: ./pythonlib/otopi/plugin.py: time stamp 2013-07-04 14:21:44 is >> 15945692.409022969 s in the future >> >> 2013-07-11 12:31:28,641 ERROR >> [org.ovirt.engine.core.utils.ssh.SSHDialog] (pool-6-thread-42) SSH error >> running command root at 10.70.43.127:'umask 0077; MYTMP="$(mktemp -t >> ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; >> rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && mkdir >> "${MYTMP}" && tar -C "${MYTMP}" -x && "${MYTMP}"/setup >> DIALOG/dialect=str:machine DIALOG/customization=bool:True': >> java.io.IOException: Error messages during execution >> at >> org.ovirt.engine.core.utils.ssh.SSHDialog.executeCommand(SSHDialog.java:318) >> [utils.jar:] >> >> >> After the failure, i tried doing a re-install, that went through fine >> without any issue and the host came up after the installation. Looks >> like the first time bootstrapping reset the time. >> Also i can see the node's time is changed to current time. >> >> Thanks, >> Kanagaraj >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> From dneary at redhat.com Fri Jul 12 12:42:42 2013 From: dneary at redhat.com (Dave Neary) Date: Fri, 12 Jul 2013 14:42:42 +0200 Subject: [Engine-devel] [Users] Linkedin oVirt company profile In-Reply-To: <492176035.180098.1373205743663.JavaMail.root@redhat.com> References: <506443926.142229.1373194923007.JavaMail.root@redhat.com> <492176035.180098.1373205743663.JavaMail.root@redhat.com> Message-ID: <51DFF9C2.2070006@redhat.com> Hi, Kiril to begin with - I would be happy to be added as a co-maintainer. I see that Ohad is also maintaining (is that right? It's hard to tell with LinkedIn). I'm interested to see that it's a company, rather than a "Group" which I think might have been better suited - Kiril, that's what I thought you were going to create. The problem with companies is that only people with email addresses matching ovirt.org can be maintainers. Cheers, Dave. On 07/07/2013 04:02 PM, Eyal Edri wrote: > +1.. > > great, i'm following it. > who's maintaining it now? (i.e adding news/events on future workshops and such) > > ----- Original Message ----- >> From: "Kiril Nesenko" >> To: "infra" , engine-devel at ovirt.org, users at ovirt.org >> Sent: Sunday, July 7, 2013 2:02:03 PM >> Subject: [Users] Linkedin oVirt company profile >> >> Hello, >> >> I would like to introduce the new company profile[1] for oVirt project. >> You are more than welcome to join and follow the company profile. >> >> [1] http://www.linkedin.com/company/ovirt?trk=top_nav_home >> >> - Kiril >> _______________________________________________ >> Users mailing list >> Users at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> > _______________________________________________ > Infra mailing list > Infra at ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > -- 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 dneary at redhat.com Fri Jul 12 12:48:00 2013 From: dneary at redhat.com (Dave Neary) Date: Fri, 12 Jul 2013 14:48:00 +0200 Subject: [Engine-devel] [Users] Linkedin oVirt company profile In-Reply-To: <51DFF9C2.2070006@redhat.com> References: <506443926.142229.1373194923007.JavaMail.root@redhat.com> <492176035.180098.1373205743663.JavaMail.root@redhat.com> <51DFF9C2.2070006@redhat.com> Message-ID: <51DFFB00.1030900@redhat.com> Actually, I just found the oVirt group: http://www.linkedin.com/groups?gid=4707460&trk=vsrp_groups_res_name&trkInfo=VSRPsearchId%3A28732331373633156117%2CVSRPtargetId%3A4707460%2CVSRPcmpt%3Aprimary It looks like Peter Styk created the group. Perhaps we should merge while the oVirt company is still young? Cheers, Dave. On 07/12/2013 02:42 PM, Dave Neary wrote: > Hi, > > Kiril to begin with - I would be happy to be added as a co-maintainer. I > see that Ohad is also maintaining (is that right? It's hard to tell with > LinkedIn). > > I'm interested to see that it's a company, rather than a "Group" which I > think might have been better suited - Kiril, that's what I thought you > were going to create. The problem with companies is that only people > with email addresses matching ovirt.org can be maintainers. > > Cheers, > Dave. > > On 07/07/2013 04:02 PM, Eyal Edri wrote: >> +1.. >> >> great, i'm following it. >> who's maintaining it now? (i.e adding news/events on future workshops and such) >> >> ----- Original Message ----- >>> From: "Kiril Nesenko" >>> To: "infra" , engine-devel at ovirt.org, users at ovirt.org >>> Sent: Sunday, July 7, 2013 2:02:03 PM >>> Subject: [Users] Linkedin oVirt company profile >>> >>> Hello, >>> >>> I would like to introduce the new company profile[1] for oVirt project. >>> You are more than welcome to join and follow the company profile. >>> >>> [1] http://www.linkedin.com/company/ovirt?trk=top_nav_home >>> >>> - Kiril >>> _______________________________________________ >>> Users mailing list >>> Users at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> _______________________________________________ >> Infra mailing list >> Infra at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/infra >> > -- 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 iheim at redhat.com Sat Jul 13 10:17:12 2013 From: iheim at redhat.com (Itamar Heim) Date: Sat, 13 Jul 2013 13:17:12 +0300 Subject: [Engine-devel] VNIC profiles In-Reply-To: <321253300.385386.1373271681521.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> <321253300.385386.1373271681521.JavaMail.root@redhat.com> Message-ID: <51E12928.6090408@redhat.com> On 07/08/2013 11:21 AM, Moti Asayag wrote: > > ... > > The wiki was updated with the VM/Template import logic: > > http://www.ovirt.org/Features/Vnic_Profiles#VM_snapshot.2Fimport.2Fexport 1. you are updating the OVF - have you found a matching field in the OVF spec[1] for vnic profiles? 2. import/export - please note exporting is backward compatible based on DC level (iirc - omer should remember better), i.e., if the DC is 3.2, the export should ignore vnic profiles, etc. 3. while at it - just to make sure before i add more comments- are the screenshots in the wiki up to date? Thanks, Itamar [1] http://dmtf.org/standards/ovf From iheim at redhat.com Sun Jul 14 09:58:39 2013 From: iheim at redhat.com (Itamar Heim) Date: Sun, 14 Jul 2013 12:58:39 +0300 Subject: [Engine-devel] VNIC profiles In-Reply-To: <51E26085.7070500@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> <321253300.385386.1373271681521.JavaMail.root@redhat.com> <51E12928.6090408@redhat.com> <51E26085.7070500@redhat.com> Message-ID: <51E2764F.7090405@redhat.com> On 07/14/2013 11:25 AM, Moti Asayag wrote: >> 2. import/export - please note exporting is backward compatible based on >> >DC level (iirc - omer should remember better), i.e., if the DC is 3.2, >> >the export should ignore vnic profiles, etc. >> > >> >3. while at it - just to make sure before i add more comments- are the >> >screenshots in the wiki up to date? > The images should be updated since the vnic profiles will be a main-tab, > appears only when a network is selected, instead of a sub-tab of the > networks. > that sounds a bit arduous (a main tab appearing only when standing on a specific entity)? From masayag at redhat.com Sun Jul 14 08:25:41 2013 From: masayag at redhat.com (Moti Asayag) Date: Sun, 14 Jul 2013 11:25:41 +0300 Subject: [Engine-devel] VNIC profiles In-Reply-To: <51E12928.6090408@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> <321253300.385386.1373271681521.JavaMail.root@redhat.com> <51E12928.6090408@redhat.com> Message-ID: <51E26085.7070500@redhat.com> On 07/13/2013 01:17 PM, Itamar Heim wrote: > On 07/08/2013 11:21 AM, Moti Asayag wrote: >> >> > ... >> >> The wiki was updated with the VM/Template import logic: >> >> http://www.ovirt.org/Features/Vnic_Profiles#VM_snapshot.2Fimport.2Fexport > > 1. you are updating the OVF - have you found a matching field in the OVF > spec[1] for vnic profiles? > Currently the only field used to specify the network is "Connection". There is no specific field for specifying a vnic profile. We can make a use of the 'OtherResourceType' which isn't in use by the engine for storing the vnic profile name. An alternative would be using the Connection field to store both Network:Profile, and parsing it when a vm or template are being imported. I'm in favour of the first option for simplicity and in order not to modify the Connection field as is being used today. > 2. import/export - please note exporting is backward compatible based on > DC level (iirc - omer should remember better), i.e., if the DC is 3.2, > the export should ignore vnic profiles, etc. > > 3. while at it - just to make sure before i add more comments- are the > screenshots in the wiki up to date? The images should be updated since the vnic profiles will be a main-tab, appears only when a network is selected, instead of a sub-tab of the networks. > > Thanks, > Itamar > > [1] http://dmtf.org/standards/ovf From mgoldboi at redhat.com Sun Jul 14 15:07:05 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Sun, 14 Jul 2013 18:07:05 +0300 Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <693107913.2226423.1373533051598.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <541281197.610361.1373373237759.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <1373532084.2489.25.camel@fdeutsch-laptop.local> <693107913.2226423.1373533051598.JavaMail.root@redhat.com> Message-ID: <51E2BE99.2000409@redhat.com> On 07/11/2013 11:57 AM, Eyal Edri wrote: > > ----- Original Message ----- >> From: "Fabian Deutsch" >> To: "Eyal Edri" >> Cc: "Alon Bar-Lev" , "engine-devel" , "infra" >> Sent: Thursday, July 11, 2013 11:41:24 AM >> Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits >> >> Am Mittwoch, den 10.07.2013, 15:27 -0400 schrieb Eyal Edri: >>> ----- Original Message ----- >>>> From: "Fabian Deutsch" >>>> To: "Alon Bar-Lev" >>>> Cc: "engine-devel" , "infra" >>>> Sent: Tuesday, July 9, 2013 3:54:06 PM >>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for engine >>>> commits >>>> >>>> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Yair Zaslavsky" >>>>>> To: "Alon Bar-Lev" >>>>>> Cc: "Eyal Edri" , "engine-devel" >>>>> , "infra" >>>>>> Sent: Tuesday, July 9, 2013 3:42:24 PM >>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for >>>>> engine commits >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Alon Bar-Lev" >>>>>>> To: "Eyal Edri" >>>>>>> Cc: "engine-devel" , "infra" >>>>> >>>>>>> Sent: Tuesday, July 9, 2013 3:33:57 PM >>>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for >>>>> engine >>>>>>> commits >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Eyal Edri" >>>>>>>> To: "engine-devel" >>>>>>>> Cc: "infra" >>>>>>>> Sent: Tuesday, July 9, 2013 12:38:51 PM >>>>>>>> Subject: Proposal for new commit msg design for engine commits >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> You all probably know and familiar with 'ovirt-engine' git hook >>>>> for >>>>>>>> commit >>>>>>>> msg template [1]. >>>>>>>> this helps understand the general area of the patch in the >>>>> project but it >>>>>>>> lacks additional info that might >>>>>>>> be valuable for scaling automatic tests in Jenkins CI. >>>>>>>> >>>>>>>> Let me explain: >>>>>>>> >>>>>>>> Infra team is working hard on expanding oVirt CI infrastructure >>>>> and >>>>>>>> adding >>>>>>>> more tests in jenkins (per commit/patch). >>>>>>>> Adding important meta-data per patch can significatly improve >>>>> the ability >>>>>>>> to >>>>>>>> run specific tests for each patch/commit, >>>>>>>> and not waste valuable resources on Jenkins jobs that are not >>>>> relevant to >>>>>>>> the >>>>>>>> code in the patch. >>>>>>>> >>>>>>>> So the idea is to add/expand current metadata per patch, in the >>>>> form of: >>>>>>>> (either) >>>>>>>> 1. expanding current header template to include more data like >>>>> 'network' >>>>>>>> , >>>>>>>> 'setup', 'tools', 'virt' >>>>>>> Please do not expand header, it is too short anyway. >>>>>>> >>>>>>>> 2. adding a new label with relevant tags for the patch, called >>>>> e.g >>>>>>>> 'METADATA: network, rest, virt' >>>>>>> Having: >>>>>>> >>>>>>> CI-Tests: xxx >>>>>>> CI-Tests: yyy >>>>>>> CI-Tests: zzz >>>>>>> >>>>>>> Is much better. >>>>>> I'm not sure we should have CI-Test - as we might use this for >>>>> something else >>>>>> besides CI. >>>>>> Region_of_Interest as Dan suggests sounds better IMHO. >>>>> I don't care how this is to be called. >>>>> However, I do not think that commit message is the place for >>>>> instructing CI to do anything. >>>>> Commit message stays for good, it should contain information that is >>>>> required a year from now. >>>>> It has nothing to do with tests and such. >>>> I agree with Alon here that the Ci informations don't belong in the >>>> commit msg. >>>> My opinion is that a testcase should know what it covers. This >>>> information from the testcase can then be used by any party to determin >>>> if the testcase should be run on a specific commit (which yields >>>> informations about the changed paths, files, owner, author, etc ... >>>> which might be valuable). >>> i think you're missing the point here. >>> can you explain how do you propose a test case will know "what it covers"? >>> >>> let's take an example: >>> let's say a new commit comes from ovirt-engine: >>> http://gerrit.ovirt.org/#/c/16668/ >>> commit msg: "core: Use images instead of volumes at CDA message". >>> >>> now you have 1000 test cases (could be system or functional test). >>> (let's assume that your infra can't support running 1000 tests per >>> patch/commit). >>> >>> Some of these test suits checks network flow, some virt (migration/template >>> for e.g), some host install, others storage flows and so on... ). >>> you have one repo to clone (ovirt-engine, let's keep vdsm a side for a >>> min), and to compile the project from for the tests. >>> >>> now given this scenario, please explain how will you know which test from >>> the 1000 you have you'll run on it. >>> do you believe that according to the author/path/filename you'll know if >>> that patch involves storage or virt scenario? >> Hey Eyal, >> >> Yes - I would at least give it a try to decide automagically what tests >> to run by looking at the change. >> The main motivation for this is to not add another things which the >> committer needs to take care of and IMO we humans tend to fail (at some >> point) on those boring tasks like adding correct metadata (let it be a >> typo or just not adding the correct testsuites/topis to be run). > this process can be fully automatic via gerrit hooks & templates: > > typos or mistakes can be easily handles by gerrit hooks to help the committer fix the tags. > as mentions previously, this logic can be done by the project maintainer and enforced by a template or hook. > > so for example - if someone writes a patch with patch header "webadmin:...." , > then the tags he'll get to choose from are only relevant to ui/ux. > > so the only task a committer will have to do is to verify the default tags are relevant. > > i don't believe this is too much to ask for, considering the huge benefit that we'll get > (stable code, less bugs, less ci breakage, mapping of specific code to relevant topic, statistics.. etc..) > >> But let's get back to your example. >> Basically we can use the path and filename to determin what testsuite to >> run. >> Testsuites could be bound to paths and/or filenames and/or regexes being >> matched against the full filename. >> Another approach would be to use a java package dependency tree to >> determine which classes are directly and indirectly affected by a >> change. This information can then be used to also build a set of >> testsuites to be run. For example: >> World uses Ocean uses Wale uses Cell - if Wale changes, we'll surely >> want to run the testsuites assigned to the classes higher up in the >> dependency chain (World and Ocean). >> >> For the concrete example above: Maybe there is a spell checker testcase >> which could be bound to the filename glob pattern *.properties. >> >>> i don't think there's an alternative to a metadata to assist mapping the >>> patch to a relevant "topic" in the code. >>> whether it exists as a git note or a label in the commit, that's another >>> matter and probably less important. >> The idea is to use the path/filename and dependency tree information to >> model these topics. Example: >> WaterTestsuite(Topic): >> regex_in_change: .*\.fish >> glob_in_change: src/classes/ocean/*.java >> path_in_change: src/classes/water.java >> change_affects_depency_of: WaterClass > I'm not familiar that much with the names of the classes and filenames, but it sounds to me like an error prone process > and very complex to start going through all the classes and file names and mapping them to a certain project/component. > sounds like we'll have to enforce a naming convention for every new file/path/class name that won't break that magic > detection. > > sure there are exceptions that will work probably, like "anything under packaging/, should trigger the 'engine-setup' or 'engine-upgrade' tests, > but imo, it is not so easy with other components. > > if something will help, it will be splitting up ovirt-engine into subject projects (different git) > > Eyal. I think some valid points were raised in this thread, and I feel we all agree regarding the need for such a mechanism. regarding mapping of different areas in the code using metadata, i think this approach worth trying, it'll increase ownership and area of responsibility within our code and hopefully provide us the functionality we are looking for. we can start doing the obvious mapping, after-which the responsibility of each team/maintainer to assign a file to a person and define the specific functional areas in it. Moran. > >> But surely labels or meta-data in the commit msg are quicker to >> implement. >> >> - fabian >> >>> eyal. >>> >>>> - fabian >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> >> > _______________________________________________ > Infra mailing list > Infra at ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra From wlbleaboy at 126.com Mon Jul 15 05:17:32 2013 From: wlbleaboy at 126.com (wlbleaboy@126) Date: Mon, 15 Jul 2013 13:17:32 +0800 Subject: [Engine-devel] about vm in vmpool In-Reply-To: <51DA938C.7020604@redhat.com> References: <004c01ce7ba1$15468fa0$3fd3aee0$@com> <51DA938C.7020604@redhat.com> Message-ID: <003c01ce811a$9d1efe70$d75cfb50$@com> Hi, How can I 'mocking' the appearance of ovirt-engine-sdk, or, could you show me how user portal 'mocking' the appearance. I'm not familiar with java, so It's hardly for me to read user portal's java code. -----Original Message----- From: Itamar Heim [mailto:iheim at redhat.com] Sent: Monday, July 08, 2013 6:25 PM To: wlbleaboy at 126 Cc: engine-devel at ovirt.org; Michal Skrivanek; Einav Cohen Subject: Re: [Engine-devel] about vm in vmpool On 07/08/2013 09:04 AM, wlbleaboy at 126 wrote: > Hi, all: > > I have using ovirt-sdk 3 monthes, I can use ovirt-sdk get vm?s > infomations like > > vm?s name, vm?s id, vm?ticket etc. > > but recently, I have a question about vm in vmpool, how could > I get vm?s information > > that the vm in vmpool. Especially, when a vm is at stop statuss. > > For example, when use UserPortal in the web-browser, no matter > the vm is in the vmpool, > > it can be showed in the web-browser, but, I can?t get vm? s information > which in the vmpool via > > the ovirt-sdk. > > Leaboy > > thanks > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > I'm pretty sure the user portal is 'mocking' the appearance of the VM, based on user having permission to the pool. From iheim at redhat.com Mon Jul 15 06:22:41 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 15 Jul 2013 09:22:41 +0300 Subject: [Engine-devel] about vm in vmpool In-Reply-To: <003c01ce811a$9d1efe70$d75cfb50$@com> References: <004c01ce7ba1$15468fa0$3fd3aee0$@com> <51DA938C.7020604@redhat.com> <003c01ce811a$9d1efe70$d75cfb50$@com> Message-ID: <51E39531.1000906@redhat.com> On 07/15/2013 08:17 AM, wlbleaboy at 126 wrote: > Hi, > How can I 'mocking' the appearance of ovirt-engine-sdk, > or, could you show me how user portal 'mocking' the appearance. > I'm not familiar with java, so It's hardly for me to read user portal's > java code. there are sample user portals, but i don't think they mock the pool's behavior. http://gerrit.ovirt.org/gitweb?p=samples-portals.git;a=tree > > -----Original Message----- > From: Itamar Heim [mailto:iheim at redhat.com] > Sent: Monday, July 08, 2013 6:25 PM > To: wlbleaboy at 126 > Cc: engine-devel at ovirt.org; Michal Skrivanek; Einav Cohen > Subject: Re: [Engine-devel] about vm in vmpool > > On 07/08/2013 09:04 AM, wlbleaboy at 126 wrote: >> Hi, all: >> >> I have using ovirt-sdk 3 monthes, I can use ovirt-sdk get vm?s >> infomations like >> >> vm?s name, vm?s id, vm?ticket etc. >> >> but recently, I have a question about vm in vmpool, how could >> I get vm?s information >> >> that the vm in vmpool. Especially, when a vm is at stop statuss. >> >> For example, when use UserPortal in the web-browser, no matter >> the vm is in the vmpool, >> >> it can be showed in the web-browser, but, I can?t get vm? s information >> which in the vmpool via >> >> the ovirt-sdk. >> >> Leaboy >> >> thanks >> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > I'm pretty sure the user portal is 'mocking' the appearance of the VM, > based on user having permission to the pool. > > From ovedo at redhat.com Mon Jul 15 06:32:35 2013 From: ovedo at redhat.com (Oved Ourfalli) Date: Mon, 15 Jul 2013 02:32:35 -0400 (EDT) Subject: [Engine-devel] VNIC profiles In-Reply-To: <51E26085.7070500@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> <321253300.385386.1373271681521.JavaMail.root@redhat.com> <51E12928.6090408@redhat.com> <51E26085.7070500@redhat.com> Message-ID: <1636854146.208497.1373869955270.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Moti Asayag" > To: "Itamar Heim" > Cc: "engine-devel" > Sent: Sunday, July 14, 2013 11:25:41 AM > Subject: Re: [Engine-devel] VNIC profiles > > On 07/13/2013 01:17 PM, Itamar Heim wrote: > > On 07/08/2013 11:21 AM, Moti Asayag wrote: > >> > >> > > ... > >> > >> The wiki was updated with the VM/Template import logic: > >> > >> http://www.ovirt.org/Features/Vnic_Profiles#VM_snapshot.2Fimport.2Fexport > > > > 1. you are updating the OVF - have you found a matching field in the OVF > > spec[1] for vnic profiles? > > > > Currently the only field used to specify the network is "Connection". > There is no specific field for specifying a vnic profile. We can make > a use of the 'OtherResourceType' which isn't in use by the engine for > storing the vnic profile name. > > An alternative would be using the Connection field to store both > Network:Profile, and parsing it when a vm or template are being imported. > > I'm in favour of the first option for simplicity and in order not to > modify the Connection field as is being used today. > I'm in favor of this option as well. > > 2. import/export - please note exporting is backward compatible based on > > DC level (iirc - omer should remember better), i.e., if the DC is 3.2, > > the export should ignore vnic profiles, etc. > > > > 3. while at it - just to make sure before i add more comments- are the > > screenshots in the wiki up to date? > > The images should be updated since the vnic profiles will be a main-tab, > appears only when a network is selected, instead of a sub-tab of the > networks. > > > > > Thanks, > > Itamar > > > > [1] http://dmtf.org/standards/ovf > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From alkaplan at redhat.com Mon Jul 15 12:58:49 2013 From: alkaplan at redhat.com (Alona Kaplan) Date: Mon, 15 Jul 2013 08:58:49 -0400 (EDT) Subject: [Engine-devel] VNIC profiles In-Reply-To: <51E2764F.7090405@redhat.com> References: <51D02BB9.4090008@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> <321253300.385386.1373271681521.JavaMail.root@redhat.com> <51E12928.6090408@redhat.com> <51E26085.7070500@redhat.com> <51E2764F.7090405@redhat.com> Message-ID: <482553474.1239575.1373893129632.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Moti Asayag" > Cc: "engine-devel" > Sent: Sunday, July 14, 2013 12:58:39 PM > Subject: Re: [Engine-devel] VNIC profiles > > On 07/14/2013 11:25 AM, Moti Asayag wrote: > >> 2. import/export - please note exporting is backward compatible based on > >> >DC level (iirc - omer should remember better), i.e., if the DC is 3.2, > >> >the export should ignore vnic profiles, etc. > >> > > >> >3. while at it - just to make sure before i add more comments- are the > >> >screenshots in the wiki up to date? > > The images should be updated since the vnic profiles will be a main-tab, > > appears only when a network is selected, instead of a sub-tab of the > > networks. > > > > that sounds a bit arduous (a main tab appearing only when standing on a > specific entity)? That's how Quota works:) I think it would be great if we could show profiles main tab also under system. But as we have too many main tabs under system and we don't have the option to close tabs we don't want to see, we decided not to put profiles main tab under system. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Mon Jul 15 13:07:16 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 15 Jul 2013 16:07:16 +0300 Subject: [Engine-devel] VNIC profiles In-Reply-To: <482553474.1239575.1373893129632.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> <321253300.385386.1373271681521.JavaMail.root@redhat.com> <51E12928.6090408@redhat.com> <51E26085.7070500@redhat.com> <51E2764F.7090405@redhat.com> <482553474.1239575.1373893129632.JavaMail.root@redhat.com> Message-ID: <51E3F404.6080607@redhat.com> On 07/15/2013 03:58 PM, Alona Kaplan wrote: >>>> 2. import/export - please note exporting is backward compatible based on >>>>> > >> >DC level (iirc - omer should remember better), i.e., if the DC is 3.2, >>>>> > >> >the export should ignore vnic profiles, etc. >>>>> > >> > >>>>> > >> >3. while at it - just to make sure before i add more comments- are the >>>>> > >> >screenshots in the wiki up to date? >>> > >The images should be updated since the vnic profiles will be a main-tab, >>> > >appears only when a network is selected, instead of a sub-tab of the >>> > >networks. >>> > > >> > >> >that sounds a bit arduous (a main tab appearing only when standing on a >> >specific entity)? > That's how Quota works:) > I think it would be great if we could show profiles main tab also under system. > But as we have too many main tabs under system and we don't have the option to > close tabs we don't want to see, we decided not to put profiles main tab under system. > quota's are at DC level. vnic profiles are at logical network level? From alkaplan at redhat.com Mon Jul 15 13:40:59 2013 From: alkaplan at redhat.com (Alona Kaplan) Date: Mon, 15 Jul 2013 09:40:59 -0400 (EDT) Subject: [Engine-devel] VNIC profiles In-Reply-To: <51E3F404.6080607@redhat.com> References: <51D02BB9.4090008@redhat.com> <51DA6613.9040903@redhat.com> <321253300.385386.1373271681521.JavaMail.root@redhat.com> <51E12928.6090408@redhat.com> <51E26085.7070500@redhat.com> <51E2764F.7090405@redhat.com> <482553474.1239575.1373893129632.JavaMail.root@redhat.com> <51E3F404.6080607@redhat.com> Message-ID: <995648311.1336813.1373895659361.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Alona Kaplan" > Cc: "Moti Asayag" , "engine-devel" > Sent: Monday, July 15, 2013 4:07:16 PM > Subject: Re: [Engine-devel] VNIC profiles > > On 07/15/2013 03:58 PM, Alona Kaplan wrote: > >>>> 2. import/export - please note exporting is backward compatible based on > >>>>> > >> >DC level (iirc - omer should remember better), i.e., if the DC is > >>>>> > >> >3.2, > >>>>> > >> >the export should ignore vnic profiles, etc. > >>>>> > >> > > >>>>> > >> >3. while at it - just to make sure before i add more comments- > >>>>> > >> >are the > >>>>> > >> >screenshots in the wiki up to date? > >>> > >The images should be updated since the vnic profiles will be a > >>> > >main-tab, > >>> > >appears only when a network is selected, instead of a sub-tab of the > >>> > >networks. > >>> > > > >> > > >> >that sounds a bit arduous (a main tab appearing only when standing on a > >> >specific entity)? > > That's how Quota works:) > > I think it would be great if we could show profiles main tab also under > > system. > > But as we have too many main tabs under system and we don't have the option > > to > > close tabs we don't want to see, we decided not to put profiles main tab > > under system. > > > > quota's are at DC level. vnic profiles are at logical network level? Yes, profiles are at logical network level. But the tab can be visible on dc context as well. It can be convenient since the user can change the profile's network. > From mgoldboi at redhat.com Mon Jul 15 14:45:43 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Mon, 15 Jul 2013 17:45:43 +0300 Subject: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo Message-ID: <51E40B17.6010901@redhat.com> Maintainers and all, due to some misunderstanding regarding feature freeze for ovirt 3.3 release (suppose to be today, but marked as Jul 17th on release page), we are extending feature freeze till wendesday. feature owners: -please update 3.3 release page [1] with the feature status -please update testing page for your feature package owners- once your component is ready (should be done till wendesday) -tag your repo for 3.3 beta release -provide srpm to mike -provide fc19/el6 rpms builds using mock to mike mike if you would like to set a place people can upload it too please let us know. [1]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table Thanks. From iheim at redhat.com Mon Jul 15 14:51:19 2013 From: iheim at redhat.com (Itamar Heim) Date: Mon, 15 Jul 2013 17:51:19 +0300 Subject: [Engine-devel] VNIC profiles In-Reply-To: <995648311.1336813.1373895659361.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <51DA6613.9040903@redhat.com> <321253300.385386.1373271681521.JavaMail.root@redhat.com> <51E12928.6090408@redhat.com> <51E26085.7070500@redhat.com> <51E2764F.7090405@redhat.com> <482553474.1239575.1373893129632.JavaMail.root@redhat.com> <51E3F404.6080607@redhat.com> <995648311.1336813.1373895659361.JavaMail.root@redhat.com> Message-ID: <51E40C67.3050302@redhat.com> On 07/15/2013 04:40 PM, Alona Kaplan wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Alona Kaplan" >> Cc: "Moti Asayag" , "engine-devel" >> Sent: Monday, July 15, 2013 4:07:16 PM >> Subject: Re: [Engine-devel] VNIC profiles >> >> On 07/15/2013 03:58 PM, Alona Kaplan wrote: >>>>>> 2. import/export - please note exporting is backward compatible based on >>>>>>>>>>> DC level (iirc - omer should remember better), i.e., if the DC is >>>>>>>>>>> 3.2, >>>>>>>>>>> the export should ignore vnic profiles, etc. >>>>>>>>>>> >>>>>>>>>>> 3. while at it - just to make sure before i add more comments- >>>>>>>>>>> are the >>>>>>>>>>> screenshots in the wiki up to date? >>>>>>> The images should be updated since the vnic profiles will be a >>>>>>> main-tab, >>>>>>> appears only when a network is selected, instead of a sub-tab of the >>>>>>> networks. >>>>>>> >>>>> >>>>> that sounds a bit arduous (a main tab appearing only when standing on a >>>>> specific entity)? >>> That's how Quota works:) >>> I think it would be great if we could show profiles main tab also under >>> system. >>> But as we have too many main tabs under system and we don't have the option >>> to >>> close tabs we don't want to see, we decided not to put profiles main tab >>> under system. >>> >> >> quota's are at DC level. vnic profiles are at logical network level? > > Yes, profiles are at logical network level. > But the tab can be visible on dc context as well. > It can be convenient since the user can change the profile's network. it will be easier for me to continue the discussion when the screenshots/mockups are updated i guess. Thanks, Itamar From iheim at redhat.com Tue Jul 16 12:27:18 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 16 Jul 2013 15:27:18 +0300 Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <324529653.3123453.1372852500150.JavaMail.root@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <2036896830.10266657.1372610122917.JavaMail.root@redhat.com> <51D11BE0.6000809@redhat.com> <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> <429008692.30913072.1372667257807.JavaMail.root@redhat.com> <51D1528E.5050908@redhat.com> <230315749.1320462.1372754674527.JavaMail.root@redhat.com> <762BDFC8-7094-4C84-9EF3-DEBA88A06336@redhat.com> <324529653.3123453.1372852500150.JavaMail.root@redhat.com> Message-ID: <51E53C26.6040906@redhat.com> On 07/03/2013 02:55 PM, Martin Perina wrote: > Let's summarize again, SSH Soft Fencing patches has been merged yesterday > with following functionality: > > 1) For hosts with power management configured, SSH Soft Fencing is the 1st > fencing stage. If it doesn't help, real fencing will be executed. > > 2) For hosts without power management configured, SSH Soft Fencing is the only > fencing stage. If it doesn't help, host will become non responsive. > > 3) SSH Soft Fencing is enabled by default, there's no configuration option > to disable it > > 4) SshSoftFencingCommand option is used to define what command is executed > during SSH Soft Fencing. It can only be changed manually in database. > > The whole fencing process in oVirt 3.3 is decribed at > > http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3 I assume ssh soft fencing isn't considered "fencing"? i.e., i assume it does not release resource occupied by the host (spm, running vms)? Thanks, Itamar From iheim at redhat.com Tue Jul 16 13:03:46 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 16 Jul 2013 16:03:46 +0300 Subject: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo In-Reply-To: <51E40B17.6010901@redhat.com> References: <51E40B17.6010901@redhat.com> Message-ID: <51E544B2.9030003@redhat.com> On 07/15/2013 05:45 PM, Moran Goldboim wrote: > Maintainers and all, > > due to some misunderstanding regarding feature freeze for ovirt 3.3 > release (suppose to be today, but marked as Jul 17th on release page), > we are extending feature freeze till wendesday. > > feature owners: > -please update 3.3 release page [1] with the feature status > -please update testing page for your feature > > package owners- once your component is ready (should be done till > wendesday) > -tag your repo for 3.3 beta release > -provide srpm to mike > -provide fc19/el6 rpms builds using mock to mike > > mike if you would like to set a place people can upload it too please > let us know. > > > [1]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table > what's the status of these which seem a shame to release without (and all are supposed to be on their final step)? - glance integration (federico) - Neutron (quantum) integration (livnat/mike)? - cloud-init (greg/omer)? - plugable scheduling (doron)? Thanks, Itamar From alonbl at redhat.com Tue Jul 16 13:04:46 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 16 Jul 2013 09:04:46 -0400 (EDT) Subject: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo In-Reply-To: <51E544B2.9030003@redhat.com> References: <51E40B17.6010901@redhat.com> <51E544B2.9030003@redhat.com> Message-ID: <183124858.581754.1373979886447.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Moran Goldboim" , "Doron Fediuck" , "Greg Padgett" > , "Omer Frenkel" , "Michal Skrivanek" , "Mike > Kolesnik" , "Livnat Peer" , "Ayal Baron" , "Federico > Simoncelli" > Cc: "engine-devel" > Sent: Tuesday, July 16, 2013 4:03:46 PM > Subject: Re: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo > > On 07/15/2013 05:45 PM, Moran Goldboim wrote: > > Maintainers and all, > > > > due to some misunderstanding regarding feature freeze for ovirt 3.3 > > release (suppose to be today, but marked as Jul 17th on release page), > > we are extending feature freeze till wendesday. > > > > feature owners: > > -please update 3.3 release page [1] with the feature status > > -please update testing page for your feature > > > > package owners- once your component is ready (should be done till > > wendesday) > > -tag your repo for 3.3 beta release > > -provide srpm to mike > > -provide fc19/el6 rpms builds using mock to mike > > > > mike if you would like to set a place people can upload it too please > > let us know. > > > > > > [1]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table > > > > what's the status of these which seem a shame to release without (and > all are supposed to be on their final step)? > - glance integration (federico) > - Neutron (quantum) integration (livnat/mike)? I am working on releasing beta of the prerequisites. > - cloud-init (greg/omer)? > - plugable scheduling (doron)? > > Thanks, > Itamar > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From dfediuck at redhat.com Tue Jul 16 13:13:51 2013 From: dfediuck at redhat.com (Doron Fediuck) Date: Tue, 16 Jul 2013 09:13:51 -0400 (EDT) Subject: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo In-Reply-To: <183124858.581754.1373979886447.JavaMail.root@redhat.com> References: <51E40B17.6010901@redhat.com> <51E544B2.9030003@redhat.com> <183124858.581754.1373979886447.JavaMail.root@redhat.com> Message-ID: <384069084.1795333.1373980431730.JavaMail.root@redhat.com> ----- Original Message ----- | From: "Alon Bar-Lev" | To: "Itamar Heim" | Cc: "Moran Goldboim" , "Doron Fediuck" , "Greg Padgett" | , "Omer Frenkel" , "Michal Skrivanek" , "Mike | Kolesnik" , "Livnat Peer" , "Ayal Baron" , "Federico | Simoncelli" , "engine-devel" | Sent: Tuesday, July 16, 2013 4:04:46 PM | Subject: Re: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo | | | | ----- Original Message ----- | > From: "Itamar Heim" | > To: "Moran Goldboim" , "Doron Fediuck" | > , "Greg Padgett" | > , "Omer Frenkel" , "Michal | > Skrivanek" , "Mike | > Kolesnik" , "Livnat Peer" , "Ayal | > Baron" , "Federico | > Simoncelli" | > Cc: "engine-devel" | > Sent: Tuesday, July 16, 2013 4:03:46 PM | > Subject: Re: [Engine-devel] oVirt 3.3 feature freeze and delivery to | > testing repo | > | > On 07/15/2013 05:45 PM, Moran Goldboim wrote: | > > Maintainers and all, | > > | > > due to some misunderstanding regarding feature freeze for ovirt 3.3 | > > release (suppose to be today, but marked as Jul 17th on release page), | > > we are extending feature freeze till wendesday. | > > | > > feature owners: | > > -please update 3.3 release page [1] with the feature status | > > -please update testing page for your feature | > > | > > package owners- once your component is ready (should be done till | > > wendesday) | > > -tag your repo for 3.3 beta release | > > -provide srpm to mike | > > -provide fc19/el6 rpms builds using mock to mike | > > | > > mike if you would like to set a place people can upload it too please | > > let us know. | > > | > > | > > [1]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table | > > | > | > what's the status of these which seem a shame to release without (and | > all are supposed to be on their final step)? | > - glance integration (federico) | > - Neutron (quantum) integration (livnat/mike)? | | I am working on releasing beta of the prerequisites. | | > - cloud-init (greg/omer)? | > - plugable scheduling (doron)? Working now on merging the new internal scheduler. The proxy (pluggable part) will take a few more days. So if there's a re-spin the proxy will be in. | > | > Thanks, | > Itamar | > _______________________________________________ | > Engine-devel mailing list | > Engine-devel at ovirt.org | > http://lists.ovirt.org/mailman/listinfo/engine-devel | > | From fsimonce at redhat.com Tue Jul 16 13:35:03 2013 From: fsimonce at redhat.com (Federico Simoncelli) Date: Tue, 16 Jul 2013 09:35:03 -0400 (EDT) Subject: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo In-Reply-To: <51E544B2.9030003@redhat.com> References: <51E40B17.6010901@redhat.com> <51E544B2.9030003@redhat.com> Message-ID: <1357951875.1299075.1373981703910.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Moran Goldboim" , "Doron Fediuck" , "Greg Padgett" > , "Omer Frenkel" , "Michal Skrivanek" , "Mike > Kolesnik" , "Livnat Peer" , "Ayal Baron" , "Federico > Simoncelli" > Cc: "engine-devel" > Sent: Tuesday, July 16, 2013 3:03:46 PM > Subject: Re: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo > > On 07/15/2013 05:45 PM, Moran Goldboim wrote: > > Maintainers and all, > > > > due to some misunderstanding regarding feature freeze for ovirt 3.3 > > release (suppose to be today, but marked as Jul 17th on release page), > > we are extending feature freeze till wendesday. > > > > feature owners: > > -please update 3.3 release page [1] with the feature status > > -please update testing page for your feature > > > > package owners- once your component is ready (should be done till > > wendesday) > > -tag your repo for 3.3 beta release > > -provide srpm to mike > > -provide fc19/el6 rpms builds using mock to mike > > > > mike if you would like to set a place people can upload it too please > > let us know. > > > > > > [1]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table > > > > what's the status of these which seem a shame to release without (and > all are supposed to be on their final step)? > - glance integration (federico) VDSM side is merged. Engine patches need some revisions, overall feedback is positive (+1/+2). -- Federico > - Neutron (quantum) integration (livnat/mike)? > - cloud-init (greg/omer)? > - plugable scheduling (doron)? From ofrenkel at redhat.com Tue Jul 16 13:36:04 2013 From: ofrenkel at redhat.com (Omer Frenkel) Date: Tue, 16 Jul 2013 09:36:04 -0400 (EDT) Subject: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo In-Reply-To: <51E544B2.9030003@redhat.com> References: <51E40B17.6010901@redhat.com> <51E544B2.9030003@redhat.com> Message-ID: <1198334429.1812945.1373981764574.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Moran Goldboim" , "Doron Fediuck" , "Greg Padgett" > , "Omer Frenkel" , "Michal Skrivanek" , "Mike > Kolesnik" , "Livnat Peer" , "Ayal Baron" , "Federico > Simoncelli" > Cc: "engine-devel" > Sent: Tuesday, July 16, 2013 4:03:46 PM > Subject: Re: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo > > On 07/15/2013 05:45 PM, Moran Goldboim wrote: > > Maintainers and all, > > > > due to some misunderstanding regarding feature freeze for ovirt 3.3 > > release (suppose to be today, but marked as Jul 17th on release page), > > we are extending feature freeze till wendesday. > > > > feature owners: > > -please update 3.3 release page [1] with the feature status > > -please update testing page for your feature > > > > package owners- once your component is ready (should be done till > > wendesday) > > -tag your repo for 3.3 beta release > > -provide srpm to mike > > -provide fc19/el6 rpms builds using mock to mike > > > > mike if you would like to set a place people can upload it too please > > let us know. > > > > > > [1]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table > > > > what's the status of these which seem a shame to release without (and > all are supposed to be on their final step)? > - glance integration (federico) > - Neutron (quantum) integration (livnat/mike)? > - cloud-init (greg/omer)? pending ack from REST > - plugable scheduling (doron)? > > Thanks, > Itamar > From mkolesni at redhat.com Tue Jul 16 13:50:00 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Tue, 16 Jul 2013 09:50:00 -0400 (EDT) Subject: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo In-Reply-To: <183124858.581754.1373979886447.JavaMail.root@redhat.com> References: <51E40B17.6010901@redhat.com> <51E544B2.9030003@redhat.com> <183124858.581754.1373979886447.JavaMail.root@redhat.com> Message-ID: <954295562.1370991.1373982600052.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Moran Goldboim" , "Doron Fediuck" > > , "Greg Padgett" > > , "Omer Frenkel" , "Michal > > Skrivanek" , "Mike > > Kolesnik" , "Livnat Peer" , "Ayal > > Baron" , "Federico > > Simoncelli" > > Cc: "engine-devel" > > Sent: Tuesday, July 16, 2013 4:03:46 PM > > Subject: Re: [Engine-devel] oVirt 3.3 feature freeze and delivery to > > testing repo > > > > On 07/15/2013 05:45 PM, Moran Goldboim wrote: > > > Maintainers and all, > > > > > > due to some misunderstanding regarding feature freeze for ovirt 3.3 > > > release (suppose to be today, but marked as Jul 17th on release page), > > > we are extending feature freeze till wendesday. > > > > > > feature owners: > > > -please update 3.3 release page [1] with the feature status > > > -please update testing page for your feature > > > > > > package owners- once your component is ready (should be done till > > > wendesday) > > > -tag your repo for 3.3 beta release > > > -provide srpm to mike > > > -provide fc19/el6 rpms builds using mock to mike > > > > > > mike if you would like to set a place people can upload it too please > > > let us know. > > > > > > > > > [1]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table > > > > > > > what's the status of these which seem a shame to release without (and > > all are supposed to be on their final step)? > > - glance integration (federico) > > - Neutron (quantum) integration (livnat/mike)? > > I am working on releasing beta of the prerequisites. Almost all is in, there are some host installation patches that are still pending Alon's mentioned work and some UI patches under review. > > > - cloud-init (greg/omer)? > > - plugable scheduling (doron)? > > > > Thanks, > > Itamar > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From mpastern at redhat.com Tue Jul 16 14:01:32 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 16 Jul 2013 17:01:32 +0300 Subject: [Engine-devel] ovirt-engine-sdk-python 3.3.0.3-1 released In-Reply-To: <515AD1E4.7050506@redhat.com> References: <515AD1E4.7050506@redhat.com> Message-ID: <51E5523C.6010301@redhat.com> * Tue Jul 16 2013 Michael Pasternak - 3.3.0.3-1 - rename package to ovirt-engine-sdk-python - added "watchdog" feature #947977 - added "external tasks" feature #872719 - snapshot can persist/restore memory state now #960931 - sdk expose datetime elements as strings while schema defines them as xs:dateTime #960747 - removed DataCenterQuota.delete() (not supported in this version) - removed DataCenterQuota.add() (not supported in this version) - to cluster.add()/update() added [trusted_service: boolean] property - to datacenter added new field [comment] - to disk added [sgio] field to enable|disable filtering for the ScsiGenericIo - to VmPools.add() added new property [@param vmpool.max_user_vms: int] - to NIC added new property [custom_properties] - to cluster.update() added new doc [@param cluster.data_center.id: string] - to host.fence() added parameter action.fence_type - to StorageDomain.delete() added doc host.id|name - to StorageDomains.add() added doc [@param storagedomain.storage_format: string] - to VM added new sub-collection VMApplications For more details see [1]. [1] http://wiki.ovirt.org/Python-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Tue Jul 16 14:10:27 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 16 Jul 2013 17:10:27 +0300 Subject: [Engine-devel] ovirt-engine-cli 3.3.0.3-1 released In-Reply-To: <5180CF89.60400@redhat.com> References: <5180CF89.60400@redhat.com> Message-ID: <51E55453.2020905@redhat.com> * Tue Jul 16 2013 Michael Pasternak - 3.3.0.3-1 - refactor "connect" command help - remove support for --password option #983713 - add option to define auto connect #918908 - "exit" command fails after "disconnect" from script #971285 - list permits format better error when not enough parameters #962472 - ovirt-shell should contain the hostname of the system #866319 - certificate file keys are not exposed in .ovirtshellrc #960983 - add brick operation fails from ovirt-shell #923169 More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Tue Jul 16 14:28:36 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 16 Jul 2013 17:28:36 +0300 Subject: [Engine-devel] ovirt-engine-sdk-java 1.0.0.11-1 released In-Reply-To: <51DACB05.2080908@redhat.com> References: <51DACB05.2080908@redhat.com> Message-ID: <51E55894.6080904@redhat.com> * Tue Jul 16 2013 Michael Pasternak - 1.0.0.11-1 - added "watchdog" feature #947977 - added "external tasks" feature #872719 - snapshot can persist/restore memory state now #960931 More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D From vszocs at redhat.com Tue Jul 16 15:31:03 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Tue, 16 Jul 2013 11:31:03 -0400 (EDT) Subject: [Engine-devel] Upgrading oVirt UI technology stack - patch is ready! In-Reply-To: <1735062604.3333173.1373553993922.JavaMail.root@redhat.com> References: <526288595.5644695.1372946839995.JavaMail.root@redhat.com> <1735062604.3333173.1373553993922.JavaMail.root@redhat.com> Message-ID: <810999370.1359385.1373988663789.JavaMail.root@redhat.com> Hello everyone, *big* thanks to Tomas, Daniel and Alex for taking their time and reviewing this monstrous patch, I've uploaded new patch set and (hopefully) addressed all remaining comments. The patch has been verified locally in both debug and web mode using FF10/Linux, no behavioral or visual regressions were detected during the initial testing. Regards, Vojtech ----- Original Message ----- > From: "Einav Cohen" > To: "engine-devel" > Cc: "Vojtech Szocs" > Sent: Thursday, July 11, 2013 4:46:33 PM > Subject: Upgrading oVirt UI technology stack - patch is ready! > > Hi Everyone, > > Following the announcement below and the changes-overview session from > a couple of days ago: The patch is now ready for review: > http://gerrit.ovirt.org/#/c/16739/ > The patch is quite huge and touches *a lot* of files, therefore it is > expected > to cause a bit of a rebase nightmare; so as I am sure that we all want to > move > to the new GWT-and-related dependencies, your prompt feedback (in an effort > to > merge the patch as soon as possible) will be highly-appreciated. > TIA! > > ---- > Regards, > Einav > > ----- Original Message ----- > > From: "Vojtech Szocs" > > To: "engine-devel" > > Cc: "Einav Cohen" , "Itamar Heim" > > Sent: Thursday, July 4, 2013 10:07:19 AM > > Subject: Upgrading oVirt UI technology stack > > > > Hello everyone, > > > > I wrote a wiki page to summarize our effort to upgrade existing UI > > technology > > stack shared by oVirt web applications: > > > > http://www.ovirt.org/Features/GWT_Platform_Upgrade > > > > The wiki page divides GWT and GWTP changes into Essential and > > Non-essential. > > All Essential changes will be part of the initial upgrade patch (currently > > in progress), all Non-essential changes will be addressed later on, based > > on > > their priority. > > > > There's still one open issue (Essential change) related to GWTP framework, > > however we should come to a conclusion pretty soon. The corresponding > > (Essential change) patch will follow shortly after that. > > > > Any feedback is greatly appreciated, let me know what you think. > > > > Regards, > > Vojtech > > > From kiril at redhat.com Wed Jul 17 05:14:20 2013 From: kiril at redhat.com (Kiril Nesenko) Date: Wed, 17 Jul 2013 01:14:20 -0400 (EDT) Subject: [Engine-devel] find bugs job fails In-Reply-To: <2023521917.2013447.1374038049329.JavaMail.root@redhat.com> Message-ID: <2025214223.2013460.1374038060335.JavaMail.root@redhat.com> Hello Gilad, Seems like your patch - 6af11b4d53d8fa1f2bcc2a9088459005865bff0c brakes the job[1]. Please send a fix asap. [1] http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4674/ - Kiril From lhornyak at redhat.com Wed Jul 17 06:50:56 2013 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Wed, 17 Jul 2013 02:50:56 -0400 (EDT) Subject: [Engine-devel] find bugs job fails In-Reply-To: <2025214223.2013460.1374038060335.JavaMail.root@redhat.com> References: <2025214223.2013460.1374038060335.JavaMail.root@redhat.com> Message-ID: <2080987673.1145252.1374043856205.JavaMail.root@redhat.com> Hi, I will send a fix soon. ----- Original Message ----- > From: "Kiril Nesenko" > To: "Gilad Chaplik" > Cc: engine-devel at ovirt.org > Sent: Wednesday, July 17, 2013 7:14:20 AM > Subject: [Engine-devel] find bugs job fails > > Hello Gilad, > > Seems like your patch - 6af11b4d53d8fa1f2bcc2a9088459005865bff0c brakes the > job[1]. > > Please send a fix asap. > > [1] http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4674/ > > - Kiril > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mgoldboi at redhat.com Wed Jul 17 11:19:26 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Wed, 17 Jul 2013 14:19:26 +0300 Subject: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo In-Reply-To: <1198334429.1812945.1373981764574.JavaMail.root@redhat.com> References: <51E40B17.6010901@redhat.com> <51E544B2.9030003@redhat.com> <1198334429.1812945.1373981764574.JavaMail.root@redhat.com> Message-ID: <51E67DBE.3020304@redhat.com> On 07/16/2013 04:36 PM, Omer Frenkel wrote: > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Moran Goldboim" , "Doron Fediuck" , "Greg Padgett" >> , "Omer Frenkel" , "Michal Skrivanek" , "Mike >> Kolesnik" , "Livnat Peer" , "Ayal Baron" , "Federico >> Simoncelli" >> Cc: "engine-devel" >> Sent: Tuesday, July 16, 2013 4:03:46 PM >> Subject: Re: [Engine-devel] oVirt 3.3 feature freeze and delivery to testing repo >> >> On 07/15/2013 05:45 PM, Moran Goldboim wrote: >>> Maintainers and all, >>> >>> due to some misunderstanding regarding feature freeze for ovirt 3.3 >>> release (suppose to be today, but marked as Jul 17th on release page), >>> we are extending feature freeze till wendesday. >>> >>> feature owners: >>> -please update 3.3 release page [1] with the feature status >>> -please update testing page for your feature >>> >>> package owners- once your component is ready (should be done till >>> wendesday) >>> -tag your repo for 3.3 beta release >>> -provide srpm to mike >>> -provide fc19/el6 rpms builds using mock to mike >>> >>> mike if you would like to set a place people can upload it too please >>> let us know. >>> >>> >>> [1]http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table >>> >> what's the status of these which seem a shame to release without (and >> all are supposed to be on their final step)? >> - glance integration (federico) >> - Neutron (quantum) integration (livnat/mike)? >> - cloud-init (greg/omer)? > pending ack from REST > >> - plugable scheduling (doron)? >> >> Thanks, >> Itamar >> Adding Mike. Guys - please be ready to update the status of those features on weekly meeting today. My feeling that if those features aren't in we should block the alpha/beta1 release of the version which will go also to test-day till those are merged. Thanks. From shweng at 163.com Thu Jul 18 05:41:05 2013 From: shweng at 163.com (Edgar) Date: Thu, 18 Jul 2013 13:41:05 +0800 (CST) Subject: [Engine-devel] oVirt Engine eaten lots of memory when "Make Templates"? Message-ID: <2bb11771.6ee2.13ff04bc6b0.Coremail.shweng@163.com> Hi, all I have found oVirt eats lots of memory when "Make Tmplates" from Virtual Machines. before make templates I excuted "free" command on oVirt manager console, "Make Templates" on admin web protal then excute "free" command again and found the free momory decrease about 30GB (VM disk size configured 30GB) after make 2 templates it eaten up all system memory. my oVirt environment: OS: CentOS 6.4 wih kernel version 2.6.32-358 oVirt engine :3.2.1 qemu:0.12.1.2-2.355 [root at test ~]# rpm -qa |grep ovirt ovirt-iso-uploader-3.2.0-1.el6.noarch ovirt-log-collector-3.2.0-1.el6.noarch ovirt-engine-jbossas711-1-0.x86_64 ovirt-engine-genericapi-3.2.1-1.41.el6.noarch ovirt-engine-userportal-3.2.1-1.41.el6.noarch ovirt-engine-sdk-3.2.0.9-1.el6.noarch ovirt-host-deploy-1.1.0-0.0.master.el6.noarch ovirt-image-uploader-3.2.0-1.el6.noarch ovirt-host-deploy-java-1.1.0-0.0.master.el6.noarch ovirt-engine-dbscripts-3.2.1-1.41.el6.noarch ovirt-engine-restapi-3.2.1-1.41.el6.noarch ovirt-engine-tools-3.2.1-1.41.el6.noarch ovirt-engine-webadmin-portal-3.2.1-1.41.el6.noarch ovirt-engine-cli-3.2.0.10-1.el6.noarch ovirt-engine-backend-3.2.1-1.41.el6.noarch ovirt-engine-setup-3.2.1-1.41.el6.noarch ovirt-engine-3.2.1-1.41.el6.noarch [root at test ~]# rpm -qa |grep qemu qemu-kvm-rhev-0.12.1.2-2.355.el6.2.x86_64 qemu-kvm-tools-0.12.1.2-2.355.0.1.el6.centos.5.x86_64 gpxe-roms-qemu-0.9.7-6.9.el6.noarch qemu-img-rhev-0.12.1.2-2.355.el6.2.x86_64 [root at test ~]# rpm -qa |grep kernel kernel-headers-2.6.32-358.11.1.el6.x86_64 kernel-devel-2.6.32-358.11.1.el6.x86_64 dracut-kernel-004-303.el6.noarch kernel-2.6.32-358.el6.x86_64 kernel-firmware-2.6.32-358.el6.noarch -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecohen at redhat.com Wed Jul 17 21:02:12 2013 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 17 Jul 2013 17:02:12 -0400 (EDT) Subject: [Engine-devel] problem adding local Data (first-master) storage domain In-Reply-To: <71814935.3351398.1374094271348.JavaMail.root@redhat.com> Message-ID: <635396714.3376737.1374094932027.JavaMail.root@redhat.com> Hi, I tried adding a local storage domain to my Local Data-Center, and it failed on a "Can't obtain lock" error. The storage domain hasn't been created in ovirt-engine (appeared for a second in the GUI and then disappeared, right after the "Can't obtain lock" error popped-up), however some content has been created in the to-be-local- storage directory on the Host. ovirt-engine code is latest upstream; ovirt-engine server is fedora 18; vdsm is on fedora 18; vdsm version: vdsm-4.10.3-17.fc18.x86_64 vdsm.log attached. (relevant time-stamp: 2013-07-17 16:43:46, you can look for "/tmp/ovirt-local-storage/data1"). ideas? thanks in advance! ---- Regards, Einav -------------- next part -------------- A non-text attachment was scrubbed... Name: vdsm.log Type: text/x-log Size: 4723062 bytes Desc: not available URL: From ybronhei at redhat.com Thu Jul 18 06:48:17 2013 From: ybronhei at redhat.com (Yaniv Bronheim) Date: Thu, 18 Jul 2013 02:48:17 -0400 (EDT) Subject: [Engine-devel] SSH Soft Fencing In-Reply-To: <51E53C26.6040906@redhat.com> References: <1622219224.572748.1372330266360.JavaMail.root@redhat.com> <1870215446.1708395.1372666992955.JavaMail.root@redhat.com> <429008692.30913072.1372667257807.JavaMail.root@redhat.com> <51D1528E.5050908@redhat.com> <230315749.1320462.1372754674527.JavaMail.root@redhat.com> <762BDFC8-7094-4C84-9EF3-DEBA88A06336@redhat.com> <324529653.3123453.1372852500150.JavaMail.root@redhat.com> <51E53C26.6040906@redhat.com> Message-ID: <534337574.1140278.1374130097318.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Martin Perina" > Cc: engine-devel at ovirt.org > Sent: Tuesday, July 16, 2013 3:27:18 PM > Subject: Re: [Engine-devel] SSH Soft Fencing > > On 07/03/2013 02:55 PM, Martin Perina wrote: > > Let's summarize again, SSH Soft Fencing patches has been merged yesterday > > with following functionality: > > > > 1) For hosts with power management configured, SSH Soft Fencing is the 1st > > fencing stage. If it doesn't help, real fencing will be executed. > > > > 2) For hosts without power management configured, SSH Soft Fencing is the > > only > > fencing stage. If it doesn't help, host will become non responsive. > > > > 3) SSH Soft Fencing is enabled by default, there's no configuration option > > to disable it > > > > 4) SshSoftFencingCommand option is used to define what command is executed > > during SSH Soft Fencing. It can only be changed manually in database. > > > > The whole fencing process in oVirt 3.3 is decribed at > > > > http://www.ovirt.org/Automatic_Fencing#Automatic_Fencing_in_oVirt_3.3 > > I assume ssh soft fencing isn't considered "fencing"? i.e., i assume it > does not release resource occupied by the host (spm, running vms)? > it should. the correct way to release resources when killing vdsm, as it implemented now, is to send SIGTERM to vdsm process, as sanlock does. but it might take time (more than 40 sec) currently we just kill and start over the process with the service tool. SIGTERM calls to prepareForShutdown, it might be necessary if after the restart the engine initiates failover. "stop" verb does send SIGTERM before SIGKILL to vdsm, we just need verify that it waits enough time before sending the KILL and vdsm initiated the prepareForShutdown scope. > Thanks, > Itamar > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From gshereme at redhat.com Thu Jul 18 20:38:33 2013 From: gshereme at redhat.com (Greg Sheremeta) Date: Thu, 18 Jul 2013 16:38:33 -0400 (EDT) Subject: [Engine-devel] Unknown operation 'force-start' when starting VDSM In-Reply-To: <60046984.1390646.1374179386173.JavaMail.root@redhat.com> Message-ID: <400931580.1394093.1374179913099.JavaMail.root@redhat.com> Engine is installed and working on a fresh laptop install of Fedora 19. Rebased ovirt-engine from gerrit/master this morning. Trying to install host on a fresh Fedora 19 VM -- I'm trying to get a nested host setup. Host installation fails with: Jul 18 16:24:52 ovirt-host-fedora-2 systemd[1]: Starting Virtual Desktop Server Manager... Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: Note: Forwarding request to 'systemctl disable libvirt-guests.service'. Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: vdsm: libvirt already configured for vdsm [ OK ] Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: Starting multipathd... Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: Redirecting to /bin/systemctl start multipathd.service Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: Redirecting to /bin/systemctl force-start iscsid.service Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: Unknown operation 'force-start'. Jul 18 16:24:53 ovirt-host-fedora-2 systemd[1]: vdsmd.service: control process exited, code=exited status=1 Jul 18 16:24:53 ovirt-host-fedora-2 systemd[1]: Failed to start Virtual Desktop Server Manager. Jul 18 16:24:53 ovirt-host-fedora-2 systemd[1]: Unit vdsmd.service entered failed state. I've never heard of force-start before, and googling for "fedora force-start" brings up this as the second result: https://ask.fedoraproject.org/question/27737/vdsmdservice-fails-bc-iscsid-is-started-using-force-start/ So someone else out there is having this problem too :) I'm pretty novice with systemd. Any ideas? Thanks, Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme at redhat.com From dougsland at redhat.com Fri Jul 19 02:25:08 2013 From: dougsland at redhat.com (Douglas Schilling Landgraf) Date: Thu, 18 Jul 2013 22:25:08 -0400 Subject: [Engine-devel] Unknown operation 'force-start' when starting VDSM In-Reply-To: <400931580.1394093.1374179913099.JavaMail.root@redhat.com> References: <400931580.1394093.1374179913099.JavaMail.root@redhat.com> Message-ID: <51E8A384.2050601@redhat.com> Hello Greg, On 07/18/2013 04:38 PM, Greg Sheremeta wrote: > Engine is installed and working on a fresh laptop install of Fedora 19. Rebased ovirt-engine from gerrit/master this morning. Trying to install host on a fresh Fedora 19 VM -- I'm trying to get a nested host setup. > > Host installation fails with: > > Jul 18 16:24:52 ovirt-host-fedora-2 systemd[1]: Starting Virtual Desktop Server Manager... > Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: Note: Forwarding request to 'systemctl disable libvirt-guests.service'. > Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: vdsm: libvirt already configured for vdsm [ OK ] > Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: Starting multipathd... > Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: Redirecting to /bin/systemctl start multipathd.service > Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: Redirecting to /bin/systemctl force-start iscsid.service > Jul 18 16:24:53 ovirt-host-fedora-2 systemd-vdsmd[3956]: Unknown operation 'force-start'. > Jul 18 16:24:53 ovirt-host-fedora-2 systemd[1]: vdsmd.service: control process exited, code=exited status=1 > Jul 18 16:24:53 ovirt-host-fedora-2 systemd[1]: Failed to start Virtual Desktop Server Manager. > Jul 18 16:24:53 ovirt-host-fedora-2 systemd[1]: Unit vdsmd.service entered failed state. > > I've never heard of force-start before, and googling for "fedora force-start" brings up this as the second result: > https://ask.fedoraproject.org/question/27737/vdsmdservice-fails-bc-iscsid-is-started-using-force-start/ > > So someone else out there is having this problem too :) > vdsm-4.10.3-18 should fix it. Please check: http://permalink.gmane.org/gmane.comp.emulators.ovirt.user/9488 -- Cheers Douglas From dougsland at redhat.com Sat Jul 20 07:42:38 2013 From: dougsland at redhat.com (Douglas Schilling Landgraf) Date: Sat, 20 Jul 2013 03:42:38 -0400 Subject: [Engine-devel] testDisplayPort - VmMapperTest Message-ID: <51EA3F6E.3090405@redhat.com> Hi, Anyone else failing on this unittest? $ make install-dev PREFIX="$HOME/ovirt-engine" BUILD_UT=1 Results : Tests in error: testDisplayPort(org.ovirt.engine.api.restapi.types.VmMapperTest) Tests run: 121, Failures: 0, Errors: 1, Skipped: 0 [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] ovirt-root ........................................ SUCCESS [0.443s] [INFO] oVirt Build Tools root ............................ SUCCESS [0.010s] [INFO] oVirt checkstyle .................................. SUCCESS [1.054s] [INFO] oVirt JBoss Modules Maven Plugin .................. SUCCESS [3.084s] [INFO] oVirt Checkstyle Checks ........................... SUCCESS [0.762s] [INFO] oVirt Modules - backend ........................... SUCCESS [0.004s] [INFO] oVirt Manager ..................................... SUCCESS [0.004s] [INFO] oVirt Engine dependencies ......................... SUCCESS [1.428s] [INFO] oVirt Modules - manager ........................... SUCCESS [0.466s] [INFO] CSharp Compatibility .............................. SUCCESS [2.694s] [INFO] Common Code ....................................... SUCCESS [10.024s] [INFO] Common utilities .................................. SUCCESS [19.154s] [INFO] Data Access Layer ................................. SUCCESS [7.966s] [INFO] engine scheduler bean ............................. SUCCESS [1.462s] [INFO] Vds broker ........................................ SUCCESS [7.028s] [INFO] Search Backend .................................... SUCCESS [2.866s] [INFO] Backend Logic @Service bean ....................... SUCCESS [28.853s] [INFO] oVirt RESTful API Backend Integration ............. SUCCESS [0.094s] [INFO] oVirt RESTful API interface ....................... SUCCESS [0.119s] [INFO] oVirt Engine API Definition ....................... SUCCESS [10.331s] [INFO] oVirt Engine API Commom Parent POM ................ SUCCESS [0.068s] [INFO] oVirt Engine API Common JAX-RS .................... SUCCESS [5.188s] [INFO] oVirt RESTful API Backend Integration Type Mappers FAILURE [1:49.300s] [INFO] oVirt RESTful API Backend Integration JAX-RS Resources SKIPPED [INFO] oVirt RESTful API Backend Integration Webapp ...... SKIPPED [INFO] oVirt Engine Web Root ............................. SKIPPED [INFO] oVirt Engine Tools ................................ SKIPPED [INFO] oVirt Modules :: Frontend ......................... SKIPPED [INFO] oVirt Modules :: Webadmin ......................... SKIPPED [INFO] oVirt Modules - ui ................................ SKIPPED [INFO] Extensions for GWT ................................ SKIPPED [INFO] UI Utils Compatibility (for UICommon) ............. SKIPPED [INFO] Frontend for GWT UI Projects ...................... SKIPPED [INFO] UICommonWeb ....................................... SKIPPED [INFO] oVirt GWT UI common infrastructure ................ SKIPPED [INFO] WebAdmin .......................................... SKIPPED [INFO] UserPortal ........................................ SKIPPED [INFO] oVirt Server EAR .................................. SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 3:33.247s [INFO] Finished at: Sat Jul 20 04:09:04 BRT 2013 [INFO] Final Memory: 165M/881M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.7.2:test (default-test) on project restapi-types: There are test failures. Thanks! -- Cheers Douglas From eedri at redhat.com Sat Jul 20 17:34:28 2013 From: eedri at redhat.com (Eyal Edri) Date: Sat, 20 Jul 2013 13:34:28 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <51E2BE99.2000409@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <502026617.1247179.1373373744620.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <1373532084.2489.25.camel@fdeutsch-laptop.local> <693107913.2226423.1373533051598.JavaMail.root@redhat.com> <51E2BE99.2000409@redhat.com> Message-ID: <810613569.3650942.1374341668497.JavaMail.root@redhat.com> OK, Rome wasn't built in a day. To move things forward, I propose we'll just improve current commit header template to include more relevant code areas [1], and start looking into mapping all code to the relevant components (either via renaming folders, adding a metadata file under each folder mapping the files/classnames/directory names or using automated tools like sonar) [1] instead of change to something like Eyal. ----- Original Message ----- > From: "Moran Goldboim" > To: "Eyal Edri" > Cc: "Fabian Deutsch" , "engine-devel" , "infra" > Sent: Sunday, July 14, 2013 6:07:05 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > On 07/11/2013 11:57 AM, Eyal Edri wrote: > > > > ----- Original Message ----- > >> From: "Fabian Deutsch" > >> To: "Eyal Edri" > >> Cc: "Alon Bar-Lev" , "engine-devel" > >> , "infra" > >> Sent: Thursday, July 11, 2013 11:41:24 AM > >> Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > >> commits > >> > >> Am Mittwoch, den 10.07.2013, 15:27 -0400 schrieb Eyal Edri: > >>> ----- Original Message ----- > >>>> From: "Fabian Deutsch" > >>>> To: "Alon Bar-Lev" > >>>> Cc: "engine-devel" , "infra" > >>>> Sent: Tuesday, July 9, 2013 3:54:06 PM > >>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > >>>> engine > >>>> commits > >>>> > >>>> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Yair Zaslavsky" > >>>>>> To: "Alon Bar-Lev" > >>>>>> Cc: "Eyal Edri" , "engine-devel" > >>>>> , "infra" > >>>>>> Sent: Tuesday, July 9, 2013 3:42:24 PM > >>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > >>>>> engine commits > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Alon Bar-Lev" > >>>>>>> To: "Eyal Edri" > >>>>>>> Cc: "engine-devel" , "infra" > >>>>> > >>>>>>> Sent: Tuesday, July 9, 2013 3:33:57 PM > >>>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > >>>>> engine > >>>>>>> commits > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> From: "Eyal Edri" > >>>>>>>> To: "engine-devel" > >>>>>>>> Cc: "infra" > >>>>>>>> Sent: Tuesday, July 9, 2013 12:38:51 PM > >>>>>>>> Subject: Proposal for new commit msg design for engine commits > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> You all probably know and familiar with 'ovirt-engine' git hook > >>>>> for > >>>>>>>> commit > >>>>>>>> msg template [1]. > >>>>>>>> this helps understand the general area of the patch in the > >>>>> project but it > >>>>>>>> lacks additional info that might > >>>>>>>> be valuable for scaling automatic tests in Jenkins CI. > >>>>>>>> > >>>>>>>> Let me explain: > >>>>>>>> > >>>>>>>> Infra team is working hard on expanding oVirt CI infrastructure > >>>>> and > >>>>>>>> adding > >>>>>>>> more tests in jenkins (per commit/patch). > >>>>>>>> Adding important meta-data per patch can significatly improve > >>>>> the ability > >>>>>>>> to > >>>>>>>> run specific tests for each patch/commit, > >>>>>>>> and not waste valuable resources on Jenkins jobs that are not > >>>>> relevant to > >>>>>>>> the > >>>>>>>> code in the patch. > >>>>>>>> > >>>>>>>> So the idea is to add/expand current metadata per patch, in the > >>>>> form of: > >>>>>>>> (either) > >>>>>>>> 1. expanding current header template to include more data like > >>>>> 'network' > >>>>>>>> , > >>>>>>>> 'setup', 'tools', 'virt' > >>>>>>> Please do not expand header, it is too short anyway. > >>>>>>> > >>>>>>>> 2. adding a new label with relevant tags for the patch, called > >>>>> e.g > >>>>>>>> 'METADATA: network, rest, virt' > >>>>>>> Having: > >>>>>>> > >>>>>>> CI-Tests: xxx > >>>>>>> CI-Tests: yyy > >>>>>>> CI-Tests: zzz > >>>>>>> > >>>>>>> Is much better. > >>>>>> I'm not sure we should have CI-Test - as we might use this for > >>>>> something else > >>>>>> besides CI. > >>>>>> Region_of_Interest as Dan suggests sounds better IMHO. > >>>>> I don't care how this is to be called. > >>>>> However, I do not think that commit message is the place for > >>>>> instructing CI to do anything. > >>>>> Commit message stays for good, it should contain information that is > >>>>> required a year from now. > >>>>> It has nothing to do with tests and such. > >>>> I agree with Alon here that the Ci informations don't belong in the > >>>> commit msg. > >>>> My opinion is that a testcase should know what it covers. This > >>>> information from the testcase can then be used by any party to determin > >>>> if the testcase should be run on a specific commit (which yields > >>>> informations about the changed paths, files, owner, author, etc ... > >>>> which might be valuable). > >>> i think you're missing the point here. > >>> can you explain how do you propose a test case will know "what it > >>> covers"? > >>> > >>> let's take an example: > >>> let's say a new commit comes from ovirt-engine: > >>> http://gerrit.ovirt.org/#/c/16668/ > >>> commit msg: "core: Use images instead of volumes at CDA message". > >>> > >>> now you have 1000 test cases (could be system or functional test). > >>> (let's assume that your infra can't support running 1000 tests per > >>> patch/commit). > >>> > >>> Some of these test suits checks network flow, some virt > >>> (migration/template > >>> for e.g), some host install, others storage flows and so on... ). > >>> you have one repo to clone (ovirt-engine, let's keep vdsm a side for a > >>> min), and to compile the project from for the tests. > >>> > >>> now given this scenario, please explain how will you know which test from > >>> the 1000 you have you'll run on it. > >>> do you believe that according to the author/path/filename you'll know if > >>> that patch involves storage or virt scenario? > >> Hey Eyal, > >> > >> Yes - I would at least give it a try to decide automagically what tests > >> to run by looking at the change. > >> The main motivation for this is to not add another things which the > >> committer needs to take care of and IMO we humans tend to fail (at some > >> point) on those boring tasks like adding correct metadata (let it be a > >> typo or just not adding the correct testsuites/topis to be run). > > this process can be fully automatic via gerrit hooks & templates: > > > > typos or mistakes can be easily handles by gerrit hooks to help the > > committer fix the tags. > > as mentions previously, this logic can be done by the project maintainer > > and enforced by a template or hook. > > > > so for example - if someone writes a patch with patch header > > "webadmin:...." , > > then the tags he'll get to choose from are only relevant to ui/ux. > > > > so the only task a committer will have to do is to verify the default tags > > are relevant. > > > > i don't believe this is too much to ask for, considering the huge benefit > > that we'll get > > (stable code, less bugs, less ci breakage, mapping of specific code to > > relevant topic, statistics.. etc..) > > > >> But let's get back to your example. > >> Basically we can use the path and filename to determin what testsuite to > >> run. > >> Testsuites could be bound to paths and/or filenames and/or regexes being > >> matched against the full filename. > >> Another approach would be to use a java package dependency tree to > >> determine which classes are directly and indirectly affected by a > >> change. This information can then be used to also build a set of > >> testsuites to be run. For example: > >> World uses Ocean uses Wale uses Cell - if Wale changes, we'll surely > >> want to run the testsuites assigned to the classes higher up in the > >> dependency chain (World and Ocean). > >> > >> For the concrete example above: Maybe there is a spell checker testcase > >> which could be bound to the filename glob pattern *.properties. > >> > >>> i don't think there's an alternative to a metadata to assist mapping the > >>> patch to a relevant "topic" in the code. > >>> whether it exists as a git note or a label in the commit, that's another > >>> matter and probably less important. > >> The idea is to use the path/filename and dependency tree information to > >> model these topics. Example: > >> WaterTestsuite(Topic): > >> regex_in_change: .*\.fish > >> glob_in_change: src/classes/ocean/*.java > >> path_in_change: src/classes/water.java > >> change_affects_depency_of: WaterClass > > I'm not familiar that much with the names of the classes and filenames, but > > it sounds to me like an error prone process > > and very complex to start going through all the classes and file names and > > mapping them to a certain project/component. > > sounds like we'll have to enforce a naming convention for every new > > file/path/class name that won't break that magic > > detection. > > > > sure there are exceptions that will work probably, like "anything under > > packaging/, should trigger the 'engine-setup' or 'engine-upgrade' tests, > > but imo, it is not so easy with other components. > > > > if something will help, it will be splitting up ovirt-engine into subject > > projects (different git) > > > > Eyal. > > I think some valid points were raised in this thread, and I feel we all > agree regarding the need for such a mechanism. > regarding mapping of different areas in the code using metadata, i think > this approach worth trying, it'll increase ownership and area of > responsibility within our code and hopefully provide us the > functionality we are looking for. > we can start doing the obvious mapping, after-which the responsibility > of each team/maintainer to assign a file to a person and define the > specific functional areas in it. > > Moran. > > > > >> But surely labels or meta-data in the commit msg are quicker to > >> implement. > >> > >> - fabian > >> > >>> eyal. > >>> > >>>> - fabian > >>>> > >>>> _______________________________________________ > >>>> Engine-devel mailing list > >>>> Engine-devel at ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>> > >> > >> > > _______________________________________________ > > Infra mailing list > > Infra at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > From alonbl at redhat.com Sat Jul 20 18:34:13 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 20 Jul 2013 14:34:13 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <810613569.3650942.1374341668497.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <1808737135.614105.1373374176266.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <1373532084.2489.25.camel@fdeutsch-laptop.local> <693107913.2226423.1373533051598.JavaMail.root@redhat.com> <51E2BE99.2000409@redhat.com> <810613569.3650942.1374341668497.JavaMail.root@redhat.com> Message-ID: <2098403304.1846523.1374345253818.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eyal Edri" > To: "infra" > Cc: "engine-devel" , "Fabian Deutsch" > Sent: Saturday, July 20, 2013 8:34:28 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > OK, Rome wasn't built in a day. > > To move things forward, > I propose we'll just improve current commit header template to include more > relevant code > areas [1], and start looking into mapping all code to the relevant components > (either via renaming folders, adding a metadata file under each folder > mapping the files/classnames/directory names or using automated tools like > sonar) Again, and I am sorry, but I disagree of any relationship between commit message and CI. It will be simple to add metadata to sources, and have CI run tests based on actual source change thus probable impact, this way we won't be exposed to human errors, nor make commit message unusable for actual history. All we need is someone to take ownership of the task of adding metadata to source tree. As I proposed this can be either within every source using special signature, or can be in a directory at special file, for example .ovirt-metadata, and have the mapping between source component to relevant tests at a simple text file at source root. Regards, Alon Bar-Lev. > > [1] instead of userportal | webadmin> > change to something like | network | storage | virt | packaging> > > Eyal. > > ----- Original Message ----- > > From: "Moran Goldboim" > > To: "Eyal Edri" > > Cc: "Fabian Deutsch" , "engine-devel" > > , "infra" > > Sent: Sunday, July 14, 2013 6:07:05 PM > > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > > commits > > > > On 07/11/2013 11:57 AM, Eyal Edri wrote: > > > > > > ----- Original Message ----- > > >> From: "Fabian Deutsch" > > >> To: "Eyal Edri" > > >> Cc: "Alon Bar-Lev" , "engine-devel" > > >> , "infra" > > >> Sent: Thursday, July 11, 2013 11:41:24 AM > > >> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > >> engine > > >> commits > > >> > > >> Am Mittwoch, den 10.07.2013, 15:27 -0400 schrieb Eyal Edri: > > >>> ----- Original Message ----- > > >>>> From: "Fabian Deutsch" > > >>>> To: "Alon Bar-Lev" > > >>>> Cc: "engine-devel" , "infra" > > >>>> Sent: Tuesday, July 9, 2013 3:54:06 PM > > >>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > >>>> engine > > >>>> commits > > >>>> > > >>>> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>>> From: "Yair Zaslavsky" > > >>>>>> To: "Alon Bar-Lev" > > >>>>>> Cc: "Eyal Edri" , "engine-devel" > > >>>>> , "infra" > > >>>>>> Sent: Tuesday, July 9, 2013 3:42:24 PM > > >>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > >>>>> engine commits > > >>>>>> > > >>>>>> > > >>>>>> ----- Original Message ----- > > >>>>>>> From: "Alon Bar-Lev" > > >>>>>>> To: "Eyal Edri" > > >>>>>>> Cc: "engine-devel" , "infra" > > >>>>> > > >>>>>>> Sent: Tuesday, July 9, 2013 3:33:57 PM > > >>>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > >>>>> engine > > >>>>>>> commits > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> ----- Original Message ----- > > >>>>>>>> From: "Eyal Edri" > > >>>>>>>> To: "engine-devel" > > >>>>>>>> Cc: "infra" > > >>>>>>>> Sent: Tuesday, July 9, 2013 12:38:51 PM > > >>>>>>>> Subject: Proposal for new commit msg design for engine commits > > >>>>>>>> > > >>>>>>>> Hi, > > >>>>>>>> > > >>>>>>>> You all probably know and familiar with 'ovirt-engine' git hook > > >>>>> for > > >>>>>>>> commit > > >>>>>>>> msg template [1]. > > >>>>>>>> this helps understand the general area of the patch in the > > >>>>> project but it > > >>>>>>>> lacks additional info that might > > >>>>>>>> be valuable for scaling automatic tests in Jenkins CI. > > >>>>>>>> > > >>>>>>>> Let me explain: > > >>>>>>>> > > >>>>>>>> Infra team is working hard on expanding oVirt CI infrastructure > > >>>>> and > > >>>>>>>> adding > > >>>>>>>> more tests in jenkins (per commit/patch). > > >>>>>>>> Adding important meta-data per patch can significatly improve > > >>>>> the ability > > >>>>>>>> to > > >>>>>>>> run specific tests for each patch/commit, > > >>>>>>>> and not waste valuable resources on Jenkins jobs that are not > > >>>>> relevant to > > >>>>>>>> the > > >>>>>>>> code in the patch. > > >>>>>>>> > > >>>>>>>> So the idea is to add/expand current metadata per patch, in the > > >>>>> form of: > > >>>>>>>> (either) > > >>>>>>>> 1. expanding current header template to include more data like > > >>>>> 'network' > > >>>>>>>> , > > >>>>>>>> 'setup', 'tools', 'virt' > > >>>>>>> Please do not expand header, it is too short anyway. > > >>>>>>> > > >>>>>>>> 2. adding a new label with relevant tags for the patch, called > > >>>>> e.g > > >>>>>>>> 'METADATA: network, rest, virt' > > >>>>>>> Having: > > >>>>>>> > > >>>>>>> CI-Tests: xxx > > >>>>>>> CI-Tests: yyy > > >>>>>>> CI-Tests: zzz > > >>>>>>> > > >>>>>>> Is much better. > > >>>>>> I'm not sure we should have CI-Test - as we might use this for > > >>>>> something else > > >>>>>> besides CI. > > >>>>>> Region_of_Interest as Dan suggests sounds better IMHO. > > >>>>> I don't care how this is to be called. > > >>>>> However, I do not think that commit message is the place for > > >>>>> instructing CI to do anything. > > >>>>> Commit message stays for good, it should contain information that is > > >>>>> required a year from now. > > >>>>> It has nothing to do with tests and such. > > >>>> I agree with Alon here that the Ci informations don't belong in the > > >>>> commit msg. > > >>>> My opinion is that a testcase should know what it covers. This > > >>>> information from the testcase can then be used by any party to > > >>>> determin > > >>>> if the testcase should be run on a specific commit (which yields > > >>>> informations about the changed paths, files, owner, author, etc ... > > >>>> which might be valuable). > > >>> i think you're missing the point here. > > >>> can you explain how do you propose a test case will know "what it > > >>> covers"? > > >>> > > >>> let's take an example: > > >>> let's say a new commit comes from ovirt-engine: > > >>> http://gerrit.ovirt.org/#/c/16668/ > > >>> commit msg: "core: Use images instead of volumes at CDA message". > > >>> > > >>> now you have 1000 test cases (could be system or functional test). > > >>> (let's assume that your infra can't support running 1000 tests per > > >>> patch/commit). > > >>> > > >>> Some of these test suits checks network flow, some virt > > >>> (migration/template > > >>> for e.g), some host install, others storage flows and so on... ). > > >>> you have one repo to clone (ovirt-engine, let's keep vdsm a side for a > > >>> min), and to compile the project from for the tests. > > >>> > > >>> now given this scenario, please explain how will you know which test > > >>> from > > >>> the 1000 you have you'll run on it. > > >>> do you believe that according to the author/path/filename you'll know > > >>> if > > >>> that patch involves storage or virt scenario? > > >> Hey Eyal, > > >> > > >> Yes - I would at least give it a try to decide automagically what tests > > >> to run by looking at the change. > > >> The main motivation for this is to not add another things which the > > >> committer needs to take care of and IMO we humans tend to fail (at some > > >> point) on those boring tasks like adding correct metadata (let it be a > > >> typo or just not adding the correct testsuites/topis to be run). > > > this process can be fully automatic via gerrit hooks & templates: > > > > > > typos or mistakes can be easily handles by gerrit hooks to help the > > > committer fix the tags. > > > as mentions previously, this logic can be done by the project maintainer > > > and enforced by a template or hook. > > > > > > so for example - if someone writes a patch with patch header > > > "webadmin:...." , > > > then the tags he'll get to choose from are only relevant to ui/ux. > > > > > > so the only task a committer will have to do is to verify the default > > > tags > > > are relevant. > > > > > > i don't believe this is too much to ask for, considering the huge benefit > > > that we'll get > > > (stable code, less bugs, less ci breakage, mapping of specific code to > > > relevant topic, statistics.. etc..) > > > > > >> But let's get back to your example. > > >> Basically we can use the path and filename to determin what testsuite to > > >> run. > > >> Testsuites could be bound to paths and/or filenames and/or regexes being > > >> matched against the full filename. > > >> Another approach would be to use a java package dependency tree to > > >> determine which classes are directly and indirectly affected by a > > >> change. This information can then be used to also build a set of > > >> testsuites to be run. For example: > > >> World uses Ocean uses Wale uses Cell - if Wale changes, we'll surely > > >> want to run the testsuites assigned to the classes higher up in the > > >> dependency chain (World and Ocean). > > >> > > >> For the concrete example above: Maybe there is a spell checker testcase > > >> which could be bound to the filename glob pattern *.properties. > > >> > > >>> i don't think there's an alternative to a metadata to assist mapping > > >>> the > > >>> patch to a relevant "topic" in the code. > > >>> whether it exists as a git note or a label in the commit, that's > > >>> another > > >>> matter and probably less important. > > >> The idea is to use the path/filename and dependency tree information to > > >> model these topics. Example: > > >> WaterTestsuite(Topic): > > >> regex_in_change: .*\.fish > > >> glob_in_change: src/classes/ocean/*.java > > >> path_in_change: src/classes/water.java > > >> change_affects_depency_of: WaterClass > > > I'm not familiar that much with the names of the classes and filenames, > > > but > > > it sounds to me like an error prone process > > > and very complex to start going through all the classes and file names > > > and > > > mapping them to a certain project/component. > > > sounds like we'll have to enforce a naming convention for every new > > > file/path/class name that won't break that magic > > > detection. > > > > > > sure there are exceptions that will work probably, like "anything under > > > packaging/, should trigger the 'engine-setup' or 'engine-upgrade' tests, > > > but imo, it is not so easy with other components. > > > > > > if something will help, it will be splitting up ovirt-engine into subject > > > projects (different git) > > > > > > Eyal. > > > > I think some valid points were raised in this thread, and I feel we all > > agree regarding the need for such a mechanism. > > regarding mapping of different areas in the code using metadata, i think > > this approach worth trying, it'll increase ownership and area of > > responsibility within our code and hopefully provide us the > > functionality we are looking for. > > we can start doing the obvious mapping, after-which the responsibility > > of each team/maintainer to assign a file to a person and define the > > specific functional areas in it. > > > > Moran. > > > > > > > >> But surely labels or meta-data in the commit msg are quicker to > > >> implement. > > >> > > >> - fabian > > >> > > >>> eyal. > > >>> > > >>>> - fabian > > >>>> > > >>>> _______________________________________________ > > >>>> Engine-devel mailing list > > >>>> Engine-devel at ovirt.org > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > >>>> > > >> > > >> > > > _______________________________________________ > > > Infra mailing list > > > Infra at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From eedri at redhat.com Sat Jul 20 18:41:56 2013 From: eedri at redhat.com (Eyal Edri) Date: Sat, 20 Jul 2013 14:41:56 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <2098403304.1846523.1374345253818.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <1373374446.2593.2.camel@fdeutsch-laptop.local> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <1373532084.2489.25.camel@fdeutsch-laptop.local> <693107913.2226423.1373533051598.JavaMail.root@redhat.com> <51E2BE99.2000409@redhat.com> <810613569.3650942.1374341668497.JavaMail.root@redhat.com> <2098403304.1846523.1374345253818.JavaMail.root@redhat.com> Message-ID: <1896814509.3653314.1374345716481.JavaMail.root@redhat.com> This change to commit template has nothing to do with CI. it's a change that should reflect updated components relevance to the commit code. Nevertheless, i have no problems with your suggestions for metadata per directory to map all ovirt code. any suggestion how to push it forward? Eyal. ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Eyal Edri" > Cc: "infra" , "engine-devel" , "Fabian Deutsch" > Sent: Saturday, July 20, 2013 9:34:13 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > > > ----- Original Message ----- > > From: "Eyal Edri" > > To: "infra" > > Cc: "engine-devel" , "Fabian Deutsch" > > > > Sent: Saturday, July 20, 2013 8:34:28 PM > > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > > commits > > > > OK, Rome wasn't built in a day. > > > > To move things forward, > > I propose we'll just improve current commit header template to include more > > relevant code > > areas [1], and start looking into mapping all code to the relevant > > components > > (either via renaming folders, adding a metadata file under each folder > > mapping the files/classnames/directory names or using automated tools like > > sonar) > > Again, and I am sorry, but I disagree of any relationship between commit > message and CI. > > It will be simple to add metadata to sources, and have CI run tests based on > actual source change thus probable impact, this way we won't be exposed to > human errors, nor make commit message unusable for actual history. > > All we need is someone to take ownership of the task of adding metadata to > source tree. > > As I proposed this can be either within every source using special signature, > or can be in a directory at special file, for example .ovirt-metadata, and > have the mapping between source component to relevant tests at a simple text > file at source root. > > Regards, > Alon Bar-Lev. > > > > > [1] instead of > userportal | webadmin> > > change to something like > webadmin > > | network | storage | virt | packaging> > > > > Eyal. > > > > ----- Original Message ----- > > > From: "Moran Goldboim" > > > To: "Eyal Edri" > > > Cc: "Fabian Deutsch" , "engine-devel" > > > , "infra" > > > Sent: Sunday, July 14, 2013 6:07:05 PM > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > > > commits > > > > > > On 07/11/2013 11:57 AM, Eyal Edri wrote: > > > > > > > > ----- Original Message ----- > > > >> From: "Fabian Deutsch" > > > >> To: "Eyal Edri" > > > >> Cc: "Alon Bar-Lev" , "engine-devel" > > > >> , "infra" > > > >> Sent: Thursday, July 11, 2013 11:41:24 AM > > > >> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > > >> engine > > > >> commits > > > >> > > > >> Am Mittwoch, den 10.07.2013, 15:27 -0400 schrieb Eyal Edri: > > > >>> ----- Original Message ----- > > > >>>> From: "Fabian Deutsch" > > > >>>> To: "Alon Bar-Lev" > > > >>>> Cc: "engine-devel" , "infra" > > > >>>> > > > >>>> Sent: Tuesday, July 9, 2013 3:54:06 PM > > > >>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > > >>>> engine > > > >>>> commits > > > >>>> > > > >>>> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > > > >>>>> > > > >>>>> ----- Original Message ----- > > > >>>>>> From: "Yair Zaslavsky" > > > >>>>>> To: "Alon Bar-Lev" > > > >>>>>> Cc: "Eyal Edri" , "engine-devel" > > > >>>>> , "infra" > > > >>>>>> Sent: Tuesday, July 9, 2013 3:42:24 PM > > > >>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > > >>>>> engine commits > > > >>>>>> > > > >>>>>> > > > >>>>>> ----- Original Message ----- > > > >>>>>>> From: "Alon Bar-Lev" > > > >>>>>>> To: "Eyal Edri" > > > >>>>>>> Cc: "engine-devel" , "infra" > > > >>>>> > > > >>>>>>> Sent: Tuesday, July 9, 2013 3:33:57 PM > > > >>>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design > > > >>>>>>> for > > > >>>>> engine > > > >>>>>>> commits > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> ----- Original Message ----- > > > >>>>>>>> From: "Eyal Edri" > > > >>>>>>>> To: "engine-devel" > > > >>>>>>>> Cc: "infra" > > > >>>>>>>> Sent: Tuesday, July 9, 2013 12:38:51 PM > > > >>>>>>>> Subject: Proposal for new commit msg design for engine commits > > > >>>>>>>> > > > >>>>>>>> Hi, > > > >>>>>>>> > > > >>>>>>>> You all probably know and familiar with 'ovirt-engine' git hook > > > >>>>> for > > > >>>>>>>> commit > > > >>>>>>>> msg template [1]. > > > >>>>>>>> this helps understand the general area of the patch in the > > > >>>>> project but it > > > >>>>>>>> lacks additional info that might > > > >>>>>>>> be valuable for scaling automatic tests in Jenkins CI. > > > >>>>>>>> > > > >>>>>>>> Let me explain: > > > >>>>>>>> > > > >>>>>>>> Infra team is working hard on expanding oVirt CI infrastructure > > > >>>>> and > > > >>>>>>>> adding > > > >>>>>>>> more tests in jenkins (per commit/patch). > > > >>>>>>>> Adding important meta-data per patch can significatly improve > > > >>>>> the ability > > > >>>>>>>> to > > > >>>>>>>> run specific tests for each patch/commit, > > > >>>>>>>> and not waste valuable resources on Jenkins jobs that are not > > > >>>>> relevant to > > > >>>>>>>> the > > > >>>>>>>> code in the patch. > > > >>>>>>>> > > > >>>>>>>> So the idea is to add/expand current metadata per patch, in the > > > >>>>> form of: > > > >>>>>>>> (either) > > > >>>>>>>> 1. expanding current header template to include more data like > > > >>>>> 'network' > > > >>>>>>>> , > > > >>>>>>>> 'setup', 'tools', 'virt' > > > >>>>>>> Please do not expand header, it is too short anyway. > > > >>>>>>> > > > >>>>>>>> 2. adding a new label with relevant tags for the patch, called > > > >>>>> e.g > > > >>>>>>>> 'METADATA: network, rest, virt' > > > >>>>>>> Having: > > > >>>>>>> > > > >>>>>>> CI-Tests: xxx > > > >>>>>>> CI-Tests: yyy > > > >>>>>>> CI-Tests: zzz > > > >>>>>>> > > > >>>>>>> Is much better. > > > >>>>>> I'm not sure we should have CI-Test - as we might use this for > > > >>>>> something else > > > >>>>>> besides CI. > > > >>>>>> Region_of_Interest as Dan suggests sounds better IMHO. > > > >>>>> I don't care how this is to be called. > > > >>>>> However, I do not think that commit message is the place for > > > >>>>> instructing CI to do anything. > > > >>>>> Commit message stays for good, it should contain information that > > > >>>>> is > > > >>>>> required a year from now. > > > >>>>> It has nothing to do with tests and such. > > > >>>> I agree with Alon here that the Ci informations don't belong in the > > > >>>> commit msg. > > > >>>> My opinion is that a testcase should know what it covers. This > > > >>>> information from the testcase can then be used by any party to > > > >>>> determin > > > >>>> if the testcase should be run on a specific commit (which yields > > > >>>> informations about the changed paths, files, owner, author, etc ... > > > >>>> which might be valuable). > > > >>> i think you're missing the point here. > > > >>> can you explain how do you propose a test case will know "what it > > > >>> covers"? > > > >>> > > > >>> let's take an example: > > > >>> let's say a new commit comes from ovirt-engine: > > > >>> http://gerrit.ovirt.org/#/c/16668/ > > > >>> commit msg: "core: Use images instead of volumes at CDA message". > > > >>> > > > >>> now you have 1000 test cases (could be system or functional test). > > > >>> (let's assume that your infra can't support running 1000 tests per > > > >>> patch/commit). > > > >>> > > > >>> Some of these test suits checks network flow, some virt > > > >>> (migration/template > > > >>> for e.g), some host install, others storage flows and so on... ). > > > >>> you have one repo to clone (ovirt-engine, let's keep vdsm a side for > > > >>> a > > > >>> min), and to compile the project from for the tests. > > > >>> > > > >>> now given this scenario, please explain how will you know which test > > > >>> from > > > >>> the 1000 you have you'll run on it. > > > >>> do you believe that according to the author/path/filename you'll know > > > >>> if > > > >>> that patch involves storage or virt scenario? > > > >> Hey Eyal, > > > >> > > > >> Yes - I would at least give it a try to decide automagically what > > > >> tests > > > >> to run by looking at the change. > > > >> The main motivation for this is to not add another things which the > > > >> committer needs to take care of and IMO we humans tend to fail (at > > > >> some > > > >> point) on those boring tasks like adding correct metadata (let it be a > > > >> typo or just not adding the correct testsuites/topis to be run). > > > > this process can be fully automatic via gerrit hooks & templates: > > > > > > > > typos or mistakes can be easily handles by gerrit hooks to help the > > > > committer fix the tags. > > > > as mentions previously, this logic can be done by the project > > > > maintainer > > > > and enforced by a template or hook. > > > > > > > > so for example - if someone writes a patch with patch header > > > > "webadmin:...." , > > > > then the tags he'll get to choose from are only relevant to ui/ux. > > > > > > > > so the only task a committer will have to do is to verify the default > > > > tags > > > > are relevant. > > > > > > > > i don't believe this is too much to ask for, considering the huge > > > > benefit > > > > that we'll get > > > > (stable code, less bugs, less ci breakage, mapping of specific code to > > > > relevant topic, statistics.. etc..) > > > > > > > >> But let's get back to your example. > > > >> Basically we can use the path and filename to determin what testsuite > > > >> to > > > >> run. > > > >> Testsuites could be bound to paths and/or filenames and/or regexes > > > >> being > > > >> matched against the full filename. > > > >> Another approach would be to use a java package dependency tree to > > > >> determine which classes are directly and indirectly affected by a > > > >> change. This information can then be used to also build a set of > > > >> testsuites to be run. For example: > > > >> World uses Ocean uses Wale uses Cell - if Wale changes, we'll surely > > > >> want to run the testsuites assigned to the classes higher up in the > > > >> dependency chain (World and Ocean). > > > >> > > > >> For the concrete example above: Maybe there is a spell checker > > > >> testcase > > > >> which could be bound to the filename glob pattern *.properties. > > > >> > > > >>> i don't think there's an alternative to a metadata to assist mapping > > > >>> the > > > >>> patch to a relevant "topic" in the code. > > > >>> whether it exists as a git note or a label in the commit, that's > > > >>> another > > > >>> matter and probably less important. > > > >> The idea is to use the path/filename and dependency tree information > > > >> to > > > >> model these topics. Example: > > > >> WaterTestsuite(Topic): > > > >> regex_in_change: .*\.fish > > > >> glob_in_change: src/classes/ocean/*.java > > > >> path_in_change: src/classes/water.java > > > >> change_affects_depency_of: WaterClass > > > > I'm not familiar that much with the names of the classes and filenames, > > > > but > > > > it sounds to me like an error prone process > > > > and very complex to start going through all the classes and file names > > > > and > > > > mapping them to a certain project/component. > > > > sounds like we'll have to enforce a naming convention for every new > > > > file/path/class name that won't break that magic > > > > detection. > > > > > > > > sure there are exceptions that will work probably, like "anything under > > > > packaging/, should trigger the 'engine-setup' or 'engine-upgrade' > > > > tests, > > > > but imo, it is not so easy with other components. > > > > > > > > if something will help, it will be splitting up ovirt-engine into > > > > subject > > > > projects (different git) > > > > > > > > Eyal. > > > > > > I think some valid points were raised in this thread, and I feel we all > > > agree regarding the need for such a mechanism. > > > regarding mapping of different areas in the code using metadata, i think > > > this approach worth trying, it'll increase ownership and area of > > > responsibility within our code and hopefully provide us the > > > functionality we are looking for. > > > we can start doing the obvious mapping, after-which the responsibility > > > of each team/maintainer to assign a file to a person and define the > > > specific functional areas in it. > > > > > > Moran. > > > > > > > > > > >> But surely labels or meta-data in the commit msg are quicker to > > > >> implement. > > > >> > > > >> - fabian > > > >> > > > >>> eyal. > > > >>> > > > >>>> - fabian > > > >>>> > > > >>>> _______________________________________________ > > > >>>> Engine-devel mailing list > > > >>>> Engine-devel at ovirt.org > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > >>>> > > > >> > > > >> > > > > _______________________________________________ > > > > Infra mailing list > > > > Infra at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > From alonbl at redhat.com Sat Jul 20 18:53:06 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 20 Jul 2013 14:53:06 -0400 (EDT) Subject: [Engine-devel] Proposal for new commit msg design for engine commits In-Reply-To: <1896814509.3653314.1374345716481.JavaMail.root@redhat.com> References: <472371407.1023948.1373362731769.JavaMail.root@redhat.com> <1936482116.2031097.1373484420937.JavaMail.root@redhat.com> <1373532084.2489.25.camel@fdeutsch-laptop.local> <693107913.2226423.1373533051598.JavaMail.root@redhat.com> <51E2BE99.2000409@redhat.com> <810613569.3650942.1374341668497.JavaMail.root@redhat.com> <2098403304.1846523.1374345253818.JavaMail.root@redhat.com> <1896814509.3653314.1374345716481.JavaMail.root@redhat.com> Message-ID: <427928074.1846704.1374346386818.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Eyal Edri" > To: "Alon Bar-Lev" > Cc: "infra" , "engine-devel" , "Fabian Deutsch" > Sent: Saturday, July 20, 2013 9:41:56 PM > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits > > This change to commit template has nothing to do with CI. > it's a change that should reflect updated components relevance to the commit > code. This commit template is mostly invalid, as touching more than one 'subsystem' is possible, and has not enough granularity. For example, database change should trigger what? Infra change should trigger what? A change of both user interface and command should trigger what? So you end up with: userportal: storage: core: db: some message Just to make who happy? And maybe there are 50 tests of network, and you need only 5 of them for the specific change, how do you mark it, so now a developer need to know any test? what if you add one tomorrow which is relevant to a similar change? how do you inform the developer that now he needs 6? Why should it be the developer responsibility and not the quality ensuring engineer responsibility to determine which tests should run and when? As far as this template was not actually used for anything but humans, it was not that important, but once you formalize it as an interface, I step forward and state that the subject line is not the right tool for the task at hand (or any for this matter). The fact that you have in each commit are the sources that are modified, all the other data is just plain noise. From the sources that are modified you should be able to derive a test plan with high chance that this test program will be correct. Human intervention should be possible by ordering special tests that are outside of the standard policy, for cases in which the standard policy of deriving tests from sources is too narrow. Regards, Alon > > Nevertheless, i have no problems with your suggestions for metadata per > directory to map all ovirt code. > any suggestion how to push it forward? > > Eyal. > > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Eyal Edri" > > Cc: "infra" , "engine-devel" , > > "Fabian Deutsch" > > Sent: Saturday, July 20, 2013 9:34:13 PM > > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > > commits > > > > > > > > ----- Original Message ----- > > > From: "Eyal Edri" > > > To: "infra" > > > Cc: "engine-devel" , "Fabian Deutsch" > > > > > > Sent: Saturday, July 20, 2013 8:34:28 PM > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for engine > > > commits > > > > > > OK, Rome wasn't built in a day. > > > > > > To move things forward, > > > I propose we'll just improve current commit header template to include > > > more > > > relevant code > > > areas [1], and start looking into mapping all code to the relevant > > > components > > > (either via renaming folders, adding a metadata file under each folder > > > mapping the files/classnames/directory names or using automated tools > > > like > > > sonar) > > > > Again, and I am sorry, but I disagree of any relationship between commit > > message and CI. > > > > It will be simple to add metadata to sources, and have CI run tests based > > on > > actual source change thus probable impact, this way we won't be exposed to > > human errors, nor make commit message unusable for actual history. > > > > All we need is someone to take ownership of the task of adding metadata to > > source tree. > > > > As I proposed this can be either within every source using special > > signature, > > or can be in a directory at special file, for example .ovirt-metadata, and > > have the mapping between source component to relevant tests at a simple > > text > > file at source root. > > > > Regards, > > Alon Bar-Lev. > > > > > > > > [1] instead of > > userportal | webadmin> > > > change to something like > > webadmin > > > | network | storage | virt | packaging> > > > > > > Eyal. > > > > > > ----- Original Message ----- > > > > From: "Moran Goldboim" > > > > To: "Eyal Edri" > > > > Cc: "Fabian Deutsch" , "engine-devel" > > > > , "infra" > > > > Sent: Sunday, July 14, 2013 6:07:05 PM > > > > Subject: Re: [Engine-devel] Proposal for new commit msg design for > > > > engine > > > > commits > > > > > > > > On 07/11/2013 11:57 AM, Eyal Edri wrote: > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Fabian Deutsch" > > > > >> To: "Eyal Edri" > > > > >> Cc: "Alon Bar-Lev" , "engine-devel" > > > > >> , "infra" > > > > >> Sent: Thursday, July 11, 2013 11:41:24 AM > > > > >> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > > > >> engine > > > > >> commits > > > > >> > > > > >> Am Mittwoch, den 10.07.2013, 15:27 -0400 schrieb Eyal Edri: > > > > >>> ----- Original Message ----- > > > > >>>> From: "Fabian Deutsch" > > > > >>>> To: "Alon Bar-Lev" > > > > >>>> Cc: "engine-devel" , "infra" > > > > >>>> > > > > >>>> Sent: Tuesday, July 9, 2013 3:54:06 PM > > > > >>>> Subject: Re: [Engine-devel] Proposal for new commit msg design for > > > > >>>> engine > > > > >>>> commits > > > > >>>> > > > > >>>> Am Dienstag, den 09.07.2013, 08:49 -0400 schrieb Alon Bar-Lev: > > > > >>>>> > > > > >>>>> ----- Original Message ----- > > > > >>>>>> From: "Yair Zaslavsky" > > > > >>>>>> To: "Alon Bar-Lev" > > > > >>>>>> Cc: "Eyal Edri" , "engine-devel" > > > > >>>>> , "infra" > > > > >>>>>> Sent: Tuesday, July 9, 2013 3:42:24 PM > > > > >>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design > > > > >>>>>> for > > > > >>>>> engine commits > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> ----- Original Message ----- > > > > >>>>>>> From: "Alon Bar-Lev" > > > > >>>>>>> To: "Eyal Edri" > > > > >>>>>>> Cc: "engine-devel" , "infra" > > > > >>>>> > > > > >>>>>>> Sent: Tuesday, July 9, 2013 3:33:57 PM > > > > >>>>>>> Subject: Re: [Engine-devel] Proposal for new commit msg design > > > > >>>>>>> for > > > > >>>>> engine > > > > >>>>>>> commits > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> ----- Original Message ----- > > > > >>>>>>>> From: "Eyal Edri" > > > > >>>>>>>> To: "engine-devel" > > > > >>>>>>>> Cc: "infra" > > > > >>>>>>>> Sent: Tuesday, July 9, 2013 12:38:51 PM > > > > >>>>>>>> Subject: Proposal for new commit msg design for engine commits > > > > >>>>>>>> > > > > >>>>>>>> Hi, > > > > >>>>>>>> > > > > >>>>>>>> You all probably know and familiar with 'ovirt-engine' git > > > > >>>>>>>> hook > > > > >>>>> for > > > > >>>>>>>> commit > > > > >>>>>>>> msg template [1]. > > > > >>>>>>>> this helps understand the general area of the patch in the > > > > >>>>> project but it > > > > >>>>>>>> lacks additional info that might > > > > >>>>>>>> be valuable for scaling automatic tests in Jenkins CI. > > > > >>>>>>>> > > > > >>>>>>>> Let me explain: > > > > >>>>>>>> > > > > >>>>>>>> Infra team is working hard on expanding oVirt CI > > > > >>>>>>>> infrastructure > > > > >>>>> and > > > > >>>>>>>> adding > > > > >>>>>>>> more tests in jenkins (per commit/patch). > > > > >>>>>>>> Adding important meta-data per patch can significatly improve > > > > >>>>> the ability > > > > >>>>>>>> to > > > > >>>>>>>> run specific tests for each patch/commit, > > > > >>>>>>>> and not waste valuable resources on Jenkins jobs that are not > > > > >>>>> relevant to > > > > >>>>>>>> the > > > > >>>>>>>> code in the patch. > > > > >>>>>>>> > > > > >>>>>>>> So the idea is to add/expand current metadata per patch, in > > > > >>>>>>>> the > > > > >>>>> form of: > > > > >>>>>>>> (either) > > > > >>>>>>>> 1. expanding current header template to include more data > > > > >>>>>>>> like > > > > >>>>> 'network' > > > > >>>>>>>> , > > > > >>>>>>>> 'setup', 'tools', 'virt' > > > > >>>>>>> Please do not expand header, it is too short anyway. > > > > >>>>>>> > > > > >>>>>>>> 2. adding a new label with relevant tags for the patch, > > > > >>>>>>>> called > > > > >>>>> e.g > > > > >>>>>>>> 'METADATA: network, rest, virt' > > > > >>>>>>> Having: > > > > >>>>>>> > > > > >>>>>>> CI-Tests: xxx > > > > >>>>>>> CI-Tests: yyy > > > > >>>>>>> CI-Tests: zzz > > > > >>>>>>> > > > > >>>>>>> Is much better. > > > > >>>>>> I'm not sure we should have CI-Test - as we might use this for > > > > >>>>> something else > > > > >>>>>> besides CI. > > > > >>>>>> Region_of_Interest as Dan suggests sounds better IMHO. > > > > >>>>> I don't care how this is to be called. > > > > >>>>> However, I do not think that commit message is the place for > > > > >>>>> instructing CI to do anything. > > > > >>>>> Commit message stays for good, it should contain information that > > > > >>>>> is > > > > >>>>> required a year from now. > > > > >>>>> It has nothing to do with tests and such. > > > > >>>> I agree with Alon here that the Ci informations don't belong in > > > > >>>> the > > > > >>>> commit msg. > > > > >>>> My opinion is that a testcase should know what it covers. This > > > > >>>> information from the testcase can then be used by any party to > > > > >>>> determin > > > > >>>> if the testcase should be run on a specific commit (which yields > > > > >>>> informations about the changed paths, files, owner, author, etc > > > > >>>> ... > > > > >>>> which might be valuable). > > > > >>> i think you're missing the point here. > > > > >>> can you explain how do you propose a test case will know "what it > > > > >>> covers"? > > > > >>> > > > > >>> let's take an example: > > > > >>> let's say a new commit comes from ovirt-engine: > > > > >>> http://gerrit.ovirt.org/#/c/16668/ > > > > >>> commit msg: "core: Use images instead of volumes at CDA message". > > > > >>> > > > > >>> now you have 1000 test cases (could be system or functional test). > > > > >>> (let's assume that your infra can't support running 1000 tests per > > > > >>> patch/commit). > > > > >>> > > > > >>> Some of these test suits checks network flow, some virt > > > > >>> (migration/template > > > > >>> for e.g), some host install, others storage flows and so on... ). > > > > >>> you have one repo to clone (ovirt-engine, let's keep vdsm a side > > > > >>> for > > > > >>> a > > > > >>> min), and to compile the project from for the tests. > > > > >>> > > > > >>> now given this scenario, please explain how will you know which > > > > >>> test > > > > >>> from > > > > >>> the 1000 you have you'll run on it. > > > > >>> do you believe that according to the author/path/filename you'll > > > > >>> know > > > > >>> if > > > > >>> that patch involves storage or virt scenario? > > > > >> Hey Eyal, > > > > >> > > > > >> Yes - I would at least give it a try to decide automagically what > > > > >> tests > > > > >> to run by looking at the change. > > > > >> The main motivation for this is to not add another things which the > > > > >> committer needs to take care of and IMO we humans tend to fail (at > > > > >> some > > > > >> point) on those boring tasks like adding correct metadata (let it be > > > > >> a > > > > >> typo or just not adding the correct testsuites/topis to be run). > > > > > this process can be fully automatic via gerrit hooks & templates: > > > > > > > > > > typos or mistakes can be easily handles by gerrit hooks to help the > > > > > committer fix the tags. > > > > > as mentions previously, this logic can be done by the project > > > > > maintainer > > > > > and enforced by a template or hook. > > > > > > > > > > so for example - if someone writes a patch with patch header > > > > > "webadmin:...." , > > > > > then the tags he'll get to choose from are only relevant to ui/ux. > > > > > > > > > > so the only task a committer will have to do is to verify the default > > > > > tags > > > > > are relevant. > > > > > > > > > > i don't believe this is too much to ask for, considering the huge > > > > > benefit > > > > > that we'll get > > > > > (stable code, less bugs, less ci breakage, mapping of specific code > > > > > to > > > > > relevant topic, statistics.. etc..) > > > > > > > > > >> But let's get back to your example. > > > > >> Basically we can use the path and filename to determin what > > > > >> testsuite > > > > >> to > > > > >> run. > > > > >> Testsuites could be bound to paths and/or filenames and/or regexes > > > > >> being > > > > >> matched against the full filename. > > > > >> Another approach would be to use a java package dependency tree to > > > > >> determine which classes are directly and indirectly affected by a > > > > >> change. This information can then be used to also build a set of > > > > >> testsuites to be run. For example: > > > > >> World uses Ocean uses Wale uses Cell - if Wale changes, we'll surely > > > > >> want to run the testsuites assigned to the classes higher up in the > > > > >> dependency chain (World and Ocean). > > > > >> > > > > >> For the concrete example above: Maybe there is a spell checker > > > > >> testcase > > > > >> which could be bound to the filename glob pattern *.properties. > > > > >> > > > > >>> i don't think there's an alternative to a metadata to assist > > > > >>> mapping > > > > >>> the > > > > >>> patch to a relevant "topic" in the code. > > > > >>> whether it exists as a git note or a label in the commit, that's > > > > >>> another > > > > >>> matter and probably less important. > > > > >> The idea is to use the path/filename and dependency tree information > > > > >> to > > > > >> model these topics. Example: > > > > >> WaterTestsuite(Topic): > > > > >> regex_in_change: .*\.fish > > > > >> glob_in_change: src/classes/ocean/*.java > > > > >> path_in_change: src/classes/water.java > > > > >> change_affects_depency_of: WaterClass > > > > > I'm not familiar that much with the names of the classes and > > > > > filenames, > > > > > but > > > > > it sounds to me like an error prone process > > > > > and very complex to start going through all the classes and file > > > > > names > > > > > and > > > > > mapping them to a certain project/component. > > > > > sounds like we'll have to enforce a naming convention for every new > > > > > file/path/class name that won't break that magic > > > > > detection. > > > > > > > > > > sure there are exceptions that will work probably, like "anything > > > > > under > > > > > packaging/, should trigger the 'engine-setup' or 'engine-upgrade' > > > > > tests, > > > > > but imo, it is not so easy with other components. > > > > > > > > > > if something will help, it will be splitting up ovirt-engine into > > > > > subject > > > > > projects (different git) > > > > > > > > > > Eyal. > > > > > > > > I think some valid points were raised in this thread, and I feel we all > > > > agree regarding the need for such a mechanism. > > > > regarding mapping of different areas in the code using metadata, i > > > > think > > > > this approach worth trying, it'll increase ownership and area of > > > > responsibility within our code and hopefully provide us the > > > > functionality we are looking for. > > > > we can start doing the obvious mapping, after-which the responsibility > > > > of each team/maintainer to assign a file to a person and define the > > > > specific functional areas in it. > > > > > > > > Moran. > > > > > > > > > > > > > >> But surely labels or meta-data in the commit msg are quicker to > > > > >> implement. > > > > >> > > > > >> - fabian > > > > >> > > > > >>> eyal. > > > > >>> > > > > >>>> - fabian > > > > >>>> > > > > >>>> _______________________________________________ > > > > >>>> Engine-devel mailing list > > > > >>>> Engine-devel at ovirt.org > > > > >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > >>>> > > > > >> > > > > >> > > > > > _______________________________________________ > > > > > Infra mailing list > > > > > Infra at ovirt.org > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > From dneary at redhat.com Sun Jul 21 18:41:51 2013 From: dneary at redhat.com (Dave Neary) Date: Sun, 21 Jul 2013 20:41:51 +0200 Subject: [Engine-devel] oVirt developer meeting @ KVM Forum Message-ID: <51EC2B6F.1090406@redhat.com> Hi everyone, Put the date in your calendar! The oVirt developer meeting will be held in Edinburgh on October 23rd alongside the KVM Forum. As most of you know, the KVM Forum is happening alongside LinuxCon Europe and CloudOpen Europe in Edinburgh this year, on October 21-23. As we proposed to the oVirt board in January, we would like to take advantage of this gathering of KVM core developers to plan the future of the oVirt project too. In addition to the numerous oVirt presentations which have been proposed both for CloudOpen and the KVM Forum, we will be setting aside one day for developer working sessions. The agenda for these sessions is not (yet) set - we will have subject matter experts leading discussions on the future of their component, where oVirt fits into the broader world of virtualization and the cloud, and how we can grow the community. Among the topics which may be on the table are: * Storage - integration with Gluster, Ceph, Swift, Cinder, NetApp, EMC * Core virtualization - what's missing to make oVirt the best virtualization solution on the market? What's next? How can oVirt best take advantage of the latest KVM features? * Networking - Going beyond Quantum integration: L2 and L3 networking in oVirt * User interface & engine - making oVirt nicer to use and easeir to learn * Ecosystem - Integration with OpenStack, CloudStack; migration strategy from vSphere; integration with other 3rd party projects - what is our place in the world? * Community and marketing - Should we add a forum? How can we grow the user base and community of oVirt? (Note, these are just my ideas - topics will be set by session leaders on a specific topic). What next? First, if you are interested in the future of the oVirt project, please plan to attend the developer meeting. If you are active in oVirt, but cannot finance your travel to the event, please send an email to dneary at redhat.com - I can't promise anything, but we do not want budget constraints to be the main reason for someone missing the meeting. Second, if you are interested in leading a working session on one of the topics above, or a different topic which is important to you, please send an email to the Workshop program committee at workshop-pc at ovirt.org We will keep you posted with schedule updates and more details as plannign advances during the coming weeks. Thanks for your interest, and for your support of oVirt! Regards, Dave Neary. -- 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 alonbl at redhat.com Mon Jul 22 13:43:03 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 22 Jul 2013 09:43:03 -0400 (EDT) Subject: [Engine-devel] [ATN] [devenv] engine service had been moved In-Reply-To: <1287141974.2066676.1374500417178.JavaMail.root@redhat.com> Message-ID: <1214007154.2073139.1374500583831.JavaMail.root@redhat.com> Hello, As we have more services, the engine service had been moved to own directory: OLD: $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py NEW: $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py README.developer[1] and wiki[2] updated. Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=README.developer;hb=HEAD [2] http://www.ovirt.org/OVirt_Engine_Development_Environment#Usage From liran.zelkha at gmail.com Tue Jul 23 07:13:06 2013 From: liran.zelkha at gmail.com (Liran Zelkha) Date: Tue, 23 Jul 2013 10:13:06 +0300 Subject: [Engine-devel] ovirt.org and profiliing Message-ID: Hi all As part of our effort to get profiling licenses to the ovirt contributors, we need to place an image of JProfiler (the chosen profiler) on the home page of ovirt.org. Anyone here knows who has the rights to do that? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpastern at redhat.com Tue Jul 23 07:37:35 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 23 Jul 2013 10:37:35 +0300 Subject: [Engine-devel] ovirt.org and profiliing In-Reply-To: References: Message-ID: <51EE32BF.8040502@redhat.com> On 07/23/2013 10:13 AM, Liran Zelkha wrote: > Hi all > > As part of our effort to get profiling licenses to the ovirt contributors, we need to place an image of JProfiler (the chosen profiler) on the home page of ovirt.org > . > Anyone here knows who has the rights to do that? Dave? > > Thanks > > > _______________________________________________ > 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 sbonazzo at redhat.com Tue Jul 23 11:17:59 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Tue, 23 Jul 2013 13:17:59 +0200 Subject: [Engine-devel] repository closure Message-ID: <51EE6667.9070902@redhat.com> yum install vdsm Error: Package: vdsm-4.12.0-rc2.12.git6bf7c5b.fc19.x86_64 (ovirt-nightly) Requires: mom >= 0.3.2-2 Available: mom-0.3.0-2.fc19.noarch (fedora) mom = 0.3.0-2.fc19 Can we add a job for checking the repository closure? Just calling: # repoclosure -r ovirt-nightly -l fedora -l updates Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 3 fedora ovirt-nightly updates Num Packages in Repos: 45486 package: vdsm-4.12.0-rc2.12.git6bf7c5b.fc19.x86_64 from ovirt-nightly unresolved deps: mom >= 0:0.3.2-2 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From mgoldboi at redhat.com Tue Jul 23 12:23:35 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Tue, 23 Jul 2013 15:23:35 +0300 Subject: [Engine-devel] Fwd: [Users] [ANN] oVirt 3.3 Test Day - Tomorrow Wed - Jul 24th In-Reply-To: <51EE7057.40108@redhat.com> References: <51EE7057.40108@redhat.com> Message-ID: <51EE75C7.4030508@redhat.com> Feature owners, please make sure: -your feature is updated on release table page [1]. -you have test page for your feature [2]. -your team regression testing section is organized and up to date [3]. Thanks. [1] http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table [2] http://www.ovirt.org/OVirt_3.3_TestDay#oVirt_3.3_New_Features_-_Test_Status_Table [3] http://www.ovirt.org/OVirt_3.3_TestDay#Regression_testing -------- Original Message -------- Subject: [Users] [ANN] oVirt 3.3 Test Day - Tomorrow Wed - Jul 24th Date: Tue, 23 Jul 2013 15:00:23 +0300 From: Moran Goldboim CC: users at ovirt.org oVirt 3.3 release is just around the corner, and we would like to invite you all to take a taste of the new release [1]. http://www.ovirt.org/OVirt_3.3_TestDay Tomorrow morning (when all repos are packages are ready - finger crossed) you are invited to: -checkout Test Day page [2] -choose a distro (el6/fc19) -install oVirt [3] -check out the version -report what you find Developers and Users will be available in the channel/ on list to support in case there is trouble Thanks [1] http://www.ovirt.org/OVirt_3.3_release-management [2] http://www.ovirt.org/OVirt_3.3_TestDay [3]http://www.ovirt.org/Download -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Users mailing list Users at ovirt.org http://lists.ovirt.org/mailman/listinfo/users From awinter at redhat.com Tue Jul 23 12:12:45 2013 From: awinter at redhat.com (Amihay Winter) Date: Tue, 23 Jul 2013 08:12:45 -0400 (EDT) Subject: [Engine-devel] VNIC profiles & Device Custom Properties In-Reply-To: <663641499.4577901.1374576949784.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> <663641499.4577901.1374576949784.JavaMail.root@redhat.com> Message-ID: <1013791164.11407199.1374581565912.JavaMail.root@redhat.com> Hi all, I'm building a TCMS plan for the Device Custom Properties feature and I came across some questions. I'm sorry that I'm a little late with my thoughts but I hope you'll still hear them out. Also, I know It's a little long but please bear with me :) I want to talk about two things: 1. Sending an updateDevice verb whenever clicking on "Edit" and than "OK". 2. Setting Port Mirroring at the configuring of a nic and not at the profile. 1.According to the Vnic_Profiles's wiki (in the Editing a profile section) it says: "The changes will seep down to all VNICs using the profile. In case VNIC using the edited profile are connected to running VMs, the change will apply only on the VM next run." I'll describe a Scenario: Creating profile A with property speed = 500 Setting vnic2 on vm to have profile A (using Hotplugnic) Changing (in the profile) speed = 700 According to the Vnic_Profiles's wiki, only when I restart my vm I'll get my setting right. In my opinion, If we could enable the update of those setting LIVE we will give the clients a better solution in the Vnic Profiles. I will be able to update all of my 1000 vms in a few minutes with a single script instead of restarting them all and maybe stopping others' work. I think that restarting 1000 vms because I want to set a property is not something that an admin would want to do. One way to implement it is to send a verb "updateDevice" each time we open the the "Edit" window and clicking "OK" I guess that when the design of update device was made, we tried to send minimal verbs, but in this case, I think that if a user clicked on "Edit" & "OK" then he wanted to send the verb, otherwise, he would have pressed on "Edit" & "Cancel". Sending this verb will allow us to keep the vms update with, in my opinion, minimum cost and with great profit - Giving the client a "more correct environment" LIVE. 2. I'll start with saying that in my opinion, the Vnic Profile feature was created to give the client a *more dynamic network environment* and I support. But, I think that the statical variables like MAC, Un/Pluged and Port Mirroring which always exist should be at the nic and not in the profile. In my opinion, Profile's properties may have: max_mtu, min_mtu, mtu, speed, id, vlan... Identifiers for the network. Maybe I'm missing something but it seems natural to me that the port mirroring will be at nic and not at the profile. I'll really appreciate comments. Thank you for your time. Amihay Winter ----- Original Message ----- > ----- Forwarded Message ----- > From: "Livnat Peer" > To: "Moti Asayag" > Cc: "engine-devel" , "Ofri Masad" > , "Mike Kolesnik" , "Oved Ourfalli" > > Sent: Monday, July 8, 2013 10:11:15 AM > Subject: Re: VNIC profiles > On 07/08/2013 12:36 AM, Moti Asayag wrote: > > I've updated the wiki accordingly and added few comments inline. > > > > ----- Original Message ----- > >> From: "Livnat Peer" > >> To: "Moti Asayag" > >> Cc: "engine-devel" , "Ofri Masad" > >> , "Mike Kolesnik" , > >> "Oved Ourfalli" > >> Sent: Sunday, July 7, 2013 2:59:34 PM > >> Subject: Re: VNIC profiles > >> > >> On 07/07/2013 01:59 PM, Moti Asayag wrote: > >>> Hi, > >>> > >>> I've updated the wiki with the feedbacks from this thread, added a > >>> backend > >>> section naming the affected commands and also add added few questions of > >>> my own embedded in the pastedtext below. > >>> > >> > >> Hi Moti, > >> A good and comprehensive description of the feature behavior. > >> See my comments bellow - > >> > >>> In addition, another question here: > >>> > >>> The units within the UI mockups are Mb and Mbps. The libvirt APIs expects > >>> the units to be in kb and kbps. Which component is responsible to convert > >>> them to the expect units ? engine or VDSM ? > >> > >> Giuseppe mentioned that in a previous thread on this subject. > >> Ofri and Giuseppe agreed that the translation would be done on the > >> engine level. > >> > >> > >>> > >>> Copied text from the wiki: > >>> > >>> Adding a Profile > >>> > >>> The network administrator could create several VNIC Profiles for each > >>> network. He could then grant a users with the permission to use (consume) > >>> each profile. The user will only be able to use profiles which he was > >>> granted access to. > >>> > >>> For example: the network admin will create two VNIC profiles for > >>> network "blue": > >>> > >>> Profile "Gold" - with better QoS and with port mirroring > >>> Profile "Silver" with lower QoS and without port mirroring. > >>> > >> > >> I would use other names for the profiles to avoid confusion. > >> Gold and Silver are likely to be QoS object names, a more typical name > >> for a network profile is - teachers-blue and students-blue > >> > >> The different profiles can have different QoS (teachers-blue would get > >> Gold QoS while Students-blue will have Silver). > >> > >> > >>> He will then define the user-group "students" as user of profile > >>> "Silver" and user-group "teachers" as user of profile "Gold". In this > >>> case the teachers will enjoy better quality of service then the > >>> students. When a teacher will add/edit a virtual NIC he could select > >>> profile "Gold" for that NIC - the VNIC will be connected to network > >>> "blue" with high QoS and with port mirroring. > >>> > >>> Question: In the same matter we allowed via the UI to grant 'NetworkUser' > >>> to 'everyone' user, wouldn't it ease the use of Profiles if we support it > >>> in this context as well? > >> > >> The ease of use could be that when creating a network we'll display in > >> the UI all VNIC-QoS-objects and the users could tick next to the QoS > >> they are interested in, for each QoS that was chosen a profile would be > >> created. > >> > >> I would enhance that with youe suggestion above and display next to the > >> QoS that was checked the option to mark 'Allow All users' like we have > >> today for making a network public, this option would give permission to > >> everyone on that profile. > >> > >> > >>> > >>> Editing a Profile > >>> > >>> A user should be able to edit the profile properties (including profile > >>> name) while VMs are attached and are using this Profile (reference > >>> should be done by id). > >>> Changing the network of a vNic profile will be allowed only if no VMs > >>> are using the profile. > >> > >> It would be better if we can limit this to no running VM is using the > >> profile (or more simple to implement if all VMs that are using this > >> profile are in status down). > > > > Allowing to delete a vnic profile when used by vms is asymmetric to the > > network removal > > when it is used by vms or templates. Today the update network operation is > > blocked for that. > > In addition, with the suggest simplification to remove a profile when no > > running vms, the user > > will have to find for himself if the profile is being used prior to its > > removal since the > > operation will not be blocked. > > > > If we allow to delete a vnic profile, when a vm is using it (regardless the > > VM status) > > we'll have to update the VM entity as well in that operation: since we do > > not support a > > network with 'none' profile, we'll have to delete the network as well. > > > > If we'll remove a vnic profile in 3.1 cluster, used by vms in status down, > > we'd find a case > > in which a VM is attached to a 'none' network. This is unsupported in 3.1 > > cluster. We can block > > such operation, but this is another motivation why we'd better not to allow > > removing a used profile. > > > The context above is about editing not deleting :) > I agree with what you wrote if the context was remove. > >> > >>> Since we have no way to distinguish between running and current > >>> configurations, the expected behavior of such a change is > >>> unpredictable and less intuitive to the user (especially since > >>> dynamic wiring is supported). > >>> The changes will seep down to all VNICs using the profile. > >>> In case VNIC using the edited profile are connected to running VMs, > >>> the change will apply only on the VM next run. > >>> > >>> Question: What about Hibernate/Suspend VM ? will the resume VM action > >>> uses > >>> the original configuration for the vnics when the VM was started ? > >> > >> Currently profile includes: network, port-mirroring, custom property, QoS > >> > >> Changing any of the above (except for network) requires a VM reboot, so > >> I think that we can start with the following statement - the profile > >> change would only apply after next VM reboot. > >> > >> There are 2 problems with the above: > >> - Today we support network wiring, with VNIC profiles we are asking the > >> users to create a new profile and attach the VMs to the new profile, I > >> can see the RFE coming - we can report that ourselves ;) > >> > >> - We don't reflect with which configuration the VM is running, e.g we > >> edited the profile QoS but I'm not sure with which QoS the VM is > >> currently running. (The RFE for differentiating between current > >> configuration and running configuration was already asked for by > >> numerous users) > >> > >> The above is a general issue that we need to solve and I would not limit > >> editing VNIC profiles because of it. > >> We can mitigate this specifically for QoS like described bellow. > >> > >> > >> > >>> Deleting a Profile > >>> > >>> VNIC Profiles could not be deleted from the engine as long as one or more > >>> VM/Templates are using those profiles. > >> > >>> Reporting vNic actual configuration > >>> > >>> The engine will retrieve the actual configuration of the profile > >>> properties on the VNIC from VDSM (using the network statistics > >>> mechanism) and the networked administrator will be presented with the > >>> state of each VNIC (synched/unsynched). > >>> > >> > >> Will the admin be able to see the actual values? I think the synced > >> property is not enough (I'm not sure how interesting this property is to > >> start with). > > > > We can extend the VmGuestAgentInterface to contain the actual value, so > > they > > will be presented for each vnic in the 'guest data' sub-tab. > > > AFAIU this info does not come from the guest it is info we retrieve from > libvirt. > The VmGuestAgentInterface should be used only for information reported > by the guest, information whose credibility can be questioned. > >> > >>> Editing a VNIC / Changing a VNIC profile > >>> > >>> Changing the profile a VM is using while the VM is running should > >>> behave like dynamic wiring (changing the VM network while it is > >>> running). > >>> Hot-plug of a vnic will will use will use the updated profile connected > >>> to the VNIC. > >>> > >> > >> Not sure I fully understand the sentence above. > >> Hot plug will be fully supported, you can choose any profile (you have > >> permissions on) while plugging a new device. > >> > > > > That was the intention. seems like an edgy hand syndrome :) > > Changed to: > > * Hot plug will be fully supported: the user can choose any permitted > > profile while plugging a new device or when activating an existing one. > > > >>> Adding a Network > >>> > >>> When adding a network, a user can provide an option to create a vNic > >>> Profile for it. > >>> > >>> Question: Is it s default profile ? what are its properties ? > >>> Question: What about 'Public Use' option ? Are they still relevant in the > >>> context of adding new networks or we should eliminate them and move it > >>> only to 'Add vNic Profile' dialog? > >>> > >> > >> see previous comments > >> In addition when creating a profile we should have 'Allow all' for > >> implicitly creating permissions, like we have today for network. > >> > >>> Updating a Network > >>> > >>> When a network role is modified to be a 'non-VM network', all vNic > >>> profiles > >>> associated with it should be deleted. > >> > >> And permissions associated with these profiles > >> > >>> Removing a Network > >>> > >>> Should remove all profiles on that network > >>> > >> > >> And associated permissions > >> > >>> Adding an Empty Data-Center > >>> > >>> Currently, When creating a new Data-Center, the management network is > >>> automatically created. > >>> From 3.3, a default vNic profile will be created for the management > >>> network. > >>> > >>> VM snapshot/import/export > >>> > >>> We should handle VMs that are pointing to a network directly for > >>> backward compatibility. > >>> We need to select first profile that is on that network that the user > >>> has permissions on. > >>> > >>> Question: Do we wish to support it export from 3.3 and import to 3.2 or > >>> below? > >> > >> That means that when you write a VM in the OVF you need to write network > >> in addition to profile. > >> > > > > The network name is already there, so when importing a vnic from 3.3 to an > > earlier version > > the profile name will be ignored. > > > >> > >>> Question: A user can import/export a VM/Template even if he doesn't have > >>> permissions on the networks. Is the next flow valid ? > >>> > >>> The profile name should be saved in the OVF (in addition to the network > >>> name which is saved today). > >>> During import, if both (network name, profile name) exist on the target > >>> DC, the vnic will get the profile id. > >>> If the network exists in the Data-Center, but has no profile as > >>> specified in the OVF, the user will be notified (event log) and the > >>> VNIC will be connected to a default minimal profile defined in the > >>> system, regardless the permissions the user has on the network. > >>> > >> > >> What is a 'default minimal profile' ? I would rather have a VNIC with no > >> profile associated with it. > > > > The 'default minimal profile' refers to a vnic profile with the lower > > average bandwidth. > > > > With the approach you've suggested, any imported VM/Template from an > > earlier to 3.3 version > > will require a manual intervention in order to configure a network to the > > VM. > I should have elaborated some more - > If a VM has a profile then we should look up this specific profile, if > such a profile does not exists then import the VM with profile none like > we do today for VM's with reference to a network that does not exist on > the setup. > If a VM does not have a profile (3.2 and lower versions) we should look > into the network name, if this network exist and we have a profile with > permissions to the user then use this profile (if there is more than one > choose one randomly). > > And for 3.1 we'll have to drop such vnics since network 'none' isn't > > supported. > > > >> > >>> If failed to find any matching vNic profile, the vnic's profile will be > >>> set > >>> with 'none'. > >>> > >>> When a Template is created from a VM the VNIC Profile will be kept > >>> along with the VNIC. When a VM is created from template the VNIC > >>> Profiles will be taken from the template's VNICs. > >>> > >>> ----- Original Message ----- > >>>> From: "Livnat Peer" > >>>> To: "engine-devel" , "Ofri Masad" > >>>> > >>>> Cc: "Mike Kolesnik" , "Moti Asayag" > >>>> , "Oved Ourfalli" > >>>> Sent: Sunday, June 30, 2013 3:59:37 PM > >>>> Subject: VNIC profiles > >>>> > >>>> Hi, > >>>> > >>>> We are working on adding VNIC profiles as part of the work to add VNIC > >>>> QoS. > >>>> > >>>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles > >>>> > >>>> We need to define some of the system behavior followed by this change, > >>>> here is my take - > >>>> > >>>> Editing a profile - > >>>> -------------------- > >>>> A user should be able to edit the profile properties (including profile > >>>> name) while VMs are attached and are using this Profile (reference > >>>> should be done by id). > >>>> > >>>> Changing the network though is a bit more tricky as long as we don't > >>>> have a way to distinguish between running and current configurations I > >>>> think it could be very confusing to the user. Especially since we > >>>> support dynamic wiring so the behavior IMO is unpredictable. > >>>> I think it should be blocked at this point. > >>>> > >>>> > >>>> Edit a VNIC / change a VNIC profile - > >>>> ------------------------------------ > >>>> Changing the profile a VM is using while the VM is running should behave > >>>> like dynamic wiring (changing the VM network while it is running). > >>>> > >>>> > >>>> Remove a Profile - > >>>> ------------------- > >>>> Is only valid if all VMs that are using this profile are in status down. > >>>> It should update all VMs to point to no profile which should behave like > >>>> none network today. > >>>> > >>>> I see no reason to support a profile on a none network at this point. > >>>> > >>>> The above is also relevant for upgrade flow (upgrading none network to > >>>> point to no profile) > >>>> > >>>> > >>>> Removing a Network - > >>>> ---------------------- > >>>> should remove all profiles on that network > >>>> > >>>> > >>>> VM snapshot/import/export - > >>>> -------------------------- > >>>> We should handle VMs that are pointing to a network directly for b/w > >>>> compatibility. > >>>> we need to select first profile that is on that network that the user > >>>> has permissions on. > >>>> > >>>> > >>>> I assume there are more, comments are welcome > >>>> > >>>> Thanks, Livnat > >>>> > >>>> > >> > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From eedri at redhat.com Tue Jul 23 14:11:34 2013 From: eedri at redhat.com (Eyal Edri) Date: Tue, 23 Jul 2013 10:11:34 -0400 (EDT) Subject: [Engine-devel] [ANN] ovirt nigthly rpms for fedora19 available for download In-Reply-To: <2065386154.4695752.1374588618927.JavaMail.root@redhat.com> Message-ID: <504509792.4696759.1374588694714.JavaMail.root@redhat.com> Fyi, fedora19 rpm for ovirt projects are now available on http://resources.ovirt.org/releases/nightly/rpm/Fedora/19. Eyal. From iheim at redhat.com Tue Jul 23 15:44:12 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 23 Jul 2013 18:44:12 +0300 Subject: [Engine-devel] JDK Failures with .gwttar In-Reply-To: <50EB20226B72D6419356FC320AB62B8719171584@SERV070.corp.eldorado.org.br> References: <50EB20226B72D6419356FC320AB62B8719171584@SERV070.corp.eldorado.org.br> Message-ID: <51EEA4CC.3000707@redhat.com> On 07/23/2013 05:28 PM, Leonardo Bianconi wrote: > Hi Itamar! > > After rebasing our patches against the master branch from the git > repository, we noticed that the current version of the oVirt engine uses > a new version of GWT. This introduced a problem while building the > engine, which is documented in this link: > > ?IBM JDK failures with .gwtar and compile? - > https://code.google.com/p/google-web-toolkit/issues/detail?id=7530 > > The problem here is that we are using a different JVM (the IBM?s one) > than the one that compiled the gwt files. In the beginning, we tried to > use the Open JDK, but it was too slow to be used, it takes about 1h20m > to build everything against 7m of IBM JDK, so we are using the IBM one. > > We have a question, as we are working on oVirt to work with different > architectures, should we work on fixes when we find a problem like that? > For this issue we got a workaround, using an parameter on the build > command and removing the gwt cached files. Hi Leonardo, yes, we should strive to fix these things. it would be even better if we can detect them earlier, by having a jenkins ppc slave to the ovirt jenkins, or just a local jenkins by you which will report when a patch breaks on ppc/ibm jdk for further consideration). questions: 1. is there a bug right now to fix? we need the build to know to add the modifier when using ibm jdk. 2. (added alon) i remember we actually have an issue with ibm jdk wrt certificates or something which is worth considering in this context. 3. do you have more details on the openjdk performance issue on ppc to try and fix that one? can you open a bug on this and forward to us? Thanks, Itamar From Dustin.Schoenbrun at netapp.com Tue Jul 23 22:35:45 2013 From: Dustin.Schoenbrun at netapp.com (Schoenbrun, Dustin) Date: Tue, 23 Jul 2013 22:35:45 +0000 Subject: [Engine-devel] Getting Hosts in a Data Center using the oVirt API Message-ID: Hey Michael, I had a question about what the best way of getting all hosts within a data center was using the oVirt Java API. Currently, we've been doing a "reverse lookup" from all hosts present in the oVirt Engine to see what clusters they're in and then finding out what data center the cluster belongs to. Thanks in advance, Michael! -- Dustin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpastern at redhat.com Wed Jul 24 05:44:12 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Wed, 24 Jul 2013 08:44:12 +0300 Subject: [Engine-devel] Getting Hosts in a Data Center using the oVirt API In-Reply-To: References: Message-ID: <51EF69AC.1060003@redhat.com> Hi Dustin, On 07/24/2013 01:35 AM, Schoenbrun, Dustin wrote: > Hey Michael, > > I had a question about what the best way of getting all hosts within a data center was using the oVirt Java API. Currently, we've been doing a "reverse lookup" from all > hosts present in the oVirt Engine to see what clusters they're in and then finding out what data center the cluster belongs to. Thanks in advance, Michael! Almost all root collections (such as hosts in your case), supports querying using very same engine search dialect, so actually you can go to UI, combine query, (use auto-completion) and use it in SDK, e.g: List hosts = api.getHosts().list("datacenter = mydatacenter", null, null); hope it helps. > > -- Dustin > -- Michael Pasternak RedHat, ENG-Virtualization R&D From mgoldboi at redhat.com Wed Jul 24 07:09:36 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Wed, 24 Jul 2013 10:09:36 +0300 Subject: [Engine-devel] [Users] [ANN] oVirt 3.3 Test Day - Tomorrow Wed - Jul 24th In-Reply-To: <51EE75C7.4030508@redhat.com> References: <51EE75C7.4030508@redhat.com> Message-ID: <51EF7DB0.1090904@redhat.com> Short update - rpms for ovirt-engine, are not up in the repo yet - and being copied ATM. we'll send a short update when it's there - should be in beta repo [1] [1] http://resources.ovirt.org/releases/beta/rpm/ -------- Original Message -------- Subject: Fwd: [Users] [ANN] oVirt 3.3 Test Day - Tomorrow Wed - Jul 24th Date: Tue, 23 Jul 2013 15:23:35 +0300 From: Moran Goldboim To: engine-devel , vdsm-devel at ovirt.org Feature owners, please make sure: -your feature is updated on release table page [1]. -you have test page for your feature [2]. -your team regression testing section is organized and up to date [3]. Thanks. [1] http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table [2] http://www.ovirt.org/OVirt_3.3_TestDay#oVirt_3.3_New_Features_-_Test_Status_Table [3] http://www.ovirt.org/OVirt_3.3_TestDay#Regression_testing -------- Original Message -------- Subject: [Users] [ANN] oVirt 3.3 Test Day - Tomorrow Wed - Jul 24th Date: Tue, 23 Jul 2013 15:00:23 +0300 From: Moran Goldboim CC: users at ovirt.org oVirt 3.3 release is just around the corner, and we would like to invite you all to take a taste of the new release [1]. http://www.ovirt.org/OVirt_3.3_TestDay Tomorrow morning (when all repos are packages are ready - finger crossed) you are invited to: -checkout Test Day page [2] -choose a distro (el6/fc19) -install oVirt [3] -check out the version -report what you find Developers and Users will be available in the channel/ on list to support in case there is trouble Thanks [1] http://www.ovirt.org/OVirt_3.3_release-management [2] http://www.ovirt.org/OVirt_3.3_TestDay [3]http://www.ovirt.org/Download -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Users mailing list Users at ovirt.org http://lists.ovirt.org/mailman/listinfo/users From mgoldboi at redhat.com Wed Jul 24 07:54:12 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Wed, 24 Jul 2013 10:54:12 +0300 Subject: [Engine-devel] [Users] [ANN] oVirt 3.3 Test Day - Tomorrow Wed - Jul 24th In-Reply-To: <51EF7DB0.1090904@redhat.com> References: <51EE75C7.4030508@redhat.com> <51EF7DB0.1090904@redhat.com> Message-ID: <51EF8824.7040705@redhat.com> Beta RPMs are available on the repo for FC19 and EL6. On 07/24/2013 10:09 AM, Moran Goldboim wrote: > Short update - rpms for ovirt-engine, are not up in the repo yet - and > being copied ATM. > we'll send a short update when it's there - should be in beta repo [1] > > [1] http://resources.ovirt.org/releases/beta/rpm/ > > > -------- Original Message -------- > Subject: Fwd: [Users] [ANN] oVirt 3.3 Test Day - Tomorrow Wed - Jul 24th > Date: Tue, 23 Jul 2013 15:23:35 +0300 > From: Moran Goldboim > To: engine-devel , vdsm-devel at ovirt.org > > > > Feature owners, please make sure: > > -your feature is updated on release table page [1]. > -you have test page for your feature [2]. > -your team regression testing section is organized and up to date [3]. > > Thanks. > > [1] > http://www.ovirt.org/OVirt_3.3_release-management#Features_Status_Table > [2] > http://www.ovirt.org/OVirt_3.3_TestDay#oVirt_3.3_New_Features_-_Test_Status_Table > [3] http://www.ovirt.org/OVirt_3.3_TestDay#Regression_testing > > > -------- Original Message -------- > Subject: [Users] [ANN] oVirt 3.3 Test Day - Tomorrow Wed - Jul 24th > Date: Tue, 23 Jul 2013 15:00:23 +0300 > From: Moran Goldboim > CC: users at ovirt.org > > > > oVirt 3.3 release is just around the corner, and we would like to > invite you all to take a taste of the new release [1]. > > http://www.ovirt.org/OVirt_3.3_TestDay > > Tomorrow morning (when all repos are packages are ready - finger > crossed) you are invited to: > > -checkout Test Day page [2] > -choose a distro (el6/fc19) > -install oVirt [3] > -check out the version > -report what you find > > Developers and Users will be available in the channel/ on list to > support in case there is trouble > > Thanks > > > [1] http://www.ovirt.org/OVirt_3.3_release-management > [2] http://www.ovirt.org/OVirt_3.3_TestDay > [3]http://www.ovirt.org/Download > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alonbl at redhat.com Wed Jul 24 08:05:39 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Wed, 24 Jul 2013 04:05:39 -0400 (EDT) Subject: [Engine-devel] [ATN] [devenv] setup/cleanup scripts where renamed In-Reply-To: <1068188909.2670430.1374653074001.JavaMail.root@redhat.com> Message-ID: <78721963.2670535.1374653139228.JavaMail.root@redhat.com> Hello All, A bit late. setup/cleanup scripts at master were renamed (removed the -2 suffix). README.developer update is available[1]. Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17275/ From amureini at redhat.com Wed Jul 24 11:54:44 2013 From: amureini at redhat.com (Allon Mureinik) Date: Wed, 24 Jul 2013 07:54:44 -0400 (EDT) Subject: [Engine-devel] Linking to bugs from oVirt wiki In-Reply-To: <1330794524.5234428.1374666746828.JavaMail.root@redhat.com> Message-ID: <60562369.5235161.1374666884414.JavaMail.root@redhat.com> Hi guys, Since a lot of us will be busy opening bugs as part of the oVirt Test Day, I cooeked up a quick template to help adding Bugzilla links. You can just use {BZ|number} in your wiki markup, and you'll get a user-friendly link to Bugzilla with the given number (e.g., {BZ|123} will create a link to http://bugzilla.redhat.com/123). Enjoy, Allon From leonardo.bianconi at eldorado.org.br Wed Jul 24 11:46:14 2013 From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi) Date: Wed, 24 Jul 2013 11:46:14 +0000 Subject: [Engine-devel] JDK Failures with .gwttar In-Reply-To: <51EEA4CC.3000707@redhat.com> References: <50EB20226B72D6419356FC320AB62B8719171584@SERV070.corp.eldorado.org.br> <51EEA4CC.3000707@redhat.com> Message-ID: <50EB20226B72D6419356FC320AB62B87191716B5@SERV070.corp.eldorado.org.br> >-----Original Message----- >From: Itamar Heim [mailto:iheim at redhat.com] >Sent: ter?a-feira, 23 de julho de 2013 12:44 >To: Leonardo Bianconi >Cc: Vitor de Lima; Gustavo Frederico Temple Pedrosa; engine-devel; Vojtech Szocs; Alon Bar-Lev >Subject: Re: JDK Failures with .gwttar > >On 07/23/2013 05:28 PM, Leonardo Bianconi wrote: >> Hi Itamar! >> >> After rebasing our patches against the master branch from the git >> repository, we noticed that the current version of the oVirt engine >> uses a new version of GWT. This introduced a problem while building >> the engine, which is documented in this link: >> >> "IBM JDK failures with .gwtar and compile" - >> https://code.google.com/p/google-web-toolkit/issues/detail?id=7530 >> >> The problem here is that we are using a different JVM (the IBM's one) >> than the one that compiled the gwt files. In the beginning, we tried >> to use the Open JDK, but it was too slow to be used, it takes about >> 1h20m to build everything against 7m of IBM JDK, so we are using the IBM one. >> >> We have a question, as we are working on oVirt to work with different >> architectures, should we work on fixes when we find a problem like that? >> For this issue we got a workaround, using an parameter on the build >> command and removing the gwt cached files. > >Hi Leonardo, > >yes, we should strive to fix these things. >it would be even better if we can detect them earlier, by having a jenkins ppc slave to the ovirt jenkins, or just a local jenkins by you >which will report when a patch breaks on ppc/ibm jdk for further consideration). > >questions: >1. is there a bug right now to fix? we need the build to know to add the modifier when using ibm jdk. No, there is no bug in the oVirt project, it's only about the way it builds. We compiled it following the workaround: "As a workaround, you can also simply remove the .gwtar files from gwt-user.jar. I think there's also a -Dgwt.usearchives=false system property to disable loading the gwtar files." The real problem is that the gwt jar contains some serializable files already compiled. Seems gwt developers are looking for a solution, so we could wait a gwt solution before try to fix it. > >2. (added alon) i remember we actually have an issue with ibm jdk wrt certificates or something which is worth considering in this >context. We didn't know about it, I will check that. > >3. do you have more details on the openjdk performance issue on ppc to try and fix that one? can you open a bug on this and forward >to us? We haven't analyzed why it happens, but we know the problem is in the gwt packages, because the compilation time of the other packages are normal. We will compile the oVirt project with both JDKs and attach in the bug the output where it says the compilation time for each package, then I forward it for you. > >Thanks, > Itamar Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa From iheim at redhat.com Wed Jul 24 11:57:02 2013 From: iheim at redhat.com (Itamar Heim) Date: Wed, 24 Jul 2013 14:57:02 +0300 Subject: [Engine-devel] JDK Failures with .gwttar In-Reply-To: <50EB20226B72D6419356FC320AB62B87191716B5@SERV070.corp.eldorado.org.br> References: <50EB20226B72D6419356FC320AB62B8719171584@SERV070.corp.eldorado.org.br> <51EEA4CC.3000707@redhat.com> <50EB20226B72D6419356FC320AB62B87191716B5@SERV070.corp.eldorado.org.br> Message-ID: <51EFC10E.3050108@redhat.com> On 07/24/2013 02:46 PM, Leonardo Bianconi wrote: > > >> -----Original Message----- >> From: Itamar Heim [mailto:iheim at redhat.com] >> Sent: ter?a-feira, 23 de julho de 2013 12:44 >> To: Leonardo Bianconi >> Cc: Vitor de Lima; Gustavo Frederico Temple Pedrosa; engine-devel; Vojtech Szocs; Alon Bar-Lev >> Subject: Re: JDK Failures with .gwttar >> >> On 07/23/2013 05:28 PM, Leonardo Bianconi wrote: >>> Hi Itamar! >>> >>> After rebasing our patches against the master branch from the git >>> repository, we noticed that the current version of the oVirt engine >>> uses a new version of GWT. This introduced a problem while building >>> the engine, which is documented in this link: >>> >>> "IBM JDK failures with .gwtar and compile" - >>> https://code.google.com/p/google-web-toolkit/issues/detail?id=7530 >>> >>> The problem here is that we are using a different JVM (the IBM's one) >>> than the one that compiled the gwt files. In the beginning, we tried >>> to use the Open JDK, but it was too slow to be used, it takes about >>> 1h20m to build everything against 7m of IBM JDK, so we are using the IBM one. >>> >>> We have a question, as we are working on oVirt to work with different >>> architectures, should we work on fixes when we find a problem like that? >>> For this issue we got a workaround, using an parameter on the build >>> command and removing the gwt cached files. >> >> Hi Leonardo, >> >> yes, we should strive to fix these things. >> it would be even better if we can detect them earlier, by having a jenkins ppc slave to the ovirt jenkins, or just a local jenkins by you >> which will report when a patch breaks on ppc/ibm jdk for further consideration). >> >> questions: >> 1. is there a bug right now to fix? we need the build to know to add the modifier when using ibm jdk. > No, there is no bug in the oVirt project, it's only about the way it builds. We compiled it following the workaround: > "As a workaround, you can also simply remove the .gwtar files from gwt-user.jar. I think there's also a -Dgwt.usearchives=false system property to disable loading the gwtar files." > > The real problem is that the gwt jar contains some serializable files already compiled. Seems gwt developers are looking for a solution, so we could wait a gwt solution before try to fix it. well, it failed us as well - could be this (late last night) solves it for you as well: http://gerrit.ovirt.org/#/c/17264/ >> >> 2. (added alon) i remember we actually have an issue with ibm jdk wrt certificates or something which is worth considering in this >> context. > We didn't know about it, I will check that. >> >> 3. do you have more details on the openjdk performance issue on ppc to try and fix that one? can you open a bug on this and forward >> to us? > We haven't analyzed why it happens, but we know the problem is in the gwt packages, because the compilation time of the other packages are normal. We will compile the oVirt project with both JDKs and attach in the bug the output where it says the compilation time for each package, then I forward it for you. >> >> Thanks, >> Itamar > > Thanks, > Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa > From amureini at redhat.com Wed Jul 24 12:15:33 2013 From: amureini at redhat.com (Allon Mureinik) Date: Wed, 24 Jul 2013 08:15:33 -0400 (EDT) Subject: [Engine-devel] Linking to bugs from oVirt wiki In-Reply-To: <60562369.5235161.1374666884414.JavaMail.root@redhat.com> References: <60562369.5235161.1374666884414.JavaMail.root@redhat.com> Message-ID: <7113008.5245835.1374668133358.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Allon Mureinik" > To: "engine-devel" , vdsm-devel at lists.fedorahosted.org > Sent: Wednesday, July 24, 2013 2:54:44 PM > Subject: Linking to bugs from oVirt wiki > > Hi guys, > > Since a lot of us will be busy opening bugs as part of the oVirt Test Day, I > cooeked up a quick template to help adding Bugzilla links. > > You can just use {BZ|number} in your wiki markup, and you'll get a {{BZ|number}} of course. Thanks Alissa for pointing this out. ;-) > user-friendly link to Bugzilla with the given number (e.g., {BZ|123} will > create a link to http://bugzilla.redhat.com/123). > > > Enjoy, > Allon From mgoldboi at redhat.com Wed Jul 24 14:04:53 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Wed, 24 Jul 2013 17:04:53 +0300 Subject: [Engine-devel] [Users] [ANN] oVirt 3.3 Test Day - Tomorrow Wed - Jul 24th In-Reply-To: <51EE7057.40108@redhat.com> References: <51EE7057.40108@redhat.com> Message-ID: <51EFDF05.9010601@redhat.com> For all participants in the test day: -it would be great if you can put your name/distro here [1] -if you found a general bug (regression) , you can add it to to the table under general [2] we would like to get some input on general bugs/problems you are experiencing. Thanks. [1] http://www.ovirt.org/OVirt_3.3_TestDay#Participants_Table [2] http://www.ovirt.org/OVirt_3.3_TestDay#oVirt_3.3_New_Features_-_Test_Status_Table On 07/23/2013 03:00 PM, Moran Goldboim wrote: > oVirt 3.3 release is just around the corner, and we would like to > invite you all to take a taste of the new release [1]. > > http://www.ovirt.org/OVirt_3.3_TestDay > > Tomorrow morning (when all repos are packages are ready - finger > crossed) you are invited to: > > -checkout Test Day page [2] > -choose a distro (el6/fc19) > -install oVirt [3] > -check out the version > -report what you find > > Developers and Users will be available in the channel/ on list to > support in case there is trouble > > Thanks > > > [1] http://www.ovirt.org/OVirt_3.3_release-management > [2] http://www.ovirt.org/OVirt_3.3_TestDay > [3]http://www.ovirt.org/Download > > > > _______________________________________________ > Users mailing list > Users at ovirt.org > http://lists.ovirt.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From wei.d.chen at intel.com Thu Jul 25 03:05:24 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Thu, 25 Jul 2013 03:05:24 +0000 Subject: [Engine-devel] fail to add host from portal Message-ID: It fails when add a host from portal, and error info as follows, anyone can give us some suggestion? 2013-07-25 22:55:39,539 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) Correlation ID: 296737fb, Call Stack: null, Custom Event ID: -1, Message: Installing Host onode. Logs at host located at: '/tmp/ovirt-host-deploy-20130725105531.log'. 2013-07-25 22:55:39,563 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (VdsDeploy) Error during deploy dialog: java.lang.NullPointerException at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] 2013-07-25 22:55:39,565 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com install: java.lang.NullPointerException at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] 2013-07-25 22:55:39,568 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com install, prefering first exception: java.lang.NullPointerException at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] 2013-07-25 22:55:39,569 ERROR [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-6-thread-5) [296737fb] Host installation failed for host 00c50bb0-f843-442a-a032-acebe0d092c4, onode.: java.lang.NullPointerException at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] 2013-07-25 22:55:39,572 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (pool-6-thread-5) [296737fb] START, SetVdsStatusVDSCommand(HostName = onode, HostId = 00c50bb0-f843-442a-a032-acebe0d092c4, status=InstallFailed, nonOperationalReason=NONE), log id: 39c3919d 2013-07-25 22:55:39,581 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (pool-6-thread-5) [296737fb] FINISH, SetVdsStatusVDSCommand, log id: 39c3919d 2013-07-25 22:55:39,589 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (pool-6-thread-5) [296737fb] Correlation ID: 296737fb, Call Stack: null, Custom Event ID: -1, Message: Host onode installation failed. Please refer to engine.log and log files under /var/log/ovirt-engine/host-deploy/ on the engine for further details.. Best Regards, Dave Chen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6648 bytes Desc: not available URL: From dougsland at redhat.com Thu Jul 25 03:21:29 2013 From: dougsland at redhat.com (Douglas Schilling Landgraf) Date: Wed, 24 Jul 2013 23:21:29 -0400 Subject: [Engine-devel] fail to add host from portal In-Reply-To: References: Message-ID: <51F099B9.7070109@redhat.com> Hello, On 07/24/2013 11:05 PM, Chen, Wei D wrote: > It fails when add a host from portal, and error info as follows, anyone can give us some suggestion? > > 2013-07-25 22:55:39,539 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) Correlation ID: > 296737fb, Call Stack: null, Custom Event ID: -1, Message: Installing Host onode. Logs at host located at: > '/tmp/ovirt-host-deploy-20130725105531.log'. > 2013-07-25 22:55:39,563 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (VdsDeploy) Error during deploy dialog: > java.lang.NullPointerException > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > 2013-07-25 22:55:39,565 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (pool-6-thread-5) [296737fb] Error during host > onode.sh.intel.com install: java.lang.NullPointerException > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > 2013-07-25 22:55:39,568 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (pool-6-thread-5) [296737fb] Error during host > onode.sh.intel.com install, prefering first exception: java.lang.NullPointerException > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > 2013-07-25 22:55:39,569 ERROR [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-6-thread-5) [296737fb] Host installation failed > for host 00c50bb0-f843-442a-a032-acebe0d092c4, onode.: java.lang.NullPointerException > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > 2013-07-25 22:55:39,572 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (pool-6-thread-5) [296737fb] START, > SetVdsStatusVDSCommand(HostName = onode, HostId = 00c50bb0-f843-442a-a032-acebe0d092c4, status=InstallFailed, > nonOperationalReason=NONE), log id: 39c3919d > 2013-07-25 22:55:39,581 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (pool-6-thread-5) [296737fb] FINISH, > SetVdsStatusVDSCommand, log id: 39c3919d > 2013-07-25 22:55:39,589 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (pool-6-thread-5) [296737fb] > Correlation ID: 296737fb, Call Stack: null, Custom Event ID: -1, Message: Host onode installation failed. Please refer to engine.log > and log files under /var/log/ovirt-engine/host-deploy/ on the engine for further details.. > > On Engine side, can you please check the log available at: /var/log/ovirt-engine/host-deploy/ ? -- Cheers Douglas From wei.d.chen at intel.com Thu Jul 25 04:45:27 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Thu, 25 Jul 2013 04:45:27 +0000 Subject: [Engine-devel] fail to add host from portal In-Reply-To: <51F099B9.7070109@redhat.com> References: <51F099B9.7070109@redhat.com> Message-ID: Hi Douglas, There is not extra logs. /var/log/ovirt-engine/host-deploy/ is empty. Best Regards, Dave Chen > -----Original Message----- > From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Douglas Schilling Landgraf > Sent: Thursday, July 25, 2013 11:21 AM > To: engine-devel at ovirt.org > Subject: Re: [Engine-devel] fail to add host from portal > > Hello, > > On 07/24/2013 11:05 PM, Chen, Wei D wrote: > > It fails when add a host from portal, and error info as follows, anyone can give us some suggestion? > > > > 2013-07-25 22:55:39,539 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) Correlation ID: > > 296737fb, Call Stack: null, Custom Event ID: -1, Message: Installing Host onode. Logs at host located at: > > '/tmp/ovirt-host-deploy-20130725105531.log'. > > 2013-07-25 22:55:39,563 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (VdsDeploy) Error during deploy dialog: > > java.lang.NullPointerException > > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > 2013-07-25 22:55:39,565 ERROR [org.ovirt.engine.core.bll.VdsDeploy] > > (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com install: java.lang.NullPointerException > > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > 2013-07-25 22:55:39,568 ERROR [org.ovirt.engine.core.bll.VdsDeploy] > > (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com install, prefering first exception: java.lang.NullPointerException > > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > 2013-07-25 22:55:39,569 ERROR > > [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-6-thread-5) [296737fb] Host installation failed for host > 00c50bb0-f843-442a-a032-acebe0d092c4, onode.: java.lang.NullPointerException > > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > 2013-07-25 22:55:39,572 INFO > > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > > (pool-6-thread-5) [296737fb] START, SetVdsStatusVDSCommand(HostName = > > onode, HostId = 00c50bb0-f843-442a-a032-acebe0d092c4, > > status=InstallFailed, nonOperationalReason=NONE), log id: 39c3919d > > 2013-07-25 22:55:39,581 INFO > > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > > (pool-6-thread-5) [296737fb] FINISH, SetVdsStatusVDSCommand, log id: > > 39c3919d > > 2013-07-25 22:55:39,589 INFO > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > (pool-6-thread-5) [296737fb] Correlation ID: 296737fb, Call Stack: null, Custom Event ID: -1, Message: Host onode installation failed. > Please refer to engine.log and log files under /var/log/ovirt-engine/host-deploy/ on the engine for further details.. > > > > > > On Engine side, can you please check the log available at: > /var/log/ovirt-engine/host-deploy/ ? > > > > -- > Cheers > Douglas > _______________________________________________ > 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: smime.p7s Type: application/pkcs7-signature Size: 6648 bytes Desc: not available URL: From wei.d.chen at intel.com Thu Jul 25 05:34:53 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Thu, 25 Jul 2013 05:34:53 +0000 Subject: [Engine-devel] fail to add host from portal In-Reply-To: <51F099B9.7070109@redhat.com> References: <51F099B9.7070109@redhat.com> Message-ID: whether this log is helpful? thanks. directory : '/tmp/ovirt-host-deploy-20130725132704.log' Best Regards, Dave Chen > -----Original Message----- > From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Douglas Schilling Landgraf > Sent: Thursday, July 25, 2013 11:21 AM > To: engine-devel at ovirt.org > Subject: Re: [Engine-devel] fail to add host from portal > > Hello, > > On 07/24/2013 11:05 PM, Chen, Wei D wrote: > > It fails when add a host from portal, and error info as follows, anyone can give us some suggestion? > > > > 2013-07-25 22:55:39,539 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (VdsDeploy) Correlation ID: > > 296737fb, Call Stack: null, Custom Event ID: -1, Message: Installing Host onode. Logs at host located at: > > '/tmp/ovirt-host-deploy-20130725105531.log'. > > 2013-07-25 22:55:39,563 ERROR [org.ovirt.engine.core.bll.VdsDeploy] (VdsDeploy) Error during deploy dialog: > > java.lang.NullPointerException > > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > 2013-07-25 22:55:39,565 ERROR [org.ovirt.engine.core.bll.VdsDeploy] > > (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com install: java.lang.NullPointerException > > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > 2013-07-25 22:55:39,568 ERROR [org.ovirt.engine.core.bll.VdsDeploy] > > (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com install, prefering first exception: java.lang.NullPointerException > > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > 2013-07-25 22:55:39,569 ERROR > > [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-6-thread-5) [296737fb] Host installation failed for host > 00c50bb0-f843-442a-a032-acebe0d092c4, onode.: java.lang.NullPointerException > > at org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) [otopi.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) [bll.jar:] > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > 2013-07-25 22:55:39,572 INFO > > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > > (pool-6-thread-5) [296737fb] START, SetVdsStatusVDSCommand(HostName = > > onode, HostId = 00c50bb0-f843-442a-a032-acebe0d092c4, > > status=InstallFailed, nonOperationalReason=NONE), log id: 39c3919d > > 2013-07-25 22:55:39,581 INFO > > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > > (pool-6-thread-5) [296737fb] FINISH, SetVdsStatusVDSCommand, log id: > > 39c3919d > > 2013-07-25 22:55:39,589 INFO > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > (pool-6-thread-5) [296737fb] Correlation ID: 296737fb, Call Stack: null, Custom Event ID: -1, Message: Host onode installation failed. > Please refer to engine.log and log files under /var/log/ovirt-engine/host-deploy/ on the engine for further details.. > > > > > > On Engine side, can you please check the log available at: > /var/log/ovirt-engine/host-deploy/ ? > > > > -- > Cheers > Douglas > _______________________________________________ > 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: ovirt-host-deploy-20130725132704.log Type: application/octet-stream Size: 118145 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6648 bytes Desc: not available URL: From alonbl at redhat.com Thu Jul 25 08:19:46 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 25 Jul 2013 04:19:46 -0400 (EDT) Subject: [Engine-devel] fail to add host from portal In-Reply-To: References: <51F099B9.7070109@redhat.com> Message-ID: <1042636494.2984057.1374740386976.JavaMail.root@redhat.com> Something is not correct in your otopi/ovirt-host-deploy installation. Many files seem to be missing. Can you please reinstall these packages and remove /var/cache/ovirt-enigne/* ? ----- Original Message ----- > From: "Wei D Chen" > To: dougsland at redhat.com, engine-devel at ovirt.org > Cc: "Lijuan Zhang" > Sent: Thursday, July 25, 2013 8:34:53 AM > Subject: Re: [Engine-devel] fail to add host from portal > > whether this log is helpful? thanks. > > directory : '/tmp/ovirt-host-deploy-20130725132704.log' > > > Best Regards, > Dave Chen > > > > -----Original Message----- > > From: engine-devel-bounces at ovirt.org > > [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Douglas Schilling > > Landgraf > > Sent: Thursday, July 25, 2013 11:21 AM > > To: engine-devel at ovirt.org > > Subject: Re: [Engine-devel] fail to add host from portal > > > > Hello, > > > > On 07/24/2013 11:05 PM, Chen, Wei D wrote: > > > It fails when add a host from portal, and error info as follows, anyone > > > can give us some suggestion? > > > > > > 2013-07-25 22:55:39,539 INFO > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > > (VdsDeploy) Correlation ID: > > > 296737fb, Call Stack: null, Custom Event ID: -1, Message: Installing Host > > > onode. Logs at host located at: > > > '/tmp/ovirt-host-deploy-20130725105531.log'. > > > 2013-07-25 22:55:39,563 ERROR [org.ovirt.engine.core.bll.VdsDeploy] > > > (VdsDeploy) Error during deploy dialog: > > > java.lang.NullPointerException > > > at > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > [otopi.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > [bll.jar:] > > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > > > 2013-07-25 22:55:39,565 ERROR [org.ovirt.engine.core.bll.VdsDeploy] > > > (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com > > > install: java.lang.NullPointerException > > > at > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > [otopi.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > [bll.jar:] > > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > > > 2013-07-25 22:55:39,568 ERROR [org.ovirt.engine.core.bll.VdsDeploy] > > > (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com > > > install, prefering first exception: > java.lang.NullPointerException > > > at > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > [otopi.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > [bll.jar:] > > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > > > 2013-07-25 22:55:39,569 ERROR > > > [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-6-thread-5) > > > [296737fb] Host installation failed for host > > 00c50bb0-f843-442a-a032-acebe0d092c4, onode.: > > java.lang.NullPointerException > > > at > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > [otopi.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > [bll.jar:] > > > at > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > [bll.jar:] > > > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > > > > > > 2013-07-25 22:55:39,572 INFO > > > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > > > (pool-6-thread-5) [296737fb] START, SetVdsStatusVDSCommand(HostName = > > > onode, HostId = 00c50bb0-f843-442a-a032-acebe0d092c4, > > > status=InstallFailed, nonOperationalReason=NONE), log id: 39c3919d > > > 2013-07-25 22:55:39,581 INFO > > > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > > > (pool-6-thread-5) [296737fb] FINISH, SetVdsStatusVDSCommand, log id: > > > 39c3919d > > > 2013-07-25 22:55:39,589 INFO > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > > > (pool-6-thread-5) [296737fb] Correlation ID: 296737fb, Call Stack: null, > > > Custom Event ID: -1, Message: Host onode installation > failed. > > Please refer to engine.log and log files under > > /var/log/ovirt-engine/host-deploy/ on the engine for further details.. > > > > > > > > > > On Engine side, can you please check the log available at: > > /var/log/ovirt-engine/host-deploy/ ? > > > > > > > > -- > > Cheers > > Douglas > > _______________________________________________ > > 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 wlbleaboy at 126.com Fri Jul 26 02:20:47 2013 From: wlbleaboy at 126.com (wlbleaboy@126) Date: Fri, 26 Jul 2013 10:20:47 +0800 Subject: [Engine-devel] get certificate with SDK Message-ID: <000001ce89a6$be34a260$3a9de720$@com> Hi, all: I can got all the VM?s information in https://{ovirt-engine}/api/vms/{id} , and I can get mostly VM?s informations via ovirt-engine-sdk, but I can?t got via SDK. This is a part of XML in https://{ovirt-engine}/api/vms/{id} spice
192.168.1.241
5914 5915 1 false O=thtfc.com,CN=allinone241.thtfc.com false For example, I can port like vm.get_display().get_port() but when I want CN, I tyied use vm.get_display().get_certificate().get_subject() it return >>> vm.get_display().get_certificate().get_subject() Traceback (most recent call last): File "", line 1, in AttributeError: 'NoneType' object has no attribute 'get_subject' -------------- next part -------------- An HTML attachment was scrubbed... URL: From wei.d.chen at intel.com Fri Jul 26 05:38:56 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Fri, 26 Jul 2013 05:38:56 +0000 Subject: [Engine-devel] fail to add host from portal In-Reply-To: <1042636494.2984057.1374740386976.JavaMail.root@redhat.com> References: <51F099B9.7070109@redhat.com> <1042636494.2984057.1374740386976.JavaMail.root@redhat.com> Message-ID: Hi Alon, What do you mean many files are missing? such as? What's otopi? the name of package? Best Regards, Dave Chen > -----Original Message----- > From: Alon Bar-Lev [mailto:alonbl at redhat.com] > Sent: Thursday, July 25, 2013 4:20 PM > To: Chen, Wei D > Cc: dougsland at redhat.com; engine-devel at ovirt.org; Zhang, Lijuan > Subject: Re: [Engine-devel] fail to add host from portal > > Something is not correct in your otopi/ovirt-host-deploy installation. > Many files seem to be missing. > > Can you please reinstall these packages and remove /var/cache/ovirt-enigne/* ? > > ----- Original Message ----- > > From: "Wei D Chen" > > To: dougsland at redhat.com, engine-devel at ovirt.org > > Cc: "Lijuan Zhang" > > Sent: Thursday, July 25, 2013 8:34:53 AM > > Subject: Re: [Engine-devel] fail to add host from portal > > > > whether this log is helpful? thanks. > > > > directory : '/tmp/ovirt-host-deploy-20130725132704.log' > > > > > > Best Regards, > > Dave Chen > > > > > > > -----Original Message----- > > > From: engine-devel-bounces at ovirt.org > > > [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Douglas > > > Schilling Landgraf > > > Sent: Thursday, July 25, 2013 11:21 AM > > > To: engine-devel at ovirt.org > > > Subject: Re: [Engine-devel] fail to add host from portal > > > > > > Hello, > > > > > > On 07/24/2013 11:05 PM, Chen, Wei D wrote: > > > > It fails when add a host from portal, and error info as follows, > > > > anyone can give us some suggestion? > > > > > > > > 2013-07-25 22:55:39,539 INFO > > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirec > > > > tor] > > > > (VdsDeploy) Correlation ID: > > > > 296737fb, Call Stack: null, Custom Event ID: -1, Message: > > > > Installing Host onode. Logs at host located at: > > > > '/tmp/ovirt-host-deploy-20130725105531.log'. > > > > 2013-07-25 22:55:39,563 ERROR > > > > [org.ovirt.engine.core.bll.VdsDeploy] > > > > (VdsDeploy) Error during deploy dialog: > > > > java.lang.NullPointerException > > > > at > > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > > [otopi.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > > [bll.jar:] > > > > at java.lang.Thread.run(Thread.java:724) > > > > [rt.jar:1.7.0_25] > > > > > > > > 2013-07-25 22:55:39,565 ERROR > > > > [org.ovirt.engine.core.bll.VdsDeploy] > > > > (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com > > > > install: java.lang.NullPointerException > > > > at > > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > > [otopi.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > > [bll.jar:] > > > > at java.lang.Thread.run(Thread.java:724) > > > > [rt.jar:1.7.0_25] > > > > > > > > 2013-07-25 22:55:39,568 ERROR > > > > [org.ovirt.engine.core.bll.VdsDeploy] > > > > (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com > > > > install, prefering first exception: > > java.lang.NullPointerException > > > > at > > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > > [otopi.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > > [bll.jar:] > > > > at java.lang.Thread.run(Thread.java:724) > > > > [rt.jar:1.7.0_25] > > > > > > > > 2013-07-25 22:55:39,569 ERROR > > > > [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-6-thread-5) > > > > [296737fb] Host installation failed for host > > > 00c50bb0-f843-442a-a032-acebe0d092c4, onode.: > > > java.lang.NullPointerException > > > > at > > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > > [otopi.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > > [bll.jar:] > > > > at java.lang.Thread.run(Thread.java:724) > > > > [rt.jar:1.7.0_25] > > > > > > > > 2013-07-25 22:55:39,572 INFO > > > > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > > > > (pool-6-thread-5) [296737fb] START, > > > > SetVdsStatusVDSCommand(HostName = onode, HostId = > > > > 00c50bb0-f843-442a-a032-acebe0d092c4, > > > > status=InstallFailed, nonOperationalReason=NONE), log id: 39c3919d > > > > 2013-07-25 22:55:39,581 INFO > > > > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > > > > (pool-6-thread-5) [296737fb] FINISH, SetVdsStatusVDSCommand, log id: > > > > 39c3919d > > > > 2013-07-25 22:55:39,589 INFO > > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirec > > > > tor] > > > > (pool-6-thread-5) [296737fb] Correlation ID: 296737fb, Call Stack: > > > > null, Custom Event ID: -1, Message: Host onode installation > > failed. > > > Please refer to engine.log and log files under > > > /var/log/ovirt-engine/host-deploy/ on the engine for further details.. > > > > > > > > > > > > > > On Engine side, can you please check the log available at: > > > /var/log/ovirt-engine/host-deploy/ ? > > > > > > > > > > > > -- > > > Cheers > > > Douglas > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6648 bytes Desc: not available URL: From wei.d.chen at intel.com Fri Jul 26 08:15:11 2013 From: wei.d.chen at intel.com (Chen, Wei D) Date: Fri, 26 Jul 2013 08:15:11 +0000 Subject: [Engine-devel] fail to add host from portal In-Reply-To: <1042636494.2984057.1374740386976.JavaMail.root@redhat.com> References: <51F099B9.7070109@redhat.com> <1042636494.2984057.1374740386976.JavaMail.root@redhat.com> Message-ID: The issue is solved by updating the package of "ovirt-host-deploy". thanks Alon. Best Regards, Dave Chen > -----Original Message----- > From: Alon Bar-Lev [mailto:alonbl at redhat.com] > Sent: Thursday, July 25, 2013 4:20 PM > To: Chen, Wei D > Cc: dougsland at redhat.com; engine-devel at ovirt.org; Zhang, Lijuan > Subject: Re: [Engine-devel] fail to add host from portal > > Something is not correct in your otopi/ovirt-host-deploy installation. > Many files seem to be missing. > > Can you please reinstall these packages and remove /var/cache/ovirt-enigne/* ? > > ----- Original Message ----- > > From: "Wei D Chen" > > To: dougsland at redhat.com, engine-devel at ovirt.org > > Cc: "Lijuan Zhang" > > Sent: Thursday, July 25, 2013 8:34:53 AM > > Subject: Re: [Engine-devel] fail to add host from portal > > > > whether this log is helpful? thanks. > > > > directory : '/tmp/ovirt-host-deploy-20130725132704.log' > > > > > > Best Regards, > > Dave Chen > > > > > > > -----Original Message----- > > > From: engine-devel-bounces at ovirt.org > > > [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Douglas > > > Schilling Landgraf > > > Sent: Thursday, July 25, 2013 11:21 AM > > > To: engine-devel at ovirt.org > > > Subject: Re: [Engine-devel] fail to add host from portal > > > > > > Hello, > > > > > > On 07/24/2013 11:05 PM, Chen, Wei D wrote: > > > > It fails when add a host from portal, and error info as follows, > > > > anyone can give us some suggestion? > > > > > > > > 2013-07-25 22:55:39,539 INFO > > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirec > > > > tor] > > > > (VdsDeploy) Correlation ID: > > > > 296737fb, Call Stack: null, Custom Event ID: -1, Message: > > > > Installing Host onode. Logs at host located at: > > > > '/tmp/ovirt-host-deploy-20130725105531.log'. > > > > 2013-07-25 22:55:39,563 ERROR > > > > [org.ovirt.engine.core.bll.VdsDeploy] > > > > (VdsDeploy) Error during deploy dialog: > > > > java.lang.NullPointerException > > > > at > > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > > [otopi.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > > [bll.jar:] > > > > at java.lang.Thread.run(Thread.java:724) > > > > [rt.jar:1.7.0_25] > > > > > > > > 2013-07-25 22:55:39,565 ERROR > > > > [org.ovirt.engine.core.bll.VdsDeploy] > > > > (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com > > > > install: java.lang.NullPointerException > > > > at > > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > > [otopi.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > > [bll.jar:] > > > > at java.lang.Thread.run(Thread.java:724) > > > > [rt.jar:1.7.0_25] > > > > > > > > 2013-07-25 22:55:39,568 ERROR > > > > [org.ovirt.engine.core.bll.VdsDeploy] > > > > (pool-6-thread-5) [296737fb] Error during host onode.sh.intel.com > > > > install, prefering first exception: > > java.lang.NullPointerException > > > > at > > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > > [otopi.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > > [bll.jar:] > > > > at java.lang.Thread.run(Thread.java:724) > > > > [rt.jar:1.7.0_25] > > > > > > > > 2013-07-25 22:55:39,569 ERROR > > > > [org.ovirt.engine.core.bll.InstallVdsCommand] (pool-6-thread-5) > > > > [296737fb] Host installation failed for host > > > 00c50bb0-f843-442a-a032-acebe0d092c4, onode.: > > > java.lang.NullPointerException > > > > at > > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > > > [otopi.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$14.call(VdsDeploy.java:347) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:579) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:791) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy.access$1800(VdsDeploy.java:76) > > > > [bll.jar:] > > > > at > > > > org.ovirt.engine.core.bll.VdsDeploy$44.run(VdsDeploy.java:882) > > > > [bll.jar:] > > > > at java.lang.Thread.run(Thread.java:724) > > > > [rt.jar:1.7.0_25] > > > > > > > > 2013-07-25 22:55:39,572 INFO > > > > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > > > > (pool-6-thread-5) [296737fb] START, > > > > SetVdsStatusVDSCommand(HostName = onode, HostId = > > > > 00c50bb0-f843-442a-a032-acebe0d092c4, > > > > status=InstallFailed, nonOperationalReason=NONE), log id: 39c3919d > > > > 2013-07-25 22:55:39,581 INFO > > > > [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] > > > > (pool-6-thread-5) [296737fb] FINISH, SetVdsStatusVDSCommand, log id: > > > > 39c3919d > > > > 2013-07-25 22:55:39,589 INFO > > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirec > > > > tor] > > > > (pool-6-thread-5) [296737fb] Correlation ID: 296737fb, Call Stack: > > > > null, Custom Event ID: -1, Message: Host onode installation > > failed. > > > Please refer to engine.log and log files under > > > /var/log/ovirt-engine/host-deploy/ on the engine for further details.. > > > > > > > > > > > > > > On Engine side, can you please check the log available at: > > > /var/log/ovirt-engine/host-deploy/ ? > > > > > > > > > > > > -- > > > Cheers > > > Douglas > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6648 bytes Desc: not available URL: From Dustin.Schoenbrun at netapp.com Fri Jul 26 17:41:03 2013 From: Dustin.Schoenbrun at netapp.com (Schoenbrun, Dustin) Date: Fri, 26 Jul 2013 17:41:03 +0000 Subject: [Engine-devel] Getting Hosts in a Data Center using the oVirt API In-Reply-To: <51EF69AC.1060003@redhat.com> Message-ID: Hey Michael, That's really helpful! I didn't know you could use queries like in the search bar within the API. Thanks for the help! -- Dustin On 7/24/13 1:44 AM, "Michael Pasternak" wrote: > >Hi Dustin, > >On 07/24/2013 01:35 AM, Schoenbrun, Dustin wrote: >> Hey Michael, >> >> I had a question about what the best way of getting all hosts within a >>data center was using the oVirt Java API. Currently, we've been doing a >>"reverse lookup" from all >> hosts present in the oVirt Engine to see what clusters they're in and >>then finding out what data center the cluster belongs to. Thanks in >>advance, Michael! > >Almost all root collections (such as hosts in your case), supports >querying using >very same engine search dialect, so actually you can go to UI, combine >query, >(use auto-completion) and use it in SDK, e.g: > >List hosts = api.getHosts().list("datacenter = mydatacenter", null, >null); > >hope it helps. > >> >> -- Dustin >> > > >-- > >Michael Pasternak >RedHat, ENG-Virtualization R&D From dneary at redhat.com Fri Jul 26 20:06:19 2013 From: dneary at redhat.com (Dave Neary) Date: Fri, 26 Jul 2013 13:06:19 -0700 Subject: [Engine-devel] ovirt.org and profiliing In-Reply-To: <51EE32BF.8040502@redhat.com> References: <51EE32BF.8040502@redhat.com> Message-ID: <51F2D6BB.1050704@redhat.com> Hi, Anyone who is an administrator or bureaucrat on the wiki may. This includes all the people on this list: http://www.ovirt.org/index.php?title=Special%3AListUsers&username=&group=bureaucrat&limit=50 I will not be able to do it for several weeks (totally booked on urgent issues Monday and Tuesday, and my Summer vacation starts right after that). Cheers, Dave. On 07/23/2013 12:37 AM, Michael Pasternak wrote: > On 07/23/2013 10:13 AM, Liran Zelkha wrote: >> Hi all >> >> As part of our effort to get profiling licenses to the ovirt contributors, we need to place an image of JProfiler (the chosen profiler) on the home page of ovirt.org >> . >> Anyone here knows who has the rights to do that? > > Dave? > >> >> Thanks >> >> >> _______________________________________________ >> 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 mpastern at redhat.com Sat Jul 27 08:42:37 2013 From: mpastern at redhat.com (Michael Pasternak) Date: Sat, 27 Jul 2013 11:42:37 +0300 Subject: [Engine-devel] Fwd: get certificate with SDK In-Reply-To: <51F1E9F7.2080500@redhat.com> References: <000001ce89a6$be34a260$3a9de720$@com> <51F1E9F7.2080500@redhat.com> Message-ID: <51F387FD.5070305@redhat.com> Hi, By default not all data returned in the object as some may be retrieved only via dedicated query that may consume a lot of resources, therefore we've added new concept called All-Content, in the native api you can pass All-Content:True http header to see entire object, ovirt-engine-sdk-python lacks of this capability (for vm specifically) due to a bug in api, this will be addressed in the one of upcoming releases. thanks for reporting. > > > Hi, all: > > I can got all the VM?s information in https://{ovirt-engine}/api/vms/{id} , and I can > > get mostly VM?s informations via ovirt-engine-sdk, but I can?t got via SDK. > > > > This is a part of XML in https://{ovirt-engine}/api/vms/{id} > > > > spice > >
192.168.1.241
> > 5914 > > 5915 > > 1 > > false > > ** > > *O=thtfc.com,CN=allinone241.thtfc.com* > > ** > > false > > > > > > For example, I can port like > > vm.get_display().get_port() > > > > but when I want CN, I tyied use > > vm.get_display().get_certificate().get_subject() > > it return > > > >>>> vm.get_display().get_certificate().get_subject() > > Traceback (most recent call last): > > File "", line 1, in > > AttributeError: 'NoneType' object has no attribute 'get_subject' > > > > _______________________________________________ > 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 alonbl at redhat.com Sun Jul 28 07:46:09 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sun, 28 Jul 2013 03:46:09 -0400 (EDT) Subject: [Engine-devel] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <1121392319.3565764.1374996539046.JavaMail.root@redhat.com> Message-ID: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> Hello All, I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. There are two alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. [[[ There was 3rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ From jhernand at redhat.com Sun Jul 28 09:26:56 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Sun, 28 Jul 2013 11:26:56 +0200 Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> Message-ID: <51F4E3E0.600@redhat.com> On 07/28/2013 09:46 AM, Alon Bar-Lev wrote: > Hello All, > > I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. > > Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host). > > I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. > > There are two alternatives : > > 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. > > Benefit: simplicity. > Benefit: use standard tools. > Benefit: lower payload to transmit. > Drawback: require tar at destination machine. > > 2. Do not use tar but self extracting python script, a patch is ready[1]. > > Benefit: ability to deploy environment in which tar is missing. > Drawback: non standard tool at destination machine. > Drawback: complexity within our code. > > [[[ > There was 3rd alternative, using python tar module to deploy tar. > However, there is a bug in that module when processing last block if empty. > This is edge condition but happened to at least one of the users and I could > reproduce it. > ]]] > > Regards, > Alon Bar-Lev Consider using cpio instead of tar. It is required to build initrd, so available in any installation. It is also supported by the library currently used in the engine to build the tar archive. -- 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 Sun Jul 28 10:42:58 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sun, 28 Jul 2013 06:42:58 -0400 (EDT) Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <51F4E3E0.600@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> Message-ID: <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Juan Hernandez" > To: "Alon Bar-Lev" > Cc: "engine-devel" , "arch" , "users" > Sent: Sunday, July 28, 2013 12:26:56 PM > Subject: Re: [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup > > On 07/28/2013 09:46 AM, Alon Bar-Lev wrote: > > Hello All, > > > > I would like to receive feedback regarding how we should cope with a state > > presented to use by Fedora. > > > > Fedora-19 minimal setup does not install tar utility which is required to > > deploy files during the host-deploy process (Hosts->Add Host). > > > > I guess because of 2.8M in size (including translations) -- a standard > > commonly used utility was removed. > > > > There are two alternatives : > > > > 1. Instruct users who are using minimal installations to manually install > > tar utility just like they configure repository, dns, etc.. > > > > Benefit: simplicity. > > Benefit: use standard tools. > > Benefit: lower payload to transmit. > > Drawback: require tar at destination machine. > > > > 2. Do not use tar but self extracting python script, a patch is ready[1]. > > > > Benefit: ability to deploy environment in which tar is missing. > > Drawback: non standard tool at destination machine. > > Drawback: complexity within our code. > > > > [[[ > > There was 3rd alternative, using python tar module to deploy tar. > > However, there is a bug in that module when processing last block if empty. > > This is edge condition but happened to at least one of the users and I > > could > > reproduce it. > > ]]] > > > > Regards, > > Alon Bar-Lev > > Consider using cpio instead of tar. It is required to build initrd, so > available in any installation. It is also supported by the library > currently used in the engine to build the tar archive. Thanks Juan, it is good idea. I did not thought of using cpio, as I remembered that cpio has no embedded eof (a.cpio+b.cpio=cpio), but now I experiments and see that I was mistaken. Will try to establish a working solution. Thanks, Alon From masayag at redhat.com Sun Jul 28 12:33:27 2013 From: masayag at redhat.com (Moti Asayag) Date: Sun, 28 Jul 2013 08:33:27 -0400 (EDT) Subject: [Engine-devel] VNIC profiles & Device Custom Properties In-Reply-To: <1013791164.11407199.1374581565912.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> <663641499.4577901.1374576949784.JavaMail.root@redhat.com> <1013791164.11407199.1374581565912.JavaMail.root@redhat.com> Message-ID: <1993847417.8505166.1375014807119.JavaMail.root@redhat.com> Hi Amihay, Thank you for your inputs on the feature. See answers in-line for each of the raised issues. ----- Original Message ----- > From: "Amihay Winter" > To: engine-devel at ovirt.org > Cc: "Moti Asayag" , "Livnat Peer" > Sent: Tuesday, July 23, 2013 3:12:45 PM > Subject: VNIC profiles & Device Custom Properties > > Hi all, > > I'm building a TCMS plan for the Device Custom Properties feature and I came > across some questions. > I'm sorry that I'm a little late with my thoughts but I hope you'll still > hear them out. > Also, I know It's a little long but please bear with me :) > > I want to talk about two things: > 1. Sending an updateDevice verb whenever clicking on "Edit" and than "OK". > 2. Setting Port Mirroring at the configuring of a nic and not at the profile. > > 1.According to the Vnic_Profiles's wiki (in the Editing a profile section) it > says: > "The changes will seep down to all VNICs using the profile. > In case VNIC using the edited profile are connected to running VMs, the > change will apply only on the VM next run." > I'll describe a Scenario: > Creating profile A with property speed = 500 > Setting vnic2 on vm to have profile A (using Hotplugnic) > Changing (in the profile) speed = 700 > According to the Vnic_Profiles's wiki, only when I restart my vm I'll get my > setting right. > In my opinion, If we could enable the update of those setting LIVE we will > give the clients a better solution in the Vnic Profiles. > I will be able to update all of my 1000 vms in a few minutes with a single > script instead of restarting them all and maybe stopping others' work. > I think that restarting 1000 vms because I want to set a property is not > something that an admin would want to do. > One way to implement it is to send a verb "updateDevice" each time we open > the the "Edit" window and clicking "OK" > I guess that when the design of update device was made, we tried to send > minimal verbs, but in this case, I think that if a user clicked on "Edit" & > "OK" then he wanted to send the verb, otherwise, he would have pressed on > "Edit" & "Cancel". > > Sending this verb will allow us to keep the vms update with, in my opinion, > minimum cost and with great profit - Giving the client a "more correct > environment" LIVE. The engine-vdsm has a verb for updating a device. It is sent when the engine detect a change in the state of the vnic which requires updating the device. However, the engine doesn't store the vnic profile definition used to activate the vnic. Instead of restarting the VM, the user can plug-unplug the specific device, if it already activated. > > 2. I'll start with saying that in my opinion, the Vnic Profile feature was > created to give the client a *more dynamic network environment* and I > support. > But, I think that the statical variables like MAC, Un/Pluged and Port > Mirroring which always exist should be at the nic and not in the profile. > In my opinion, Profile's properties may have: max_mtu, min_mtu, mtu, speed, > id, vlan... Identifiers for the network. > Maybe I'm missing something but it seems natural to me that the port > mirroring will be at nic and not at the profile. > I'm not sure how port mirroring is commonly used to enable it on vnic level. Having the port mirroring on vnic profile level allows to control the network usage in a concentrated place. In both cases, we're a bit late on schedule, therefore changes would be done later on if required. > I'll really appreciate comments. > Thank you for your time. > Amihay Winter > > ----- Original Message ----- > > > ----- Forwarded Message ----- > > From: "Livnat Peer" > > To: "Moti Asayag" > > Cc: "engine-devel" , "Ofri Masad" > > , "Mike Kolesnik" , "Oved Ourfalli" > > > > Sent: Monday, July 8, 2013 10:11:15 AM > > Subject: Re: VNIC profiles > > > On 07/08/2013 12:36 AM, Moti Asayag wrote: > > > I've updated the wiki accordingly and added few comments inline. > > > > > > ----- Original Message ----- > > >> From: "Livnat Peer" > > >> To: "Moti Asayag" > > >> Cc: "engine-devel" , "Ofri Masad" > > >> , "Mike Kolesnik" , > > >> "Oved Ourfalli" > > >> Sent: Sunday, July 7, 2013 2:59:34 PM > > >> Subject: Re: VNIC profiles > > >> > > >> On 07/07/2013 01:59 PM, Moti Asayag wrote: > > >>> Hi, > > >>> > > >>> I've updated the wiki with the feedbacks from this thread, added a > > >>> backend > > >>> section naming the affected commands and also add added few questions > > >>> of > > >>> my own embedded in the pastedtext below. > > >>> > > >> > > >> Hi Moti, > > >> A good and comprehensive description of the feature behavior. > > >> See my comments bellow - > > >> > > >>> In addition, another question here: > > >>> > > >>> The units within the UI mockups are Mb and Mbps. The libvirt APIs > > >>> expects > > >>> the units to be in kb and kbps. Which component is responsible to > > >>> convert > > >>> them to the expect units ? engine or VDSM ? > > >> > > >> Giuseppe mentioned that in a previous thread on this subject. > > >> Ofri and Giuseppe agreed that the translation would be done on the > > >> engine level. > > >> > > >> > > >>> > > >>> Copied text from the wiki: > > >>> > > >>> Adding a Profile > > >>> > > >>> The network administrator could create several VNIC Profiles for each > > >>> network. He could then grant a users with the permission to use > > >>> (consume) > > >>> each profile. The user will only be able to use profiles which he was > > >>> granted access to. > > >>> > > >>> For example: the network admin will create two VNIC profiles for > > >>> network "blue": > > >>> > > >>> Profile "Gold" - with better QoS and with port mirroring > > >>> Profile "Silver" with lower QoS and without port mirroring. > > >>> > > >> > > >> I would use other names for the profiles to avoid confusion. > > >> Gold and Silver are likely to be QoS object names, a more typical name > > >> for a network profile is - teachers-blue and students-blue > > >> > > >> The different profiles can have different QoS (teachers-blue would get > > >> Gold QoS while Students-blue will have Silver). > > >> > > >> > > >>> He will then define the user-group "students" as user of profile > > >>> "Silver" and user-group "teachers" as user of profile "Gold". In this > > >>> case the teachers will enjoy better quality of service then the > > >>> students. When a teacher will add/edit a virtual NIC he could select > > >>> profile "Gold" for that NIC - the VNIC will be connected to network > > >>> "blue" with high QoS and with port mirroring. > > >>> > > >>> Question: In the same matter we allowed via the UI to grant > > >>> 'NetworkUser' > > >>> to 'everyone' user, wouldn't it ease the use of Profiles if we support > > >>> it > > >>> in this context as well? > > >> > > >> The ease of use could be that when creating a network we'll display in > > >> the UI all VNIC-QoS-objects and the users could tick next to the QoS > > >> they are interested in, for each QoS that was chosen a profile would be > > >> created. > > >> > > >> I would enhance that with youe suggestion above and display next to the > > >> QoS that was checked the option to mark 'Allow All users' like we have > > >> today for making a network public, this option would give permission to > > >> everyone on that profile. > > >> > > >> > > >>> > > >>> Editing a Profile > > >>> > > >>> A user should be able to edit the profile properties (including profile > > >>> name) while VMs are attached and are using this Profile (reference > > >>> should be done by id). > > >>> Changing the network of a vNic profile will be allowed only if no VMs > > >>> are using the profile. > > >> > > >> It would be better if we can limit this to no running VM is using the > > >> profile (or more simple to implement if all VMs that are using this > > >> profile are in status down). > > > > > > Allowing to delete a vnic profile when used by vms is asymmetric to the > > > network removal > > > when it is used by vms or templates. Today the update network operation > > > is > > > blocked for that. > > > In addition, with the suggest simplification to remove a profile when no > > > running vms, the user > > > will have to find for himself if the profile is being used prior to its > > > removal since the > > > operation will not be blocked. > > > > > > If we allow to delete a vnic profile, when a vm is using it (regardless > > > the > > > VM status) > > > we'll have to update the VM entity as well in that operation: since we do > > > not support a > > > network with 'none' profile, we'll have to delete the network as well. > > > > > > If we'll remove a vnic profile in 3.1 cluster, used by vms in status > > > down, > > > we'd find a case > > > in which a VM is attached to a 'none' network. This is unsupported in 3.1 > > > cluster. We can block > > > such operation, but this is another motivation why we'd better not to > > > allow > > > removing a used profile. > > > > > > The context above is about editing not deleting :) > > I agree with what you wrote if the context was remove. > > > >> > > >>> Since we have no way to distinguish between running and current > > >>> configurations, the expected behavior of such a change is > > >>> unpredictable and less intuitive to the user (especially since > > >>> dynamic wiring is supported). > > >>> The changes will seep down to all VNICs using the profile. > > >>> In case VNIC using the edited profile are connected to running VMs, > > >>> the change will apply only on the VM next run. > > >>> > > >>> Question: What about Hibernate/Suspend VM ? will the resume VM action > > >>> uses > > >>> the original configuration for the vnics when the VM was started ? > > >> > > >> Currently profile includes: network, port-mirroring, custom property, > > >> QoS > > >> > > >> Changing any of the above (except for network) requires a VM reboot, so > > >> I think that we can start with the following statement - the profile > > >> change would only apply after next VM reboot. > > >> > > >> There are 2 problems with the above: > > >> - Today we support network wiring, with VNIC profiles we are asking the > > >> users to create a new profile and attach the VMs to the new profile, I > > >> can see the RFE coming - we can report that ourselves ;) > > >> > > >> - We don't reflect with which configuration the VM is running, e.g we > > >> edited the profile QoS but I'm not sure with which QoS the VM is > > >> currently running. (The RFE for differentiating between current > > >> configuration and running configuration was already asked for by > > >> numerous users) > > >> > > >> The above is a general issue that we need to solve and I would not limit > > >> editing VNIC profiles because of it. > > >> We can mitigate this specifically for QoS like described bellow. > > >> > > >> > > >> > > >>> Deleting a Profile > > >>> > > >>> VNIC Profiles could not be deleted from the engine as long as one or > > >>> more > > >>> VM/Templates are using those profiles. > > >> > > >>> Reporting vNic actual configuration > > >>> > > >>> The engine will retrieve the actual configuration of the profile > > >>> properties on the VNIC from VDSM (using the network statistics > > >>> mechanism) and the networked administrator will be presented with the > > >>> state of each VNIC (synched/unsynched). > > >>> > > >> > > >> Will the admin be able to see the actual values? I think the synced > > >> property is not enough (I'm not sure how interesting this property is to > > >> start with). > > > > > > We can extend the VmGuestAgentInterface to contain the actual value, so > > > they > > > will be presented for each vnic in the 'guest data' sub-tab. > > > > > > AFAIU this info does not come from the guest it is info we retrieve from > > libvirt. > > The VmGuestAgentInterface should be used only for information reported > > by the guest, information whose credibility can be questioned. > > > >> > > >>> Editing a VNIC / Changing a VNIC profile > > >>> > > >>> Changing the profile a VM is using while the VM is running should > > >>> behave like dynamic wiring (changing the VM network while it is > > >>> running). > > >>> Hot-plug of a vnic will will use will use the updated profile connected > > >>> to the VNIC. > > >>> > > >> > > >> Not sure I fully understand the sentence above. > > >> Hot plug will be fully supported, you can choose any profile (you have > > >> permissions on) while plugging a new device. > > >> > > > > > > That was the intention. seems like an edgy hand syndrome :) > > > Changed to: > > > * Hot plug will be fully supported: the user can choose any permitted > > > profile while plugging a new device or when activating an existing one. > > > > > >>> Adding a Network > > >>> > > >>> When adding a network, a user can provide an option to create a vNic > > >>> Profile for it. > > >>> > > >>> Question: Is it s default profile ? what are its properties ? > > >>> Question: What about 'Public Use' option ? Are they still relevant in > > >>> the > > >>> context of adding new networks or we should eliminate them and move it > > >>> only to 'Add vNic Profile' dialog? > > >>> > > >> > > >> see previous comments > > >> In addition when creating a profile we should have 'Allow all' for > > >> implicitly creating permissions, like we have today for network. > > >> > > >>> Updating a Network > > >>> > > >>> When a network role is modified to be a 'non-VM network', all vNic > > >>> profiles > > >>> associated with it should be deleted. > > >> > > >> And permissions associated with these profiles > > >> > > >>> Removing a Network > > >>> > > >>> Should remove all profiles on that network > > >>> > > >> > > >> And associated permissions > > >> > > >>> Adding an Empty Data-Center > > >>> > > >>> Currently, When creating a new Data-Center, the management network is > > >>> automatically created. > > >>> From 3.3, a default vNic profile will be created for the management > > >>> network. > > >>> > > >>> VM snapshot/import/export > > >>> > > >>> We should handle VMs that are pointing to a network directly for > > >>> backward compatibility. > > >>> We need to select first profile that is on that network that the user > > >>> has permissions on. > > >>> > > >>> Question: Do we wish to support it export from 3.3 and import to 3.2 or > > >>> below? > > >> > > >> That means that when you write a VM in the OVF you need to write network > > >> in addition to profile. > > >> > > > > > > The network name is already there, so when importing a vnic from 3.3 to > > > an > > > earlier version > > > the profile name will be ignored. > > > > > >> > > >>> Question: A user can import/export a VM/Template even if he doesn't > > >>> have > > >>> permissions on the networks. Is the next flow valid ? > > >>> > > >>> The profile name should be saved in the OVF (in addition to the network > > >>> name which is saved today). > > >>> During import, if both (network name, profile name) exist on the target > > >>> DC, the vnic will get the profile id. > > >>> If the network exists in the Data-Center, but has no profile as > > >>> specified in the OVF, the user will be notified (event log) and the > > >>> VNIC will be connected to a default minimal profile defined in the > > >>> system, regardless the permissions the user has on the network. > > >>> > > >> > > >> What is a 'default minimal profile' ? I would rather have a VNIC with no > > >> profile associated with it. > > > > > > The 'default minimal profile' refers to a vnic profile with the lower > > > average bandwidth. > > > > > > With the approach you've suggested, any imported VM/Template from an > > > earlier to 3.3 version > > > will require a manual intervention in order to configure a network to the > > > VM. > > > I should have elaborated some more - > > > If a VM has a profile then we should look up this specific profile, if > > such a profile does not exists then import the VM with profile none like > > we do today for VM's with reference to a network that does not exist on > > the setup. > > > If a VM does not have a profile (3.2 and lower versions) we should look > > into the network name, if this network exist and we have a profile with > > permissions to the user then use this profile (if there is more than one > > choose one randomly). > > > > And for 3.1 we'll have to drop such vnics since network 'none' isn't > > > supported. > > > > > >> > > >>> If failed to find any matching vNic profile, the vnic's profile will be > > >>> set > > >>> with 'none'. > > >>> > > >>> When a Template is created from a VM the VNIC Profile will be kept > > >>> along with the VNIC. When a VM is created from template the VNIC > > >>> Profiles will be taken from the template's VNICs. > > >>> > > >>> ----- Original Message ----- > > >>>> From: "Livnat Peer" > > >>>> To: "engine-devel" , "Ofri Masad" > > >>>> > > >>>> Cc: "Mike Kolesnik" , "Moti Asayag" > > >>>> , "Oved Ourfalli" > > >>>> Sent: Sunday, June 30, 2013 3:59:37 PM > > >>>> Subject: VNIC profiles > > >>>> > > >>>> Hi, > > >>>> > > >>>> We are working on adding VNIC profiles as part of the work to add VNIC > > >>>> QoS. > > >>>> > > >>>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles > > >>>> > > >>>> We need to define some of the system behavior followed by this change, > > >>>> here is my take - > > >>>> > > >>>> Editing a profile - > > >>>> -------------------- > > >>>> A user should be able to edit the profile properties (including > > >>>> profile > > >>>> name) while VMs are attached and are using this Profile (reference > > >>>> should be done by id). > > >>>> > > >>>> Changing the network though is a bit more tricky as long as we don't > > >>>> have a way to distinguish between running and current configurations I > > >>>> think it could be very confusing to the user. Especially since we > > >>>> support dynamic wiring so the behavior IMO is unpredictable. > > >>>> I think it should be blocked at this point. > > >>>> > > >>>> > > >>>> Edit a VNIC / change a VNIC profile - > > >>>> ------------------------------------ > > >>>> Changing the profile a VM is using while the VM is running should > > >>>> behave > > >>>> like dynamic wiring (changing the VM network while it is running). > > >>>> > > >>>> > > >>>> Remove a Profile - > > >>>> ------------------- > > >>>> Is only valid if all VMs that are using this profile are in status > > >>>> down. > > >>>> It should update all VMs to point to no profile which should behave > > >>>> like > > >>>> none network today. > > >>>> > > >>>> I see no reason to support a profile on a none network at this point. > > >>>> > > >>>> The above is also relevant for upgrade flow (upgrading none network to > > >>>> point to no profile) > > >>>> > > >>>> > > >>>> Removing a Network - > > >>>> ---------------------- > > >>>> should remove all profiles on that network > > >>>> > > >>>> > > >>>> VM snapshot/import/export - > > >>>> -------------------------- > > >>>> We should handle VMs that are pointing to a network directly for b/w > > >>>> compatibility. > > >>>> we need to select first profile that is on that network that the user > > >>>> has permissions on. > > >>>> > > >>>> > > >>>> I assume there are more, comments are welcome > > >>>> > > >>>> Thanks, Livnat > > >>>> > > >>>> > > >> > > >> > From eedri at redhat.com Sun Jul 28 13:09:52 2013 From: eedri at redhat.com (Eyal Edri) Date: Sun, 28 Jul 2013 09:09:52 -0400 (EDT) Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_unit_tests - Build # 4737 - Still Unstable! In-Reply-To: <10745147.4813.1375014320351.JavaMail.jenkins@jenkins.ovirt.org> References: <1920774544.4809.1375013350349.JavaMail.jenkins@jenkins.ovirt.org> <10745147.4813.1375014320351.JavaMail.jenkins@jenkins.ovirt.org> Message-ID: <202303651.8507317.1375016992958.JavaMail.root@redhat.com> fyi, the following patch [1] caused new unit tests failures: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/4733/ [1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git&a=commit&h=3806a44b33e303c89c8b4b03c902944d6784a44e ----- 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, obasan at redhat.com, > gerrit2 at gerrit.ovirt.org > Sent: Sunday, July 28, 2013 3:25:18 PM > Subject: [oVirt Jenkins] ovirt_engine_unit_tests - Build # 4737 - Still Unstable! > > Project: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/ > Build: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/4737/ > Build Number: 4737 > Build Status: Still Unstable > Triggered By: Started by an SCM change > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #4733 > [Vojtech Szocs] core: i18n welcome page with branding > > > Changes for Build #4734 > [Vojtech Szocs] userportal,webadmin: Frontend refactor > > > Changes for Build #4735 > [Gerrit Code Review] packaging: update README.developer broken by feefb12b > > [Gerrit Code Review] webadmin: support Memory Balloon > > [Gerrit Code Review] packaging: setup: fix pep8 issue > > > Changes for Build #4736 > [Gilad Chaplik] webadmin: Fix QoS validator error tooltip > > [Gilad Chaplik] core: Add Audit log messages for Quota "Audit" mode > > [Gilad Chaplik] webadmin: cluster policy look & feel enhancements > > [Gerrit Code Review] packaging: spec: create ovirt user for > ovirt-websocket-proxy > > > Changes for Build #4737 > [Gerrit Code Review] packaging: setup: produce and manage setup logs at > /var/log > > > > > ----------------- > Failed Tests: > ----------------- > 2 tests failed. > FAILED: > org.ovirt.engine.core.WelcomeServletTest.testDoGetHttpServletRequestHttpServletResponseNoDispatcher > > Error Message: > null > > Stack Trace: > java.lang.NullPointerException > at > org.ovirt.engine.core.utils.branding.BrandingManager.getWelcomeSections(BrandingManager.java:247) > at org.ovirt.engine.core.WelcomeServlet.doGet(WelcomeServlet.java:104) > at > org.ovirt.engine.core.WelcomeServletTest.testDoGetHttpServletRequestHttpServletResponseNoDispatcher(WelcomeServletTest.java:65) > 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:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.mockito.internal.runners.JUnit45AndHigherRunnerImpl.run(JUnit45AndHigherRunnerImpl.java:37) > at org.mockito.runners.MockitoJUnitRunner.run(MockitoJUnitRunner.java:62) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > 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:606) > at > org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > > > FAILED: > org.ovirt.engine.core.WelcomeServletTest.testDoGetHttpServletRequestHttpServletResponseWithDispatcher > > Error Message: > null > > Stack Trace: > java.lang.NullPointerException > at > org.ovirt.engine.core.utils.branding.BrandingManager.getWelcomeSections(BrandingManager.java:247) > at org.ovirt.engine.core.WelcomeServlet.doGet(WelcomeServlet.java:104) > at > org.ovirt.engine.core.WelcomeServletTest.testDoGetHttpServletRequestHttpServletResponseWithDispatcher(WelcomeServletTest.java:75) > 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:606) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.mockito.internal.runners.JUnit45AndHigherRunnerImpl.run(JUnit45AndHigherRunnerImpl.java:37) > at org.mockito.runners.MockitoJUnitRunner.run(MockitoJUnitRunner.java:62) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > 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:606) > at > org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > > > > > From mkolesni at redhat.com Sun Jul 28 14:42:40 2013 From: mkolesni at redhat.com (Mike Kolesnik) Date: Sun, 28 Jul 2013 10:42:40 -0400 (EDT) Subject: [Engine-devel] Join us in a deep dive into the oVirt-Neutron integration Message-ID: <405855399.6950278.1375022559989.JavaMail.root@redhat.com> The following is a new meeting request: Subject: Join us in a deep dive into the oVirt-Neutron integration Organizer: "Mike Kolesnik" Time: Wednesday, July 31, 2013, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem Invitees: users at ovirt.org; engine-devel at ovirt.org *~*~*~*~*~*~*~*~*~* Hi everyone, As you may know, In oVirt 3.3 we're releasing an integration of OpenStack Networking service (a.k.a. Neutron) as another way to define & use VM networks, besides the good old Linux Bridge support in VDSM. You're all invited to join us in a deep dive into this integration, highlighting the way it works, the value it brings and how it can be further extended. The session will take place on Wednesday, Jul 31 , 2013 from 4:00 PM to 5:00 PM GMT +02:00 (Jerusalem) The session will be done via Elluminate: https://sas.elluminate.com/m.jnlp?sid=819&password=M.DF0344C0EEC820394D37F89D9BE68C There will also be a teleconferencing bridge available via Intercall: Bridge id: 972506565679 Phone numbers: http://www.ovirt.org/Intercall Regards, Mike & Livnat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 4541 bytes Desc: not available URL: From wlbleaboy at 126.com Mon Jul 29 03:25:48 2013 From: wlbleaboy at 126.com (wlbleaboy@126) Date: Mon, 29 Jul 2013 11:25:48 +0800 Subject: [Engine-devel] Fwd: get certificate with SDK In-Reply-To: <51F387FD.5070305@redhat.com> References: <000001ce89a6$be34a260$3a9de720$@com> <51F1E9F7.2080500@redhat.com> <51F387FD.5070305@redhat.com> Message-ID: <000901ce8c0b$55b5cdb0$01216910$@com> Thanks for Itamar Heim: Could I take part in it? -----Original Message----- From: Michael Pasternak [mailto:mpastern at redhat.com] Sent: Saturday, July 27, 2013 4:43 PM To: leaboy at 126; engine-devel Cc: Itamar Heim Subject: Re: Fwd: [Engine-devel] get certificate with SDK Hi, By default not all data returned in the object as some may be retrieved only via dedicated query that may consume a lot of resources, therefore we've added new concept called All-Content, in the native api you can pass All-Content:True http header to see entire object, ovirt-engine-sdk-python lacks of this capability (for vm specifically) due to a bug in api, this will be addressed in the one of upcoming releases. thanks for reporting. > > > Hi, all: > > I can got all the VM?s information in https://{ovirt-engine}/api/vms/{id} , and I can > > get mostly VM?s informations via ovirt-engine-sdk, but I can?t got via SDK. > > > > This is a part of XML in https://{ovirt-engine}/api/vms/{id} > > > > spice > >
192.168.1.241
> > 5914 > > 5915 > > 1 > > false > > ** > > *O=thtfc.com,CN=allinone241.thtfc.com* > > ** > > false > > > > > > For example, I can port like > > vm.get_display().get_port() > > > > but when I want CN, I tyied use > > vm.get_display().get_certificate().get_subject() > > it return > > > >>>> vm.get_display().get_certificate().get_subject() > > Traceback (most recent call last): > > File "", line 1, in > > AttributeError: 'NoneType' object has no attribute 'get_subject' > > > > _______________________________________________ > 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 alonbl at redhat.com Mon Jul 29 07:15:33 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Mon, 29 Jul 2013 03:15:33 -0400 (EDT) Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> Message-ID: <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Juan Hernandez" > Cc: "engine-devel" , "arch" , "users" > Sent: Sunday, July 28, 2013 1:42:58 PM > Subject: Re: [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup > > > > ----- Original Message ----- > > From: "Juan Hernandez" > > To: "Alon Bar-Lev" > > Cc: "engine-devel" , "arch" , > > "users" > > Sent: Sunday, July 28, 2013 12:26:56 PM > > Subject: Re: [Users] [Feedback required][host-deploy] Fedora-19 misses tar > > at minimal setup > > > > On 07/28/2013 09:46 AM, Alon Bar-Lev wrote: > > > Hello All, > > > > > > I would like to receive feedback regarding how we should cope with a > > > state > > > presented to use by Fedora. > > > > > > Fedora-19 minimal setup does not install tar utility which is required to > > > deploy files during the host-deploy process (Hosts->Add Host). > > > > > > I guess because of 2.8M in size (including translations) -- a standard > > > commonly used utility was removed. > > > > > > There are two alternatives : > > > > > > 1. Instruct users who are using minimal installations to manually install > > > tar utility just like they configure repository, dns, etc.. > > > > > > Benefit: simplicity. > > > Benefit: use standard tools. > > > Benefit: lower payload to transmit. > > > Drawback: require tar at destination machine. > > > > > > 2. Do not use tar but self extracting python script, a patch is ready[1]. > > > > > > Benefit: ability to deploy environment in which tar is missing. > > > Drawback: non standard tool at destination machine. > > > Drawback: complexity within our code. > > > > > > [[[ > > > There was 3rd alternative, using python tar module to deploy tar. > > > However, there is a bug in that module when processing last block if > > > empty. > > > This is edge condition but happened to at least one of the users and I > > > could > > > reproduce it. > > > ]]] > > > > > > Regards, > > > Alon Bar-Lev > > > > Consider using cpio instead of tar. It is required to build initrd, so > > available in any installation. It is also supported by the library > > currently used in the engine to build the tar archive. > > Thanks Juan, it is good idea. > > I did not thought of using cpio, as I remembered that cpio has no embedded > eof (a.cpio+b.cpio=cpio), but now I experiments and see that I was mistaken. > > Will try to establish a working solution. Done[1]. Thanks! host-deploy: use cpio instead of tar for bundle transfer for some reason fedora-18/19 got tar out of base system, so we are forced to find some solution, although manual configuration is required anyway (repository, networking etc...). there was attempt to use python tar module, however this module has a bug when last block is empty, so it is not suitable for usage. cpio is alternative for fedora, however it is rightfully missing from other distributions as it is much less used. as we do not support hosts using different distributions, we are ok now. in future, we can use python self extract script, work already performed at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of complexity. Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca Signed-off-by: Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17396/ From eedri at redhat.com Mon Jul 29 07:42:25 2013 From: eedri at redhat.com (Eyal Edri) Date: Mon, 29 Jul 2013 03:42:25 -0400 (EDT) Subject: [Engine-devel] [oVirt Jenkins] ovirt_engine_gwt_user - Build # 4736 - Failure! In-Reply-To: <750040929.4974.1375083176613.JavaMail.jenkins@jenkins.ovirt.org> References: <750040929.4974.1375083176613.JavaMail.jenkins@jenkins.ovirt.org> Message-ID: <1782362449.8983611.1375083745969.JavaMail.root@redhat.com> fyi, gwt compilations on gwt-user & gwt-admin are failing post these commits. changed: http://jenkins.ovirt.org/job/ovirt_engine_gwt_admin/4925/changes#detail5 error: http://jenkins.ovirt.org/job/ovirt_engine_gwt_admin/4925/console Eyal. oVirt 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, gerrit2 at gerrit.ovirt.org > Sent: Monday, July 29, 2013 10:32:56 AM > Subject: [oVirt Jenkins] ovirt_engine_gwt_user - Build # 4736 - Failure! > > Project: http://jenkins.ovirt.org/job/ovirt_engine_gwt_user/ > Build: http://jenkins.ovirt.org/job/ovirt_engine_gwt_user/4736/ > Build Number: 4736 > Build Status: Failure > Triggered By: Started by an SCM change > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #4736 > [Gerrit Code Review] packaging: setup: allow uninstall ca,cert.conf > > [Gerrit Code Review] engine:Trusted Compute Pools - Open Attestation > integration with oVirt engine > > [Gerrit Code Review] engine:Trusted Compute Pools - Open Attestation > integration with oVirt engine > > [Gerrit Code Review] engine:Trusted Compute Pools - Open Attestation > integration with oVirt engine > > [Gerrit Code Review] engine:Trusted Compute Pools - Open Attestation > integration with oVirt engine > > [Gerrit Code Review] engine:Trusted Compute Pools - Open Attestation > integration with oVirt engine > > > > > ----------------- > Failed Tests: > ----------------- > No tests ran. > > From fsimonce at redhat.com Mon Jul 29 09:44:21 2013 From: fsimonce at redhat.com (Federico Simoncelli) Date: Mon, 29 Jul 2013 05:44:21 -0400 (EDT) Subject: [Engine-devel] oVirt - Glance Integration Deep Dive Session Message-ID: <1022963017.7822903.1375091061913.JavaMail.root@redhat.com> The following is a new meeting request: Subject: oVirt - Glance Integration Deep Dive Session Organizer: "Federico Simoncelli" Time: Tuesday, July 30, 2013, 3:00:00 PM - 4:00:00 PM GMT +01:00 Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna Invitees: users at ovirt.org; engine-devel at ovirt.org *~*~*~*~*~*~*~*~*~* Hi everyone, on Tuesday at 3pm (CEST) I will be presenting the recent work done in integrating OpenStack Glance into oVirt 3.3. The presentation will include both a high level overview (usage in webadmin) and a deep dive about the low level implementation details. When: Tue 30 Jul 2013 15:00 - 16:00 (CEST) Where: https://sas.elluminate.com/m.jnlp?sid=819&password=M.9E565882E4EA0288E3479F3D2141BD Bridge: 8425973915# Phone numbers: http://www.ovirt.org/Intercall -- Federico -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 2068 bytes Desc: not available URL: From leonardo.bianconi at eldorado.org.br Mon Jul 29 13:02:22 2013 From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi) Date: Mon, 29 Jul 2013 13:02:22 +0000 Subject: [Engine-devel] JDK Failures with .gwttar In-Reply-To: <51EFC10E.3050108@redhat.com> References: <50EB20226B72D6419356FC320AB62B8719171584@SERV070.corp.eldorado.org.br> <51EEA4CC.3000707@redhat.com> <50EB20226B72D6419356FC320AB62B87191716B5@SERV070.corp.eldorado.org.br> <51EFC10E.3050108@redhat.com> Message-ID: <50EB20226B72D6419356FC320AB62B871917181E@SERV070.corp.eldorado.org.br> >-----Original Message----- >From: Itamar Heim [mailto:iheim at redhat.com] >Sent: quarta-feira, 24 de julho de 2013 08:57 >To: Leonardo Bianconi >Cc: Vitor de Lima; Gustavo Frederico Temple Pedrosa; engine-devel; Vojtech Szocs; Alon Bar-Lev; Juan Antonio Hernandez Fernandez >Subject: Re: JDK Failures with .gwttar > >On 07/24/2013 02:46 PM, Leonardo Bianconi wrote: >> >> >>> -----Original Message----- >>> From: Itamar Heim [mailto:iheim at redhat.com] >>> Sent: ter?a-feira, 23 de julho de 2013 12:44 >>> To: Leonardo Bianconi >>> Cc: Vitor de Lima; Gustavo Frederico Temple Pedrosa; engine-devel; >>> Vojtech Szocs; Alon Bar-Lev >>> Subject: Re: JDK Failures with .gwttar >>> >>> On 07/23/2013 05:28 PM, Leonardo Bianconi wrote: >>>> Hi Itamar! >>>> >>>> After rebasing our patches against the master branch from the git >>>> repository, we noticed that the current version of the oVirt engine >>>> uses a new version of GWT. This introduced a problem while building >>>> the engine, which is documented in this link: >>>> >>>> "IBM JDK failures with .gwtar and compile" - >>>> https://code.google.com/p/google-web-toolkit/issues/detail?id=7530 >>>> >>>> The problem here is that we are using a different JVM (the IBM's >>>> one) than the one that compiled the gwt files. In the beginning, we >>>> tried to use the Open JDK, but it was too slow to be used, it takes >>>> about 1h20m to build everything against 7m of IBM JDK, so we are using the IBM one. >>>> >>>> We have a question, as we are working on oVirt to work with >>>> different architectures, should we work on fixes when we find a problem like that? >>>> For this issue we got a workaround, using an parameter on the build >>>> command and removing the gwt cached files. >>> >>> Hi Leonardo, >>> >>> yes, we should strive to fix these things. >>> it would be even better if we can detect them earlier, by having a >>> jenkins ppc slave to the ovirt jenkins, or just a local jenkins by you which will report when a patch breaks on ppc/ibm jdk for further >consideration). >>> >>> questions: >>> 1. is there a bug right now to fix? we need the build to know to add the modifier when using ibm jdk. >> No, there is no bug in the oVirt project, it's only about the way it builds. We compiled it following the workaround: >> "As a workaround, you can also simply remove the .gwtar files from gwt-user.jar. I think there's also a -Dgwt.usearchives=false >system property to disable loading the gwtar files." >> >> The real problem is that the gwt jar contains some serializable files already compiled. Seems gwt developers are looking for a >solution, so we could wait a gwt solution before try to fix it. > >well, it failed us as well - could be this (late last night) solves it for you as well: >http://gerrit.ovirt.org/#/c/17264/ > > >>> >>> 2. (added alon) i remember we actually have an issue with ibm jdk wrt certificates or something which is worth considering in this >>> context. >> We didn't know about it, I will check that. >>> >>> 3. do you have more details on the openjdk performance issue on ppc to try and fix that one? can you open a bug on this and >forward >>> to us? >> We haven't analyzed why it happens, but we know the problem is in the gwt packages, because the compilation time of the other >packages are normal. We will compile the oVirt project with both JDKs and attach in the bug the output where it says the compilation >time for each package, then I forward it for you. I've opened the but for the OpenJDK performance - https://bugs.openjdk.java.net/show_bug.cgi?id=100322 Any additional info for that, you can ask me. Regards Leonardo Bianconi >>> >>> Thanks, >>> Itamar >> >> Thanks, >> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa >> From awinter at redhat.com Mon Jul 29 13:57:44 2013 From: awinter at redhat.com (Amihay Winter) Date: Mon, 29 Jul 2013 09:57:44 -0400 (EDT) Subject: [Engine-devel] VNIC profiles & Device Custom Properties In-Reply-To: <1993847417.8505166.1375014807119.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <1677136307.170396.1373194789480.JavaMail.root@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> <663641499.4577901.1374576949784.JavaMail.root@redhat.com> <1013791164.11407199.1374581565912.JavaMail.root@redhat.com> <1993847417.8505166.1375014807119.JavaMail.root@redhat.com> Message-ID: <417283555.17897435.1375106264140.JavaMail.root@redhat.com> Hi Moti, Thanks for the quick response, Please look down at the comment. Amihay ----- Original Message ----- > From: "Moti Asayag" > To: "Amihay Winter" > Cc: engine-devel at ovirt.org, "Livnat Peer" > Sent: Sunday, July 28, 2013 3:33:27 PM > Subject: Re: VNIC profiles & Device Custom Properties > Hi Amihay, > Thank you for your inputs on the feature. See answers in-line for each of the > raised issues. > ----- Original Message ----- > > From: "Amihay Winter" > > To: engine-devel at ovirt.org > > Cc: "Moti Asayag" , "Livnat Peer" > > Sent: Tuesday, July 23, 2013 3:12:45 PM > > Subject: VNIC profiles & Device Custom Properties > > > > Hi all, > > > > I'm building a TCMS plan for the Device Custom Properties feature and I > > came > > across some questions. > > I'm sorry that I'm a little late with my thoughts but I hope you'll still > > hear them out. > > Also, I know It's a little long but please bear with me :) > > > > I want to talk about two things: > > 1. Sending an updateDevice verb whenever clicking on "Edit" and than "OK". > > 2. Setting Port Mirroring at the configuring of a nic and not at the > > profile. > > > > 1.According to the Vnic_Profiles's wiki (in the Editing a profile section) > > it > > says: > > "The changes will seep down to all VNICs using the profile. > > In case VNIC using the edited profile are connected to running VMs, the > > change will apply only on the VM next run." > > I'll describe a Scenario: > > Creating profile A with property speed = 500 > > Setting vnic2 on vm to have profile A (using Hotplugnic) > > Changing (in the profile) speed = 700 > > According to the Vnic_Profiles's wiki, only when I restart my vm I'll get > > my > > setting right. > > In my opinion, If we could enable the update of those setting LIVE we will > > give the clients a better solution in the Vnic Profiles. > > I will be able to update all of my 1000 vms in a few minutes with a single > > script instead of restarting them all and maybe stopping others' work. > > I think that restarting 1000 vms because I want to set a property is not > > something that an admin would want to do. > > One way to implement it is to send a verb "updateDevice" each time we open > > the the "Edit" window and clicking "OK" > > I guess that when the design of update device was made, we tried to send > > minimal verbs, but in this case, I think that if a user clicked on "Edit" & > > "OK" then he wanted to send the verb, otherwise, he would have pressed on > > "Edit" & "Cancel". > > > > Sending this verb will allow us to keep the vms update with, in my opinion, > > minimum cost and with great profit - Giving the client a "more correct > > environment" LIVE. > The engine-vdsm has a verb for updating a device. It is sent when the engine > detect a change in the state of the vnic which requires updating the device. > However, the engine doesn't store the vnic profile definition used to > activate > the vnic. > Instead of restarting the VM, the user can plug-unplug the specific device, > if > it already activated. I know that plug/unplug the specific device will propagate the change but why use only the hotplug & hotunplug verbs? why not using the updateDevice verb as well? Isn't LIVE (without losing connectivity to vm (because the hotunplug)) is better? > > > > 2. I'll start with saying that in my opinion, the Vnic Profile feature was > > created to give the client a *more dynamic network environment* and I > > support. > > But, I think that the statical variables like MAC, Un/Pluged and Port > > Mirroring which always exist should be at the nic and not in the profile. > > In my opinion, Profile's properties may have: max_mtu, min_mtu, mtu, speed, > > id, vlan... Identifiers for the network. > > Maybe I'm missing something but it seems natural to me that the port > > mirroring will be at nic and not at the profile. > > > I'm not sure how port mirroring is commonly used to enable it on vnic level. > Having the port mirroring on vnic profile level allows to control the network > usage in a concentrated place. > In both cases, we're a bit late on schedule, therefore changes would be done > later on if required. > > I'll really appreciate comments. > > Thank you for your time. > > Amihay Winter > > > > ----- Original Message ----- > > > > > ----- Forwarded Message ----- > > > From: "Livnat Peer" > > > To: "Moti Asayag" > > > Cc: "engine-devel" , "Ofri Masad" > > > , "Mike Kolesnik" , "Oved > > > Ourfalli" > > > > > > Sent: Monday, July 8, 2013 10:11:15 AM > > > Subject: Re: VNIC profiles > > > > > On 07/08/2013 12:36 AM, Moti Asayag wrote: > > > > I've updated the wiki accordingly and added few comments inline. > > > > > > > > ----- Original Message ----- > > > >> From: "Livnat Peer" > > > >> To: "Moti Asayag" > > > >> Cc: "engine-devel" , "Ofri Masad" > > > >> , "Mike Kolesnik" , > > > >> "Oved Ourfalli" > > > >> Sent: Sunday, July 7, 2013 2:59:34 PM > > > >> Subject: Re: VNIC profiles > > > >> > > > >> On 07/07/2013 01:59 PM, Moti Asayag wrote: > > > >>> Hi, > > > >>> > > > >>> I've updated the wiki with the feedbacks from this thread, added a > > > >>> backend > > > >>> section naming the affected commands and also add added few questions > > > >>> of > > > >>> my own embedded in the pastedtext below. > > > >>> > > > >> > > > >> Hi Moti, > > > >> A good and comprehensive description of the feature behavior. > > > >> See my comments bellow - > > > >> > > > >>> In addition, another question here: > > > >>> > > > >>> The units within the UI mockups are Mb and Mbps. The libvirt APIs > > > >>> expects > > > >>> the units to be in kb and kbps. Which component is responsible to > > > >>> convert > > > >>> them to the expect units ? engine or VDSM ? > > > >> > > > >> Giuseppe mentioned that in a previous thread on this subject. > > > >> Ofri and Giuseppe agreed that the translation would be done on the > > > >> engine level. > > > >> > > > >> > > > >>> > > > >>> Copied text from the wiki: > > > >>> > > > >>> Adding a Profile > > > >>> > > > >>> The network administrator could create several VNIC Profiles for each > > > >>> network. He could then grant a users with the permission to use > > > >>> (consume) > > > >>> each profile. The user will only be able to use profiles which he was > > > >>> granted access to. > > > >>> > > > >>> For example: the network admin will create two VNIC profiles for > > > >>> network "blue": > > > >>> > > > >>> Profile "Gold" - with better QoS and with port mirroring > > > >>> Profile "Silver" with lower QoS and without port mirroring. > > > >>> > > > >> > > > >> I would use other names for the profiles to avoid confusion. > > > >> Gold and Silver are likely to be QoS object names, a more typical name > > > >> for a network profile is - teachers-blue and students-blue > > > >> > > > >> The different profiles can have different QoS (teachers-blue would get > > > >> Gold QoS while Students-blue will have Silver). > > > >> > > > >> > > > >>> He will then define the user-group "students" as user of profile > > > >>> "Silver" and user-group "teachers" as user of profile "Gold". In this > > > >>> case the teachers will enjoy better quality of service then the > > > >>> students. When a teacher will add/edit a virtual NIC he could select > > > >>> profile "Gold" for that NIC - the VNIC will be connected to network > > > >>> "blue" with high QoS and with port mirroring. > > > >>> > > > >>> Question: In the same matter we allowed via the UI to grant > > > >>> 'NetworkUser' > > > >>> to 'everyone' user, wouldn't it ease the use of Profiles if we > > > >>> support > > > >>> it > > > >>> in this context as well? > > > >> > > > >> The ease of use could be that when creating a network we'll display in > > > >> the UI all VNIC-QoS-objects and the users could tick next to the QoS > > > >> they are interested in, for each QoS that was chosen a profile would > > > >> be > > > >> created. > > > >> > > > >> I would enhance that with youe suggestion above and display next to > > > >> the > > > >> QoS that was checked the option to mark 'Allow All users' like we have > > > >> today for making a network public, this option would give permission > > > >> to > > > >> everyone on that profile. > > > >> > > > >> > > > >>> > > > >>> Editing a Profile > > > >>> > > > >>> A user should be able to edit the profile properties (including > > > >>> profile > > > >>> name) while VMs are attached and are using this Profile (reference > > > >>> should be done by id). > > > >>> Changing the network of a vNic profile will be allowed only if no VMs > > > >>> are using the profile. > > > >> > > > >> It would be better if we can limit this to no running VM is using the > > > >> profile (or more simple to implement if all VMs that are using this > > > >> profile are in status down). > > > > > > > > Allowing to delete a vnic profile when used by vms is asymmetric to the > > > > network removal > > > > when it is used by vms or templates. Today the update network operation > > > > is > > > > blocked for that. > > > > In addition, with the suggest simplification to remove a profile when > > > > no > > > > running vms, the user > > > > will have to find for himself if the profile is being used prior to its > > > > removal since the > > > > operation will not be blocked. > > > > > > > > If we allow to delete a vnic profile, when a vm is using it (regardless > > > > the > > > > VM status) > > > > we'll have to update the VM entity as well in that operation: since we > > > > do > > > > not support a > > > > network with 'none' profile, we'll have to delete the network as well. > > > > > > > > If we'll remove a vnic profile in 3.1 cluster, used by vms in status > > > > down, > > > > we'd find a case > > > > in which a VM is attached to a 'none' network. This is unsupported in > > > > 3.1 > > > > cluster. We can block > > > > such operation, but this is another motivation why we'd better not to > > > > allow > > > > removing a used profile. > > > > > > > > > The context above is about editing not deleting :) > > > I agree with what you wrote if the context was remove. > > > > > >> > > > >>> Since we have no way to distinguish between running and current > > > >>> configurations, the expected behavior of such a change is > > > >>> unpredictable and less intuitive to the user (especially since > > > >>> dynamic wiring is supported). > > > >>> The changes will seep down to all VNICs using the profile. > > > >>> In case VNIC using the edited profile are connected to running VMs, > > > >>> the change will apply only on the VM next run. > > > >>> > > > >>> Question: What about Hibernate/Suspend VM ? will the resume VM action > > > >>> uses > > > >>> the original configuration for the vnics when the VM was started ? > > > >> > > > >> Currently profile includes: network, port-mirroring, custom property, > > > >> QoS > > > >> > > > >> Changing any of the above (except for network) requires a VM reboot, > > > >> so > > > >> I think that we can start with the following statement - the profile > > > >> change would only apply after next VM reboot. > > > >> > > > >> There are 2 problems with the above: > > > >> - Today we support network wiring, with VNIC profiles we are asking > > > >> the > > > >> users to create a new profile and attach the VMs to the new profile, I > > > >> can see the RFE coming - we can report that ourselves ;) > > > >> > > > >> - We don't reflect with which configuration the VM is running, e.g we > > > >> edited the profile QoS but I'm not sure with which QoS the VM is > > > >> currently running. (The RFE for differentiating between current > > > >> configuration and running configuration was already asked for by > > > >> numerous users) > > > >> > > > >> The above is a general issue that we need to solve and I would not > > > >> limit > > > >> editing VNIC profiles because of it. > > > >> We can mitigate this specifically for QoS like described bellow. > > > >> > > > >> > > > >> > > > >>> Deleting a Profile > > > >>> > > > >>> VNIC Profiles could not be deleted from the engine as long as one or > > > >>> more > > > >>> VM/Templates are using those profiles. > > > >> > > > >>> Reporting vNic actual configuration > > > >>> > > > >>> The engine will retrieve the actual configuration of the profile > > > >>> properties on the VNIC from VDSM (using the network statistics > > > >>> mechanism) and the networked administrator will be presented with the > > > >>> state of each VNIC (synched/unsynched). > > > >>> > > > >> > > > >> Will the admin be able to see the actual values? I think the synced > > > >> property is not enough (I'm not sure how interesting this property is > > > >> to > > > >> start with). > > > > > > > > We can extend the VmGuestAgentInterface to contain the actual value, so > > > > they > > > > will be presented for each vnic in the 'guest data' sub-tab. > > > > > > > > > AFAIU this info does not come from the guest it is info we retrieve from > > > libvirt. > > > The VmGuestAgentInterface should be used only for information reported > > > by the guest, information whose credibility can be questioned. > > > > > >> > > > >>> Editing a VNIC / Changing a VNIC profile > > > >>> > > > >>> Changing the profile a VM is using while the VM is running should > > > >>> behave like dynamic wiring (changing the VM network while it is > > > >>> running). > > > >>> Hot-plug of a vnic will will use will use the updated profile > > > >>> connected > > > >>> to the VNIC. > > > >>> > > > >> > > > >> Not sure I fully understand the sentence above. > > > >> Hot plug will be fully supported, you can choose any profile (you have > > > >> permissions on) while plugging a new device. > > > >> > > > > > > > > That was the intention. seems like an edgy hand syndrome :) > > > > Changed to: > > > > * Hot plug will be fully supported: the user can choose any permitted > > > > profile while plugging a new device or when activating an existing one. > > > > > > > >>> Adding a Network > > > >>> > > > >>> When adding a network, a user can provide an option to create a vNic > > > >>> Profile for it. > > > >>> > > > >>> Question: Is it s default profile ? what are its properties ? > > > >>> Question: What about 'Public Use' option ? Are they still relevant in > > > >>> the > > > >>> context of adding new networks or we should eliminate them and move > > > >>> it > > > >>> only to 'Add vNic Profile' dialog? > > > >>> > > > >> > > > >> see previous comments > > > >> In addition when creating a profile we should have 'Allow all' for > > > >> implicitly creating permissions, like we have today for network. > > > >> > > > >>> Updating a Network > > > >>> > > > >>> When a network role is modified to be a 'non-VM network', all vNic > > > >>> profiles > > > >>> associated with it should be deleted. > > > >> > > > >> And permissions associated with these profiles > > > >> > > > >>> Removing a Network > > > >>> > > > >>> Should remove all profiles on that network > > > >>> > > > >> > > > >> And associated permissions > > > >> > > > >>> Adding an Empty Data-Center > > > >>> > > > >>> Currently, When creating a new Data-Center, the management network is > > > >>> automatically created. > > > >>> From 3.3, a default vNic profile will be created for the management > > > >>> network. > > > >>> > > > >>> VM snapshot/import/export > > > >>> > > > >>> We should handle VMs that are pointing to a network directly for > > > >>> backward compatibility. > > > >>> We need to select first profile that is on that network that the user > > > >>> has permissions on. > > > >>> > > > >>> Question: Do we wish to support it export from 3.3 and import to 3.2 > > > >>> or > > > >>> below? > > > >> > > > >> That means that when you write a VM in the OVF you need to write > > > >> network > > > >> in addition to profile. > > > >> > > > > > > > > The network name is already there, so when importing a vnic from 3.3 to > > > > an > > > > earlier version > > > > the profile name will be ignored. > > > > > > > >> > > > >>> Question: A user can import/export a VM/Template even if he doesn't > > > >>> have > > > >>> permissions on the networks. Is the next flow valid ? > > > >>> > > > >>> The profile name should be saved in the OVF (in addition to the > > > >>> network > > > >>> name which is saved today). > > > >>> During import, if both (network name, profile name) exist on the > > > >>> target > > > >>> DC, the vnic will get the profile id. > > > >>> If the network exists in the Data-Center, but has no profile as > > > >>> specified in the OVF, the user will be notified (event log) and the > > > >>> VNIC will be connected to a default minimal profile defined in the > > > >>> system, regardless the permissions the user has on the network. > > > >>> > > > >> > > > >> What is a 'default minimal profile' ? I would rather have a VNIC with > > > >> no > > > >> profile associated with it. > > > > > > > > The 'default minimal profile' refers to a vnic profile with the lower > > > > average bandwidth. > > > > > > > > With the approach you've suggested, any imported VM/Template from an > > > > earlier to 3.3 version > > > > will require a manual intervention in order to configure a network to > > > > the > > > > VM. > > > > > I should have elaborated some more - > > > > > If a VM has a profile then we should look up this specific profile, if > > > such a profile does not exists then import the VM with profile none like > > > we do today for VM's with reference to a network that does not exist on > > > the setup. > > > > > If a VM does not have a profile (3.2 and lower versions) we should look > > > into the network name, if this network exist and we have a profile with > > > permissions to the user then use this profile (if there is more than one > > > choose one randomly). > > > > > > And for 3.1 we'll have to drop such vnics since network 'none' isn't > > > > supported. > > > > > > > >> > > > >>> If failed to find any matching vNic profile, the vnic's profile will > > > >>> be > > > >>> set > > > >>> with 'none'. > > > >>> > > > >>> When a Template is created from a VM the VNIC Profile will be kept > > > >>> along with the VNIC. When a VM is created from template the VNIC > > > >>> Profiles will be taken from the template's VNICs. > > > >>> > > > >>> ----- Original Message ----- > > > >>>> From: "Livnat Peer" > > > >>>> To: "engine-devel" , "Ofri Masad" > > > >>>> > > > >>>> Cc: "Mike Kolesnik" , "Moti Asayag" > > > >>>> , "Oved Ourfalli" > > > >>>> Sent: Sunday, June 30, 2013 3:59:37 PM > > > >>>> Subject: VNIC profiles > > > >>>> > > > >>>> Hi, > > > >>>> > > > >>>> We are working on adding VNIC profiles as part of the work to add > > > >>>> VNIC > > > >>>> QoS. > > > >>>> > > > >>>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles > > > >>>> > > > >>>> We need to define some of the system behavior followed by this > > > >>>> change, > > > >>>> here is my take - > > > >>>> > > > >>>> Editing a profile - > > > >>>> -------------------- > > > >>>> A user should be able to edit the profile properties (including > > > >>>> profile > > > >>>> name) while VMs are attached and are using this Profile (reference > > > >>>> should be done by id). > > > >>>> > > > >>>> Changing the network though is a bit more tricky as long as we don't > > > >>>> have a way to distinguish between running and current configurations > > > >>>> I > > > >>>> think it could be very confusing to the user. Especially since we > > > >>>> support dynamic wiring so the behavior IMO is unpredictable. > > > >>>> I think it should be blocked at this point. > > > >>>> > > > >>>> > > > >>>> Edit a VNIC / change a VNIC profile - > > > >>>> ------------------------------------ > > > >>>> Changing the profile a VM is using while the VM is running should > > > >>>> behave > > > >>>> like dynamic wiring (changing the VM network while it is running). > > > >>>> > > > >>>> > > > >>>> Remove a Profile - > > > >>>> ------------------- > > > >>>> Is only valid if all VMs that are using this profile are in status > > > >>>> down. > > > >>>> It should update all VMs to point to no profile which should behave > > > >>>> like > > > >>>> none network today. > > > >>>> > > > >>>> I see no reason to support a profile on a none network at this > > > >>>> point. > > > >>>> > > > >>>> The above is also relevant for upgrade flow (upgrading none network > > > >>>> to > > > >>>> point to no profile) > > > >>>> > > > >>>> > > > >>>> Removing a Network - > > > >>>> ---------------------- > > > >>>> should remove all profiles on that network > > > >>>> > > > >>>> > > > >>>> VM snapshot/import/export - > > > >>>> -------------------------- > > > >>>> We should handle VMs that are pointing to a network directly for b/w > > > >>>> compatibility. > > > >>>> we need to select first profile that is on that network that the > > > >>>> user > > > >>>> has permissions on. > > > >>>> > > > >>>> > > > >>>> I assume there are more, comments are welcome > > > >>>> > > > >>>> Thanks, Livnat > > > >>>> > > > >>>> > > > >> > > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From masayag at redhat.com Mon Jul 29 14:07:34 2013 From: masayag at redhat.com (Moti Asayag) Date: Mon, 29 Jul 2013 10:07:34 -0400 (EDT) Subject: [Engine-devel] VNIC profiles & Device Custom Properties In-Reply-To: <417283555.17897435.1375106264140.JavaMail.root@redhat.com> References: <51D02BB9.4090008@redhat.com> <51D95826.40009@redhat.com> <562865353.219690.1373233015552.JavaMail.root@redhat.com> <51DA6613.9040903@redhat.com> <663641499.4577901.1374576949784.JavaMail.root@redhat.com> <1013791164.11407199.1374581565912.JavaMail.root@redhat.com> <1993847417.8505166.1375014807119.JavaMail.root@redhat.com> <417283555.17897435.1375106264140.JavaMail.root@redhat.com> Message-ID: <236346485.9297530.1375106854646.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Amihay Winter" > To: "Moti Asayag" > Cc: engine-devel at ovirt.org, "Livnat Peer" > Sent: Monday, July 29, 2013 4:57:44 PM > Subject: Re: VNIC profiles & Device Custom Properties > > Hi Moti, > > Thanks for the quick response, > > Please look down at the comment. > > Amihay > ----- Original Message ----- > > > From: "Moti Asayag" > > To: "Amihay Winter" > > Cc: engine-devel at ovirt.org, "Livnat Peer" > > Sent: Sunday, July 28, 2013 3:33:27 PM > > Subject: Re: VNIC profiles & Device Custom Properties > > > Hi Amihay, > > > Thank you for your inputs on the feature. See answers in-line for each of > > the > > raised issues. > > > ----- Original Message ----- > > > From: "Amihay Winter" > > > To: engine-devel at ovirt.org > > > Cc: "Moti Asayag" , "Livnat Peer" > > > Sent: Tuesday, July 23, 2013 3:12:45 PM > > > Subject: VNIC profiles & Device Custom Properties > > > > > > Hi all, > > > > > > I'm building a TCMS plan for the Device Custom Properties feature and I > > > came > > > across some questions. > > > I'm sorry that I'm a little late with my thoughts but I hope you'll still > > > hear them out. > > > Also, I know It's a little long but please bear with me :) > > > > > > I want to talk about two things: > > > 1. Sending an updateDevice verb whenever clicking on "Edit" and than > > > "OK". > > > 2. Setting Port Mirroring at the configuring of a nic and not at the > > > profile. > > > > > > 1.According to the Vnic_Profiles's wiki (in the Editing a profile > > > section) > > > it > > > says: > > > "The changes will seep down to all VNICs using the profile. > > > In case VNIC using the edited profile are connected to running VMs, the > > > change will apply only on the VM next run." > > > I'll describe a Scenario: > > > Creating profile A with property speed = 500 > > > Setting vnic2 on vm to have profile A (using Hotplugnic) > > > Changing (in the profile) speed = 700 > > > According to the Vnic_Profiles's wiki, only when I restart my vm I'll get > > > my > > > setting right. > > > In my opinion, If we could enable the update of those setting LIVE we > > > will > > > give the clients a better solution in the Vnic Profiles. > > > I will be able to update all of my 1000 vms in a few minutes with a > > > single > > > script instead of restarting them all and maybe stopping others' work. > > > I think that restarting 1000 vms because I want to set a property is not > > > something that an admin would want to do. > > > One way to implement it is to send a verb "updateDevice" each time we > > > open > > > the the "Edit" window and clicking "OK" > > > I guess that when the design of update device was made, we tried to send > > > minimal verbs, but in this case, I think that if a user clicked on "Edit" > > > & > > > "OK" then he wanted to send the verb, otherwise, he would have pressed on > > > "Edit" & "Cancel". > > > > > > Sending this verb will allow us to keep the vms update with, in my > > > opinion, > > > minimum cost and with great profit - Giving the client a "more correct > > > environment" LIVE. > > > The engine-vdsm has a verb for updating a device. It is sent when the > > engine > > detect a change in the state of the vnic which requires updating the > > device. > > However, the engine doesn't store the vnic profile definition used to > > activate > > the vnic. > > > Instead of restarting the VM, the user can plug-unplug the specific device, > > if > > it already activated. > I know that plug/unplug the specific device will propagate the change but why > use only the hotplug & > hotunplug verbs? why not using the updateDevice verb as well? > Isn't LIVE (without losing connectivity to vm (because the hotunplug)) is > better? I agree updating the device is a proper way of doing it, however we do not maintain the vnic profile configuration used to run the VM. Basically, the vnic profile contains network name (not modifiable), port mirroring (not modifiable if the profile is used by vms) and custom properties which are only relevant when the vm is being started or when a device is plugged. We may reconsider it once the vnic profile is integrated with the QoS, than we should be able to compare the actual (running) qos settings against the qos of the vnic profile and upon discrepancy to issue an update device. > > > > > > > 2. I'll start with saying that in my opinion, the Vnic Profile feature > > > was > > > created to give the client a *more dynamic network environment* and I > > > support. > > > But, I think that the statical variables like MAC, Un/Pluged and Port > > > Mirroring which always exist should be at the nic and not in the profile. > > > In my opinion, Profile's properties may have: max_mtu, min_mtu, mtu, > > > speed, > > > id, vlan... Identifiers for the network. > > > Maybe I'm missing something but it seems natural to me that the port > > > mirroring will be at nic and not at the profile. > > > > > > I'm not sure how port mirroring is commonly used to enable it on vnic > > level. > > Having the port mirroring on vnic profile level allows to control the > > network > > usage in a concentrated place. > > > In both cases, we're a bit late on schedule, therefore changes would be > > done > > later on if required. > > > > I'll really appreciate comments. > > > Thank you for your time. > > > Amihay Winter > > > > > > ----- Original Message ----- > > > > > > > ----- Forwarded Message ----- > > > > From: "Livnat Peer" > > > > To: "Moti Asayag" > > > > Cc: "engine-devel" , "Ofri Masad" > > > > , "Mike Kolesnik" , "Oved > > > > Ourfalli" > > > > > > > > Sent: Monday, July 8, 2013 10:11:15 AM > > > > Subject: Re: VNIC profiles > > > > > > > On 07/08/2013 12:36 AM, Moti Asayag wrote: > > > > > I've updated the wiki accordingly and added few comments inline. > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Livnat Peer" > > > > >> To: "Moti Asayag" > > > > >> Cc: "engine-devel" , "Ofri Masad" > > > > >> , "Mike Kolesnik" , > > > > >> "Oved Ourfalli" > > > > >> Sent: Sunday, July 7, 2013 2:59:34 PM > > > > >> Subject: Re: VNIC profiles > > > > >> > > > > >> On 07/07/2013 01:59 PM, Moti Asayag wrote: > > > > >>> Hi, > > > > >>> > > > > >>> I've updated the wiki with the feedbacks from this thread, added a > > > > >>> backend > > > > >>> section naming the affected commands and also add added few > > > > >>> questions > > > > >>> of > > > > >>> my own embedded in the pastedtext below. > > > > >>> > > > > >> > > > > >> Hi Moti, > > > > >> A good and comprehensive description of the feature behavior. > > > > >> See my comments bellow - > > > > >> > > > > >>> In addition, another question here: > > > > >>> > > > > >>> The units within the UI mockups are Mb and Mbps. The libvirt APIs > > > > >>> expects > > > > >>> the units to be in kb and kbps. Which component is responsible to > > > > >>> convert > > > > >>> them to the expect units ? engine or VDSM ? > > > > >> > > > > >> Giuseppe mentioned that in a previous thread on this subject. > > > > >> Ofri and Giuseppe agreed that the translation would be done on the > > > > >> engine level. > > > > >> > > > > >> > > > > >>> > > > > >>> Copied text from the wiki: > > > > >>> > > > > >>> Adding a Profile > > > > >>> > > > > >>> The network administrator could create several VNIC Profiles for > > > > >>> each > > > > >>> network. He could then grant a users with the permission to use > > > > >>> (consume) > > > > >>> each profile. The user will only be able to use profiles which he > > > > >>> was > > > > >>> granted access to. > > > > >>> > > > > >>> For example: the network admin will create two VNIC profiles for > > > > >>> network "blue": > > > > >>> > > > > >>> Profile "Gold" - with better QoS and with port mirroring > > > > >>> Profile "Silver" with lower QoS and without port mirroring. > > > > >>> > > > > >> > > > > >> I would use other names for the profiles to avoid confusion. > > > > >> Gold and Silver are likely to be QoS object names, a more typical > > > > >> name > > > > >> for a network profile is - teachers-blue and students-blue > > > > >> > > > > >> The different profiles can have different QoS (teachers-blue would > > > > >> get > > > > >> Gold QoS while Students-blue will have Silver). > > > > >> > > > > >> > > > > >>> He will then define the user-group "students" as user of profile > > > > >>> "Silver" and user-group "teachers" as user of profile "Gold". In > > > > >>> this > > > > >>> case the teachers will enjoy better quality of service then the > > > > >>> students. When a teacher will add/edit a virtual NIC he could > > > > >>> select > > > > >>> profile "Gold" for that NIC - the VNIC will be connected to network > > > > >>> "blue" with high QoS and with port mirroring. > > > > >>> > > > > >>> Question: In the same matter we allowed via the UI to grant > > > > >>> 'NetworkUser' > > > > >>> to 'everyone' user, wouldn't it ease the use of Profiles if we > > > > >>> support > > > > >>> it > > > > >>> in this context as well? > > > > >> > > > > >> The ease of use could be that when creating a network we'll display > > > > >> in > > > > >> the UI all VNIC-QoS-objects and the users could tick next to the QoS > > > > >> they are interested in, for each QoS that was chosen a profile would > > > > >> be > > > > >> created. > > > > >> > > > > >> I would enhance that with youe suggestion above and display next to > > > > >> the > > > > >> QoS that was checked the option to mark 'Allow All users' like we > > > > >> have > > > > >> today for making a network public, this option would give permission > > > > >> to > > > > >> everyone on that profile. > > > > >> > > > > >> > > > > >>> > > > > >>> Editing a Profile > > > > >>> > > > > >>> A user should be able to edit the profile properties (including > > > > >>> profile > > > > >>> name) while VMs are attached and are using this Profile (reference > > > > >>> should be done by id). > > > > >>> Changing the network of a vNic profile will be allowed only if no > > > > >>> VMs > > > > >>> are using the profile. > > > > >> > > > > >> It would be better if we can limit this to no running VM is using > > > > >> the > > > > >> profile (or more simple to implement if all VMs that are using this > > > > >> profile are in status down). > > > > > > > > > > Allowing to delete a vnic profile when used by vms is asymmetric to > > > > > the > > > > > network removal > > > > > when it is used by vms or templates. Today the update network > > > > > operation > > > > > is > > > > > blocked for that. > > > > > In addition, with the suggest simplification to remove a profile when > > > > > no > > > > > running vms, the user > > > > > will have to find for himself if the profile is being used prior to > > > > > its > > > > > removal since the > > > > > operation will not be blocked. > > > > > > > > > > If we allow to delete a vnic profile, when a vm is using it > > > > > (regardless > > > > > the > > > > > VM status) > > > > > we'll have to update the VM entity as well in that operation: since > > > > > we > > > > > do > > > > > not support a > > > > > network with 'none' profile, we'll have to delete the network as > > > > > well. > > > > > > > > > > If we'll remove a vnic profile in 3.1 cluster, used by vms in status > > > > > down, > > > > > we'd find a case > > > > > in which a VM is attached to a 'none' network. This is unsupported in > > > > > 3.1 > > > > > cluster. We can block > > > > > such operation, but this is another motivation why we'd better not to > > > > > allow > > > > > removing a used profile. > > > > > > > > > > > > The context above is about editing not deleting :) > > > > I agree with what you wrote if the context was remove. > > > > > > > >> > > > > >>> Since we have no way to distinguish between running and current > > > > >>> configurations, the expected behavior of such a change is > > > > >>> unpredictable and less intuitive to the user (especially since > > > > >>> dynamic wiring is supported). > > > > >>> The changes will seep down to all VNICs using the profile. > > > > >>> In case VNIC using the edited profile are connected to running VMs, > > > > >>> the change will apply only on the VM next run. > > > > >>> > > > > >>> Question: What about Hibernate/Suspend VM ? will the resume VM > > > > >>> action > > > > >>> uses > > > > >>> the original configuration for the vnics when the VM was started ? > > > > >> > > > > >> Currently profile includes: network, port-mirroring, custom > > > > >> property, > > > > >> QoS > > > > >> > > > > >> Changing any of the above (except for network) requires a VM reboot, > > > > >> so > > > > >> I think that we can start with the following statement - the profile > > > > >> change would only apply after next VM reboot. > > > > >> > > > > >> There are 2 problems with the above: > > > > >> - Today we support network wiring, with VNIC profiles we are asking > > > > >> the > > > > >> users to create a new profile and attach the VMs to the new profile, > > > > >> I > > > > >> can see the RFE coming - we can report that ourselves ;) > > > > >> > > > > >> - We don't reflect with which configuration the VM is running, e.g > > > > >> we > > > > >> edited the profile QoS but I'm not sure with which QoS the VM is > > > > >> currently running. (The RFE for differentiating between current > > > > >> configuration and running configuration was already asked for by > > > > >> numerous users) > > > > >> > > > > >> The above is a general issue that we need to solve and I would not > > > > >> limit > > > > >> editing VNIC profiles because of it. > > > > >> We can mitigate this specifically for QoS like described bellow. > > > > >> > > > > >> > > > > >> > > > > >>> Deleting a Profile > > > > >>> > > > > >>> VNIC Profiles could not be deleted from the engine as long as one > > > > >>> or > > > > >>> more > > > > >>> VM/Templates are using those profiles. > > > > >> > > > > >>> Reporting vNic actual configuration > > > > >>> > > > > >>> The engine will retrieve the actual configuration of the profile > > > > >>> properties on the VNIC from VDSM (using the network statistics > > > > >>> mechanism) and the networked administrator will be presented with > > > > >>> the > > > > >>> state of each VNIC (synched/unsynched). > > > > >>> > > > > >> > > > > >> Will the admin be able to see the actual values? I think the synced > > > > >> property is not enough (I'm not sure how interesting this property > > > > >> is > > > > >> to > > > > >> start with). > > > > > > > > > > We can extend the VmGuestAgentInterface to contain the actual value, > > > > > so > > > > > they > > > > > will be presented for each vnic in the 'guest data' sub-tab. > > > > > > > > > > > > AFAIU this info does not come from the guest it is info we retrieve > > > > from > > > > libvirt. > > > > The VmGuestAgentInterface should be used only for information reported > > > > by the guest, information whose credibility can be questioned. > > > > > > > >> > > > > >>> Editing a VNIC / Changing a VNIC profile > > > > >>> > > > > >>> Changing the profile a VM is using while the VM is running should > > > > >>> behave like dynamic wiring (changing the VM network while it is > > > > >>> running). > > > > >>> Hot-plug of a vnic will will use will use the updated profile > > > > >>> connected > > > > >>> to the VNIC. > > > > >>> > > > > >> > > > > >> Not sure I fully understand the sentence above. > > > > >> Hot plug will be fully supported, you can choose any profile (you > > > > >> have > > > > >> permissions on) while plugging a new device. > > > > >> > > > > > > > > > > That was the intention. seems like an edgy hand syndrome :) > > > > > Changed to: > > > > > * Hot plug will be fully supported: the user can choose any permitted > > > > > profile while plugging a new device or when activating an existing > > > > > one. > > > > > > > > > >>> Adding a Network > > > > >>> > > > > >>> When adding a network, a user can provide an option to create a > > > > >>> vNic > > > > >>> Profile for it. > > > > >>> > > > > >>> Question: Is it s default profile ? what are its properties ? > > > > >>> Question: What about 'Public Use' option ? Are they still relevant > > > > >>> in > > > > >>> the > > > > >>> context of adding new networks or we should eliminate them and move > > > > >>> it > > > > >>> only to 'Add vNic Profile' dialog? > > > > >>> > > > > >> > > > > >> see previous comments > > > > >> In addition when creating a profile we should have 'Allow all' for > > > > >> implicitly creating permissions, like we have today for network. > > > > >> > > > > >>> Updating a Network > > > > >>> > > > > >>> When a network role is modified to be a 'non-VM network', all vNic > > > > >>> profiles > > > > >>> associated with it should be deleted. > > > > >> > > > > >> And permissions associated with these profiles > > > > >> > > > > >>> Removing a Network > > > > >>> > > > > >>> Should remove all profiles on that network > > > > >>> > > > > >> > > > > >> And associated permissions > > > > >> > > > > >>> Adding an Empty Data-Center > > > > >>> > > > > >>> Currently, When creating a new Data-Center, the management network > > > > >>> is > > > > >>> automatically created. > > > > >>> From 3.3, a default vNic profile will be created for the management > > > > >>> network. > > > > >>> > > > > >>> VM snapshot/import/export > > > > >>> > > > > >>> We should handle VMs that are pointing to a network directly for > > > > >>> backward compatibility. > > > > >>> We need to select first profile that is on that network that the > > > > >>> user > > > > >>> has permissions on. > > > > >>> > > > > >>> Question: Do we wish to support it export from 3.3 and import to > > > > >>> 3.2 > > > > >>> or > > > > >>> below? > > > > >> > > > > >> That means that when you write a VM in the OVF you need to write > > > > >> network > > > > >> in addition to profile. > > > > >> > > > > > > > > > > The network name is already there, so when importing a vnic from 3.3 > > > > > to > > > > > an > > > > > earlier version > > > > > the profile name will be ignored. > > > > > > > > > >> > > > > >>> Question: A user can import/export a VM/Template even if he doesn't > > > > >>> have > > > > >>> permissions on the networks. Is the next flow valid ? > > > > >>> > > > > >>> The profile name should be saved in the OVF (in addition to the > > > > >>> network > > > > >>> name which is saved today). > > > > >>> During import, if both (network name, profile name) exist on the > > > > >>> target > > > > >>> DC, the vnic will get the profile id. > > > > >>> If the network exists in the Data-Center, but has no profile as > > > > >>> specified in the OVF, the user will be notified (event log) and the > > > > >>> VNIC will be connected to a default minimal profile defined in the > > > > >>> system, regardless the permissions the user has on the network. > > > > >>> > > > > >> > > > > >> What is a 'default minimal profile' ? I would rather have a VNIC > > > > >> with > > > > >> no > > > > >> profile associated with it. > > > > > > > > > > The 'default minimal profile' refers to a vnic profile with the lower > > > > > average bandwidth. > > > > > > > > > > With the approach you've suggested, any imported VM/Template from an > > > > > earlier to 3.3 version > > > > > will require a manual intervention in order to configure a network to > > > > > the > > > > > VM. > > > > > > > I should have elaborated some more - > > > > > > > If a VM has a profile then we should look up this specific profile, if > > > > such a profile does not exists then import the VM with profile none > > > > like > > > > we do today for VM's with reference to a network that does not exist on > > > > the setup. > > > > > > > If a VM does not have a profile (3.2 and lower versions) we should look > > > > into the network name, if this network exist and we have a profile with > > > > permissions to the user then use this profile (if there is more than > > > > one > > > > choose one randomly). > > > > > > > > And for 3.1 we'll have to drop such vnics since network 'none' isn't > > > > > supported. > > > > > > > > > >> > > > > >>> If failed to find any matching vNic profile, the vnic's profile > > > > >>> will > > > > >>> be > > > > >>> set > > > > >>> with 'none'. > > > > >>> > > > > >>> When a Template is created from a VM the VNIC Profile will be kept > > > > >>> along with the VNIC. When a VM is created from template the VNIC > > > > >>> Profiles will be taken from the template's VNICs. > > > > >>> > > > > >>> ----- Original Message ----- > > > > >>>> From: "Livnat Peer" > > > > >>>> To: "engine-devel" , "Ofri Masad" > > > > >>>> > > > > >>>> Cc: "Mike Kolesnik" , "Moti Asayag" > > > > >>>> , "Oved Ourfalli" > > > > >>>> Sent: Sunday, June 30, 2013 3:59:37 PM > > > > >>>> Subject: VNIC profiles > > > > >>>> > > > > >>>> Hi, > > > > >>>> > > > > >>>> We are working on adding VNIC profiles as part of the work to add > > > > >>>> VNIC > > > > >>>> QoS. > > > > >>>> > > > > >>>> http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles > > > > >>>> > > > > >>>> We need to define some of the system behavior followed by this > > > > >>>> change, > > > > >>>> here is my take - > > > > >>>> > > > > >>>> Editing a profile - > > > > >>>> -------------------- > > > > >>>> A user should be able to edit the profile properties (including > > > > >>>> profile > > > > >>>> name) while VMs are attached and are using this Profile (reference > > > > >>>> should be done by id). > > > > >>>> > > > > >>>> Changing the network though is a bit more tricky as long as we > > > > >>>> don't > > > > >>>> have a way to distinguish between running and current > > > > >>>> configurations > > > > >>>> I > > > > >>>> think it could be very confusing to the user. Especially since we > > > > >>>> support dynamic wiring so the behavior IMO is unpredictable. > > > > >>>> I think it should be blocked at this point. > > > > >>>> > > > > >>>> > > > > >>>> Edit a VNIC / change a VNIC profile - > > > > >>>> ------------------------------------ > > > > >>>> Changing the profile a VM is using while the VM is running should > > > > >>>> behave > > > > >>>> like dynamic wiring (changing the VM network while it is running). > > > > >>>> > > > > >>>> > > > > >>>> Remove a Profile - > > > > >>>> ------------------- > > > > >>>> Is only valid if all VMs that are using this profile are in status > > > > >>>> down. > > > > >>>> It should update all VMs to point to no profile which should > > > > >>>> behave > > > > >>>> like > > > > >>>> none network today. > > > > >>>> > > > > >>>> I see no reason to support a profile on a none network at this > > > > >>>> point. > > > > >>>> > > > > >>>> The above is also relevant for upgrade flow (upgrading none > > > > >>>> network > > > > >>>> to > > > > >>>> point to no profile) > > > > >>>> > > > > >>>> > > > > >>>> Removing a Network - > > > > >>>> ---------------------- > > > > >>>> should remove all profiles on that network > > > > >>>> > > > > >>>> > > > > >>>> VM snapshot/import/export - > > > > >>>> -------------------------- > > > > >>>> We should handle VMs that are pointing to a network directly for > > > > >>>> b/w > > > > >>>> compatibility. > > > > >>>> we need to select first profile that is on that network that the > > > > >>>> user > > > > >>>> has permissions on. > > > > >>>> > > > > >>>> > > > > >>>> I assume there are more, comments are welcome > > > > >>>> > > > > >>>> Thanks, Livnat > > > > >>>> > > > > >>>> > > > > >> > > > > >> > > > > From gustavo.pedrosa at eldorado.org.br Mon Jul 29 18:06:53 2013 From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa) Date: Mon, 29 Jul 2013 18:06:53 +0000 Subject: [Engine-devel] Question about the attribute lunType (LUNs) Message-ID: Hello everyone, The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires the implementation of methods that evaluate if a Disk is a iSCSI LUN or not, in order to avoid its use in this specific architecture. Looks like this can be determined by the attribute lunType (which is of the type StorageType, an Enum) of the class LUNs. But when I retrieve the object, the attribute lunType has the value "UNKNOWN", even if I've setted it with another value. In the class LunDAODbFacadeImpl there is not a call to the "entity.setLunType" method. Does anyone know how to retrieve the attribute lunType? Is the "UNKNOW" value a bug? Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa -------------- next part -------------- An HTML attachment was scrubbed... URL: From laravot at redhat.com Tue Jul 30 06:51:53 2013 From: laravot at redhat.com (Liron Aravot) Date: Tue, 30 Jul 2013 02:51:53 -0400 (EDT) Subject: [Engine-devel] Question about the attribute lunType (LUNs) In-Reply-To: References: Message-ID: <2097411436.3951984.1375167113456.JavaMail.root@redhat.com> Hi Gustavo, ----- Original Message ----- > From: "Gustavo Frederico Temple Pedrosa" > To: engine-devel at ovirt.org > Cc: "Leonardo Bianconi" > Sent: Monday, July 29, 2013 9:06:53 PM > Subject: [Engine-devel] Question about the attribute lunType (LUNs) > > > > Hello everyone, > > The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires the > implementation of methods that evaluate if a Disk is a iSCSI LUN or not, in > order to avoid its use in this specific architecture. > Looks like this can be determined by the attribute lunType (which is of the > type StorageType, an Enum) of the class LUNs. But when I retrieve the > object, the attribute lunType has the value "UNKNOWN", even if I've setted > it with another value. In the class LunDAODbFacadeImpl there is not a call > to the "entity.setLunType" method. > > Does anyone know how to retrieve the attribute lunType? Is the "UNKNOW" value > a bug? > IIRC the lun type isn't saved in the DB - so that DAO will never set it. This attribute is currently being generated by checking if the LUN is FC or ISCSI based on it's connections (FC - currently means "no connections" while ISCSI means "has connections"). Therefore you won't see it being set when querying it from the DB. let me know if you have any further related questions. Liron. > Thanks, > > Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Tue Jul 30 10:11:44 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 30 Jul 2013 13:11:44 +0300 Subject: [Engine-devel] Question about the attribute lunType (LUNs) In-Reply-To: References: Message-ID: <51F79160.6080307@redhat.com> On 07/29/2013 09:06 PM, Gustavo Frederico Temple Pedrosa wrote: > Hello everyone, > > The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires the > implementation of methods that evaluate if a Disk is a iSCSI LUN or not, > in order to avoid its use in this specific architecture. > Looks like this can be determined by the attribute lunType (which is of > the type StorageType, an Enum) of the class LUNs. But when I retrieve > the object, the attribute lunType has the value "UNKNOWN", even if I've > setted it with another value. In the class LunDAODbFacadeImpl there is > not a call to the "entity.setLunType" method. > > Does anyone know how to retrieve the attribute lunType? Is the "UNKNOW" > value a bug? > > Thanks, > > Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > Gustavo - what are you trying to achieve exactly? not allowing iscsi storage domains for ppc, or direct lun type disks (or something else)? Thanks, Itamar From didi at redhat.com Tue Jul 30 13:07:24 2013 From: didi at redhat.com (Yedidyah Bar David) Date: Tue, 30 Jul 2013 09:07:24 -0400 (EDT) Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> Message-ID: <836171819.8244986.1375189644738.JavaMail.root@redhat.com> Hi all, ----- Original Message ----- > From: alonbl at redhat.com, at at redhat.com, "Alon Bar-Lev" > Sent: Monday, July 29, 2013 10:15:33 AM > Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup > [snip] > > for some reason fedora-18/19 got tar out of base system, so we are > forced to find some solution, although manual configuration is required > anyway (repository, networking etc...). > > there was attempt to use python tar module, however this module has a > bug when last block is empty, so it is not suitable for usage. > > cpio is alternative for fedora, however it is rightfully missing from > other distributions as it is much less used. as we do not support hosts > using different distributions, we are ok now. > > in future, we can use python self extract script, work already performed > at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of > complexity. > > Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca > Signed-off-by: Alon Bar-Lev > > [1] http://gerrit.ovirt.org/#/c/17396/ > FWIW: I personally find it least ugly to choose neither cpio nor pyar, and require installing tar. Besides Ohad's case in the bug, do we know about real problems? Is there a specific requirement to be able to run a node on a minimal installation of $distro? Some other real complications this might cause? Anyway, if we do have to choose, I'd go with pyar and not cpio. cpio is used by rpm and initramfs, but other than that it's not very common (? IMHO), and if we go with it we might face ourselves in the same situation at some later point in time - that cpio will not be included in a minimal installation of $distro. Best regards, -- Didi From iheim at redhat.com Tue Jul 30 13:10:15 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 30 Jul 2013 16:10:15 +0300 Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <836171819.8244986.1375189644738.JavaMail.root@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> <836171819.8244986.1375189644738.JavaMail.root@redhat.com> Message-ID: <51F7BB37.2010608@redhat.com> On 07/30/2013 04:07 PM, Yedidyah Bar David wrote: > Hi all, > > ----- Original Message ----- >> From: alonbl at redhat.com, at at redhat.com, "Alon Bar-Lev" >> Sent: Monday, July 29, 2013 10:15:33 AM >> Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup >> > [snip] >> >> for some reason fedora-18/19 got tar out of base system, so we are >> forced to find some solution, although manual configuration is required >> anyway (repository, networking etc...). >> >> there was attempt to use python tar module, however this module has a >> bug when last block is empty, so it is not suitable for usage. >> >> cpio is alternative for fedora, however it is rightfully missing from >> other distributions as it is much less used. as we do not support hosts >> using different distributions, we are ok now. >> >> in future, we can use python self extract script, work already performed >> at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of >> complexity. >> >> Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca >> Signed-off-by: Alon Bar-Lev >> >> [1] http://gerrit.ovirt.org/#/c/17396/ >> > > FWIW: > > I personally find it least ugly to choose neither cpio nor pyar, and > require installing tar. I personally always install fedora/rhel at minimal install level when using it for oVirt, so i can appreciate the pain in failing on this. (i.e., my success criteria for testing things is "i don't need to change anything to use it out of the box with minimal install"). > > Besides Ohad's case in the bug, do we know about real problems? we fixed missing deps in the past around issues with minimal install. this is a chicken and an egg one, still i think it should be fixed. > Is there a specific requirement to be able to run a node on a minimal > installation of $distro? Some other real complications this might cause? I'd say yes... > > Anyway, if we do have to choose, I'd go with pyar and not cpio. cpio is > used by rpm and initramfs, but other than that it's not very common (? IMHO), > and if we go with it we might face ourselves in the same situation at some > later point in time - that cpio will not be included in a minimal installation > of $distro. > > Best regards, > did we solve the issue with pyar? (i don't have a preference between the two, i just want/expect things to work out of the box without RTFM) From alonbl at redhat.com Tue Jul 30 13:12:03 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Jul 2013 09:12:03 -0400 (EDT) Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> Message-ID: <1031113778.4037715.1375189923523.JavaMail.root@redhat.com> Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ From michal.skrivanek at redhat.com Tue Jul 30 13:25:24 2013 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Tue, 30 Jul 2013 15:25:24 +0200 Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <1031113778.4037715.1375189923523.JavaMail.root@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> <1031113778.4037715.1375189923523.JavaMail.root@redhat.com> Message-ID: <2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com> On Jul 30, 2013, at 15:12 , Alon Bar-Lev wrote: > Hello All, > > Starting the discussion again... > > I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. > > Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host). > > I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. How about filing bug on that? This is such a basic utility I can't imagine anyone removing it. > > There are three alternatives : > > 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. > > Benefit: simplicity. > Benefit: use standard tools. > Benefit: lower payload to transmit. > Drawback: require tar at destination machine. > > 2. Do not use tar but self extracting python script, a patch is ready[1]. > > Benefit: ability to deploy environment in which tar is missing. > Drawback: non standard tool at destination machine. > Drawback: complexity within our code. > > 3. Do not use tar but cpio, a patch is ready[2]. > > Benefit: simplicity. > Benefit: use standard tools. > Benefit: lower payload to transmit. > Benefit: ability to use Fedora-19 minimal. > Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. > Drawback: most other distributions will not have cpio in their minimal installation. > > [[[ > There was 4rd alternative, using python tar module to deploy tar. > However, there is a bug in that module when processing last block if empty. > This is edge condition but happened to at least one of the users and I could > reproduce it. > ]]] > > What option do you prefer? > > Regards, > Alon Bar-Lev > > [1] http://gerrit.ovirt.org/#/c/17295/ > [2] http://gerrit.ovirt.org/#/c/17396/ > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From asegurap at redhat.com Tue Jul 30 14:09:47 2013 From: asegurap at redhat.com (Antoni Segura Puimedon) Date: Tue, 30 Jul 2013 10:09:47 -0400 (EDT) Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> <1031113778.4037715.1375189923523.JavaMail.root@redhat.com> <2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com> Message-ID: <1118719160.4093235.1375193387063.JavaMail.root@redhat.com> I would advocate for option 2. ----- Original Message ----- > From: "Michal Skrivanek" > To: "Alon Bar-Lev" > Cc: "Juan Hernandez" , "engine-devel" , "arch" , "users" > > Sent: Tuesday, July 30, 2013 3:25:24 PM > Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup > > > On Jul 30, 2013, at 15:12 , Alon Bar-Lev wrote: > > > Hello All, > > > > Starting the discussion again... > > > > I would like to receive feedback regarding how we should cope with a state > > presented to use by Fedora. > > > > Fedora-19 minimal setup does not install tar utility which is required to > > deploy files during the host-deploy process (Hosts->Add Host). > > > > I guess because of 2.8M in size (including translations) -- a standard > > commonly used utility was removed. > > How about filing bug on that? This is such a basic utility I can't imagine > anyone removing it. > > > > > There are three alternatives : > > > > 1. Instruct users who are using minimal installations to manually install > > tar utility just like they configure repository, dns, etc.. > > > > Benefit: simplicity. > > Benefit: use standard tools. > > Benefit: lower payload to transmit. > > Drawback: require tar at destination machine. > > > > 2. Do not use tar but self extracting python script, a patch is ready[1]. > > > > Benefit: ability to deploy environment in which tar is missing. > > Drawback: non standard tool at destination machine. > > Drawback: complexity within our code. > > > > 3. Do not use tar but cpio, a patch is ready[2]. > > > > Benefit: simplicity. > > Benefit: use standard tools. > > Benefit: lower payload to transmit. > > Benefit: ability to use Fedora-19 minimal. > > Drawback: cpio is even less common than tar, even if it exists in Fedora-19 > > it can be removed without anyone notice. > > Drawback: most other distributions will not have cpio in their minimal > > installation. > > > > [[[ > > There was 4rd alternative, using python tar module to deploy tar. > > However, there is a bug in that module when processing last block if empty. > > This is edge condition but happened to at least one of the users and I > > could > > reproduce it. > > ]]] > > > > What option do you prefer? > > > > Regards, > > Alon Bar-Lev > > > > [1] http://gerrit.ovirt.org/#/c/17295/ > > [2] http://gerrit.ovirt.org/#/c/17396/ > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > From gustavo.pedrosa at eldorado.org.br Tue Jul 30 14:13:38 2013 From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa) Date: Tue, 30 Jul 2013 14:13:38 +0000 Subject: [Engine-devel] Question about the attribute lunType (LUNs) In-Reply-To: <51F79160.6080307@redhat.com> References: <51F79160.6080307@redhat.com> Message-ID: > -----Original Message----- > From: Itamar Heim [mailto:iheim at redhat.com] > Sent: ter?a-feira, 30 de julho de 2013 07:12 > To: Gustavo Frederico Temple Pedrosa > Cc: engine-devel at ovirt.org; Leonardo Bianconi > Subject: Re: [Engine-devel] Question about the attribute lunType (LUNs) > > On 07/29/2013 09:06 PM, Gustavo Frederico Temple Pedrosa wrote: > > Hello everyone, > > > > The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires > > the implementation of methods that evaluate if a Disk is a iSCSI LUN > > or not, in order to avoid its use in this specific architecture. > > Looks like this can be determined by the attribute lunType (which is > > of the type StorageType, an Enum) of the class LUNs. But when I > > retrieve the object, the attribute lunType has the value "UNKNOWN", > > even if I've setted it with another value. In the class > > LunDAODbFacadeImpl there is not a call to the "entity.setLunType" > method. > > > > Does anyone know how to retrieve the attribute lunType? Is the > "UNKNOW" > > value a bug? > > > > Thanks, > > > > Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa > > > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > Gustavo - what are you trying to achieve exactly? not allowing iscsi storage > domains for ppc, or direct lun type disks (or something else)? > > Thanks, > Itamar Hello Itamar, The QEMU/KVM on IBM POWER does not support direct LUN disks (i.e. -drive file=iscsi://ip_address/target/1), so this kind of device cannot be available on the frontend. Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa From iheim at redhat.com Tue Jul 30 14:14:53 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 30 Jul 2013 17:14:53 +0300 Subject: [Engine-devel] Question about the attribute lunType (LUNs) In-Reply-To: References: <51F79160.6080307@redhat.com> Message-ID: <51F7CA5D.2090703@redhat.com> On 07/30/2013 05:13 PM, Gustavo Frederico Temple Pedrosa wrote: >> -----Original Message----- >> From: Itamar Heim [mailto:iheim at redhat.com] >> Sent: ter?a-feira, 30 de julho de 2013 07:12 >> To: Gustavo Frederico Temple Pedrosa >> Cc: engine-devel at ovirt.org; Leonardo Bianconi >> Subject: Re: [Engine-devel] Question about the attribute lunType (LUNs) >> >> On 07/29/2013 09:06 PM, Gustavo Frederico Temple Pedrosa wrote: >>> Hello everyone, >>> >>> The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires >>> the implementation of methods that evaluate if a Disk is a iSCSI LUN >>> or not, in order to avoid its use in this specific architecture. >>> Looks like this can be determined by the attribute lunType (which is >>> of the type StorageType, an Enum) of the class LUNs. But when I >>> retrieve the object, the attribute lunType has the value "UNKNOWN", >>> even if I've setted it with another value. In the class >>> LunDAODbFacadeImpl there is not a call to the "entity.setLunType" >> method. >>> >>> Does anyone know how to retrieve the attribute lunType? Is the >> "UNKNOW" >>> value a bug? >>> >>> Thanks, >>> >>> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa >>> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >> Gustavo - what are you trying to achieve exactly? not allowing iscsi storage >> domains for ppc, or direct lun type disks (or something else)? >> >> Thanks, >> Itamar > > > > Hello Itamar, > > The QEMU/KVM on IBM POWER does not support direct LUN disks (i.e. -drive file=iscsi://ip_address/target/1), so this kind of device cannot be available on the frontend. > > Thanks, > Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa > i could be wrong, but i'm pretty sure direct lun disks in ovirt are done by the host doing the iscsi connection, and mounting the disk as a regular block device to the guest? From mgoldboi at redhat.com Tue Jul 30 15:05:46 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Tue, 30 Jul 2013 18:05:46 +0300 Subject: [Engine-devel] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review] Message-ID: <51F7D64A.4050103@redhat.com> We would like to go a head on oVirt 3.3 release process and issue an RC for tomorrow meeting: Maintainers/ Package owners ================== -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1], see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 ... Users ==== with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule ============ Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1]*Bug 918494* -Tracker: oVirt 3.3 release -------------- next part -------------- An HTML attachment was scrubbed... URL: From alonbl at redhat.com Tue Jul 30 15:10:26 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Jul 2013 11:10:26 -0400 (EDT) Subject: [Engine-devel] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review] In-Reply-To: <51F7D64A.4050103@redhat.com> References: <51F7D64A.4050103@redhat.com> Message-ID: <834354904.4127994.1375197026698.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Moran Goldboim" > To: "engine-devel" , vdsm-devel at ovirt.org, users at ovirt.org > Sent: Tuesday, July 30, 2013 6:05:46 PM > Subject: [Engine-devel] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review] > > We would like to go a head on oVirt 3.3 release process and issue an RC > > for tomorrow meeting: > > Maintainers/ Package owners > ================== > -branch your git repo (master) with 3.3 branch (making master ready for 3.4) > -for tomorrow meeting, overview [1] , see if you have any changes to it > -if you don't have any blockers under your component, please branch 3.3 with > RC1 branch > > | > -master > | > -engine_3.3 > | > -RC1 > | > -engine_3.2 Please use proper notation... ovirt-engine-3.3.0 branch for 3.3.0 release cycle ovirt-engine-3.3.0_rc1 - for rc1 tag or branch > ... > > Users > ==== > with your experience from test day and with nightlies, if you feel there are > additional candidates to block this version for please add it to the tracker > bug [1]. > > Suggested Schedule > ============ > Wed Jul 31st - review of blockers for the version and component readiness > Mon Aug 5th - RC1 release > Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be > issued) > > Thanks. > > [1] Bug 918494 - Tracker: oVirt 3.3 release > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From sbonazzo at redhat.com Tue Jul 30 15:11:38 2013 From: sbonazzo at redhat.com (Sandro Bonazzola) Date: Tue, 30 Jul 2013 17:11:38 +0200 Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <1031113778.4037715.1375189923523.JavaMail.root@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> <1031113778.4037715.1375189923523.JavaMail.root@redhat.com> Message-ID: <51F7D7AA.2020102@redhat.com> Il 30/07/2013 15:12, Alon Bar-Lev ha scritto: > Hello All, > > Starting the discussion again... > > I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. > > Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host). > > I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. > > There are three alternatives : > > 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. > > Benefit: simplicity. > Benefit: use standard tools. > Benefit: lower payload to transmit. > Drawback: require tar at destination machine. > > 2. Do not use tar but self extracting python script, a patch is ready[1]. > > Benefit: ability to deploy environment in which tar is missing. > Drawback: non standard tool at destination machine. > Drawback: complexity within our code. > > 3. Do not use tar but cpio, a patch is ready[2]. > > Benefit: simplicity. > Benefit: use standard tools. > Benefit: lower payload to transmit. > Benefit: ability to use Fedora-19 minimal. > Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. > Drawback: most other distributions will not have cpio in their minimal installation. > > [[[ > There was 4rd alternative, using python tar module to deploy tar. > However, there is a bug in that module when processing last block if empty. > This is edge condition but happened to at least one of the users and I could > reproduce it. > ]]] > > What option do you prefer? Well, honestly, the solution I like more than the others is having the python tar bug fixed and be free to use the python tar lib. I would like to exclude cpio: it's on rpm based distro but not commonly available on others. I would like to exclude the RTFM solution, having it working out of the box. So my second choice is using a self extracting script. If you think pyar is a non standard tool, do you have considered the use of shar? Or do you think it's also a non standard tool? > > Regards, > Alon Bar-Lev > > [1] http://gerrit.ovirt.org/#/c/17295/ > [2] http://gerrit.ovirt.org/#/c/17396/ > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com From alonbl at redhat.com Tue Jul 30 15:17:48 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Jul 2013 11:17:48 -0400 (EDT) Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <51F7D7AA.2020102@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> <1031113778.4037715.1375189923523.JavaMail.root@redhat.com> <51F7D7AA.2020102@redhat.com> Message-ID: <251998728.4130707.1375197468062.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" > Cc: "users" , "arch" , "engine-devel" , "Juan Hernandez" > > Sent: Tuesday, July 30, 2013 6:11:38 PM > Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup > > Il 30/07/2013 15:12, Alon Bar-Lev ha scritto: > > Hello All, > > > > Starting the discussion again... > > > > I would like to receive feedback regarding how we should cope with a state > > presented to use by Fedora. > > > > Fedora-19 minimal setup does not install tar utility which is required to > > deploy files during the host-deploy process (Hosts->Add Host). > > > > I guess because of 2.8M in size (including translations) -- a standard > > commonly used utility was removed. > > > > There are three alternatives : > > > > 1. Instruct users who are using minimal installations to manually install > > tar utility just like they configure repository, dns, etc.. > > > > Benefit: simplicity. > > Benefit: use standard tools. > > Benefit: lower payload to transmit. > > Drawback: require tar at destination machine. > > > > 2. Do not use tar but self extracting python script, a patch is ready[1]. > > > > Benefit: ability to deploy environment in which tar is missing. > > Drawback: non standard tool at destination machine. > > Drawback: complexity within our code. > > > > 3. Do not use tar but cpio, a patch is ready[2]. > > > > Benefit: simplicity. > > Benefit: use standard tools. > > Benefit: lower payload to transmit. > > Benefit: ability to use Fedora-19 minimal. > > Drawback: cpio is even less common than tar, even if it exists in Fedora-19 > > it can be removed without anyone notice. > > Drawback: most other distributions will not have cpio in their minimal > > installation. > > > > [[[ > > There was 4rd alternative, using python tar module to deploy tar. > > However, there is a bug in that module when processing last block if empty. > > This is edge condition but happened to at least one of the users and I > > could > > reproduce it. > > ]]] > > > > What option do you prefer? > > Well, honestly, the solution I like more than the others is having the > python tar bug fixed and be free to use the python tar lib. > > I would like to exclude cpio: it's on rpm based distro but not commonly > available on others. > > I would like to exclude the RTFM solution, having it working out of the box. > > So my second choice is using a self extracting script. > If you think pyar is a non standard tool, do you have considered the use > of shar? > Or do you think it's also a non standard tool? shar needs dependencies on remote: - md5sum - uudecode > > > > > > > Regards, > > Alon Bar-Lev > > > > [1] http://gerrit.ovirt.org/#/c/17295/ > > [2] http://gerrit.ovirt.org/#/c/17396/ > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > > From danken at redhat.com Tue Jul 30 16:58:27 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 30 Jul 2013 19:58:27 +0300 Subject: [Engine-devel] [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review] In-Reply-To: <51F7D64A.4050103@redhat.com> References: <51F7D64A.4050103@redhat.com> Message-ID: <20130730165827.GA22332@redhat.com> On Tue, Jul 30, 2013 at 06:05:46PM +0300, Moran Goldboim wrote: > We would like to go a head on oVirt 3.3 release process and issue an RC > > for tomorrow meeting: > > Maintainers/ Package owners > ================== > -branch your git repo (master) with 3.3 branch (making master ready for 3.4) > -for tomorrow meeting, overview [1], see if you have any changes to it > -if you don't have any blockers under your component, please branch > 3.3 with RC1 branch > > | > -master > | > -engine_3.3 > | > -RC1 > | > -engine_3.2 > ... > > Users > ==== > with your experience from test day and with nightlies, if you feel > there are additional candidates to block this version for please add > it to the tracker bug [1]. > > Suggested Schedule > ============ > Wed Jul 31st - review of blockers for the version and component readiness > Mon Aug 5th - RC1 release > Wed Aug 7th - Release readiness review (in case of blockers an RC2 > will be issued) > > Thanks. > > [1]*Bug 918494* > -Tracker: oVirt 3.3 release I've just tagged vdsm-4.12.0 and branched ovirt-3.3 branch for the vdsm repository starting at git has 620343d6317c849fc985a5083cebb68c995f7c15. Expect a deluge of non-ovirt-3.3 merges to the master branch soon. Future ovirt-3.3 fixes would have to be backported and cherry-picked. Dan. From jhernand at redhat.com Tue Jul 30 18:25:13 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Tue, 30 Jul 2013 20:25:13 +0200 Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <836171819.8244986.1375189644738.JavaMail.root@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> <836171819.8244986.1375189644738.JavaMail.root@redhat.com> Message-ID: <51F80509.8000405@redhat.com> On 07/30/2013 03:07 PM, Yedidyah Bar David wrote: > Hi all, > > ----- Original Message ----- >> From: alonbl at redhat.com, at at redhat.com, "Alon Bar-Lev" >> Sent: Monday, July 29, 2013 10:15:33 AM >> Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup >> > [snip] >> >> for some reason fedora-18/19 got tar out of base system, so we are >> forced to find some solution, although manual configuration is required >> anyway (repository, networking etc...). >> >> there was attempt to use python tar module, however this module has a >> bug when last block is empty, so it is not suitable for usage. >> >> cpio is alternative for fedora, however it is rightfully missing from >> other distributions as it is much less used. as we do not support hosts >> using different distributions, we are ok now. >> >> in future, we can use python self extract script, work already performed >> at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of >> complexity. >> >> Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca >> Signed-off-by: Alon Bar-Lev >> >> [1] http://gerrit.ovirt.org/#/c/17396/ >> > > FWIW: > > I personally find it least ugly to choose neither cpio nor pyar, and > require installing tar. > > Besides Ohad's case in the bug, do we know about real problems? > Is there a specific requirement to be able to run a node on a minimal > installation of $distro? Some other real complications this might cause? > > Anyway, if we do have to choose, I'd go with pyar and not cpio. cpio is > used by rpm and initramfs, but other than that it's not very common (? IMHO), > and if we go with it we might face ourselves in the same situation at some > later point in time - that cpio will not be included in a minimal installation > of $distro. > > Best regards, > As far as I know most distributions use initramfs to boot, and that requires the cpio command to build it, so all machines running Fedora, RHEL, CentOS, Debian, Ubuntu and Gentoo (if using genkernel) should have cpio installed even for minimal installations. -- 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 Jul 30 18:29:38 2013 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 30 Jul 2013 14:29:38 -0400 (EDT) Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <51F80509.8000405@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> <836171819.8244986.1375189644738.JavaMail.root@redhat.com> <51F80509.8000405@redhat.com> Message-ID: <1205748888.4285209.1375208978826.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Juan Hernandez" > To: "Yedidyah Bar David" > Cc: engine-devel at ovirt.org > Sent: Tuesday, July 30, 2013 9:25:13 PM > Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup > > On 07/30/2013 03:07 PM, Yedidyah Bar David wrote: > > Hi all, > > > > ----- Original Message ----- > >> From: alonbl at redhat.com, at at redhat.com, "Alon Bar-Lev" > >> > >> Sent: Monday, July 29, 2013 10:15:33 AM > >> Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 > >> misses tar at minimal setup > >> > > [snip] > >> > >> for some reason fedora-18/19 got tar out of base system, so we are > >> forced to find some solution, although manual configuration is required > >> anyway (repository, networking etc...). > >> > >> there was attempt to use python tar module, however this module has a > >> bug when last block is empty, so it is not suitable for usage. > >> > >> cpio is alternative for fedora, however it is rightfully missing from > >> other distributions as it is much less used. as we do not support hosts > >> using different distributions, we are ok now. > >> > >> in future, we can use python self extract script, work already performed > >> at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of > >> complexity. > >> > >> Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca > >> Signed-off-by: Alon Bar-Lev > >> > >> [1] http://gerrit.ovirt.org/#/c/17396/ > >> > > > > FWIW: > > > > I personally find it least ugly to choose neither cpio nor pyar, and > > require installing tar. > > > > Besides Ohad's case in the bug, do we know about real problems? > > Is there a specific requirement to be able to run a node on a minimal > > installation of $distro? Some other real complications this might cause? > > > > Anyway, if we do have to choose, I'd go with pyar and not cpio. cpio is > > used by rpm and initramfs, but other than that it's not very common (? > > IMHO), > > and if we go with it we might face ourselves in the same situation at some > > later point in time - that cpio will not be included in a minimal > > installation > > of $distro. > > > > Best regards, > > > > As far as I know most distributions use initramfs to boot, and that > requires the cpio command to build it, so all machines running Fedora, > RHEL, CentOS, Debian, Ubuntu and Gentoo (if using genkernel) should have > cpio installed even for minimal installations. Hi, Binary based distributions do not build initramfs on the fly, right? Require cpio to build initramfs is like require gcc to build kernel, no? RHEL, CentOS does have tar at minimal as far as I know... Gentoo does not have genkernel/cpio in stage3 (minimal). All but Fedora have tar at minimal. Regards, Alon From jhernand at redhat.com Tue Jul 30 18:45:41 2013 From: jhernand at redhat.com (Juan Hernandez) Date: Tue, 30 Jul 2013 20:45:41 +0200 Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <1205748888.4285209.1375208978826.JavaMail.root@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> <836171819.8244986.1375189644738.JavaMail.root@redhat.com> <51F80509.8000405@redhat.com> <1205748888.4285209.1375208978826.JavaMail.root@redhat.com> Message-ID: <51F809D5.7070505@redhat.com> On 07/30/2013 08:29 PM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Juan Hernandez" >> To: "Yedidyah Bar David" >> Cc: engine-devel at ovirt.org >> Sent: Tuesday, July 30, 2013 9:25:13 PM >> Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup >> >> On 07/30/2013 03:07 PM, Yedidyah Bar David wrote: >>> Hi all, >>> >>> ----- Original Message ----- >>>> From: alonbl at redhat.com, at at redhat.com, "Alon Bar-Lev" >>>> >>>> Sent: Monday, July 29, 2013 10:15:33 AM >>>> Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 >>>> misses tar at minimal setup >>>> >>> [snip] >>>> >>>> for some reason fedora-18/19 got tar out of base system, so we are >>>> forced to find some solution, although manual configuration is required >>>> anyway (repository, networking etc...). >>>> >>>> there was attempt to use python tar module, however this module has a >>>> bug when last block is empty, so it is not suitable for usage. >>>> >>>> cpio is alternative for fedora, however it is rightfully missing from >>>> other distributions as it is much less used. as we do not support hosts >>>> using different distributions, we are ok now. >>>> >>>> in future, we can use python self extract script, work already performed >>>> at: I1e5ddab9ae87979da7d7296c4f3c7ef08e21e903 at the price of >>>> complexity. >>>> >>>> Change-Id: I1386e7d688a9ec7e28519fb407478fd17cbab4ca >>>> Signed-off-by: Alon Bar-Lev >>>> >>>> [1] http://gerrit.ovirt.org/#/c/17396/ >>>> >>> >>> FWIW: >>> >>> I personally find it least ugly to choose neither cpio nor pyar, and >>> require installing tar. >>> >>> Besides Ohad's case in the bug, do we know about real problems? >>> Is there a specific requirement to be able to run a node on a minimal >>> installation of $distro? Some other real complications this might cause? >>> >>> Anyway, if we do have to choose, I'd go with pyar and not cpio. cpio is >>> used by rpm and initramfs, but other than that it's not very common (? >>> IMHO), >>> and if we go with it we might face ourselves in the same situation at some >>> later point in time - that cpio will not be included in a minimal >>> installation >>> of $distro. >>> >>> Best regards, >>> >> >> As far as I know most distributions use initramfs to boot, and that >> requires the cpio command to build it, so all machines running Fedora, >> RHEL, CentOS, Debian, Ubuntu and Gentoo (if using genkernel) should have >> cpio installed even for minimal installations. > > Hi, > > Binary based distributions do not build initramfs on the fly, right? Require cpio to build initramfs is like require gcc to build kernel, no? > Fedora, RHEL, CentOS, Debian and Ubuntu (for example) do build initramfs on the fly when the kernel is installed/updated, and that uses the cpio command. So any updatable installation has it. > RHEL, CentOS does have tar at minimal as far as I know... > > Gentoo does not have genkernel/cpio in stage3 (minimal). > It doesn't have any kernel either, so you need to build it (according to the installations instructions) which would need to build the initramfs as well, and that (if using genkernel, at least) requires cpio. > All but Fedora have tar at minimal. > > Regards, > 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 iheim at redhat.com Tue Jul 30 18:56:40 2013 From: iheim at redhat.com (Itamar Heim) Date: Tue, 30 Jul 2013 21:56:40 +0300 Subject: [Engine-devel] [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review] In-Reply-To: <51F7D64A.4050103@redhat.com> References: <51F7D64A.4050103@redhat.com> Message-ID: <51F80C68.3000709@redhat.com> On 07/30/2013 06:05 PM, Moran Goldboim wrote: > We would like to go a head on oVirt 3.3 release process and issue an RC how can we do this before folks review all the bugs with target release of 3.3 and either suggest them as blockers or move them from 3.3? there are currently 59 NEW, 7 ASSIGNED and 22 POST with target release of 3.3? http://alturl.com/aq23x > > for tomorrow meeting: > > Maintainers/ Package owners > ================== > -branch your git repo (master) with 3.3 branch (making master ready for 3.4) > -for tomorrow meeting, overview [1], see if you have any changes to it > -if you don't have any blockers under your component, please branch 3.3 > with RC1 branch > > | > -master > | > -engine_3.3 > | > -RC1 > | > -engine_3.2 > ... > > Users > ==== > with your experience from test day and with nightlies, if you feel there > are additional candidates to block this version for please add it to the > tracker bug [1]. > > Suggested Schedule > ============ > Wed Jul 31st - review of blockers for the version and component readiness > Mon Aug 5th - RC1 release > Wed Aug 7th - Release readiness review (in case of blockers an RC2 will > be issued) > > Thanks. > > [1]*Bug 918494* > -Tracker: oVirt 3.3 release > > > > > _______________________________________________ > Users mailing list > Users at ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > From mgoldboi at redhat.com Tue Jul 30 19:01:44 2013 From: mgoldboi at redhat.com (Moran Goldboim) Date: Tue, 30 Jul 2013 22:01:44 +0300 Subject: [Engine-devel] [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review] In-Reply-To: <51F80C68.3000709@redhat.com> References: <51F7D64A.4050103@redhat.com> <51F80C68.3000709@redhat.com> Message-ID: <51F80D98.2070703@redhat.com> On 07/30/2013 09:56 PM, Itamar Heim wrote: > On 07/30/2013 06:05 PM, Moran Goldboim wrote: >> We would like to go a head on oVirt 3.3 release process and issue an RC > > how can we do this before folks review all the bugs with target > release of 3.3 and either suggest them as blockers or move them from 3.3? > there are currently 59 NEW, 7 ASSIGNED and 22 POST with target release > of 3.3? > > http://alturl.com/aq23x that the aim of this mail, maintainers should review their realm for blockers (unscrubbed bugs as well), and this release should get into stabilization mode. by tomorrow we should have a better view on what are the blockers for the version, we are already going to delay this release, and i would like to get a clear view by tomorrow, as mentioned later in the mail - RC should go out without any known blockers. > >> >> for tomorrow meeting: >> >> Maintainers/ Package owners >> ================== >> -branch your git repo (master) with 3.3 branch (making master ready >> for 3.4) >> -for tomorrow meeting, overview [1], see if you have any changes to it >> -if you don't have any blockers under your component, please branch 3.3 >> with RC1 branch >> >> | >> -master >> | >> -engine_3.3 >> | >> -RC1 >> | >> -engine_3.2 >> ... >> >> Users >> ==== >> with your experience from test day and with nightlies, if you feel there >> are additional candidates to block this version for please add it to the >> tracker bug [1]. >> >> Suggested Schedule >> ============ >> Wed Jul 31st - review of blockers for the version and component >> readiness >> Mon Aug 5th - RC1 release >> Wed Aug 7th - Release readiness review (in case of blockers an RC2 will >> be issued) >> >> Thanks. >> >> [1]*Bug 918494* >> -Tracker: oVirt 3.3 release >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> > From gustavo.pedrosa at eldorado.org.br Tue Jul 30 19:21:37 2013 From: gustavo.pedrosa at eldorado.org.br (Gustavo Frederico Temple Pedrosa) Date: Tue, 30 Jul 2013 19:21:37 +0000 Subject: [Engine-devel] Question about the attribute lunType (LUNs) In-Reply-To: <51F7CA5D.2090703@redhat.com> References: <51F79160.6080307@redhat.com> <51F7CA5D.2090703@redhat.com> Message-ID: > -----Original Message----- > From: Itamar Heim [mailto:iheim at redhat.com] > Sent: ter?a-feira, 30 de julho de 2013 11:15 > To: Gustavo Frederico Temple Pedrosa > Cc: engine-devel at ovirt.org; Leonardo Bianconi; Vitor de Lima; Federico > Simoncelli > Subject: Re: [Engine-devel] Question about the attribute lunType (LUNs) > > On 07/30/2013 05:13 PM, Gustavo Frederico Temple Pedrosa wrote: > >> -----Original Message----- > >> From: Itamar Heim [mailto:iheim at redhat.com] > >> Sent: ter?a-feira, 30 de julho de 2013 07:12 > >> To: Gustavo Frederico Temple Pedrosa > >> Cc: engine-devel at ovirt.org; Leonardo Bianconi > >> Subject: Re: [Engine-devel] Question about the attribute lunType > >> (LUNs) > >> > >> On 07/29/2013 09:06 PM, Gustavo Frederico Temple Pedrosa wrote: > >>> Hello everyone, > >>> > >>> The QEMU/KVM on IBM POWER does not support iSCSI yet. This > requires > >>> the implementation of methods that evaluate if a Disk is a iSCSI LUN > >>> or not, in order to avoid its use in this specific architecture. > >>> Looks like this can be determined by the attribute lunType (which is > >>> of the type StorageType, an Enum) of the class LUNs. But when I > >>> retrieve the object, the attribute lunType has the value "UNKNOWN", > >>> even if I've setted it with another value. In the class > >>> LunDAODbFacadeImpl there is not a call to the "entity.setLunType" > >> method. > >>> > >>> Does anyone know how to retrieve the attribute lunType? Is the > >> "UNKNOW" > >>> value a bug? > >>> > >>> Thanks, > >>> > >>> Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa > >>> > >>> > >>> > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel at ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >> > >> Gustavo - what are you trying to achieve exactly? not allowing iscsi > >> storage domains for ppc, or direct lun type disks (or something else)? > >> > >> Thanks, > >> Itamar > > > > > > > > Hello Itamar, > > > > The QEMU/KVM on IBM POWER does not support direct LUN disks (i.e. - > drive file=iscsi://ip_address/target/1), so this kind of device cannot be > available on the frontend. > > > > Thanks, > > Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa > > > > i could be wrong, but i'm pretty sure direct lun disks in ovirt are done by the > host doing the iscsi connection, and mounting the disk as a regular block > device to the guest? Yes, you are correct. We tested and the VDSM does not pass LUNs directly to QEMU. From dougsland at redhat.com Tue Jul 30 21:24:34 2013 From: dougsland at redhat.com (Douglas Schilling Landgraf) Date: Tue, 30 Jul 2013 17:24:34 -0400 Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> <1031113778.4037715.1375189923523.JavaMail.root@redhat.com> <2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com> Message-ID: <51F82F12.1010608@redhat.com> On 07/30/2013 09:25 AM, Michal Skrivanek wrote: > > On Jul 30, 2013, at 15:12 , Alon Bar-Lev wrote: > >> Hello All, >> >> Starting the discussion again... >> >> I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. >> >> Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts->Add Host). >> >> I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. > > How about filing bug on that? This is such a basic utility I can't imagine anyone removing it. +1 I do agree with Michael. I have opened a thread in fedora devel mailing list anyway. > >> >> There are three alternatives : >> >> 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. >> >> Benefit: simplicity. >> Benefit: use standard tools. >> Benefit: lower payload to transmit. >> Drawback: require tar at destination machine. >> >> 2. Do not use tar but self extracting python script, a patch is ready[1]. >> >> Benefit: ability to deploy environment in which tar is missing. >> Drawback: non standard tool at destination machine. >> Drawback: complexity within our code. >> >> 3. Do not use tar but cpio, a patch is ready[2]. >> >> Benefit: simplicity. >> Benefit: use standard tools. >> Benefit: lower payload to transmit. >> Benefit: ability to use Fedora-19 minimal. >> Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. >> Drawback: most other distributions will not have cpio in their minimal installation. >> >> [[[ >> There was 4rd alternative, using python tar module to deploy tar. >> However, there is a bug in that module when processing last block if empty. >> This is edge condition but happened to at least one of the users and I could >> reproduce it. >> ]]] >> >> What option do you prefer? >> >> Regards, >> Alon Bar-Lev >> >> [1] http://gerrit.ovirt.org/#/c/17295/ >> [2] http://gerrit.ovirt.org/#/c/17396/ >> _______________________________________________ >> 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 danken at redhat.com Tue Jul 30 21:40:29 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 31 Jul 2013 00:40:29 +0300 Subject: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup In-Reply-To: <1118719160.4093235.1375193387063.JavaMail.root@redhat.com> References: <733894071.3566217.1374997569084.JavaMail.root@redhat.com> <51F4E3E0.600@redhat.com> <1199327522.3570177.1375008177999.JavaMail.root@redhat.com> <1832045797.3650023.1375082133389.JavaMail.root@redhat.com> <1031113778.4037715.1375189923523.JavaMail.root@redhat.com> <2E2BF622-110C-47C1-8C45-111F4B74C379@redhat.com> <1118719160.4093235.1375193387063.JavaMail.root@redhat.com> Message-ID: <20130730214029.GA24058@redhat.com> On Tue, Jul 30, 2013 at 10:09:47AM -0400, Antoni Segura Puimedon wrote: > I would advocate for option 2. > > ----- Original Message ----- > > From: "Michal Skrivanek" > > To: "Alon Bar-Lev" > > Cc: "Juan Hernandez" , "engine-devel" , "arch" , "users" > > > > Sent: Tuesday, July 30, 2013 3:25:24 PM > > Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup > > > > > > On Jul 30, 2013, at 15:12 , Alon Bar-Lev wrote: > > > > > Hello All, > > > > > > Starting the discussion again... > > > > > > I would like to receive feedback regarding how we should cope with a state > > > presented to use by Fedora. > > > > > > Fedora-19 minimal setup does not install tar utility which is required to > > > deploy files during the host-deploy process (Hosts->Add Host). > > > > > > I guess because of 2.8M in size (including translations) -- a standard > > > commonly used utility was removed. > > > > How about filing bug on that? This is such a basic utility I can't imagine > > anyone removing it. > > > > > > > > There are three alternatives : > > > > > > 1. Instruct users who are using minimal installations to manually install > > > tar utility just like they configure repository, dns, etc.. > > > > > > Benefit: simplicity. > > > Benefit: use standard tools. > > > Benefit: lower payload to transmit. > > > Drawback: require tar at destination machine. > > > > > > 2. Do not use tar but self extracting python script, a patch is ready[1]. > > > > > > Benefit: ability to deploy environment in which tar is missing. > > > Drawback: non standard tool at destination machine. > > > Drawback: complexity within our code. How about option 2.1: convince Fedora to reintroduce tar? It is ironic that Gnome is shipped by default, but not such a staple utility. Where in Fedora did this decision take place? Can it be undone? Is it commonplace these days among other distros to boycot tar? Dan. From danken at redhat.com Tue Jul 30 21:49:07 2013 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 31 Jul 2013 00:49:07 +0300 Subject: [Engine-devel] [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review] In-Reply-To: <51F7D64A.4050103@redhat.com> References: <51F7D64A.4050103@redhat.com> Message-ID: <20130730214907.GD24058@redhat.com> On Tue, Jul 30, 2013 at 06:05:46PM +0300, Moran Goldboim wrote: > We would like to go a head on oVirt 3.3 release process and issue an RC > > for tomorrow meeting: > > Maintainers/ Package owners > ================== > -branch your git repo (master) with 3.3 branch (making master ready for 3.4) > -for tomorrow meeting, overview [1], see if you have any changes to it > -if you don't have any blockers under your component, please branch > 3.3 with RC1 branch > > | > -master > | > -engine_3.3 > | > -RC1 > | > -engine_3.2 > ... > > Users > ==== > with your experience from test day and with nightlies, if you feel > there are additional candidates to block this version for please add > it to the tracker bug [1]. > > Suggested Schedule > ============ > Wed Jul 31st - review of blockers for the version and component readiness > Mon Aug 5th - RC1 release > Wed Aug 7th - Release readiness review (in case of blockers an RC2 > will be issued) > > Thanks. > > [1]*Bug 918494* > -Tracker: oVirt 3.3 release I've just tagged vdsm-4.12.0 and branched ovirt-3.3 branch for the vdsm repository starting at git has 620343d6317c849fc985a5083cebb68c995f7c15. Expect a deluge of non-ovirt-3.3 merges to the master branch soon. Future ovirt-3.3 fixes would have to be backported and cherry-picked. Dan. From ykatabam at redhat.com Wed Jul 31 06:01:20 2013 From: ykatabam at redhat.com (Yuko Katabami) Date: Wed, 31 Jul 2013 16:01:20 +1000 Subject: [Engine-devel] [oVirt/RHEV 3.3 Localization Question #2] gluster hook stage "Pre" and "Post" Message-ID: <51F8A830.7090103@redhat.com> Hello all, I am a Brisbane-based translator currently working on the oVirt/RHEV 3.3 localization project along with 5 other translators. I was suggested to post my localization-related questions to this mailing list instead of rhev-devel. We often have difficulty in comprehending some strings or are unable to determine the usage of strings without knowing the context. In order to translate software UI strings accurately, we need extra information from time to time. It would be very much appreciated if any of you can help us by responding my email. My question this time is about the following strings: File: LocalizedEnums Resource Ids: "GlusterHookStage___PRE" and "GlusterHookStage___POST" Strings: "Pre" and "Post" Question: Could anyone explain how these are used? In our language we need to know what comes after "Pre" and "Post", otherwise our translation would become "Front" and "Back" that would not make sense in this case. Thank you. Kind regards, 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 at 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 *Facebook:* Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC *Twitter:* Red Hat APAC | Red Hat ANZ *LinkedIn:* Red Hat APAC | JBoss APAC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: redhat-logo.png Type: image/png Size: 4635 bytes Desc: not available URL: From kmayilsa at redhat.com Wed Jul 31 06:39:48 2013 From: kmayilsa at redhat.com (Kanagaraj) Date: Wed, 31 Jul 2013 12:09:48 +0530 Subject: [Engine-devel] [oVirt/RHEV 3.3 Localization Question #2] gluster hook stage "Pre" and "Post" In-Reply-To: <51F8A830.7090103@redhat.com> References: <51F8A830.7090103@redhat.com> Message-ID: <51F8B134.901@redhat.com> Hi Yuko, "Pre" refers to the point in time just before the corresponding volume command(aka volume event) has taken effect on a peer/host. " Post" refers to the point in time just after the corresponding volume command(aka volume event) has taken effect on a peer/host. More information is available here http://www.gluster.org/community/documentation/index.php/Features/Hooks Thanks, Kanagaraj On 07/31/2013 11:31 AM, Yuko Katabami wrote: > Hello all, > > I am a Brisbane-based translator currently working on the oVirt/RHEV > 3.3 localization project along with 5 other translators. > I was suggested to post my localization-related questions to this > mailing list instead of rhev-devel. > > We often have difficulty in comprehending some strings or are unable > to determine the usage of strings without knowing the context. > In order to translate software UI strings accurately, we need extra > information from time to time. > It would be very much appreciated if any of you can help us by > responding my email. > > My question this time is about the following strings: > File: LocalizedEnums > Resource Ids: "GlusterHookStage___PRE" and "GlusterHookStage___POST" > Strings: "Pre" and "Post" > Question: Could anyone explain how these are used? In our language we > need to know what comes after "Pre" and "Post", otherwise our > translation would become "Front" and "Back" that would not make sense > in this case. > > Thank you. > > Kind regards, > > 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 at 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 > > *Facebook:* Red Hat APAC | Red > Hat Japan | Red Hat Korea > | JBoss APAC > > *Twitter:* Red Hat APAC | Red > Hat ANZ > *LinkedIn:* Red Hat APAC > | JBoss APAC > > > _______________________________________________ > 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: not available Type: image/png Size: 4635 bytes Desc: not available URL: From leonardo.bianconi at eldorado.org.br Wed Jul 31 11:32:52 2013 From: leonardo.bianconi at eldorado.org.br (Leonardo Bianconi) Date: Wed, 31 Jul 2013 11:32:52 +0000 Subject: [Engine-devel] [Engine-patches] Change in ovirt-host-deploy[master]: packaging: Fixed building RPMs on non-x86_64 architectures In-Reply-To: <51F81453.4040001@redhat.com> References: <51F1E824.2010604@redhat.com> <51F66717.5070601@redhat.com> <50EB20226B72D6419356FC320AB62B871917192C@SERV070.corp.eldorado.org.br> <51F81453.4040001@redhat.com> Message-ID: <50EB20226B72D6419356FC320AB62B87191719D1@SERV070.corp.eldorado.org.br> Ok, no problem. Thanks >-----Original Message----- >From: Itamar Heim [mailto:iheim at redhat.com] >Sent: ter?a-feira, 30 de julho de 2013 16:30 >To: Leonardo Bianconi >Cc: Vitor de Lima >Subject: Re: [Engine-patches] Change in ovirt-host-deploy[master]: packaging: Fixed building RPMs on non-x86_64 architectures > >On 07/30/2013 10:26 PM, Leonardo Bianconi wrote: >> Hi Itamar! >> >> I'm working on the API change: >> >>>> I think setting it from cpu name automatically and having it read >>>> only makes sense API wise. >>>> GUI wise, i'm torn, but you could always make the API only accept >>>> the cpu, and let the user use the arch only to filter the cpu models, etc. >> >> I looked for how create a field read-only, but I didn't find anything in the wiki. So, I added the field 'Architecture' for cluster, getting it >from the CPU object. In the file rsdl_metadata.yaml I added the architecture field as optional for the cluster's requests (update and >add) and internally it is being defined by the CPU name, so when the architecture is sent in the xml, it is ignored. I tested it and it`s >working fine. >> >> Is this the read only behavior you expect for the API? > >can you please re-send with engine-devel in cc so i can cc the rest api maintainer easily? > >thanks > >> >> Regards. >> Leonardo Bianconi >> >>> -----Original Message----- >>> From: Vitor de Lima >>> Sent: ter?a-feira, 30 de julho de 2013 11:11 >>> To: Leonardo Bianconi >>> Subject: FW: [Engine-patches] Change in ovirt-host-deploy[master]: >>> packaging: Fixed building RPMs on non-x86_64 architectures >>> >>> >>> >>>> -----Original Message----- >>>> From: Itamar Heim [mailto:iheim at redhat.com] >>>> Sent: segunda-feira, 29 de julho de 2013 09:59 >>>> To: Vitor de Lima >>>> Subject: Re: [Engine-patches] Change in ovirt-host-deploy[master]: packaging: >>>> Fixed building RPMs on non-x86_64 architectures >>>> >>>> On 07/29/2013 03:38 PM, Vitor de Lima wrote: >>>>> Thanks, the problem is I had issues testing it on a x86_64 machine. >>>> Everything is OK right now and unfortunately I rebased the patches, >>>> so the code review must be done again. >>>>> >>>>> I have a question, the engine patch is in review process, after >>>>> adding the >>>> architecture field I thought a little bit about how the REST API >>>> would be changed, so far I have two options on how to integrate this >>>> new field. I could export the architecture field to the user of the >>>> API, so the resources would have the architecture field accessible >>>> to the user of the API. This can cause problems related to bad user >>>> input (like a cluster with a POWER cpu name and an architecture field defined to 'x86_64'). >>>>> >>>>> On other hand, I could hide this field and set its content >>>>> automatically >>>> (derived from the cpu name in clusters and from the selected cluster >>>> on VMs, Templates and Pools). Which approach would be the most appropriate? >>>> >>>> I think setting it from cpu name automatically and having it read >>>> only makes sense API wise. >>>> GUI wise, i'm torn, but you could always make the API only accept >>>> the cpu, and let the user use the arch only to filter the cpu models, etc. >>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Itamar Heim [mailto:iheim at redhat.com] >>>>>> Sent: sexta-feira, 26 de julho de 2013 00:08 >>>>>> To: Vitor de Lima >>>>>> Subject: Re: [Engine-patches] Change in ovirt-host-deploy[master]: >>>> packaging: >>>>>> Fixed building RPMs on non-x86_64 architectures >>>>>> >>>>>> On 07/24/2013 03:13 PM, vitor.lima at eldorado.org.br wrote: >>>>>>> Vitor de Lima has uploaded a new change for review. >>>>>>> >>>>>>> Change subject: packaging: Fixed building RPMs on non-x86_64 >>>>>>> architectures ...................................................................... >>>>>>> >>>>>>> packaging: Fixed building RPMs on non-x86_64 architectures >>>>>>> >>>>>>> The DMI decode is available only on the x86_64 architecture, the >>>>>>> spec file was changed to reflect this. >>>>>>> >>>>>>> Change-Id: I691544be6630ed2e88acbf8f1828b7995f582ffa >>>>>>> Signed-off-by: Vitor de Lima >>>>>>> --- >>>>>>> M ovirt-host-deploy.spec.in >>>>>>> 1 file changed, 2 insertions(+), 0 deletions(-) >>>>>> >>>>>> >>>>>> hi vitor, >>>>>> >>>>>> just to make sure the status is clear - alon mentioned on both >>>>>> these >>>> patches >>>>>> to "please verify". this means he expects you to tick the 'verified' >>>>>> checkbox >>>> on >>>>>> the gerrit patch and commenting that you tested this works for >>>>>> you, >>>> doesn't >>>>>> break things, etc. >>>>>> once you do that, he can merge the patches (he already approved >>>>>> them) >>>>>> >>>>>> Thanks, >>>>>> Itamar >> From ykatabam at redhat.com Wed Jul 31 12:09:06 2013 From: ykatabam at redhat.com (Yuko Katabami) Date: Wed, 31 Jul 2013 22:09:06 +1000 Subject: [Engine-devel] [oVirt 3.3 Localization Question #2] gluster hook stage "Pre" and "Post" In-Reply-To: <51F8B134.901@redhat.com> References: <51F8A830.7090103@redhat.com> <51F8B134.901@redhat.com> Message-ID: <51F8FE62.20800@redhat.com> On 07/31/2013 04:39 PM, Kanagaraj wrote: > Hi Yuko, > > "Pre" refers to the point in time just before the corresponding volume > command(aka volume event) has taken effect on a peer/host. > > " Post" refers to the point in time just after the corresponding > volume command(aka volume event) has taken effect on a peer/host. > > More information is available here > http://www.gluster.org/community/documentation/index.php/Features/Hooks > > > Thanks, > Kanagaraj Hi Kanagaraj, Thank you very much for your explanation. It makes sense clearly now. Kind regards, Yuko -------------- next part -------------- An HTML attachment was scrubbed... URL: From vszocs at redhat.com Wed Jul 31 13:17:30 2013 From: vszocs at redhat.com (Vojtech Szocs) Date: Wed, 31 Jul 2013 09:17:30 -0400 (EDT) Subject: [Engine-devel] oVirt UI technology stack upgrade complete In-Reply-To: <1371263835.5152453.1374568755635.JavaMail.root@redhat.com> Message-ID: <162740763.9237639.1375276650565.JavaMail.root@redhat.com> 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#DevGuideSerializableTypes From oschreib at redhat.com Wed Jul 31 14:52:36 2013 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 31 Jul 2013 10:52:36 -0400 (EDT) Subject: [Engine-devel] ovirt-engine-3.3 branch created In-Reply-To: <318856459.9067314.1375282095099.JavaMail.root@redhat.com> Message-ID: <294145179.9073695.1375282356185.JavaMail.root@redhat.com> Hey, I have just created the ovirt-engine-3.3 branch in gerrit.ovirt.org, which will be used for 3.3 builds. Please make sure you cherry pick important patches (== blockers) into that branch, otherwise, 3.3 will miss them. If you are unsure if a patch should get inside 3.3 branch, please feel free to contact me. Regards, -- Ofer Schreiber From jenkins at ovirt.org Wed Jul 31 23:02:58 2013 From: jenkins at ovirt.org (Jenkins ci oVirt Server) Date: Thu, 1 Aug 2013 00:02:58 +0100 (BST) Subject: [Engine-devel] [oVirt jenkins] Weekly report on open tasks for ovirt-engine Message-ID: <689342260.41.1375311778175.JavaMail.jenkins@jenkins.ovirt.org> An HTML attachment was scrubbed... URL: