July 2013 - Devel - oVirt List Archives

[Engine-devel] ovirt-engine-sdk-java 1.0.0.6-1 released
by Michael Pasternak 25 Dec '13

25 Dec '13

- added new collection ClusterGlusterVolumeGlusterBrickStatistics - added new properties to the GlusterBrick - to vm added cpu.mode - to host install action added "image" parameter - ignore case in factory method lookup More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 10

[Engine-devel] ovirt-sdk-python 3.3.0.1 released
by Michael Pasternak 25 Dec '13

25 Dec '13

- added new collection ClusterGlusterVolumeBrickStatistics - added NetUp 'cloned disk' importing capabilities - to ClusterGlusterVolumeBricks.list() added new argument "all_content" - to ClusterGlusterVolumeBricks.get() added new argument "all_content" - to host install method added new parameter "image" - to host add method added new parameter "display.address" - to vm add method added new parameter "vm.cpu.mode" - to vm add method added new overload for creating vm from snapshot - to cluster added tunnel_migration - to display added keyboard_layout - to display added smartcard_enabled - to DataCenter added Clusters sub-collection - to StorageDomain added Disks sub-collection - to Disks.list() added 'unregistered' argument - to Host added display.address - to Snapshot added commit/preview/undo actions - to vms.add() added overload for creating vm from snapshot - to hosts.add() added [@param host.display.address: string] - to vm.ticket() added [@param action.ticket.value: string] - return error if amount of fetched objects in X.get() is > 1 #890327 - session based authentication for /localhost is broken #916285 - explicitly ask for reply in xml - Add constructor parameter validate_cert_chain=True #915225 - defend against malformed server reply For more details see [1]. [1] http://wiki.ovirt.org/Python-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 5

[Engine-devel] ovirt-cli 3.3.0.1 released
by Michael Pasternak 14 Nov '13

14 Nov '13

- at vm.start() --vm-os-boot doesn't send the order of devices #921464 - rephrase status command help - add option to retrieve system summary #854369 - accept IP address as FQ argument rather than string #886067 - fix broken pipe - Bad error message when trying to create a new Role #908284 - add flag --dont-validate-cert-chain #915231 - collection-based-options could be passed in 2 ways #859684 - make NO_SUCH_ACTION error a bit more clear - ovirt-cli DistributionNotFound exception on f18 #881011 - ovirt-shell misleading help for command "connect" #907943 - show event -id accept strings instead of numeric values #886786 - Use vncviewer passwordFile instead of passwdInput More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 5

[Engine-devel] Proposal for new commit msg design for engine commits
by Eyal Edri 23 Aug '13

23 Aug '13

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] <core | restapi | tools | history | engine | userportal | webadmin>: thoughts? Eyal Edri.

12 29

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

20 Aug '13

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

2 3

[Engine-devel] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
by Alon Bar-Lev 06 Aug '13

06 Aug '13

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/

10 18

[Engine-devel] oVirt - Glance Integration Deep Dive Session
by Federico Simoncelli 05 Aug '13

05 Aug '13

------=_Part_7822902_1276514821.1375091061911 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The following is a new meeting request: Subject: oVirt - Glance Integration Deep Dive Session Organizer: "Federico Simoncelli" <fsimonce(a)redhat.com> Time: Tuesday, July 30, 2013, 3:00:00 PM - 4:00:00 PM GMT +01:00 Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna Invitees: users(a)ovirt.org; engine-devel(a)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.9E565882E4EA0288E3479F… Bridge: 8425973915# Phone numbers: http://www.ovirt.org/Intercall -- Federico ------=_Part_7822902_1276514821.1375091061911 Content-Type: text/calendar; charset=utf-8; method=REQUEST; name=meeting.ics Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:STANDARD DTSTART:16010101T030000 TZOFFSETTO:+0100 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETTO:+0200 TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:8ea8a413-e9de-46be-be2d-8f83ca22df3a SUMMARY:oVirt - Glance Integration Deep Dive Session ATTENDEE;CN=oVirt Users;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE :mailto:users@ovirt.org ATTENDEE;CN=engine-devel;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:engine-devel@ovirt.org ORGANIZER;CN=Federico Simoncelli:mailto:fsimonce@redhat.com DTSTART;TZID="Europe/Berlin":20130730T150000 DTEND;TZID="Europe/Berlin":20130730T160000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20130729T094421Z DTSTAMP:20130729T094421Z SEQUENCE:0 DESCRIPTION:The following is a new meeting request:\n\nSubject: oVirt - Glan ce Integration Deep Dive Session \nOrganizer: "Federico Simoncelli" <fsimonc e(a)redhat.com> \n\nTime: Tuesday\, July 30\, 2013\, 3:00:00 PM - 4:00:00 PM G MT +01:00 Amsterdam\, Berlin\, Bern\, Rome\, Stockholm\, Vienna\n \nInvitees : users(a)ovirt.org\; engine-devel(a)ovirt.org \n\n\n*~*~*~*~*~*~*~*~*~*\n\nHi e veryone\,\n on Tuesday at 3pm (CEST) I will be presenting the recent work do ne in\nintegrating OpenStack Glance into oVirt 3.3.\n\nThe presentation will include both a high level overview (usage in webadmin)\nand a deep dive abo ut the low level implementation details.\n\nWhen:\nTue 30 Jul 2013 15:00 - 1 6:00 (CEST)\n\nWhere:\nhttps://sas.elluminate.com/m.jnlp?sid=819&password=M. 9E565882E4EA0288E3479F3D2141BD\n\nBridge: 8425973915#\nPhone numbers: http:/ /www.ovirt.org/Intercall\n\n-- \nFederico\n BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR ------=_Part_7822902_1276514821.1375091061911--

3 3

[Engine-devel] [oVirt jenkins] Weekly report on open tasks for ovirt-engine
by Jenkins ci oVirt Server 01 Aug '13

01 Aug '13

------=_Part_40_614977538.1375311778010 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <b>Files scanned: '**/*.java, **/*.py'. </b><br> <b>Strings searched: FIXME | TODO | @deprecated </b> <br><br> Report: http://jenkins.ovirt.org/job/ovirt_engine_scan_open_tasks/10/tasksResult/? ------=_Part_40_614977538.1375311778010--

2 1

[Engine-devel] ovirt-engine-3.3 branch created
by Ofer Schreiber 31 Jul '13

31 Jul '13

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

1 0

