core: Extracting OvfDataUpdater logic to commands

This patch moves the ovf update logic resides within the
OvfDataUpdater to BLL commands, so that it can be executed easily by
other flows as well.
The logic was mainly moved to ProcessOvfUpdateForStoragePoolCommand,
tests were added accordingly.

Change-Id: I6780aedf2d215d08c4bed0ff4f7520c45f753f66
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1138124
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: Adding context ctor ProcessOvfUpdateForStorageDomain

Change-Id: Ia170d17191b3fd541fa4b0d695a94e3ed06dee72
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1138124
Signed-off-by: Yair Zaslavsky <yzaslavs@redhat.com>
core: perform ovf update for domain when it's deactivated

When a storage domain is being deactivated, we can attempt to perform an
ovf update to that domain if the data center version supports it, if the
update fails the domain will still be moved to maintenance.

Ovf stores are created for a domain according to the config
value StorageDomainOvfStoreCount on each OvfDataUpdater run, so the same
case should be supported on deactivation of domain (OVF stores will be
created if needed).

Change-Id: I54cc929937d3b14dc49a2edab9e763cbe603a9c3
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1138124
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: handling of possible race when deactivating domain

When deactivating the last  master domain a new thread is started to make sure that
the domain is deactivated only after the tasks are cleared.
In case of engine crash during that time the domain may remain in status
LOCKED, because nothing will restart the thread on the engine start (as
the tasks were cleared).
The infrastructure that we currently have to handle that case is the
compensation context, in this patch i create a compensation context that
will assure that the domain will return to the appropiate status in case
of an engine crash.

Change-Id: If4e482a2a13741e8b4509851d9d8e4645d8b81e6
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1138124
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: jobs/steps/audit log handling for domain deactivation

When a Storage Domain is being deactivated, we first attempt to update
the OVF data on the domain and only afterward attempt to deactivate it.
The OVF update phase may contain create volume operations (in case more
OVF stores are needed) and upload image operations afterwards (to update
OVF data contained on the OVF stores).

This patch handle the jobs/steps of the deactivation scenario, so that
on the EXECUTING step all the Upload/Create Image tasks will appear.

Furthermore, when the execution is initiated by the user there's no
need to log that there are tasks, as the tasks were created by the
flow itself (it's being checked on the CDA phase that there are no
tasks prior to the execution).

Change-Id: I4cde77da50fe63a4fda6d9fb61e95fc113e4b54c
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1138124
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: correct ProcessOvfUpdateForStorageDomainCommand lock properties

ProcessOvfUpdateForStorageDomainCommand lock is released always on the
execute phase prior to change I54cc929937d3b14dc49a2edab9e763cbe603a9c3
- either by the child command or because the created tasks aren't added
to the command task
list.

This patch changes the applyLockProperties method to state that
explictly.

Change-Id: I938e8a0ce74bb931635948210f26a1f451fbe815
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1138124
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: remove unneeded setSucceeded

The following code in the started thread is executed after the tasks
were cleared, therefore there's no need to execute setSucceeded,
furthermore, as the class isn't thread safe it's risky to have that call
in terms of future changes.

Change-Id: I2d15162aded39cf43064b14fd6c02644bf95936f
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1138124
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: DeactivateStorageDomainWithOvfUpdate - locks

