[Engine-devel] [CORE] broken backward compatibility for vm creation
[oVirt shell (connected)]# add vm --name test --cluster-id 0001-0001-0001-0001-0001 --template-id ---- === ERROR = status: 400 reason: Bad Request detail: Cannot add VM. Selected operating system is not supported by the architecture. === [oVirt shell (connected)]# show template ---- id: ---- name : Blank description : Blank template cluster-id: 0001-0001-0001-0001-0001 cpu-architecture : UNDEFINED cpu-topology-cores: 1 cpu-topology-sockets : 1 cpu_shares: 0 creation_time : 2008-04-01 00:00:00+03:00 delete_protected : False display-allow_override: False display-monitors : 1 display-single_qxl_pci: False display-smartcard_enabled : False display-type : spice high_availability-enabled : False high_availability-priority: 0 memory: 1073741824 origin: rhev os-boot-dev : hd os-type : other stateless : False status-state : ok type : desktop usb-enabled : False [oVirt shell (connected)]# show cluster 0001-0001-0001-0001-0001 id : 0001-0001-0001-0001-0001 name : Default description: The default server cluster ballooning_enabled : False data_center-id : 0002-0002-0002-0002-0002 error_handling-on_error: migrate gluster_service: False memory_policy-overcommit-percent : 100 memory_policy-transparent_hugepages-enabled: True scheduling_policy-policy : none threads_as_cores : False trusted_service: False tunnel_migration : False version-major : 3 version-minor : 3 virt_service : True -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [CORE] broken backward compatibility for vm creation
Thanks Vitor, Such changes should be merged all together, otherwise they create significant noise in master, and make testing not possible what can lead to not stable master afterwards, btw eyal, shouldn't Jenkins job be alerting on such changes? On 12/24/2013 02:04 PM, Vitor de Lima wrote: This is temporarily broken due to the introduction of multi-architecture support. Changes #18227 and #20667 are going to fix this by blocking the addition of VMs into clusters without a defined architecture and properly selecting the default OS when creating VMs. -Original Message- From: engine-devel-boun...@ovirt.org [mailto:engine-devel- boun...@ovirt.org] On Behalf Of Michael Pasternak Sent: terça-feira, 24 de dezembro de 2013 07:30 To: engine-devel Cc: Michal Skrivanek Subject: [Engine-devel] [CORE] broken backward compatibility for vm creation [oVirt shell (connected)]# add vm --name test --cluster-id 0001-0001- 0001-0001-0001 --template-id ---- == = ERROR == === status: 400 reason: Bad Request detail: Cannot add VM. Selected operating system is not supported by the architecture. == == === [oVirt shell (connected)]# show template ---- id: ---- name : Blank description : Blank template cluster-id: 0001-0001-0001-0001-0001 cpu-architecture : UNDEFINED cpu-topology-cores: 1 cpu-topology-sockets : 1 cpu_shares: 0 creation_time : 2008-04-01 00:00:00+03:00 delete_protected : False display-allow_override: False display-monitors : 1 display-single_qxl_pci: False display-smartcard_enabled : False display-type : spice high_availability-enabled : False high_availability-priority: 0 memory: 1073741824 origin: rhev os-boot-dev : hd os-type : other stateless : False status-state : ok type : desktop usb-enabled : False [oVirt shell (connected)]# show cluster 0001-0001-0001-0001- 0001 id : 0001-0001-0001-0001-0001 name : Default description: The default server cluster ballooning_enabled : False data_center-id : 0002-0002-0002-0002-0002 error_handling-on_error: migrate gluster_service: False memory_policy-overcommit-percent : 100 memory_policy-transparent_hugepages-enabled: True scheduling_policy-policy : none threads_as_cores : False trusted_service: False tunnel_migration : False version-major : 3 version-minor : 3 virt_service : True -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-python 3.4.0.1-1 released
- to host.install() added ssh related details - to template added virtio_scsi.enabled - to vm added virtio_scsi.enabled - to File class added 'content' field - Payload class now reuses Files instead of own List of PayloadFile objects - added ability to attach a disk snapshot to the virtual machine - to vms.add() added [action.vm.initialization.cloud-init] - to NIC added OnBoot/BootProtocol properties - to VersionCaps added a list of supported payload-encodings - to Step added externalType - to NIC added vnicProfile and bootProtocol - to CPU added architecture - to VnicProfilePermission added delete() method - to Disk added readOnly - to VMs.add() added [vm.cpu.architecture], [action.vm.initialization.cloud_init.*] arguments - to Templates.add() added [template.cpu.architecture], [action.template.initialization.cloud_init.*] arguments - to UserRoles.add() added permit.id|name arguments - at VMSnapshot removed preview/undo/commit methods - to DataCenterClusterGlusterVolumeGlusterBricks added activate/stopmigrate/migrate actions - to NetworkVnicProfile added Permissions sub-collection - to Cluster added [cluster.cpu.architecture] - to DataCenter added Networks sub-collection - to ClusterGlusterVolumeGlusterBricks added activate method - to ClusterGlusterVolume added stoprebalance method - to entry-point API added Permissions collection (for managing system-permissions) - to host.install() added ssh related arguments - to template added virtio_scsi.enabled - to vm added virtio_scsi.enabled - added ability to attach a disk snapshot to the virtual machine - to File class added 'content' field - Payload class now reuses Files instead of own PayloadFile collection - to Cluster added [cluster.display.proxy] - to VmPool added [vmpool.display.proxy] - sdk ignores url attribute and hardcode /api #1038952 - support automatic auth session invalidation #1018559 more details can be found at [1]. [1] http://www.ovirt.org/Python-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 3.4.0.1-1 released
- to vms.add() added [action.vm.initialization.cloud-init] - to NIC added OnBoot/BootProtocol properties - to VersionCaps added a list of supported payload-encodings - to Step added externalType - to NIC added vnicProfile and bootProtocol - to CPU added architecture - to VnicProfilePermission added delete() method - to Disk added readOnly - to VMs.add() added [vm.cpu.architecture], [action.vm.initialization.cloud_init.*] arguments - to Templates.add() added [template.cpu.architecture], [action.template.initialization.cloud_init.*] arguments - to UserRoles.add() added permit.id|name arguments - at VMSnapshot removed preview/undo/commit methods - to DataCenterClusterGlusterVolumeGlusterBricks added activate/stopmigrate/migrate actions - to NetworkVnicProfile added Permissions sub-collection - to Cluster added [cluster.cpu.architecture] - to DataCenter added Networks sub-collection - to ClusterGlusterVolumeGlusterBricks added activate method - to ClusterGlusterVolume added stoprebalance method - to entry-point API added Permissions collection (for managing system-permissions) - to host.install() added ssh related arguments - to template added virtio_scsi.enabled - to vm added virtio_scsi.enabled - added ability to attach a disk snapshot to the virtual machine - to File class added 'content' field - Payload class now reuses Files instead of own PayloadFile collection more details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Proposal to add Juan Hernandez as maintainer to api/sdk/cli
Juan has worked on oVirt for a long period of time, developing several features in the different areas (including api and cli), and obviously gained a lot of experience and knowledge, I'd like to propose Juan as a maintainer of the api/sdk/cli projects. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] master is broken by Common#VdcActionUtilsTest ??
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile (default-testCompile) on project common: Compilation failure: Compilation failure: [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[13,42] error: package org.ovirt.engine.core.common.action does not exist [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[14,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[15,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[16,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[17,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[18,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[19,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[20,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[21,52] error: cannot find symbol ... org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile (default-testCompile) on project common: Compilation failure at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656) at org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:161) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] master is broken by Common#VdcActionUtilsTest ??
On 12/09/2013 01:11 PM, Yair Zaslavsky wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, December 9, 2013 12:47:12 PM Subject: [Engine-devel] master is broken by Common#VdcActionUtilsTest ?? Please provide the commit hash you tried to compile with ? 30ff53078b18063e1ee94f68db11e91d49515e27 thanks. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile (default-testCompile) on project common: Compilation failure: Compilation failure: [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[13,42] error: package org.ovirt.engine.core.common.action does not exist [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[14,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[15,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[16,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[17,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[18,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[19,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[20,52] error: cannot find symbol [ERROR] package org.ovirt.engine.core.common.businessentities [ERROR] /home/mpastern/Coding/ovirt/ovirt-engine/backend/manager/modules/common/src/test/java/org/ovirt/engine/core/common/VdcActionUtilsTest.java:[21,52] error: cannot find symbol ... org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile (default-testCompile) on project common: Compilation failure at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure
Re: [Engine-devel] Using REST API in web UI - review call summary
On 11/28/2013 09:37 PM, Vojtech Szocs wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Vojtech Szocs vsz...@redhat.com, engine-devel engine-devel@ovirt.org, Einav Cohen eco...@redhat.com Sent: Sunday, November 24, 2013 9:37:22 AM Subject: Re: Using REST API in web UI - review call summary On 11/22/2013 12:00 AM, Itamar Heim wrote: On 11/21/2013 11:56 PM, Vojtech Szocs wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Vojtech Szocs vsz...@redhat.com, engine-devel engine-devel@ovirt.org Cc: Einav Cohen eco...@redhat.com Sent: Thursday, November 21, 2013 10:25:04 PM Subject: Re: Using REST API in web UI - review call summary On 11/21/2013 11:18 PM, Vojtech Szocs wrote: Hi guys, this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something. -- Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael Gilad) A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us. As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code). -- Q: What about functionality currently used by oVirt UI but not supported by REST API? (asked by Einav) [For example, fetching VM entity over GWT RPC also returns related data such as Cluster name.] A: Based on discussion I've had with other colleagues after yesterday's review call, I don't think that separate support-like backend layer is a good idea. Instead, this is the kind of functionality that could be placed in oVirt.js library. Logical operations like get VMs and related data would be exposed through oVirt.js (callback-based) API and ultimately realized as multiple physical requests to REST API via JavaScript Binding. oVirt.js client would be completely oblivious to the fact that multiple physical requests are dispatched. In fact, since HTTP communication is asynchronous in nature, oVirt.js client wouldn't even notice any difference in terms of API consumption. This assumes JavaScript SDK would use callback-based (non-blocking) API instead of blocking one - after all, blocking API on top of non-blocking implementation sounds pretty much like leaky abstraction [1]. For example: sdk.getVmsWithExtraData( callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST API callbackFiredWhenAllDataIsReady // update client only when all data is ready ) would this also resolve RunMultipleActions? Yes, I think so. There could be API to pass multiple actions and get notified when they complete. sounds like no reason to have RunMultipleQueries, although i'm still sure a single call to engine for multiple keys would be much more efficient than multiple async calls? (I understand we may not be able to model this). Efficiency-wise, yes, single call to get all data seems optimal. API-wise, I don't think it really matters from oVirt.js client perspective. We can proceed with simple (possibly inefficient) solution and improve as needed. We're making baby steps now.. [1] http://en.wikipedia.org/wiki/Leaky_abstraction -- Last but not least, where to maintain JavaScript SDK projects: low-level JavaScript Binding + high-level oVirt.js library. I agree that conceptually both above mentioned projects should go into dedicated ovirt-engine-sdk-js git repository and have their own build/release process. However, for now, we're just making baby steps so let's keep things simple and prototype these projects as part of ovirt-engine git repository. ... we can complicate things anytime, but we should know that any complex system that works has inevitably evolved from simple system that works ... (quote from http://en.wikipedia.org/wiki/Gall%27s_law) I think the entities should just be generated from the xsd. +1 The JavaScript Binding (aka low-level SDK) module should follow same concepts as existing Java SDK
Re: [Engine-devel] Using REST API in web UI - review call summary
On 11/29/2013 11:59 AM, Michael Pasternak wrote: On 11/29/2013 11:45 AM, Michael Pasternak wrote: On 11/28/2013 09:22 PM, Vojtech Szocs wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 24, 2013 9:07:01 AM Subject: Re: [Engine-devel] Using REST API in web UI - review call summary Hi Vojtech, First of all it was a good presentation of requirements + suggested solutions - well done!, Thank you :) few comments/questions inline. On 11/21/2013 11:18 PM, Vojtech Szocs wrote: Hi guys, this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something. -- Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael Gilad) A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us. not sure i buy this one :), this is the purpose of any sdk, including the one you about to write, people that will use it, will be coupling to it ... Of course, but by saying coupling ourselves to Java SDK I meant SDK perspective, not client perspective: of course, but you told something different, that you want js-sdk to be aware of the client, and this is actually why you taking this path. - someone else (you) maintains Java SDK and therefore controls generated sources (JAR or RPM isn't relevant here) - another guy (me) maintains (fictional) Java/GWT SDK that relies on Java SDK + some (supported) customizations - the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources, i.e. the whole code generation process is driven by your SDK, so my SDK is coupled to your SDK's build/release cycle that's how things working in software, you always depending on the certain version of the component you're working against, as it expose set of features you need, i don't think that having control over framework features, justifying rewriting the framework ... (please note that i'm not against the js-sdk, go ahead, this is a nice initiative indeed, i just can't see the business case for not reusing existent infrastructure cause it works for all your needs and eventually both worlds would benefiting from it UI and java-sdk users cause you where extending it with additional capabilities they may also need) For the sake of simplicity, I guess it's best to start with SDK that has no dependencies whatsoever. so why won't you rewrite the engine in Java-script? your js-sdk eventually will be depending on it, this way you'll have control over it (and it's features) as well ;-) After all, there's no common dependency (aside from running Engine to provide XSD RSDL) between Java Python SDK too, if I understand correctly. In other words, building on top of something existing (just because we can do that) isn't always appropriate/flexible/efficient, it always depends on given context and requirements. it would be true, if your requirements would make existing infrastructure inappropriate. As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code). what do you mean by people should have full control over generated code? It's related to coupling from SDK perspective I mentioned above: the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources if you need additional functionality in java-sdk, you could do the following: 1. submit a patch to java-sdk 2. build new java-sdk locally and use it along with new feature you've added 3. make UI depending on next version of java-sdk (which includes your new feature) we (and all other SW projects) doing that day by day in engine,api,etc. (as i mentioned this would also benefit java-sdk users with additional features they might find useful as well) (by people I meant JavaScript SDK developers) Full control means ability to change generated sources in whatever way
Re: [Engine-devel] Using REST API in web UI - review call summary
On 11/29/2013 11:45 AM, Michael Pasternak wrote: On 11/28/2013 09:22 PM, Vojtech Szocs wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 24, 2013 9:07:01 AM Subject: Re: [Engine-devel] Using REST API in web UI - review call summary Hi Vojtech, First of all it was a good presentation of requirements + suggested solutions - well done!, Thank you :) few comments/questions inline. On 11/21/2013 11:18 PM, Vojtech Szocs wrote: Hi guys, this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something. -- Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael Gilad) A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us. not sure i buy this one :), this is the purpose of any sdk, including the one you about to write, people that will use it, will be coupling to it ... Of course, but by saying coupling ourselves to Java SDK I meant SDK perspective, not client perspective: of course, but you told something different, that you want js-sdk to be aware of the client, and this is actually why you taking this path. - someone else (you) maintains Java SDK and therefore controls generated sources (JAR or RPM isn't relevant here) - another guy (me) maintains (fictional) Java/GWT SDK that relies on Java SDK + some (supported) customizations - the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources, i.e. the whole code generation process is driven by your SDK, so my SDK is coupled to your SDK's build/release cycle that's how things working in software, you always depending on the certain version of the component you're working against, as it expose set of features you need, i don't think that having control over framework features, justifying rewriting the framework ... (please note that i'm not against the js-sdk, go ahead, this is a nice initiative indeed, i just can't see the business case for not reusing existent infrastructure cause it works for all your needs and eventually both worlds would benefiting from it UI and java-sdk users cause you where extending it with additional capabilities they may also need) For the sake of simplicity, I guess it's best to start with SDK that has no dependencies whatsoever. so why won't you rewrite the engine in Java-script? your js-sdk eventually will be depending on it, this way you'll have control over it (and it's features) as well ;-) After all, there's no common dependency (aside from running Engine to provide XSD RSDL) between Java Python SDK too, if I understand correctly. In other words, building on top of something existing (just because we can do that) isn't always appropriate/flexible/efficient, it always depends on given context and requirements. it would be true, if your requirements would make existing infrastructure inappropriate. As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code). what do you mean by people should have full control over generated code? It's related to coupling from SDK perspective I mentioned above: the only way I can impose changes in my SDK is through supported customizations as you control original (Java SDK) sources if you need additional functionality in java-sdk, you could do the following: 1. submit a patch to java-sdk 2. build new java-sdk locally and use it along with new feature you've added 3. make UI depending on next version of java-sdk (which includes your new feature) we (and all other SW projects) doing that day by day in engine,api,etc. (as i mentioned this would also benefit java-sdk users with additional features they might find useful as well) (by people I meant JavaScript SDK developers) Full control means ability to change generated sources in whatever way desired, but assuming the idea of reusing
Re: [Engine-devel] Using REST API in web UI - review call summary
Hi Vojtech, First of all it was a good presentation of requirements + suggested solutions - well done!, few comments/questions inline. On 11/21/2013 11:18 PM, Vojtech Szocs wrote: Hi guys, this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something. -- Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael Gilad) A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us. not sure i buy this one :), this is the purpose of any sdk, including the one you about to write, people that will use it, will be coupling to it ... As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code). what do you mean by people should have full control over generated code? the purpose of code generation is to ease maintenance, i.e you/maintainer should not write the feature once it available in api, just run CodeGen and you'll get it for free, but this is zero control over code. -- Q: What about functionality currently used by oVirt UI but not supported by REST API? (asked by Einav) [For example, fetching VM entity over GWT RPC also returns related data such as Cluster name.] A: Based on discussion I've had with other colleagues after yesterday's review call, I don't think that separate support-like backend layer is a good idea. Instead, this is the kind of functionality that could be placed in oVirt.js library. Logical operations like get VMs and related data would be exposed through oVirt.js (callback-based) API and ultimately realized as multiple physical requests to REST API via JavaScript Binding. oVirt.js client would be completely oblivious to the fact that multiple physical requests are dispatched. In fact, since HTTP communication is asynchronous in nature, oVirt.js client wouldn't even notice any difference in terms of API consumption. This assumes JavaScript SDK would use callback-based (non-blocking) API instead of blocking one - after all, blocking API on top of non-blocking implementation sounds pretty much like leaky abstraction [1]. For example: sdk.getVmsWithExtraData( callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST API callbackFiredWhenAllDataIsReady // update client only when all data is ready ) actually this the main bottleneck in moving UI to work on top of REST, and most interesting/complex part of this project, you should think of very wise polling mechanism cause callbacks is a nice thing on paper, but behind the scene it all about polling: - the entity/s till action got accomplished - add to this updating different grids - running multiple actions - showing events - and obviously much more and don't forget that every polled entity should be marshalled from xml to the javascript entity so at the end, callbacks mechanism will be extremely CPU consuming. [1] http://en.wikipedia.org/wiki/Leaky_abstraction -- Last but not least, where to maintain JavaScript SDK projects: low-level JavaScript Binding + high-level oVirt.js library. I agree that conceptually both above mentioned projects should go into dedicated ovirt-engine-sdk-js git repository and have their own build/release process. However, for now, we're just making baby steps so let's keep things simple and prototype these projects as part of ovirt-engine git repository. ... we can complicate things anytime, but we should know that any complex system that works has inevitably evolved from simple system that works ... (quote from http://en.wikipedia.org/wiki/Gall%27s_law) Regards, Vojtech ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Using REST API in web UI - review call summary
be written by hand, things will get generated as soon as we have better idea how the end result should look like. i can understand that for the methods and maybe for populating the entities for the first few. the entities themselves, no point in hand coding - just generated them from the api.xsd. and once you decide how you want to fill them, not worth hand coding this - either json gives this out of the box, or should be generated as well. lets try to plan for lightweight entities while at it - the API has a mechanism for different level of details - maybe we need a custom level where the client specifies which fields they want back or something like that. Good idea! We should definitely think about the granularity of entities. I didn't know REST API supports different level of detail per entity, is there some documentation for this feature? currently it's about adding adding extra information (by supplying header [1]), this is driven by the properties that require extra query against the engine to fill them, obviously the default is [2] [1] All-Content: True [2] All-Content: False Since JavaScript is dynamic, one possible solution would be to let client define the entity structure (i.e. what data client needs) on the fly, during runtime :) we talked about this solution couple of years ago, but it was obvious that there is no real demand for it till UI moves to REST, btw it won't solve the problem where to fill UI entity you need combination of N REST entities, you still will have to perform N + 1 queries to API (maybe asking for entity with fewer details), - all it address is a capacity of the data being send. michael? Good luck, Itamar -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Using REST API in web UI - review call summary
On 11/22/2013 12:08 AM, Vojtech Szocs wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Einav Cohen eco...@redhat.com, Michael Pasternak mpast...@redhat.com Sent: Thursday, November 21, 2013 11:00:25 PM Subject: Re: Using REST API in web UI - review call summary On 11/21/2013 11:56 PM, Vojtech Szocs wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Vojtech Szocs vsz...@redhat.com, engine-devel engine-devel@ovirt.org Cc: Einav Cohen eco...@redhat.com Sent: Thursday, November 21, 2013 10:25:04 PM Subject: Re: Using REST API in web UI - review call summary On 11/21/2013 11:18 PM, Vojtech Szocs wrote: Hi guys, this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something. -- Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael Gilad) A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us. As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code). -- Q: What about functionality currently used by oVirt UI but not supported by REST API? (asked by Einav) [For example, fetching VM entity over GWT RPC also returns related data such as Cluster name.] A: Based on discussion I've had with other colleagues after yesterday's review call, I don't think that separate support-like backend layer is a good idea. Instead, this is the kind of functionality that could be placed in oVirt.js library. Logical operations like get VMs and related data would be exposed through oVirt.js (callback-based) API and ultimately realized as multiple physical requests to REST API via JavaScript Binding. oVirt.js client would be completely oblivious to the fact that multiple physical requests are dispatched. In fact, since HTTP communication is asynchronous in nature, oVirt.js client wouldn't even notice any difference in terms of API consumption. This assumes JavaScript SDK would use callback-based (non-blocking) API instead of blocking one - after all, blocking API on top of non-blocking implementation sounds pretty much like leaky abstraction [1]. For example: sdk.getVmsWithExtraData( callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST API callbackFiredWhenAllDataIsReady // update client only when all data is ready ) would this also resolve RunMultipleActions? Yes, I think so. There could be API to pass multiple actions and get notified when they complete. sounds like no reason to have RunMultipleQueries, although i'm still sure a single call to engine for multiple keys would be much more efficient than multiple async calls? (I understand we may not be able to model this). Efficiency-wise, yes, single call to get all data seems optimal. API-wise, I don't think it really matters from oVirt.js client perspective. We can proceed with simple (possibly inefficient) solution and improve as needed. We're making baby steps now.. [1] http://en.wikipedia.org/wiki/Leaky_abstraction -- Last but not least, where to maintain JavaScript SDK projects: low-level JavaScript Binding + high-level oVirt.js library. I agree that conceptually both above mentioned projects should go into dedicated ovirt-engine-sdk-js git repository and have their own build/release process. However, for now, we're just making baby steps so let's keep things simple and prototype these projects as part of ovirt-engine git repository. ... we can complicate things anytime, but we should know that any complex system that works has inevitably evolved from simple system that works ... (quote from http://en.wikipedia.org/wiki/Gall%27s_law) I think the entities should just be generated from the xsd. +1 The JavaScript Binding (aka low-level SDK) module should follow same concepts as existing Java SDK - generated entities decorated with operations to form
Re: [Engine-devel] When is ovirt-engine expected to start supporting wildfly?
On 11/18/2013 09:08 PM, Juan Hernandez wrote: On 11/17/2013 09:31 PM, Itamar Heim wrote: On 11/17/2013 06:56 PM, Mooli Tayer wrote: Thanks, Mooli Tayer. well, fedora 20 comes with wildfly (formerly JBoss AS8), so i think we should aim for 3.4 support on fedora 20 with wildfly, but preserving compatibility with AS7/EAP6 for other platforms. iirc, juan has been looking at wildfly compatibility implications - juan? At the moment I have identified two issues that will prevent us from running in WildFly 8: 1. WildFly 8 changed the default web container from JBoss Web (based on Tomcat) to Undertow. This shouldn't mean much changes in the application, as we don't use Tomcat specific APIs. But in means changes in the XML configuration that we use, including changes in how we configure connectors. 2. WildFly 8 comes with a new version of Resteasy, and we do use some Resteasy specific APIs. We will need minor changes in this area. it means RESTEasy breaks backward compatibility, can you elaborate on this a bit? thanks. These two aren't huge issues, but I think it isn't worth going deeper before there is a release of WildFly 8. Anyhow, one can always use JBoss AS 7 or EAP in Fedora 20, it is a matter of uncompressing the JBoss .zip in some directory and setting JBOSS_HOME=/that/directory in the engine configuration. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] move api from /api to /ovirt-engine/api
Hey Alon, i've noticed that ForwardServlet does not address URI parameters (such as query/matrix), i.e all destinations of this servlet will lack URI parameters been passed at source. On 11/06/2013 12:10 PM, Alon Bar-Lev wrote: Alon Bar-Lev has posted comments on this change. -- To view, visit http://gerrit.ovirt.org/20786 To unsubscribe, visit http://gerrit.ovirt.org/settings -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] move api from /api to /ovirt-engine/api
On 11/17/2013 01:23 PM, Alon Bar-Lev wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 17, 2013 1:20:58 PM Subject: move api from /api to /ovirt-engine/api Hey Alon, i've noticed that ForwardServlet does not address URI parameters (such as query/matrix), i.e all destinations of this servlet will lack URI parameters been passed at source. Thanks Alexander, can you please look at it? Michael... What do you mean URI parameters? just for me to be able to investigate this today? Do you mean query parameters? actually it didn't worked for me with matrix [2] so i assumed it's true for all URI params such as query [1], but it fine afaics, so it's only about [2] [1] http://localhost:8080/api/vms?search=name%3Dtest [2] http://localhost:8080/api/events;max=2 thanks. On 11/06/2013 12:10 PM, Alon Bar-Lev wrote: Alon Bar-Lev has posted comments on this change. -- To view, visit http://gerrit.ovirt.org/20786 To unsubscribe, visit http://gerrit.ovirt.org/settings -- Michael Pasternak RedHat, ENG-Virtualization RD -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-cli 3.4.0.1 released
- implement CLI invocation capabilities #895559 - expose api capabilities in cli #891227 - add the option to retrieve partial history #957499 - construct object using factory on update #950684 - added new state - UNAUTHORIZED - implement StateMachine - implement event driven messaging - implement visualization effects - history length was limited to 3000 records - raise CommandError on generic errors - implicitly disconnect on exit - ovirt-shell does not exit when using -f option #854519 - eliminate ambiguity by adding suffix -identifier to parent's options #1027281 - do not ask for credentials at /help in auto-connect mode #1026798 - list xxx --show all - output is not well formatted #890038 More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] RSDL breakage in oVirt upstream
Hi Shubhendu, On 11/14/2013 04:32 PM, Shubhendu Tripathi wrote: Hi Michael/Ori, There is payload breakage for RSDL in upstream oVirt. can you elaborate a bit? [1] works for me. [1] http://localhost:8080/api?rsdl This has happened somewhere between the patches gerrit.ovirt.org/#/c/20610/ and http://gerrit.ovirt.org/#/c/15409/. If I try to test out with patch http://gerrit.ovirt.org/#/c/15409/, it does break. Not sure what could be the issue. Tried debugging but not able to figure it out. Kindly help me on the same figuring out what could be the issue. Thanks and Regards, Shubhendu -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-cli 3.4.0.2 released
- added missing package descriptors in setup.py (required for easy_install deployment) More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-python 3.3.0.8-1 released
- to host.install() added ssh related arguments - to template added virtio_scsi.enabled - to vm added virtio_scsi.enabled - added ability to attach a disk snapshot to the virtual machine - to File class added 'content' field - Payload class now reuses Files instead of own PayloadFile collection more details can be found at [1]. [1] http://www.ovirt.org/Python-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.19-1 released
- to host.install() added ssh related arguments - to template added virtio_scsi.enabled - to vm added virtio_scsi.enabled - added ability to attach a disk snapshot to the virtual machine - to File class added 'content' field - Payload class now reuses Files instead of own PayloadFile collection more details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] 3.3.1 Release tracker
On 10/16/2013 08:30 AM, Sandro Bonazzola wrote: Hi, as you may know, we're planning to build oVirt 3.3.1 beta really soon and release 3.3.1 by the end of October. Ofer has created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1019391) for this release. Only 2 bugs considered blocking up to now are both in modified state, so we're in a good shape for 3.3.1 beta build. The following is a list of the bugs with target 3.3.1 or 3.3: Bug ID,Component,Summary,Status,Target Release,Assignee,Whiteboard 988354,ovirt-engine-webadmin,nic-network assignement not working for VM created from template with disk,POST,3.3,tjeli...@redhat.com,network 988067,ovirt-engine-sdk-java,Adding a cluster with incomplete version fails with exception,ASSIGNED,3.3,ol...@redhat.com,infra 904149,ovirt-engine-installer,engine-cleanup doesn't remove iso nfs export,ASSIGNED,3.3,d...@redhat.com,integration 1017267,ovirt-engine-core,Plaintext user passwords in async_tasks database,ASSIGNED,3.3.1,emes...@redhat.com,infra 987897,ovirt-engine-webadmin,VM - network interfaces subtab has a delayed refresh and displays wrong info for a while,NEW,3.3,nob...@fedoraproject.org,network 988016,ovirt-engine-webadmin,Specify custom MAC address in new/edit VNIC dialog for templates shouldn't exist,NEW,3.3,nob...@fedoraproject.org,network 987935,ovirt-engine-webadmin,[oVirt] [neutron] Networking plugin type doesn't reappear after test,NEW,3.3,lp...@redhat.com,network 988002,ovirt-engine-webadmin,[oVirt] [network] Add button shouldn't appear on specific network,NEW,3.3,lp...@redhat.com,network 987933,ovirt-engine-webadmin,[oVirt] [provider] Type list is not sorted in add dialog,NEW,3.3,lp...@redhat.com,network 987949,ovirt-engine-webadmin,[oVirt] [provider] It's seemingly possible to add a provider with the same name,NEW,3.3,lp...@redhat.com,network 987916,ovirt-engine-webadmin,[oVirt] [provider] Dialog doesn't update unless focus lost,NEW,3.3,lp...@redhat.com,network 987999,ovirt-engine-webadmin,[oVirt] [provider] Add button shouldn't appear on specific provider,NEW,3.3,lp...@redhat.com,network 987982,ovirt-engine-api,When adding a host through the REST API, the error message says that rootPassword is required, but the actual field name is root_password,NEW,3.3,mpast...@redhat.com,infra 987887,ovirt-engine-webadmin,Error message when reports portal is not installed,NEW,3.3,mta...@redhat.com,infra 915753,ovirt-engine-core,Deadlock detected during creation vms in pool,NEW,3.3,lara...@redhat.com,storage 987917,ovirt-engine-webadmin,[oVirt] [glance] API version not specified in provider dialog,NEW,3.3,fsimo...@redhat.com,storage 987832,vdsm,failed to add ovirtmgmt bridge when the host has static ip,NEW,3.3,lp...@redhat.com,network 991267,ovirt-node,[RFE] Add TUI information to log file.,POST,3.3,fdeut...@redhat.com, 1009899,ovirt-engine-core,exportDbSchema scripts generates output file with wrong name,POST,3.3.1,emes...@redhat.com,infra 990854,vdsm,Multiple Gateways: Upgrade VDSM to 3.3 must reconfigure networking on host,NEW,3.3,amul...@redhat.com,network Please set the target to 3.3.1 and add the bug to the tracker if you think that 3.3.1 should not be released without it fixed. the Bugzila bot changing it back to 3.3.0, any suggestions? Please also update the target to 3.3.2 or any next release for bugs that won't be in 3.3.1: it will ease gathering the blocking bugs for next releases. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] 3.3.1 Release tracker
On 10/16/2013 09:42 AM, Itamar Heim wrote: On 10/16/2013 04:17 AM, Michael Pasternak wrote: On 10/16/2013 08:30 AM, Sandro Bonazzola wrote: Hi, as you may know, we're planning to build oVirt 3.3.1 beta really soon and release 3.3.1 by the end of October. Ofer has created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1019391) for this release. Only 2 bugs considered blocking up to now are both in modified state, so we're in a good shape for 3.3.1 beta build. The following is a list of the bugs with target 3.3.1 or 3.3: Bug ID,Component,Summary,Status,Target Release,Assignee,Whiteboard 988354,ovirt-engine-webadmin,nic-network assignement not working for VM created from template with disk,POST,3.3,tjeli...@redhat.com,network 988067,ovirt-engine-sdk-java,Adding a cluster with incomplete version fails with exception,ASSIGNED,3.3,ol...@redhat.com,infra 904149,ovirt-engine-installer,engine-cleanup doesn't remove iso nfs export,ASSIGNED,3.3,d...@redhat.com,integration 1017267,ovirt-engine-core,Plaintext user passwords in async_tasks database,ASSIGNED,3.3.1,emes...@redhat.com,infra 987897,ovirt-engine-webadmin,VM - network interfaces subtab has a delayed refresh and displays wrong info for a while,NEW,3.3,nob...@fedoraproject.org,network 988016,ovirt-engine-webadmin,Specify custom MAC address in new/edit VNIC dialog for templates shouldn't exist,NEW,3.3,nob...@fedoraproject.org,network 987935,ovirt-engine-webadmin,[oVirt] [neutron] Networking plugin type doesn't reappear after test,NEW,3.3,lp...@redhat.com,network 988002,ovirt-engine-webadmin,[oVirt] [network] Add button shouldn't appear on specific network,NEW,3.3,lp...@redhat.com,network 987933,ovirt-engine-webadmin,[oVirt] [provider] Type list is not sorted in add dialog,NEW,3.3,lp...@redhat.com,network 987949,ovirt-engine-webadmin,[oVirt] [provider] It's seemingly possible to add a provider with the same name,NEW,3.3,lp...@redhat.com,network 987916,ovirt-engine-webadmin,[oVirt] [provider] Dialog doesn't update unless focus lost,NEW,3.3,lp...@redhat.com,network 987999,ovirt-engine-webadmin,[oVirt] [provider] Add button shouldn't appear on specific provider,NEW,3.3,lp...@redhat.com,network 987982,ovirt-engine-api,When adding a host through the REST API, the error message says that rootPassword is required, but the actual field name is root_password,NEW,3.3,mpast...@redhat.com,infra 987887,ovirt-engine-webadmin,Error message when reports portal is not installed,NEW,3.3,mta...@redhat.com,infra 915753,ovirt-engine-core,Deadlock detected during creation vms in pool,NEW,3.3,lara...@redhat.com,storage 987917,ovirt-engine-webadmin,[oVirt] [glance] API version not specified in provider dialog,NEW,3.3,fsimo...@redhat.com,storage 987832,vdsm,failed to add ovirtmgmt bridge when the host has static ip,NEW,3.3,lp...@redhat.com,network 991267,ovirt-node,[RFE] Add TUI information to log file.,POST,3.3,fdeut...@redhat.com, 1009899,ovirt-engine-core,exportDbSchema scripts generates output file with wrong name,POST,3.3.1,emes...@redhat.com,infra 990854,vdsm,Multiple Gateways: Upgrade VDSM to 3.3 must reconfigure networking on host,NEW,3.3,amul...@redhat.com,network Please set the target to 3.3.1 and add the bug to the tracker if you think that 3.3.1 should not be released without it fixed. the Bugzila bot changing it back to 3.3.0, any suggestions? for an ovirt bug? no, it was slight confusion, all good now, thanks. Please also update the target to 3.3.2 or any next release for bugs that won't be in 3.3.1: it will ease gathering the blocking bugs for next releases. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.18-1 released
More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-python 3.3.07-1 released
For more details see [1]. * note for pypi users: 3.3 sdk was renamed to ovirt-engine-sdk-python and hosted at [2], old repository [3] contains 3.2 artifacts only. [1] http://wiki.ovirt.org/Python-sdk-changelog [2] https://pypi.python.org/pypi/ovirt-engine-sdk-python [3] https://pypi.python.org/pypi/ovirt-engine-sdk -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-cli 3.3.0.5-1 released
More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] External events and flood rate
Eli, any reason for hardcoding this [1]? i'd move it to vdc_config. [1] Math.max(auditLogable.getEventFloodInSec(), 30) // Min duration for External Events is 30 sec On 09/19/2013 12:50 AM, Morrissey, Christopher wrote: Hi All, I’ve been working on submitting external events to oVirt through the REST API. It seems to be working in general, although it appears that, no matter what value I put for the flood rate in the event, only 1 or so events are allowed every 30 seconds. If I send another event during this time, I get an operation failed exception. Should the flood rate have any impact on this? Is there any way to allow my code to get an event through when needed or should I have a thread that shoots them off every 30 seconds if several occur too quickly together? -Chris *Chris Morrissey* Software Engineer NetApp Inc. 919.476.4428 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] what is the difference between origin/ovirt-engine-3.3.0 and origin/ovirt-engine-3.3 branches?
Thanks. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.17-1 released
More details can be found at [1], (note: change-log for [2] describing changes that took place from the last release 1.0.0.11-1) [1] http://www.ovirt.org/Java-sdk-changelog [2] 1.0.0.16 -1, 1.0.0.15 -1, 1.0.0.14 -1, 1.0.0.13 -1 -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Minor question concerning ServerException class
Hi Ricky, On 09/06/2013 09:31 PM, Hopper, Richard wrote: Hi Michael, While working with the ovirt-engine-sdk-java, I came across a small issue concerning the ServerException class. I wrote a utility to handle different types of exceptions (ServerException being one of those) for our plugin and found that ServerException does not meet GWT's specific serialization requirements due to the lack of a no-arg constructor of any visibility level. Is there an explicit reason for the lack of such a constructor? no, not at all, addressed at [1]. [1] http://gerrit.ovirt.org/#/c/18960/ thanks for reporting this. I was able to work around this, it's just a minor concern as far as GWT goes, and it could be useful to others if such types were serializable as well. Thanks, - Ricky -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Deprecating signatures/parameters in restapi (RSDL)
Hi All,
We have added the ability to deprecate signatures/parameters in RSDL,
you can mark parameter as deprecated in rsdl_metadata.yaml file this way [1],
please make sure you deprecating signatures/parameters which planned
to be non-maintained/removed.
thanks.
[1]
signature parameter:
===
vm.display.type--DEPRECATED: xs:string
url parameter:
=
max: {context: matrix, type: 'xs:int', value: 'max results', required: false,
deprecated: true}
header parameter:
=
Filter: {value: true|false, required: false, deprecated: true}
entire signature:
- mandatoryArguments: {}
optionalArguments: {action.vm.os.initRd: 'xs:string', action.vm.domain.name:
'xs:string',
action.vm.placement_policy.host.id|name: 'xs:string',
action.vm.placement_policy.affinity: 'xs:string',
action.async: 'xs:boolean', action.vm.os.kernel: 'xs:string',
action.grace_period.expiry: 'xs:long',
action.vm.display.type: 'xs:string', action.vm.stateless: 'xs:boolean',
action.vm.os.cmdline: 'xs:string',
action.vm.domain.user.username: 'xs:string', action.pause: 'xs:boolean',
action.vm.os.boot--COLLECTION: {boot.dev: 'xs:string'},
action.vm.domain.user.password: 'xs:string'}
deprecated: true
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Fwd: get certificate with SDK
Hi,
By default not all data returned in the object as some may be retrieved
only via dedicated query that may consume a lot of resources, therefore
we've added new concept called All-Content, in the native api you can pass
All-Content:True http header to see entire object, ovirt-engine-sdk-python
lacks of this capability (for vm specifically) due to a bug in api, this will
be addressed in the one of upcoming releases.
thanks for reporting.
Hi, all:
I can got all the VM’s information in
https://{ovirt-engine}/api/vms/{id}
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
typespice/type
address192.168.1.241/address
port5914/port
secure_port5915/secure_port
monitors1/monitors
allow_overridefalse/allow_override
*certificate*
*subjectO=thtfc.com,CN=allinone241.thtfc.com/subject*
*/certificate*
smartcard_enabledfalse/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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt.org and profiliing
On 07/23/2013 10:13 AM, Liran Zelkha wrote: Hi all As part of our effort to get profiling licenses to the ovirt contributors, we need to place an image of JProfiler (the chosen profiler) on the home page of ovirt.org http://ovirt.org. Anyone here knows who has the rights to do that? Dave? Thanks ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-cli 3.3.0.3-1 released
* Tue Jul 16 2013 Michael Pasternak mpast...@redhat.com - 3.3.0.3-1 - refactor connect command help - remove support for --password option #983713 - add option to define auto connect #918908 - exit command fails after disconnect from script #971285 - list permits format better error when not enough parameters #962472 - ovirt-shell should contain the hostname of the system #866319 - certificate file keys are not exposed in .ovirtshellrc #960983 - add brick operation fails from ovirt-shell #923169 More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.10-1 released
* Thu Jul 8 2013 Michael Pasternak mpast...@redhat.com - 1.0.0.10-1 - to cluster.add()/.update() added [trusted_service] property - implement Secure Socket Layer (SSL) host verification (CA certificate) - allow nullifying headers via passing NULL as header value More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] [DEV-DEPLOY] [ ERROR ] Failed to execute stage 'Environment customization': Command '/bin/systemctl' failed to execute
2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd
systemd.state:134 starting service firewalld
2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd
plugin.executeRaw:366 execute: ('/bin/systemctl', 'start',
'firewalld.service'), executable='Non
e', cwd='None', env=None
2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd
plugin.executeRaw:383 execute-result: ('/bin/systemctl', 'start',
'firewalld.service'), rc=1
2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd
plugin.execute:441 execute-output: ('/bin/systemctl', 'start',
'firewalld.service') stdout:
2013-07-04 14:31:23 DEBUG otopi.plugins.otopi.services.systemd
plugin.execute:446 execute-output: ('/bin/systemctl', 'start',
'firewalld.service') stderr:
Failed to issue method call: Access denied
2013-07-04 14:31:23 DEBUG otopi.context context._executeMethod:132 method
exception
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/otopi/context.py, line 122, in
_executeMethod
method['method']()
File /usr/share/otopi/plugins/otopi/network/firewalld.py, line 142, in
_customization
self._firewalld_version = self._get_firewalld_cmd_version()
File /usr/share/otopi/plugins/otopi/network/firewalld.py, line 63, in
_get_firewalld_cmd_version
state=True,
File /usr/share/otopi/plugins/otopi/services/systemd.py, line 138, in state
'start' if state else 'stop'
File /usr/share/otopi/plugins/otopi/services/systemd.py, line 77, in
_executeServiceCommand
raiseOnError=raiseOnError
File /usr/lib/python2.7/site-packages/otopi/plugin.py, line 451, in execute
command=args[0],
RuntimeError: Command '/bin/systemctl' failed to execute
2013-07-04 14:31:23 ERROR otopi.context context._executeMethod:141 Failed to
execute stage 'Environment customization': Command '/bin/systemctl' failed to
exec
ute
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] development installation issues
Hi Alon, On 06/30/2013 10:16 PM, Alon Bar-Lev wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Sunday, June 30, 2013 11:03:06 AM Subject: [Engine-devel] development installation issues does anyone faced this with new 'development installation'? Hi Michael, Can I have the output of: OTOPI_DEBUG=1 /home/mpastern/Coding/ovirt/ovirt-engine/bin/engine-setup-2 i made it work, it was my bad. thanks. Thanks! [mpastern@lpt21-f ovirt-engine]$ /home/mpastern/Coding/ovirt/ovirt-engine/bin/engine-setup-2 [ ERROR ] Failed to execute stage 'Booting': 5 [ INFO ] Stage: Initializing Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: Yes [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. Specifically, engine-setup-2 does not support upgrade from previous installations. [mpastern@lpt21-f ovirt-engine]$ -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] development installation issues
does anyone faced this with new 'development installation'? [mpastern@lpt21-f ovirt-engine]$ /home/mpastern/Coding/ovirt/ovirt-engine/bin/engine-setup-2 [ ERROR ] Failed to execute stage 'Booting': 5 [ INFO ] Stage: Initializing Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: Yes [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. Specifically, engine-setup-2 does not support upgrade from previous installations. [mpastern@lpt21-f ovirt-engine]$ -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] development installation issues
On 06/30/2013 11:43 AM, Moti Asayag wrote: On 06/30/2013 11:03 AM, Michael Pasternak wrote: does anyone faced this with new 'development installation'? [mpastern@lpt21-f ovirt-engine]$ /home/mpastern/Coding/ovirt/ovirt-engine/bin/engine-setup-2 [ ERROR ] Failed to execute stage 'Booting': 5 [ INFO ] Stage: Initializing Setup was run under unprivileged user this will produce development installation do you wish to proceed? (Yes, No) [No]: Yes [WARNING] engine-setup-2 is a technical preview, and yet to include all functionality that exists in legacy engine-setup. Specifically, engine-setup-2 does not support upgrade from previous installations. [mpastern@lpt21-f ovirt-engine]$ I had the same problem which was solved by upgrading to the latest otopi package. thanks moti, i'm on latest otopi (1b29c7f06a0b9b6715bd8340396c35ac29bf086c). -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Guid improvements
On 06/30/2013 12:20 PM, Liran Zelkha wrote: I checked such a solution using JProfiler. Creating the GUID object takes much more CPU cycles that checking the string in the Map. of course it is, but what is the size of map that you checked?, check on worst scenario, i.e map is full of all possible guids, also problem a bit different,java map has a load factor (which is usually 0.75), when ratio increases beyond the load factor, occurs proses called re-hash so that the hash table will double amount of buckets. what can produce a cpu spikes (though it should not happen too often), to avoid this the initial capacity should be greater than the maximum number of entries / the load factor, and this is a huge map so basically this is a tradeoff between time and space costs against the new guid generation. On Jun 30, 2013, at 12:06 PM, Michael Pasternak wrote: On 06/30/2013 11:37 AM, Liran Zelkha wrote: Great news. Allon - please note that GUID is being recreated from String by both DB calls and by data received from VDSM. It is VERY useful to cache Guid String--Guid, and not just Empty GUID. However, as the Guid class runs in GWT as well, you can't use Infinispan and you're limited in the HashMap implementations you can use. Personally, I don't think it's a memory leak, as GUID number in the system are finite and not too large. it's large, it's 128-bit random number, it's not about memory leaking, but cpu cost, as you'll face a lot of rehash'ings in the map, i'm not even sure that using indexing in the map can help, worth checking. What do you think? Want to add it to your patch? On Jun 30, 2013, at 11:13 AM, Yair Zaslavsky wrote: Well done, should have been done ages ago :) Now, for the painful rebase of async_task_mgr changes :) - Original Message - From: Allon Mureinik amure...@redhat.com To: engine-devel engine-devel@ovirt.org, Barak Azulay bazu...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com, Michael Pasternak mpast...@redhat.com, Tal Nisan tni...@redhat.com, Ayal Baron aba...@redhat.com Sent: Sunday, June 30, 2013 11:11:30 AM Subject: Guid improvements Hi all, I just merged a couple of improvements to the [N]Guid class [1] to improve it's performance both CPU-wise and memory-wise, based on a set of benchmarks presented by Liran. What this patchset achieves: 1. Clean up the code, so it's easier to understand and use 2. Eliminate the inflation in the memory foot print caused by the getValue() method 3. Eliminate all the heavy calls to UUID.fromString when creating a new/empty Guid instance as a default value 4. Note that the cleanups proposed in (1) will have minor performance benefits (e.g., eliminating useless conditional statements), but I doubt this would be anything to write home about. From a developer's perspective, here's what changed: 1. No more NGuid, just Guid. Both static methods to create a Guid from String still exist, and are named createGuidFromString and createGuidFromStringDefaultEmpty. 2. [N]Guid.getValue() was removed, it's no longer needed after (1) was implemented 3. The Guid() constructor was made private, as it forced a redundant call to UUID.fromString(String). If you need an empty Guid instance, just use Guid.Empty 4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was used for redundant calls to UUID.fromString. If you really, REALLY, need it, just call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a String. 5. All sorts of ways to transform Strings to Guids were removed. If you have a literal you trust, just use new Guid(String). If you suspect it may be null, use Guid.createGuidFromString[DefaultEmpty] 6. NewGuid is now called newGuid. We're in Java, not C# :-) Many thanks to everyone who reviewed this patchset. You guys rock! Regards, Allon [1] http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:guid-cleanup,n,z ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Guid improvements
On 06/30/2013 12:45 PM, Liran Zelkha wrote: All is true. But average UUID.fromString execution is 1675us, and HashMap.put is 78us - so the benefit is clear when we're talking on 100K executions for 10minutes... even with synchronization? what about ConcurrentHashMap? On Sun, Jun 30, 2013 at 12:44 PM, Michael Pasternak mpast...@redhat.com mailto:mpast...@redhat.com wrote: On 06/30/2013 12:20 PM, Liran Zelkha wrote: I checked such a solution using JProfiler. Creating the GUID object takes much more CPU cycles that checking the string in the Map. of course it is, but what is the size of map that you checked?, check on worst scenario, i.e map is full of all possible guids, also problem a bit different,java map has a load factor (which is usually 0.75), when ratio increases beyond the load factor, occurs proses called re-hash so that the hash table will double amount of buckets. what can produce a cpu spikes (though it should not happen too often), to avoid this the initial capacity should be greater than the maximum number of entries / the load factor, and this is a huge map so basically this is a tradeoff between time and space costs against the new guid generation. On Jun 30, 2013, at 12:06 PM, Michael Pasternak wrote: On 06/30/2013 11:37 AM, Liran Zelkha wrote: Great news. Allon - please note that GUID is being recreated from String by both DB calls and by data received from VDSM. It is VERY useful to cache Guid String--Guid, and not just Empty GUID. However, as the Guid class runs in GWT as well, you can't use Infinispan and you're limited in the HashMap implementations you can use. Personally, I don't think it's a memory leak, as GUID number in the system are finite and not too large. it's large, it's 128-bit random number, it's not about memory leaking, but cpu cost, as you'll face a lot of rehash'ings in the map, i'm not even sure that using indexing in the map can help, worth checking. What do you think? Want to add it to your patch? On Jun 30, 2013, at 11:13 AM, Yair Zaslavsky wrote: Well done, should have been done ages ago :) Now, for the painful rebase of async_task_mgr changes :) - Original Message - From: Allon Mureinik amure...@redhat.com mailto:amure...@redhat.com To: engine-devel engine-devel@ovirt.org mailto:engine-devel@ovirt.org, Barak Azulay bazu...@redhat.com mailto:bazu...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com mailto:yzasl...@redhat.com, Michael Pasternak mpast...@redhat.com mailto:mpast...@redhat.com, Tal Nisan tni...@redhat.com mailto:tni...@redhat.com, Ayal Baron aba...@redhat.com mailto:aba...@redhat.com Sent: Sunday, June 30, 2013 11:11:30 AM Subject: Guid improvements Hi all, I just merged a couple of improvements to the [N]Guid class [1] to improve it's performance both CPU-wise and memory-wise, based on a set of benchmarks presented by Liran. What this patchset achieves: 1. Clean up the code, so it's easier to understand and use 2. Eliminate the inflation in the memory foot print caused by the getValue() method 3. Eliminate all the heavy calls to UUID.fromString when creating a new/empty Guid instance as a default value 4. Note that the cleanups proposed in (1) will have minor performance benefits (e.g., eliminating useless conditional statements), but I doubt this would be anything to write home about. From a developer's perspective, here's what changed: 1. No more NGuid, just Guid. Both static methods to create a Guid from String still exist, and are named createGuidFromString and createGuidFromStringDefaultEmpty. 2. [N]Guid.getValue() was removed, it's no longer needed after (1) was implemented 3. The Guid() constructor was made private, as it forced a redundant call to UUID.fromString(String). If you need an empty Guid instance, just use Guid.Empty 4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was used for redundant calls to UUID.fromString. If you really, REALLY, need it, just call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a String. 5. All sorts of ways to transform Strings to Guids were removed. If you have a literal you trust, just use new Guid(String). If you suspect it may be null, use Guid.createGuidFromString[DefaultEmpty] 6. NewGuid is now called newGuid. We're in Java, not C# :-) Many thanks to everyone who reviewed this patchset. You guys rock! Regards, Allon [1] http://gerrit.ovirt.org/#/q/project:ovirt
Re: [Engine-devel] Guid improvements
On 06/30/2013 01:08 PM, Liran Zelkha wrote: Why synchronization? No need for it. Worst case scenario a put (which should be much less common then get) will occur twice on the same key. why assuming a best not worst scenario? don't forget that every new insertion requires collision resolution which is triggers .equals() on the GUID. On Jun 30, 2013, at 1:00 PM, Michael Pasternak wrote: On 06/30/2013 12:45 PM, Liran Zelkha wrote: All is true. But average UUID.fromString execution is 1675us, and HashMap.put is 78us - so the benefit is clear when we're talking on 100K executions for 10minutes... even with synchronization? what about ConcurrentHashMap? On Sun, Jun 30, 2013 at 12:44 PM, Michael Pasternak mpast...@redhat.com mailto:mpast...@redhat.com wrote: On 06/30/2013 12:20 PM, Liran Zelkha wrote: I checked such a solution using JProfiler. Creating the GUID object takes much more CPU cycles that checking the string in the Map. of course it is, but what is the size of map that you checked?, check on worst scenario, i.e map is full of all possible guids, also problem a bit different,java map has a load factor (which is usually 0.75), when ratio increases beyond the load factor, occurs proses called re-hash so that the hash table will double amount of buckets. what can produce a cpu spikes (though it should not happen too often), to avoid this the initial capacity should be greater than the maximum number of entries / the load factor, and this is a huge map so basically this is a tradeoff between time and space costs against the new guid generation. On Jun 30, 2013, at 12:06 PM, Michael Pasternak wrote: On 06/30/2013 11:37 AM, Liran Zelkha wrote: Great news. Allon - please note that GUID is being recreated from String by both DB calls and by data received from VDSM. It is VERY useful to cache Guid String--Guid, and not just Empty GUID. However, as the Guid class runs in GWT as well, you can't use Infinispan and you're limited in the HashMap implementations you can use. Personally, I don't think it's a memory leak, as GUID number in the system are finite and not too large. it's large, it's 128-bit random number, it's not about memory leaking, but cpu cost, as you'll face a lot of rehash'ings in the map, i'm not even sure that using indexing in the map can help, worth checking. What do you think? Want to add it to your patch? On Jun 30, 2013, at 11:13 AM, Yair Zaslavsky wrote: Well done, should have been done ages ago :) Now, for the painful rebase of async_task_mgr changes :) - Original Message - From: Allon Mureinik amure...@redhat.com mailto:amure...@redhat.com To: engine-devel engine-devel@ovirt.org mailto:engine-devel@ovirt.org, Barak Azulay bazu...@redhat.com mailto:bazu...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com mailto:yzasl...@redhat.com, Michael Pasternak mpast...@redhat.com mailto:mpast...@redhat.com, Tal Nisan tni...@redhat.com mailto:tni...@redhat.com, Ayal Baron aba...@redhat.com mailto:aba...@redhat.com Sent: Sunday, June 30, 2013 11:11:30 AM Subject: Guid improvements Hi all, I just merged a couple of improvements to the [N]Guid class [1] to improve it's performance both CPU-wise and memory-wise, based on a set of benchmarks presented by Liran. What this patchset achieves: 1. Clean up the code, so it's easier to understand and use 2. Eliminate the inflation in the memory foot print caused by the getValue() method 3. Eliminate all the heavy calls to UUID.fromString when creating a new/empty Guid instance as a default value 4. Note that the cleanups proposed in (1) will have minor performance benefits (e.g., eliminating useless conditional statements), but I doubt this would be anything to write home about. From a developer's perspective, here's what changed: 1. No more NGuid, just Guid. Both static methods to create a Guid from String still exist, and are named createGuidFromString and createGuidFromStringDefaultEmpty. 2. [N]Guid.getValue() was removed, it's no longer needed after (1) was implemented 3. The Guid() constructor was made private, as it forced a redundant call to UUID.fromString(String). If you need an empty Guid instance, just use Guid.Empty 4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was used for redundant calls to UUID.fromString. If you really, REALLY, need it, just call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a String. 5. All sorts of ways to transform Strings to Guids were removed. If you have a literal you trust, just use new Guid(String). If you suspect it may be null, use Guid.createGuidFromString[DefaultEmpty] 6. NewGuid is now called newGuid. We're in Java, not C# :-) Many thanks to everyone who reviewed this patchset. You guys rock! Regards, Allon [1] http://gerrit.ovirt.org/#/q/project:ovirt-engine
Re: [Engine-devel] Guid improvements
On 06/30/2013 01:15 PM, Michael Pasternak wrote: On 06/30/2013 01:08 PM, Liran Zelkha wrote: Why synchronization? No need for it. Worst case scenario a put (which should be much less common then get) will occur twice on the same key. why assuming a best not worst scenario? don't forget that every new insertion requires collision resolution which is triggers .equals() on the GUID. Liran, don't get me wrong, i'm not against the caching in general, obviously reads writes so actually i'm all with you, just we're going to significantly enlarge a memory footprint so i just want to make sure we're on a right track for the worst scenario where engine runs for ages and hashmap reaches it's load factor. On Jun 30, 2013, at 1:00 PM, Michael Pasternak wrote: On 06/30/2013 12:45 PM, Liran Zelkha wrote: All is true. But average UUID.fromString execution is 1675us, and HashMap.put is 78us - so the benefit is clear when we're talking on 100K executions for 10minutes... even with synchronization? what about ConcurrentHashMap? On Sun, Jun 30, 2013 at 12:44 PM, Michael Pasternak mpast...@redhat.com mailto:mpast...@redhat.com wrote: On 06/30/2013 12:20 PM, Liran Zelkha wrote: I checked such a solution using JProfiler. Creating the GUID object takes much more CPU cycles that checking the string in the Map. of course it is, but what is the size of map that you checked?, check on worst scenario, i.e map is full of all possible guids, also problem a bit different,java map has a load factor (which is usually 0.75), when ratio increases beyond the load factor, occurs proses called re-hash so that the hash table will double amount of buckets. what can produce a cpu spikes (though it should not happen too often), to avoid this the initial capacity should be greater than the maximum number of entries / the load factor, and this is a huge map so basically this is a tradeoff between time and space costs against the new guid generation. On Jun 30, 2013, at 12:06 PM, Michael Pasternak wrote: On 06/30/2013 11:37 AM, Liran Zelkha wrote: Great news. Allon - please note that GUID is being recreated from String by both DB calls and by data received from VDSM. It is VERY useful to cache Guid String--Guid, and not just Empty GUID. However, as the Guid class runs in GWT as well, you can't use Infinispan and you're limited in the HashMap implementations you can use. Personally, I don't think it's a memory leak, as GUID number in the system are finite and not too large. it's large, it's 128-bit random number, it's not about memory leaking, but cpu cost, as you'll face a lot of rehash'ings in the map, i'm not even sure that using indexing in the map can help, worth checking. What do you think? Want to add it to your patch? On Jun 30, 2013, at 11:13 AM, Yair Zaslavsky wrote: Well done, should have been done ages ago :) Now, for the painful rebase of async_task_mgr changes :) - Original Message - From: Allon Mureinik amure...@redhat.com mailto:amure...@redhat.com To: engine-devel engine-devel@ovirt.org mailto:engine-devel@ovirt.org, Barak Azulay bazu...@redhat.com mailto:bazu...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com mailto:yzasl...@redhat.com, Michael Pasternak mpast...@redhat.com mailto:mpast...@redhat.com, Tal Nisan tni...@redhat.com mailto:tni...@redhat.com, Ayal Baron aba...@redhat.com mailto:aba...@redhat.com Sent: Sunday, June 30, 2013 11:11:30 AM Subject: Guid improvements Hi all, I just merged a couple of improvements to the [N]Guid class [1] to improve it's performance both CPU-wise and memory-wise, based on a set of benchmarks presented by Liran. What this patchset achieves: 1. Clean up the code, so it's easier to understand and use 2. Eliminate the inflation in the memory foot print caused by the getValue() method 3. Eliminate all the heavy calls to UUID.fromString when creating a new/empty Guid instance as a default value 4. Note that the cleanups proposed in (1) will have minor performance benefits (e.g., eliminating useless conditional statements), but I doubt this would be anything to write home about. From a developer's perspective, here's what changed: 1. No more NGuid, just Guid. Both static methods to create a Guid from String still exist, and are named createGuidFromString and createGuidFromStringDefaultEmpty. 2. [N]Guid.getValue() was removed, it's no longer needed after (1) was implemented 3. The Guid() constructor was made private, as it forced a redundant call to UUID.fromString(String). If you need an empty Guid instance, just use Guid.Empty 4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was used for redundant calls to UUID.fromString. If you really, REALLY, need it, just call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a String. 5. All sorts of ways to transform
[Engine-devel] ovirt-engine-sdk-java 1.0.0.9-1 released
* Fri Jun 28 2013 Michael Pasternak mpast...@redhat.com - 1.0.0.9-1 - configure log4j programmatically More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt-engine-sdk
On 06/25/2013 04:23 AM, wlbleaboy@126 wrote:
connect to ovirt-engine via ovirt-engine-sdk is using sdk like this:
Api = API('https://{ovirt-engine}', 'user@domain', 'password', None, None,
'ca.crt', filter=True)
this function running more than 10 seconds.
this is very odd,
1. please run GET query with curl against a /api and see how much time it takes
to get a response?
2. what is the machine that you running your sdk code at? the ovirt-engine
machine?
3. please check CPU, I/O, memory load on the machine where your sdk code runs
4. please add debug=True to API() initialization and send me the output
And Userportal is faster than it.
sdk is not the same as UserPortal, it runs on a different platform,
uses different technology to communicate with the server, on initialization it
creates a pool
of connections to be used + verifying ca cert + maps python-xml at runtime,
etc.,
but any of these should not be time consuming in a way you describing.
-Original Message-
From: Michael Pasternak [mailto:mpast...@redhat.com]
Sent: Monday, June 24, 2013 9:42 PM
To: wlbleaboy@126
Cc: engine-devel@ovirt.org
Subject: Re: [Engine-devel] ovirt-engine-sdk
On 06/24/2013 12:34 PM, wlbleaboy@126 wrote:
Hi, all:
I found when I connect to ovirt-engine via ovirt-engine-sdk is
slowly
than connect to engine via UserPortal, could anyone explain the reason.
- what do you mean by saying connect to ovirt-engine via ovirt-engine-sdk?
- you comparing two different things, sdk != userportal
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.8-1 released
* Thu Jun 25 2013 Michael Pasternak mpast...@redhat.com - 1.0.0.8-1 - implement support for the /capabilities resource - implement basic debugging capabilities - added VMApplications sub-collection - to datacenter added new field [comment] - to disk added [sgio] field to enable|disable filtering for the ScsiGenericIo - to StorageDomain.delete() added storagedomain.host.id|name - to VmPool added MaxUserVMs property - to cluster.update() added [cluster.data_center.id] - to host.fence() added action.fence_type - to storagedomain.delete() added [storagedomain.format] - to nic added [nic.custom_properties.custom_property] - to vm.add(), vm.update() added [vm.memory_policy.guaranteed] More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt-engine-sdk
On 06/24/2013 12:34 PM, wlbleaboy@126 wrote: Hi, all: I found when I connect to ovirt-engine via ovirt-engine-sdk is slowly than connect to engine via UserPortal, could anyone explain the reason. - what do you mean by saying connect to ovirt-engine via ovirt-engine-sdk? - you comparing two different things, sdk != userportal ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] about session_timeout in API
On 06/08/2013 10:34 AM, wlbleaboy@126 wrote: Hi, all: What’s meaning of session_timeout in ovirt-engine-sdk-python API, [@param session_timeout: authentication session timeout (if persistent_auth is enabled)] p.s you can find this in __doc__ under API.__init__ ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] about session_timeout in API
On 06/09/2013 10:30 AM, wlbleaboy@126 wrote: Yes, I saw that you assigned, because I'm not familiar with python, so , I want to know that's It's specific meaning, what's the meaning of that argument used for API.__init__() By default sdk uses persistent authentication [1], and to achieve that used http session, the default for the session idle state is 2 hours (IIRC) after that, if you'll try to perform any action, it will fail with 401 error, by changing session_timeout in the SDK, you can define your own session timeout. [1] you can switch off persistent authentication by making 'persistent_auth=False', but please note that then authentication will take place per sdk request. -Original Message- From: Michael Pasternak [mailto:mpast...@redhat.com] Sent: Sunday, June 09, 2013 3:06 PM To: wlbleaboy@126 Cc: engine-devel@ovirt.org Subject: Re: [Engine-devel] about session_timeout in API On 06/08/2013 10:34 AM, wlbleaboy@126 wrote: Hi, all: What's meaning of session_timeout in ovirt-engine-sdk-python API, [@param session_timeout: authentication session timeout (if persistent_auth is enabled)] p.s you can find this in __doc__ under API.__init__ ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] about govirt
On 06/05/2013 09:43 AM, wlbleaboy@126 wrote: Hi, Itamar Heim: I used ovirit-engine-sdk-python to connect ovirt-engine and get vms It's about 20 seconds, so I felt it's slow. 20 seconds? How much VMs did you fetched?, How do you measure the time?, can i see your code? I have build govirt success, but how can I use it, I give REST_URI=https://192.168.1.201/api;, and proxy = ovirt_proxy_new(REST_URI) always return NULL; -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Wednesday, June 05, 2013 5:29 AM To: wlbleaboy@126 Cc: cferg...@redhat.com; engine-devel@ovirt.org; Michael Pasternak Subject: Re: [Engine-devel] about govirt On 06/04/2013 01:23 PM, wlbleaboy@126 wrote: Hi, cfergeau: Recently, I do something about ovirt-engine-sdk, I just want to console a vm via sdk, but I found the sdk implemented by python is so slowly, so I want to build a simple sdk use C to do that, Can you please share more info on what do you mean by slow? Thanks, Itamar before I do it, I found the code govirt you worte, I felt luckly, you had do that. So I got the code, but when I build it on ubuntu, it's failed I used autogen.sh , but got the error message like: configure: error: Package requirements (rest-0.7 = 0.7.13) were not met: No package 'rest-0.7' found Because I didn't familiar with autogen and configure, such gnu build tools, ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] about govirt
On 06/05/2013 10:51 AM, wlbleaboy@126 wrote:
I build a local sdk base on ovirt-engine-sdk-python, I do that like this:
First, I created a python file naked wrap.py, in wrap.py I have
a class naked CWrap , CWrap have some interface for get vm's information
and connect to ovirt-enginelike:
login(), getVmName(), getVmId(), getVmPort(), getVmTicket() etc.
second, I created a C file named engine-sdk.c, in this file I also implement
some interface like getVmName() etc. but in this file, all the function is
call python module like
PyObject *pyVmId;
char *vmId;
pyVmId = PyObject_CallMethod(pInstant, getVmId, (i), vmIndex);
if(pyVmId == NULL)
{
DBG(ERROR:Call py Method getVmDisplayType is failed!\n);
return NULL;
}
vmId = PyString_AsString(pyVmId);
so, the local sdk is used for a client(C/S ) implemented by gtk.
Every time, when I use my client login and get vms's information, it's about
10~20 seconds.
i'm confused, are you mixing python with c? so what is CWrap/wrap.py from
python?
can you post theirs code?
-Original Message-
From: Michael Pasternak [mailto:mpast...@redhat.com]
Sent: Wednesday, June 05, 2013 3:14 PM
To: wlbleaboy@126
Cc: 'Itamar Heim'; cferg...@redhat.com; engine-devel@ovirt.org
Subject: Re: [Engine-devel] about govirt
On 06/05/2013 09:43 AM, wlbleaboy@126 wrote:
Hi, Itamar Heim:
I used ovirit-engine-sdk-python to connect ovirt-engine and get vms
It's about 20 seconds, so I felt it's slow.
20 seconds? How much VMs did you fetched?, How do you measure the time?, can
i see your code?
I have build govirt success, but how can I use it, I give
REST_URI=https://192.168.1.201/api;,
and proxy = ovirt_proxy_new(REST_URI) always return NULL;
-Original Message-
From: Itamar Heim [mailto:ih...@redhat.com]
Sent: Wednesday, June 05, 2013 5:29 AM
To: wlbleaboy@126
Cc: cferg...@redhat.com; engine-devel@ovirt.org; Michael Pasternak
Subject: Re: [Engine-devel] about govirt
On 06/04/2013 01:23 PM, wlbleaboy@126 wrote:
Hi, cfergeau:
Recently, I do something about ovirt-engine-sdk, I just want to
console a vm via sdk, but I found the sdk implemented by python is
so slowly, so I want to build a simple sdk use C to do that,
Can you please share more info on what do you mean by slow?
Thanks,
Itamar
before I do it, I found the code govirt you worte, I felt
luckly, you
had do that. So I got the code, but when I build it on ubuntu, it's
failed
I used autogen.sh , but got the error message
like:
configure: error: Package requirements (rest-0.7 = 0.7.13)
were not met:
No package 'rest-0.7' found
Because I didn't familiar with autogen and configure, such gnu
build tools,
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.7-1 released
- updated storagedomain add()/update() docs - updated tag update() docs - enabled correct generation of Boolean getters/setters to enable Bean Introspection apis (bollean getters will be prefixed with getX()) - fixed docs for GlusterBricks add|update - fixed docs for add|update Tag - added [network.usages.usage] to ClusterNetworks - in add TemplateNICs, network.id|name is no longer mandatory - StorageDomainVM can be removed asynchronously now - removed DataCenterQuota.add|delete (yet not supported) More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] How to get the number of all running VMs
On 05/27/2013 04:35 PM, Edgar wrote: Hi All, I need to get the number of All running VMs of the oVirt-engine. My thought is first get all hosts with up status and then traverse each host and count the VM with state Running . you can use ovirt-shell (3.3+) for this, just run 'summary' command: [oVirt shell (connected)]# summary hosts-active : 0 hosts-total : 0 storage_domains-active: 0 storage_domains-total : 0 users-active : 1 users-total : 1 vms-active: 0 vms-total : 3 Does this method feasible,and is there any easier way to count the running VMs of oVirt-engine? Best Regards ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] about ovirt-shell
On 05/22/2013 09:59 AM, wlbleaboy@126 wrote: Hi all: When I connect to ovirt-engine use ovirt-shell like this: It’s failed, I don’t know why. The ovirt-engine is build and deployed by myself and base ovirt-engine 3.2 But when I connect to the ovirt-engine use rmp installed, ovirt-shell work well. ++ Welcome to oVirt shell ++ [oVirt shell (disconnected)]# connect --url http://192.168.1.201 --user admin@internal --password 11 error: [ERROR]::No response returned from server. If you're using HTTP protocol against a SSL secured server, then try using HTTPS instead. the problem exactly as stated in this error message, e.g you're using http protocol in your url, while server running over ssl, just do --url https://192.168.1.201 [oVirt shell (disconnected)]# ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
Hi Vojtech, On 05/14/2013 05:13 PM, Vojtech Szocs wrote: Hi guys, I followed this thread, there are some interesting points, sending my comments below. First of all, I understand that REST API should follow common REST principles, and implement additional features (such as authentication) seamlessly on top of these principles, if possible. It's just that sometimes, especially in JavaScript/HTML world, there are known issues (limitations) for which a good REST API implementation should provide reasonable workarounds. For me, this means two things: (a) issue with browser-specific HTTP 'Authorization' header handling for JavaScript apps [https://bugzilla.redhat.com/958861] (b) issue with browser-specific cookie handling restriction for JavaScript apps [*] this is to avoid cross-site/cross-subdomain cookie attacks. [*] long story short: JavaScript app hosted from /myapp/index.html cannot access cookies for say /api path, only for /myapp path, i.e. cookies are under control of browser and not JavaScript app, more details: http://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path Both issues written above have something (very important) in common: browser-specific + browser having control (over 'Authorization' header / cookies) instead of JavaScript app.. none of these two is a REST specific, those just two (another) authentication methods, and there are plenty of others that can be used. @Michael: is there some RFE/document for your URI based authentication proposal? Assuming JSESSIONID could be passed via URI, we could use this as a workaround for browser-specific cookie handling restriction. In practice, this would mean any JavaScript (WebAdmin itself, UI Plugin, any other web app) could talk to REST API without relying on cookies entirely. Even better, if we could pass auth credentials via URI, we could talk to REST API without relying on HTTP 'Authorization' header entirely. in order to avoid link sharing problems and fixation attacks, for this pattern to work, we will have to regenerating SID on each request, this approach will give us a better view on given plugin activity via web server/proxy logs/etc., but doubt if it worth the effort, cause same may be tuned on the engine side, i guess it's just another way to do the same. Also, I'm not strictly against HTTP Basic Auth used in REST API, I just pointed out some of its drawbacks (a while ago). Originally, I proposed to support alternative (extra) auth scheme that is better and more secure, but in the end, I guess we should settle for one reasonably good auth scheme. I looked at SPNEGO [http://en.wikipedia.org/wiki/SPNEGO] - it looks interesting, basically a protocol for negotiating specific auth scheme based on what server supports, the question is if we really need to support multiple auth schemes, or just one that is reasonably good. we may have to support kerberos auth in future. - SPNEGO/OAuth are good candidates for this. One auth scheme I really like is [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html] - basically preventing password from being sent over the network entirely, which is always a good thing. The disadvantage is that the server has to know password (secret key) in plain-text for the given user, in order to re-produce compare signature (hash) of relevant request information. and this is a giant cons. On the other hand, Gerrit REST API uses HTTP Digest Auth [https://gerrit-review.googlesource.com/Documentation/rest-api.html#_protocol_details] but IMHO Digest Auth is over-complicated protocol, most importantly its too complex for clients to implement. and this why we having this discussion, currently options are: 1. adapt session based authentication 2. introduce new concept I'd vote for auth scheme that doesn't contradict general REST principles but is reasonably good (easy secure). One thing is the auth protocol itself (HTTP Basic Auth), another is how auth-related information is transmitted between client and server (HTTP 'Authorization' header, JSESSIONID cookie) - for now I'd just proposed to revisit the auth-related info transmission part.. i tend to agree on this, the most simple way of supporting browsers in this stage is among cookie, obtaining SID from the headers. Regards, Vojtech -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
On 05/16/2013 08:58 PM, Alon Bar-Lev wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Vojtech Szocs vsz...@redhat.com, Einav Cohen eco...@redhat.com, Itamar Heim ih...@redhat.com, Juan Hernandez jhern...@redhat.com, engine-devel engine-devel@ovirt.org, Barak Azulay bazu...@redhat.com Sent: Thursday, May 9, 2013 12:27:35 PM Subject: Re: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874 On 05/07/2013 07:44 PM, Alon Bar-Lev wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Alon Bar-Lev alo...@redhat.com, Vojtech Szocs vsz...@redhat.com, Einav Cohen eco...@redhat.com, Itamar Heim ih...@redhat.com, Juan Hernandez jhern...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Monday, May 6, 2013 9:46:31 AM Subject: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874 https://bugzilla.redhat.com/show_bug.cgi?id=958874 Hi Alon, (In reply to comment #2) Regardless of this specific RFE I would like to write that I don't like the REST API session mechanism [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it relays on cookies and not explicit API interaction. authentication in RESTful application is a matter of debate, it can be achieved in various ways, but session + cookie auth. method is very common and usually effective, it's biggest disadvantage is that it's not exactly RESfull cause client have to maintain (story) the cookie and not the server (but i wouldn't call it an issue at all), besides that it's works perfectly well from the REST PoV, also some may say that cookies are not strong enough and OAuth for instance should be used instead, but this is a different story cause in our case, cookie are for the clients (not browsers [1]) that can store them in a secure way or even not to store at all (in-memory cookie). [1] another disadvantage is that webbrowsers not able to access cookie namespace, but lately i've suggested URI based authentication [2] to support web browsers as well. [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html the biggest advantage of the cookie is a session expiration that maintained by the server and abstracted from the client what is much better from security PoV than standard authentication mechanisms such as HTTP basic auth for instance which can be potentially cached. Expiration is always managed by server side, regardless the cookie vs ticket debate. I would have expected a 'ticket' to be retrieved and that 'ticket' to be disconnected from the application server objects. Although we can refer the 'cookie' as a ticket, however the requirement to parse it should not be required, there be a conflict between two separate applications running on same server, and there may be a problem to transfer credentials between servers. well, this is not exactly correct: 1. client desn't have to decode/parse the cookie and pass credentials, all it need is just to store the cookie and pass it as is to server on every request. You just described what cookies are. And if I understand we want better control of application authentication, disconnected from 'default browser behavior'. 2. conflict between two separate applications running on same server? different cookie uses different domain path by spec., can you pls explain what do you mean by this? If you call the cookie JSESSIONID different applications cannot live under same path, this what for cookie has a path attribute, but it can create a bit of confusion indeed, but you not talking with more than one application in same time right ?!, i.e container/client fetches the JSESSIONID cookie from the specific request/response, I am taking exactly on that... good on demand authentication mechanism should allow concurrent multiple users processing. This is what API is all about. works like a charm with today's authentication methods. Of course this can somehow achieved via cookie, but doing so is so complex that one probably wish to use plain header, complex only for browsers. or worse case a cookie that does not conflict with the application that loaded the static content. so i'm not sure how possibly client can get in reply two cookies with a same name (even if all applications are using same cookie) Because of this, authorization mechanism should not use cookies. ?, sorry, you lost me. If we modify authentication we should support more authentication types, at least SPNEGO. In order to allow SPNEGO and other authentication mechanisms, we better force people to use single URI to perform the login and return authenticated 'ticket' to continue interaction with application. this is good for the backend authentication, but is not for the RESTful
Re: [Engine-devel] ovirt-engine-sdk with C
On 05/13/2013 01:17 PM, leaboy@126 wrote: Hi，All I felt oivrt-engine-sdk coded with Python is slowly to connect ovirt-engine and console vm when a user have many vms, So, I just, want to rewrite the sdk with C(ANSI C Language). Just rewrite a sdk with C to connect overt-engine and console vm, would anyone give the amount of VMs should not effect private actions on vm, please show me your code, maybe i can advice on this. me some suggestion. Now, the problem is how can I connect to ovit-engine with C, and how can I get some information of vms, and how ovirrt-engine can respond my action(start,stop, .eg) Leaboy@beijing Thinks ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
On 05/07/2013 07:44 PM, Alon Bar-Lev wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Alon Bar-Lev alo...@redhat.com, Vojtech Szocs vsz...@redhat.com, Einav Cohen eco...@redhat.com, Itamar Heim ih...@redhat.com, Juan Hernandez jhern...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Monday, May 6, 2013 9:46:31 AM Subject: [REST-API] Support passing auth information without having to use HTTP Authorization header #958874 https://bugzilla.redhat.com/show_bug.cgi?id=958874 Hi Alon, (In reply to comment #2) Regardless of this specific RFE I would like to write that I don't like the REST API session mechanism [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it relays on cookies and not explicit API interaction. authentication in RESTful application is a matter of debate, it can be achieved in various ways, but session + cookie auth. method is very common and usually effective, it's biggest disadvantage is that it's not exactly RESfull cause client have to maintain (story) the cookie and not the server (but i wouldn't call it an issue at all), besides that it's works perfectly well from the REST PoV, also some may say that cookies are not strong enough and OAuth for instance should be used instead, but this is a different story cause in our case, cookie are for the clients (not browsers [1]) that can store them in a secure way or even not to store at all (in-memory cookie). [1] another disadvantage is that webbrowsers not able to access cookie namespace, but lately i've suggested URI based authentication [2] to support web browsers as well. [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html the biggest advantage of the cookie is a session expiration that maintained by the server and abstracted from the client what is much better from security PoV than standard authentication mechanisms such as HTTP basic auth for instance which can be potentially cached. Expiration is always managed by server side, regardless the cookie vs ticket debate. I would have expected a 'ticket' to be retrieved and that 'ticket' to be disconnected from the application server objects. Although we can refer the 'cookie' as a ticket, however the requirement to parse it should not be required, there be a conflict between two separate applications running on same server, and there may be a problem to transfer credentials between servers. well, this is not exactly correct: 1. client desn't have to decode/parse the cookie and pass credentials, all it need is just to store the cookie and pass it as is to server on every request. You just described what cookies are. And if I understand we want better control of application authentication, disconnected from 'default browser behavior'. 2. conflict between two separate applications running on same server? different cookie uses different domain path by spec., can you pls explain what do you mean by this? If you call the cookie JSESSIONID different applications cannot live under same path, this what for cookie has a path attribute, but it can create a bit of confusion indeed, but you not talking with more than one application in same time right ?!, i.e container/client fetches the JSESSIONID cookie from the specific request/response, so i'm not sure how possibly client can get in reply two cookies with a same name (even if all applications are using same cookie) If we modify authentication we should support more authentication types, at least SPNEGO. In order to allow SPNEGO and other authentication mechanisms, we better force people to use single URI to perform the login and return authenticated 'ticket' to continue interaction with application. this is good for the backend authentication, but is not for the RESTful application, it's like buying an aeroplane and driving it on a road, And why is that? who are you to decide what authentication mechanism is to be used by customers? alon, you misunderstood, i'm not talking about authentication method, but about your sentence ^ we better force people to use single URI If customer has a policy of not transmitting passwords over the network, then SPENGO is your friend. But let's ignore it for now. cookie is not any different from the SPENGO token in this meaning, it's just another data container. force people to use single URI to perform the login means SOAP while we wanted REST where any URI is considered as entry point and actually a resource address that should be accessible/manipulatable and authentication should be abstracted/disconnected from this concept. Again, you provide statements that are not written in stone. this is main REST principal. Having custom authentication header breaks the 'plain simple rest'. Having a URI is only makes it easier to manage this breakage. for us, but this is breaks a REST concept
[Engine-devel] [REST-API] Support passing auth information without having to use HTTP Authorization header #958874
https://bugzilla.redhat.com/show_bug.cgi?id=958874 Hi Alon, (In reply to comment #2) Regardless of this specific RFE I would like to write that I don't like the REST API session mechanism [http://wiki.ovirt.org/Features/RESTSessionManagement] solution, as it relays on cookies and not explicit API interaction. authentication in RESTful application is a matter of debate, it can be achieved in various ways, but session + cookie auth. method is very common and usually effective, it's biggest disadvantage is that it's not exactly RESfull cause client have to maintain (story) the cookie and not the server (but i wouldn't call it an issue at all), besides that it's works perfectly well from the REST PoV, also some may say that cookies are not strong enough and OAuth for instance should be used instead, but this is a different story cause in our case, cookie are for the clients (not browsers [1]) that can store them in a secure way or even not to store at all (in-memory cookie). [1] another disadvantage is that webbrowsers not able to access cookie namespace, but lately i've suggested URI based authentication [2] to support web browsers as well. [2] http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html the biggest advantage of the cookie is a session expiration that maintained by the server and abstracted from the client what is much better from security PoV than standard authentication mechanisms such as HTTP basic auth for instance which can be potentially cached. I would have expected a 'ticket' to be retrieved and that 'ticket' to be disconnected from the application server objects. Although we can refer the 'cookie' as a ticket, however the requirement to parse it should not be required, there be a conflict between two separate applications running on same server, and there may be a problem to transfer credentials between servers. well, this is not exactly correct: 1. client desn't have to decode/parse the cookie and pass credentials, all it need is just to store the cookie and pass it as is to server on every request. 2. conflict between two separate applications running on same server? different cookie uses different domain path by spec., can you pls explain what do you mean by this? If we modify authentication we should support more authentication types, at least SPNEGO. In order to allow SPNEGO and other authentication mechanisms, we better force people to use single URI to perform the login and return authenticated 'ticket' to continue interaction with application. this is good for the backend authentication, but is not for the RESTful application, it's like buying an aeroplane and driving it on a road, force people to use single URI to perform the login means SOAP while we wanted REST where any URI is considered as entry point and actually a resource address that should be accessible/manipulatable and authentication should be abstracted/disconnected from this concept. SPNEGO is only an implementation detail that can be abstracted for the API. This will be much simpler implementation at the api side and much more efficient, and as we are discussion application-to-application interaction there should be no user experience visible issues. i'm not sure: force people to use single URI to perform the login and no no user experience visible issues.? What I recommend is purely applicative rest login command... IIUC this is SOAP and not REST ... --- Input: authentication type, authentication credentials authentication=http authentication=password credentials: user=user password=password [OPTIONALLY] HTTP authentication headers Output: ticket ticket issue time (required to avoid clock sync) ticket expiration time Logic: if authentication is http, use http authentication headers to establish user authentication. This will allow future SSO. if authentication is password, use embedded credentials. --- For every other rest call add http header: oVirt-Authentication-Ticket: ticket this is not any different from the today's session based auth. only instead of oVirt-Authentication-Ticket added cookie. The backend side will attach the correct security context to the action if the header is received. this is how it's works today. No need for the prefer mechanism nor multiple authentications. It should be easy for javascript implementation to perform the authentication via the designated URI, and then pass the ticket if not expired, when expired to perform re-authentication with or without involving the user. again this is how it works today, and you not solving web browser problem as when ticket expires, they cannot re-authenticate with new oVirt-Authentication-Ticket cause this header is cached and cannot be changed by the browser in runtime. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel
Re: [Engine-devel] REST vs. UI validation
Hi Roy, On 05/02/2013 08:29 AM, Roy Golan wrote: On Wed 01 May 2013 08:41:15 PM IDT, Vered Volansky wrote: - Original Message - From: Kari Whitcomb kari.whitc...@hp.com To: Michael Pasternak mpast...@redhat.com, Vered Volansky ve...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, May 1, 2013 8:12:09 PM Subject: RE: [Engine-devel] REST vs. UI validation Thanks for the discussion. One clarifying question below... -Kari Vered - I disagree that this is by design. There is only one definition of what a correct value is, there should be no ambiguity about it[1] If the GUI prohibits you from a legal configuration - it should be fixed. if the backend allows an illegal configuration - a CDA should be added. My two cents - this is not OK, please open bugs (or even better - send patches!) for the specific issues. This was discussed with Michael (until he answers himself). More info on the issue - The backend validations are less restrictive than UI, but not contradicting it. This IS by design and is not a bug in general. The specific min-max differences example is for sure by design. In some (but I guess not all) cases the reasoning is a thought to expand possible values in the future. So this is how things are right now. I agree it looks weird that you might be able to set illegal values in REST and then connect via UI and see these values. I suppose it can always come up for devel discussion whether that should be changed. you cannot set any illegal value in REST-API, UI is more restrictive indeed, while api expose all backend capabilities (including those that are restricted in UI) So if I understanding correctly... The backend validations are checking legality. The UI may in some cases (like the specific ones I mentioned) impose additional restrictions/validations that further narrow the allowed input and this is by design and not a bug. Does that sum the current state about right? Yep. I disagree. The UI is validating input to fail as fast and save rountrips for better responsiveness and overall a better UX. This means validation are duplicated and sometimes, different - which I consider a bug - there is no good reason an action would be valid using the API and invalid with UI or vise versa. you basically repeating told above, if you'll read this tread from the beginning, kari gives two examples in Cluster load balancing both not even near to be different, it's just a different (UI) representation for same thing, UI actually hiding engine implementation details over mentioned properties. the main chalenge is to share the validation code which might be achievablle if GWT will support our validation annotation on beans (jsr303) - Vojetech this one I think you'll be able to help with this is nice to have approach and will work with static validations only (that does not require dialogue with the engine), in any case api don't have any validation concept (except of mandatory parameters existence) and should not have, as engine do this job, - and that what we trying to make clear, but again not always same validations as mentioned above will take place on both client and engine sides. Thanks, Kari - Original Message - From: Kari Whitcomb kari.whitc...@hp.com To: engine-devel@ovirt.org Sent: Tuesday, April 30, 2013 1:19:00 AM Subject: [Engine-devel] REST vs. UI validation I've been making use of the oVirt REST api, and have noticed that in several cases the validation done for a REST request is different than what the admin UI does. It seems that the UI is generally more restrictive on the data it will accept than the backend. So you can set things up using the REST api that the UI wouldn't let you do. Two examples I've hit recently, both in the cluster policy (load balancing section): - Cluster load balancing policy duration - the UI requires a value between 1 and 100, but the REST api seems to let you set it to any integer. - Cluster load balancing high and low thresholds / max and min service levels - The UI restricts the high value to 51-90% and the low value to 10-50%. But the backend only requires that the values be 0-100% and that low can't be greater than high. So my question - is this intended behavior, or is it a bug that the validation is different? If similar validation should be done through both the UI and REST api, should the UI be less restrictive, or the backend more restrictive? Thanks, Kari ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel
Re: [Engine-devel] about ovirt-engine-sdk
Hi,
On 05/02/2013 05:53 AM, leaboy@126 wrote:
Hi,all
How can I use overt-engine-sdk in the python environment below python2.7,
For example, when I use it in python 2.6.5 like thus:
what sdk version you're using?
how did you installed it?
what version of lxml you have installed?
percy@percy-desktop:~/thtf-client$ python --version
Python 2.6.5
percy@percy-desktop:~/thtf-client$ python
Python 2.6.5 (r265:79063, Oct 1 2012, 22:04:36)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
from ovirtsdk.api import API
from ovirtsdk.xml import params
api = API('http://192.168.1.181', 'admin@internal', '11', None, None,
'~/.spicec/ca.crt', None, None, True)
*Traceback (most recent call last):*
* File stdin, line 1, in module*
* File ovirtsdk/api.py, line 107, in __init__*
*url='/api')*
* File ovirtsdk/infrastructure/proxy.py, line 129, in request*
*last=last)*
* File ovirtsdk/infrastructure/proxy.py, line 171, in __doRequest*
*return params.parseString(response_body) if response_body is not None
and response_body is not '' \*
* File ovirtsdk/xml/params.py, line 21229, in parseString*
*rootObj.build(rootNode)*
* File ovirtsdk/xml/params.py, line 20304, in build*
*self.buildAttributes(node, node.attrib, [])*
* File ovirtsdk/xml/params.py, line 20309, in buildAttributes*
*super(API, self).buildAttributes(node, attrs, already_processed)*
* File ovirtsdk/xml/params.py, line 4160, in buildAttributes*
*value = find_attr_value_('xsi:type', node)*
* File ovirtsdk/xml/params.py, line 316, in find_attr_value_*
*namespace = node.nsmap.get(prefix)*
*AttributeError: nsmap*
But, when I use it in python 2.7.3, it’s ok
leaboy@leaboy:~/workspace/thtf-client$ python --version
Python 2.7.3
leaboy@leaboy:~/workspace/thtf-client$ python
Python 2.7.3 (default, Aug 1 2012, 05:16:07)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more information.
from ovirtsdk.api import API
from ovirtsdk.xml import params
api = API('http://192.168.1.181', 'admin@internal', '11', None, None,
'~/.spicec/ca.crt', None, True)
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] 答复: about ovirt-engine-sdk
On 05/02/2013 11:06 AM, leaboy@126 wrote:
The code I got in 2013-1-27 with git, I don't know which version I got,
I didn't install it , I just use it like the example,
you should be installing sdk in some way, cause just fetching it from the git,
wasn't make it available in python,
i suggest you installing official releases (unless you would like to develop
contribute)
from pypi/easy_install.
leaboy@leaboy:~/workspace/thtf-client$ python --version
Python 2.7.3
leaboy@leaboy:~/workspace/thtf-client$ python
Python 2.7.3 (default, Aug 1 2012, 05:16:07)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more information.
from ovirtsdk.api import API
from ovirtsdk.xml import params
api = API('http://192.168.1.181', 'admin@internal', '11', None,
None, '~/.spicec/ca.crt', None, True)
I use it successful in ubuntu 12.04 without any other operation,
Just import the modules with python 2.7.3
But when I use it in other OS, such as ubuntu 11, or embed linux for ARM,
With python 2.6.*, It does't work,
i just verified it on [1], not sure about embed linux, in any case to
make it work, lxml should be installed.
[1]
python 2.6.6
python-lxml-2.2.3-1
-邮件原件-
发件人: Michael Pasternak [mailto:mpast...@redhat.com]
发送时间: 2013年5月2日 14:19
收件人: leaboy@126
抄送: engine-devel@ovirt.org
主题: Re: about ovirt-engine-sdk
Hi,
On 05/02/2013 05:53 AM, leaboy@126 wrote:
Hi,all
How can I use overt-engine-sdk in the python environment below python2.7,
For example, when I use it in python 2.6.5 like thus:
what sdk version you're using?
how did you installed it?
what version of lxml you have installed?
percy@percy-desktop:~/thtf-client$ python --version
Python 2.6.5
percy@percy-desktop:~/thtf-client$ python
Python 2.6.5 (r265:79063, Oct 1 2012, 22:04:36)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
from ovirtsdk.api import API
from ovirtsdk.xml import params
api = API('http://192.168.1.181', 'admin@internal', '11', None,
None, '~/.spicec/ca.crt', None, None, True)
*Traceback (most recent call last):*
* File stdin, line 1, in module*
* File ovirtsdk/api.py, line 107, in __init__*
*url='/api')*
* File ovirtsdk/infrastructure/proxy.py, line 129, in request*
*last=last)*
* File ovirtsdk/infrastructure/proxy.py, line 171, in __doRequest*
*return params.parseString(response_body) if response_body is not None
and response_body is not '' \*
* File ovirtsdk/xml/params.py, line 21229, in parseString*
*rootObj.build(rootNode)*
* File ovirtsdk/xml/params.py, line 20304, in build*
*self.buildAttributes(node, node.attrib, [])*
* File ovirtsdk/xml/params.py, line 20309, in buildAttributes*
*super(API, self).buildAttributes(node, attrs, already_processed)*
* File ovirtsdk/xml/params.py, line 4160, in buildAttributes*
*value = find_attr_value_('xsi:type', node)*
* File ovirtsdk/xml/params.py, line 316, in find_attr_value_*
*namespace = node.nsmap.get(prefix)*
*AttributeError: nsmap*
But, when I use it in python 2.7.3, it’s ok
leaboy@leaboy:~/workspace/thtf-client$ python --version
Python 2.7.3
leaboy@leaboy:~/workspace/thtf-client$ python
Python 2.7.3 (default, Aug 1 2012, 05:16:07)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more information.
from ovirtsdk.api import API
from ovirtsdk.xml import params
api = API('http://192.168.1.181', 'admin@internal', '11', None,
None, '~/.spicec/ca.crt', None, True)
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-python 3.3.0.2-1 released
- in ClusterGlusterVolumeBricks fixed add() parameters - to StorageDomainVM.delete() added async parameter - fixed parent tag parameter in the tags.add()/.update() methods - nic.network is no longer mandatory parameter for vnic creation - Implement Session-TTL header support #928313 - refactor invocation flow #949189, #949187 - user should not see admin permissions the DC #924357 More details can be found at [1]. [1] http://wiki.ovirt.org/Python-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-cli 3.3.0.2 released
- datetime.datetime object has no attribute __dict__ #957519 - remove pexpect dependency - Ping command success message need to be rephrased #918749 - spicec does not pass cert_file #953582 - Error in update network --cluster-identifier --usages-usage #950993 - List/Show suggests parent+child as single param #950398 - Error type brick does not exist. on replace brick #923196 - Implement Session-TTL header support #928314 - unclear error message when using unsupported 2 levels attribute #949642 - correlation_id is not attached to update command #950441 - connect --help will log the user out of the disconnected cli #890340 - help add fails to format the error when number of provided args in incorrect #922018 More details can be found at [1]. [1] http://wiki.ovirt.org/Cli-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST vs. UI validation
-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST vs. UI validation
On 05/01/2013 08:12 PM, Whitcomb, Kari wrote: Thanks for the discussion. One clarifying question below... -Kari Vered - I disagree that this is by design. There is only one definition of what a correct value is, there should be no ambiguity about it[1] If the GUI prohibits you from a legal configuration - it should be fixed. if the backend allows an illegal configuration - a CDA should be added. My two cents - this is not OK, please open bugs (or even better - send patches!) for the specific issues. This was discussed with Michael (until he answers himself). More info on the issue - The backend validations are less restrictive than UI, but not contradicting it. This IS by design and is not a bug in general. The specific min-max differences example is for sure by design. In some (but I guess not all) cases the reasoning is a thought to expand possible values in the future. So this is how things are right now. I agree it looks weird that you might be able to set illegal values in REST and then connect via UI and see these values. I suppose it can always come up for devel discussion whether that should be changed. you cannot set any illegal value in REST-API, UI is more restrictive indeed, while api expose all backend capabilities (including those that are restricted in UI) So if I understanding correctly... The backend validations are checking legality. The UI may in some cases (like the specific ones I mentioned) impose additional restrictions/validations that further narrow the allowed input and this is by design and not a bug. Does that sum the current state about right? yep. Thanks, Kari - Original Message - From: Kari Whitcomb kari.whitc...@hp.com To: engine-devel@ovirt.org Sent: Tuesday, April 30, 2013 1:19:00 AM Subject: [Engine-devel] REST vs. UI validation I've been making use of the oVirt REST api, and have noticed that in several cases the validation done for a REST request is different than what the admin UI does. It seems that the UI is generally more restrictive on the data it will accept than the backend. So you can set things up using the REST api that the UI wouldn't let you do. Two examples I've hit recently, both in the cluster policy (load balancing section): - Cluster load balancing policy duration - the UI requires a value between 1 and 100, but the REST api seems to let you set it to any integer. - Cluster load balancing high and low thresholds / max and min service levels - The UI restricts the high value to 51-90% and the low value to 10-50%. But the backend only requires that the values be 0-100% and that low can't be greater than high. So my question - is this intended behavior, or is it a bug that the validation is different? If similar validation should be done through both the UI and REST api, should the UI be less restrictive, or the backend more restrictive? Thanks, Kari -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [oss-security] CVE-2012-XXYY Request -- google-authenticator: Information disclosure due insecure requirement on the secrets file
FYI On 04/18/2013 01:45 PM, Jan Lieskovsky wrote: Hello Kurt, Steve, Alexander, vendors, as noted in [1]: An information disclosure file was found in the way google-authenticator, a pluggable authentication module (PAM) which allows login using one-time passcodes conforming to the open standards developed by the Initiative for Open Authentication (OATH), performed management of its secret / state file in certain configurations. Due the lack of 'user=' option the secret file was previously required to be user-readable, allowing (in certain cases) a local attacker to obtain the (pre)shared client-to-authentication-server secret, possibly leading to victim's account impersonation. A different vulnerability than CVE-2013-0258. References: [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#10 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#20 [4] https://bugzilla.redhat.com/show_bug.cgi?id=953505 Relevant upstream patch: [5] https://code.google.com/p/google-authenticator/source/detail?r=c3414e9857ad64e52283f3266065ef3023fc69a8 @Alexander - since I am not sure I have described the attack vector above properly, please correct me if / where required. @Kurt * the CVE-2012- identifier should be allocated to this issue, since the security implications of this problem are for the first time mentioned here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666129#10 (2012-09-22), * from what I have looked, there doesn't seem to be: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authenticator a CVE identifier allocated to this issue yet (as noted above CVE-2013-0258 from that list is different issue). = could you allocate one? Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Location of findbugs filter.xml file
On 04/18/2013 04:58 PM, Oved Ourfalli wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, April 18, 2013 4:55:46 PM Subject: [Engine-devel] Location of findbugs filter.xml file Hi all, I sent a patch upstream to add findbugs filter that will filter out bug reports that we decided that are not bugs. We have a debate on whether to have the findbugs filter definition in the root pom.xml or to put it in the jenkins jobs repo and treat it as an external tool. I would like to hear opinions about what you think should be the proper location Putting it in the root pom.xml file will allow running filtered findbugs using maven, without the need to use jenkins, so I'd go with that approach. +1 Thanks, Yair ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal to make REST API more webapp-friendly
authentication scheme. I've just read an excellent article at [http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/] which describes easy yet secure authentication scheme inspired by Amazon Web Services REST API authentication [http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html]. The idea is simple: collect auth information, hash (sign) it with a private key, and send everything to server. To guard against Replay attacks, just provide some timestamp to enforce request expiry after some time (say, 5-15 minutes). Easy and simple! 1. this concept has very same drawbacks as any other content encryption 2. decoding time stamp from request/s will produce fair load for the server as well and won't protect the server against DDOS, also it shouldn't as it's not api/webapp prerogative. in general what Vojtech is trying to achieve is passing session via some other container than cookie as webapp/browsers can't omit auth. header in runtime, what is only justifying my resistance of passing session id via http header, i think using matrix parameter (as mentioned above) may give you a decent solution. -- (3) Support JSON for resource representations! I think this is pretty much obvious. XML has no real advantages over JSON. JSON, on the other hand, has good support in webapps (JavaScript) and maps directly to common data structures (i.e. string, number, boolean, and so on). From webapp perspective, it's much easier and natural to use JSON than to parse/format XML documents. Alternative: clients could be given the *option* to use JSON, in addition to XML representation. not sure how it's related, but we plan supporting JSON in future. -- Vojtech ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.6-1 released
- 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 RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Improvement for the oVirt java sdk
On 03/07/2013 04:53 PM, Morrissey, Christopher wrote: -Chris -Original Message- From: Michael Pasternak [mailto:mpast...@redhat.com] Sent: Thursday, March 07, 2013 6:37 AM To: Morrissey, Christopher Cc: us...@ovirt.org; engine-devel Subject: Re: Improvement for the oVirt java sdk On 03/04/2013 05:26 PM, Morrissey, Christopher wrote: Hi Michael, Yes, that is the case here. I'm getting the JSESSIONID from the client and passing it to our server so that it can perform REST-API calls back to oVirt under the logged in user's authenticated session. done, see http://lists.ovirt.org/pipermail/users/2013-March/012969.html Thanks for the very quick implementation! I'll give it a try shortly. here [1] is wiki for this change. [1] http://www.ovirt.org/Java-sdk#Authenticating_using_sessionid -Chris -Original Message- From: Michael Pasternak [mailto:mpast...@redhat.com] Sent: Sunday, March 03, 2013 4:44 AM To: Morrissey, Christopher Cc: us...@ovirt.org; engine-devel Subject: Re: Improvement for the oVirt java sdk Hi Christopher, In general SDK abstracts the transport layer, therefore all authentication internals hidden from the user, i.e SESSION based authentication happens implicitly (by default), when you initiate SDK entry point, the story is different if you want using SSO-like login by reusing JSESSIONID from the REST-API for instance, and i can support such scenario, but, is this your case? On 02/28/2013 10:04 PM, Morrissey, Christopher wrote: Hi Michael, I'm looking to use the oVirt java sdk for connecting into oVirt from our server. However, we have a UI plugin that gets access to a session ID that we should be able to use to connect through the REST API instead of the username and password. Any chance the sdk could be updated to take the session ID and create a connection vs. a user name and password? -Chris Chris Morrissey Software Engineer NetApp Inc. 919.476.4428 -- Michael Pasternak RedHat, ENG-Virtualization RD -- Michael Pasternak RedHat, ENG-Virtualization RD -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.5-1 released
- use explicit classloader for JAXBContext - implement support for (user defined) session authentication - implement generic JAXBElement generation - to DataCenterStorageDomain added Disks sub-collection - to StorageDomain added Disks sub-collection - to host added display.address property - to vms.add() added overload for creating vm from snapshot More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] fedora openid authentication for gerrit is broken
Ok, here how it works, old id: https://admin.fedoraproject.org/accounts/openid/id/username is no longer supported according to [1], new format is: username.id.fedoraproject.org [1] https://fedoraproject.org/wiki/OpenID thanks. On 03/06/2013 10:37 AM, Michael Pasternak wrote: https://admin.fedoraproject.org/accounts/openid/server 404 Not Found The path '/openid/server' was not found. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] fedora openid authentication for gerrit is broken
On 03/06/2013 02:46 PM, Michael Kublin wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Dary yd...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Vered Volansky ve...@redhat.com, in...@ovirt.org Sent: Wednesday, March 6, 2013 2:42:46 PM Subject: Re: [Engine-devel] fedora openid authentication for gerrit is broken On 03/06/2013 02:18 PM, Yaniv Dary wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Vered Volansky ve...@redhat.com, in...@ovirt.org Sent: Wednesday, March 6, 2013 12:48:57 PM Subject: Re: [Engine-devel] fedora openid authentication for gerrit is broken On 03/06/2013 12:34 PM, Itamar Heim wrote: On 03/06/2013 11:38 AM, Dan Kenigsberg wrote: On Wed, Mar 06, 2013 at 09:55:45AM +0100, Alexander Rydekull wrote: Itamar, I think Vered summarize it quite perfectly in a parallell thread: http://lists.ovirt.org/pipermail/infra/2013-March/002314.html He was also kind enough to open a ticket on the issue. Could you look into it? I wonder if our friendly gerrit.ovirt.org dba could add the new url https://danken.id.fedoraproject.org/ for every user with the old one, so that people lacking the new one can keep on working? (/me not included, I have both urls) Dan. it's not that simple, still investigating... ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ok, new url is working. for general knowledge, its aside of the use of the new identity url and in the form of: https://admin.fedoraproject.org/accounts/user/view/iheim previous format was: https://admin.fedoraproject.org/accounts/openid/id/iheim (there could be something more correct, but this works...) please check and update if you still see issues. Getting 'Provider is not supported, or was incorrectly entered.'. use this format in the gerrit sign in screen: http://iheim.id.fedoraproject.org/ But all my patches and reviews are not linked to my old user and I can not link it via gerrit because of https://admin.fedoraproject.org/accounts/user/view/mkublin is not valid anymore in general you should be linking your old identity in gerrit from the [1], but since it's disabled - it's not possible. [1] https://admin.fedoraproject.org/accounts/openid/id/user ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from
On 02/24/2013 03:01 PM, Oved Ourfalli wrote: - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: Oved Ourfalli ov...@redhat.com, engine-devel@ovirt.org, a...@ovirt.org Sent: Sunday, February 24, 2013 1:20:12 PM Subject: Re: [Engine-devel] REST API calls from - Original Message - From: Michael Pasternak mpast...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Sunday, February 24, 2013 9:47:28 AM Subject: Re: [Engine-devel] REST API calls from On 02/24/2013 09:05 AM, Oved Ourfalli wrote: - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Thursday, February 21, 2013 6:54:59 PM Subject: Re: [Engine-devel] REST API calls from - Original Message - From: Michael Pasternak mpast...@redhat.com To: Doron Fediuck dfedi...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 20, 2013 2:56:59 PM Subject: Re: [Engine-devel] REST API calls from On 02/14/2013 11:20 AM, Doron Fediuck wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Libor Spevak lspe...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI Hi Libor, This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion, Intuitively REST is a way to go with GWT AJAX calls --- pros - api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is easy as api describes itself in RSDL [2] cons - implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers Java-SDK pros - abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance) cons - has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC thoughts? [1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context? Doron, I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api-GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself, i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that. Michael, true but... Thinking about it differently both UI and hooks needs a client. The underlying protocols should be abstracted. This is something which will serve other functions as well. I'm not sure we would need a new abstraction here. Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine. +1
[Engine-devel] ovirt-engine-sdk-java 1.0.0.3-1 released
* Wed Jan 30 2013 Michael Pasternak mpast...@redhat.com - 1.0.0.3-1 - implement SSL support (without host verification) - implement shutdown() to deallocate system resources - to cluster added tunnel_migration property - to DataCenter added Clusters sub-collection - to root collection resource Disk added Permissions sub-collectio - to root collection resource Disk added Statistic sub-collection - host can be attached to cluster now either by id or name - to StorageDomainTemplate added Disks sub-collection - to StorageDomainVM added Disks sub-collection - to template.display added keyboard_layout property - to template added tunnel_migration property - to vm.display added keyboard_layout property - to vm added tunnel_migration property - to VMSnapshot added preview method - to VMSnapshot added undo method - to VMSnapshot added commit method More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.4-1 released
- implement SSL support (without host verification) - implement shutdown() to deallocate system resources - to cluster added tunnel_migration property - to DataCenter added Clusters sub-collection - to root collection resource Disk added Permissions sub-collectio - to root collection resource Disk added Statistic sub-collection - host can be attached to cluster now either by id or name - to StorageDomainTemplate added Disks sub-collection - to StorageDomainVM added Disks sub-collection - to template.display added keyboard_layout property - to template added tunnel_migration property - to vm.display added keyboard_layout property - to vm added tunnel_migration property - to VMSnapshot added preview method - to VMSnapshot added undo method - to VMSnapshot added commit method More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from the GUI
On 02/21/2013 03:30 PM, Vojtech Szocs wrote: Hi guys, We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT. why? they only have jaxb annotations which are 'must' for serialization talking with api. Actually, we *can* use JAXB-generated REST API Java types with GWT, since GWT compiler simply ignores annotations in Java sources during compilation to JavaScript. The only problem I see is REST API Java types using stuff like javax.xml.datatype.XMLGregorianCalendar - we'd have to emulate it in GWT (shouldn't be an issue). Other than that, I'd recommend using JAXB-generated REST API Java types, as they always match current REST API schema (api.xsd). As for the marshalling layer, we can't use JAXB (REST API Java SDK) with GWT, but we can still write deferred binding generator to generate mappers for XML -- Rest API Java type conversion. if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML as they are defined in the api schema and not using Java naming convention (as XJC does), Yeah, with XML representation we would have to do this ourselves. On the other hand, things would be much simpler if REST API supported JSON, which is something we should consider (wait for JSON support? work with XML?) not sure we will support JSON in near future as we're blocked by underlying provider. It would be better if We can come up with a GWT REST API SDK, which is analogous Java SDK. I'd rather have JavaScript REST API SDK which we could use with GWT, this would open up new possibilities for web clients. Vojtech -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from
On 02/24/2013 09:05 AM, Oved Ourfalli wrote: - Original Message - From: Doron Fediuck dfedi...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Thursday, February 21, 2013 6:54:59 PM Subject: Re: [Engine-devel] REST API calls from - Original Message - From: Michael Pasternak mpast...@redhat.com To: Doron Fediuck dfedi...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 20, 2013 2:56:59 PM Subject: Re: [Engine-devel] REST API calls from On 02/14/2013 11:20 AM, Doron Fediuck wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Libor Spevak lspe...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI Hi Libor, This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion, Intuitively REST is a way to go with GWT AJAX calls --- pros - api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is easy as api describes itself in RSDL [2] cons - implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers Java-SDK pros - abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance) cons - has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC thoughts? [1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context? Doron, I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api-GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself, i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that. Michael, true but... Thinking about it differently both UI and hooks needs a client. The underlying protocols should be abstracted. This is something which will serve other functions as well. I'm not sure we would need a new abstraction here. Both UI plugins and engine plugins need some API to do basic operations, and have access to different properties in the engine. +1, that's exactly what i've suggested to begin with. In the UI plguins implementation, we gave this API, and in addition created a REST session to be used in order to do more sophisticated operations. I think we should probably do the same for engine plugins, giving the basic API, and giving a REST session for more advanced operations. The engine plugin may also have another 3rd party application it interacts with, and it would be able to share this session with it, allowing it to perform different operations on the engine. It would obviously be easy to do that using the Java SDK in the engine side, without creating a new layer of abstraction. true, but the thing is that java-sdk designed to work with rest-api, and what Doron is trying to do is saving round-trip of engine-sdk-api-engine by enabling extra layer in sdk that will work not via HTTP, but natively with RESTeasy (REST framework we using in api), the disadvantages of such design are: 1. working with java-sdk via JNI (walking out from container to client application - sdk) 2. hacking
Re: [Engine-devel] REST API calls from the GUI
On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote: - Original Message - From: Vojtech Szocs vsz...@redhat.com To: Daniel Erez de...@redhat.com Cc: a...@ovirt.org, engine-devel@ovirt.org Sent: Saturday, February 16, 2013 1:07:56 AM Subject: Re: [Engine-devel] REST API calls from the GUI Hi Daniel, The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK. Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map restapi-types entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema. AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be useful instead of generating/writing overlay types. AutoBeans will be converted overlay types internally by GWT automatically. The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode). Indeed, we can't use Java REST API SDK as it is with GWT: https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation This means we need to implement our own transport layer (RequestBuilder) and most likely also the marshalling layer (XMLParser vs. JSONParser vs. overlay types). It would be better if We can come up with a GWT REST API SDK, which is analogous Java SDK. A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend - REST - Java SDK (servlet) - JavaScript (client). This is interesting, generic API could be used to transfer restapi-types, along with extra information to emulate proper HTTP request, without any marshalling involved. We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT. why? they only have jaxb annotations which are 'must' for serialization talking with api. Vojtech - Original Message - From: Daniel Erez de...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: engine-devel@ovirt.org, Einav Cohen eco...@redhat.com, a...@ovirt.org, Libor Spevak lspe...@redhat.com, Vojtech Szocs vsz...@redhat.com Sent: Friday, February 15, 2013 7:17:43 PM Subject: Re: [Engine-devel] REST API calls from the GUI - Original Message - From: Michael Pasternak mpast...@redhat.com To: Libor Spevak lspe...@redhat.com Cc: engine-devel@ovirt.org, Daniel Erez de...@redhat.com, Gilad Chaplik gchap...@redhat.com, Einav Cohen eco...@redhat.com, a...@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI Hi Libor, This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion, Intuitively REST is a way to go with GWT AJAX calls --- pros - api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is easy as api describes itself in RSDL [2] cons - implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers Java-SDK pros - abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance) cons - has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out
Re: [Engine-devel] REST API calls from
On 02/14/2013 11:20 AM, Doron Fediuck wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Libor Spevak lspe...@redhat.com Cc: engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 13, 2013 12:55:36 PM Subject: Re: [Engine-devel] REST API calls from the GUI Hi Libor, This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion, Intuitively REST is a way to go with GWT AJAX calls --- pros - api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is easy as api describes itself in RSDL [2] cons - implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers Java-SDK pros - abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance) cons - has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC thoughts? [1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl Although started as a UI request, there are other needs who wish to use API calls with a different transport. For example a backend hook which gets a REST entry point it can use to fetch for additional data, or perform actions. In this case I'd expect an internal connection rather than creating additional connections. How would you resolve it generically enough in this context? Doron, I believe your approach a bit different, UX folks seeking for a convenient way of communicating with ovirt public api, e.g closing api-GUI gap, and theirs alternatives where native HTTP layer or Java-SDK based framework, while what you need is in-process channel to communicate with the engine itself, i understanding your will of using stable api for this (RESTapi), but not sure that doing this via JavaSDK is a good way to go simply because SDK is designed to operate in a client-space, while what you need is a server-space bridge for that. On 02/12/2013 06:13 PM, Libor Spevak wrote: Hi, I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed transparently by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate. Java REST API SDK enables to build thick client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps. I found several links about REST API support from GWT, so there is something for inspiration... - http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/ But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)? Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from the GUI
On 02/20/2013 02:45 PM, Kanagaraj Mayilsamy wrote: - Original Message - From: Michael Pasternak mpast...@redhat.com To: Kanagaraj Mayilsamy kmayi...@redhat.com Cc: Vojtech Szocs vsz...@redhat.com, engine-devel@ovirt.org, a...@ovirt.org Sent: Wednesday, February 20, 2013 5:55:50 PM Subject: Re: [Engine-devel] REST API calls from the GUI On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote: - Original Message - From: Vojtech Szocs vsz...@redhat.com To: Daniel Erez de...@redhat.com Cc: a...@ovirt.org, engine-devel@ovirt.org Sent: Saturday, February 16, 2013 1:07:56 AM Subject: Re: [Engine-devel] REST API calls from the GUI Hi Daniel, The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK. Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map restapi-types entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema. AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean) could be useful instead of generating/writing overlay types. AutoBeans will be converted overlay types internally by GWT automatically. The benefit of the second alternative is currently rather vague since the Java SDK can't be converted to JavaScript as is (can't use apache.commons and javax packages in GWT client side). Need to check how easily they can be replaced with JRE libraries that GWT can emulate (for supporting both GWT web and debug mode). Indeed, we can't use Java REST API SDK as it is with GWT: https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation This means we need to implement our own transport layer (RequestBuilder) and most likely also the marshalling layer (XMLParser vs. JSONParser vs. overlay types). It would be better if We can come up with a GWT REST API SDK, which is analogous Java SDK. A third alternative could be simply maintaining the current GWT RPC mechanism we use. I.e. integrating the Java SDK into the GWT servlet, which means wrapping the API into GenericApiGWTService. The main drawback is an additional layer of data type conversion and round-trip: Backend - REST - Java SDK (servlet) - JavaScript (client). This is interesting, generic API could be used to transfer restapi-types, along with extra information to emulate proper HTTP request, without any marshalling involved. We can't directly use the restapi models in the client side, as they have lot of xml and annotations stuff involved which will not be compatible with GWT. why? they only have jaxb annotations which are 'must' for serialization talking with api. We can't use jaxb, as GWT won't emulate the jaxb classes. https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation If at all we want use jaxb, we should include the source of jaxb to ui module, so that GWT can compile them to javascript equivalents. But this is less likely as jaxb relies heavily on reflection which not supported by GWT. if you not using JAXB, you should make sure calling variables in the classes that will be marshalled to XML as they are defined in the api schema and not using Java naming convention (as XJC does), if your schema-java converting tool support this, you're okay. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from the GUI
On 02/15/2013 09:37 PM, Vojtech Szocs wrote: Hi Daniel, The first alternative can be implemented by using GWT RequestBuilder (for sending the HTTP requests) and GWT overlay types (that can be generated from java POJOs). Probably best performance-wise/less data type conversions/etc; However, basically means writing a JavaScript SDK. Yes, we can use RequestBuilder for making AJAX HTTP requests, but using GWT overlay types is possible only if REST API fully supports JSON format. In case of XML format, we would have to use GWT XMLParser to map restapi-types entities/collections to/from XML strings, e.g. we could write GWT deferred binding generators to generate such mappers from current schema. REST API does not support JSON yet due to Resteasy JacksonProvider and JAXB issues. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] REST API calls from the GUI
Hi Libor, This issue came across in one of the conversations i had with UX folks, but since we didn't end up with any conclusion/road map (nor discussed it properly to hear other thoughts), this is a perfect place to start this discussion, Intuitively REST is a way to go with GWT AJAX calls --- pros - api data objects can be reused by generating java classes (using jaxb) from the rest schema [1] - no backend logic will be duplicated as api abstracts the backend exposing RESTful collection/resources to operate on - development against api is easy as api describes itself in RSDL [2] cons - implementing transport layer (HTTP) under GWT - implementing own j2xml/json/yaml/... marshalling layer - implementing own error handling mechanism - implementing REST callback mechanism (in GWT) - constant maintenance of the data objects generated from the api - painful for Java developers Java-SDK pros - abstracts transport layer (leaving developer in standard Java api) - typesafe code (no need to mess with XML bulks) - has own data objects to work with - abstracts authentication/authorization (kerberos/cookie/session/etc.) - since SDK is auto-generated, it can be easily extended with required features to support UI (such as callback infrastructure for instance) cons - has to be converted in to Javascript (not sure what the impacts are in terms of AJAX calls/etc.) - probably much more cons that we're not aware of and will have to figure out with POC thoughts? [1] http[s]://server[:port]/api?schema [2] http[s]://server[:port]/api?rsdl On 02/12/2013 06:13 PM, Libor Spevak wrote: Hi, I would like to ask, if there have been discussions about an option to call REST API services directly from the Frontend (GWT layer)? GWT compiles Java frontend-side to Javascript, calls to backend services are performed transparently by the framework using AJAX support. But, there is still a need to have a special set of data objects and the server-side logic can duplicate. Java REST API SDK enables to build thick client. The calls are realized using e.g. Apache HttClient and supported libraries. I think the requirements of GWT can be a little bit different, but something overlaps. I found several links about REST API support from GWT, so there is something for inspiration... - http://www.spiffyui.org/ - http://www.zackgrossbart.com/hackito/gwt-rest/ - http://code.google.com/p/gwt-rest/ - http://restygwt.fusesource.org/ But, do you think it would be useful and what drawbacks can occur (authentication, authorization, response times, need to support larger set of services, painful refactoring, ...)? Regards, Libor ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Java process increasing resident memory
On 01/31/2013 12:50 AM, Moti Asayag wrote: On 01/29/2013 10:27 AM, navin p wrote: Hi, I wrote this sample code and the resident memory of the process is increasing gradually over time. What could be the reason ? I don't see any obvious leaks in my program. Could it be that the API is not freeing/deleting memory ? By monitoring the program, it seems that the failure is due to constant threads creation by invoking the new API() call: Exception in thread main java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:691) at org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.createPoolingClientConnectionManager(ConnectionsPoolBuilder.java:182) at org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.createDefaultHttpClient(ConnectionsPoolBuilder.java:160) at org.ovirt.engine.sdk.web.ConnectionsPoolBuilder.build(ConnectionsPoolBuilder.java:234) at org.ovirt.engine.sdk.Api.init(Api.java:82) at collectHosts.main(collectHosts.java:102) By pulling the API instantiation outside of the loop, problem solved, since only a single thread is created to monitor the idle/expired connections. Thanks Moti, I already suggested navin to take SDK proxy initiation out of his while loop. Michael, wouldn't you suggest adding some sort of API.shutdown() method in order to release resources used by it including the connection monitor and any other live connections if exists? no need for that, in SDK i have dedicated thread (watchdog) for that. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] java SDK question
On 02/01/2013 03:17 PM, Moti Asayag wrote:
On 02/01/2013 12:56 PM, navin p wrote:
Hi,
When i do the api call for events from , i only get 100 events. Can
someone tell me how to get all the events ?
There are 2 options:
1. Use the overloaded Event.list method and specify the amount of result
you wish to get. In the next example you'll get 1000 entries.
Events events = api.getEvents();
events.list(, false, , 1000);
You can use this method to retrieve events by extents.
2. Increase the value of the configuration value 'SearchResultsLimit' to
the desired reasonable value.
There is a third option, you can use pagination via engine search interface,
just append to your query string page N.
ListEvent evlst=api.getEvents().list();
for(Event obj:evlst) {
System.out.println(obj.getDescription() + : +obj.getSeverity()
+:+obj.getTime().toString()+:+k.toString());
}
Regards,
Navin
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.3-1 released
- added persistent authentication support - added support for the methods overloads based on url/headers params - added delete methods overloads with body as parameters holder - to host added [display.address] property for overriding display address - user can specify own ticket now in vm.ticket() via [action.ticket.value] More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/30/2013 05:31 PM, Alon Bar-Lev wrote: Hi, You merge this with the rpm version to 3.3.0 which is totally invalid. 3.3.0 is a *RELEASE*. I really don't care what maven approach is, but please do not create issues with product release cycle. There should be no issues with product release cycle, carrying next development iteration with [VERSION+1]-SNAPSHOT is a standard, this way people know that they working against yet not officially released version. release should drop -SNAPSHOT prefix and at the end of release procedure, bump version and add -SNAPSHOT back. Alon - Original Message - From: Juan Hernandez jhern...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, January 30, 2013 5:26:25 PM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? Note that this change has just been merged. Let me know if you find any issue. -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Java process increasing resident memory
Hi Navin,
On 01/29/2013 10:27 AM, navin p wrote:
while (true)
{
Api api = new Api(URL,SOMEUSERNAME,SOMEPASSWORD);
i'd suggest you moving SDK proxy initiation out of this (endless) loop.
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Java process increasing resident memory
Navin,
It's quite hard to see from your piece of code what exactly causing this,
also i can't reproduce this on my environment running very same sdk code,
can you please run your app with some profiling tool attached and send me
the output?
On 01/29/2013 03:09 PM, navin p wrote:
Hi Michael,
On Tue, Jan 29, 2013 at 2:42 PM, Michael Pasternak mpast...@redhat.com
mailto:mpast...@redhat.com wrote:
Hi Navin,
On 01/29/2013 10:27 AM, navin p wrote:
while (true)
{
Api api = new Api(URL,SOMEUSERNAME,SOMEPASSWORD);
i'd suggest you moving SDK proxy initiation out of this (endless) loop.
I tried that but it didn't help. The Resident memory was increasing in the
top -p output
Regards,
Navin
--
Michael Pasternak
RedHat, ENG-Virtualization RD
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] unit tests failing
Hey Ewoud, +1 for bisect, what's up Ewoud?, this email reminds me good old rhevm-api days. On 01/29/2013 05:36 PM, Ewoud Kohl van Wijngaarden wrote: May I recommend git bisect? See http://lwn.net/Articles/317154/ or http://clock.co.uk/tech-blogs/git-bisect-simple-examples-and-automation as well. First you find a known BAD, for example master. Then you find a known GOOD (for example 100 commits ago in master: master~100). Then we can use a script to determine if it's good. I'm assuming mvn test will be sufficient, but maybe you can refine this to only test for a specific unit test. git bisect start BAD GOOD git bisect run mvn test Now it will do a binary search in your history trying to find the commit that broke mvn test. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Watchdog support Feature
On 01/24/2013 04:19 PM, Laszlo Hornyak wrote: Hi, Watchdog support in engine will add watchdog to the ovirt UI and REST API. Watchdog cards will be mainly used in HA vm's. http://www.ovirt.org/Features/Watchdog_engine_support Your feedback is welcome! Thank you, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel Definitely nice feature, but i have a question for [1], won't it cause slow responsive guests (on highly loaded hosts) to constantly reboot? i.e it's understood that 'reboot' is a goal of this feature, but endless reboot of pinned-to-host guests for instance won't do any good right?, my point is: should watchdog 'action' have extra logic for guest-policy like placement for instance? [1] watchdog model=i6300esb action=reset/ -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt engine sdk
Hi Navin, On 01/23/2013 01:54 PM, navin p wrote: Hi, I've written the following python program after configuring ovirt. from ovirtsdk.xml import params from ovirtsdk.api import API api=API(url='http://XYZ:80',username='ABC',password='123') print \n**VMS\n vmlist = api.vms.list() hostlist = api.hosts.list() evenlist = api.events.list(); for vm in vmlist: print vm.name http://vm.name,vm.memory,vm.id http://vm.id,vm.os.kernel,vm.cluster.id http://vm.cluster.id,vm.start_time print \n**HOSTS \n for host in hostlist: print host.name http://host.name #print \n**EVENTS \n #for evt in evenlist: # print evt.description It prints the output as *VMS fedora18 2147483648 3e4634b7-82a9-4c4f-8599-0f9092a9258e None 99408929-82cf-4dc7-a532-9d998063fa95 None testdtop1 536870912 c256a1d9-2e3f-42e8-9020-6d08d21d2d73 None 99408929-82cf-4dc7-a532-9d998063fa95 2013-01-23T09:59:36.726Z testvm1 268435456 f6b2a97d-34b2-4a62-adae-ac0504b96558 None 99408929-82cf-4dc7-a532-9d998063fa95 2013-01-23T09:55:06.727Z testvmfedora18 536870912 25c14ee6-65dd-4785-af0c-a8df3f87573f None 99408929-82cf-4dc7-a532-9d998063fa95 None **HOSTS omwin.ind.hp.com http://omwin.ind.hp.com Now i want to get the statistics for each vm like the memory used and memory installed etc in python. How do i go about getting them ? vm object has statistics sub-collection, you can access it by: vm.statistics.list(), Do we have something like a header file in C or C++ where i can see the member variables and then get the statistics ? in python, you can see object's attributes by accessing __dict__/__getattr__/dir(object)/etc., vm.__dict__ will do the job for you, however i'd suggest you using some IDE (i'm using Eclipse + PyDev plugin), this way you'll be able accessing object attributes simply by Ctrl+SPACE auto-completion. Regards, Navin ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt engine sdk
On 01/23/2013 03:53 PM, navin p wrote: Hi Michael, Thanks for your help. On Wed, Jan 23, 2013 at 6:15 PM, Michael Pasternak mpast...@redhat.com mailto:mpast...@redhat.com wrote: in python, you can see object's attributes by accessing __dict__/__getattr__/dir(object)/etc., vm.__dict__ will do the job for you, however i'd suggest you using some IDE (i'm using Eclipse + PyDev plugin), this way you'll be able accessing object attributes simply by Ctrl+SPACE auto-completion. Do i have import something for Ctrl+SPACE to work ? It doesn't work for me atleast for list attributes. for vm in vmlist: print vm.name http://vm.name,vm.memory,vm.id http://vm.id,vm.os.kernel,vm.cluster.id http://vm.cluster.id,vm.start_time #print help(vm.statistics.list()) vmslist = vm.statistics.list() for i in vmslist: print i.get_name() prints memory.installed memory.used cpu.current.guest cpu.current.hypervisor cpu.current.total but i need the values of memory.installed and memory.used . statistic holders are complex types, you can fetch data by: i.unit // the unit of the holder data i.values.value[0].datum // actual data Also where do i get the Java SDK and jars ? I looked at maven but it was 1.0 version of SDK. central repo has 1.0.0.2-1, see [1], deployment details can be found at [2], wiki at [3]. [1] http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.ovirt.engine.sdk%22 [2] http://www.ovirt.org/Java-sdk#Maven_deployment [3] http://www.ovirt.org/Java-sdk Regards, Navin -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/21/2013 10:28 AM, Omer Frenkel wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Michael Pasternak mpast...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org Sent: Monday, January 21, 2013 8:27:36 AM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? - Original Message - From: Michael Pasternak mpast...@redhat.com To: Juan Hernandez jhern...@redhat.com Cc: engine-devel@ovirt.org Sent: Sunday, January 20, 2013 3:24:58 PM Subject: Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT? On 01/17/2013 01:04 PM, Juan Hernandez wrote: Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in the master branch: +1 I agree, and this is not the only place where should start marking and cluster compatibility version.. all above is true, but Juan meant preparing MVN infra for the next development iteration, while you're talking about engine internals, maybe we should file BZs on that (as next version tasks) or should we define new process of preparing for the next version that will include both? 3.3.0 - what about upgrade scripts? http://gerrit.ovirt.org/11143 -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Time to move to 3.3.0-SNAPSHOT?
On 01/17/2013 01:04 PM, Juan Hernandez wrote: Once 3.2.0 is released I think we should move to 3.3.0-SNAPSHOT in the master branch: +1 http://gerrit.ovirt.org/11143 -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.2 released
Basically this release addresses an issue when [1] constructor is used with NULLs as optional parameters, [1] public Api(String url, String username, String password, String key_file, String cert_file, String ca_file, Integer port, Integer timeout, Boolean persistentAuth, Boolean insecure, Boolean filter, Boolean debug) -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java 1.0.0.1 released
Hi all, I'm happy to announce first official release of ovirt-engine-sdk-java, change log between sdk announcement and 1.0.0.1 is: * Tue Jan 15 2013 Michael Pasternak mpast...@redhat.com - 1.0.0.1-1 - implement parametrized list() methods - events can be added now (user defined events) - events can be removed now - host can be added now by using cluster.name (not only cluster-id) - NIC now has linked property - NIC now has plugged property - VM has now ReportedDevices sub-collection - VMNIC has now ReportedDevices sub-collection - to host add/update added power_management.agents parameter - to disk added permissions sub-collection - to PowerManagement added Agents collection - to VMDisk added move() action - to host added hooks sub-collection - to cluster added threads_as_cores property - to host added hardwareInformation property - to host added OS property - added force flag to the host.delete() method - added host.power_management.pm_proxy sub-collection - added permissions sub-collection to the network - added search capabilities to api.networks collection - added deletion protection support to template/vm via .delete_protected property More details can be found at [1]. [1] http://www.ovirt.org/Java-sdk-changelog -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] ovirt-engine-sdk-java package available via maven distribution now
All you need to work with oVirt java-sdk is add it as dependency to your pom.xml, for more details see [1]. [1] http://www.ovirt.org/Java-sdk#Maven_deployment -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] oVirt Java-SDK
Hi Lawrence, On 01/14/2013 08:31 PM, lawrence_sepulv...@nmcourt.fed.us wrote: Hello Michael. I wanted to extend my thanks for your great work on the oVirt Java-SDK. We are running a RHEV 3.0 stack and I have been reviewing the oVirt Java-SDK to integrate w/Nagios for monitoring purposes. That said, I'd like to request some minor changes to the Java API that would permit easier access for subclassing. If there is another more appropriate channel to make these suggestions, please let me know so I may follow through. In the org.ovirt.engine.sdk.Api class: - Add protected createConnectionsPoolBuilder(), createHttpProxyBuilder() and createHttpProxyBroker() methods that are called from the Api constructor(s) ConnectionsPoolBuilder, HttpProxyBuilder using 'builder' design pattern, adding methods accepting builder's parameters and invoking builder after analysing these params, will delegitimize this pattern. In the org.ovirt.engine.sdk.web.ConnectionsPoolBuilder class: - Change private to protected for createDefaultHttpClient(), createPoolingClientConnectionManager() and createSchemaRegistry() methods - Change private to protected for get() accessor methods The thing is that sdk creating abstraction over transport layer so all mentioned ConnectionsPoolBuilder methods are considered sdk internals, may i ask why do you need this (use-case)? Thank you again for the great work on this API. I am finding this API to be exactly what I was needing to monitor our RHEV 3.0 stack. Thank you very much for your kind words, i really appreciate that. If I should redirect these requests to another communication channel, please let me know. CC'ing engine-devel ML. Thank you, -- Lawrence Sepulveda Systems Engineer U.S. District Court District of New Mexico 333 Lomas Blvd., NW Albuquerque, NM 87102 Phone: (505) 348-2085 Fax: (505) 348-2028 lsepulv...@nmcourt.fed.us -- -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