[Engine-devel] [oVirt/RHEV 3.3 Localization Question #2] gluster hook stage "Pre" and "Post"
by Yuko Katabami 31 Jul '13

31 Jul '13

This is a multi-part message in MIME format. --------------020707080904020408090704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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(a)redhat.com Red Hat *Red Hat, Asia-Pacific Pty Ltd* Level 1, 193 North Quay Brisbane 4000 *Office:* +61 7 3514 8100 *Fax:* +61 7 3514 8199 *Website:* www.redhat.com <http://www.redhat.com> *Facebook:* Red Hat APAC <http://www.facebook.com/redhatapac> | Red Hat Japan <http://www.facebook.com/redhatjapan> | Red Hat Korea <http://www.facebook.com/redhatkorea> | JBoss APAC <http://www.facebook.com/JBossAPAC> *Twitter:* Red Hat APAC <http://www.twitter.com/red_hat_apac> | Red Hat ANZ <http://www.twitter.com/redhatanz> *LinkedIn:* Red Hat APAC <http://www.linkedin.com/groups?gid=3124596> | JBoss APAC <http://www.linkedin.com/groups?gid=4068303> --------------020707080904020408090704 Content-Type: multipart/related; boundary="------------070206040803090007060302" --------------070206040803090007060302 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"> Hello all,<br> <br> I am a Brisbane-based translator currently working on the oVirt/RHEV 3.3 localization project along with 5 other translators.<br> I was suggested to post my localization-related questions to this mailing list instead of rhev-devel.<br> <br> We often have difficulty in comprehending some strings or are unable to determine the usage of strings without knowing the context. <br> In order to translate software UI strings accurately, we need extra information from time to time.<br> It would be very much appreciated if any of you can help us by responding my email.<br> <br> My question this time is about the following strings:<br> File: LocalizedEnums<br> Resource Ids: "GlusterHookStage___PRE" and "GlusterHookStage___POST"<br> Strings: "Pre" and "Post"<br> 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.<br> <br> Thank you.<br> <br> Kind regards,<br> <br> Yuko<br> <br> <br> <div class="moz-signature">-- <br> <font color="#000000" face="arial, sans-serif" size="2"> Regards, <br> <br> Yuko Katabami (方波見裕子) <br> Technical Translator II <br> NAATI Accredited Professional Translator (English into Japanese) #28138 <br> RHCSA #111-119-244 <br> <b>Mobile:</b> +61 415 847 352 <br> <b>Email:</b> <a class="moz-txt-link-abbreviated" href="mailto:ykatabam@redhat.com">ykatabam(a)redhat.com</a> <br> <br> <a target="_blank"><img src="cid:part1.01040103.07010606@redhat.com" alt="Red Hat" height="42" border="0" width="128"></a> <br> <br> <b>Red Hat, Asia-Pacific Pty Ltd</b> <br> Level 1, 193 North Quay <br> Brisbane 4000 <br> <b>Office:</b> +61 7 3514 8100 <br> <b>Fax:</b> +61 7 3514 8199 <br> <b>Website:</b> <a href="http://www.redhat.com" target="_blank">www.redhat.com</a> <br> <br> <b>Facebook:</b> <a href="http://www.facebook.com/redhatapac" target="_blank">Red Hat APAC</a> | <a href="http://www.facebook.com/redhatjapan" target="_blank">Red Hat Japan</a> | <a href="http://www.facebook.com/redhatkorea" target="_blank">Red Hat Korea</a> | <a href="http://www.facebook.com/JBossAPAC" target="_blank">JBoss APAC</a> <br> <b>Twitter:</b> <a href="http://www.twitter.com/red_hat_apac" target="_blank">Red Hat APAC</a> | <a href="http://www.twitter.com/redhatanz" target="_blank">Red Hat ANZ</a> <br> <b>LinkedIn:</b> <a href="http://www.linkedin.com/groups?gid=3124596" target="_blank">Red Hat APAC</a> | <a href="http://www.linkedin.com/groups?gid=4068303" target="_blank">JBoss APAC</a> </font> </div> </body> </html> --------------070206040803090007060302 Content-Type: image/png; name="redhat-logo.png" Content-Transfer-Encoding: base64 Content-ID: <part1.01040103.07010606(a)redhat.com> Content-Disposition: inline; filename="redhat-logo.png" iVBORw0KGgoAAAANSUhEUgAAAIAAAAApCAYAAAD9LSHtAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAA6NpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tl dCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1l dGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUu MC1jMDYxIDY0LjE0MDk0OSwgMjAxMC8xMi8wNy0xMDo1NzowMSAgICAgICAgIj4gPHJkZjpS REYgeG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgt bnMjIj4gPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wTU09Imh0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iIHhtbG5zOnN0UmVmPSJodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvc1R5cGUvUmVzb3VyY2VSZWYjIiB4bWxuczp4bXA9Imh0dHA6Ly9u cy5hZG9iZS5jb20veGFwLzEuMC8iIHhtbG5zOmRjPSJodHRwOi8vcHVybC5vcmcvZGMvZWxl bWVudHMvMS4xLyIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpDMTM3NDQ3MkZCQzExMUUw OTQzNzk0QTNCNkFFNjg1RCIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpDMTM3NDQ3MUZC QzExMUUwOTQzNzk0QTNCNkFFNjg1RCIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBJbGx1c3Ry YXRvciBDUzMiPiA8eG1wTU06RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0idXVpZDpD QzZBQjQzODY4MDNERDExOENBRDk2OTlCQTZCNjM4OSIgc3RSZWY6ZG9jdW1lbnRJRD0idXVp ZDpDQjZBQjQzODY4MDNERDExOENBRDk2OTlCQTZCNjM4OSIvPiA8ZGM6dGl0bGU+IDxyZGY6 QWx0PiA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPnJlZGhhdF9jbXlrX2xvZ288L3Jk ZjpsaT4gPC9yZGY6QWx0PiA8L2RjOnRpdGxlPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6 UkRGPiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv93CnUAAA4OSURBVHja7FwL dBTVGf5ms49kySYkgSQkIZCkvKLyCCAIEQRFLdIiqPUN4qsitmhFQKgWKlpRQT1HsEINePBR hfr2+ECUtAoICCggGEKCEEkC5EFeu9nN7vS/s/+SyWR2s4mBgGf/cz4ye+femdn7f/d/3Vkk tE0MhPMJowgXEXoRkgidCDJBItgJxYQCwhbCRsL3BBdCcs5KLGEGYSuhgZUdLDyE3YQ5hITQ VJ5bEk54kFe03A4oJywgRIWm9uyX4YRdzZVo0EBSwffZ11fSfD6FPMKloSnuOJFaOC/M/RKC RT0kMtyM0amJSDYZ4ZJlFLvcOFJrR62rARFGI/pEWTHYYkKiLMFEIwpJ9+9X1GDnkRLWexMR ruFRwuMhdZxdBHiS/XVTX0BKX9o3HVdUS6RK73AXHdUpQYEMM7W5jMCOCBnbPA04aHeid4QF 1zUY8ZzswEd5h/VIIORFwr0hlZxZCfPT/hRhtl7wPy4jBTPtJtTTpypSpIPgIqVLyllJUa2b rEKCE4iwGLD6cDE2HS1D/+RY/NFhwnqzjPJah949hxISCR+F1NKxBLiPsMjfgBtTuiLFKWGX TUZvpwERpPRwholQr1zUS4gCCh37xNpwd3wchpHFsJFLkOMikFta7u/yQ9gqbQyppmNcwEjC hqY+v1GMYQa83bsXdhg9WLD7IKZk9kQ8tZW4Pagh9LUYMbHaADMp2kO2QJDDopBCWArvzTwG YKqjAj8cPe7PFQi5mvBeSD1n1gJYCW8RuvvjSjqt5NskK+JIk9tNEjYUknk/Vo4Kj4yqBjec hjAMMxgR4ZGUyE4UCoSLaOArCHXHyAaUdzZhy7HKQAQQ7uB1Ql1IRWeOADMJUwMZi4GJcbhG NiO6QUJWdARORFsxJzkB96MTbjFaMV4mJ+CmGMC/YhViJJDV+KTejjpnQ6CCk5DPz8E5FYmP qIpWn0sEiCesaizMeEO6xmMv0mKjcLXHhJOk4FiXhIlEhuR6KNmAk/4Vpl5u4YZuMTtuA76L MiG/vDqQFcgkrCVUnGME6AxvpfR6tqYi4Ck9Wx/WyH9vJiT7FJ4SG40R8Z3Rx2xEJBFBdDrs cSMnvwiv9UrFzdVhICOAWor23S2qXF9GUGr4SeCxMYQ7CfPOMQIIIxdJGMboy2TwfSdBkMKz iQASE0A5HJmWhEWmSKQ6yI9z5GYiRa+PNqHa4cKjuw/gm949MMliwQU1EmJlr6UQxtyO4Ahh p+tlUQbR2WpBZV19ICtwHWckv5ZYIIvwCQfbW8+GBxLaG8RQFHFnVCS6U5pXTkSuFJDFXyDN 7kFql2hlyEd5R3Dn7jzcai/DgxYHVtoa8LXNAzvRqbNkUOoBgUSQJc4FdLVFonHzUHfMb3iy fi0i86LrdIbuJyzQGkLXQBZgVKPDl5SlJktNF6Wo9CXTil3YLV7ZwfnpxEmlb15JGaEc77Pl S+sai98nxGBajdewePysbHH2CCWa1nojVp/fGwcMHnxaWYvth0u8T0H3l+VTY8cQ1v/Kgm/5 DN3ncnY/DwayAMPUDWur6xQnFqZZkTXUOpxitpy4eEzN7IH46E68an07veTYjlfg+T0F2ESh ZKQkBfQ7XxrcuCrGhotrDJhWZcQqQxTm989QSs1y0+m5sB0mQqS4afC/+yjOpxJ68mqRgryu qJekEHqw32+LhPO9U/k4GKstKqbpHLcZgyCbJ9DF0tV9NxYUYYnVhWiaA2MzEsjoQi77r3UW vJqYhAcuSMOg7olKgUidNXxWX6/sB/oTcZ1xDQbcUG1QXE0FQbwlckdVGOb166ntnt6KyRV7 CdsI3xAe4Lbp8L6HUKBq80kGvHsQewg/Eg7wX2FxrmghQP07vLukeYy9hGeYQA1BBIpC/kbI JxwShpWP/+JHqV24/w8cRO4XhpQ/36jp+yq8L99M57RUFPe28/Nuhup9DGNj9N9IghV7C+DM TMNDdSalvGtXWSyR7gkk1EuYUW/C1LAo7O1rw9eSG7tr61F4sgYbj5RgfUYqLqmWUKtj7QSt kh3eCmFjeigTESRcU2XAe0Sqbxt3DsWE2hTetCyCPUP4+HtW+FLNilVXG1dxVK5V7qUMsRn2 lOa8WO0fEC7QtKeyqf1tECtZBFMb+Xn/QdjJtY874N197U+4TTPmeq7VLCPkEo6z9ZnJRTNh 3V7ivpsIBwmjOcXfwHUJk6JCwKHWRTl/6WbGYUx6MuaarcggZVX5ifANyj4AlJKvIMYJolSx xVsniHXCbxzgN4mmIPJ+k10JNHmhCOMwgLAviOGP8MoEr+TOaPr20WLCXHjfcfiCEMHt27gK Km54Lbyvuan96HqVq8hVkQw8sYJsZn5Os+aZ3lKlgWP4vj/xiryJFaKWhfBuj4sMaJ2qPZLr Nid1vve7HMuJV/PKNPMxn4lywp8L8Gulviz4GdNKS/CKza1QJ0onwvcoW8GyYsbFS4CUECCz VkJcG5Qvri1SxGK7s61xknqbsQ8rP4/N6q1cWBLyuEr5Yvcxm833Up5IdQVSHUBN1yhfuJrB PP5CdhulQQR/NVx1der0WcKr+/ZmnlNf+eDnFot4hG4JN0BMY2jJVR2tqMJju/NxU20pPjQ6 leAuCvqpnkep+3u3iNtSIIqia28nQ7azqLitBNA+1H5W6LPsF78lXEwYqyLMHI0iGjRuYwSv ICFTVO1VbKYPqNo2sklu6flyCLV++lTxdbKCCPB8soeLrP3aUgiq03cBjaQddXE2si+5DG99 9jHWFhXgptgYjCL/Hk00qOMS8C8VUXGsCJPxAhFObpqHikpRZRsvu1RnRY5WHRezP75ItRic 7Dpc7DNt7Ks9mgn+mAmmlS/4eTsHeK69LTy38N+/42cr85N99OIgNpH1Fwb/73cEJMDPzQNB VVTVowfeeP0NJKWk4JH5czF6zFj8efMm9I2LxlWJXTDOHYY0B1kEyVvhc6F1pl/EDp0IB8Jl LHBUY0fz18aOo20bK+IiO3Ta1UoUqeHXQVwrjoloUrV966evK0DaJem4Kj2pZmVqLXQSW6zr mRzCiqj3StxtIUBBoFzbaDQiIsIb1IZbLHjh2SW4d8YMJCalYMkHH+Jf4WEYmtIN2VYLhjgl pDi8LkJxCZL37SC3qt4nvpWJTL14RVQUmA5RwPi+qQHvFB1HSaXu5lBBkBmAXsFRz8ya23At u0b5CGDC2+Kq9M5rJ0JkJf9hcjxB+JQtWBUTtLQVLqMJAUQgc0OzWTKb4XQ6kX/wIOY9/DBe XLFSaR86bDg2bd4Mk8mMh2fPxpNPP43P848oUVNMpwhlx7CnNRxpZiOSKWiMoa8RTuvBSiwQ pWKKD2lJe1DocWM/BXt7jlagrNqOxheFm8kvqZnrxTj1qmORT/+JeSkFuMb/ONhTS7czWDlM 4gB2F6eZ9vasLGZZwsPdVqtVjo6Ols/L7CfPuOceeduWb+TVL+fIUVFRimZWrVwp68mcWbNk rh5rXgH3QrTTDMpG7iOd6mMI9Lq4GuNa8V1mq8YJX56p02e+qs8JntxgpAevet9Yf64ji02x r9+bqnNjue2SFu41n4nqq+HP5HFD/PSPZYs3Tyctrg+4F7Ds+ed39h84YKfZZB4cabMhPSMD 4RHeDGnIsAtRXV2F+2fNwrS77kJMbCwmTp7c5ALCAmRnZyMnJwclx0oR2SkSyUlJGDRoIOrs DuTm5mLAgAHontoDX36xATZbJBK6xmPxkiXBTHp+kD66NSKM1WO84uPYnN4WxDhf7j5KlR3c zhG9Wh5qObtqtfTiVX/Iz/kEtmLa2MPN7f5dg9h0ITwgB5BtW7bIr69ZIxcfPSq3h9w3fXqw vyB6opUTFYwFAPtS9X1yuZzan+sHw7lusKJpqVwp3KjHOTjFFGZ5MmcG2u/w73awAIt5nL80 bzmfn6tpv4Pb+7ZEgHhCkdxOcqiwUP7808+U4x/37ZP3/bC3yfmLR44MRvllHKWL6tkfdIKw X0KAJK7eae/ZwOPUbddpxr7ZwnOXsqXwfX63HQiQzeNe0fQTcyJ+v3GM3dMzmvNDedx8Tbuw CpMIV/lMlbjAc+1lr15esQLjrrwCg7MGYfI1k/Hdzp2NERgFlpWVQaX1/+TNjgmEiVxrDyao DSbSPsqxxWto+mvlMB2iaf2nMPur/VxXkPYW3is4Vd9qYxagruB9xSXuKVzizuES8xG2Spdz yqt9oddX4l7E+wHvsrUQtYPxhCsl1b67qHP/VyfabbWcrKjA3r17sHz5cmSkZ2DhosafGZAr wc1TvAU1CjwxsH9/9OndW4kbjCYjTp6swv4f9x8sKCwclncgv4yebxwXYz5Ayz8tH8JFHRf7 v3Vo+Z1CYSUuYzMZzRaghPcetnKlTy+/HsFmP4nP72BzX8yB4EhefcJvf8hjknkT6h0mIQIE kkIPazQ1gzFMgniOCTYwiat4oUB1L7Ve72brY+B9jWXstlw+F+DDSIJDPk0iYojMfv1OZQMi FtCTn4uKJr69bh2yBg5ESE6zaAggcN/pIsCE8eMVxQ8dMlh+ZvFif0HlAt+zXDtpUkhBHUAA gafaW/kvLV+mKH/ihAmyy+Xy1+1F9XOECNBxBBB4sr2Uv23rVjmpWzf5srFj5Mrycn/dlmuf IUSAjiWAwIz2iAm+ys2V31671t/KdxPm690/RICOJ4DAcMKu0xQW5BEu9XfvEAFOvwRTstzC lbFZnB61h4jUbAGnbRtCaji7CQDORUXx/jx4//+AbWj93rPIifdwuVKUNBdy/hqSDpTW7h+X cxFBvErd0v8TWMdl0YMI/T+BZ638X4ABALiJt5GyzHDtAAAAAElFTkSuQmCC --------------070206040803090007060302-- --------------020707080904020408090704--

2 2

Re: [Engine-devel] [Engine-patches] Change in ovirt-host-deploy[master]: packaging: Fixed building RPMs on non-x86_64 architectures
by Leonardo Bianconi 31 Jul '13

31 Jul '13

Ok, no problem. Thanks >-----Original Message----- >From: Itamar Heim [mailto:iheim@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@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@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(a)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 <vitor.lima(a)eldorado.org.br> >>>>>>> --- >>>>>>> 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 >>

1 0

[Engine-devel] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
by Moran Goldboim 30 Jul '13

30 Jul '13

This is a multi-part message in MIME format. --------------080603010209010007090703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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* <https://bugzilla.redhat.com/show_bug.cgi?id=918494> -Tracker: oVirt 3.3 release --------------080603010209010007090703 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"> We would like to go a head on oVirt 3.3 release process and issue an RC <br> <br> for tomorrow meeting:<br> <br> Maintainers/ Package owners <br> ==================<br> -branch your git repo (master) with 3.3 branch (making master ready for 3.4)<br> -for tomorrow meeting, overview [1]<span id="summary_alias_container"><span id="short_desc_nonedit_display">, see if you have any changes to it<br> -if you don't have any blockers under your component, please branch 3.3 with RC1 branch<br> <br>     |    <br>     -master<br>     |    <br>     -engine_3.3<br>         |<br>         -RC1<br>     |<br>     -engine_3.2<br>     ...<br>    <br> Users<br> ====<br> 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].<br> <br> Suggested Schedule<br> ============<br> Wed Jul 31st - review of blockers for the version and component readiness<br> Mon Aug 5th - RC1 release<br> Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued)<br> </span></span><span id="summary_alias_container"><span id="short_desc_nonedit_display"><span id="summary_alias_container"><span id="short_desc_nonedit_display"><br> Thanks.</span></span> <br> <br> [1]</span></span><a href="https://bugzilla.redhat.com/show_bug.cgi?id=918494"><b>Bug 918494</b></a> -<span id="summary_alias_container"> <span id="short_desc_nonedit_display">Tracker: oVirt 3.3 release<br> <br> <br> </span></span> </body> </html> --------------080603010209010007090703--

4 5

[Engine-devel] Question about the attribute lunType (LUNs)
by Gustavo Frederico Temple Pedrosa 30 Jul '13

30 Jul '13

--_000_EF26FC1776F7FF46BFC072393EFD13A29A07E9SERV070corpeldora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello everyone, The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires the imp= lementation of methods that evaluate if a Disk is a iSCSI LUN or not, in or= der 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 obje= ct, the attribute lunType has the value "UNKNOWN", even if I've setted it w= ith another value. In the class LunDAODbFacadeImpl there is not a call to t= he "entity.setLunType" method. Does anyone know how to retrieve the attribute lunType? Is the "UNKNOW" val= ue a bug? Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa --_000_EF26FC1776F7FF46BFC072393EFD13A29A07E9SERV070corpeldora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"PT-BR" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"color:black;mso-fareas= t-language:ZH-CN">Hello everyone,<br> <br> The QEMU/KVM on IBM POWER does not support iSCSI yet. This requires the imp= lementation of methods that evaluate if a Disk is a iSCSI LUN or not, in or= der to avoid its use in this specific architecture.<br> 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 obje= ct, the attribute lunType has the value "UNKNOWN", even if I've s= etted it with another value. In the class LunDAODbFacadeImpl there is not a call to the "entity.setLunType&quot= ; method.<br> <br> Does anyone know how to retrieve the attribute lunType? Is the "UNKNOW= " value a bug?<br> <br> </span><span style=3D"color:black;mso-fareast-language:ZH-CN">Thanks,</span= ><span style=3D"mso-fareast-language:ZH-CN"><o:p></o:p></span></p> <p class=3D"MsoNormal">Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa<o:p>= </o:p></p> </div> </body> </html> --_000_EF26FC1776F7FF46BFC072393EFD13A29A07E9SERV070corpeldora_--

3 5

[Engine-devel] VNIC profiles & Device Custom Properties
by Amihay Winter 29 Jul '13

29 Jul '13

------=_Part_11407198_1454246753.1374581565910 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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" <lpeer(a)redhat.com> > To: "Moti Asayag" <masayag(a)redhat.com> > Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri Masad" > <omasad(a)redhat.com>, "Mike Kolesnik" <mkolesni(a)redhat.com>, "Oved Ourfalli" > <oourfali(a)redhat.com> > 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" <lpeer(a)redhat.com> > >> To: "Moti Asayag" <masayag(a)redhat.com> > >> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri Masad" > >> <omasad(a)redhat.com>, "Mike Kolesnik" <mkolesni(a)redhat.com>, > >> "Oved Ourfalli" <oourfali(a)redhat.com> > >> 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" <lpeer(a)redhat.com> > >>>> To: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri Masad" > >>>> <omasad(a)redhat.com> > >>>> Cc: "Mike Kolesnik" <mkolesni(a)redhat.com>, "Moti Asayag" > >>>> <masayag(a)redhat.com>, "Oved Ourfalli" <oourfali(a)redhat.com> > >>>> 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 > >>>> > >>>> > >> > >> ------=_Part_11407198_1454246753.1374581565910 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: times new roman, new york, times, se= rif; font-size: 12pt; color: #000000"><div><br></div><div>Hi all,<br></div>= <div><br></div><div>I'm building a TCMS plan for the <span dir=3D"auto">Dev= ice Custom Properties feature and I came across some questions.</span><br><= /div><div>I'm sorry that I'm a little late with my thoughts but I hope you'= ll still hear them out.<br></div><div>Also, I know It's a little long but p= lease bear with me :)<br></div><div><div><br></div><div>I want to talk abou= t two things:<br></div><div>1. Sending an updateDevice verb whenever clicki= ng on "Edit" and than "OK".<br></div><div>2. Setting Port Mirroring at the = configuring of a nic and not at the profile.<br></div><div><br></div><div>1= .According to the Vnic_Profiles's wiki (in the Editing a profile section) i= t says:</div><div>      "The changes will seep down to = all VNICs using the profile.</div><div>      &nbsp= ; In case VNIC using the edited profile are connected to running VMs, = the change will apply only on the VM next run."<br></div><div>  &= nbsp; I'll describe a Scenario:</div><div>     &nb= sp; Creating profile A with property speed =3D 500 <br></div><div> &nb= sp;     Setting vnic2 on vm to have profile A (using Ho= tplugnic)</div><div>       Changing (in the profil= e) speed =3D 700</div><div>    According to the Vnic_Profile= s's wiki, only when I restart my vm I'll get my setting right.</div><div>&n= bsp;   In my opinion, If we could enable the update of those sett= ing LIVE we will give the clients a better solution in the Vnic Profiles.<b= r></div><div>    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 m= aybe stopping others' work.<br></div><div>    I think that r= estarting 1000 vms because I want to set a property is not something that a= n admin would want to do.<br></div><div>     &nbsp= ;  </div><div>    One way to implement it is to se= nd a verb "updateDevice" each time we open the the "Edit" window and clicki= ng "OK"</div><div>    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 ver= b, otherwise, he would have pressed on "Edit" & "Cancel".</div><div><br= ></div><div>    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.</div><div><br></div><d= iv>2. I'll start with saying that in my opinion, the Vnic Profile feature w= as created to give the client a *more dynamic network environment* and I su= pport.</div><div>    But, I think that the statical var= iables like MAC, Un/Pluged and Port Mirroring which always exist should be = at the nic and not in the profile.</div><div>    In my opini= on, Profile's properties may have: max_mtu, min_mtu, mtu, speed, id, vlan..= . Identifiers for the network.</div><div>    Maybe I'm missi= ng something but it seems natural to me that the port mirroring will be at = nic and not at the profile.</div><div><br></div><div><br></div><div><span i= d=3D"result_box" class=3D"short_text" lang=3D"en"><span class=3D"hps alt-ed= ited">I'll really appreciate comments.</span></span></div><div><span id=3D"= result_box" class=3D"short_text" lang=3D"en"><span class=3D"hps alt-edited"= >Thank you for your time.</span></span></div><div>Amihay Winter<br> &n= bsp;           &nbsp= ; </div><br></div><hr id=3D"zwchr"><blockquote style=3D"border-left:2p= x solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:nor= mal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans= -serif;font-size:12pt;">----- Forwarded Message -----<br>From: "Livnat Peer= " <lpeer(a)redhat.com><br>To: "Moti Asayag" <masayag(a)redhat.com><= br>Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri Masad" <omas= ad(a)redhat.com>, "Mike Kolesnik" <mkolesni(a)redhat.com>, "Oved Ourfa= lli" <oourfali(a)redhat.com><br>Sent: Monday, July 8, 2013 10:11:15 AM<= br>Subject: Re: VNIC profiles<br><div><br></div>On 07/08/2013 12:36 AM, Mot= i Asayag wrote:<br>> I've updated the wiki accordingly and added few com= ments inline.<br>> <br>> ----- Original Message -----<br>>> Fro= m: "Livnat Peer" <lpeer(a)redhat.com><br>>> To: "Moti Asayag" &lt= ;masayag(a)redhat.com><br>>> Cc: "engine-devel" <engine-devel@ovi= rt.org>, "Ofri Masad" <omasad(a)redhat.com>, "Mike Kolesnik" <mko= lesni(a)redhat.com>,<br>>> "Oved Ourfalli" <oourfali(a)redhat.com&g= t;<br>>> Sent: Sunday, July 7, 2013 2:59:34 PM<br>>> Subject: R= e: VNIC profiles<br>>><br>>> On 07/07/2013 01:59 PM, Moti Asaya= g wrote:<br>>>> Hi,<br>>>><br>>>> I've updated t= he wiki with the feedbacks from this thread, added a backend<br>>>&gt= ; section naming the affected commands and also add added few questions of<= br>>>> my own embedded in the pastedtext below.<br>>>><br= >>><br>>> Hi Moti,<br>>> A good and comprehensive descrip= tion of the feature behavior.<br>>> See my comments bellow -<br>>&= gt;<br>>>> In addition, another question here:<br>>>><br>= >>> The units within the UI mockups are Mb and Mbps. The libvirt A= PIs expects<br>>>> the units to be in kb and kbps. Which component= is responsible to convert<br>>>> them to the expect units ? engin= e or VDSM ?<br>>><br>>> Giuseppe mentioned that in a previous t= hread on this subject.<br>>> Ofri and Giuseppe agreed that the transl= ation would be done on the<br>>> engine level.<br>>><br>>&gt= ;<br>>>><br>>>> Copied text from the wiki:<br>>>&gt= ;<br>>>> Adding a Profile<br>>>><br>>>> The netw= ork administrator could create several VNIC Profiles for each<br>>>&g= t; network. He could then grant a users with the permission to use (consume= )<br>>>> each profile. The user will only be able to use profiles = which he was<br>>>> granted access to.<br>>>><br>>>= >     For example: the network admin will create two VNIC prof= iles for<br>>>>     network "blue":<br>>>><br>&= gt;>>         Profile "Gold" - with better QoS an= d with port mirroring<br>>>>         Profile "= Silver" with lower QoS and without port mirroring.<br>>>><br>>&= gt;<br>>> I would use other names for the profiles to avoid confusion= .<br>>> Gold and Silver are likely to be QoS object names,  a mo= re typical name<br>>> for a network profile is - teachers-blue and st= udents-blue<br>>><br>>> The different profiles can have differe= nt QoS (teachers-blue would get<br>>> Gold QoS while Students-blue wi= ll have Silver).<br>>><br>>><br>>>>     He w= ill then define the user-group "students" as user of profile<br>>>&gt= ;     "Silver" and user-group "teachers" as user of profile "Gold= ". In this<br>>>>     case the teachers will enjoy bette= r quality of service then the<br>>>>     students. When = a teacher will add/edit a virtual NIC he could select<br>>>> &nbsp= ;   profile "Gold" for that NIC - the VNIC will be connected to networ= k<br>>>>     "blue" with high QoS and with port mirrorin= g.<br>>>><br>>>> Question: In the same matter we allowed = via the UI to grant 'NetworkUser'<br>>>> to 'everyone' user, would= n't it ease the use of Profiles if we support it<br>>>> in this co= ntext as well?<br>>><br>>> The ease of use could be that when c= reating a network we'll display in<br>>> the UI all VNIC-QoS-objects = and the users could tick next to the QoS<br>>> they are interested in= , for each QoS that was chosen a profile would be<br>>> created.<br>&= gt;><br>>> I would enhance that with youe suggestion above and dis= play next to the<br>>> QoS that was checked the option to mark 'Allow= All users' like we have<br>>> today for making a network public, thi= s option would give permission to<br>>> everyone on that profile.<br>= >><br>>><br>>>><br>>>> Editing a Profile<br>&= gt;>><br>>>>     A user should be able to edit the= profile properties (including profile<br>>>>     name) = while VMs are attached and are using this Profile (reference<br>>>&gt= ;     should be done by id).<br>>>>     Changi= ng the network of a vNic profile will be allowed only if no VMs<br>>>= >     are using the profile.<br>>><br>>> It would = be better if we can limit this to no running VM is using the<br>>> pr= ofile (or more simple to implement if all VMs that are using this<br>>&g= t; profile are in status down).<br>> <br>> Allowing to delete a vnic = profile when used by vms is asymmetric to the network removal<br>> when = it is used by vms or templates. Today the update network operation is block= ed for that.<br>> In addition, with the suggest simplification to remove= a profile when no running vms, the user<br>> will have to find for hims= elf if the profile is being used prior to its removal since the <br>> op= eration will not be blocked.<br>> <br>> If we allow to delete a vnic = profile, when a vm is using it (regardless the VM status) <br>> we'll ha= ve to update the VM entity as well in that operation: since we do not suppo= rt a<br>> network with 'none' profile, we'll have to delete the network = as well.<br>> <br>> If we'll remove a vnic profile in 3.1 cluster, us= ed by vms in status down, we'd find a case <br>> in which a VM is attach= ed to a 'none' network. This is unsupported in 3.1 cluster. We can block<br= >> such operation, but this is another motivation why we'd better not to= allow removing a used profile.<br>> <br><div><br></div>The context abov= e is about editing not deleting :)<br>I agree with what you wrote if the co= ntext was remove.<br><div><br></div>>><br>>>>     =     Since we have no way to distinguish between running and curre= nt<br>>>>         configurations, the expected= behavior of such a change is<br>>>>         u= npredictable and less intuitive to the user (especially since<br>>>&g= t;         dynamic wiring is supported).<br>>>&gt= ;     The changes will seep down to all VNICs using the profile.<= br>>>>         In case VNIC using the edited p= rofile are connected to running VMs,<br>>>>       &= nbsp; the change will apply only on the VM next run.<br>>>><br>&gt= ;>> Question: What about Hibernate/Suspend VM ? will the resume VM ac= tion uses<br>>>> the original configuration for the vnics when the= VM was started ?<br>>><br>>> Currently profile includes: netwo= rk, port-mirroring, custom property, QoS<br>>><br>>> Changing a= ny of the above (except for network) requires a VM reboot, so<br>>> I= think that we can start with the following statement - the profile<br>>= > change would only apply after next VM reboot.<br>>><br>>> = There are 2 problems with the above:<br>>> - Today we support network= wiring, with VNIC profiles we are asking the<br>>> users to create a= new profile and attach the VMs to the new profile, I<br>>> can see t= he RFE coming - we can report that ourselves ;)<br>>><br>>> - W= e don't reflect with which configuration the VM is running, e.g we<br>>&= gt; edited the profile QoS but I'm not sure with which QoS the VM is<br>&gt= ;> currently running. (The RFE for differentiating between current<br>&g= t;> configuration and running configuration was already asked for by<br>= >> numerous users)<br>>><br>>> The above is a general iss= ue that we need to solve and I would not limit<br>>> editing VNIC pro= files because of it.<br>>> We can mitigate this specifically for QoS = like described bellow.<br>>><br>>><br>>><br>>>> = Deleting a Profile<br>>>><br>>>> VNIC Profiles could not = be deleted from the engine as long as one or more<br>>>> VM/Templa= tes are using those profiles.<br>>><br>>>> Reporting vNic ac= tual configuration<br>>>><br>>>>     The engine= will retrieve the actual configuration of the profile<br>>>> &nbs= p;   properties on the VNIC from VDSM (using the network statistics<br= >>>>     mechanism) and the networked administrator will= be presented with the<br>>>>     state of each VNIC (sy= nched/unsynched).<br>>>><br>>><br>>> Will the admin be= able to see the actual values? I think the synced<br>>> property is = not enough (I'm not sure how interesting this property is to<br>>> st= art with).<br>> <br>> We can extend the VmGuestAgentInterface to cont= ain the actual value, so they<br>> will be presented for each vnic in th= e 'guest data' sub-tab.<br>> <br><div><br></div>AFAIU this info does not= come from the guest it is info we retrieve from<br>libvirt.<br>The VmGuest= AgentInterface should be used only for information reported<br>by the guest= , information whose credibility can be questioned.<br><div><br></div><br>&g= t;><br>>>> Editing a VNIC / Changing a VNIC profile<br>>>= ><br>>>>     Changing the profile a VM is using while= the VM is running should<br>>>>     behave like dynamic= wiring (changing the VM network while it is<br>>>>     = running).<br>>>>     Hot-plug of a vnic will will use wi= ll use the updated profile connected<br>>>>     to the V= NIC.<br>>>><br>>><br>>> Not sure I fully understand th= e sentence above.<br>>> Hot plug will be fully supported, you can cho= ose any profile (you have<br>>> permissions on) while plugging a new = device.<br>>><br>> <br>> That was the intention. seems like an = edgy hand syndrome :)<br>> Changed to:<br>>  * Hot plug will be = fully supported: the user can choose any permitted profile while plugging a= new device or when activating an existing one.<br>> <br>>>> Ad= ding a Network<br>>>><br>>>>     When adding a = network, a user can provide an option to create a vNic<br>>>> &nbs= p;   Profile for it.<br>>>><br>>>> Question: Is it s= default profile ? what are its properties ?<br>>>> Question: What= about 'Public Use' option ? Are they still relevant in the<br>>>>= context of adding new networks or we should eliminate them and move it<br>= >>> only to 'Add vNic Profile' dialog?<br>>>><br>>>= <br>>> see previous comments<br>>> In addition when creating a = profile we should have 'Allow all' for<br>>> implicitly creating perm= issions, like we have today for network.<br>>><br>>>> Updati= ng a Network<br>>>><br>>>> When a network role is modifie= d to be a 'non-VM network', all vNic profiles<br>>>> associated wi= th it should be deleted.<br>>><br>>> And permissions associated= with these profiles<br>>><br>>>> Removing a Network<br>>= >><br>>>>     Should remove all profiles on that n= etwork<br>>>><br>>><br>>> And associated permissions<b= r>>><br>>>> Adding an Empty Data-Center<br>>>><br>&= gt;>>     Currently, When creating a new Data-Center, the m= anagement network is<br>>>>     automatically created.<b= r>>>>     From 3.3, a default vNic profile will be creat= ed for the management<br>>>>     network.<br>>>&gt= ;<br>>>> VM snapshot/import/export<br>>>><br>>>>=     We should handle VMs that are pointing to a network directly= for<br>>>>     backward compatibility.<br>>>> =     We need to select first profile that is on that network that = the user<br>>>>     has permissions on.<br>>>><= br>>>> Question: Do we wish to support it export from 3.3 and impo= rt to 3.2 or<br>>>> below?<br>>><br>>> That means that= when you write a VM in the OVF you need to write network<br>>> in ad= dition to profile.<br>>><br>> <br>> The network name is already= there, so when importing a vnic from 3.3 to an earlier version<br>> the= profile name will be ignored.<br>> <br>>><br>>>> Questio= n: A user can import/export a VM/Template even if he doesn't have<br>>&g= t;> permissions on the networks. Is the next flow valid ?<br>>>&gt= ;<br>>>>     The profile name should be saved in the OVF= (in addition to the network<br>>>>     name which is sa= ved today).<br>>>>     During import, if both (network n= ame, profile name) exist on the target<br>>>>     DC, th= e vnic will get the profile id.<br>>>>     If the networ= k exists in the Data-Center, but has no profile as<br>>>>   &= nbsp; specified in the OVF, the user will be notified (event log) and the<b= r>>>>     VNIC will be connected to a default minimal pr= ofile defined in the<br>>>>     system, regardless the p= ermissions the user has on the network.<br>>>><br>>><br>>= > What is a 'default minimal profile' ? I would rather have a VNIC with = no<br>>> profile associated with it.<br>> <br>> The 'default mi= nimal profile' refers to a vnic profile with the lower average bandwidth.<b= r>> <br>> With the approach you've suggested, any imported VM/Templat= e from an earlier to 3.3 version <br>> will require a manual interventio= n in order to configure a network to the VM.<br><div><br></div>I should hav= e elaborated some more -<br><div><br></div>If a VM has a profile then we sh= ould look up this specific profile, if<br>such a profile does not exists th= en import the VM with profile none like<br>we do today for VM's with refere= nce to a network that does not exist on<br>the setup.<br><div><br></div>If = a VM does not have a profile (3.2 and lower versions) we should look<br>int= o the network name, if this network exist and we have a profile with<br>per= missions to the user then use this profile (if there is more than one<br>ch= oose one randomly).<br><div><br></div><br>> And for 3.1 we'll have to dr= op such vnics since network 'none' isn't supported.<br>> <br>>><br= >>>> If failed to find any matching vNic profile, the vnic's profi= le will be set<br>>>> with 'none'.<br>>>><br>>>>=     When a Template is created from a VM the VNIC Profile will b= e kept<br>>>>     along with the VNIC. When a VM is crea= ted from template the VNIC<br>>>>     Profiles will be t= aken from the template's VNICs.<br>>>><br>>>> ----- Origi= nal Message -----<br>>>>> From: "Livnat Peer" <lpeer(a)redhat.= com><br>>>>> To: "engine-devel" <engine-devel(a)ovirt.org&g= t;, "Ofri Masad"<br>>>>> <omasad(a)redhat.com><br>>>&= gt;> Cc: "Mike Kolesnik" <mkolesni(a)redhat.com>, "Moti Asayag"<br>&= gt;>>> <masayag(a)redhat.com>, "Oved Ourfalli" <oourfali@re= dhat.com><br>>>>> Sent: Sunday, June 30, 2013 3:59:37 PM<br>= >>>> Subject: VNIC profiles<br>>>>><br>>>>= > Hi,<br>>>>><br>>>>> We are working on adding V= NIC profiles as part of the work to add VNIC<br>>>>> QoS.<br>&g= t;>>><br>>>>> http://www.ovirt.org/Features/Network_Qo= S#VNIC_Profiles<br>>>>><br>>>>> We need to define s= ome of the system behavior followed by this change,<br>>>>> her= e is my take -<br>>>>><br>>>>> Editing a profile -<= br>>>>> --------------------<br>>>>> A user should = be able to edit the profile properties (including profile<br>>>>&g= t; name) while VMs are attached and are using this Profile (reference<br>&g= t;>>> should be done by id).<br>>>>><br>>>>&g= t; Changing the network though is a bit more tricky as long as we don't<br>= >>>> have a way to distinguish between running and current conf= igurations I<br>>>>> think it could be very confusing to the us= er. Especially since we<br>>>>> support dynamic wiring so the b= ehavior IMO is unpredictable.<br>>>>> I think it should be bloc= ked at this point.<br>>>>><br>>>>><br>>>>&= gt; Edit a VNIC / change a VNIC profile -<br>>>>> -------------= -----------------------<br>>>>> Changing the profile a VM is us= ing while the VM is running should behave<br>>>>> like dynamic = wiring (changing the VM network while it is running).<br>>>>><b= r>>>>><br>>>>> Remove a Profile -<br>>>>&g= t; -------------------<br>>>>> Is only valid if all VMs that ar= e using this profile are in status down.<br>>>>> It should upda= te all VMs to point to no profile which should behave like<br>>>>&= gt; none network today.<br>>>>><br>>>>> I see no re= ason to support a profile on a none network at this point.<br>>>>&= gt;<br>>>>> The above is also relevant for upgrade flow (upgrad= ing none network to<br>>>>> point to no profile)<br>>>&gt= ;><br>>>>><br>>>>> Removing a Network -<br>>&= gt;>> ----------------------<br>>>>> should remove all pr= ofiles on that network<br>>>>><br>>>>><br>>>&= gt;> VM snapshot/import/export -<br>>>>> -------------------= -------<br>>>>> We should handle VMs that are pointing to a net= work directly for b/w<br>>>>> compatibility.<br>>>>&gt= ; we need to select first profile that is on that network that the user<br>= >>>> has permissions on.<br>>>>><br>>>>&gt= ;<br>>>>> I assume there are more, comments are welcome<br>>= >>><br>>>>> Thanks, Livnat<br>>>>><br>>= >>><br>>><br>>><br><div><br></div></blockquote><div><b= r></div></div></body></html> ------=_Part_11407198_1454246753.1374581565910--

2 3

Re: [Engine-devel] JDK Failures with .gwttar
by Itamar Heim 29 Jul '13

29 Jul '13

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

2 3

Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_gwt_user - Build # 4736 - Failure!
by Eyal Edri 29 Jul '13

29 Jul '13

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" <jenkins(a)ovirt.org> > To: eedri(a)redhat.com, engine-patches(a)ovirt.org, oliel(a)redhat.com, yzaslavs(a)redhat.com, gerrit2(a)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. > >

1 0

Re: [Engine-devel] Fwd: get certificate with SDK
by Michael Pasternak 29 Jul '13

29 Jul '13

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} <https://%7bovirt-engine%7d/api/vms/%7bid%7d>, and I can > > get mostly VM’s informations via ovirt-engine-sdk, but I can’t got <certificate> via SDK. > > > > This is a part of XML in https://{ovirt-engine}/api/vms/{id} <https://%7bovirt-engine%7d/api/vms/%7bid%7d> > > <display> > > <type>spice</type> > > <address>192.168.1.241</address> > > <port>5914</port> > > <secure_port>5915</secure_port> > > <monitors>1</monitors> > > <allow_override>false</allow_override> > > *<certificate>* > > *<subject>O=thtfc.com,CN=allinone241.thtfc.com</subject>* > > *</certificate>* > > <smartcard_enabled>false</smartcard_enabled> > > </display> > > > > 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 "<stdin>", line 1, in <module> > > AttributeError: 'NoneType' object has no attribute 'get_subject' > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -- Michael Pasternak RedHat, ENG-Virtualization R&D

2 1

[Engine-devel] Join us in a deep dive into the oVirt-Neutron integration
by Mike Kolesnik 28 Jul '13

28 Jul '13

------=_Part_6950277_1603066323.1375022559987 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The following is a new meeting request: Subject: Join us in a deep dive into the oVirt-Neutron integration Organizer: "Mike Kolesnik" <mkolesni(a)redhat.com> Time: Wednesday, July 31, 2013, 4:00:00 PM - 5:00:00 PM GMT +02:00 Jerusalem Invitees: users(a)ovirt.org; engine-devel(a)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.DF0344C0EEC820394D37F8… There will also be a teleconferencing bridge available via Intercall: Bridge id: 972506565679 Phone numbers: http://www.ovirt.org/Intercall Regards, Mike & Livnat ------=_Part_6950277_1603066323.1375022559987 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body id=3D'htmlmode'><h3>The following is a new meeting request:</h3= > <p> <table border=3D'0'> <tr><th align=3Dleft>Subject:</th><td>Join us in a deep dive into the oVirt= -Neutron integration </td></tr> <tr><th align=3Dleft>Organizer:</th><td>"Mike Kolesnik" <mkolesni@redhat= .com> </td></tr> </table> <p> <table border=3D'0'> <tr><th align=3Dleft>Time:</th><td>Wednesday, July 31, 2013, 4:00:00 PM - 5= :00:00 PM GMT +02:00 Jerusalem </td></tr></table> <p> <table border=3D'0'> <tr><th align=3Dleft>Invitees:</th><td>users(a)ovirt.org; engine-devel(a)ovirt.= org </td></tr> </table> <div>*~*~*~*~*~*~*~*~*~*</div><br><div style=3D"font-family: times new roma= n, new york, times, serif; font-size: 12pt; color: #000000"><div><div>Hi ev= eryone,</div><div><br></div><div>As you may know, In oVirt 3.3 we're releas= ing an integration of OpenStack Networking service</div><div>(a.k.a. Neutro= n) as another way to define & use VM networks, besides the good old Lin= ux</div><div>Bridge support in VDSM.</div><div><br></div><div>You're all in= vited to join us in a deep dive into this integration, highlighting the way= it works,</div><div>the value it brings and how it can be further extended= .</div><div><br></div><div>The session will take place on Wednesday, <span = class=3D"Object" id=3D"OBJ_PREFIX_DWT856_com_zimbra_date">Jul 31</span>, 20= 13 from 4:00 PM to 5:00 PM GMT +02:00 (Jerusalem)</div><div><br></div><div>= The session will be done via Elluminate:</div><div><a href=3D"https://sas.e= lluminate.com/m.jnlp?sid=3D819&password=3DM.DF0344C0EEC820394D37F89D9BE= 68C" data-mce-href=3D"https://sas.elluminate.com/m.jnlp?sid=3D819&passw= ord=3DM.DF0344C0EEC820394D37F89D9BE68C">https://sas.elluminate.com/m.jnlp?s= id=3D819&password=3DM.DF0344C0EEC820394D37F89D9BE68C</a><br data-mce-bo= gus=3D"1"></div><div><br></div><div>There will also be a teleconferencing b= ridge available via Intercall:</div><div>Bridge id: 972506565679</div><div>= Phone numbers: http://www.ovirt.org/Intercall</div><div><br></div><span nam= e=3D"x"></span>Regards,<br>Mike & Livnat<span name=3D"x"></span></div><= /div></body></html> ------=_Part_6950277_1603066323.1375022559987 Content-Type: text/calendar; charset=utf-8; method=REQUEST; name=meeting.ics Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Asia/Jerusalem BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETTO:+0200 TZOFFSETFROM:+0300 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=1SU TZNAME:IST END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETTO:+0300 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR TZNAME:IDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:5c4f436c-de9b-4420-823f-b122d5d0e354 SUMMARY:Join us in a deep dive into the oVirt-Neutron integration ATTENDEE;CN=users;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailt o:users@ovirt.org ATTENDEE;CN=engine-devel;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:engine-devel@ovirt.org ORGANIZER;CN=Mike Kolesnik:mailto:mkolesni@redhat.com DTSTART;TZID="Asia/Jerusalem":20130731T160000 DTEND;TZID="Asia/Jerusalem":20130731T170000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20130728T144239Z DTSTAMP:20130728T144239Z SEQUENCE:0 DESCRIPTION:The following is a new meeting request:\n\nSubject: Join us in a deep dive into the oVirt-Neutron integration \nOrganizer: "Mike Kolesnik" < mkolesni(a)redhat.com> \n\nTime: Wednesday\, July 31\, 2013\, 4:00:00 PM - 5:0 0:00 PM GMT +02:00 Jerusalem\n \nInvitees: users(a)ovirt.org\; engine-devel@ov irt.org \n\n\n*~*~*~*~*~*~*~*~*~*\n\nHi everyone\, \n\nAs you may know\, In oVirt 3.3 we're releasing an integration of OpenStack Networking service \n( a.k.a. Neutron) as another way to define & use VM networks\, besides the goo d old Linux \nBridge support in VDSM. \n\nYou're all invited to join us in a deep dive into this integration\, highlighting the way it works\, \nthe val ue it brings and how it can be further extended. \n\nThe session will take p lace on Wednesday\, Jul 31 \, 2013 from 4:00 PM to 5:00 PM GMT +02:00 (Jerus alem) \n\nThe session will be done via Elluminate: \nhttps://sas.elluminate. com/m.jnlp?sid=819&password=M.DF0344C0EEC820394D37F89D9BE68C \n\nThere will also be a teleconferencing bridge available via Intercall: \nBridge id: 9725 06565679 \nPhone numbers: http://www.ovirt.org/Intercall \n\nRegards\, \nMik e & Livnat \n X-ALT-DESC;FMTTYPE=text/html:<html><body id='htmlmode'><h3>The following is a new meeting request:</h3>\n\n<p>\n<table border='0'>\n<tr><th align=left>S ubject:</th><td>Join us in a deep dive into the oVirt-Neutron integration </ td></tr>\n<tr><th align=left>Organizer:</th><td>"Mike Kolesnik" &lt\;mkolesn i(a)redhat.com&gt\; </td></tr>\n</table>\n<p>\n<table border='0'>\n<tr><th ali gn=left>Time:</th><td>Wednesday\, July 31\, 2013\, 4:00:00 PM - 5:00:00 PM G MT +02:00 Jerusalem\n </td></tr></table>\n<p>\n<table border='0'>\n<tr><th a lign=left>Invitees:</th><td>users(a)ovirt.org\; engine-devel(a)ovirt.org </td></ tr>\n</table>\n<div>*~*~*~*~*~*~*~*~*~*</div><br><div style="font-family: ti mes new roman\, new york\, times\, serif\; font-size: 12pt\; color: #000000" ><div><div>Hi everyone\,</div><div><br></div><div>As you may know\, In oVirt 3.3 we're releasing an integration of OpenStack Networking service</div><di v>(a.k.a. Neutron) as another way to define &amp\; use VM networks\, besides the good old Linux</div><div>Bridge support in VDSM.</div><div><br></div><d iv>You're all invited to join us in a deep dive into this integration\, high lighting the way it works\,</div><div>the value it brings and how it can be further extended.</div><div><br></div><div>The session will take place on We dnesday\, <span class="Object" id="OBJ_PREFIX_DWT856_com_zimbra_date">Jul 31 </span>\, 2013 from 4:00 PM to 5:00 PM GMT +02:00 (Jerusalem)</div><div><br> </div><div>The session will be done via Elluminate:</div><div><a href="https ://sas.elluminate.com/m.jnlp?sid=819&amp\;password=M.DF0344C0EEC820394D37F89 D9BE68C" data-mce-href="https://sas.elluminate.com/m.jnlp?sid=819&amp\;passw ord=M.DF0344C0EEC820394D37F89D9BE68C">https://sas.elluminate.com/m.jnlp?sid= 819&amp\;password=M.DF0344C0EEC820394D37F89D9BE68C</a><br data-mce-bogus="1" ></div><div><br></div><div>There will also be a teleconferencing bridge avai lable via Intercall:</div><div>Bridge id: 972506565679</div><div>Phone numbe rs: http://www.ovirt.org/Intercall</div><div><br></div><span name="x"></span >Regards\,<br>Mike &amp\; Livnat<span name="x"></span></div></div></body></h tml> BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR ------=_Part_6950277_1603066323.1375022559987--

1 0

Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_unit_tests - Build # 4737 - Still Unstable!
by Eyal Edri 28 Jul '13

28 Jul '13

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=3806a44b33e303… ----- Original Message ----- > From: "Jenkins ci oVirt Server" <jenkins(a)ovirt.org> > To: eedri(a)redhat.com, engine-patches(a)ovirt.org, oliel(a)redhat.com, yzaslavs(a)redhat.com, obasan(a)redhat.com, > gerrit2(a)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) > > > > >

