You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Chip Childers <ch...@sungard.com> on 2013/01/07 20:21:36 UTC
Re: FS for host updates notifications
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?
-chip
On Mon, Sep 24, 2012 at 9:33 AM, Sanjay Tripathi
<sa...@citrix.com> 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.
>
> Regards,
> Sanjay
>
RE: FS for host updates notifications
Posted by Alex Huang <Al...@citrix.com>.
Wow....shows how much I'm removed from Citrix releases now. You're right. My mistake there.
--Alex
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Monday, January 07, 2013 11:29 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: FS for host updates notifications
>
> On Mon, Jan 7, 2013 at 2:25 PM, Alex Huang <Al...@citrix.com> wrote:
> > I could be wrong but I don't think Citrix has done anything wrt to this
> feature. There's no code in existence now.
> >
> > --Alex
>
> I may also be confused, but section 4.5 of the CloudPlatform Release
> Notes [1] talks about "XenServer Hotfix Notification". If I'm not
> interpreting things correctly, please let me know!
>
> -chip
>
> [1] http://support.citrix.com/servlet/KbServlet/download/33105-102-
> 693048/CloudPlatform3.0.6ReleaseNotes.pdf
>
> >> -----Original Message-----
> >> From: Chip Childers [mailto:chip.childers@sungard.com]
> >> Sent: Monday, January 07, 2013 11:22 AM
> >> To: cloudstack-dev@incubator.apache.org
> >> Subject: Re: FS for host updates notifications
> >>
> >> 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?
> >>
> >> -chip
> >>
> >> On Mon, Sep 24, 2012 at 9:33 AM, Sanjay Tripathi
> >> <sa...@citrix.com> 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+upda
> >> tes+notification
> >> >
> >> > Please let me know your suggestions/comments.
> >> >
> >> > Regards,
> >> > Sanjay
> >> >
> >
Re: FS for host updates notifications
Posted by Chip Childers <ch...@sungard.com>.
On Mon, Jan 7, 2013 at 2:25 PM, Alex Huang <Al...@citrix.com> wrote:
> I could be wrong but I don't think Citrix has done anything wrt to this feature. There's no code in existence now.
>
> --Alex
I may also be confused, but section 4.5 of the CloudPlatform Release
Notes [1] talks about "XenServer Hotfix Notification". If I'm not
interpreting things correctly, please let me know!
-chip
[1] http://support.citrix.com/servlet/KbServlet/download/33105-102-693048/CloudPlatform3.0.6ReleaseNotes.pdf
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> Sent: Monday, January 07, 2013 11:22 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: Re: FS for host updates notifications
>>
>> 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?
>>
>> -chip
>>
>> On Mon, Sep 24, 2012 at 9:33 AM, Sanjay Tripathi
>> <sa...@citrix.com> 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+upda
>> tes+notification
>> >
>> > Please let me know your suggestions/comments.
>> >
>> > Regards,
>> > Sanjay
>> >
>
RE: FS for host updates notifications
Posted by Sudha Ponnaganti <su...@citrix.com>.
This done as Citrix Cloud platform release earlier.
-----Original Message-----
From: Alex Huang [mailto:Alex.Huang@citrix.com]
Sent: Monday, January 07, 2013 11:26 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: FS for host updates notifications
I could be wrong but I don't think Citrix has done anything wrt to this feature. There's no code in existence now.
--Alex
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Monday, January 07, 2013 11:22 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: FS for host updates notifications
>
> 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?
>
> -chip
>
> On Mon, Sep 24, 2012 at 9:33 AM, Sanjay Tripathi
> <sa...@citrix.com> 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+upda
> tes+notification
> >
> > Please let me know your suggestions/comments.
> >
> > Regards,
> > Sanjay
> >
RE: FS for host updates notifications
Posted by Alex Huang <Al...@citrix.com>.
I could be wrong but I don't think Citrix has done anything wrt to this feature. There's no code in existence now.
--Alex
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Monday, January 07, 2013 11:22 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: FS for host updates notifications
>
> 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?
>
> -chip
>
> On Mon, Sep 24, 2012 at 9:33 AM, Sanjay Tripathi
> <sa...@citrix.com> 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+upda
> tes+notification
> >
> > Please let me know your suggestions/comments.
> >
> > Regards,
> > Sanjay
> >
RE: FS for host updates notifications
Posted by Ram Ganesh <Ra...@citrix.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@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 <Ra...@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
> >> <ch...@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
Re: FS for host updates notifications
Posted by Wido den Hollander <wi...@widodh.nl>.
On 01/21/2013 08:38 PM, David Nalley wrote:
> On Tue, Jan 15, 2013 at 1:02 PM, Ram Ganesh <Ra...@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
>>> <ch...@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 st
andard pr
otocol 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.
>
> 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.
>
If somebody is still running 4.1.0 three years from now, how likely do
you think it is that person/organization is actually updating it's
hypervisors?
I still don't think this feature is something for CloudStack, but I
think I already made that clear. Other tools can do a better job.
Wido
> --David
>
Re: FS for host updates notifications
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jan 15, 2013 at 1:02 PM, Ram Ganesh <Ra...@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
>> <ch...@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.
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
RE: FS for host updates notifications
Posted by Ram Ganesh <Ra...@citrix.com>.
> -----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
> <ch...@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.
Thanks,
Ram
RE: FS for host updates notifications
Posted by Sudha Ponnaganti <su...@citrix.com>.
+1 on David's comments. This has been discussed from usability stand point. I will wait for Ram to revive the thread to follow up on this.
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Monday, January 07, 2013 11:32 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: FS for host updates notifications
On Mon, Jan 7, 2013 at 2:21 PM, Chip Childers <ch...@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
Re: FS for host updates notifications
Posted by David Nalley <da...@gnsa.us>.
On Mon, Jan 7, 2013 at 2:21 PM, Chip Childers <ch...@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