Puppet 3.4.0 name as an array in package

[Fabrice Bacchella]

Puppet 3.4 is out and broke an very usefull undocument feature.

Previsiously, one can write :

package {'bla':
ensure => present,
name => ['pkg1', 'pkg2']
}

and it will install pkg1 and pkg2.

It now says :
Parameter name failed on Package['blab']: Name must be a String not Array at /etc/puppet/modules/...


I know this was undocument, considered as a bad practice. But I used it intensively because it provides a quick solution to 3 problems :
- a small performance gain, it reduce the number of call to your package manage (at least in redhat) because it executes 'yum ... pkg1 pkg2' once
- easier to read dependency, 'bla' was a symbolic name for a dependency set, and I could easily wrote :
require => Package['bla']
what ever the real packages list it was.
- a easer solution to multiple dependencies for the same package, as I could write :
in openssh module :
package {'openssh':
name => ['openssl', ...]
}

package {'https':
name => ['openssl', ...]
}
without any complication to solve it. Yum would just be called twice for the same package.

quick clean, very readable. I loved this feature^Wbug.

I don't really hope to get this back, but can some on help on clean and quick alternative solution for the same feature set ?

[Charlie Sharpsteen]

Hi Fabrice,

This came up during the development of 3.4.0 and sparked quite a bit of discussion that can be found in this Redmine ticket:

https://projects.puppetlabs.com/issues/22557

Eventually, it was decided not to restore the ability to pass an array of packages to the name parameter because:

• It was an “accidental” feature that was never intended to work.
• It only works when the entire array of packages is in the same state. If one package is out of sync with the rest, unexpected results will occur.
• We could not find any forge modules that exploited this behavior.

The recommended workaround is to pass an array of resource titles:

package {['pkg1', 'pkg2']:
  ensure => present, 
}

This won’t achieve the exact same effect, i.e. there will be multiple calls to yum, but it is pretty close for most use cases.

Hope this helps!

-- 

Charlie Sharpsteen

Open Source Support Engineer

Puppet Labs

[Fabrice Bacchella]

Le 20 déc. 2013 à 19:55, Charlie Sharpsteen <ch...@puppetlabs.com> a écrit :

On Friday, December 20, 2013 10:30:14 AM UTC-8, Fabrice Bacchella wrote:

Puppet 3.4 is out and broke an very usefull undocument feature.

Previsiously, one can write :

    package {'bla':
        ensure => present,
        name => ['pkg1', 'pkg2']
    }

and it will install pkg1 and pkg2.

It now says :
 Parameter name failed on Package['blab']: Name must be a String not Array at /etc/puppet/modules/...


I know this was undocument, considered as a bad practice. But I used it intensively because it provides a quick solution to 3 problems :
- a small performance gain, it reduce the number of call to your package manage (at least in redhat) because it executes 'yum ... pkg1 pkg2' once
- easier to read dependency, 'bla' was a symbolic name for a dependency set, and I could easily wrote :
 require => Package['bla']
 what ever the real packages list it was.
- a easer solution to multiple dependencies for the same package, as I could write :
in openssh module :
package {'openssh':
        name => ['openssl', ...]
}

package {'https':
        name => ['openssl', ...]
}
without any complication to solve it. Yum would just be called twice for the same package.

quick clean, very readable. I loved this feature^Wbug.

I don't really hope to get this back, but can some on help on clean and quick alternative solution for the same feature set ? 

The recommended workaround is to pass an array of resource titles:

package {['pkg1', 'pkg2']:
  ensure => present, 
}

This won’t achieve the exact same effect, i.e. there will be multiple calls to yum, but it is pretty close for most use cases.

That's an understatement. I already knew this syntaxic sugar but it's nothing more that an short hand for

package {'pkg1':

...

}

package {'pkg2':

...

}

So it provides none of the describe features I will miss badly

Hope this helps!

Not really but thanks for the time.