I'm interested in this. Please add me to whatever medium you guys are using.
--Alex > -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Tuesday, January 15, 2013 7:09 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: new storage framework update > > 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
