On Mon, Oct 8, 2012 at 9:14 AM, Sanjay Tripathi <sanjay.tripa...@citrix.com> wrote: > Thanks for the feedback. Sorry for the delayed reply; I was trying your > suggestions to see how it works. > > Summarized the approach in below mentioned steps: > > 1. The host update feature will be in a separate plugin and contained in an > independent jar file. > 2. This will use PluggableService to add the APIs into CloudStack. > 3. A manager to schedule a thread to check the updates and update the > database with new updates. > 4. An agent to call ServerResource which will fetch the list of all the > patches applied to a host. This agent will use the objects > "HostUpdatesCommand" and "HostUpdatesAnswer" to get the information from > ServerResource. These objects will be placed in "api" project under > "com.cloud.agent.api" package. > > I have updated functional spec with this information. > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/XenServer+updates+notification > > Does this approach sound right? > Please let me know your suggestions. > > Wido/David/Chip/Alex: Please do share your thoughts on this approach. > > Regards, > Sanjay
I like breaking it out into its own separate plugin. I still think this is a bad idea for several reasons. 1. We have historically said we wished to be hypervisor agnostic - and while I don't expect folks to write plugins for hypervisors they don't care about - I do want us to tread carefully in introducing new features that will be difficult or impossible to implement in a sane manner for other hypervisors. (The way to convince me this isn't a problem is to tell me how someone would do this for KVM (on both EL and Ubuntu - and other distros) - as that's the biggest hole IMO.) The worst thing we can do on this front is have stellar support for XenServer and just barely capable support for $otherhypervisor. 2. This is the primrose path to perdition IMO - CloudStack isn't a monitoring system, or patch management system, and because that isn't our core focus we will never do that well - I'd like our focus to be on the orchestration pieces - which are hard enough without making us becoming the swiss army knife of system management/orchestration tools. If you are really serious about this - perhaps it can become a separate plugin and hosted at apache extras instead of in the codebase for CloudStack. --David
