> -----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/tak > e > > +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. Yah, text conversation on skype. If on irc, as people can talk about different topics at the same time, may not be the best place IMHO.
> > --David
