March 2012 - Devel - oVirt List Archives

[Engine-devel] Problem with detachment of host interface using ovirt-sdk
by Itzik Brown 11 Apr '12

11 Apr '12

--_000_4488206DC085244C886DBC9E7038B68918D382CEMTRDAG01mtlcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'm using ovirt-sdk to attach and detach a network to a host's Interface. Once the network is attached to the interface I try to detach the network f= rom the interface using the following steps: 1.Detach the network from the cluster through the GUI. 2.Remove the network from the datacenter through the GUI. 3.Detach the network from the host's interface using the SDK: nic =3D api.hosts.get(name=3Dhost).nics.get(name=3Dif_name) net =3D params.Network(name=3Dnet_name) act =3D params.Action(network=3Dnet) nic.detach(act) api.hosts.get(name=3Dhost).commitnetconfig() Then I get the error: http://pastebin.com/3Md07huE The same flow using the GUI works fine. Network removal from the Datacenter is a trigger for me to run the detachme= nt operation therefore I use this flow. I use the following components: rhevm-3.0.2_0001-2 ovirt-sdk (Using the latest from git repository) Please advise how to proceed. Thanks, Itzik --_000_4488206DC085244C886DBC9E7038B68918D382CEMTRDAG01mtlcom_ 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,<o:p></o:p> <o:p> </o:p> I'm using ovirt-sdk to attach and detach a network to a host's Inter= face.<o:p></o:p> Once the network is attached to the interface I try to detach the ne= twork from the interface using the following steps:<o:p><= /o:p> <o:p> </o:p> 1.Detach the network from the cluster through the GUI.<o:p></o:p></p= > 2.Remove the network from the datacenter through the GUI.<o:p></o:p>= 3.Detach the network from the host's interface using the SDK:<o:p></= o:p> <o:p> </o:p> nic = =3D api.hosts.get(name=3Dhost).nics.get(name=3Dif_name)<o:p></o:p> net = =3D params.Network(name=3Dnet_name)<o:p></o:p> act = =3D params.Action(network=3Dnet)<o:p></o:p> nic.d= etach(act)= <o:p></o:p> api.h= osts.get(name=3Dhost).commitnetconfig()<o:p></o:p> <o:p> </o:p> Then I get the error:<o:p></o:p> <a href=3D"http://pastebin.com/3Md07huE">http://pastebin.com/3Md07hu= E</a><o:p></o:p> <o:p> </o:p> The same flow using the GUI works fine.<o:p></o:p> <o:p> </o:p> Network removal from the Datacenter is a trigger for me to run the d= etachment operation therefore I use this flow.<o:p></o:p> <o:p> </o:p> I use the following components:<o:p></o:p> <o:p> </o:p> rhevm-3.0.2_0001-2<o:p></o:p> ovirt-sdk (Using the latest from git repository)<o:p></o:p> <o:p> </o:p> Please advise how to proceed.<o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> Itzik<o:p></o:p> </div> </body> </html> --_000_4488206DC085244C886DBC9E7038B68918D382CEMTRDAG01mtlcom_--

3 3

[Engine-devel] VM Payload feature
by Oved Ourfalli 10 Apr '12

10 Apr '12

