Wido,David et al, Thanks a lot for the comments. We are still debating how to proceed with this feature.
I do have a question - are we looking at an extensions model (may be similar to Java extensions) where features get developed as extensions and when we get better traction/support for community becomes mainstream;is contrib\extras the model for that? If yes can someone help let know the process please? Thanks again for all the excellent comments Ram PS: I will be offline for next 7-8 days so please do expect delay in my response. > -----Original Message----- > From: Wido den Hollander [mailto:w...@widodh.nl] > Sent: 09 October 2012 02:12 > To: cloudstack-dev@incubator.apache.org > Subject: Re: FS for host updates notifications > > > > On 10/08/2012 06:00 PM, David Nalley wrote: > > 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+update > s+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. > > > > I agree on this one. Although I do understand the request for such a > feature, I do have the feeling this will stay a XenServer only feature. > > Yes, some smart guy could implement this for Ubuntu or RHEL running KVM > hypervisors, but I don't think it is maintainable on the longer run. > > How do we foresee this for VMWare or OVM? > > > 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. > > > > I agree, we shouldn't try to re-invent the wheel here. While I'm not > familiar with XenServer at all I know that recently at our company some > sysadmins implement something like this in Zabbix. > > Whenever there are Apt updates ready for hosts they will get a > Informational message from Zabbix that a host has updates. > > The same could be done for XenServer I guess. Next to CloudStack you > will have a monitoring system like Nagios/Icinga, Zabbix or ZenOSS, > you'd better implement it there. > > We have to prevent that CloudStack becomes this big piece of software > that starts to dictate your infrastructure. > > Again, I really do get the request from customers for this, but I don't > think this is the task for CloudStack. > > Wido
