- Devel - oVirt List Archives

[Engine-devel] Proposal of Alon bar-lev as oVirt jenkins power user
by Eyal Edri 25 Nov '12

25 Nov '12

Hi, To continue our new tradition of delegating power users for various oVirt sub project management in jenkins, I want to propose Alon bar-lev as power user for oVirt jenkins. Alon is well known within the oVirt community, and been contributing it in the past months. Alon has contributed code to many oVirt projects including massive re-factoring of the bootstrap process and numerous patches on other oVirt projects, Latest projects are otopi and ovirt-host-deploy. He is very technical with previous knowledge of Jenkins. as a power user he will be to: 1. create/update new jobs in jenkins.ovirt.org 2. run/trigger builds 3. run manual gerrit trigger jobs. i vote +1. please vote confidence with +1 or -1 for not. thanks, Eyal Edri.

6 6

[Engine-devel] Mocking EJB resources
by Allon Mureinik 25 Nov '12

25 Nov '12

Hi guys, Many of our classes use EJBUtils to access JBoss' resources/beans, such as TransactionManager, Schedular, LockingManager, etc. This is all fine and well, but it's a bit of a pain when testing those classes. Earlier today I merged a patch (thanks Laszlo, Michael K., Yair and Alissa for their comments!) that allows a streamlined, easier way of doing this, instead of having to muck around with mock objects (or mock around with muck objects, for that matter). The details can be found in the following wiki page: http://wiki.ovirt.org/wiki/MockEJBStrategyRule Enjoy, Allon

1 0

[Engine-devel] Testing failed
by Stephen Liu 23 Nov '12

23 Nov '12

Hi all Fedora 17 64bit # cd /home/satimis/jboss-as/bin # ./standalone.sh -b 0.0.0.0 ...... ...... ./standalone.sh: line 178: 2121 Aborted (core dumped) "java" -D"[Standalone]" -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml "-Dorg.jboss.boot.log.file=/home/satimis/jboss-as/standalone/log/boot.log" "-Dlogging.configuration=file:/home/satimis/jboss-as/standalone/configuration/logging.properties" -jar "/home/satimis/jboss-as/jboss-modules.jar" -mp "/home/satimis/jboss-as/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -Djboss.home.dir="/home/satimis/jboss-as" -b 0.0.0.0 Pls help Re running:- http://<server name>:<port>/api server name? Is it the hostname of Fedora17? # hostname fedora17 TIA B.R Stephen L

3 6

[Engine-devel] UI plugins crash course (for plugin developers)
by Vojtech Szocs 23 Nov '12

23 Nov '12

Hi guys, Oved asked me how to get started with writing UI plugins, and I thought I'd post a quick "crash course" for writing simple UI plugin here. Level 1 - Plugin basics ======================= 1. Sync with upstream git repository and apply recent UI plugin patches (rev.6 and rev.7) $ cd <OVIRT_HOME> $ git fetch && git rebase origin $ git fetch git://gerrit.ovirt.org/ovirt-engine refs/changes/20/8120/4 && git checkout FETCH_HEAD $ git fetch git://gerrit.ovirt.org/ovirt-engine refs/changes/50/9250/2 && git checkout FETCH_HEAD 2. Verify your default (machine-specific) Engine configuration - do this if /usr/share/ovirt-engine/conf doesn't exist yet: $ mkdir -p /usr/share/ovirt-engine/conf $ cp <OVIRT_HOME>/backend/manager/conf/engine.conf.defaults /usr/share/ovirt-engine/conf/engine.conf.defaults 3. Create plugin descriptor $ mkdir /usr/share/ovirt-engine/ui-plugins $ vim /usr/share/ovirt-engine/ui-plugins/hello-ui-world.json [hello-world.json] { "name": "HelloWorldPlugin", "url": "/webadmin/webadmin/plugin/HelloWorldPlugin/start.html", "resourcePath": "hello-world-files" } [/hello-ui-world.json] 4. Create plugin host page $ mkdir /usr/share/ovirt-engine/ui-plugins/hello-world-files $ vim /usr/share/ovirt-engine/ui-plugins/hello-world-files/start.html [start.html] <!DOCTYPE html><html><head> <script type='text/javascript'> var api = parent.pluginApi('HelloWorldPlugin'); api.register({ UiInit: function() { window.alert('Hello World!'); } }); api.ready(); </script> </head><body></body></html> [/start.html] 5. See plugin in action by logging into WebAdmin, you should see following message in Engine log: ... Reading UI plugin descriptor [/usr/share/ovirt-engine/ui-plugins/hello-ui-world.json] Level 2 - Using plugin API ========================== 6. Add custom main tab that shows content of the given URL [start.html] ... api.register({ UiInit: function() { api.addMainTab('Test Tab', 'test-tab', 'http://www.example.com/'); } }); ... [/start.html] 7. Update main tab content URL [start.html] ... # Anywhere within event handler function code (e.g. UiInit) api.setMainTabContentUrl('test-tab', 'http://www.another-example.com/'); ... [/start.html] 8. Add custom context-sensitive button to existing main tab [start.html] ... api.register({ UiInit: function() { api.addMainTabActionButton('Host', 'Do something with selected host', { onClick: function() { # arguments[0] is the first selected item var hostId = arguments[0].entityId; window.alert('Host ID ' + hostId); }, isEnabled: function() { # This button is enabled only on single item selection return arguments.length == 1; } }); } }); ... [/start.html] 9. Show custom dialog that shows content of the given URL [start.html] ... # Anywhere within event handler function code (e.g. UiInit) api.showDialog('Test Dialog', 'http://www.example.com/', 600, 400); ... [/start.html] Level 3 - REST API integration ============================== 10. Get notified upon acquiring new Engine REST API session [start.html] ... api.register({ RestApiSessionAcquired: function(sessionId) { window.alert('REST API session ID ' + sessionId); } }); ... [/start.html] Regards, Vojtech

