Ok, that makes sense. So this will be a part of the storage refactor? If
you're not already working on it I'll play with it and see if I can create
a working implementation.
I'm assuming we'd have in your example both a getStoragePool(String uuid)
that selects the old/default LibvirtStorageAdaptor and a
getStoragePool(String storagePoolType, String uuid), so as not to have to
redo any existing code?
On Mon, Dec 10, 2012 at 1:31 PM, Edison Su <edison...@citrix.com> wrote:
> KVMStoragePoolManager should manage the mapping between storage pool type
> and storageadaptor. ****
>
> **1. **In KVMStoragePoolManager’s constructor, create a map between
> storage pool type and storageadaptor:****
>
> sample code:****
>
> map<String, storageadaptor> storageMapper = new HashMap<String,
> storageadaptor>();****
>
> storageMapper.add(“your-storage-type”, new your-storage-adaptor);****
>
> storageMapper.add(“libvirt-managed-storage”, new LibvirtStorageAdaptor);**
> **
>
> **2. **For each api of KVMStoragePoolManager, should pass down a storage
> pool type, e.g:****
>
> public KVMStoragePool getStoragePool(String storagePoolType, String uuid) {
> ****
>
> storageadaptor adaptor = storageMapper.get(storagepoolType);****
>
> if (adaptor == null) {****
>
> adaptor = storageMapper.get(“libvirt-managed-storage”);****
>
> }****
>
> return adaptor.getStoragePool(uuid);****
>
> }****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Marcus Sorensen [mailto:shadow...@gmail.com]
> *Sent:* Monday, December 10, 2012 3:06 PM
> *To:* Edison Su
> *Cc:* cloudstack-dev@incubator.apache.org
> *Subject:* Re: pluggable storage implementation****
>
> ** **
>
> Yeah, but I'm not seeing an easy/pluggable way to implement a storage
> adaptor, where LibvirtComputingResource relies exclusively on
> KVMStoragePoolManager, which is implementing LibvirtStorageAdaptor. I don't
> see how to switch between storage adaptors in KVMStoragePoolManager.java
> based on what primary storage type I happen to be acting upon.****
>
> ** **
>
> On Mon, Dec 10, 2012 at 12:51 PM, Edison Su <edison...@citrix.com> wrote:*
> ***
>
> ****
>
> ****
>
> *From:* Marcus Sorensen [mailto:shadow...@gmail.com]
> *Sent:* Monday, December 10, 2012 2:06 PM
> *To:* Edison Su
> *Cc:* cloudstack-dev@incubator.apache.org
> *Subject:* pluggable storage implementation****
>
> ****
>
> Just curious, hadn't thought about this before but it seems that at least
> on KVM (probably similar in Xen and VMware too?), there are two separate
> issues with storage in the existing code. First, adding a new storage type
> is a matter of adding in a new 'else if' or something in a bunch of
> different places, as well as tweaking behavior to match the storage type.
> Second, everything about the storage is tightly integrated with Libvirt,
> meaning that if your storage type is not supported by Libvirt it's much,
> much more difficult to implement.****
>
> ****
>
> Are these both being addressed by the storage changes, for example can we
> write a storage plugin that creates pools/volumes that libvirt doesn't know
> about and still attach those to instances? Or would we need to patch
> libvirt to utilize our storage first?****
>
> ****
>
> [Edison] That’s the storageadaptor used for:
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob;f=plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/StorageAdaptor.java;h=ef1e7c9302ab6ac8f197cf75bbf7235bba0235cf;hb=HEAD
> ****
>
> The LibvirtStorageAdaptor is one of implementation of storageadaptor,
> which is totally based on libvirt, If you have a new storage, not supported
> by libvirt, then you can add a new implementation of storageadaptor.****
>
> ** **
>
