This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Ganeti core".
The branch, master has been updated
via 235c1a99d7c257db4013d3097a60053887120290 (commit)
via 8a63c84d2d1e145683c2ef2201f559083d84cd84 (commit)
via c032a8bbe737085ee5635f739ffe1f415539b4e8 (commit)
via c5523180492884c5ee33c9aabb411c3df334dc5a (commit)
via 96e388434d1a0eb017e51291122c42bac5c8a9e6 (commit)
via 369986a0ce86461ea66d2641c0a2607e27080c96 (commit)
via 76ffbc3b2e52d2a9da501f9d7616b628f38e9590 (commit)
via 5dc6c2bf29d3e85976d32e1e5971ed603890e052 (commit)
via 29fc3594ed042e97d88bf06383569052be856536 (commit)
via 75477697659441ab487af9c56045e84a18241426 (commit)
via 258b3f03d3f6a9e21b7d6f71d84f984f7392449d (commit)
via 8a9dc0d3c95a69b078a157b646c5b420fccd235a (commit)
via 88615f7dc7f93c86c2c4a17bf7a416548fa20952 (commit)
via e359b8542a18aeaf3addd35d9cbb87bc9ca77d2f (commit)
from f24bce01fc2e990e5e8ecce696efdf179d2d2d03 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 235c1a99d7c257db4013d3097a60053887120290
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 12:48:21 2014 +0100
Remove NAL and its level from WConfD
...as no one will ask for it any more.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit 8a63c84d2d1e145683c2ef2201f559083d84cd84
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 12:45:26 2014 +0100
Remove NAL and its level from Python lock hierarchy
...as it is not used any more.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit c032a8bbe737085ee5635f739ffe1f415539b4e8
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 12:40:59 2014 +0100
Node operations without NAL
...even if all nodes are affected. Having the node locks is enough,
as jobs know how to wait for enough nodes to become available.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit c5523180492884c5ee33c9aabb411c3df334dc5a
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 12:38:20 2014 +0100
Cluster-wide operations without NAL
As locking all nodes suffices to block conflicting
jobs; opportunistically locking jobs know how to wait
for enough locks.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit 96e388434d1a0eb017e51291122c42bac5c8a9e6
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 12:34:45 2014 +0100
Verify groups without NAL
Even though all node locks are acquired, there is no need to
get the node allocation locks; jobs using opportunistic locking
know how to wait for enough locks.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit 369986a0ce86461ea66d2641c0a2607e27080c96
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 12:25:17 2014 +0100
Verify group without NAL
...as the node locks already lock enough and jobs
using opportunistic locking know how to wait for
enough locks.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit 76ffbc3b2e52d2a9da501f9d7616b628f38e9590
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 12:19:05 2014 +0100
OOB without NAL
Even in cases where out-of-band operations acquire all node
locks, there is no need to warn other processes, as the node
locks themselves serve this purpose.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit 5dc6c2bf29d3e85976d32e1e5971ed603890e052
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 12:16:55 2014 +0100
Instance multi allocation and group change without NAL
Again, while allocation is going on, all jobs know how to
wait for the needed locks without relying on the node allocation
lock.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit 29fc3594ed042e97d88bf06383569052be856536
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 12:13:46 2014 +0100
Instance migration without NAL
Even if doing node allocation, there is no need for the
node allocation lock, as the nodes themselves are locked.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit 75477697659441ab487af9c56045e84a18241426
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 11:58:22 2014 +0100
Handle backups without NAL
Again, while taking all nodes, there is no need to stop
allocation.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit 258b3f03d3f6a9e21b7d6f71d84f984f7392449d
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 11:48:29 2014 +0100
Add networks without asking for NAL
Again, while network addition asks for a shared lock
on all nodes, it is no longer necessary to ask for
the node allocation lock, as jobs doing opportunistic
locking know how to wait for enough free locks.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit 8a9dc0d3c95a69b078a157b646c5b420fccd235a
Author: Klaus Aehlig <[email protected]>
Date: Fri Dec 5 11:17:03 2014 +0100
Replace and Recreate disks without using NAL
These operations may run the IAllocator to decide on
where to create a new disk and hence ask for a lot
of node locks. Therefore, it was necessary to ask for
the node allocation lock in order to protect jobs
using opportunistic locking from running out of
nodes. This necessity does not exist any more, hence
don't ask for the node allocation lock either.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit 88615f7dc7f93c86c2c4a17bf7a416548fa20952
Author: Klaus Aehlig <[email protected]>
Date: Thu Dec 4 14:19:28 2014 +0100
Create instances without NAL
With the new locking library it is no longer necessary to
avoid simultaneous requests for lots of node locks; every
job will wait till enough locks are available.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
commit e359b8542a18aeaf3addd35d9cbb87bc9ca77d2f
Author: Klaus Aehlig <[email protected]>
Date: Thu Dec 4 13:15:04 2014 +0100
In mcpu, do not insist on NAL being acquired
The NAL (Node allocation lock) originally was added to prevent
jobs needing many locks from starving instance creation with
opportunistic locking. However, with the new lock mechanism,
jobs opportunistically locking can wait till the required minimum
number of locks is available. So the use of NAL has become
optional.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Niklas Hambuechen <[email protected]>
-----------------------------------------------------------------------
Summary of changes:
lib/cmdlib/backup.py | 12 ----
lib/cmdlib/base.py | 1 -
lib/cmdlib/cluster/__init__.py | 8 ---
lib/cmdlib/cluster/verify.py | 5 --
lib/cmdlib/group.py | 6 --
lib/cmdlib/instance.py | 7 +--
lib/cmdlib/instance_create.py | 3 -
lib/cmdlib/instance_migration.py | 17 +-----
lib/cmdlib/instance_storage.py | 6 --
lib/cmdlib/misc.py | 6 --
lib/cmdlib/network.py | 2 -
lib/cmdlib/node.py | 6 --
lib/locking.py | 14 +----
lib/mcpu.py | 53 ----------------
src/Ganeti/Locking/Locks.hs | 12 ----
test/hs/Test/Ganeti/Locking/Locks.hs | 2 -
test/py/ganeti.mcpu_unittest.py | 110 ----------------------------------
17 files changed, 3 insertions(+), 267 deletions(-)
hooks/post-receive
--
Ganeti core
--
---
You received this message because you are subscribed to the Google Groups
"ganeti-commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