The lock taken by the command should be released at the end of the
endAction() method, therfore we should avoid passing it to the child
command (so it won't be released by it). Also, avoid releasing the in
memory lock while there are still tasks.

Change-Id: Id8199e372d72f673aeb7b16d12cc8f5ffa043117
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1138124
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: always perform ovf update after disk creation

Currently the OVF Update is performed after the disk creation only if
atleast one OVF store creation succeeds.

The reason for that is that prior to change I54cc9 the OVF update flow
first updated the existing OVF stores, then created new stores if needed
and if atleast of creation was succesful - update the OVF data.

As in change I54cc9 the order of operations was change (first the OVF
disks are created and then the OVF data is updated) performing the
update only if one disk succeeded is wrong and it should be done always.

Change-Id: Ic029f819f2d0c0a51c098667daa319b921f8750c
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1138124
Signed-off-by: Liron Aravot <laravot@redhat.com>
core: CreateOvfStoresForStorageDomain - set StorageDomainId

setStorageDomainId() in case of storage domain related audit log is done
(so that the replacements to the message could be done).

Change-Id: I9b6fcfbdc1aa12421b133c5df76cd81e9c3d13f4
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1138124
Signed-off-by: Liron Aravot <laravot@redhat.com>
rest: Validation of the protocol values

We did not check protocol values provided so update of the host with
wrong protocol string failed on backend whereas it should fail during
initial validation.

Change-Id: I666b5469bcaf2bd00f793ad4320c3f37505d49b0
Signed-off-by: pkliczewski <piotr.kliczewski@gmail.com>
Bug-Url: https://bugzilla.redhat.com/1170125
webadmin: Fixed misalignment 'Copy Quota' dialog.

On the french version of the webadmin, Inside the "Copy Quota" dialog,
the "copy consumers and permissions" label was sliding of to the next
line.

This error was fixed by extending the width of
the "copyPermissionsEditor" field to 600px.

Change-Id: I5bb7d488d9570591215118633e69437bd0f6af17
Bug-Url: https://bugzilla.redhat.com/1123796
Signed-off-by: Tomer Saban <tsaban@redhat.com>
core: fix missing QoS name from audig log

Change-Id: Id37d5210e4dc963217587ff93ff88d428cb38919
Bug-Url: https://bugzilla.redhat.com/1168250
Signed-off-by: Roy Golan <rgolan@redhat.com>
restapi: Fix disk move and export metadata

The description of the operations to move, copy and export disks using
the top level disks collection is incorrect. This means that these
operations aren't supported in the SDKs and in the CLI. This patch fixes
the documentation.

Change-Id: I8a5cec5bf3049d3a9325b23a7d54c21565388b51
Bug-Url: https://bugzilla.redhat.com/1169376
Signed-off-by: Juan Hernandez <juan.hernandez@redhat.com>
(cherry picked from commit a3589e9e649f076344b1949aa9cc99944d7de942)
webadmin: CPU shares custom value is now possible

On the "New Virtual Machine" dialog, inside the "Resource Allocation"
tab on the left, when selecting "Custom" on the CPU shares combobox,
the textbox on the right(Where you set the actual value of the CPU
shares) wasn't changeable.
Now, it becomes changeable once "Custom" is chosen and unchangeable
once another value is chosen in the combobox.

Change-Id: Ie1fe20afa682926ac14b7d9ac7c5fa589b3b0459
Bug-Url: https://bugzilla.redhat.com/1152636
Signed-off-by: Tomer Saban <tsaban@redhat.com>
webadmin: fix cpu profile changes for import

When importing vm/template and changing cluster didn't
change corresponding cpu profile.

Change-Id: Ia524e72fcff6d3cc655e6aee9f078b9365faaba3
Bug-Url: https://bugzilla.redhat.com/1168532
Signed-off-by: Gilad Chaplik <gchaplik@redhat.com>
core, engine: Disable CPU pinning validation

This patch disables the validation responsible for checking if a
physical CPU exists during the verification of CPU pinning settings.

This is needed in ppc64 due to the lack of a list of which CPUs are
online, something that is correctly reported currently only in x86-64.

As soon as this missing info is fixed in ppc64, this patch can be reverted.

Change-Id: I98c7a2f136b278a7a695bae8b2eadd3658f3e65c
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1171724
Signed-off-by: Vitor de Lima <vdelima@redhat.com>
webadmin: Remove Storage connection on import domain failure

Remove storage server connection if we failed to import an existing Storage Domain.

Change-Id: I553a311fe8856b9cd5825405fef39e91e4c6e771
Bug-Url: https://bugzilla.redhat.com/1136930
Signed-off-by: Maor Lipchuk <mlipchuk@redhat.com>
webadmin: ImportVmFromExportDomainModel#doInit DLS

Removed the unused local variable cluster which was causing a FindBugs
warning.

Change-Id: Iaf9dc95b3099c202cebdf955db6706990f4cf0bf
Bug-Url: https://bugzilla.redhat.com/1168532
Signed-off-by: Allon Mureinik <amureini@redhat.com>
packaging: rename: drop handling of RedirectServletReportsPage

This option does not exist in 3.5.

Bug-Url: https://bugzilla.redhat.com/1170229
Change-Id: If22134524c7699d53fb944b9b26dc158ac71ea49
Signed-off-by: Yedidyah Bar David <didi@redhat.com>
(cherry picked from commit 9601e6223b9f602a6c6a30ec8e1b25d985876258)