Solusvm Module Extra Ram/disk Problems

[Jonathan]

SolusVM extra_memory and extra_disk logic appears flawed.  When adding/removing extra disk it does calculation incorrectly as if always based on the first listed plan with a similar-pattern name to what you're working with.

 

To recreate it:

 

Create 2-3 plans in SolusVM.  Title them SSD-1 (1GB RAM), SSD-2 (2GB RAM), etc.

Tie these to plans in Blesta.

Create an extra_memory configurable option using a quantity field.  Min 0, Max 1024, Inc 256

Create a new SSD-2 service (0 value on the configurable option).

Add lets say 512MB of extra memory.

 

The service should now have 2.5GB of memory since it's an SSD-2 with 2GB base, and we added 512.  Problem is, we only have 1.5 because Blesta when adding extra, added it based upon the SSD-1.

 

We take this even further:

 

Remove the 512MB addon memory.

 

Now we have 1GB of memory because again Blesta did this based upon the SSD-1 for some reason.

 

The only way to get back to correct plan values using Blesta is to (with the addon values at 0) upgrade/downgrade the plan to another one.

[Tyson]

The only way to get back to correct plan values using Blesta is to (with the addon values at 0) upgrade/downgrade the plan to another one.

 

This may be the problem.

 

Make sure that the plan set on the service is the correct plan it is set to in SolusVM. It's possible if you upgraded the service to use a different plan that the plan on the service in Blesta no longer coincides. You would need to check the database.

 

Run the following query to determine the service's plan. Replace SERVICE_ID with the ID of the service:

SELECT * FROM `service_fields` WHERE `key` = 'solusvm_plan' AND `service_id` = 'SERVICE_ID';

[Jonathan]

This query indeed returns an incorrect plan, the plan that it's basing everything on.

 

All up/downgrades on this plan were done via Blesta, and in manage service Blesta does show the correct plan.

 

"Package Name: SSD-5"

 

MariaDB [blesta]> SELECT * FROM `service_fields` WHERE `key` =
    -> 'solusvm_plan' AND `service_id` = 12126;
+------------+--------------+-------+------------+-----------+
| service_id | key          | value | serialized | encrypted |
+------------+--------------+-------+------------+-----------+
|      12126 | solusvm_plan | SSD-1 |          0 |         0 |
+------------+--------------+-------+------------+-----------+
1 row in set (0.02 sec)

 

Hoping you have an idea as to what's going on here.

[Tyson]

I believe the problem is an upgrade (change of package) to a different plan (SSD-5) that updates the plan with the module but does not update the service in Blesta to the new plan. The plan is then out of sync with SolusVM, accounting for the discrepancies in values like extra memory that rely on the plan for proper calculation. The larger issue here is described in CORE-1669.

[Tyson]

If you want to fix this yourself,

 

Open /app/models/services.php and find:

$module->changeServicePackage($package_from, $package, $service, $parent_package, $parent_service);

if (($errors = $module->errors())) {
	$this->Input->setErrors($errors);
	return;
}

Replace with:

$service_info = $module->changeServicePackage($package_from, $package, $service, $parent_package, $parent_service);

if (($errors = $module->errors())) {
	$this->Input->setErrors($errors);
	return;
}
elseif ($service_info && is_array($service_info)) {
	$this->setFields($service_id, $service_info);
	$service = $this->get($service_id);
}