On Mon, Sep 24, 2012 at 10:04 AM, Wido den Hollander <[email protected]> wrote:
> On 09/24/2012 03:33 PM, Sanjay Tripathi wrote:
>>
>> Hi,
>>
>> We are working on the feature - "Xenserver updates notification" which
>> will list the updates that are available for any XenServer host.
>>
>> The functional spec for the feature:
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/XenServer+updates+notification
>>
>> Please let me know your suggestions/comments.
>>
>
> I'm not sure if this is the task for CloudStack.

I agree - looks like scope creep for CloudStack.

>
> If we go down this path, are we also going to check if new apt/yum updates
> are available on KVM platforms?

Ughhh - and then what aspect. - only look for qemu/libvirt/kvm
updates? How do you distinguish between other kernel updates and
updates that effect KVM? What about security fixes

>
> CloudStack should set a minimum version of which the Xen server should be
> updated to to work with properly, but I don't think CloudStack should
> actually be checking which updates are available.
>
> Where does it end? Later on we are also going to check if a update for the
> F5 loadbalancer is available or for the NetScaler or for a Brocade switch?

Agreed - this is a systems management problem not a cloud
orchestration problem. I understand the reasoning behind wanting to do
this (problems that are already solved by patches are not applied and
then folks run into problems and had they applied the hotfixes or
patches the problems would have been avoided. However, I'd posit that
folks who don't care enough to have a means of patch management in
place already are not going to be making an API call to determine
which of their hypervisor hosts are not up to date, nor are they going
to go look at the tab in the UI that shows it (and at scale who could
afford to do it via the UI))

>
> It's only adding code to the management server which needs to stay
> simplistic imho.
>
> These kinds of task should be outsourced to tools like Zabbix, Nagios,
> Incinga, SolarWinds, etc, but I don't think this is something CloudStack
> should do.

I agree - there are wonderful tools like puppet, chef for automating
the updates and reporting status, there are good tools like Zenoss,
Zabbix, and Nagios for keeping status on this type of thing.
CloudStack shouldn't try to reinvent the wheel - folks running
CloudStack deployments do need a clue about managing and maintaining
systems at scale, and should realize that CloudStack isn't a solution
for everything and that other pieces of infrastructure should be in
place.

--David

Reply via email to