On Fri, Jul 03, 2015 at 03:42:42PM +0100, R.I.Pienaar wrote:
>
>
> ----- Original Message -----
> > From: "Christopher Wood" <christopher_w...@pobox.com>
> > To: "puppet-users" <puppet-users@googlegroups.com>
> > Sent: Friday, July 3, 2015 3:34:29 PM
> > Subject: Re: [Puppet Users] Ordering without dependencies
>
> > On Fri, Jul 03, 2015 at 02:10:55PM +0100, R.I.Pienaar wrote:
> >> hello,
> >>
> >> I am looking for a way to influence run order without also doing
> >> dependencies.
> >>
> >> I have a case where I am removing a bit of software from my system and so
> >> as is
> >> typical things need to be done in a different order from creation,
> >> crucially I
> >> also do not really care if removal fails. It should just try to remove
> >> everything
> >> independent of each other - but at least in a given order so there's some
> >> chance
> >> of it working.
> >
> > I couldn't say about doing things without dependencies, but for uninstalling
> > stuff I have wrapped everything in a giant if/then or had two different
> > classes
> > doing different things.
> >
> > class c1 ($un = false) {
> > if str2bool($un) {
> > service { 'mys': ensure => stopped, enable => false }
> > package { 'myp': ensure => absent, }
> > }
> > else {
> > package { 'myp': }
> > service { 'mys': ensure => running, enable => true, require =>
> > Package['myp'] }
> >
> > }
> > }
> >
> > Once managing the service resource fails on every host (due to a lack of
> > init
> > script from package removal) I amend the manifests. Filthy but it works.
> >
> >> There seems to be no way to influence order which does not also imply a
> >> requirement
> >> and so today the only way this is achieved is by invoking puppet 3 times
> >> with 3
> >> different manifest files which seems horrible but that's the only way I
> >> can find
> >> to achieve this as well.
> >
> > If you don't care about the service maybe just kill it?
> >
> > class c2 {
> > exec {'k': command => 'killall -9 mys || true', path => ['/bin',
> > '/usr/bin'], }
> > package { 'myp': ensure => absent, require => Exec['k'], }
> > }
> >
> > (Using true because an exec fails on a non-zero exit status iirc.)
>
> Yeah it's a bit more complex than just a service. This manifest builds an
> entire
> hyperv cluster with n dependant servers, storage volumes, dns entries and so
> forth
> and so on, even virtual machine deployment.
>
> On teardown I don't care what stays and go, just want to try my best to kill
> things
>
> So the resources in question are varied and custom and spread over multiple
> hosts.
>
> So rather than a specific solution that involves just killing this or that I
> am
> after ideas for how to do so in a generic way with any kind of resource
Just rhubarbing along, but what about:
copying all the current environment into another environment
removing all the require/before/subscribe/notify metaparams
removing all the ensure metaparams
add a stack of resource defaults saying ensure => absent
(except for Service, which has true/false running/stopped not present/absent)
(might need to preserve puppet so it's the last to die)
agent runs in the other environment
Service { ensure => false }
Package { ensure => absent }
Hypervserver { ensure => absent }
...
Another thought, grabbing all the resource titles/types from your catalogs and
generating a site.pp with ensure => absent as the only parameter for each
resource.
Being ridiculous now, a single site.pp with a resources type for each type (and
a stub puppet config!) you have:
resources { 't1': purge => true, }
resources { 't2': purge => true, }
On the other hand, since this is HyperV, maybe you can keep your removal
manifests to the lower level stuff Destroying all the low-level resources (VMs,
storage pools, virtual switches) would take out everything at higher levels too.
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/2022577340.109977.1435934562598.JavaMail.zimbra%40devco.net.
> For more options, visit https://groups.google.com/d/optout.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20150703151602.GA25552%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
