On Tue, Jan 15, 2013 at 8:35 PM, Edison Su <edison...@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
