core: Make the number of concurrent vds and irs connections configurable

Allow tuning of apache HttpClients MaxConnectionsPerHost and
MaxTotalConnections values, to increase command throughput.

- Add VdsMaxConnectionsPerHost and IrsMaxConnectionsPerHost config
values. Each value is used for specific type of the connection, with
default 2, which is the value in use without tuning
- Add MaxTotalConnections config value which determines maxiumum number
of allowed connections, with default 20, which is the value in use
without tuning


Change-Id: Id6a7e2bc0f6865e41dd85ab1fd188625cab22ddf
Bug-Url: https://bugzilla.redhat.com/1168538
Signed-off-by: Tim Speetjens <tim.speetjens@redhat.com>
Signed-off-by: pkliczewski <piotr.kliczewski@gmail.com>
jsonrpc: version bump

Changing the ordering to mitigate rebase conflicts.


Change-Id: Ib22057574a52527a2a3f205dd58e1303a044ec23
Signed-off-by: pkliczewski <piotr.kliczewski@gmail.com>
Bug-Url: https://bugzilla.redhat.com/1172757
aaa: fix session timeout

The fix is done by the following ways:
a. Public Queries which do not require user should not perform session refresh (they should be agnostic to it)
b. The API resource should not perform refresh as well
Change-Id: I6640beef3ca28f95def87ac5e29d41f75b0fddd8
Topic: AAA
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1168842
Signed-off-by: Yair Zaslavsky <yzaslavs@redhat.com>
webadmin: Export template help tag incorrectly dispalys export vm help

Change-Id: I0fb15ede6a2d6b489e21e858b3cd274caddbc5f3
Bug-Url: https://bugzilla.redhat.com/1174043
Signed-off-by: Tal Nisan <tnisan@redhat.com>
aaa: two providers produce the same "domain id"

This may occur if two authz names have the same prefix that gets
converted to the same Guid.
This happens as the Guid ctor that receives an array of bytes needs
only the first 16 bytes to consturct a guid and ignores the rest.
The fix suggest an id that is based on base64 encoding of the entire string.

Change-Id: Ieddb2c31645d7276652db17df190bc4f2cfdaacb
Bug-Url: https://bugzilla.redhat.com/1172187
Topic: AAA
Signed-off-by: Yair Zaslavsky <yzaslavs@redhat.com>
aaa: fix error messages of basic authentication filter

Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1174731
Change-Id: I3ec060ee36bc94a2c8b40501358b21e4da44c4ca
Signed-off-by: Alon Bar-Lev <alonbl@redhat.com>
core: avoid saving duplicate records when saving LUN connections

When adding a LUN to the db, StorageHandlingCommandBase.proceedLUNInDb()
is executed. Among its other operations, this method checks if
connections with the same details as the LUN connections already exists
by executing Getstorage_server_connectionsByKey and if not a new connection
record is being saved, otherwise the existing one is used.

Getstorage_server_connectionsByKey currently checks if connection with the same
details exists according to the iqn, connection, port, portal username
and password fields - the problem is that those fields could be
set and persisted with with empty string or null, which will lead to
duplicate records.

*This patch only avoid having empty string in those fields - further
patch will fix the current state in the db and will add proper
contraints.

*Further fix that's done in this patch is to remove the password field
from Getstorage_server_connectionsByKey - each time we save/fetch a
connection from the db by it's details we encrypt the password - as the
encrypted password is different each time, we'll never be able to fetch
an existing record.

Change-Id: I997ba0fbc6e984a9e6782502c6b36b1f9a1f3d8c
Bug-Url: https://bugzilla.redhat.com/1173951
Signed-off-by: Liron Aravot <laravot@redhat.com>
webadmin: Add help tag for import storage domain

Change-Id: Ic5955a050dc30b9a98b52a09e2603db0a657976b
Bug-Url: https://bugzilla.redhat.com/1174042
Signed-off-by: Tal Nisan <tnisan@redhat.com>
webadmin: Added help tag to attach storage to data center dialog

Change-Id: I98530b5e3e774222e5fb38add850c087ee4d8194
Bug-Url: https://bugzilla.redhat.com/1174045
Signed-off-by: Tal Nisan <tnisan@redhat.com>
aaa: Stop constant synchronization of admin@internal

The following changes are required -
a. when reading group_ids from db - an empty string of group_ids  should not become
a a set containing the "zero" guid, but should be an empty set.
b. group_ids should not have sub strings of "zero" guids
c. equals of DbUser should not check isAdmin

