Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <35F04D4C394874409D9BE4BF45AC5EA9010B286BF024@BANPMAILBOX01.citrite.net>
References: 
 <02C38648D4635F4EB02DE11EE81CF1EE0120ABB5635E@BANPMAILBOX01.citrite.net>
 <CA+96GG6z-ZREoca=-jYXSb+uaiTgrfyGna7_P-7vnwZs0TXmpA@mail.gmail.com>
 <CAKprHVbrQg7sWXVDuD2SM7Zf8M3O1iuzVByhbLitDsvWYiw8HA@mail.gmail.com>
 <35F04D4C394874409D9BE4BF45AC5EA9010B286BF024@BANPMAILBOX01.citrite.net>
From: David Nalley <david@gnsa.us>
Date: Mon, 21 Jan 2013 14:38:04 -0500
Message-ID: 
 <CAKprHVbOzx22zuwDG9FK2F_NTAGkNgX6e-Lfzvr1yNgdnTJmKg@mail.gmail.com>
Subject: Re: FS for host updates notifications
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 15, 2013 at 1:02 PM, Ram Ganesh <Ram.Ganesh@citrix.com> wrote:
>> -----Original Message-----
>> From: David Nalley [mailto:david@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.childers@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 X=
en hosts managed by CloudStack from a central repository which is updated a=
s and when a patch is available for a version of XenServer and presents a n=
eat report of which patches are already applied on a given host and which a=
re 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 th=
e credentials of all his/her Xen hosts to an external monitoring system a C=
loud Admin can have CloudStack provide a single central interface to these =
external software like zabbix. This to me makes integration with third part=
y software like zabbix, zenoss much easier and meaningful. It is an operati=
onal nightmare for an Admin to key in credentials of all his/her hosts to b=
oth CloudStack and his external management systems. This feature can be sup=
ported across other elements managed by CloudStack as long as those element=
s 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 t=
ime 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.

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