I'm personally more of a fan of what some programming languages call
interfaces; a sort of contract if you will that a module implements.
So for instance olindata::galera could look for any class that implements
the IMysql interface. That way, I don't really need to worry if the
end-user is using puppetlabs::mysql or example42::mysql, as long as they
implement the IMysql interface I can guarantee it does what I need.
This would have pretty heavy impact on how you write code right now, but it
would be a rather elegant solution imho.
interface IMysql::server identified by
'9ff3d80b-b02d-4994-b4da-e1ff205304ea' {
Service['mysql']
Package['mysql-server']
File['apache2.conf']
}
class puppetlabs::mysql implements
IMysql['9ff3d80b-b02d-4994-b4da-e1ff205304ea'] {
[.. SNIP..]
# file, service, package here like normal
}
class example42::mysql implements
IMysql['9ff3d80b-b02d-4994-b4da-e1ff205304ea'] {
[.. SNIP..]
# file, service, package here like normal
}
class olindata::galera {
package { 'galera':
require => Package['IMysql::server::mysql-server']
}
}
Or something along those lines. Question remains where the IMysql::server
interface then needs to be declared, and how we would manage the GUID
registration of interfaces.
Comments, thoughts?
Walter
On Tuesday, February 10, 2015 at 5:52:37 PM UTC+1, henrik lindberg wrote:
>
> On 2015-10-02 1:23, Trevor Vaughan wrote:
> > I was talking with a few folks today about potential resolutions to
> > module namespace issues.
> >
> > == Fundamental Issue ==
> >
> > puppetlabs_apache -- Installs To --> apache
> > example42_apache -- Installs To --> apache
> > theforeman_apache -- Installs To --> apache
> >
> > You get my point...
> >
> > == Current Solutions ==
> >
> > Right now, there are two ways to solve this problem if you want some of
> > your nodes to use puppetlabs_apache and others to use theforeman_apache.
> >
> > 1) Modify the module and force the namespace:
> > - puppetlabs_apache -- Installs To --> puppetlabs_apache
> > - theforeman_apache -- Installs To --> theforeman_apache
> >
> > * Isssue: You can't just use outside code at will. You have to modify
> > *everything* that uses the above code.
> >
> > 2) You have to create a separate environment for each host group
> > (potentially each host) that you want to have use the differing code.
> >
> > * Issue: This is a LOT of overhead for a couple of modules and may
> > have other ramifications in terms of performance as you get up in
> number.
> >
> > So, would it be possible to allow multiple versions of a module to exist
> > in the same namespace but only use one during a given run?
> >
>
> Basically no, this is not possible without adding some kind of mechanism
> to filter out modules on the modulepath. This will need to be done per
> environment anyway. Remember that modules can contribute all sorts of
> extensions to puppet (faces, indirections, facts, functions, types, and
> with future parser also bindings). For performance reasons (and
> bootstrapping, etc.) these are scanned when the environment loads (some
> scans are lazy, but may take place before manifests really starts to be
> evaluated).
>
> - henrik
>
> > == The First Proposal ==
> >
> > Inspired by RVM Gemsets, how about allowing modules to declare which
> > version of a given module they will use?
> >
> > /etc/puppet/modules/apache/puppetlabs/{files,modules,manifests}
> > /etc/puppet/modules/apache/theforeman/{files,modules,manifests}
> > /etc/puppet/modules/apache/<author>/{files,modules,manifests}
> >
> > Then, use could be dictated by something like: include
> apache@puppetlabs.
> >
> > Unfortunately, this really comes down to the parser being able to
> > understand the following:
> >
> > include apache => See if there are any @'s and use that one
> > include apache@puppetlabs => include the Puppetlabs apache
> > include apache@puppetlabs && include apache@theforeman => Fail, conflict
> >
> > == Alternative ==
> >
> > One possible alternative is to just use the metadata.json file to
> > dictate which module will be used when loading other modules.
> >
> > Again, if there is a conflict, that is a failure but *only* if the code
> > attempts to use both at the same time.
> >
> > The benefit here is that it should make things very unambiguous while
> > the drawback (if it really is) is that you *must* put a metadata.json
> > file in every module that you create.
> >
> > This is just a set of thoughts that I hope get us moving in a direction
> > where this type of thing is possible and I look forward to hearing what
> > people think (good, bad, or ugly)!
> >
> > Thanks,
> >
> > Trevor
> >
> > --
> > Trevor Vaughan
> > Vice President, Onyx Point, Inc
> > (410) 541-6699
> > [email protected] <javascript:> <mailto:[email protected]
> <javascript:>>
> >
> > -- This account not approved for unencrypted proprietary information --
> >
> > --
> > 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] <javascript:>
> > <mailto:[email protected] <javascript:>>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoU2unExPve9ig%3DinW9obDpwii7gBi6W4RkHycViibJp-g%40mail.gmail.com
>
> > <
> https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoU2unExPve9ig%3DinW9obDpwii7gBi6W4RkHycViibJp-g%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
>
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
>
>
--
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/d171f0ce-4d7b-41fb-8722-98e0c8244e92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
