Puppet users - Apr 2013 - How do I automagically remove old versions of jar files?

I keep running into the following upgrade pattern.

Previous Puppet run declared: 
     file { "my_jar.1.2.3.jar": ... }

New puppet run declares:
     file {"my_jar.2.4.6.jar": ... }

But the new puppet run doesn''t delete the older versions of this jar
file.

Is there a standard puppet pattern for removing older versions of jars 
without explicitly naming each version?

The overall pattern is...

   declare resource file {  "my_jar.1.2.3.jar": }
   ensure absent for all older versions of my_jar
   ensure => "1.2.3"  (imaginary code since version is specified in
the
name)
   only restart service if my_jar.nnn.jar  has changed

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Wednesday, April 24, 2013 4:24:08 PM UTC-5, Larry Fast
wrote:
>
> I keep running into the following upgrade pattern.
>
> Previous Puppet run declared: 
>      file { "my_jar.1.2.3.jar": ... }
>
> New puppet run declares:
>      file {"my_jar.2.4.6.jar": ... }
>
> But the new puppet run doesn''t delete the older versions of this
jar file.
>  
>
> Is there a standard puppet pattern for removing older versions of jars 
> without explicitly naming each version?
>
> The overall pattern is...
>
>    declare resource file {  "my_jar.1.2.3.jar": }
>    ensure absent for all older versions of my_jar
>    ensure => "1.2.3"  (imaginary code since version is
specified in the
> name)
>    only restart service if my_jar.nnn.jar  has changed
>
>
You need to be able to identify the files to remove somehow.  If you
don''t
want to list them individually, then the most automated way to do it would 
be to manage the directory in which they reside, and use the
''purge''
parameter for the directory.  That does require that all the wanted 
contents of the directory be managed, but you should be able to arrange 
that one way or another.  For example, if there are unmanaged files that 
you want to keep, then you could move the managed jar file(s) to a 
for-purpose, managed subdirectory, and symlink the correct one to its 
original location.

Alternatively, you can probably come up with an Exec that removes (only) 
the unwanted files.  That''s less in the Puppet spirit, but probably
quicker
and easier to write (yet maybe also more prone to bugs).


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Apr 25, 2013, at 9:47 AM, jcbollinger <John.Bollinger@stJude.org>
 wrote:
> On Wednesday, April 24, 2013 4:24:08 PM UTC-5, Larry Fast wrote:
> I keep running into the following upgrade pattern.
>
> Previous Puppet run declared:
>      file { "my_jar.1.2.3.jar": ... }
>
> New puppet run declares:
>      file {"my_jar.2.4.6.jar": ... }
>
> But the new puppet run doesn''t delete the older versions of this
jar file.
>
> Is there a standard puppet pattern for removing older versions of jars
without explicitly naming each version?
>
> The overall pattern is...
>
>    declare resource file {  "my_jar.1.2.3.jar": }
>    ensure absent for all older versions of my_jar
>    ensure => "1.2.3"  (imaginary code since version is
specified in the name)
>    only restart service if my_jar.nnn.jar  has changed
>
>
>
> You need to be able to identify the files to remove somehow.  If you
don''t want to list them individually, then the most automated way to do
it would be to manage the directory in which they reside, and use the
''purge'' parameter for the directory.  That does require that
all the wanted contents of the directory be managed, but you should be able to
arrange that one way or another.  For example, if there are unmanaged files that
you want to keep, then you could move the managed jar file(s) to a for-purpose,
managed subdirectory, and symlink the correct one to its original location.
>
> Alternatively, you can probably come up with an Exec that removes (only)
the unwanted files.  That''s less in the Puppet spirit, but probably
quicker and easier to write (yet maybe also more prone to bugs).
>
>
> John

John''s suggestion is definitely the cleanest.

Some shops have a regularly scheduled deployment of a new jar with updated
content, and like to keep the last version around.
If that is close to your paradigm,  you could also do this with a cron job to
purge any jar files older than ((2x(deployment delta))+~7 ) days. This would
give you the ability to keep the current+last in case you need to rollback at
some point in time.




________________________________

This message may contain confidential or privileged information. If you are not
the intended recipient, please advise us immediately and delete this message.
See http://www.datapipe.com/legal/email_disclaimer/ for further information on
confidentiality and the risks of non-secure electronic communication. If you
cannot access these links, please notify us by reply message and we will send
the contents to you.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Wednesday, April 24, 2013 2:24:08 PM UTC-7, Larry Fast
wrote:
>
>
> Is there a standard puppet pattern for removing older versions of jars 
> without explicitly naming each version?
>
>  
Yes! The tidy resource type. 

http://docs.puppetlabs.com/references/latest/type.html#tidy

You''d want something like this: 

tidy {''/tmp/jars'':
  recurse => true,
  matches => "my_jar.*.jar",
}

This example would kill all files matching that shell glob pattern UNLESS 
there''s already a puppet resource for them, so it would leave the
latest
version intact. (I just tested it to make sure that''s the case.)

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Larry Fast <lfast1234@gmail.com> writes:
> Is there a standard puppet pattern for removing older versions of jars 
> without explicitly naming each version?
A couple of solutions in addition to the proposed ones:

- Use your package manager. Build a package containing your jar file and
  upload it to a local repo; your resource then becomes:
    package { ''my_jar'': version =>
''2.4.6'', }

- Write a custom fact listing the files you will want to remove. This is
  probably the most portable solution but it can prove a bit tricky to
  get it right (actually this is a variant of the solution involving an
  exec resource).

-- 
A

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Thursday, April 25, 2013 1:26:05 PM UTC-5, Nick Fagerlund
wrote:
>
>
>
> tidy {''/tmp/jars'':
>   recurse => true,
>   matches => "my_jar.*.jar",
> }
>
> This example would kill all files matching that shell glob pattern UNLESS 
> there''s already a puppet resource for them, so it would leave the
latest
> version intact. (I just tested it to make sure that''s the case.)
>

Very nice!  I seem always to forget about ''tidy'', but
it''s a good fit
here.  I wish its docs were clear that it does not affect files that are 
otherwise managed, though I guess that''s a reasonable expectation.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Thank you all.  Yes, tidy should be exactly what I need.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.