- Devel - oVirt List Archives

Re: [ovirt-devel] Sanlock fencing reservations
by Nir Soffer 01 May '14

01 May '14

----- Original Message ----- > From: "Saggi Mizrahi" <smizrahi(a)redhat.com> > To: "arch" <arch(a)ovirt.org> > Cc: "Nir Soffer" <nsoffer(a)redhat.com>, "David Teigland" <teigland(a)redhat.com> > Sent: Wednesday, February 26, 2014 6:14:33 PM > Subject: Sanlock fencing reservations > > I've recently been introduced to the this feature and I was wondering is this > really > the correct way to go for solving this particular problem. > > My main issue is with making two unrelated flow dependent. Hi Saggi, Sorry for the late response. The flows are related - sanlock already fencing as part of the lease and resources keeping. > By pushing this into the existing sanlock data structures you limit yourself > in the future from changing either to optimize or even solve problems for a > single use case. I agree, we have 196 unused bits in the sanlock lease, which can be used for other needs if we don't used them the new host_message api. We can keep the extra space forever - or use it now. > > Having an independent daemon to perform this task will give more room as to > how to implement the feature. I agree, but we are not designing this system from scratch, and adding this feature to the existing daemon is easy and makes sense. I thinks this is a good trade-off. > > I don't want to reach a situation where we need to change a sanlock struct > and not be able to do it as it makes problems with fencing flows. This is the price for choosing this way. > > I believe in the mantra that things should do one thing and do it well. > This feels like an ad-hoc solution to a very niche problem. > > > Further more, it kind of seems like a mailbox issue. > Leaving a fencing request is just a message. In the > future I can see it just being a suspend-to-disk request > so that you don't even have to fence the host in such cases. > > The only reason I see people putting it to sanlock is > that it's a daemon that reads from disk and has does fencing. > > I agree that in VDSMs current state putting this in the mailbox > is unreliable to say the least but it doesn't mean that we can't > have a small independent daemon to do the task until we get > messaging in VDSM to a stable state. > > IMHO it's better than having it as and ad-hoc feature to sanlock. > A feature which we can't remove later as someone might depend on it. > A feature that might limit us or that we might even abandon once we > have more reliable disk based messaging in VDSM. > I don't think we need another daemon that duplicate most of what sanlock is doing now, and I would not mix critical messages (fencing) with everyday messages in such new messaging solution. Regards, Nir

1 0

oVirt sources tagging
by Sandro Bonazzola 01 May '14

01 May '14

Hi, today I've seen that ovirt-hosted-engine-ha was missing proper tagging of version released. I've not checked all projects so this is just a reminder. Maintainers, please ensure that all previous releases are properly tagged (at least GA ones, but RC and beta are recommended too) and please remember to tag each time you release a new tarball. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

UI plugins using REST API
by Vojtech Szocs 30 Apr '14

30 Apr '14

Hi guys, just a quick note on UI plugin vs. REST API integration, there are currently two ways to work with REST API: * (standard) /ovirt-engine/api * (legacy) /api Please don't use the legacy URL, since "sessionId" that is acquired via RestApiSessionAcquired event handler [1] works only for the standard URL. (Also, don't forget to include "Prefer:persistent-auth" header when making calls that shouldn't close the session.) [1] http://www.ovirt.org/Features/UIPlugins#REST_API_integration Regards, Vojtech

4 7

oVirt 3.4.1 branching
by Sandro Bonazzola 30 Apr '14

30 Apr '14

Hi, we're going to create ovirt-engine-3.4.1 branch tomorrow morning 08:00 UTC in order to allow 3.4.2 development starting on 3.4 branch while we prepare for 3.4.1 GA release. So starting tomorrow morning, if you have patches targeted to 3.4.1 you'll need to push them on 3.4.1 branch too. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 1

short recap of today's vdsm call (29.4.2014)
by Dan Kenigsberg 30 Apr '14

30 Apr '14

Few things mentioned on today's call: - ovirt-3.3 is no longer supported: only security patches need to be merged there. - fenceSpmStorage turned into noop - intenetionally - infra code is expected to move around to its own subdir, as warned 2 weeks ago. - with pthreading used, any os.fork() causes a nasty warning Bug 1084500 - threading._after_fork spews "cannot notify on un-acquired lock" when os.fork is called from a thread - a huge json-rpc by Piotr needs to be broken to manageable pieces and reviewed. - Adam to create json-to-yaml schema conversion script (as a backward task) - sanlock fencing - Saggi's worries are to be addressed on the mailing list thread.

