On Mon, Sep 24, 2012 at 8:30 PM, Chip Childers <chip.child...@sungard.com> wrote: > On Mon, Sep 24, 2012 at 12:29 PM, David Nalley <da...@gnsa.us> wrote: >> On Mon, Sep 24, 2012 at 10:04 AM, Wido den Hollander <w...@widodh.nl> 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 > > Not to jump on the bandwagon here, but I also agree that, while this > might seem like a good idea for a small environment, it doesn't > functionally scale. We should be doing everything we can to ensure > that KVM, ESX and Xen are supported in the same way, and I don't see > how this gets implemented across the different HV's cleanly. > > Perhaps an alternative would be to think of this as an external > project to CloudStack itself (or even look for another project that > might be a good fit)? I know that the use case exists, I'm just > concerned that it will end up adding a set of features that don't work > as well as an alternative tool chain might be able to provide. > > If we DO end up doing this, then I think we would have to bite the > bullet and figure out how to make it work with more than just Xen. At > the very least, the approach needs to account for the other > hypervisors. Looking through the functional spec, I think that there > is some work to do on that front. Again though, this is only if we do > end up agreeing that it belongs in CloudStack. > > -chip
Another alternative for achieving this (without adding the per-hypervisor logic to CloudStack itself) might be to build a framework for plugging in best-of-breed update tools for the various hypervisors (and bare metal servers). Example: provide the KVM update feature via a combination of puppet manifests and mcollective instructions, where CloudStack isn't responsible for the actual update tracking or installation of updates, merely calling an appropriate external tool to query status and force policy updates. A simple command line specification for inputs and outputs could allow for various environments to have scripts that drive the process that's most appropriate for their specific conditions. Thoughts? > >>> >>> 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 >>
