> -----Original Message-----
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: 22 January 2013 01:08
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: FS for host updates notifications
>
> On Tue, Jan 15, 2013 at 1:02 PM, Ram Ganesh <ram.gan...@citrix.com>
> wrote:
> >> -----Original Message-----
> >> From: David Nalley [mailto:da...@gnsa.us]
> >> Sent: 08 January 2013 01:02
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: Re: FS for host updates notifications
> >>
> >> On Mon, Jan 7, 2013 at 2:21 PM, Chip Childers
> >> <chip.child...@sungard.com> wrote:
> >> > Bumping this thread.
> >> >
> >> > In reviewing CLOUDSTACK-192, I don't believe that we have reached
> >> > consensus on this feature being part of CloudStack. Ram noted in
> the
> >> > ticket that the conversation would be revived. Do we want to do
> >> that?
> >> >
> >> > If not, I'm going to close CLOUDSTACK-192 as not applicable, move
> the
> >> > functional spec to the uncommitted design page, and note that it
> >> > wasn't accepted for now.
> >> >
> >> > If it was, I believe that Citrix released this feature in
> >> > CloudPlatform. If that is the case, we will have to bring in the
> >> code
> >> > via the IP Clearance process.
> >> >
> >> > Does someone want to try to drive this to consensus?
> >> >
> >>
> >>
> >> As I understand it the proposed plan is to check a URL that the
> >> project doesn't control, and based on the contents of that URL
> advise
> >> users, regardless of version of CloudStack that they have deployed
> >> that there is an update to to their hypervisor and the unwritten
> part
> >> of this implies that the user should apply said update, and that we
> >> essentially are condoning it, despite the fact that we have done no
> >> testing. CloudStack is in a weird position in that it orchestrates
> >> lots of moving pieces. Blindly encouraging folks to update scares
> the
> >> sysadmin in me, yes we might avoid some problems, but if you look at
> >> some of the things we might have 'encouraged' upgrades for across
> all
> >> of the hypervisors, letting a third party tell us "it's ok" should
> >> scare you as well.
> >>
> >> --David
> >
> > That is true David. This feature collates available patches for all
> the Xen hosts managed by CloudStack from a central repository which is
> updated as and when a patch is available for a version of XenServer and
> presents a neat report of which patches are already applied on a given
> host and which are not across various versions of a host. What it does
> not do is to "apply patches". That is left to tools that do a better
> job. Instead of sharing the credentials of all his/her Xen hosts to an
> external monitoring system a Cloud Admin can have CloudStack provide a
> single central interface to these external software like zabbix. This
> to me makes integration with third party software like zabbix, zenoss
> much easier and meaningful. It is an operational nightmare for an Admin
> to key in credentials of all his/her hosts to both CloudStack and his
> external management systems. This feature can be supported across other
> elements managed by CloudStack as long as those elements provide a
> standard protocol to share the patch details. Also please note
> scalability is not a concern here as we are not looking at providing
> real time updates.
> >
>
>
> So the premise is that applying updates is good. (otherwise, we
> wouldn't care to know that updates are available) And generally that
> is a true statement. However, it is not always true, and as proposed
> we have no way. of distinguishing between the two.
>
> If the proposal was that there would be some page of XML under the
> project's control, and was version specific, and had an explicit
> obligation of QAing updates against each specific version before
> listing an available update and we had eventual commitment to do this
> against all supported platforms, I could see this being awesome. But
> that's a far cry from where the proposal seems to stand today, which
> is something that scares me.
>
Good point David. We may need CS QA'ed list of patches that can be
verified against.
> Imaging someone installing 4.1.0 today, and performing no further ACS
> updates. Are we sure that 3 years down the road every hotfix/patch
> that is available won't break something? I am not, and not personally
> willing to cede that to a third party.
>
> --David
