Bug : SharedMountPoint not working after StorPool plugin support

[dhslove]

After adding support for StorPool in CloudStack version 4.17, Default Primary Storage of SharedMountPoint Type is no longer created. This Bug is related and caused by #6007

This is an issue caused by the StoragePoolType of the StorPoolStorageAdaptor.

Currently, the Pool Type of StorPoolStorageAdaptor is set to SharedMountPoint.
See the following code.

StorPoolStorageAdaptor :

@StorageAdaptorInfo(storagePoolType=StoragePoolType.SharedMountPoint)
public class StorPoolStorageAdaptor implements StorageAdaptor {
    public static void SP_LOG(String fmt, Object... args) {
    ......

For this reason, even if it is a Default SharedMountPoint type of storage other than StorPool, LibvirtStorageAdaptor is not selected by the following code, but StorPoolStorageAdaptor is selected and an error occurs.

KVMStoragePoolManager :

    private StorageAdaptor getStorageAdaptor(StoragePoolType type) {
        // type can be null: LibVirtComputingResource:3238
        if (type == null) {
            return _storageMapper.get("libvirt");
        }
        StorageAdaptor adaptor = _storageMapper.get(type.toString());
        if (adaptor == null) {
            // LibvirtStorageAdaptor is selected by default
            adaptor = _storageMapper.get("libvirt");
        }
        return adaptor;
    }

In my opinion, it is better to create a separate Pool Type for StorPoolStorageAdaptor like the LINSTOR Plugin.

ISSUE TYPE

• Bug Report

COMPONENT NAME

UI, API, Plugin

CLOUDSTACK VERSION

4.17.0

CONFIGURATION

3 Hosts, GFS2 Clustered File System, Shared Mount Point : /mnt/gfs2

OS / ENVIRONMENT

CentOS 8.5, CloudStack 4.17.0

SUMMARY

STEPS TO REPRODUCE

1. AddPrimaryStorage 
2. Select SharedMountPoint Protocol
3. Input Mount Directory
4. Select DefaultPrimary Provider
5. Submit 

EXPECTED RESULTS

Create Shared Mount Point Primary Storage

ACTUAL RESULTS

SharedMountPoint Primary Storage is recorded in DB, but the pool is not actually created because an appropriate StorageAdaptor is not selected.

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template!

[slavkap]

@dhslove, unfortunately, a few storage pools are using libvirt storage adaptor, and the method you mentioned shouldn't rely only on the StoragePoolType. I've missed that this could cause any issues, for which I'm sorry. We will work on a fix for 4.17.1.0.
Till then, as a workaround that comes to my mind, you could delete the jars files of the StorPool plug-in for the management/agents.

/usr/share/cloudstack-management/lib/cloud-plugin-storage-volume-storpool-4.17.0.0.jar
/usr/share/cloudstack-agent/lib/cloud-plugin-storage-volume-storpool-4.17.0.0.jar

and restart the services
CS doesn't depend on that code, and deleting it shouldn't cause any other issues

[nvazquez]

Thanks @slavkap - @dhslove can you please confirm if this workaround solves the issue for you?

[dhslove]

@slavkap Thank you for your comment.

I've already read your README file and solved it as you say.

For other users, I expect this bug to be resolved in the next patch.

Thank you for your hard work.

[dhslove]

@nvazquez Of course. I would be happy to do so if I can help you with your workaround.

[yadvr]

@dhslove do upgraded env continue to work, for. ex if you had a sharemountpoint based storage prior to the upgrade does it continue to work post upgrade to 4.17.0.0. (I understand the original bug report is adding new sharedmountpoint).

@nvazquez I think if the workaround solves the issue then we should document that part of the release notes (update the docs website) and send an email to both dev and users ML.

[slavkap]

@rohityadavcloud, I checked the code, and the method getStorageAdaptor is used in almost every case. Before StorPool, if you use SharedMountPoint, it's not added to _storageMapper because there isn't a specific adaptor for it, and it uses the libvirt storage adapter. It should get in here:

        StorageAdaptor adaptor = _storageMapper.get(type.toString());
        if (adaptor == null) {
            // LibvirtStorageAdaptor is selected by default
            adaptor = _storageMapper.get("libvirt");
        }

I'm working to change our storage pool type to StorPool in a way that will not affect current clients. But I think the best solution is to rewrite the getStorageAdaptor in cases where different adaptors use SharedMountPoint.

[yadvr]

Thanks @slavkap feel free to ping me and @nvazquez if you've the fix ready, we'll help with an expedited review/merge towards 4.17.1.0 milestone. If the workaround is available and works, then @nvazquez can help draft and publish the advisory for our users on the project ML, blog and via an update in the 4.17.0.0 release notes (docs website).

[yadvr]

Ping Hi @slavkap are you working on a bugfix PR for this, for 4.17.1.0?

[slavkap]

Hi @rohityadavcloud, yes, I'm working on a fix for 4.17.1.0. I need some time for more extensive testing