We’ve accumulated a load of tomcat installations and having refactored
our installations of it so it’s now a single definition which installs
the version of tomcat you asked for (so you drop it into the recipe
you want it in) I now want to clean up all the unused ones.
My thinking is to add a report handler which figures out which
versions of tomcat we actually used in a run, drop that to a file
somewhere locally and then use that file next time around to clean up
all the dead ones…
Or am I missing something and making this more work than needed!
–
Alex Kiernan
I would just extend your tomcat installation cookbook to clean up the
old ones idempotently.
Adam
On Mon, Sep 5, 2011 at 5:27 AM, Alex Kiernan alex.kiernan@gmail.com wrote:
We've accumulated a load of tomcat installations and having refactored
our installations of it so it's now a single definition which installs
the version of tomcat you asked for (so you drop it into the recipe
you want it in) I now want to clean up all the unused ones.
My thinking is to add a report handler which figures out which
versions of tomcat we actually used in a run, drop that to a file
somewhere locally and then use that file next time around to clean up
all the dead ones...
Or am I missing something and making this more work than needed!
--
Alex Kiernan
--
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com
So something like collect all the ones we've used in a global variable
and then clean up the rest at the end? Is there a way of hooking into
"the end" or should I just have a recipe I run last?
On Mon, Sep 5, 2011 at 6:58 PM, Adam Jacob adam@opscode.com wrote:
I would just extend your tomcat installation cookbook to clean up the
old ones idempotently.
Adam
On Mon, Sep 5, 2011 at 5:27 AM, Alex Kiernan alex.kiernan@gmail.com wrote:
We've accumulated a load of tomcat installations and having refactored
our installations of it so it's now a single definition which installs
the version of tomcat you asked for (so you drop it into the recipe
you want it in) I now want to clean up all the unused ones.
My thinking is to add a report handler which figures out which
versions of tomcat we actually used in a run, drop that to a file
somewhere locally and then use that file next time around to clean up
all the dead ones...
Or am I missing something and making this more work than needed!
--
Alex Kiernan
--
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com
--
Alex Kiernan
I don't know that it needs to happen at the end, honestly. Just have the tomcat cookbook deploy the right version, and then add whatever logic you need to clean up the old ones, and move along.
--
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com
On Tuesday, September 6, 2011 at 11:06 AM, Alex Kiernan wrote:
So something like collect all the ones we've used in a global variable
and then clean up the rest at the end? Is there a way of hooking into
"the end" or should I just have a recipe I run last?
On Mon, Sep 5, 2011 at 6:58 PM, Adam Jacob <adam@opscode.com (mailto:adam@opscode.com)> wrote:
I would just extend your tomcat installation cookbook to clean up the
old ones idempotently.
Adam
On Mon, Sep 5, 2011 at 5:27 AM, Alex Kiernan <alex.kiernan@gmail.com (mailto:alex.kiernan@gmail.com)> wrote:
We've accumulated a load of tomcat installations and having refactored
our installations of it so it's now a single definition which installs
the version of tomcat you asked for (so you drop it into the recipe
you want it in) I now want to clean up all the unused ones.
My thinking is to add a report handler which figures out which
versions of tomcat we actually used in a run, drop that to a file
somewhere locally and then use that file next time around to clean up
all the dead ones...
Or am I missing something and making this more work than needed!
--
Alex Kiernan
--
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com (mailto:adam@opscode.com)
--
Alex Kiernan
I've explained it poorly... we're doing one tomcat instance per app,
then multiple tomcat instances/apps per host, and each of those
tomcats can be different versions - the definition goes something like
this:
apache_tomcat "tomcat 6.0.32" do
version "6.0.32"
...
end
We install each of those into /opt (catalina_home) and then have an
individual instance for the app in /srv (catalina_base). The
definition then gets referenced in individual recipes which deploy
both the catalina_home piece (if needed) and the catalina_base piece.
It's cleaning up those in /opt which aren't referenced by the end of
the run which I'm trying to clean up.
On Tue, Sep 6, 2011 at 8:35 PM, Adam Jacob adam@opscode.com wrote:
I don't know that it needs to happen at the end, honestly. Just have the tomcat cookbook deploy the right version, and then add whatever logic you need to clean up the old ones, and move along.
--
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com
On Tuesday, September 6, 2011 at 11:06 AM, Alex Kiernan wrote:
So something like collect all the ones we've used in a global variable
and then clean up the rest at the end? Is there a way of hooking into
"the end" or should I just have a recipe I run last?
On Mon, Sep 5, 2011 at 6:58 PM, Adam Jacob <adam@opscode.com (mailto:adam@opscode.com)> wrote:
I would just extend your tomcat installation cookbook to clean up the
old ones idempotently.
Adam
On Mon, Sep 5, 2011 at 5:27 AM, Alex Kiernan <alex.kiernan@gmail.com (mailto:alex.kiernan@gmail.com)> wrote:
We've accumulated a load of tomcat installations and having refactored
our installations of it so it's now a single definition which installs
the version of tomcat you asked for (so you drop it into the recipe
you want it in) I now want to clean up all the unused ones.
My thinking is to add a report handler which figures out which
versions of tomcat we actually used in a run, drop that to a file
somewhere locally and then use that file next time around to clean up
all the dead ones...
Or am I missing something and making this more work than needed!
--
Alex Kiernan
--
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: adam@opscode.com (mailto:adam@opscode.com)
--
Alex Kiernan
--
Alex Kiernan