[jira] [Commented] (CLOUDSTACK-1146) auto update of KVM agent

["Wido den Hollander (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570167#comment-13570167 ] 

Wido den Hollander commented on CLOUDSTACK-1146:
------------------------------------------------

I totally disagree on this one.

Let CloudStack do what it does best and don't try to re-invent the wheel here.

With proper RPM and DEB packaging tools like Puppet and Chef are easily up to the task by just having Apt or Yum update the Agent.

As soon as a new CloudStack version comes out, new packages are pushed to the RPM/DEB repo (or admins can maintain their own) and can let Apt and Yum do the rest.
                
> auto update of KVM agent
> ------------------------
>
>                 Key: CLOUDSTACK-1146
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1146
>             Project: CloudStack
>          Issue Type: New Feature
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: KVM
>    Affects Versions: 4.0.0
>            Reporter: Kevin Kluge
>
> I'd like to see a feature to have the KVM agent automatically updated.  Managing hundreds or thousands of hosts becomes unwieldy in the current design.  Chef/Puppet can help but I think it'd be helpful to manage the update through CloudStack.
> From an earlier mail on this topic:
> > 
> > - In connection to management server, the version of the software is
> > exchanged.
> > - Management server decides that it needs to be downloaded and terminates
> > the connection with a response that contains the url to the new package.
> > - The agent downloads the package using wget and quits.
> > - The script that restarts the agent explodes the package and restarts the agent.
> > - The agent connects again with the matched version.
> I'd want this to have some way for the admin to control the update.  The use case is to slowly roll out the change across the hosts, or roll it out to just a few clusters/pods first, verify functionality, then roll it out to all hosts.  Maybe unmanage hosts/clusters is sufficient for this.
> We also need to think through host OS upgrade.  Suppose a version of CloudStack no longer supports RHEL 6.x for example.  Now the admin needs to update RHEL then CloudStack.  So it would be nice if the MS could recognize that the RHEL version has changed, then download the "new " version of the agent (it's actually the same version of CloudStack agent, but built for RHEL 7.x for example), then the admin upgrades CS Management Server, then the new version of CS agent for RHEL 7.x is downloaded. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira