Installing multiple packages (via apt) on one command line...

[Matt W]

Hey we have a problem that I think we need to solve with a custom Puppet provider, but I could use a bit of help getting started. Overall the issue of being able to install multiple packages at-once has been discussed a ton of times (issue #2128 for example). We ultimately need to be able to pass in an arbitrary list of packages (and their versions) to a package-like provider in Puppet and have it install them all at once. For example:

  package { 'myapp':

    packages => [ 'backend=1.0', 'frontend=1.1' ],

    provider    => some_custom_provider;

  }

  Ultimately the provider would need to validate that each and every package supplied (backend, and frontend in this example) are either installed or not. If not, they are all installed on one commandline:

  aptitude install backend=1.0 frontend=1.1 -y -q -f

Should we just build a resource from scratch? or do you think we should build a provider for the Package resource in Puppet and go from there?

[Jakov Sosic]

Just write a custom exec to circumvent the issue. Something along these
lines:

exec { 'install_linked_packages':
command => "something install backend=1.0 frontend=1.1",
unless => "dpkg -l | grep -q fronted=1.1",
}

package { 'backend=1.0':
requires => Exec['install_linked_packages'],
}
package { 'fronted=1.1':
requires => Exec['install_linked_packages'],
}

[Christopher Wood]

Do you have a link for this #2128? All I can find are these:

http://projects.puppetlabs.com/issues/2128
https://tickets.puppetlabs.com/browse/PUP-2128

I'm nosy about the why. If you need to map the package to the provider this seems like the perfect opportunity for create_resources(), but there's something else going on here.

> --
> 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 [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/5b98ce35-a9ff-4e76-89e7-a4d4475cedd3%40googlegroups.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/5b98ce35-a9ff-4e76-89e7-a4d4475cedd3%40googlegroups.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

[Felix Frank]

On 04/21/2014 11:25 PM, Matt W wrote:

> Ultimately the provider would need to validate that each and every
> package supplied (backend, and frontend in this example) are either
> installed or not. If not, they are all installed on one commandline:
>
> aptitude install backend=1.0 frontend=1.1 -y -q -f
>
> Should we just build a resource from scratch? or do you think we should
> build a provider for the Package resource in Puppet and go from there?

The idea is sound-ish. You cannot implement this as a provider for the
resource type. There are too many assumptions rooted in the package type
to liberate its notion of being in sync the way you need.

So if you could come up with the apt_multi_package module (or whatever),
that would likely be useful. Keep us posted :)

(Bonus points if it ends up as just the multi_package module with
providers for both aptitude and yum ;-)

Cheers,
Felix

[Matt Wise]

The Exec method is tricky if you don't know what the incoming package list is ahead of time. In our case -- we don't. We're giving our developers a method to specify a list of packages (in order) that will be installed and set to an explicit version.

It turns out though that one of the guys on our team built a recursion-loop in puppet that handles this fairly gracefully with standard package resources. We have it working and have unit tests for it ... but we're going to spend a week or two with it before we post it publicly on our Engineering blog (engblog.nextdoor.com).

Matt Wise

Sr. Systems Architect

Nextdoor.com

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/DdIHu0US0tY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5357BA82.6070202%40alumni.tu-berlin.de.

For more options, visit https://groups.google.com/d/optout.