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