December 2012 - Devel - oVirt List Archives

[Engine-devel] Read Only Disk Feature
by Vered Volansky 24 Dec '12

24 Dec '12

Hi all, This is the wiki page for the new read-only disks feature in the engine: http://www.ovirt.org/Features/Read_Only_Disk Comments are welcome. Thanks, Vered

1 0

[Engine-devel] Problems with ovirt gerrit?
by Yair Zaslavsky 23 Dec '12

23 Dec '12

Hi, I see that git fetch -v (or git fetch) get stuck. I saw Maor and Yaniv Bronheim suffer from same issue Can someone please be of aid and fix this? Yair

2 1

[Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
by Michael Pasternak 23 Dec '12

23 Dec '12

Hi All, In many cases OSS maintainers not always can be in the loop of different threads what may cause them missing important decisions being taken, As result later on during reviews of the patches they're not accepting (already implemented) features, what is causing not once for feature to be re-designed and/or delayed, what is wrong from the development cycle PoV. Therefore I'd like to suggest establishing dev-rules for the new feature implementation, what will make entire process much more easer for all of us: 1. discuss new feature on the mailing list (requirements/constraints/etc.) 2. summarise feature details in feature-doc 3. send feature-doc to review to: 3.1 ML (engine-devel) 3.2 MG (mailing group of maintainers of the relevant layers) 4. after feature-doc is accepted, 4.1 implement the feature 4.2 send it to gerrit for review to: 4.2.1 lead maintainer/s (they will review/delegate it) NOTE 3.2, 4.2.1 will require defining MGs such as: - engine-devel-core - engine-devel-ui - engine-devel-api - engine-devel-sdk - engine-devel-cli - engine-devel-vdsm ... Thoughts? -- Michael Pasternak RedHat, ENG-Virtualization R&D -- Michael Pasternak RedHat, ENG-Virtualization R&D

3 15

[Engine-devel] CPU Overcommit Feature
by Greg Padgett 20 Dec '12

20 Dec '12

Hi, I've been working on a feature to allow CPU Overcommitment of hosts in a cluster. This first stage allows the engine to consider host cpu threads as cores for the purposes of VM resource allocation. This wiki page has further details, your comments are welcome! http://www.ovirt.org/Features/cpu_overcommit Thanks in advance, Greg

7 18

[Engine-devel] oVirt-Foreman UI plugin
by Oved Ourfalli 20 Dec '12

20 Dec '12

Hey all, I've been working on an oVirt-Foreman UI-plugin recently, using oVirt's new UI-plugin infrastructure. It allows users to see Foreman data on oVirt entities, from inside Webadmin. I wrote a blog post describing this plugin, what can he do, some challenges that I faced and solutions, some screenshots, future work and more. Check it out at: ovedou.blogpost.com I'll be happy to hear your feedback both on the blog and on the plugin itself! If you need help installing the plugin feel free to contact me :-) Cheers, Oved

3 4

[Engine-devel] Proposal to add Shireesh Anjal as maintainer to engine-gluster
by Itamar Heim 20 Dec '12

20 Dec '12

Shireesh has been working on the engine gluster support for the past year, covering patches and leading reviews of the various engine gluster patches. I'd like to propose a new sub-component of the engine for the gluster module, adding shireesh as its maintainer. Thanks, Itamar

5 5

[Engine-devel] LDAP: Add support for simple authentication over SSL
by snmishra＠linux.vnet.ibm.com 19 Dec '12

19 Dec '12

Hi, IBM Tivoli Directory Server (ITDS) supports simple authentication over SSL. What will it take to add this support? I can help with this work item but will need some guidance. Regards Sharad Mishra

2 4

[Engine-devel] [SUGGESTION] Defining a process for the new feature discussion/implementation.
by Michael Pasternak 19 Dec '12

19 Dec '12

Hi All, In many cases OSS maintainers not always can be in the loop of different threads what may cause them missing important decisions being taken, As result later on during reviews of the patches they're not accepting (already implemented) features, what is causing not once for feature to be re-designed and/or delayed, what is wrong from the development cycle PoV. Therefore I'd like to suggest establishing dev-rules for the new feature implementation, what will make entire process much more easer for all of us: 1. discuss new feature on the mailing list (requirements/constraints/etc.) 2. summarise feature details in feature-doc 3. send feature-doc to review to: 3.1 ML (engine-devel) 3.2 MG (mailing group of maintainers of the relevant layers) 4. after feature-doc is accepted, 4.1 implement the feature 4.2 send it to gerrit for review to: 4.2.1 lead maintainer/s (they will review/delegate it) NOTE 3.2, 4.2.1 will require defining MGs such as: - engine-devel-core - engine-devel-ui - engine-devel-api - engine-devel-sdk - engine-devel-cli - engine-devel-vdsm ... Thoughts? -- Michael Pasternak RedHat, ENG-Virtualization R&D

1 0

[Engine-devel] Revisiting Java7
by Allon Mureinik 18 Dec '12

18 Dec '12

Hi guys, Earlier today, Java6 compatibility was broken (http://gerrit.ovirt.org/#/c/9430/) This was picked up on pretty quickly, and easily fixed (http://gerrit.ovirt.org/#/c/9666/) However, I think this is a good opportunity to revisit our policy towards Java 7. Currently, we have an "odd" setup, where we recommend running a compiling /with/ Java 7 [1] but comply to Java 6 language level [2] and JDK [3]. Inevitably, mistakes like the that happened today will happen. I know we're holding back due to GWT issues, but looking forward to oVirt 4.0, is Java 7 on our roadmap? -Allon [1] http://wiki.ovirt.org/Building_oVirt_engine#Installing_OpenJDK [2] maven-compiler-plugin section in ${OVIRT_GIT}/pom.xml [3] http://jenkins.ovirt.org/job/ovirt_engine_animal_sniffer_check/ P.S. If you want to check that you aren't breaking Java/JDK 6 compatibility locally without installing java 6, you can run "mvn animal-sniffer:check". Note that animal sniffer analyzes binaries, so this has to be done /after/ the project was built. Of course, you can do this in a single line "mvn install animal-sniffer:check"

7 10

[Engine-devel] [Draft]Task Management API
by Saggi Mizrahi 18 Dec '12

18 Dec '12

Dan rightly suggested I'd be more specific about what the task system is instead of what the task system isn't. The problem is that I'm not completely sure how it's going to work. It also depends on the events mechanism. This is my current working draft: TaskInfo: id string methodName string kwargs json-object (string keys variant values) *filtered to remove sensitive information getRunningTasks(filter string, filterType enum{glob, regexp}) Returns a list of TaskInfo of all tasks that their id's match the filter That's it, not even stopTask() As explained, I would like to offload handling to the subsystems. In order to make things easier for the clients every subsystem can choose a filed of the object to be of type OperationInfo. This is a generic structure that the user has a generic way to track all tasks on all subsystem with a report interface. The extraData field is for subsystem specific data. This is where the storage subsystem would put, for example, imageState (broken, degraded, optimized) data. OperationInfo: operationDescription string - something out of an agreed enum of strings vaguely describing the operation at hand for example "Copying", "Merging", "Deleting", "Configuring", "Stopped", "Paused", .... They must be known to the client so it can in turn translate it in the UI. The also have to remain relatively vague as they are part of the interface meaning that new values will break old clients so they have to be reusable. stageDescription - Similar to operation description in case you want more granularity, optional. stage (int, int) - (5, 10) means 5 out of 10. 1 out of 1 implies the UI to not display stage widgets. percentage - 0-100, -1 means unknown. lastError - (code, message) the same errors that can return for regular calls extraData - json-object For example creatVM will return once the object is created in VDSM. getVmInfo() would return, amongst other things, the operation info. For the case of preparing for launch it will be: {"Creating", "configuring", (2, 4), 40, (0, ""), {state="preparing for launch"}} In the case of VM paused on EIO: {"Paused", "Paused", (1, 1), -1, (123, "Error writing to disks"), {state="paused"}} Migration is a tricky one, it will be reported as a task while it's in progress but all the information is available on the image operationInfo. In the case of Migration: {"Migration", "Configuring", (1, 3), -1, (0, ""), {status="Migrating"}} For StorageConnection this is somewhat already the case but in simplified version. If you want to ask about any other operation I'd be more then happy to write my suggestion for it. Subsystems have complete freedom about how to set up the API. For Storage you have Fixes() to start\stop operations. Gluster is pretty autonomous once operations have been started. Since operations return as soon as they are registered (persisted) or fail to register, it makes synchronous programming a bit clunky. vdsm.pauseVm(vmId) doesn't return when the VM is paused but when VDSM committed it will try to pause it. This means you will have to poll in order to see if the operation finished. For gluster, as an example, this is the only way we can check that the operation finished. For stuff we have a bit more control over vdsm will fire events using json-rpc notifications sent to the clients. The will be in the form of: {"method": "alert", "params": { "alertName": <subsystem>(.<objectType>)?.<object>.(<subobject>., ...), "operationInfo", OperationInfo} } The user can register to recive events using a glob or a regexp. registering to vdsm.VM.* pop every time any VM has changed stage. This means that whenever the task finishes, fails or gains significance progress and VDSM is there to track it, an event will be sent to the client. This means that the general flow is. # Register operation vmID = best_vm host.VM.pauseVM(vmID) while True: opInfo = None try: event = host.waitForEvent("vdsm.VM.best_vm", timeout=10) opInfo = event.opInfo except VdsmDisconnectionError: host.waitForReconnect() host.vm.getVmInfo(vmID) # Double check that we didn't miss the event continue except Timeout: # This is a long operation, poll to see that we didn't miss any event # but more commonly, update percentage in the UI to show progress. vmInfo = host.vm.getVmInfo(vmID) opInfo = vmInfo.operationInfo if opInfo.stage.number != op.stage.total: # Operation in progress updateUI(opInfo) else: # Operation completed # Check that the state is what we expected it to be. if oInfo.extraData.state == "paused": return SUCCESS else: return opInfo.lastError vdsm.waitForEvent(filterm, timeout) is a client side libvdsm helper operation. Clients that access the raw API need to create thir own client side code to filter out events and manage their distribution. I'm open to also defining server side filters but I'm not sure whether it's worth it or just having it be a boolean (all events or none) is sufficient. This is a very simplified example but the general flow is clear. Even if the connection is lost for 1 second or 4 days, the code still works. Further more, the user can wait for multiple operations in the same thread using: host.waitForEvent("vdsm.VM.(best_vm_ever|not_so_good_vm)") This means that the client can wait for a 100 VMs or all VMs (using wildecards) in a mechanism similar "poll()" with minimal overhead. This also means that if The fact that operations are registered means that even if connections is lost due to VDSM crashing or the network crashing, the manager doesn't need to care one the original command returns as it know the operation registered. This doesn't mean that every operation must retry forever. How persistent every method is can and should change between the different operations. Also, it means that manager that didn't initiate an operation track it in the same way as those that did. This makes clustered managers a lot easier to implement as if one goes down a second one can more or less immediately with minimal extra code.

2 1