1 0

[Engine-devel] ovirt.org and profiliing
by Liran Zelkha 26 Jul '13

26 Jul '13

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

3 2

[Engine-devel] Getting Hosts in a Data Center using the oVirt API
by Schoenbrun, Dustin 26 Jul '13

26 Jul '13

--_000_CE147D80D9B0dustinschoenbrunnetappcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 "revers= e lookup" from all hosts present in the oVirt Engine to see what clusters t= hey're in and then finding out what data center the cluster belongs to. Tha= nks in advance, Michael! -- Dustin --_000_CE147D80D9B0dustinschoenbrunnetappcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <B3BCD3481914DD4A954C01CE14D8DF57(a)hq.netapp.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif; "> <div> <div> <div>Hey Michael,</div> <div><br> </div> <div>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 &q= uot;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!</= div> <div><br> </div> <div> <div>-- Dustin</div> <div><br> </div> </div> </div> </div> </body> </html> --_000_CE147D80D9B0dustinschoenbrunnetappcom_--

2 2

[Engine-devel] fail to add host from portal
by Chen, Wei D 26 Jul '13

26 Jul '13

------=_NextPart_000_0022_01CE8926.DC07BBE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0022_01CE8926.DC07BBE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV/jCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIE6zCC A9OgAwIBAgIQUukCyhHoRJ2UZTgvoxowuzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTEzMDMxOTAwMDAwMFoX DTIwMDUzMDEwNDgzOFoweTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQwEgYDVQQHEwtTYW50 YSBDbGFyYTEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVy bmFsIEJhc2ljIElzc3VpbmcgQ0EgNEEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDg sMyAndhJVfoD2wT6OMfdv4XddrzrPcssq7/pa+Mh29RvGejPaqe+X1QpAjewTXNRFDGt+C+0/Rs+ C3W4PAB8tzofl6qfKL7sWs+xMYJHiDAOarVaRNCA0M1dSBvvV73/qx+r5Z8IOmLxJxqCXIsJGnum H9XrRxuK0G+dkV6UoIMGHffZLoobdsB2c0YH++TzpvAOVjqiYOzr9Gx83DNBXCj8zeg+u7HrLrPI ihG6V+RUQ1szT/1GvNA6XIrhblWTgQSx9baOUJXhbzdAqpFxwAohTHDar8egdU9tsROusuYTpFFn /55aWQZaX6a3HjYc6A6ZfQFF1NGj28fvJ4GjAgMBAAGjggF3MIIBczAfBgNVHSMEGDAWgBStvZh6 NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUHmkqtNwo/kcYTiELP7ysES/wmPUwDgYDVR0PAQH/ BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwNgYDVR0lBC8wLQYIKwYBBQUHAwQGCisGAQQBgjcK AwQGCisGAQQBgjcKAwwGCSsGAQQBgjcVBTAXBgNVHSAEEDAOMAwGCiqGSIb4TQEFAWkwSQYDVR0f BEIwQDA+oDygOoY4aHR0cDovL2NybC50cnVzdC1wcm92aWRlci5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwOgYIKwYBBQUHAQEELjAsMCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC50cnVz dC1wcm92aWRlci5jb20wNQYDVR0eBC4wLKAqMAuBCWludGVsLmNvbTAboBkGCisGAQQBgjcUAgOg CwwJaW50ZWwuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQApws2j/ZKjUmeiLwbtblDoVI+rV+bIpbex IN/Vqa/IeSMSB3bmfswpEcYSZHHGjOI8qlyZt9dhT4nSDnrScKjmA8XvxZ3tmbNyYJybVQUV8jF/ DpADX1tGlMLxswxpJISXzLf0+DBr4cQ2ag9mwzrcN1nrOIOc+pxJtx9izyp3+bl3baulerkgZVS1 fotftH+FJLD/ex8BOcEuCIm2KVXJjs4YaZgoIBLYjTiK29JLVa15xdO305kPI1uXsu05sGuAwuFm Sklb6k5H1/eHlUbZLm4qQDtOH00L0ShJx3BAIAjD5RYptJDQiyPZQUvt8cq+apYpVMv3yxHO8jex 40LgMIIGZjCCBU6gAwIBAgIKFyvckgACAAAU0jANBgkqhkiG9w0BAQUFADB5MQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSA0QTAeFw0x MzA3MTgwMTEwMzdaFw0xNjA3MDIwMTEwMzdaMDsxFDASBgNVBAMTC0NoZW4sIFdlaSBEMSMwIQYJ KoZIhvcNAQkBFhR3ZWkuZC5jaGVuQGludGVsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAN50qdmWdvh7vbj60QYyg7t3euDjJ8OU7EkwSPOgX3DKIW1PgAjzkpXvCxMhIBPr/KWX 7OVqYgP/vY8X0gLYrtGgBjwIkPOmFrSB2oRNEQiAtbP8YyOlprYHDeAUHFziVb6UPjPD9sR15q00 rH41v9qhRcll5V2cz4krCAdzSEWMGxnpZMBS8vV3zrwD1fiU0LLyn8Nb1u1MT0Sh0ZKQrWC/Icv1 UWklTdaGkbUxUa3eUZZdH5ayXIfLir4h3hChmkWsjLeLWXMHz/fCn3KW6qP64+WJJr0kcnpOM/Sp 07F9F6yfdg27HVWEHAphROkHJFdHK47RxnWWrnmB6lLMdzkCAwEAAaOCAywwggMoMEQGCSqGSIb3 DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG 9w0DBzAdBgNVHQ4EFgQUUIOKK8gtAh2SucBYccty6S33jggwCwYDVR0PBAQDAgeAMB8GA1UdIwQY MBaAFB5pKrTcKP5HGE4hCz+8rBEv8Jj1MIHJBgNVHR8EgcEwgb4wgbuggbiggbWGVGh0dHA6Ly93 d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElz c3VpbmclMjBDQSUyMDRBLmNybIZdaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3Np dG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwNEEuY3Js MIH1BggrBgEFBQcBAQSB6DCB5TBsBggrBgEFBQcwAoZgaHR0cDovL3d3dy5pbnRlbC5jb20vcmVw b3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUy MENBJTIwNEEoMikuY3J0MHUGCCsGAQUFBzAChmlodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNv bS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1 aW5nJTIwQ0ElMjA0QSgyKS5jcnQwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhsOMdYSZ5VGD /YEohY6fU4KRwAlngd69OZXwQwIBZAIBCDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoD DDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwwwRQYDVR0RBD4wPKAk BgorBgEEAYI3FAIDoBYMFHdlaS5kLmNoZW5AaW50ZWwuY29tgRR3ZWkuZC5jaGVuQGludGVsLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEAFKXJisQoKmP6JRz7poS0Z+AbM5QEpy/NTxT4lI+nHfznQcEW emgt5pFJORthxKKFipifuHQxDYpnmNBq5wkn5zLpnMJQVMqoG/FPP2NWXW7NHRmzewousUCjm6ci MSJbu7YNSfJAPz/fUznOKxmwBi5i+yROQXpeAx5eU9bcqaClBUt7e0FRyUCUEGfuwrzqamuPaxGc Jg0zS7t7uPLtMQ+Xg83nVUBmWzjCXEzJesEG4KkY9lXInQojn7nIqSYJyQnm+0xK1TKNQ/G/J2DD m2V7WDlfyECVbQwzwseJcFCET+zKvePggmgwoJ7Vjc/6gju3mj9wrr4TEil7PzVKIjCCBmcwggVP oAMCAQICChcsF54AAgAAFNMwDQYJKoZIhvcNAQEFBQAweTELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AkNBMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzAp BgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgNEEwHhcNMTMwNzE4MDExMDUy WhcNMTYwNzAyMDExMDUyWjA7MRQwEgYDVQQDEwtDaGVuLCBXZWkgRDEjMCEGCSqGSIb3DQEJARYU d2VpLmQuY2hlbkBpbnRlbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpHWFM hzvKyQ+h07xAyVymceQlT/Y1YK+nxXKFLq6Kglz8suv/Uk4ur+YXoBfW/+OWxjYU+misOO+apdAw my3KXs+222bBd7hmxvMdOuz5jN1m+dLYlMlWpWyvLe+3531ufG4yymmlGxfifVtqKVmWSZ8li1gm MbOGip1GU1dXfdckGwinmRFaSHFThcy+6jOKMY88cf7gRY/pJP6g3/tSwnO3LZgRZzqBu7VkZJpE phgfPHMgmNLWQRUuQ/PEO/XrLkCrNWo90RhQzYbvWMFOx+/y/VGRvf/QKqJBUj+cDOT7qLtp15lm vm5oBGC/qBLv5ty2ZSHU/lUih1Io4nclAgMBAAGjggMtMIIDKTBEBgkqhkiG9w0BCQ8ENzA1MA4G CCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0O BBYEFIQlFPFOAdRJpFVdkBxzADk9BtROMAsGA1UdDwQEAwIEMDAfBgNVHSMEGDAWgBQeaSq03Cj+ RxhOIQs/vKwRL/CY9TCByQYDVR0fBIHBMIG+MIG7oIG4oIG1hlRodHRwOi8vd3d3LmludGVsLmNv bS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0El MjA0QS5jcmyGXWh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0lu dGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDRBLmNybDCB9QYIKwYBBQUH AQEEgegwgeUwbAYIKwYBBQUHMAKGYGh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2Vy dGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDRBKDIp LmNydDB1BggrBgEFBQcwAoZpaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9y eS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIw NEEoMikuY3J0MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJ Z4S52UGHhP9OAgFkAgENMB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMEMCkGCSsGAQQB gjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDBDBFBgNVHREEPjA8oCQGCisGAQQBgjcU AgOgFgwUd2VpLmQuY2hlbkBpbnRlbC5jb22BFHdlaS5kLmNoZW5AaW50ZWwuY29tMA0GCSqGSIb3 DQEBBQUAA4IBAQBKK79ulOFE5/S7yfejfIXz8xX3aRUmggULkjwh4sTe1M6JEKLDB9AqzNMKb/hy PHPDFAlSuYToRu5QUiIIREdC4+RJhZrJ/NRELZktPJrOIpydhKsOAODNle2Rlypq9XvmeCqElLiR XZTrBQQ4j4bMhnJVjS2h0ZULsR3qraV3ssWYjC1d6mBysmf4IdVnNSKECjGAJhLhwsow9igtjCzz qKZ9A62vrG+ag/vnlx8bOO7ReqoK/X3hCYvuappzZ7udulpjf5zD/oAv5xJU0S0mSr1XKyfNOCIT btX0zJM9tOoV1zr0eJb1I+aulgCjqqxaZqbvWdkQPdn++dAgQsmAMYIDvDCCA7gCAQEwgYcweTEL MAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQwEgYDVQQHEwtTYW50YSBDbGFyYTEaMBgGA1UEChMR SW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3Vpbmcg Q0EgNEECChcr3JIAAgAAFNIwCQYFKw4DAhoFAKCCAgkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTMwNzI1MDMwNTIzWjAjBgkqhkiG9w0BCQQxFgQUvoLvQz3lM/UU OwlFPxpn0MVx6gUwcgYJKoZIhvcNAQkPMWUwYzALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoG CCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAIC MAsGCWCGSAFlAwQCATCBmAYJKwYBBAGCNxAEMYGKMIGHMHkxCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJDQTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSsw KQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDRBAgoXLBeeAAIAABTTMIGa BgsqhkiG9w0BCRACCzGBiqCBhzB5MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFDASBgNVBAcT C1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwg RXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSA0QQIKFywXngACAAAU0zANBgkqhkiG9w0BAQEFAASC AQBvhHuC7L00tasqo4geRaoE7tRLON/Fd7LBRcTKFaWNNA+hnnG33IP5H8uQ9nUtaQ7hneIPGtUS 32T3vmk32V/1QOZEFA3gvXE8kNNUtQxdLhOsI7sRrmPu9wEPFVagM2xVu2woAeeB/osF8j8lDsq9 kIvO73jGuuJMLUsDW1KUf/q+yv8UQMIdWeAZuZ0f9vyZ0iTzNxPSSCBSZa0Xwm9tOohRufUZs2o2 B2hq5wgqI7WFLwU9sjNL/ryhVTNOSXpYVmYz1j355ZNFxwljbM77VP4vSQEpx1xQjViGo+1+cCjy YsL4q1PCVA4bX1CxQEs627At4Juqd+JQQ0jVyEd7AAAAAAAA ------=_NextPart_000_0022_01CE8926.DC07BBE0--

