On 2015-10-02 21:17, Trevor Vaughan wrote:
To Henrik: Yes, this make sense, it would be nice to have some easy way to keep the purely Puppet DSL portions separate though.
Yeah, but that is the way it works - so way to much to change to make that happen.
I guess it would be possible to have a special implementation of a module that is a proxy for a real selected module, and that the real module is not on the real module path - only the proxy. Still quite complex to achieve. Since the concept of a module is not that well encapsulated.
Another approach is to differentiate between available modules (more like a repo) and modules being used in an environment - having a distinct step in between that configures the modulepath for the runtime. Still the same issue with where the description of which modules to use is kept - probably ends up with the same amount of configuration as when just using directory environments.
You could write something yourself that does that for you - i.e. something that creates the environments you need/want.
- henrik
Walter: This would be nice, but variables are the...uh...variable here. Many people only expose the variables that they need while others expose every variable they can find. It would be an interesting experiment to see if it would work though. Trevor On Tue, Feb 10, 2015 at 1:52 PM, Walter Heck <walterh...@olindata.com <mailto:walterh...@olindata.com>> wrote: 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 <tel:%28410%29%20541-6699> > tvau...@onyxpoint.com <mailto:tvau...@onyxpoint.com__> > > -- 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 puppet-dev+...@__googlegroups.com > <mailto:puppet-dev+__unsubscr...@googlegroups.com>. > To view this discussion on the web visit >https://groups.google.com/d/__msgid/puppet-dev/CANs%__2BFoU2unExPve9ig%__3DinW9obDpwii7gBi6W4RkHycViibJ__p-g%40mail.gmail.com <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%__3DinW9obDpwii7gBi6W4RkHycViibJ__p-g%40mail.gmail.com?utm___medium=email&utm_source=footer <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoU2unExPve9ig%3DinW9obDpwii7gBi6W4RkHycViibJp-g%40mail.gmail.com?utm_medium=email&utm_source=footer>__>. > For more options, visithttps://groups.google.com/d/__optout <https://groups.google.com/d/optout>. -- Visit my Blog "Puppet on the Edge" http://puppet-on-the-edge.__blogspot.se/ <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 puppet-dev+unsubscr...@googlegroups.com <mailto:puppet-dev+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/d171f0ce-4d7b-41fb-8722-98e0c8244e92%40googlegroups.com <https://groups.google.com/d/msgid/puppet-dev/d171f0ce-4d7b-41fb-8722-98e0c8244e92%40googlegroups.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com <mailto:tvaug...@onyxpoint.com> -- 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 puppet-dev+unsubscr...@googlegroups.com <mailto:puppet-dev+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXFyivsBttxKa23YFEe6jLMANYKbnAn5tjJany%2BbDq3hQ%40mail.gmail.com <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXFyivsBttxKa23YFEe6jLMANYKbnAn5tjJany%2BbDq3hQ%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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/mbdqb4%248mv%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
