On Friday, June 14, 2013 2:01:50 AM UTC-5, Tom Lanyon wrote:
Hi John
On 14/06/2013, at 12:06 AM, jcbollinger [...] wrote:
This is where it fell apart for me before, I didn't realise that you
assumed $::app_packages was every possible package; in my first post I'd
specified that $::app_packages was a fact generated on each node from the
list of *currently installed* packages, so it contains all of the packages
which have been previously been installed but not packages which may be
installed in the future.
Hi John
On 14/06/2013, at 12:06 AM, jcbollinger [...] wrote:
This is where it fell apart for me before, I didn't realise that you
assumed $::app_packages was every possible package; in my first post I'd
specified that $::app_packages was a fact generated on each node from the
list of *currently installed* packages, so it contains all of the packages
which have been previously been installed but not packages which may be
installed in the future.
My apologies for the confusion.
I think it's going to be a managerial nightmare to update some such list
of all possible packages, so might look for an alternate solution. I don't
think Puppet really meets our needs here, unless there's a way we can
programmatically parse out all of the versions of the package specified in
our manifests to include them in the $::app_packages (so they get defined
as 'purged') before building the rest of the catalog which would override
them as 'present'.
of all possible packages, so might look for an alternate solution. I don't
think Puppet really meets our needs here, unless there's a way we can
programmatically parse out all of the versions of the package specified in
our manifests to include them in the $::app_packages (so they get defined
as 'purged') before building the rest of the catalog which would override
them as 'present'.
I think you're looking at it the wrong way around. It is a fundamental
problem for you if you don't know what all the packages you (may) want to
manage are. This is not information that ought to be gleaned from your
manifest set, nor even information that you ought to be collecting
dynamically from clients, but rather information which you ought to have a
priori. How you store it and keep it updated is a separate matter that I
have heretofore avoided, but Puppet does have a capable external data
interface, Hiera, that could reasonably be applied to the problem.
Nevertheless, if it is not feasible for you to determine up front all the
packages your apps may be using or may want to use, then you can get by
with a smaller list, consisting of just the union of those packages
currently installed and those you want to be installed. You already have
those data at hand, and it is possible to merge them into the needed list.
For example, rewriting my app::packages this way should help:
class app::packages {
$apps = unique(concat(split($::app_packages, ','), <wanted_packages>))
package { $apps:
ensure => 'purged'
}
}
That might be paired with app::myapp declarations there or elsewhere of the
form
app::myapp { <wanted_packages>: }
The <wanted_packages> represents an array of the names of the packages you
want installed, which could be a variable (including a parameter) of some
class in the 'app' module (even app::packages itself), or might be a
function call (e.g. to an external data service) or maybe something else.
The unique() and concat() functions are available from PuppetLabs's popular
"stdlib" add-in module.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.