Best Practice Performing Upgrade and Uninstall

Hi,

I am new to Chef.

I ran over some recipes in several cookbooks maintained by the community.

All I see is installation. I wonder the best practice of upgrading and
uninstalling software?

Could you give me some brief idea how to upgrade and uninstall software?
(please do not say " apt-get uninstall").

PS: I also ran over some recipes on OpsWorks which is one part of service
provided by AWS.

Cheers,
Howard

are you using berkshelf? berks can show you outdated cookbooks using berks outdated. We manually run this and update minor version changes whenever
available, and then test it in staging. Except the version bump in
Berksfile, rest is automates (i.e. uploading cookbook & testing it on
staging ).

On Tue, Aug 20, 2013 at 7:20 PM, Howard Zhang
howardzhanghaohua@gmail.comwrote:

Hi,

I am new to Chef.

I ran over some recipes in several cookbooks maintained by the community.

All I see is installation. I wonder the best practice of upgrading and
uninstalling software?

Could you give me some brief idea how to upgrade and uninstall software?
(please do not say " apt-get uninstall").

PS: I also ran over some recipes on OpsWorks which is one part of service
provided by AWS.

Cheers,
Howard

I assumed Chef server could do it too. Chef Server bump all version of
cookbooks I uploaded, all I need is to assign a specific version of
cookbook to run list. I think that is not what I am talking about.

Take source code of tomcat for example. I download the source code zip, put
it in “file” folder. I write a recipe to install it, blah, blah blah.
What I concern is how to do the upgrade, when major version changes come?
What is the best practice or say “common practice” you guys using?

Sincerely,
Howard Zhang Haohua
MSc Student in Information Technology
The Department of Computer Science and Engineering
School of Engineering
Hong Kong University of Science and Technology
Email: howardzhanghaohua@gmail.com
about.me/HowardZhang

On Wed, Aug 21, 2013 at 10:30 AM, Ranjib Dey dey.ranjib@gmail.com wrote:

are you using berkshelf? berks can show you outdated cookbooks using
berks outdated. We manually run this and update minor version changes
whenever available, and then test it in staging. Except the version bump in
Berksfile, rest is automates (i.e. uploading cookbook & testing it on
staging ).

On Tue, Aug 20, 2013 at 7:20 PM, Howard Zhang <howardzhanghaohua@gmail.com

wrote:

Hi,

I am new to Chef.

I ran over some recipes in several cookbooks maintained by the community.

All I see is installation. I wonder the best practice of upgrading and
uninstalling software?

Could you give me some brief idea how to upgrade and uninstall software?
(please do not say " apt-get uninstall").

PS: I also ran over some recipes on OpsWorks which is one part of service
provided by AWS.

Cheers,
Howard

Hi Howard,

If you want to uninstall a piece of software via chef the easiest way is to
use the ‘package’ resource with the ‘:remove’ action:

package “apache2” do
action :remove
end

To make sure you always upgrade to the latest available version use
’:upgrade’:

package “apache2” do
action :upgrade
end

You can also pin the specific version you want to install:

package “apache2” do
version "1.0"
action :install
end

See here for more information:
http://docs.opscode.com/resource_package.html

HTH,
Torben
On Aug 21, 2013 5:04 AM, “Howard Zhang” howardzhanghaohua@gmail.com wrote:

I assumed Chef server could do it too. Chef Server bump all version of
cookbooks I uploaded, all I need is to assign a specific version of
cookbook to run list. I think that is not what I am talking about.

Take source code of tomcat for example. I download the source code zip,
put it in “file” folder. I write a recipe to install it, blah, blah blah.
What I concern is how to do the upgrade, when major version changes come?
What is the best practice or say “common practice” you guys using?

Sincerely,
Howard Zhang Haohua
MSc Student in Information Technology
The Department of Computer Science and Engineering
School of Engineering
Hong Kong University of Science and Technology
Email: howardzhanghaohua@gmail.com
about.me/HowardZhang

On Wed, Aug 21, 2013 at 10:30 AM, Ranjib Dey dey.ranjib@gmail.com wrote:

