-----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
