On Thursday, June 19, 2014 8:01:40 PM UTC-5, Joachim Thuau wrote:
>
> (Felix - my apologies, i'm just going to start a new thread :)
>
> As requested, a new thread to discuss the possibility of having a module
> masquerading feature.
>
> Have a look at PUP-2811 -- I'm going to try to keep that updated with the
> output of this discussion.
>
> What I am after is something akin to the debian package "provides"
> property. When a Debian system needs an MTA, most packages shouldn't care
> what MTA is installed, just that "MTA" as a feature is installed. I can
> install any of exim, postfix, sendmail, qmail. The package name is still
> "exim" or "postfix" or whatever, but they all provide a "mta" package
> (which doesn't really exists, it's just so that it can be used as a
> dependency). So when logwatch needs to make sure a MTA is installed to send
> mails about the logs, it doesn't care which one, as long as *something*
> provides a mail feature.
>
> In the context of puppet modules, we could have competing modules offering
> similar features, and a module that needs that feature, but doesn't care
> which one is being used, as long as one *is*.
>
> The example I have is around this:
> Sssd and nslcd are both systems to get user information out of ldap/active
> directory. They can't be installed together, and some other modules needs
> to make sure some sort of auth has been setup prior doing the changes...
>
> One module for sssd:
> class sssd as auth {
> # setup sssd
> }
>
> One module for nslcd:
> class nslcd as auth {
> # setup nslcd
> }
>
> And one module that needs one of them:
> class ssh_authz {
> require auth
> # setup some ssh authz that require one of the auth module to be applied
> }
>
> Then we have some nodes:
>
> node nodeSSSD {
> # do the right thing here... even if this is coming from ENC in whatever
> order
> include sssd
> include ssh_authz
> }
>
> node nodeNSLCD {
> # still should be able to apply in the right sequence based on the
> require in ssh_authz
> include ssh_authz
> include nslcd
> }
>
> node broken-missing {
> # fails because nothing provides "auth" that's required...
> include ssh_authz
> }
>
> node broken-dups {
> # duplicate resources, as both sssd and nslcd show up as "auth"
> include sssd
> include ssh_authz
> include nslcd
> }
>
> I hope this could be useful especially around modules that potentially
> provide similar features. If i provide a module for installing a piece of
> software that requires a DB, we could simply say that we need some DB
> module (and maybe some default, if none exists for the "puppet module
> install". Maybe I have a "mysql" module that's pretty simple, and maybe
> there is another one with much more control, and just need one of them for
> that purpose...
>
> hoping for a lively discussion around this...
> Thanks,
> Jok
>
I think there is potential for a feature such as this, but for the sake of
argument, what are the advantages of doing it that way, as opposed to via
classes? For instance:
class ssh_authz {
require 'auth'
}
class auth ($implementation = 'sssd') {
require $implementation
}
Or if a wrapper class is not a sufficient aliasing mechanism then is it
really best to put the facility alias in the class *definition*? For that
to be reusable pretty much requires wide consensus on the facility aliases
and their meaning. Wouldn't it be better to associate classes with aliases
at the point of *declaration*? For example:
node nodeNSLCD {
include 'ssh_authz'
include 'nslcd' as 'auth'
}
(I suspect that particular syntax might be difficult for the parser to
digest, but it conveys the idea.)
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/89399842-dd37-4fbd-9827-7f1e47b766b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
