System offering of router says its local storage but it ends up on different if the pools are disabled

[borisstoyanov]

ISSUE TYPE

• Bug Report

COMPONENT NAME

Deployment planner

CLOUDSTACK VERSION

4.14

CONFIGURATION

OS / ENVIRONMENT

Have a local storage pool with some other pools as well

SUMMARY

Steps:

(localcloud) SBCM5> > list routers filter=name,serviceofferingid,,templateid,
{
  "count": 1,
  "router": [
    {
      "name": "r-21-VM",
      "serviceofferingid": "1f3d4c8c-c585-47f1-8cdb-f03cb4076988",
      "templateid": "62f6a3bd-0160-4e52-b72c-2e61fc74a987"
    }
  ]
}
(localcloud) SBCM5> > list templates id=62f6a3bd-0160-4e52-b72c-2e61fc74a987 templatefilter=all filter=directdownload,name,
{
  "count": 1,
  "template": [
    {
      "directdownload": true,
      "name": "ssvm4.14"
    }
  ]
}
(localcloud) SBCM5> > list serviceofferings issystem=true
    {
      "cpunumber": 1,
      "cpuspeed": 500,
      "created": "2020-02-20T07:23:35+0000",
      "defaultuse": true,
      "id": "1f3d4c8c-c585-47f1-8cdb-f03cb4076988",
      "iscustomized": false,
      "issystem": true,
      "isvolatile": false,
      "limitcpuuse": false,
      "memory": 256,
      "name": "System Offering For Software Router - Local Storage",
      "offerha": true,
      "provisioningtype": "thin",
      "storagetype": "local",
      "systemvmtype": "domainrouter"
    },

But there’s a system offering available for mountshare and it is not used: 

 "serviceoffering": [
    {
      "cpunumber": 1,
      "cpuspeed": 1024,
      "created": "2020-02-25T09:45:03+0000",
      "defaultuse": false,
      "displaytext": "System offering for VR - Mountshare",
      "id": "43e8df56-6f4e-408e-b619-53cf6289dc30",
      "iscustomized": false,
      "iscustomizediops": false,
      "issystem": true,
      "isvolatile": false,
      "limitcpuuse": false,
      "maxiops": 0,
      "memory": 512,
      "miniops": 0,
      "name": "System offering for VR - Mountshare",
      "offerha": false,
      "provisioningtype": "thin",
      "storagetype": "shared",
      "systemvmtype": "domainrouter",
      "tags": "ms"
    },

MariaDB [cloud]> select id,pool_id from volumes where name ='ROOT-21';
+----+---------+
| id | pool_id |
+----+---------+
| 24 |       5 |
+----+---------+
1 row in set (0.00 sec)

MariaDB [cloud]> select pool_type from storage_pool where id=5;
+------------------+
| pool_type        |
+------------------+
| SharedMountPoint |
+------------------+
1 row in set (0.00 sec)

STEPS TO REPRODUCE

Enable maintenance on all Storage pools but a Sharedmountpoint

Restart a Network with cleanup

Observe that the new VR is created correctly on the only available storage pool, but the offering is not correct under which is created

EXPECTED RESULTS

Deployment to fail as there's no suitable storage

ACTUAL RESULTS

Deployment is successful on shared storage

[DaanHoogland]

this is one of those bugs that could be "featured" and be abused so I think a setting for the behaviour is desirable. in this case with old or "expected" behaviour as a reasonable default.

[shwstppr]

@DaanHoogland do you mean we should add a global setting which will govern the behaviour (to fail deployment or not) when when suitable local storage is found for router? cc @borisstoyanov

[DaanHoogland]

I think that is an implementation but certainly not that it is the most desirable. Other solutions may include a setting on zone level or a setting in the networkoffering that allows for it or not.

[yadvr]

cc @Spaceman1984 any update on this?

[Spaceman1984]

I have ruled out the list routers api and I am investigating the creation process.

[Spaceman1984]

I have found the place in the code where the service offering is selected for a VR.

RouterDeploymentDefinition.java

392 protected void findServiceOfferingId() {
393     serviceOfferingId = networkOfferingDao.findById(guestNetwork.getNetworkOfferingId()).getServiceOfferingId();
394     if (serviceOfferingId == null) {
395         findDefaultServiceOfferingId();
396     }
397 }

Line 393 seems strange to me, I don't know how the service offering would be stored on the network offering using the ui - but it seems like this would be a way to select a specific service offering by hacking the db.

In my testing serviceOfferingId = null, meaning the default service offering is used, which is based on if the zone level variable system.vm.use.local.storage is set to true or not, either Cloud.Com-SoftwareRouter or Cloud.Com-SoftwareRouter-Local.

This happens before the VM is started or any storage pools are checked.

That information is then passed to the deployment planner which has to figure out which storage pool to use.

The deployment doesn't fail, because all storage allocators are checked to find any available storage pools.