are you using berkshelf? berks can show you outdated cookbooks using
berks outdated. We manually run this and update minor version changes
whenever available, and then test it in staging. Except the version bump in
Berksfile, rest is automates (i.e. uploading cookbook & testing it on
staging ).

On Tue, Aug 20, 2013 at 7:20 PM, Howard Zhang <
howardzhanghaohua@gmail.com> wrote:

Hi,

I am new to Chef.

I ran over some recipes in several cookbooks maintained by the
community.

All I see is installation. I wonder the best practice of upgrading and
uninstalling software?

Could you give me some brief idea how to upgrade and uninstall software?
(please do not say " apt-get uninstall").

PS: I also ran over some recipes on OpsWorks which is one part of
service provided by AWS.

Cheers,
Howard

Hi Torben,

Yes, I know the “package” resource, but the prerequisite is that I have
pack my own source code into a .deb package or .rpm package.

But if the software is developed by myself, I did not pack the source code,
and it do not exist in any package repository.

What is the common practice on this situation?

Cheers,
Howard

On Wed, Aug 21, 2013 at 1:10 PM, Torben Knerr ukio@gmx.de wrote:

Hi Howard,

If you want to uninstall a piece of software via chef the easiest way is
to use the ‘package’ resource with the ‘:remove’ action:

package “apache2” do
action :remove
end

To make sure you always upgrade to the latest available version use
’:upgrade’:

package “apache2” do
action :upgrade
end

You can also pin the specific version you want to install:

package “apache2” do
version "1.0"
action :install
end

See here for more information:
http://docs.opscode.com/resource_package.html

HTH,
Torben
On Aug 21, 2013 5:04 AM, “Howard Zhang” howardzhanghaohua@gmail.com
wrote:

I assumed Chef server could do it too. Chef Server bump all version of
cookbooks I uploaded, all I need is to assign a specific version of
cookbook to run list. I think that is not what I am talking about.

Take source code of tomcat for example. I download the source code zip,
put it in “file” folder. I write a recipe to install it, blah, blah blah.
What I concern is how to do the upgrade, when major version changes come?
What is the best practice or say “common practice” you guys using?

Sincerely,
Howard Zhang Haohua
MSc Student in Information Technology
The Department of Computer Science and Engineering
School of Engineering
Hong Kong University of Science and Technology
Email: howardzhanghaohua@gmail.com
about.me/HowardZhang

On Wed, Aug 21, 2013 at 10:30 AM, Ranjib Dey dey.ranjib@gmail.comwrote:

are you using berkshelf? berks can show you outdated cookbooks using
berks outdated. We manually run this and update minor version changes
whenever available, and then test it in staging. Except the version bump in
Berksfile, rest is automates (i.e. uploading cookbook & testing it on
staging ).

On Tue, Aug 20, 2013 at 7:20 PM, Howard Zhang <
howardzhanghaohua@gmail.com> wrote:

Hi,

I am new to Chef.

I ran over some recipes in several cookbooks maintained by the
community.

All I see is installation. I wonder the best practice of upgrading and
uninstalling software?

Could you give me some brief idea how to upgrade and uninstall
software? (please do not say " apt-get uninstall").

PS: I also ran over some recipes on OpsWorks which is one part of
service provided by AWS.

Cheers,
Howard

Am 2013-08-21 04:20, schrieb Howard Zhang:

Hi,

I am new to Chef.

I ran over some recipes in several cookbooks maintained by the
community.

All I see is installation. I wonder the best practice of upgrading
and
uninstalling software?

Could you give me some brief idea how to upgrade and uninstall
software?
(please do not say " apt-get uninstall").

Some cookbooks ship recipes for uninstall. But most don’t bother.
Either you uninstall via "apt-get uninstall " (I prefer purge). Or
you just throw that vm away.
When you automate the creation of virtual machines, its easier to just
remove the recipe from the node and re-install the node then to spent
valuable tech-time touching the node(s) and removing the software by
hand.

