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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
Handle backups without NAL

Again, while taking all nodes, there is no need to stop
allocation.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
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 <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
Remove NAL and its level from Python lock hierarchy

...as it is not used any more.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
Remove NAL and its level from WConfD

...as no one will ask for it any more.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
Mention instance reservation in NEWS

Instance reservation is a new feature to Ganeti 2.14. While this
version of Ganeti will only contain basic support, it still changes
the way Ganeti thinks about instance. Hence users should be made
aware of this feature.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>
Support failover for forthcoming instances

...by simply changing the configuration and not doing
anything in the real world.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
Move out the updating nodes in disk configuration

...to a separate method. In this way it can be reused
for both replacing disks of real, and of forthcoming
instances.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
Support replacing disks for forthcoming instances

...by just modifying the configuration and not changing
anything in the real world.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Niklas Hambuechen <niklash@google.com>
Document --forthcoming does not imply other options

So, in particular, for not yet propagated instance names,
the option --no-name-check and --no-ip-check must be passed
explicitly.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>
Support renaming forthcoming instances

Allow changing the name of a forthcoming instance. Again,
this happens only in the configuration.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>