3 6

[Engine-devel] get certificate with SDK
by wlbleaboy＠126 26 Jul '13

26 Jul '13

ÕâÊÇÒ»·â MIME žñÊœµÄ¶à²¿·ÖÓÊŒþ¡£ ------=_NextPart_000_0001_01CE89E9.CC57E260 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, all: I can got all the VM=A1=AFs information in https://{ovirt-engine}/api/vms/{id} <https://%7bovirt-engine%7d/api/vms/%7bid%7d> , and I can=20 get mostly VM=A1=AFs informations via ovirt-engine-sdk, but I can=A1=AFt = got <certificate> via SDK. =20 This is a part of XML in https://{ovirt-engine}/api/vms/{id} <https://%7bovirt-engine%7d/api/vms/%7bid%7d> =20 <display> <type>spice</type> <address>192.168.1.241</address> <port>5914</port> <secure_port>5915</secure_port> <monitors>1</monitors> <allow_override>false</allow_override> <certificate> <subject>O=3Dthtfc.com,CN=3Dallinone241.thtfc.com</subject> </certificate> <smartcard_enabled>false</smartcard_enabled> </display> =20 For example, I can port like vm.get_display().get_port() =20 but when I want CN, I tyied use vm.get_display().get_certificate().get_subject() it return =20 >>> vm.get_display().get_certificate().get_subject() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'NoneType' object has no attribute 'get_subject' ------=_NextPart_000_0001_01CE89E9.CC57E260 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-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=3DContent-Type content=3D"text/html; charset=3Dgb2312"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style>  </style>  </head> <body lang=3DZH-CN link=3Dblue vlink=3Dpurple = style=3D'text-justify-trim:punctuation'> <div class=3DSection1> <p class=3DMsoNormal><span lang=3DEN-US>Hi, all:<o:p></o:p></span></p> <p class=3DMsoNormal><span = lang=3DEN-US>         I can got all the VM=A1=AFs information in <a href=3D"https://%7bovirt-engine%7d/api/vms/%7bid%7d">https://{ovirt-engin= e}/api/vms/{id}</a>, and I can <o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-US>get mostly VM=A1=AFs = informations via ovirt-engine-sdk, but I can=A1=AFt got <certificate> via = SDK.<o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-US><o:p> </o:p></span></p> <p class=3DMsoNormal><span = lang=3DEN-US>         This is a part of XML in <a = href=3D"https://%7bovirt-engine%7d/api/vms/%7bid%7d">https://{ovirt-engin= e}/api/vms/{id}</a> <o:p></o:p></span></p> <p class=3DMsoNormal><span = lang=3DEN-US>         = <display><o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'margin-left:21.0pt;text-indent:21.0pt'><span lang=3DEN-US><type>spice</type><o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'margin-left:21.0pt;text-indent:21.0pt'><span lang=3DEN-US><address>192.168.1.241</address><o:p></o:p></spa= n></p> <p class=3DMsoNormal = style=3D'margin-left:21.0pt;text-indent:21.0pt'><span lang=3DEN-US><port>5914</port><o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'margin-left:21.0pt;text-indent:21.0pt'><span lang=3DEN-US><secure_port>5915</secure_port><o:p></o:p></span= ></p> <p class=3DMsoNormal = style=3D'margin-left:21.0pt;text-indent:21.0pt'><span lang=3DEN-US><monitors>1</monitors><o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'margin-left:21.0pt;text-indent:21.0pt'><span lang=3DEN-US><allow_override>false</allow_override><o:p></o:p= ></span></p> <p class=3DMsoNormal = style=3D'margin-left:21.0pt;text-indent:21.0pt'><b><span lang=3DEN-US><certificate><o:p></o:p></span></b></p> <p class=3DMsoNormal = style=3D'margin-left:42.0pt;text-indent:21.0pt'><b><span lang=3DEN-US><subject>O=3Dthtfc.com,CN=3Dallinone241.thtfc.com</= subject><o:p></o:p></span></b></p> <p class=3DMsoNormal = style=3D'margin-left:21.0pt;text-indent:21.0pt'><b><span lang=3DEN-US></certificate><o:p></o:p></span></b></p> <p class=3DMsoNormal = style=3D'margin-left:21.0pt;text-indent:21.0pt'><span lang=3DEN-US><smartcard_enabled>false</smartcard_enabled><o:p= ></o:p></span></p> <p class=3DMsoNormal style=3D'text-indent:21.0pt'><span = lang=3DEN-US></display><o:p></o:p></span></p> <p class=3DMsoNormal style=3D'text-indent:21.0pt'><span = lang=3DEN-US><o:p> </o:p></span></p> <p class=3DMsoNormal style=3D'text-indent:21.0pt'><span lang=3DEN-US>For = example, I can port like<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'text-indent:21.0pt'><span = lang=3DEN-US>         = vm.get_display().get_port()<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'text-indent:21.0pt'><span = lang=3DEN-US><o:p> </o:p></span></p> <p class=3DMsoNormal style=3D'text-indent:21.0pt'><span lang=3DEN-US>but = when I want CN, I tyied use<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'text-indent:21.0pt'><span = lang=3DEN-US>         = vm.get_display().get_certificate().get_subject()<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'text-indent:21.0pt'><span lang=3DEN-US>it = return<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'text-indent:21.0pt'><span = lang=3DEN-US> <o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'margin-left:10.5pt;mso-para-margin-left:1.0gd; text-indent:21.0pt'><span lang=3DEN-US>>>> vm.get_display().get_certificate().get_subject()<o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'margin-left:10.5pt;mso-para-margin-left:1.0gd; text-indent:21.0pt'><span lang=3DEN-US>Traceback (most recent call = last):<o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'margin-left:10.5pt;mso-para-margin-left:1.0gd; text-indent:21.0pt'><span lang=3DEN-US>  File = "<stdin>", line 1, in <module><o:p></o:p></span></p> <p class=3DMsoNormal = style=3D'margin-left:10.5pt;mso-para-margin-left:1.0gd; text-indent:21.0pt'><span lang=3DEN-US>AttributeError: 'NoneType' object = has no attribute 'get_subject'<o:p></o:p></span></p> </div> </body> </html> ------=_NextPart_000_0001_01CE89E9.CC57E260--

