cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laszlo Hornyak (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-1146) auto update of KVM agent
Date Sat, 14 Mar 2015 11:08:38 GMT

    [ 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)

Mime
View raw message