incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: new storage framework update
Date Wed, 16 Jan 2013 03:09:12 GMT
On Tue, Jan 15, 2013 at 8:35 PM, Edison Su <Edison.su@citrix.com> wrote:
> After a lengthy discussion(more than two hours) with John on Skype, I think we figured
out the difference between us.  The API proposed by John is more at the execution level, that's
where input/output stream coming from, which assumes that both source and destination object
will be operated at the same place(either inside ssvm, or on hypervisor host). While the API
I proposed is more about how to hook up vendor's own storage into cloudstack's mgt server,
thus can replace the process on how and where to operate on the storage.
> Let's talk about the execution model at first, which will have huge impact on the design
we made. The execution model is about where to execute operations issued by mgt server. Currently,
there is no universal execution model, it's quite different for each hypervisor.
>  E.g. for KVM, mgt server will send commands to KVM host, there is a java agent running
on kvm host, which can execute command send by mgt server.
> For xenserver, most of commands will be executed on mgt server, which will call xapi,
then talking to xenserver host.  But we do put some python code at xenserver host, if there
are operations not supported by xapi.
> For vmware, most of commands will be executed on mgt server, which talking to vcenter
API, while some of them will be executed inside SSVM.
> Due to the different execution models, we'll get into a problem about how and where to
access storage device. For example, there is a storage box, which has its own management API
to be accessed. Now I want to create a volume on the storage box, where should I call stoage
box's create volume api? If we follow up above execution models, we need to call the api at
different places and even worse, you need to write the API call in different languages. For
kvm, you may need to write java code in kvm agent, for xenserver, you may need to write a
xapi python plugin, for vmware, you may need to put the java code inside ssvm  etc.
> But if the storage box already has management api, why just call it inside cloudstack
mgt server, then device vendor should just write java code once, for all the different hypervisors?
If we don't enforce the execution model, then the storage framework should have a hook in
management server, device vendor can decide where to execute commands send by mgt server.
> That's my datastoredriver layer used for. Take taking snapshot diagram as an example:
https://cwiki.apache.org/confluence/download/attachments/30741569/take+snapshot+sequence.png?version=1&modificationDate=1358189965000
> Datastoredriver is running inside mgt server, while datastoredriver itself can decide
where to execute "takasnapshot" API, driver can send a command to hypervisor host, or directly
call storage box's API, or directly call hypervisor's own API, or another service running
outside of cloudstack mgt server. It's all up to the implementation of driver.
> Does it make sense? If it's true, the device driver should not take input/out stream
as parameter, as it enforces the execution model, which I don't think it's necessary.
> BTW, John and I will discuss the matter tomorrow on Skype, if you want to join, please
let me know.
>


Is this text conversation on Skype? If so, why not do this on IRC in
-meeting or -dev? We can log it all and have more people join.

--David

Mime
View raw message