Bug-Url: https://bugzilla.redhat.com/1175046
Change-Id: I5a7660f813b7926b4193ebeb39b3c2a5f07550b4
Topic: AAA
Signed-off-by: Yair Zaslavsky <yzaslavs@redhat.com>
core: improve exception handling on run vm

In case an exception is thrown when calling the 'create' verb in VDSM
and there is no point to retry to run the VM on other host, we used to
just re-throw the exception in RunVmCommand to prevent the rerun
mechanism from taking place.

The problem is that this way the pending resources were not cleared
in this flow. The solution is to improve the error handling:
1. If Done/exists exception was thrown, we call the reportCompleted to
decrease the pending resources
2. If VDS_NETWORK_ERROR/PROVIDER_FAILURE exception was thrown, we call
the runningFailed to decrease the pending resources (in this case, the
VM should be treated as if it went down, we should remove its
stateless snapshot if such snapshot exists for example).

Change-Id: Iee3bdb65ca58c49de65770d4e9cf9435bbbe5070
Bug-Url: https://bugzilla.redhat.com/1174817
Signed-off-by: Arik Hadas <ahadas@redhat.com>
core: decrement pending vm on 'run in paused mode'

In a flow where VM is started in paused state neither of
runningSucceeded nor runningFailed methods in RunVmCommand are called.
The command is kept in the collection of async commands until the VM
will be resumed.

On resume, the reportCompleted method of the original RunVmCommand will
be called and it will be removed from the async command collection.
Thus, the pending resources are not cleared in this flow.

The solution is to decrease the pending resources in the reportCompleted
method if they were not decreased before.

Change-Id: Icc931118a848c1c7507c407d955537761dd1a742
Bug-Url: https://bugzilla.redhat.com/1174816
Signed-off-by: Arik Hadas <ahadas@redhat.com>
engine: Prevents duplicates parameters in multiple actions

The multiple action runner api serves as a method for
invoking multiple actions in a single call to the engine.
However, it turns out that due to a mysterious bug, in few
flows the UI provides the same parameter more than once which
might lead to an unexpected behavior (i.e. infinite locked vm).

By replacing the parameters collection type to set we prevent
that from happen, and each parameter class will implement its
own euqals() and hasCode() methods to enforce the uniqueness.

Change-Id: Ic874d31535d2189f934d629e689aa7a534c165d5
Bug-Url: https://bugzilla.redhat.com/1174815
Signed-off-by: Moti Asayag <masayag@redhat.com>
core: filter duplicate requests to run the same vm

If engine gets multiple requests to run the same VM at the same time
(with MultipleActionRunner), we might get into a situation where the VM
does not run and kept locked.

Say we got 2 run requests for the same VM:
- The first command acquires the lock for the VM
- The second command fails to acquire the lock
- The can-do-action phase of the first command succeed
- We sort the commands before invoking them. As part of the sort, we map
  Id of VM to its run command. Since we iterate the commands in the same
  order they were received, we end up with mapping the second command
- Since the second command didn't manage to acquire the lock, it won't
  run
Since the first command does not run, it won't release its lock.

The solution is to filter the given parameters from duplicate requests
to run the same VM. We now override the hashCode and equals methods in
RunVmParams class so if we will get duplicate instances, they will be
filtered while we insert them to a Set in MultipleActionRunner.

Change-Id: I91320cfd50fc7a12b01afae2885a783c0516a6df
Bug-Url: https://bugzilla.redhat.com/1174815
Signed-off-by: Arik Hadas <ahadas@redhat.com>
core: fix removal of attached disks to stateless vm

Change the way we handle disks when stateless VM goes down, to
prevent situations where disks are being removed. This might happen
when disk is attached to stateless VM while it was running (hot-plug)
so no snapshot was taken for it as part of the stateless snapshot of
the VM, and when restoring the stateless snapshot we'll remove it.

The solution is to find disks which don't have volumes attached to the
stateless snapshot and to detach them from the VM before restoring the
stateless snapshot.

Change-Id: I3a1d6eb8d2f4606622c7ed5c73370792406bb9b3
Bug-Url: https://bugzilla.redhat.com/1174812
Signed-off-by: Arik Hadas <ahadas@redhat.com>
Merge remote branch 'origin/ovirt-engine-3.5' into EayunOS-41-Theme_For-cherry-pick