[discuss] what needs to be done for a 1.0.0 release

[igalic]

i'd like to do a big cleanup before we comit to a 1.0 release

• there's loads of repetition with regard to params classes that has to be simplified.
• i am convinced that these params classes are to be blamed for bugs like #121, #132, etc…
• currently this module only works on debuntu, is anyone interested in making it work on other platforms?
• testing: sigh if you know me from irc, or twitter, you know i'm a big fan of testing, and no fan of rspec :( see also https://github.com/bartavelle/language-puppet/issues/99
• anything else?

[igalic]

YES!

extensions. there are two methods to install extensions, we should abstract those and provide people with a simple method to just call a defined type which handles that for them. this could (should?) be analogous to package (with a provider setting)

[jippi]

+1 to all of it

The module work both on ubuntu and debian though - I use it for debian

For sure the module need some cleanup love - it was my first ever module plugin, 4 years ago :)

I've only ever used it with hiera, so the param classes haven't been much of an issue for me, I'm sure more modern puppet can do things like that infinitely smarter.

Adding support for latest puppet versions would also be neat, think it currently only work for ancient versions :)

[igalic]

i'm using it with 3.7.4, so that works, but we're not using any of the features (contain comes to my mind), so we could as well be using 2.7 :P

[jippi]

Well, it just so happen to use 3.3.2-1puppetlabs1 :D would like to keep support for that version ;)

[schkovich]

I'm on 3.7.4 and ruby 2.1.5. Module is working fine.

I tend to use hiera instead of parameters classes as well. I also find that R. I. Pienaar has a strong argument on why using hiera and having data in modules is better than current practice of defining everything in params classes. Although R. I. Pienaar original ticket is still open Puppet 4 will support data in modules.

Refactoring current params classes might be a futile attempt. I would rather see version 1.0.0 released as quickly as possible and start working on version 2.0.0 that will be based on Puppet 4.x. :)

@igalic could not agree more on testing. rspec is a bitch. ;)

[igalic]

in that case we should merge as much as possible/sensible from the current set of pulls, and publish 1.0.0

[dbeckham]

One thing that is missing from this module is support for the Ubuntu Trusty style for linking PHP pecl modules and extensions into the different installed SAPIs. (Currently apache2 and cli.)

The xhprof extension is a good example of this. The pecl provider is used and as such, does not create the /etc/php5/mods-available/xhprof.ini file. The php::extension::xhprof itself does create this missing file, but it's never linked to either /etc/php5/apache2/conf.d/xhprof.ini, or /etc/php5/cli/conf.d/xhprof.ini, and is never loaded by PHP.

The same thing applies if you use the the php::config helper class to create a custom config like /etc/php5/mods-availble/global.ini. You must manually symlink it into the correct sapi directory for PHP to use it.

This is certainly able to be worked around with your own file resource to create the symlinks, but it's sort of hole in the module as far as managing extensions go. You have to hard code the paths as well as check for Ubuntu releases outside of the module that should already know how to handle that.

This is a change in behavior between precise and trusty.

[schkovich]

@dbeckham :+1:

I bumped into the same problem a few days ago. Actually all debian-flavoured unixes have adopted this standard for their PHP 5.4 packages.

Most likely we would have to add needed logic to extension.pp.

There is no open issue regarding this problem. It would be great if you could open an issue @dbeckham. I might be able to address the issue quickly.

[khaefeli]

Great module! we're using it for our hosting environment (snowflakehosting.ch) with puppet 3.7.2-3

anyway. some hints for the module 1.0 release:

• the documentation is nice, but sometimes a little bit unclear / incomplete (e.g. augeas / module installation part)
• proper handling for deleting php-fpm pools etc. at the moment we've to:

    file { '/etc/php5/fpm/pool.d':
        ensure  => directory,
        owner   => 'root',
        group   => 'root',
        mode    => '0700',
        recurse => true,
        purge   => true,
        force   => true,
        require => Class['::php::fpm'],
        notify  => Service['php5-fpm'],
    }

[igalic]

hah… i do this in my profile, just so i can get rid of the default www pool, so i didn't even notice that we don't have a working ensure => absent

[jippi]

ditto lol :D

[dbeckham]

@schkovich I failed to make a ticket for the Ubuntu/Debian PHP 5.4+ issue where extensions are not properly linked into the SAPI conf.d directories, but @roll4life did in #142. This issue specifically addresses this as well as using php5enmod to handle the symlink. Do you still need me to open one, or is that one enough?

[dbeckham]

@schkovich it just occurred to me that the puppetlabs-apache module has a custom provider for the Debian a2mod utility and it could be used as a model for the php5enmod and php5dismod utilities.

[schkovich]

@dbeckham having custom provider to handle enabling/disabling PHP extensions would be a great improvement. @jippi & @igalic should we care about PHP < 5.4? PHP 5.3 is still widely used.

Since #142 is opened no need to make duplicates @dbeckham . ;)

[khaefeli]

PHP 5.3 is EOL and e.g. used with debian squeeze which is also EOL soon. don't care about it and force the sysadmins to upgrade :-)

[schkovich]

LOL! SysAdmins reached EOL as well. ;) DevOps engineers are emerging.

I agree with you @khaefeli . Just nuke everyone still running PHP 5.3. ;)

However, in reality: Precise is LTS and will not reach EOL till 2017. It ships with PHP 5.3.

[igalic]

from my experience with @puppetlabs apache, it's not impossible to maintain multiple versions in one module.

[dbeckham]

@schkovich and @khaefeli : It definitely isn't impossible to support both and there are more people using PHP 5.3 than you think. Matter of fact, we are, but are transitioning to > PHP 5.4 this quarter. If this module suddenly stopped working with PHP 5.3, it would be extremely difficult to continue to use this module while moving to > PHP 5.4. Removing PHP 5.3 support would actually stop people from trying to do the very thing you want them to do the most, to move away from EOL PHP 5.3.