2 4

[Engine-devel] Design review summary for 3.2 - Host Power Management Multiple Agent Support
by Eli Mesika 22 Nov '12

22 Nov '12

http://wiki.ovirt.org/wiki/Talk:HostPMMultipleAgents Regards Eli Mesika

1 0

[Engine-devel] Atlassian Crowd Support for Ovirt
by Justin Hammond 21 Nov '12

21 Nov '12

This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_fJzGa-X67Q+KhqdUoCI9FEhv0D7g0Ni-1T1OEDm6pV+tgkUS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All,=0D=0A=0D=0AI've just uploaded to Gerrit a patch that adds atlassi= an crowd authentication support to oVirt.(http://gerrit.ovirt.org/9324)=0D= =0A=0D=0A=C2=A0=0D=0AAll the nitty gritty details are in the commit messa= ge, but basically this adds a new authentication domain, and when selecte= d sends the authentication request off to a crowd server.=0D=0A=0D=0A=C2=A0= =0D=0AWe have been using this patch on 3.1 for a while, and I thought its= overdue to see if you guys are interested in taking this upstream=3F=0D=0A= =0D=0A=C2=A0=0D=0AThere are two areas that I know could use improvements:= =0D=0A=0D=0A1) caching the results from the crowd server, so we don't que= ry for every API request etc.=0D=0A=0D=0A2) adding proper memberOf suppor= t so groups work correctly.=0D=0A=0D=0A=C2=A0=0D=0APlease let me know if = you guys are interested in this, and please be gentle on your reviews - I= =E1=B8=BF not a Java Programmer by any means, and probably brought too ma= ny C++ traits over here... :)=0D=0A=0D=0A=C2=A0=0D=0AThanks=0D=0A=0D=0A=C2= =A0=0D=0AJustin=0D=0A=0D=0A --=_fJzGa-X67Q+KhqdUoCI9FEhv0D7g0Ni-1T1OEDm6pV+tgkUS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://ww= w.w3.org/TR/html4/loose.dtd"><html>=0A<head>=0A <meta name=3D"Generator"= content=3D"Zarafa WebAccess v7.0.3-30515">=0A <meta http-equiv=3D"Conte= nt-Type" content=3D"text/html; charset=3Dutf-8">=0A <title>Atlassian Cro= wd Support for Ovirt</title>=0A <style type=3D"text/css">=0A body=0D= =0A {=0D=0A font-family: Arial, Verdana, Sans-Serif ! importa= nt;=0D=0A font-size: 12px;=0D=0A padding: 5px 5px 5px 5px;=0D= =0A margin: 0px;=0D=0A border-style: none;=0D=0A bac= kground-color: #ffffff;=0D=0A }=0D=0A=0D=0A p, ul, li=0D=0A = {=0D=0A margin-top: 0px;=0D=0A margin-bottom: 0px;=0D=0A = }=0D=0A </style>=0A</head>=0A<body>=0AHi All,I've jus= t uploaded to Gerrit a patch that adds atlassian crowd authentication sup= port to oVirt.(http://gerrit.ovirt.org/9324) All the n= itty gritty details are in the commit message, but basically this adds a = new authentication domain, and when selected sends the authentication req= uest off to a crowd server. We have been using this pa= tch on 3.1 for a while, and I thought its overdue to see if you guys are = interested in taking this upstream=3F There are two ar= eas that I know could use improvements:1) caching the results from= the crowd server, so we don't query for every API request etc.<p= >2) adding proper memberOf support so groups work correctly. = Please let me know if you guys are interested in this, and please = be gentle on your reviews - I=E1=B8=BF not a Java Programmer by any means= , and probably brought too many C++ traits over here... :) </= p>Thanks Justin=0A</body>=0A</html> --=_fJzGa-X67Q+KhqdUoCI9FEhv0D7g0Ni-1T1OEDm6pV+tgkUS--

