February 2013 - vdsm-devel - Fedora Mailing-Lists

VDSM - top 10 with patches with no activity for more than 30 days

by iheim＠redhat.com

thoughts on how to trim these? (in openstack gerrit they auto-abandon patches with no activity for a couple of weeks - author can revive them back when they are relevant) preferred_email | count ----------------------------+------ fsimonce(a)redhat.com | 34 smizrahi(a)redhat.com | 23 lvroyce(a)linux.vnet.ibm.com | 13 ewarszaw(a)redhat.com | 12 wudxw(a)linux.vnet.ibm.com | 12 xuhj(a)linux.vnet.ibm.com | 11 shaohef(a)linux.vnet.ibm.com | 6 lilei(a)linux.vnet.ibm.com | 6 zhshzhou(a)linux.vnet.ibm.com | 6 shuming(a)linux.vnet.ibm.com | 5

11 years, 1 month

6
9
0 / 0

VDSM Repository Reorganization

by Federico Simoncelli

It is some time now that we are discussing an eventual repository reorganization for vdsm. In fact I'm sure that we all experienced at least once the discomfort of having several modules scattered around the tree. The main goal of the reorganization would be to place the modules in their proper location so that they can be used (imported) without any special change (or hack) even when the code is executed inside the development repository (e.g. tests). Recently there has been an initial proposal about moving some of these modules: http://gerrit.ovirt.org/#/c/11858/ That spawned an interesting discussion that must involve the entire community; in fact before starting any work we should try to converge on a decision for the final repository structure in order to minimize the discomfort for the contributors that will be forced to rebase their pending gerrit patches. Even if the full reorganization won't happen in a short time I think we should plan the entire structure now and then eventually move only few relevant modules to their final location. To start the discussion I'm attaching here a sketch of the vdsm repository structure that I envision: . |-- client | |-- [...] | `-- vdsClient.py |-- common | |-- [...] | |-- betterPopen | | `-- [...] | `-- vdsm | |-- [...] | `-- config.py |-- contrib | |-- [...] | |-- nfs-check.py | `-- sos |-- daemon | |-- [...] | |-- supervdsm.py | `-- vdsmd `-- tool |-- [...] `-- vdsm-tool This would allow any component (daemon, client, tool, etc...) to run in place with the only addition of PYTHONPATH=$(top_srcdir)/common. The tests would need also the additional component path but that is a given since it's what they should be testing. Once the components are in the proper place we can eventually start using distutils inside the Makefile.am files in order to simplify the installation process (and also as verification that our repository structure is complying with the python standards). Please get involved, share your feedback and proposals. Thanks, -- Federico

11 years, 1 month

9
14
0 / 0

vdsm networking changes proposal

by asegurap＠redhat.com

Hi fellow oVirters! The network team and a few others have toyed in the past with several important changes like using open vSwitch, talking D-BUS to NM, making the network non-persistent, etc. It is with some of this changes in mind that we (special thanks go to Livnat Peer, Dan Kenigsberg and Igor Lvovsky) have worked in a proposal for a new architecture for vdsm's networking part. This proposal is intended to make our software more adaptable to new components and use cases, eliminate distro dependancies as much as possible and improve the responsiveness and scalability of the networking operations. To do so, it proposes an object oriented representation of the different elements that come into play in our networking use cases. But enough of introduction, please go to the feature page that we have put together and help us with your feedback, questions proposals and extensions. http://www.ovirt.org/Feature/NetworkReloaded Best regards, Toni

11 years, 1 month

6
18
0 / 0

[yajsonrpc]questions about json rpc

by shaohef＠linux.vnet.ibm.com

Hi, Adam An error arises, when I call json rpc server by AsyncoreReactor. And I can call json rpc server successfully by a simple TCPReactor write by myself. how can I call json Rpc by AsyncoreReactor correctly? >>> address = ("127.0.0.1", 4044) >>> clientsReactor = asyncoreReactor.AsyncoreReactor() >>> reactor = TestClientWrapper(clientsReactor.createClient(address)) >>> jsonAPI = JsonRpcClient(reactor) >>> jsonAPI.connect() >>> jsonAPI.callMethod("Host.ping", [], 1, 10) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/yajsonrpc/client.py", line 39, in callMethod resp = self._transport.recv(timeout=timeout) File "/usr/share/vdsm/tests/jsonRpcUtils.py", line 100, in recv return self._queue.get(timeout=timeout)[1] File "/usr/lib64/python2.7/Queue.py", line 176, in get raise Empty Queue.Empty -- Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com> IBM Linux Technology Center

