vdsm-devel December 2011

vdsm-devel@lists.stg.fedorahosted.org

25 participants
21 discussions

AUTO: Yih-Herng Chuang is out of the office (returning 12/13/2011)
by Yih-Herng Chuang 09 Dec '11

09 Dec '11

I am out of the office until 12/13/2011. I will respond to emails when return back to office. If there is an emergency please contact Doug Jans for technical issues or my manager Carol Roth. Note: This is an automated response to your message "vdsm-devel Digest, Vol 7, Issue 13" sent on 12/9/2011 5:00:17. This is the only notification you will receive while this person is away.

1 0

ovirt-guest-agent memory statistics
by agl＠us.ibm.com 08 Dec '11

08 Dec '11

To support decisions regarding a host's capacity to run virtual machines, it is useful to have an expanded set of guest memory statistics. These should be collected by the ovirt-guest-agent and made available by the vdsm getVmStats() API. Once this has been done, it will be possible to write a host-side MOM policy for auto-ballooning. The current set of vetted memory stats is published in the virtio specification: http://ozlabs.org/~rusty/virtio-spec/virtio-0.9.3.pdf (Appendix G, page 42) swap_in - the total number of pages swapped in swap_out - the total number of pages swapped out minflt - the total number of minor page faults majflt - the total number of major page faults memfree - the amount of memory that is completely unused (in Linux: MemFree) memtot - the total amount of available memory (in Linux: MemTotal) In Linux, these values can all be obtained by reading /proc/meminfo and /proc/vmstat. On Windows there is an existing implementation in the virtio balloon driver. How does everyone feel about adding these to the current set of guest stats? -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

2 1

API design and plan
by agl＠us.ibm.com 08 Dec '11

08 Dec '11

Hi everyone. On today's VDSM call we discussed the requirements, design, and plan for updating the API to include support for QMF and single-host REST API. All members present arrived at a general consensus on the best way to design the next-generation API. I have tried to capture this discussion in the oVirt wiki: http://ovirt.org/wiki/Vdsm_API Please take a look at this page and let's discuss any changes that may be needed in order to adopt it as a working plan that we can begin to execute. Thanks! -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

4 8

Fix error message "UnboundLocalError: local variable 'path' referenced before assignment" when running vm.
by Jarod.w 08 Dec '11

08 Dec '11

Hi, All The patch will fix error message "UnboundLocalError: local variable 'path' referenced before assignment" when running vm. thanks. >From 1f99c4f5b04100231c8712f2caf97d11dcc9eb37 Mon Sep 17 00:00:00 2001 From: "jarod.w" <work.iec23801(a)gmail.com> Date: Tue, 6 Dec 2011 14:00:58 +0800 Subject: [PATCH] Fix error message "UnboundLocalError: local variable 'path' referenced before assignment" when running vm. When the drive argument can't be parsed in _prepareVolumePath function, the self.log.info statement will report the error in the /var/log/vdsm/vdsm.log because the local variable 'path' isn't assigned. The patch adds the else statement to assign the local variable. --- vdsm/clientIF.py | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/vdsm/clientIF.py b/vdsm/clientIF.py index 9d6b942..10e3a24 100644 --- a/vdsm/clientIF.py +++ b/vdsm/clientIF.py @@ -590,6 +590,9 @@ class clientIF: path = drive elif os.path.exists(drive): path = drive + else: + self.log.info("invaild drive : %s" % str(drive) ) + path = '' self.log.info("prepared volume path: %s" % path) return path -- 1.7.7.3

3 4

reorganizing constants and config
by smizrahi＠redhat.com 06 Dec '11

06 Dec '11

I want to suggest a different way of handling constants.py and config.py the current way is clumsy and makes making convoluted code easy. GLOBAL VARIABLES ARE BAD. It's not something I invented. It's well accepted that proper scoping yields better code. The way we use those two files shows how much of a mess globally accessible variable can be. Not putting paths to executable in constants.py ----------------------------------------------- Instead we should have a module for each utility executable. The module should wrap the utility with a pythonic interface. That way there is no reason for more then one module to have access to a utility's path. For example: cat.py ------ _CAT_PATH = @CAT_PATH@ def cat(files): cmd = [_CAT_PATH] + files out, err = exec(cmd) return out Now there is no need to know where cat is. You have a proper interface to use. Preventing people from re-wrapping the utility over and over. This in turn means you have a canonical wrapper that is more likely to work. Every other constant -------------------- Other constants should be moved to their proper modules and used only when importing the module makes sense this will give you another step where you make sure your decencies are correct. Configuration ------------- Configuration files are just parameters to the program. They should be treated as such. Their scope should not leave the main class of the project. In our case VDSM is actually 2 projects meshed together like Siamese twins so I think clientIf.py and hsm.py should be the only ones with access to the config. Everything else should expect to get those values in a regular programmatic fashion. In my opinion these changes will make VDSM a lot more flexible, will make more parts independent and easily separated and at that end help us make VDSM better for generations to come. You can help! ------------- * Start by taking you favorite utility and write a proper safe module around it. * When writing new code try and not access the configuration directly. * Modules are free (really) don't just put stuff in misc\utils try and put some order to things.

