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

["Laszlo Hornyak (JIRA)" <ji...@apache.org>]

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

Laszlo Hornyak commented on CLOUDSTACK-1146:
--------------------------------------------

The idea is not completely new, for example ovirt does this, but I still agree that it is better if you let the existing tools do this.

No progress on this ticket for two years now. Do you guys want to try to get to an agreement or can we close it?

> 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 was sent by Atlassian JIRA
(v6.3.4#6332)