11 years, 1 month

2
2
0 / 0

Meeting minutes, Feb 25

by Dan Kenigsberg

Dave Neary hates them, but we had a phone conversation anyway. Here is how it went. - Adam has posted a patchset with the new Python vdsm client. Please review (danken thinks that Vinzenz would love to volunteer here). - Danken would like to get us going with the repo re-org. Federico suggests to have two separate commits: one with `git mv` commands (documented in its comment D.K.) and another one with Makefile fixes. This way we can continue to work on other stuff while discussing the patches. Saggi was offline, and nobody protested the suggestion to have code that is shared between the client and the server, at least for now. - Adam reported a nice success story: he managed to change mom's policy to ksm + autoballoon, without a glitch to vdsm proper. - Everybody (Adam, Yaniv Bronheim, Federico) complained about the awkward supervdsm startup, and agreed to press on with a sane "start as root, fork, drop privileges" pattern. Lv Royce and Yaniv are on top of this. - Danken tried to tell a joke over the phone, about Douglas sitting across the equator. It did not work. It never does. It was nice to hear from you all, see you soon!

11 years, 1 month

1
0
0 / 0

BZ#755528

by peet＠redhat.com

… Guys, I would like to discuss with you the patchset: http://gerrit.ovirt.org/#/c/12202/ Until now we've had no ways to catch the timeout on createXML call when a VM starts. So there is no doubt we should have one. But which one, that's the question. I propose to use «transparent» keyword arguments for libvirt calls, like that: createXML(xml, 0) → createXML(xml, 0, x_timeout=5, x_ontimeout=handler) It is simple, but… a little bit hacky. But it works :) What will you say? -- Peter V. Saveliev

11 years, 1 month

1
1
0 / 0

Re: [vdsm] [Engine-devel] vdsm/zombiereaper

by Dan Kenigsberg

On Mon, Feb 18, 2013 at 04:21:16PM -0600, Dead Horse wrote: > Any movement or thoughts yet on this one: http://gerrit.ovirt.org/#/c/11492/ > > It still has vdsm master broken. Guys, I think that DHC is right - we cannot keep deliberating forever. Having a process leak is bad, but keeping master broken for so long is even worse. So unless anyone violently objects, I'll revert the offending patch. Dan.

11 years, 2 months

2
1
0 / 0

vdsm: patches last updated more than 30 days

by iheim＠redhat.com

11 years, 2 months

1
0
0 / 0

Pretty printing for vdsClient

by asegurap＠redhat.com

Hi fellow oVirters, Working with the networking side of vdsm side, I've grown tired of the looks of the output of vdsClient. Thus, I have submitted a patch: http://gerrit.ovirt.org/#/c/11979/ That pretty prints the dictionaries that are to be displayed, e.g.: This http://pastebin.test.redhat.com/127370 Becomes http://pastebin.test.redhat.com/127373 Pavel Stehlik has suggested to make this change optional as a switch to vdsClient (I guess I'd put -p|--pretty). I would like some feedback and suggestions. Best, Toni

11 years, 2 months

5
5
0 / 0

a migration issue

by peet＠redhat.com

… system: RHEL 6.3 vdsm: ovirt master head Trying to migrate a VM, created from *CLI* , I've got two errors (at least) on the target host: 1. the network interface has no «network» attribute (libvirtvm.py:936) 2. the network interface has no «macAddr» attribute (libvirtvm.py:2972) So, we have an issue 1. either in vdsClient 2. or with the migration algo 3. or with NetworkInterfaceDevice class Right now I'm tracing what's wrong there, but if you have any ideas, it will be nice. -- Peter V. Saveliev

11 years, 2 months

4
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

vdsm-devel February 2013