3 6

can't start vdsmd and failed to connect it
by Jenna Johnson 06 Dec '11

06 Dec '11

Folks, Installed vdsm,nothing abnormal encountered,but when start vdsmd: $ sudo service vdsmd start vdsm: libvirt already configured for vdsm [ OK ] Starting iscsid: Starting libvirtd daemon: Starting up vdsm daemon: vdsm start [ OK ] $ sudo service vdsmd status VDS daemon is not running and then all connctions fail: $ vdsClient -s 0 getVdsCapabilities Connection to 0:54321 refused Any thoughts?

3 6

VDSM Sync Call proposed agenda for next Monday
by abaron＠redhat.com 03 Dec '11

03 Dec '11

Hi all, On the agenda 1. I would like to finalize details about the API (QMF/REST-API) 2. ??? Regards, Ayal.

2 2

Proposed next-generation vdsm API
by agl＠us.ibm.com 03 Dec '11

03 Dec '11

Recently we've had some very productive discussions concerning the VDSM API. I want to attempt to refocus the discussion around an emerging proposal and see if we can agree on a sensible path forward. Based on the discussion, I have identified the following requirements that a new API for vdsm should have: 1.) Single API that can be consumed by ovirt-engine and ISVs - We don't want to maintain multiple parallel APIs - To develop a vendor ecosystem, we must have a robust external API to vdsm 2.) Full vdsm capabilities are exposed without requiring ovirt-engine - ovirt components should be modular and independently useful - Some deployments might want to manage nodes without ovirt-engine 3.) Standardized protocol with low overhead - Required for widespread adoption 4.) Support for asynchronous tasks and events - Needed by ovirt-engine and other consumers Based on these requirements, the following proposal has started to emerge: Create a REST API that will provide all of the functionality that is currently available via the xmlrpc interface (with the goal of deprecating xmlrpc once it becomes mature enough). To support advanced clustering features that ovirt-engine is planning, we'll write an QMF broker that can proxy the REST API onto a message bus. ovirt-engine will interact with vdsm exclusively over this bus but the REST API will be the principle API and the entry point for ISV apps. A REST API provides a light-weight and standard way to access all of the vdsm functionality. The REST API will handle events by exposing a new 'events' collection at the api root. REST users will use some sort of polling to collect these events. The details of this interface are being worked on. Several ways for minimizing the impact of polling have been discussed. The QMF broker can expose a publish/subscribe model for events as appropriate. Is this model an acceptable way to improve the vdsm API? I would like to hear the opinions of ovirt-engine developers, vdsm developers, and other stakeholders. Thanks for providing feedback on this proposal! -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

7 13

AUTO: Yih-Herng Chuang is out of the office (returning 12/05/2011)
by Yih-Herng Chuang 02 Dec '11

02 Dec '11

I am out of the office until 12/05/2011. I will respond to emails when return back to office. If there is an emergency please contact Doug Jans for technical issues or my manager Carol Roth. Note: This is an automated response to your message "vdsm-devel Digest, Vol 7, Issue 3" sent on 12/2/2011 5:00:48. This is the only notification you will receive while this person is away.

1 0

Announcing the VDSM Fedora Packages
by Federico Simoncelli 02 Dec '11

02 Dec '11

The VDSM team and its community are proud to announce the first release of the fedora RPMs: https://koji.fedoraproject.org/koji/packageinfo?packageID=12944 (upstream master branch, hash: 931a43e) You are all invited to download and test the new packages reporting your feedback here or, when required, filing a new bug on bugzilla: https://bugzilla.redhat.com/enter_bug.cgi?product=oVirt&component=vdsm Thanks/congratulations to all people that contributed to achieve this important milestone. Happy testing, -- Federico

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

vdsm-devel December 2011