2 1

[Engine-devel] [Design for 3.2 RFE] Host Power Management Multiple Agent Support
by Eli Mesika 20 Nov '12

20 Nov '12

Requirements: http://wiki.ovirt.org/wiki/Features/HostPMMultipleAgents DR : http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMMultipleAgents

3 7

[Engine-devel] Registering an existing disk or VM through the REST API
by Morrissey, Christopher 20 Nov '12

20 Nov '12

--_000_D290AD8432118048947689BA3AE8A9B3EBCEB7SACEXCMBX04PRDhqn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, As many of you know, we're working on adding a plugin to oVirt for NetApp s= torage controllers. The plugin will allow users to add a new storage domain= and rapidly clone VMs using the native ONTAP APIs. Our plan is to do this = outside of oVirt in a separate engine and then register the new storage dom= ain or cloned VMs through the REST API. I've been going through the oVirt code and I'm not able to find a way to re= gister an existing VM or disk through the REST API. Am I missing something = or is this functionality that needs to be added? As part of the cloning pro= cess we can generate new UUIDs for the cloned disks and images, but I don't= see a way to get them recognized by oVirt. This functionality is very important to moving forward on our plugin and I = can certainly help add this capability if needed. -Chris Chris Morrissey Software Engineer NetApp Inc. 919.476.4428 --_000_D290AD8432118048947689BA3AE8A9B3EBCEB7SACEXCMBX04PRDhqn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi All,<o:p></o:p> <o:p> </o:p> As many of you know, we’re working on adding a= plugin to oVirt for NetApp storage controllers. The plugin will allow user= s to add a new storage domain and rapidly clone VMs using the native ONTAP = APIs. Our plan is to do this outside of oVirt in a separate engine and then register the new storage domain or clo= ned VMs through the REST API.<o:p></o:p> <o:p> </o:p> I’ve been going through the oVirt code and I&#= 8217;m not able to find a way to register an existing VM or disk through th= e REST API. Am I missing something or is this functionality that needs to b= e added? As part of the cloning process we can generate new UUIDs for the cloned disks and images, but I don’t see = a way to get them recognized by oVirt.<o:p></o:p> <o:p> </o:p> This functionality is very important to moving forwa= rd on our plugin and I can certainly help add this capability if needed.<o:= p></o:p> <o:p> </o:p> -Chris<o:p></o:p> <o:p> </o:p> Chris Morrissey<o:p></o:p> Software Engineer<o:p></o:p> NetApp Inc.<o:p></o:p> 919.476.4428<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_D290AD8432118048947689BA3AE8A9B3EBCEB7SACEXCMBX04PRDhqn_--

4 7

Re: [Engine-devel] network wiring DD questions/comments
by Alona Kaplan 20 Nov '12

20 Nov '12