Upgrading I do by hand (apt-get upgrade). I tried using the :upgrade
action on the package resource once, but that upgrades packages as soon
as some new version is available and not during hours I have time for
this. Its not much fun when the whole web-app shuts down during
office-hours because apache has to stop, update and restart. Better
schedule that time. Or just create a new node with the current versions,
let the reverse-proxy pick that up and then remove the old node…

Have fun,

Arnold

Greetings !
I am trying to pass a Hash as a variable to the Template like this:

==================================
params = {‘key1’ => ‘val1’, ‘key2’ => ‘val2’}

template “/etc/test.conf” do
mode 0640
variables(
:params => params
)
end

My Template looks like this:

==================================

params = <%= @params.each_pair {|k,v| print "#{k}=#{v} "} %>

But this doesn’t work, giving the errors on the compile time:

==================================

(erubis):84: syntax error, unexpected tIDENTIFIER, expecting ‘)’
(erubis):90: syntax error, unexpected tIDENTIFIER, expecting ‘)’

Please advise.

Thanks !

On Wed, 21 Aug 2013 14:34:43 +0300, “Michael L.” bigmyx@gmail.com
wrote:

Greetings !
I am trying to pass a Hash as a variable to the Template like this:

==================================
params = {‘key1’ => ‘val1’, ‘key2’ => ‘val2’}

template “/etc/test.conf” do
mode 0640
variables(
:params => params
)
end

My Template looks like this:

==================================

params = <%= @params.each_pair {|k,v| print "#{k}=#{v} "} %>

But this doesn’t work, giving the errors on the compile time:

==================================

(erubis):84: syntax error, unexpected tIDENTIFIER, expecting ‘)’
(erubis):90: syntax error, unexpected tIDENTIFIER, expecting ‘)’

Please advise.

Thanks !

<% ruby code -%>
<%= var_to_display %>

Exemple on what you try to accomplish (working for me on an actual
code):

<% @params.each do |key,value| -%>
<%= key %>=<%= value %>
<% end -%>

Or you may try <% @params.each_pair {|k,v| print "#{k}=#{v} "} -%>
but there I’ve no idea if it will work or not.

On 8/21/2013 2:36 AM, Howard Zhang wrote:

Hi Torben,

Yes, I know the “package” resource, but the prerequisite is that I
have pack my own source code into a .deb package or .rpm package.

But if the software is developed by myself, I did not pack the source
code, and it do not exist in any package repository.

What is the common practice on this situation?

The common practice is to package your software for your OS of choice
using FPM[1] and stick it in an appropriate package repository that you
host yourself.

Jeff

[1: Search Google for effing package management]

Have you tried this?


params = <% @params.each

HTH, Torben
On Aug 21, 2013 1:34 PM, “Michael L.” bigmyx@gmail.com wrote:

Greetings !
I am trying to pass a Hash as a variable to the Template like this:

==================================
params = {‘key1’ => ‘val1’, ‘key2’ => ‘val2’}

template “/etc/test.conf” do
mode 0640
variables(
:params => params
)
end

My Template looks like this:

==================================

params = <%= @params.each_pair {|k,v| print "#{k}=#{v} "} %>

But this doesn’t work, giving the errors on the compile time:

==================================

(erubis):84: syntax error, unexpected tIDENTIFIER, expecting ‘)’
(erubis):90: syntax error, unexpected tIDENTIFIER, expecting ‘)’

Please advise.

Thanks !

On Wednesday, August 21, 2013 at 9:33 AM, Torben Knerr wrote:

Have you tried this?

params = <% @params.each

HTH, Torben
On Aug 21, 2013 1:34 PM, “Michael L.” <bigmyx@gmail.com (mailto:bigmyx@gmail.com)> wrote:

Greetings !
I am trying to pass a Hash as a variable to the Template like this:

==================================
params = {‘key1’ => ‘val1’, ‘key2’ => ‘val2’}

template “/etc/test.conf” do
mode 0640
variables(
:params => params
)
end

My Template looks like this:

==================================

params = <%= @params.each_pair {|k,v| print "#{k}=#{v} "} %>

But this doesn’t work, giving the errors on the compile time:

==================================

(erubis):84: syntax error, unexpected tIDENTIFIER, expecting ‘)’
(erubis):90: syntax error, unexpected tIDENTIFIER, expecting ‘)’