Hey all, Continuing the discussion about Aeolus instance data injection to a VM (http://lists.ovirt.org/pipermail/engine-devel/2012-January/000423.html) we propose a new VM Payload feature. The following wiki page contains a description page of the feature. http://www.ovirt.org/wiki/Features/VMPayload Please read and review. There are several approaches there, and we wish to head your opinions and thoughts about them. Once we agree on an approach, we will start designing. Thank you, Oved

10 18

[Engine-devel] Reloadable Configuration - Wiki Page
by Muli Salem 02 Apr '12

02 Apr '12

Hi All, Below please find a wiki page regarding the design of the Reloadable Configuration feature. You are more than welcome to review and comment. http://www.ovirt.org/wiki/Features/ReloadableConfiguration Thanks, Muli

6 13

[Engine-devel] advanced nfs options in vdsm
by Laszlo Hornyak 02 Apr '12

02 Apr '12

Hi Saggi, The wiki page of the Advanced NFS options says that the changes needed in vdsm are already done http://www.ovirt.org/wiki/Features/AdvancedNfsOptions Which VDSM release has this feature built in? Also, could you send me what changes have been done on vdsm? Thank you, Laszlo

2 2

[Engine-devel] 'Import VM/Template More Than Once' feature
by Gilad Chaplik 30 Mar '12

30 Mar '12

Hello all, The 'Import VM/Template More Than Once' feature description can be found under the following link: http://www.ovirt.org/wiki/Features/ImportMoreThanOnce Please review, and feel free to share your comments and thoughts. Thanks, Gilad.

7 10

[Engine-devel] [Jenkins] new high priority bug still open in ovirt-engine
by Eyal Edri 29 Mar '12

29 Mar '12

fyi, these commits caused a new high priority bug: common: Changes to image_storage_domain_map (detail / gitweb) core: Extracting ImageStorageDomainMap Dao (detail / gitweb) details here: http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_find_bugs/470/ please check, Eyal Edri oVirt Infra Team

2 1

[Engine-devel] Manual DB change required - remove grant_mode column from DB
by Moti Asayag 29 Mar '12

29 Mar '12

Hi, The commit which added the grant_mode column to the permissions table was reverted (604ae480ab677b06e53abd0edfaf0ec04f017fb8). If you upgraded the DB since the 25/3, please run manually the next command in order to drop that column and run refresh procedure afterwards/run upgrade script: echo 'alter table permissions drop column grant_mode' | psql engine postgres (supply database name if differ from engine). Thanks, Moti

1 0

[Engine-devel] Getting rid of PowerMock?
by Yair Zaslavsky 29 Mar '12

29 Mar '12

Hi all, As (almost) all of us can see, Running BLL tests both takes considerable time, and also we have to take class loading dependencies between classes with static methods when we use mockStatic - IMHO, this is kinda frustrating. Maybe we should start get rid of PowerMock. Here is what I'm thinking of - Currently, as we use no IoC for DAOs , for tested class we do not use DbFacade.getInstance().getXXXDao() instead we define: protected XXXDao getXXXDao() { return DBFacade.getInstance().getXXXDao(); } And then in our tests we use Mockito to define how getXXDao acts in the test. The following can be achieved also for config values , the following way - protected <T> T getConfig(ConfigValues key) { return Config.<T> GetValue(key); } And then in code (for example, in a query test) - doReturn(5).when(query).<Integer> getConfig(any(ConfigValues.SomeIntegerConstant)); This effort can be done in small steps - a. Define getConfig method in base classes (i.e AuditLoggalbeBase). b. Rewrite parts (i.e Commands, and their tests) step by step (small commits) Thoughts and ideas are more than welcome, Yair

5 9

[Engine-devel] Monitor host's Default Gateway
by avi tal 28 Mar '12

28 Mar '12

Hi, Detach host's interface that holds the Default Gateway would be very dangerous. there for Engine must start monitor who holds the default gateway. It is true, a static IP interface can never add gateway (other than mgmt) due to CanDoAction but what about DHCP? If a non-mgmt interface with DHCP got the gateway, Engine must know about it in order to protect connectivity to the host. BTW, VDSM send these details in getCapabilities. Bottom line, we should not limit other interfaces from holding gateway, not by statically or dhcp configuration. there is a reason why someone would like to have his gateway on a different interface than the mgmt. But non-mgmt interface that holds the gateway should be treated as mgmt interface when trying to remove or edit it. Thanks

1 0

[Engine-devel] Engine meeting
by Karsten 'quaid' Wade 28 Mar '12

28 Mar '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi: I just learned that this team's open project meeting is held as a teleconference. Would you consider switching it to a regular IRC meeting, perhaps with an occasional phone call? IRC meetings have many advantages in an open project: low barrier of access, easier to understand for non-native speakers, meeting log is archivable and searchable, and more inviting for the project. For phone meetings, do you publish the audio recording? That is not optimal, but at least it allows for someone to transcribe the discussion. Cheers - Karsten - -- name: Karsten 'quaid' Wade, Sr. Community Architect team: Red Hat Community Architecture & Leadership uri: http://communityleadershipteam.org http://TheOpenSourceWay.org gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPcx1j2ZIOBq0ODEERAj1+AKDla8pokm8KifAoFOj/FE4fsXAP3wCeOJRL oQfAO+hE2tXx5fbifJUeasY= =Ftj6 -----END PGP SIGNATURE-----

3 6

[Engine-devel] agenda for todays meeting
by Livnat Peer 28 Mar '12

28 Mar '12

Hi, Today's meeting include status of the different features. If you want to add something for the agenda please send to the list. Thanks, Livnat

1 0

[Engine-devel] Feature: backend support for Advanced NFS Options
by Laszlo Hornyak 28 Mar '12

28 Mar '12

Hi, http://www.ovirt.org/wiki/Features/AdvancedNfsOptions#Changes_in_ovirt_engi… Your feedback is welcome. Laszlo

3 5

[Engine-devel] How to utilize Jenkins to do your dirty (build) work for you...
by Mike Kolesnik 27 Mar '12

27 Mar '12

--=_d543864b-a903-4efd-9bb5-a1966dfe6475 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, -- Intro -- When working on your local GIT repo you probably do a lot of: mvn clean install Additionally, if you're working on oVirt-engine you might be doing some of: mvn test -Penable-dao-tests mvn install -Pgwt-admin etc.. This, of course, might take your development computer a while, and hog your resources. Usually though, if you work on oVirt, you have a host that you use for testing your changes.. This host probably has a 2/4 cores CPU and at least 4Gb of RAM.. This host is sitting quietly most of the time, consuming mostly electricity but not doing much. You're probably not even utilizing it that much even when you are testing something on it. It is like a powerful guard dog that you keep tied in the back-yard most of the time, instead of letting it run free. Well, I have a suggestion how to put that puppy into good use and also free up your resources.. -- End Intro -- You can install Jenkins on the host, and have it monitor your local GIT repo for changes, building your commits as necessary. This works with every local branch you have - Jenkins will pick up the change (be it a local commit you just did, or a rebase over the origin) and generate a build for it. This will allow you to monitor your build results just as you would monitor locally, while in the same time utilize a (probably) more powerful machine to do this for you. It will also probably speed up your build cycle, as builds will be executed in parallel. I have written an installation guide which explains how to do it in the oVirt wiki: http://www.ovirt.org/wiki/Local_Jenkins_For_The_People I have also written a script that will run the installation part on the host for you, so you just need to download the attachment and run it as root on the host, but you will still need to do some manual work so make sure to check the wiki. -- Example Jobs -- I am also attaching sample jobs to import to Jenkins. Make sure to replace the GIT repo URL, you can do this before importing with sed: # sed -i 's#[git-repo-url]#ssh://[user]@[git-host]/[git-repo-location]#' oVirt-engine.* For example: # sed -i 's#[git-repo-url]#ssh://mkolesni@myhost/~/git/ovirt-engine#' oVirt-engine.* You can import them with the command: # cat [job].xml | java -jar /tmp/jenkins-cli.jar -s http://localhost:8080 create-job [job-name] For example: # cat oVirt-engine.xml | java -jar /tmp/jenkins-cli.jar -s http://localhost:8080 create-job oVirt-engine -- End Example Jobs -- Of course, this might not be ideal in cases when you need 100% percent of your host.. But in such a case you can simply turn off Jenkins, and turn it back on later. ;) Regards, Mike --=_d543864b-a903-4efd-9bb5-a1966dfe6475 Content-Type: application/x-shellscript; name=jenkins.sh Content-Disposition: attachment; filename=jenkins.sh Content-Transfer-Encoding: base64 IyEgL2Jpbi9iYXNoCiMKIyBDb3B5cmlnaHQgKGMpIDIwMTIgUmVkIEhhdCwgSW5jLgojCiMgTGlj ZW5zZWQgdW5kZXIgdGhlIEFwYWNoZSBMaWNlbnNlLCBWZXJzaW9uIDIuMCAodGhlICJMaWNlbnNl Iik7CiMgeW91IG1heSBub3QgdXNlIHRoaXMgZmlsZSBleGNlcHQgaW4gY29tcGxpYW5jZSB3aXRo IHRoZSBMaWNlbnNlLgojIFlvdSBtYXkgb2J0YWluIGEgY29weSBvZiB0aGUgTGljZW5zZSBhdAoj CiMgICAgICAgICAgIGh0dHA6Ly93d3cuYXBhY2hlLm9yZy9saWNlbnNlcy9MSUNFTlNFLTIuMAoj CiMgVW5sZXNzIHJlcXVpcmVkIGJ5IGFwcGxpY2FibGUgbGF3IG9yIGFncmVlZCB0byBpbiB3cml0 aW5nLCBzb2Z0d2FyZQojIGRpc3RyaWJ1dGVkIHVuZGVyIHRoZSBMaWNlbnNlIGlzIGRpc3RyaWJ1 dGVkIG9uIGFuICJBUyBJUyIgQkFTSVMsCiMgV0lUSE9VVCBXQVJSQU5USUVTIE9SIENPTkRJVElP TlMgT0YgQU5ZIEtJTkQsIGVpdGhlciBleHByZXNzIG9yIGltcGxpZWQuCiMgU2VlIHRoZSBMaWNl bnNlIGZvciB0aGUgc3BlY2lmaWMgbGFuZ3VhZ2UgZ292ZXJuaW5nIHBlcm1pc3Npb25zIGFuZAoj IGxpbWl0YXRpb25zIHVuZGVyIHRoZSBMaWNlbnNlLgojCgp1c2FnZSgpIHsKIyAgICBlY2hvICJV c2FnZTogJHtNRX0gWy1oXSAtcyBTRVJWRVJOQU1FIC11IFVTRVJOQU1FIFstdl0iCiAgICBlY2hv ICJVc2FnZTogJHtNRX0gWy1oXSBbLWZdIFstdl0iCiAgICBlY2hvICIiCiMgICAgZWNobyAiICAt cyBTRVJWRVJOQU1FIC0gVGhlIElQL0ZRRE4gZm9yIHRoZSBHSVQgc2VydmVyLiAgICAgICAgICAg KGVnIHlvdXIgbWFjaGluZSkiCiMgICAgZWNobyAiICAtdSBVU0VSTkFNRSAgIC0gVGhlIHVzZXIg eW91IGFyZSB1c2luZyBvbiB0aGUgR0lUIHNlcnZlci4gKGVnIHlvdXIgdXNlcikiCiAgICBlY2hv ICIgIC12ICAgICAgICAgICAgLSBUdXJuIG9uIHZlcmJvc2l0eS4iCiAgICBlY2hvICIgIC1mICAg ICAgICAgICAgLSBVc2UgZm9yY2UgKGRvbid0IHN0b3AgaWYgYSBjcml0aWNhbCBzdGVwIGZhaWxz KS4iCiAgICBlY2hvICIgIC1oICAgICAgICAgICAgLSBUaGlzIGhlbHAgdGV4dC4iCiAgICBlY2hv ICIiCgogICAgZXhpdCAwCn0KCmZ1bmN0aW9uIHByaW50U3VjY2VzcyB7CiAgICBpZiBbICQyID0g MCBdCiAgICB0aGVuCiAgICAgICAgc3VjY2Vzc1N0cj0nW1NVQ0NFU1NdJwogICAgZWxzZQogICAg ICAgIHN1Y2Nlc3NTdHI9J1tGQUlMRURdJwogICAgZmkKCiAgICBsaW1pdD0kKGVjaG8gNzkgLSAk KCBlY2hvICRzdWNjZXNzU3RyIHwgd2MgLW0pIHwgYmMpCiAgICBzdGFydD0kKGVjaG8gMSArICQo ZWNobyAkMSB8IHdjIC1tKSB8IGJjKQoKICAgIGVjaG8gLW4gJDEnICcKCiAgICBmb3IgaSBpbiBg c2VxICRzdGFydCAkbGltaXRgOwogICAgZG8KICAgICAgICBlY2hvIC1uICcuJwogICAgZG9uZQoK ICAgIGVjaG8gJyAnJHN1Y2Nlc3NTdHIKfQoKZnVuY3Rpb24geXVtSW5zdGFsbCB7CiAgICB5dW0g aW5zdGFsbCAkVkVSQk9TRSAteSAkMQoKICAgIHN1Y2Nlc3M9JD8KICAgIHByaW50U3VjY2VzcyAi SW5zdGFsbGVkICQxIiAkc3VjY2Vzcwp9CgpmdW5jdGlvbiBzdGFydFNlcnZpY2UgewogICAgY2hr Y29uZmlnICQxIG9uCiAgICBzdWNjZXNzPSQ/CiAgICBwcmludFN1Y2Nlc3MgIkVuYWJsZWQgJDEg c2VydmljZSBvbiBzdGFydC11cCIgJHN1Y2Nlc3MKCiAgICBpZiBbICRzdWNjZXNzIF0KICAgIHRo ZW4KICAgICAgICBzZXJ2aWNlICQxIHN0YXJ0CiAgICAgICAgc3VjY2Vzcz0kPwogICAgICAgIHBy aW50U3VjY2VzcyAiU3RhcnRlZCAkMSBzZXJ2aWNlIiAkc3VjY2VzcwogICAgZmkKfQoKZnVuY3Rp b24gaW5zdGFsbFBsdWdpbiB7CiAgICBqYXZhIC1qYXIgL3RtcC9qZW5raW5zLWNsaS5qYXIgLXMg aHR0cDovL2xvY2FsaG9zdDo4MDgwIGluc3RhbGwtcGx1Z2luICQxCiAgICBwcmludFN1Y2Nlc3Mg Ikluc3RhbGxlZCBKZW5raW5zICQxIHBsdWdpbiIgJD8KfQoKVkVSQk9TRT0nLXEnCndoaWxlIGdl dG9wdHMgOmhmdiBvcHRpb247IGRvCiAgICBjYXNlICRvcHRpb24gaW4KIyAgICAgICAgcykgU0VS VkVSTkFNRT0kT1BUQVJHOzsKIyAgICAgICAgdSkgVVNFUk5BTUU9JE9QVEFSRzs7CiAgICAgICAg dikgVkVSQk9TRT0nJzs7CiAgICAgICAgZikgRk9SQ0U9dHJ1ZTs7CiAgICAgICAgaCkgdXNhZ2U7 OwogICAgZXNhYwpkb25lCgojaWYgW1sgIiRTRVJWRVJOQU1FIiA9ICcnIHx8ICIkVVNFUk5BTUUi ID0gJycgXV0KI3RoZW4KIyAgICBlY2hvICJFUlJPUjogT25lIG9yIG1vcmUgcmVxdWlyZWQgcGFy YW1ldGVycyBhcmUgbWlzc2luZy4iCiMgICAgdXNhZ2UKI2ZpCgoKZWNobyAiSW5zdGFsbGluZyBw cmUtcmVxdWlzaXRlczoiCmVjaG8gIj09PT09PT09PT09PT09PT09PT09PT09PT09IgoKeXVtSW5z dGFsbCBudHAKCmlmICFncmVwICIxMC41LjI2LjEwIiAvZXRjL250cC5jb25mICY+IC9kZXYvbnVs bAp0aGVuCiAgICBlY2hvICJcbnNlcnZlciAxMC41LjI2LjEwICMgQWRkZWQgYnkgamVua2lucyBp bnN0YWxsIHNjcmlwdC5cbiIgPj4gL2V0Yy9udHAuY29uZgogICAgcHJpbnRTdWNjZXNzICJBZGRl ZCB3b3JraW5nIE5UUCBzZXJ2ZXIiICQ/CmZpCgoKeXVtSW5zdGFsbCBqYXZhCnl1bUluc3RhbGwg Z2l0CgppZiBncmVwIEZlZG9yYSAvZXRjL3JlZGhhdC1yZWxlYXNlICY+IC9kZXYvbnVsbAp0aGVu CiAgICB5dW1JbnN0YWxsIG1hdmVuCmVsc2UKICAgIHJwbSAtVXZoIGh0dHA6Ly9kb3dubG9hZC5m ZWRvcmFwcm9qZWN0Lm9yZy9wdWIvZXBlbC82L2kzODYvZXBlbC1yZWxlYXNlLTYtNS5ub2FyY2gu cnBtCiAgICB3Z2V0ICRWRVJCT1NFIC1PIC9ldGMveXVtLnJlcG9zLmQvZXBlbC1hcGFjaGUtbWF2 ZW4ucmVwbyBodHRwOi8vcmVwb3MuZmVkb3JhcGVvcGxlLm9yZy9yZXBvcy9kY2hlbi9hcGFjaGUt bWF2ZW4vZXBlbC1hcGFjaGUtbWF2ZW4ucmVwbwogICAgeXVtSW5zdGFsbCBhcGFjaGUtbWF2ZW4K ZmkKCnl1bUluc3RhbGwgcG9zdGdyZXNxbC1zZXJ2ZXIKeXVtSW5zdGFsbCBwb3N0Z3Jlc3FsLWNv bnRyaWIKCmlmIFsgIiQocnBtIC1xIHBvc3RncmVzcWwgfCBjdXQgLWYyIC1kJy0nIHwgY3V0IC1m MSAtZCcuJykiID0gIjgiIF0KdGhlbgogICAgc3UgLSBwb3N0Z3JlcyAtYyAnaW5pdGRiIC1VIHBv c3RncmVzIC1EIC92YXIvbGliL3Bnc3FsL2RhdGEvJwplbHNlCiAgICBzdSAtIHBvc3RncmVzIC1j ICdwZ19jdGwgaW5pdGRiJwpmaQoKcHJpbnRTdWNjZXNzICJJbml0aWFsaXplZCBEQiIgJD8KCmVj aG8gIiIKZWNobyAiSW5zdGFsbGluZyBKZW5raW5zIENJOiIKZWNobyAiPT09PT09PT09PT09PT09 PT09PT09PSIKCndnZXQgJFZFUkJPU0UgLU8gL2V0Yy95dW0ucmVwb3MuZC9qZW5raW5zLnJlcG8g aHR0cDovL3BrZy5qZW5raW5zLWNpLm9yZy9yZWRoYXQvamVua2lucy5yZXBvCgpwcmludFN1Y2Nl c3MgJ0Rvd25sb2FkZWQgSmVua2lucyByZXBvJyAkPwoKcnBtIC0taW1wb3J0IGh0dHA6Ly9wa2cu amVua2lucy1jaS5vcmcvcmVkaGF0L2plbmtpbnMtY2kub3JnLmtleQoKcHJpbnRTdWNjZXNzICdJ bXBvcnRlZCBKZW5raW5zIFJQTSBrZXknICQ/Cgp5dW1JbnN0YWxsIGplbmtpbnMKCmlmIFtbICIk c3VjY2VzcyIgIT0gIjAiICYmICEkRk9SQ0UgXV0KdGhlbgogICAgZWNobyAiRkFUQUw6IENhbid0 IGluc3RhbGwgSmVua2lucywgZXhpdGluZy4iCiAgICBleGl0IDEKZmkKCnN0YXJ0U2VydmljZSBq ZW5raW5zCgppZiBbWyAiJHN1Y2Nlc3MiICE9ICIwIiAmJiAhJEZPUkNFIF1dCnRoZW4KICAgIGVj aG8gIkZBVEFMOiBDYW4ndCBzdGFydCBKZW5raW5zIHNlcnZpY2UsIGV4aXRpbmcuIgogICAgZXhp dCAxCmZpCgojc3UgLSAtcyAvYmluL2Jhc2ggLWMgInNzaCAtbyAnU3RyaWN0SG9zdEtleUNoZWNr aW5nIG5vJyAkVVNFUk5BTUVAJFNFUlZFUk5BTUUgJ2VjaG8gU3VjY2VzcyA+IC9kZXYvbnVsbCci IGplbmtpbnMKCiNwcmludFN1Y2Nlc3MgIkFkZGVkIHNlcnZlciAkU0VSVkVSTkFNRSB0byBrbm93 biBob3N0cyBsaXN0IiAkPwoKI3N1IC0gLXMgL2Jpbi9iYXNoIC1jICJpZiBbICEgLWUgfi8uc3No L2lkX3JzYS5wdWIgXTsgdGhlbiBzc2gta2V5Z2VuIC1xIC10IHJzYTsgZmkgJiYgc3NoLWNvcHkt aWQgJFVTRVJOQU1FQCRTRVJWRVJOQU1FIiBqZW5raW5zCgojcHJpbnRTdWNjZXNzICJHZW5lcmF0 ZWQgJiBkZXBsb3llZCBTU0ggcHVibGljLWtleSIgJD8KCgplY2hvICIiCmVjaG8gIkluc3RhbGxp bmcgSmVua2lucyBQbHVnaW5zOiIKZWNobyAiPT09PT09PT09PT09PT09PT09PT09PT09PT09IgoK ZWNobyAiV2FpdCAzMHMgZm9yIGplbmtpbnMgdG8gZ28gdXAuLiIKc2xlZXAgMzBzCgp3Z2V0ICRW RVJCT1NFIC1PIC90bXAvamVua2lucy1jbGkuamFyIGh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9qbmxw SmFycy9qZW5raW5zLWNsaS5qYXIKCnByaW50U3VjY2VzcyAiRG93bmxvYWRlZCBKZW5raW5zIENM SSIgJD8KCndnZXQgJFZFUkJPU0UgLU8gL3RtcC9qZW5raW5zLXVwZGF0ZS1jZW50ZXIudG1wIGh0 dHA6Ly91cGRhdGVzLmplbmtpbnMtY2kub3JnL3VwZGF0ZS1jZW50ZXIuanNvbgoKdGFpbCAtbiAr MiAvdG1wL2plbmtpbnMtdXBkYXRlLWNlbnRlci50bXAgfCBoZWFkIC1uIC0xID4gL3RtcC9qZW5r aW5zLXVwZGF0ZS1jZW50ZXIuanNvbgoKY3VybCAtWCBQT1NUIC1kIEAvdG1wL2plbmtpbnMtdXBk YXRlLWNlbnRlci5qc29uIGh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC91cGRhdGVDZW50ZXIvYnlJZC9k ZWZhdWx0L3Bvc3RCYWNrCgpwcmludFN1Y2Nlc3MgIlxuSW5pdGlhbGl6ZWQgSmVua2lucyB1cGRh dGUgY2VudGVyIiAkPwoKaW5zdGFsbFBsdWdpbiBnaXQKaW5zdGFsbFBsdWdpbiBjaGVja3N0eWxl Cmluc3RhbGxQbHVnaW4gZmluZGJ1Z3MKaW5zdGFsbFBsdWdpbiBidWlsZC1uYW1lLXNldHRlcgpp bnN0YWxsUGx1Z2luIHNhZmVyZXN0YXJ0CgpqYXZhIC1qYXIgL3RtcC9qZW5raW5zLWNsaS5qYXIg LXMgaHR0cDovL2xvY2FsaG9zdDo4MDgwIHNhZmUtcmVzdGFydAoKcHJpbnRTdWNjZXNzICJSZXN0 YXJ0ZWQgSmVua2lucyBhZnRlciBwbHVnaW5zIGluc3RhbGxlZCIgJD8KCmVjaG8gIkplbmtpbnMg c2hvdWxkIG5vdyBiZSBpbnN0YWxsZWQgJiB3b3JraW5nLCBlbmpveSEiCgpleGl0IDAKCg== --=_d543864b-a903-4efd-9bb5-a1966dfe6475 Content-Type: application/x-compressed-tar; name=oVirt-engine.jobs.tar.gz Content-Disposition: attachment; filename=oVirt-engine.jobs.tar.gz Content-Transfer-Encoding: base64 H4sIAFRvcE8AA+0ba2/bODKf8yuE3uIKBGfJzqsFztUisdM2u3nBTpo7LBYFLdGyGkoUSCrZYLH/ /YYvvazE6W4et60mQCzOjMjhcMh5SKKfYiZ6OI3iFLvjvVNXYC64+1tC1h4N+gC729vqF6D5u7nT 31kbDN5sbfd332zvbK31B9vbm1trTv/xRLgbci4Qc5w1Rqm4j28V/W8Kwx9hqZ1rzHhM03evB27/ tYPTgIZxGr17fXH+vvf29Y/++jBj9AsOhL/uOEMUCGDmnmqEmAcsziTGn+SpIxbYATtylB05VCNm eUxCZ85o4tCKwTloLjBTHJLdGe87MXcChpHAoTv0qn3LsQiNJlQgQZlsysHRLT+nP2Oc+ZvAXrY0 Oc0T0+4Nhl7Z0lTERDyHuYzL2yRbC7rOf1LrdRkrJfXqog6vgDDGGU5DUG6MuT9HhOOht4SXzKDr DEO32KiYB4kTEMT5u1eLPOQ0dQHjnuSETEfHrzRPgNIJRYkvWA7d2pZaoJijGcGhIRVNSZsRGlzt y8W5XOB0TG9SLkD7iUKBBVgxV/Itd3aRNVj08CuYZD+CxVEEBmnnfA12R5mdJ02DnDGcCnWPFbCJ VqywtWlySdkVz1CA/Rt75VVtEO5t8Km5yF5ABrP0Ru0C8SvuHqNrnGqClBaxCAvuKwPuneFUarcX ItpTO2DoWQZ7QyJvP0EJ9tXV1tArMZYno4k/Q8EV2AVQUwTq8BIa5gRMIkTEA7o8oofyorgp5/iM xdewdyY4ozwGpd1a/bTS9Ny89snBUlV0MMzyGYn54g6VfMnTWLg/XcD/CeY5EXssWMRwqpRqAmVo Evc3NoxSPJ4zPI8Z7jGQignubehpVbltD3KrHNE0moowptX9UyKrg42RQGeF0F7rZO8VG5Rbm7O2 iUuGskx3CAzmUHzpQ/wvAK35/31XH77P6/+3tgdL/r+/3fn/54BH9f8jZTzSjStXDwQkgoUzp6wt AoARcOfjvykf39rV39LJTxeYkMKhBDQBNxz6Qeg03XI40/bLnX+iJPu3+ue4nj5HP4czly+cXu6A 0xURw9zphU4hk+m1zTUV43+VH1Z6OdeqLYVfAPJM71/u09aED4SpcRWedAEyLygJLUbuOBmpTC9G o4PpFHZcJW4BImWwxIj4/aFnL0tiQAnslf2jiwM5eUJLGb3GQA1tNOf1ffjm54CaOXy4PHcv8Wwv TOL0EUOAFf5/d3Nnu+H/d/qDzc7/Pwc81P+rHGWzZ5IQvCIQ6Nz6nW49IznsNe5GkHl8iIX07kZI cG/zOPqkl0IqpY5Yt0kem+CECjxS1PKobun/osHcPMSXTm/IxniGAyDYq5KWM+L/Ar2qXK0HrV8h rWSlj/QeLIBKR9tmMZwxlAYLfO+k9hXPtC6cmsfGRn1CrSI1bwf/WhvUxlLTfGaM3S74MmHdKA2i Eg5p4/ItbSQzCv2AUwzxcUnSqsgBJzdVMepKRmPiuVhQdspGEFTEQoCfNB0sE4y5EYzSIrRSDU24 iTN8mosyVjI8S3jNnrE8xftWh4a3jrR6kgt+RiGuKdRTYMz6Szc+WlAK9nHPvslFTNwxniNI2fcr t7yyaT4wnVNKfMMz9CxCk3mhyXlkh4FoQhT3M0xAudf4XJUpxjFTO6KJs7xzDDFpgPWuMdeahn8L SB7icIIjtVRDr4mp88n9UuXS7WJOeuFP9Nattxs8BwmKSZVJI8z0r+LsHBXRum1qYpw2RW5iTCdB YgSxV+rwhEaXq9yRq8gQ4ljZnV0uRvPsMPQpi1x6DYGYa1MDS6m7L0DIPkrPpTnA7mo9DyMKQvhq TzuwZwQixOmN1TqrqnxvHN3ALgLj2otAwncRDq7o4PNbp3cGhB6S8R/IoHpZtyXLU8hx/N5/wBqi wNQsFUoFAhHkNpF0mVNxS7Cesl7fVtK6NjTY/zA8IjXNLeGVX8VMz0/bse66gVSdRillWK9iMlqg NCrPpFaakl5V/WC1x9YW7dG5RFDLiDkl17gtJmgjmbAgwJyf6TOsPCRr2ELTnxCJQ3W4H+FrTFSs 0kpQ0uTpR4xC8CylFBWUCkKwEDAJfRCAycAubWCU0RA6Q2S6xNuO14qQRVtbXV2Rmu4Zk12qDFtb BvEZTYXMrW/wTNlgUfMuEKZuvOHeIFZugzJegCMaLPw0JUXlu4JpyyzbxLo/uzTdyD37BadXsHJB XHgnxSljEKlhzHTiKk/HKS5dr6pQJ5mUzP/HD7/vXxwejT+fXBzvH0z+6P3w+4fD88/7k72T0cc/ ZCXcMBrh//Swpo5QnQWYJbbFBbOElIs6BmzpDJBTgTN+ONdVchuiy0P//d7h0cXkoBp4FTWAzUYN wOT/k4NxJf1X5toyhDH5asrx0rnStwi1/P8Jnv1LWJH/77x502/W//tb/S7/fw54mvz/fQ4Rh3oi Cptb1f9lCKJszVQ/u6f7XYmgKxF0JYKuRNCVCLoSwdeXCNwActl76gTmMeXKUoFsnp0eF28bFW8W WUJZT5D+vKsKdFWBP1sV8Lpc+v8vl67lf4+e+Wm4P/8bDDZ3dxv5H2C697+eBbrnv99xckchapGV /m8rxfO6HO/FczwTinUp3ved4sHvaCEfLuZiggW7HdE8Ff6g31csLaQnzAvbvj95obTQKM8+iDJM LviC5rub6vTdcN72NvvOBvz1e9ugusqpdX8fEPMawpMlok/8rLpLOLuE86EJZ31bWVcRyFOGy0V3 1YGj1n9i7ilDDIyIWNzCQPbKUtQsDK28tlQ9ijr5fhl9PBj9PD3/79HBr/IZckkpMlX7kvNRDD7Y J/Sm8uKzxllWeezl6Wn6HkyqtIQGthCRw1oTgWBh8tIKGtglIQqUmiTsPDCtcwh8yR4haq4N1B3c H+No0WRXuDv4TyhL0NIABnvHPUf0pnmDRC1zn+CbuvQG0crZkNxiWnmXpC5xrfx1iQ2i5JyrBaxo u4Fo5TTyNjGtvIW8y7hWfi1vA9HkLLRba7Zw1SRd1muBb0jZptOCUpWwrs/KJirNPKQpBD1Jlgup /TKMrmHrTvTBJ4Y8YStnzoo3X2Td1N0z/ge0W3zbWHyeWAhtgiy9vZXb4RV/tERqxABfNdpf+3BE vSnwL+fOrwcapOLDwm/qO5OuevnS1csOOuiggw466KCDDjrooIMOHgr/AzZt6DAAUAAA --=_d543864b-a903-4efd-9bb5-a1966dfe6475--

2 2

[Engine-devel] Extend host_nics action with UpdateNetworks
by avi tal 27 Mar '12

27 Mar '12

This is a multi-part message in MIME format. --------------040202050707070305020800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I am checking the SetupNetwork feature in 3.1 (si01) and I think we are missing a very important implementation. SetupNetworks in vdsm layer is able to receive a nics collection which describe which nics will be updated and handle only those nics. This implementation is missing from engine-backend because backend automatically treat missing nics as nics we would like to remove. A very buggy scenario would be, missing mgmt network. The idea is to send (via REST API) a collection which contain only the interfaces (nics) we would like to update. This is actually an UPDATE collection procedure. it could be added as a different action: http://engine ip:port/hosts/id/nics/*updatenetworks* I believe it is a part of the SetupNetwork feature that needs to be in 3.1. Thanks --------------040202050707070305020800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi, I am checking the SetupNetwork feature in 3.1 (si01) and I think we are missing a very important implementation. SetupNetworks in vdsm layer is able to receive a nics collection which describe which nics will be updated and handle only those nics. This implementation is missing from engine-backend because backend automatically treat missing nics as nics we would like to remove. A very buggy scenario would be, missing mgmt network. The idea is to send (via REST API) a collection which contain only the interfaces (nics) we would like to update.  This is actually an UPDATE collection procedure. it could be added as a different action: <a class="moz-txt-link-freetext" href="http://engine">http://engine</a> ip:port/hosts/id/nics/updatenetworks I believe it is a part of the SetupNetwork feature that needs to be in 3.1. Thanks </body> </html> --------------040202050707070305020800--

2 1

[Engine-devel] check
by avi tal 27 Mar '12

27 Mar '12

1 0

[Engine-devel] checking
by avi tal 27 Mar '12

27 Mar '12

1 0

[Engine-devel] [Jenkins] ovirt engine unit tests failed
by Eyal Edri 26 Mar '12

26 Mar '12

ovirt-engine unit tests failed after this commit: core : It is possible to clone preallocated COW VM from template on NFS storage domain (#805811) (detail / gitweb) Failed test: org.ovirt.engine.core.bll.AddVmCommandTest.create10GBVmWith11GbAvailableAndA5GbBuffer please check: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/455/ eyal.

1 0

[Engine-devel] Bridgeless Networks api design
by Michael Pasternak 26 Mar '12

26 Mar '12

Hi, First of all i would like to understand the exact meaning of the vm_network, from the wiki [1] - "a "Vm network" is implemented over a bridge, otherwise bridgeless", if so, why not calling network property <bridged>true|false</bridged>? from the other hand i understand that this is only current implementation and it may change in a future, anyway adding <vm_network>true|false</vm_network> property to <network> entity in api (as was suggested) doesn't sound good cause vm_network sounds as a network type, but then the question is Management/Migration/Storage/Display should be also network's types? and if single network can be used for the Management|Migration|Storage|Display simultaneously? if the answer is yes, network modelling probably should look like: <network> <bridged>true|false</bridged> <type>Management/Migration/Storage/Display</type> </network> or <network> <bridged>true|false</bridged> <designation>Management|Migration|Storage|Display</designation> </network> your thoughts? [1] http://www.ovirt.org/wiki/Features/Design/Network/Bridgeless_Networks -- Michael Pasternak RedHat, ENG-Virtualization R&D

6 11

[Engine-devel] Releases/31/FeatureList - oVirtWiki
by Yaniv Kaul 22 Mar '12

22 Mar '12

Is anyone maintaining this page? Is it up-to-date, wrt feature list, completion percentage, etc.? http://www.ovirt.org/wiki/Releases/31/FeatureList

2 1

[Engine-devel] Forward comp[atibility of OVF
by Mike Kolesnik 22 Mar '12

22 Mar '12

--=_bc9b6b95-2d7c-4155-b37b-029c2446b231 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, I wanted to know if we want to support forward compatibility of OVF format, which is used for export/import of VMs/VM Templates. For example, I create a VM in a 3.1 system, export it to an export Domain. Should I be able to import this VM on a 3.0 system? Obviously, backwards compatibility (from older version to newer) is desired and is kept , but do we really need forward compatibility also? The reason I'm asking is some changes that need to be done in current OVF format to support new features. These new changes will be backwards-compatible with old OVF formats, but is it desirable for them to be forward compatible? Regards, Mike --=_bc9b6b95-2d7c-4155-b37b-029c2446b231 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >Hi, I wanted to know if we want to support forward compatibility of= OVF format, which is used for export/import of VMs/VM Templates. Fo= r example, I create a VM in a 3.1 system, export it to an export Domain= . Should I be able to import this VM on a 3.0 system? Obviously, = backwards compatibility (from older version to newer) is desired and is kep= t, but do we really need forward compatibility also? The reason I'm = asking is some changes that need to be done in current OVF format to suppor= t new features. These new changes will be backwards-compatible with old OVF= formats, but is it desirable for them to be forward compatible? <di= v>Regards, Mike </div= > </div></body></html> --=_bc9b6b95-2d7c-4155-b37b-029c2446b231--

2 2

[Engine-devel] ovirt.org unavailable
by Laszlo Hornyak 20 Mar '12

20 Mar '12

Hi, The ovirt.org site is inavailable for a few hours. Does the infrastructure team know about the problem? Thank you, Laszlo

2 2

[Engine-devel] Disk Permissions Feature
by Moti Asayag 19 Mar '12

19 Mar '12

Hi all, Disk Permissions feature description Wiki page: http://www.ovirt.org/wiki/Features/DiskPermissions Please share your comments. Thanks, Moti

6 14

[Engine-devel] Use java.util.Collection where possible?
by Yair Zaslavsky 18 Mar '12

18 Mar '12

Hi, I see that in some places in engine-core we use Java.Util.List, or even Java.Util.ArrayList as types of method arguments, while in the method code we do nothing besides iterating over the collection. I then found all kinds of usages like this: x.foo(new ArrayList<MyType>(myMap.values())); As you can see need to instantiate a new ArrayList in order to use the values of the map in method foo. Do you see any reason why not change the argument type (at method signature) to Collection in such places, where possible? Yair

4 5

[Engine-devel] ovirt-shell problem on F16 and nightly builds
by Gianluca Cecchi 18 Mar '12

18 Mar '12

Hello, sorry if this is a -devel mailing list. Let me know please if I have to send to another list. Would like to test ovirt-shell against an RH EV 3.0 installation. My system is based on F16 x86_64. Installed from nightly builds directory: Mar 16 11:02:30 Installed: python-lxml-2.3-1.fc16.x86_64 Mar 16 11:02:30 Installed: ovirt-engine-sdk-1.6.1-1.fc16.noarch Mar 16 11:02:30 Installed: pexpect-2.3-6.fc15.noarch Mar 16 11:02:30 Installed: python-ply-3.3-5.fc15.noarch Mar 16 11:02:30 Installed: ovirt-engine-cli-2.1.2-1.fc16.noarch But $ ovirt-shell --help Traceback (most recent call last): File "/usr/bin/ovirt-shell", line 9, in <module> load_entry_point('ovirt-shell==2.1.2-SNAPSHOT', 'console_scripts', 'ovirt-shell')() File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 337, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2279, in load_entry_point return ep.load() File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 1989, in load entry = __import__(self.module_name, globals(),globals(), ['__name__']) File "/usr/lib/python2.7/site-packages/ovirtcli/main.py", line 20, in <module> from ovirtcli.context import OvirtCliExecutionContext File "/usr/lib/python2.7/site-packages/ovirtcli/context.py", line 18, in <module> from cli.command import * File "/usr/lib/python2.7/site-packages/cli/command/__init__.py", line 2, in <module> from cli.command.command import Command File "/usr/lib/python2.7/site-packages/cli/command/command.py", line 21, in <module> from ovirtcli.utils.methodhelper import MethodHelper File "/usr/lib/python2.7/site-packages/ovirtcli/utils/methodhelper.py", line 20, in <module> from codegen.doc.documentation import Documentation ImportError: No module named codegen.doc.documentation Probably it is something stupid I miss? I installed them with sudo yum localinstall ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm and got: Loaded plugins: auto-update-debuginfo, downloadonly, langpacks, presto, refresh-packagekit Setting up Local Package Process Examining ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm: ovirt-engine-cli-2.1.2-1.fc16.noarch Marking ovirt-engine-cli-2.1.2-1.fc16.noarch.rpm to be installed Examining ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm: ovirt-engine-sdk-1.6.1-1.fc16.noarch Marking ovirt-engine-sdk-1.6.1-1.fc16.noarch.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package ovirt-engine-cli.noarch 0:2.1.2-1.fc16 will be installed --> Processing Dependency: pexpect for package: ovirt-engine-cli-2.1.2-1.fc16.noarch --> Processing Dependency: python-ply for package: ovirt-engine-cli-2.1.2-1.fc16.noarch ---> Package ovirt-engine-sdk.noarch 0:1.6.1-1.fc16 will be installed --> Processing Dependency: python-lxml for package: ovirt-engine-sdk-1.6.1-1.fc16.noarch --> Running transaction check ---> Package pexpect.noarch 0:2.3-6.fc15 will be installed ---> Package python-lxml.x86_64 0:2.3-1.fc16 will be installed ---> Package python-ply.noarch 0:3.3-5.fc15 will be installed --> Finished Dependency Resolution Dependencies Resolved possibly any dependency problem in rpm composition? Thanks in advance, Gianluca

4 5

[Engine-devel] [Jenkins] Auto Generated ovirt-engine rpms for fedora 16
by Eyal Edri 16 Mar '12

16 Mar '12

fyi, a new Jenkins job has been added to jenkins.ovirt.org. you can now d/l fresh ovirt-engine rpms after each commit. the rpms are created and latest are stored here: http://jenkins.ovirt.org/view/ovirt_engine/job/ovirt_engine_create_rpms/ the job will also notify the author in case his/her commit will break the rpm build. latest rpms for now: ovirt-engine-3.1.0_0001-1.8.fc16.src.rpm ovirt-engine-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-backend-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-config-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-dbscripts-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-debuginfo-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-genericapi-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-image-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-iso-uploader-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-jboss-deps-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-log-collector-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-notification-service-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-restapi-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-setup-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-tools-common-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-userportal-3.1.0_0001-1.8.fc16.x86_64.rpm ovirt-engine-webadmin-portal-3.1.0_0001-1.8.fc16.x86_64.rpm Enjoy, Eyal Edri oVirt Infra Team

5 8