1 0

Re: [ovirt-devel] [vdsm] Missing numactl
by Vinzenz Feenstra 29 Apr '14

29 Apr '14

Seems pretty much like it On 04/28/2014 12:30 PM, Piotr Kliczewski wrote: > Hello, > > I pulled the latest changes from master to test my code and during > getCaps I got: > > Thread-14::ERROR::2014-04-28 > 12:11:44,394::__init__::484::jsonrpc.JsonRpcServer::(_serveRequest) > [Errno 2] No such file or directory > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line > 480, in _serveRequest > res = method(**params) > File "/usr/share/vdsm/Bridge.py", line 211, in _dynamicMethod > result = fn(*methodArgs) > File "/usr/share/vdsm/API.py", line 1184, in getCapabilities > c = caps.get() > File "/usr/share/vdsm/caps.py", line 459, in get > caps['numaNodeDistance'] = _getNumaNodeDistance() > File "/usr/lib64/python2.7/site-packages/vdsm/utils.py", line 1003, > in __call__ > value = self.func(*args) > File "/usr/share/vdsm/caps.py", line 209, in _getNumaNodeDistance > retcode, out, err = utils.execCmd(['numactl', '--hardware']) > File "/usr/lib64/python2.7/site-packages/vdsm/utils.py", line 732, in execCmd > deathSignal=deathSignal, childUmask=childUmask) > File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line > 50, in __init__ > stderr=PIPE) > File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__ > errread, errwrite) > File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line > 80, in _execute_child_v275 > self._childUmask) > OSError: [Errno 2] No such file or directory > > When I installed numactl rpm getCaps work again. > > Do we need to add this dependency to spec file? > > Thanks, > Piotr > _______________________________________________ > vdsm-devel mailing list > vdsm-devel(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel -- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

[Devel] QoS Aggregate
by Gilad Chaplik 29 Apr '14

29 Apr '14

Hi list, While oVirt is rapidly continues to grow and gather features, it’s important to wrap already existing features with new ones, for better UX reasons. In oVirt 3.5, there are going to be 2 new QoS objects, CPU limits and blkio limits, added to the existing one network QoS (since 3.3). You are more than welcome to review my proposal to aggregate all features under the same umbrella: http://www.ovirt.org/Features/aggregate_QoS Thanks, Gilad.

2 4

Cooking with Python?
by Nir Soffer 29 Apr '14

29 Apr '14

You may like this free (as beer) online version: http://chimera.labs.oreilly.com/books/1230000000393 Nir

1 0

Fwd: [vdsm] Missing numactl
by Piotr Kliczewski 28 Apr '14

28 Apr '14

Hello, I pulled the latest changes from master to test my code and during getCaps I got: Thread-14::ERROR::2014-04-28 12:11:44,394::__init__::484::jsonrpc.JsonRpcServer::(_serveRequest) [Errno 2] No such file or directory Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 480, in _serveRequest res = method(**params) File "/usr/share/vdsm/Bridge.py", line 211, in _dynamicMethod result = fn(*methodArgs) File "/usr/share/vdsm/API.py", line 1184, in getCapabilities c = caps.get() File "/usr/share/vdsm/caps.py", line 459, in get caps['numaNodeDistance'] = _getNumaNodeDistance() File "/usr/lib64/python2.7/site-packages/vdsm/utils.py", line 1003, in __call__ value = self.func(*args) File "/usr/share/vdsm/caps.py", line 209, in _getNumaNodeDistance retcode, out, err = utils.execCmd(['numactl', '--hardware']) File "/usr/lib64/python2.7/site-packages/vdsm/utils.py", line 732, in execCmd deathSignal=deathSignal, childUmask=childUmask) File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line 50, in __init__ stderr=PIPE) File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__ errread, errwrite) File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line 80, in _execute_child_v275 self._childUmask) OSError: [Errno 2] No such file or directory When I installed numactl rpm getCaps work again. Do we need to add this dependency to spec file? Thanks, Piotr

1 0

new feature
by Martin Mucha 28 Apr '14

28 Apr '14

Hi, I'd like to notify you about new feature, which allows to specify distinct MAC pools, currently one per data center. http://www.ovirt.org/Scoped_MacPoolManager any comments/proposals for improvement are very welcomed. Martin.

6 23