> Hi, > > I"ve added my answers as inline comments. > > Thanks, > Alona. > > > Hi Alona, > > I reviewed the DD of wired/unwired and I have a few > > questions/comments - > > > > 1. update vnic while the VM is running should be limited to cluster > > 3.2 > > (except for plug/unplug) > I"ve updated the detailed wiki- > 1. On Add- there will be a canDoAction error if the user will try to > change the network to "none" on 3.1 or less. > I don't think the "none" should be removed from the combo. The user > won't understand why sometimes he has "none" and sometimes not. > 2. On Update- there are two problematic cases with 3.1 or less- > 2.1 The user changes the network to "none" - should behave as add. > 2.2 The vnic is plugged (before and after the update) and the only > change is the network. > In this case an "UpdateDevice" verb should be sent to vdsm, so > if it is 3.1 or less the backend should throw a canDoAction. (I > updated the wiki we this scenario) > But, if mac address, type or plug were updated- we are sending > plug/unplug to the vdsm. So the update can be done although for > 3.1. > We talked about disabling all the fields (except "plug/unplug") > in the dialog if the nic is plugged and rollback the ui if the > user change from plugged to unplugged and then to plugged > again. > I don't think it is right. Because if the user wants just to > update the mac for example, we should allow it even if the nic > is plugged. > I think the canDoAction is enough. > 2.3 I think for 3.0 or less, the update button should be disabled if > the vm is not down. (Updated the wiki). > > > > 2. RunVM - why do we need to pass the 'linkState' property to > > VDSM? > > I > > think that if the link is down we should pass none as the network > > and > > if > > the link is up we should pass the network name, like we did so far. > > the > > link-state is internal implementation detail in the engine. > > > I will talk to Simon. If he is ok with it, I will remove the link > state from the feature. > > > 3. looking on the VDSM API - > > * why do we need 'type' ? > Danken wanted UpdateDevice to be a common api for updating all the > devices. By the type the vdsm decides which device is updated. > > * why do we need 'device'? > You are right, it should be removed. (I updated the wiki) > > * why do we need 'alias'? > We don't send the mac. This is the "unique id" of the nic. > The libvirt sets a unique alias for each device(disk, interface...), > so it can be used as the identifier of the device. > > * As I wrote I think we don't need 'linkState' > > > > 4. I am missing the error handling description when the user > > performs > > - > > Update Vnic while changing the type for example. What is the > > behavior > > if > > we succeed to unplug but not plug after that, etc. > > > When changing the type we are internally using the plug/unplug > actions. > If the unplug succeeds and the plug fails- the backend/ui will get an > error from the plug action. > At the end of such situation the vnic will be unplugged. > I"m not sure what we should do with the type- store the new type or > rollback to the old value in the db? > > > 5. Updated APIs section -This section is based on the fact that we > > pass > > linkstate to vdsm which is not needed IMO, so if we change that > > this > > section should be updated accordingly. > > > > 6. The EVENT section is empty, what events should be issued to > > audit > > log? > > I think we should have an even for update vnic and if plug/unplug > > is > > required a second event should be issued. > We already have events for update_vnic failure- > NETWORK_UPDATE_VM_INTERFACE_FAILED and success- > NETWORK_UPDATE_VM_INTERFACE. > And as we use the old plug/unplug actions we don't have to add new > events to the audit log. > I don't think we have to add extra code to the events. > > > > > 7. why does link state is varchar in DB? you expect to support > > other > > option in addition to up/Down (which can be represented by 1 bit), > > maybe > > n/a status? > You are right, should be boolean. (Updated the wiki). > (If Simon will agree to remove the link state from the feature, will > be removed...) > > > > 8. About the open issues- > > > > * About deprecation of ActivateDeactivateVmNic command - I think > > that > > we should remove this command from the backend to avoid duplicate > > flows > > and bugs etc. for Backwards compatibility we should update the > > clients > > to use the new UpdateVmNetworkInterface. the down side for that is > > we > > have to make the can do action validation more complicated > > (according > > to > > cluster level etc.) > > > > * If we remove ActivateDeactivateVmNic there is no need to rename > > it > > ;) > We use it internally. > Also we have to keep it exposed for backward compatibility with Rest > API. > I"m not sure it should be renamed... > > > > > > Thanks, Livnat > > >

2 1

[Engine-devel] network wiring DD questions/comments
by Livnat Peer 20 Nov '12

20 Nov '12

Hi Alona, I reviewed the DD of wired/unwired and I have a few questions/comments - 1. update vnic while the VM is running should be limited to cluster 3.2 (except for plug/unplug) 2. RunVM - why do we need to pass the 'linkState' property to VDSM? I think that if the link is down we should pass none as the network and if the link is up we should pass the network name, like we did so far. the link-state is internal implementation detail in the engine. 3. looking on the VDSM API - * why do we need 'type' ? * why do we need 'device'? * why do we need 'alias'? * As I wrote I think we don't need 'linkState' 4. I am missing the error handling description when the user performs - Update Vnic while changing the type for example. What is the behavior if we succeed to unplug but not plug after that, etc. 5. Updated APIs section -This section is based on the fact that we pass linkstate to vdsm which is not needed IMO, so if we change that this section should be updated accordingly. 6. The EVENT section is empty, what events should be issued to audit log? I think we should have an even for update vnic and if plug/unplug is required a second event should be issued. 7. why does link state is varchar in DB? you expect to support other option in addition to up/Down (which can be represented by 1 bit), maybe n/a status? 8. About the open issues- * About deprecation of ActivateDeactivateVmNic command - I think that we should remove this command from the backend to avoid duplicate flows and bugs etc. for Backwards compatibility we should update the clients to use the new UpdateVmNetworkInterface. the down side for that is we have to make the can do action validation more complicated (according to cluster level etc.) * If we remove ActivateDeactivateVmNic there is no need to rename it ;) Thanks, Livnat

3 2