1 0

Re: [Engine-devel] [Users] [ANN] oVirt 3.3 Test Day - Tomorrow Wed - Jul 24th
by Moran Goldboim 24 Jul '13

24 Jul '13

This is a multi-part message in MIME format. --------------010002010605090001030500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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… 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users --------------010002010605090001030500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">For all participants in the test day:<br> <br> -it would be great if you can put your name/distro here [1]<br> -if you found a general bug (regression) , you can add it to to the table under general [2]<br> <br> we would like to get some input on general bugs/problems you are experiencing.<br> <br> Thanks. <br> <br> [1] <a class="moz-txt-link-freetext" href="http://www.ovirt.org/OVirt_3.3_TestDay#Participants_Table">http://www.ovirt.org/OVirt_3.3_TestDay#Participants_Table</a><br> [2] <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="http://www.ovirt.org/OVirt_3.3_TestDay#oVirt_3.3_New_Features_-_Test_Status…">http://www.ovirt.org/OVirt_3.3_TestDay#oVirt_3.3_New_Features_-_Test_Status…</a><br> <br> <br> On 07/23/2013 03:00 PM, Moran Goldboim wrote:<br> </div> <blockquote cite="mid:51EE7057.40108@redhat.com" type="cite"> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> 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].<br> <br> <a moz-do-not-send="true" href="http://www.ovirt.org/OVirt_3.3_TestDay">http://www.ovirt.org/OVirt_3.3_TestDay</a><br> <br> Tomorrow morning (when all repos are packages are ready - finger crossed) you are invited to:<br> <br> -checkout Test Day page [2]<br> -choose a distro (el6/fc19)<br> -install oVirt [3]<br> -check out the version<br> -report what you find<br> <br> Developers and Users will be available in the channel/ on list to support in case there is trouble  <br> <br> Thanks<br> <br> <br> [1] <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a moz-do-not-send="true" href="http://www.ovirt.org/OVirt_3.3_release-management">http://www.ovirt.org/OVirt_3.3_release-management</a><br> [2] <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a moz-do-not-send="true" href="http://www.ovirt.org/OVirt_3.3_TestDay">http://www.ovirt.org/OVirt_3.3_TestDay</a><br> [3]<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.ovirt.org/Download">http://www.ovirt.org/Download</a> <br> <br> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users(a)ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> </body> </html> --------------010002010605090001030500--

1 0

[Engine-devel] Linking to bugs from oVirt wiki
by Allon Mureinik 24 Jul '13

24 Jul '13

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

1 1