Hi Ove, Thanks for your thoughts.
I totally agree that using standardized APIs has a strong preference, and is the way to go. What you rightfully pointed out is the significant difference between OVM 2.x and 3.x in the ovs-agent, I already bumped into that one and indeed found out that figuring out what goes wrong where is a bit hairy if you're not familiar with the code or the concepts. So option B is for sure the one that I would prefer, and I gather from your reflections you do too. My apologies for not elaborating initially. With "along the lines of 2.x" I meant leveraging the separate OVM 3.x Hypervisor APIs, which seems supported by Oracle looking at the documentation, instead of using Oracle VM Manager in a vCenter style. Also being able to extend the ovs-agent where required to expose specific functionality if required, but rather not touching it if not required. Oracle supports plugins for the ovs-agent/API, an example of this is the Netapp plugin that is due somewhere Q2/Q3 in 2013, so there are possibilities there if need be. ACS4.2 and the storage refactor is something that impacts multiple facets, and not only OVM 3.2.1 integration (wild speculation here though). I trust that the people that commit the code, when and if done, and use the code for OVM will also maintain that code, myself and the company I work for will be one of them. Looking at the automated testing we do here on 4.1 for example will also force the fixes and functionality. At the moment we're also actively connecting with Oracle, so I trust we will get some more insight in what the OVM product development team thinks. Cheers, Funs > On 02/18/2013 03:36 PM, Funs Kessen wrote: > > Hi There, > > > > At the moment I'm diving into OVM 3.2.1 Support in Cloudstack. I've > noticed that only 2.3 support is in there now and found some earlier mails > (June 2012) from people who were looking into getting 3.x support in. There > are several paths that could be taken with the integration, my initial > thoughts are to move along the lines the 2.3 implementation followed. > > > > My question is if anyone else is thinking about this or working on this and > if so, if it would be useful to collaborate on this? > > > > Cheers, > > > > Funs > > > > Some technical reflections on this topic; > > The OVM 2.x approach is about a significant update to the python agent > code in the OVM 2.x hypervisor. The state of the OVM 2.x API presumably > prompted the folks doing the OVM 2.x port to follow this approach (there > were no other path ...). In OVM 3.2.1 the API has progressed further, there is > a CLI type API on top off SSH and there is a Java SDK > (REST/SOAP) and there is the OVM3 ovm_shell (jython) (this is not an API, > but means to control OVM3 using python code (v2.4)). > > CloudStack too has come a long way and the storage re-factor coming in > ACS4.2 adds important elements to orchestrate OVM 3.2.1 given how OVM > 3.2.1 handles storage and what means OVM 3.2.1 expose for external > control. > > The OVM 2.x approach would also modify OVM 3.2.1 hypervisor > implementation to a degree where issues can be difficult to distinguish > from OVM 3.2.1 itself vs the changes in the python agent to facilitate > ACS4 integration. > > The python implementation of the OVM 3.2.1 agent is significantly different > from OVM 2.x so reuse there is unlikely, one reason is that the XML RPC is > more abstracted in OVM 3.2.1, a step in the right direction (my subjective > observation). > > There is a storage plugin architecture in OVM3, although today primarily > geared towards NFS/iSCSI services, this may be possible to use to avoid > diving into low level changes of the OVM3 hypervisor agent to interface > with ACS (and leverage "cloud" storage). > > In short, today there may be means to integrate ACS4<->OVM3 that avoids > digging in to the python agent code in DOM0. Down the road the ACS4 > storage refactor today slated for ACS42 is also a factor. > > What pros and cons do you see with the two main approaches, A) changing > the agent on the hypervisor vs B) using the officially published API's made > available via OVM3 manager? > > /Ove > > NB; I'm not associated with the OVM3 product development, just a user of > the OVM3 product. > > > > > -- > Ove Everlid > System Administrator / Architect / SDN & Linux hacker > Mobile: +46706662363 > Office: +4618656913 (note EMEA Time Zone)