Please advise.

Thanks !

You have a syntax error elsewhere in your template. Ruby is expecting a ‘)’ character, which means you have an open-paren “(” without a matching “)”.


Daniel DeLeo

It was my fault,
the error was caused by a stupid typo which was hard to spot …
thanks !

On Aug 21, 2013, at 7:48 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, August 21, 2013 at 9:33 AM, Torben Knerr wrote:

Have you tried this?


params = <% @params.each

HTH, Torben

On Aug 21, 2013 1:34 PM, “Michael L.” bigmyx@gmail.com wrote:

Greetings !
I am trying to pass a Hash as a variable to the Template like this:

==================================
params = {‘key1’ => ‘val1’, ‘key2’ => ‘val2’}

template “/etc/test.conf” do
mode 0640
variables(
:params => params
)
end

My Template looks like this:

==================================

params = <%= @params.each_pair {|k,v| print "#{k}=#{v} "} %>

But this doesn’t work, giving the errors on the compile time:

==================================

(erubis):84: syntax error, unexpected tIDENTIFIER, expecting ‘)’
(erubis):90: syntax error, unexpected tIDENTIFIER, expecting ‘)’

Please advise.

Thanks !

You have a syntax error elsewhere in your template. Ruby is expecting a ‘)’ character, which means you have an open-paren “(” without a matching “)”.


Daniel DeLeo

howardzhanghaohua@gmail.com writes:

Yes, I know the “package” resource, but the prerequisite is that I have
pack my own source code into a .deb package or .rpm package.

But if the software is developed by myself, I did not pack the source code,
and it do not exist in any package repository.

What is the common practice on this situation?

If you have non-packaged code that you want to cleanup, I’d recommend
creating a cleanup recipe that removes it (perhaps stopping a service,
removing files and directories, etc).

For non-packaged things, it is hard to make a general uninstall
solution, so the common practice, if you can call it that, is custom
uninstall recipes.

  • seth


Seth Falcon | Development Lead | Opscode | @sfalcon

Thanks all these possible solutions.

Cheers,
Howard

On Thu, Aug 22, 2013 at 5:26 AM, Seth Falcon seth@opscode.com wrote:

howardzhanghaohua@gmail.com writes:

Yes, I know the “package” resource, but the prerequisite is that I have
pack my own source code into a .deb package or .rpm package.

But if the software is developed by myself, I did not pack the source
code,
and it do not exist in any package repository.

What is the common practice on this situation?

If you have non-packaged code that you want to cleanup, I’d recommend
creating a cleanup recipe that removes it (perhaps stopping a service,
removing files and directories, etc).

For non-packaged things, it is hard to make a general uninstall
solution, so the common practice, if you can call it that, is custom
uninstall recipes.

  • seth


Seth Falcon | Development Lead | Opscode | @sfalcon

You could always wrap your code with FPM. That way you can use the package resource to install, uninstall, and upgrade.

On Aug 21, 2013, at 3:52, “Arnold Krille” arnold@arnoldarts.de wrote:

Am 2013-08-21 04:20, schrieb Howard Zhang:

Hi,
I am new to Chef.
I ran over some recipes in several cookbooks maintained by the community.
All I see is installation. I wonder the best practice of upgrading and
uninstalling software?
Could you give me some brief idea how to upgrade and uninstall software?
(please do not say " apt-get uninstall").

Some cookbooks ship recipes for uninstall. But most don’t bother.
Either you uninstall via "apt-get uninstall " (I prefer purge). Or you just throw that vm away.
When you automate the creation of virtual machines, its easier to just remove the recipe from the node and re-install the node then to spent valuable tech-time touching the node(s) and removing the software by hand.

Upgrading I do by hand (apt-get upgrade). I tried using the :upgrade action on the package resource once, but that upgrades packages as soon as some new version is available and not during hours I have time for this. Its not much fun when the whole web-app shuts down during office-hours because apache has to stop, update and restart. Better schedule that time. Or just create a new node with the current versions, let the reverse-proxy pick that up and then remove the old node…

Have fun,

Arnold