Any interest in a knife plugin for package updates?


#1

Hi!

I wrote a rake task which does the following:

  1. connect to each role in an (chef) environment and show all available package updates (with new version and current installed version)
  2. for each node ask the user if all updates should be applied and if ‘no’, step through the list of updates and ask for each single update. if ENV[PACKAGES] (string with package names, seperated by ‘,’) is applied to the rake task, those packages will be updated without confirmation.

To avoid critical application updates (like postgresql), we set those packages ‘on hold’ (dpkg --set-selections) by a cookbook, so that they don’t get touched or listed by ‘apt-get dist-upgrade’ (which is executed in that rake task). In this combination keeping our ~50 (debian) nodes up to date is now a very simple and controllable task without much effort.

If there’s any interest, I could start to write a knife plugin for it.

Or how do you manage package updates? Are there better ways?

Holger Amann
Sauspiel GmbH
Reichenberger Str. 113a
10999 Berlin

holger@sauspiel.de

Tel. +49 (0) 30 61651135
Fax +49 (0) 30 61651138

Handelsregister Berlin: HRB 131781
Steuernummer: 29/014/05394
Geschäftsführung: A. Reissner, M. Kavalar


#2

Hi Holger,

yes, I’d like to use that!

Steffen

On 10/11/13 7:40 AM, Holger Amann wrote:

Hi!

I wrote a rake task which does the following:

  1. connect to each role in an (chef) environment and show all available package updates (with new version and current installed version)
  2. for each node ask the user if all updates should be applied and if ‘no’, step through the list of updates and ask for each single update. if ENV[PACKAGES] (string with package names, seperated by ‘,’) is applied to the rake task, those packages will be updated without confirmation.

To avoid critical application updates (like postgresql), we set those packages ‘on hold’ (dpkg --set-selections) by a cookbook, so that they don’t get touched or listed by ‘apt-get dist-upgrade’ (which is executed in that rake task). In this combination keeping our ~50 (debian) nodes up to date is now a very simple and controllable task without much effort.

If there’s any interest, I could start to write a knife plugin for it.

Or how do you manage package updates? Are there better ways?

Holger Amann
Sauspiel GmbH
Reichenberger Str. 113a
10999 Berlin

holger@sauspiel.de

Tel. +49 (0) 30 61651135
Fax +49 (0) 30 61651138

Handelsregister Berlin: HRB 131781
Steuernummer: 29/014/05394
Geschäftsführung: A. Reissner, M. Kavalar


#3

I think we mentioned at ChefConf this year that we wrote a cookbook to try
to handle this. A knife plugin seems like an interesting alternative, but
we were thinking in terms of patching many servers at once … in which
case you really don’t want a human to answer a series of yes-or-no
questions even once to say which packages should or shouldn’t be upgraded.

By moving those decisions into a version-controlled Chef object, it’s at
least subject to your change control processes.

Has anyone else done anything like this in OSS Chef for patching, BTW?

On Fri, Oct 11, 2013 at 10:07 AM, Steffen Gebert st+gmane@st-g.de wrote:

Hi Holger,

yes, I’d like to use that!

Steffen

On 10/11/13 7:40 AM, Holger Amann wrote:

Hi!

I wrote a rake task which does the following:

  1. connect to each role in an (chef) environment and show all available
    package updates (with new version and current installed version)
  2. for each node ask the user if all updates should be applied and if
    ’no’, step through the list of updates and ask for each single update. if
    ENV[PACKAGES] (string with package names, seperated by ‘,’) is applied to
    the rake task, those packages will be updated without confirmation.

To avoid critical application updates (like postgresql), we set those
packages ‘on hold’ (dpkg --set-selections) by a cookbook, so that they
don’t get touched or listed by ‘apt-get dist-upgrade’ (which is executed in
that rake task). In this combination keeping our ~50 (debian) nodes up to
date is now a very simple and controllable task without much effort.

If there’s any interest, I could start to write a knife plugin for it.

Or how do you manage package updates? Are there better ways?

Holger Amann
Sauspiel GmbH
Reichenberger Str. 113a
10999 Berlin

holger@sauspiel.de

Tel. +49 (0) 30 61651135
Fax +49 (0) 30 61651138

Handelsregister Berlin: HRB 131781
Steuernummer: 29/014/05394
Geschäftsführung: A. Reissner, M. Kavalar


#4

here it is :slight_smile:

Please test it and give me some feedback

Am 11.10.2013 um 19:07 schrieb Steffen Gebert st+gmane@st-g.de:

yes, I’d like to use that!

Holger Amann
Sauspiel GmbH
Reichenberger Str. 113a
10999 Berlin

holger@sauspiel.de

Tel. +49 (0) 30 61651135
Fax +49 (0) 30 61651138

Handelsregister Berlin: HRB 131781
Steuernummer: 29/014/05394
Geschäftsführung: A. Reissner, M. Kavalar


#5

Already bad ass man.

Thank you so much.

Best Regards,
JJ Asghar
e: jj.asghar@peopleadmin.com | c: 512.619.0722 | o: 512.977.5876

From: Holger Amann <holger@sauspiel.demailto:holger@sauspiel.de>
Reply-To: <chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Monday, October 14, 2013 3:27 PM
To: <chef@lists.opscode.commailto:chef@lists.opscode.com>
Subject: [chef] Re: Any interest in a knife plugin for package updates?

here it is :slight_smile:

Please test it and give me some feedback

Am 11.10.2013 um 19:07 schrieb Steffen Gebert <st+gmane@st-g.demailto:st+gmane@st-g.de>:

yes, I’d like to use that!

Holger Amann
Sauspiel GmbH
Reichenberger Str. 113a
10999 Berlin

holger@sauspiel.demailto:holger@sauspiel.de

Tel. +49 (0) 30 61651135
Fax +49 (0) 30 61651138

Handelsregister Berlin: HRB 131781
Steuernummer: 29/014/05394
Geschäftsführung: A. Reissner, M. Kavalar