Pluggable models for core and api have been in since 2.2. Pluggable UI is being planned.
--Alex > -----Original Message----- > From: Wido den Hollander [mailto:w...@widodh.nl] > Sent: Friday, October 19, 2012 5:32 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: FS for host updates notifications > > Hi, > > On 10/12/2012 10:08 AM, Ram Ganesh wrote: > > 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? > > > > I think we do? But this would mean there should be a completely pluggeable > model for the core, API and UI and that doesn't exist at this moment. > > There has been some talk about this, but nothing concrete. I'm also not sure > how you should implement this. > > Wido > > > 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+upda > >> te > >> 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
