CLOUDSTACK-7680:Adding kwargs to volume.upload in base.py

Signed-off-by: SrikanteswaraRao Talluri <talluri@apache.org>
CLOUDSTACK-6650: Reorder Cluster list in deployment planner to protect
GPU enabled hosts from non-GPU VM deployment.
Cluster reordering is based on the number of unique host tags in a cluster,
cluster with most number of unique host tags will put at the end of list.
Hosts with GPU capability will get tagged with implicit tags defined by
global config param 'implicit.host.tags' at the time os host discovery.

Also added FirstFitPlannerTest unit test file.
CLOUDSTACK-7649: test_lb_secondary_ip.py - Removed SSH trying step after Destroying and Recovering VM because secondary IP information does not retain on VM after destroying it and SSH will not be successful in that case

Signed-off-by: SrikanteswaraRao Talluri <talluri@apache.org>
CLOUDSTACK-7644: test_persistent_networks.py - SSH failure in case of LB rule due to port mismatch

Signed-off-by: SrikanteswaraRao Talluri <talluri@apache.org>
CLOUDSTACK-7646: test_nuage_vsp.py - Fixed basic indentation issues, list index issues, marked it as invalid because the test cases needs attention by the original author as it does not pass even after fixing the issues. Also moving it to smoke folder as clearly it is a Basic Validation test

Signed-off-by: SrikanteswaraRao Talluri <talluri@apache.org>
CLOUDSTACK-7681: UI > zone wizard > Advanced zone > hypervisor => do not support BareMetal
CLOUDSTACK-7661: VM wizard: Add keyboard language dropdown
Revert "CLOUDSTACK-7671: Management server restart failed after reboot"

This reverts commit e8f1c592120707ac214d535a6637fa7dc5826289.
CLOUDSTACK-4987: UI > Instances > detailView > NICs tab > Add network to VM > Network dropdown => (1) For root-admin, populate networks of all accounts. (2) For regular-user/domain-admin, populate only networks belonging to this VM owner.
CLOUDSTACK-3195: UI > IP Address > detailView > Configuration tab > Port Forwarding > for regular-user, if underlying VM has been destroyed (i.e. listVirtualMachines API returns nothing), compose vm object from limited vm data in port forwarding rule object. So, a vm object (required in widget code) can be passed to widget code.
CLOUDSTACK-7632:Automation for volume life cycle testPath

Signed-off-by: SrikanteswaraRao Talluri <talluri@apache.org>
CLOUDSTACK:7323: [vGPU] Creation of VM snapshot with "memory" is failing.

VM snapshot with memory is not supported for VGPU VMs, so putting checks
for same.
updated packge scripts to support simularot rpm build
CLOUDSTACK-7661: UI > VM Wizard > Keyboard Language > send new parameter keyboard to deployVirtualMachine API call.
CLOUDSTACK-5359: UI > Infrastructure > Clusters > Add Cluster > Public Traffic vSwitch Type field, Guest Traffic vSwitch Type field > do not pass the value of the form field to API call when the the form field is not displaying.
CLOUDSTACK-2625, CLOUDSTACK-3401: Usage records are ordered by start_date which is not unique. While listing large datasets or when page size is small this will result in duplicates. Order records by id instead
Fixed few coverity patches

Signed-off-by: Santhosh Edukulla <santhosh.edukulla@gmail.com>
CLOUDSTACK-5719: UI > Network > Add Guest Network > when Physical Network dropdown is changed, refresh Network Offering dropdown (because each physical network has its own tags which maps to different network offerings)
Revert "CLOUDSTACK-6650: Reorder Cluster list in deployment planner to protect"

This reverts commit d910b4ff14bcf5d9e7892b5ffd39acb47745f106 since it is causing encryption/decryption issues with RPM builds
kvm: Add better logging when fetching a volume from libvirt

Clearly show if a volume is found and if not, that the pool is being refreshed
and the fetch is tried again.

Due to my commit b53a9dcc9f3ee95d40761b9c2c860f821595a661 the chance of a volume
not being found is slightly bigger, but the performance gain is enormous on larger
deployments.

This is why we clearly have to log that we are refreshing the pool information
when a volume is not found.

It could be that a volume is created on host A and a few seconds later host B tries
to access the volume. In that case host B's libvirt doesn't know about the volume
yet and has to refresh the pool before it does.