Re: [Puppet-dev] Thoughts on Module Namespace Conflicts
On 11/02/15 18:13, Trevor Vaughan wrote: Heh, that's probably because it's the third hit in the list when you search for Apache on the Forge. Is there a way for people to mark Forge modules as unmaintained? Not as far as I know. I ought to upload a new release with a big warning in the README. All I've done for the meantime is add a deprecated tag, which isn't a big help. There's a similar issue I have with augeasproviders. Again I've yet to update the README in domcleal/augeasproviders to indicate that herculesteam/augeasproviders is the maintained version, but it would be great to be able to mark this as such in the Forge, or even redirect to another module. -- Dominic Cleal Red Hat Engineering -- 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/54DC72AD.9000103%40redhat.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] new to puppet
Hi, can any one help me to work in puppet work.. i am started working in puppetdb, i need to connect to puppetdb and access some fields. i have downloaded the puppet source code from the github, they mentioned some .pem files need to run the junit. can any one tell me where to get these .pem files ? Regards, Rajashekhar -- 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/e43baaac-84ac-4455-b98d-b9db929bd77f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] new to puppet
can any one help me to work in puppet work.. i am started working in puppetdb, i need to connect to puppetdb and access some fields. i have downloaded the puppet source code from the github, they mentioned some .pem files need to run the junit. I'm not sure where we mention junit :-). We use clojure test which is a lot like junit testing however. But junit is for development testing, I'm not sure why this is needed if all you are trying to do is install PuppetDB in your environment. These pem files are normally sourced from the Puppet agent installation on the existing system you are trying to install PuppetDB on, and if an agent run has already happened on that server, installation of the PuppetDB packages will automatically grab those for use with PuppetDB. There is a tool called puppetdb-ssl-setup that normally assists with this that is run as part of the post-install steps. can any one tell me where to get these .pem files ? So first and foremost, why are you downloading the source code for PuppetDB? If your goal is to just have this installed in a production scenario, you shouldn't use the source based version of PuppetDB if you can avoid it. Its far easier to follow the package or module based installation instructions, I would step back and use those instead of the source based installation instructions: https://docs.puppetlabs.com/puppetdb/2.2/install_via_module.html https://docs.puppetlabs.com/puppetdb/2.2/install_from_packages.html Also - puppet-dev is really for development related questions, if your questions are only related to the installation of PuppetDB - the forum puppet-users is far better for this: https://groups.google.com/forum/#!forum/puppet-users ken. -- 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/CAE4bNTkermK0ZfBiwODHyT%3DosrO3oS8ar3EF6VoBNXOSE5GoNQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Thoughts on Module Namespace Conflicts
- Original Message - From: Dominic Cleal dclea...@redhat.com To: puppet-dev puppet-dev@googlegroups.com Sent: Thursday, February 12, 2015 10:30:21 AM Subject: Re: [Puppet-dev] Thoughts on Module Namespace Conflicts On 11/02/15 18:13, Trevor Vaughan wrote: Heh, that's probably because it's the third hit in the list when you search for Apache on the Forge. Is there a way for people to mark Forge modules as unmaintained? Not as far as I know. I ought to upload a new release with a big warning in the README. All I've done for the meantime is add a deprecated tag, which isn't a big help. There's a similar issue I have with augeasproviders. Again I've yet to update the README in domcleal/augeasproviders to indicate that herculesteam/augeasproviders is the maintained version, but it would be great to be able to mark this as such in the Forge, or even redirect to another module. redirects would be nice, I have the same problem with ripienaar/concat and puppetlabs/concat -- 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/100231099.15755.1423733538852.JavaMail.zimbra%40devco.net. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Thoughts on Module Namespace Conflicts
And this is why he gets awards... +1 On Thu, Feb 12, 2015 at 9:12 AM, Erik Dalén erik.gustav.da...@gmail.com wrote: A related ticket to the interface and redirect functionality is https://tickets.puppetlabs.com/browse/FORGE-111 There I just suggest the feature to be able to say that module B provides the interface of module A version X. So either module can satisfy a dependency on module A version X. Then if you want to have some sort of generic interface that other modules can implement, you could have a sort of virtual module with he version being the interface version. And then other modules provide or depend on that virtual module. The meaning of virtual module here is the same as for virtual packages in package managers, like ruby-interpreter or smtp-server in Debian, and the implementation would also be pretty similar. Regarding having multiple variants or versions of a module being installed at the same time I think we should change the environment loader API to provide a list of modules instead of a list of module paths. Then plugins could implement any sort of behaviour for this without jumping through hoops. Basically I think that would mean deprecating this: https://github.com/puppetlabs/puppet/blob/master/lib/puppet/node/environment.rb#L144-L150 And changing this method to return list of paths to individual modules instead of names of modules: https://github.com/puppetlabs/puppet/blob/master/lib/puppet/node/environment.rb#L233-L241 On Thu Feb 12 2015 at 10:32:24 AM R.I.Pienaar r...@devco.net wrote: - Original Message - From: Dominic Cleal dclea...@redhat.com To: puppet-dev puppet-dev@googlegroups.com Sent: Thursday, February 12, 2015 10:30:21 AM Subject: Re: [Puppet-dev] Thoughts on Module Namespace Conflicts On 11/02/15 18:13, Trevor Vaughan wrote: Heh, that's probably because it's the third hit in the list when you search for Apache on the Forge. Is there a way for people to mark Forge modules as unmaintained? Not as far as I know. I ought to upload a new release with a big warning in the README. All I've done for the meantime is add a deprecated tag, which isn't a big help. There's a similar issue I have with augeasproviders. Again I've yet to update the README in domcleal/augeasproviders to indicate that herculesteam/augeasproviders is the maintained version, but it would be great to be able to mark this as such in the Forge, or even redirect to another module. redirects would be nice, I have the same problem with ripienaar/concat and puppetlabs/concat -- 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/100231099.15755.1423733538852.JavaMail. zimbra%40devco.net. For more options, visit https://groups.google.com/d/optout. -- 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/CAAAzDLe5OC2Y44_P2ovuCFnZ2iw3uZEN-Sgic_pjcamYyNVHrQ%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CAAAzDLe5OC2Y44_P2ovuCFnZ2iw3uZEN-Sgic_pjcamYyNVHrQ%40mail.gmail.com?utm_medium=emailutm_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 -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWc9PW%3DBsvN09cgkXo5pY8Q-s8S1a_XKS5ZoYxBnLjuug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Thoughts on Module Namespace Conflicts
A related ticket to the interface and redirect functionality is https://tickets.puppetlabs.com/browse/FORGE-111 There I just suggest the feature to be able to say that module B provides the interface of module A version X. So either module can satisfy a dependency on module A version X. Then if you want to have some sort of generic interface that other modules can implement, you could have a sort of virtual module with he version being the interface version. And then other modules provide or depend on that virtual module. The meaning of virtual module here is the same as for virtual packages in package managers, like ruby-interpreter or smtp-server in Debian, and the implementation would also be pretty similar. Regarding having multiple variants or versions of a module being installed at the same time I think we should change the environment loader API to provide a list of modules instead of a list of module paths. Then plugins could implement any sort of behaviour for this without jumping through hoops. Basically I think that would mean deprecating this: https://github.com/puppetlabs/puppet/blob/master/lib/puppet/node/environment.rb#L144-L150 And changing this method to return list of paths to individual modules instead of names of modules: https://github.com/puppetlabs/puppet/blob/master/lib/puppet/node/environment.rb#L233-L241 On Thu Feb 12 2015 at 10:32:24 AM R.I.Pienaar r...@devco.net wrote: - Original Message - From: Dominic Cleal dclea...@redhat.com To: puppet-dev puppet-dev@googlegroups.com Sent: Thursday, February 12, 2015 10:30:21 AM Subject: Re: [Puppet-dev] Thoughts on Module Namespace Conflicts On 11/02/15 18:13, Trevor Vaughan wrote: Heh, that's probably because it's the third hit in the list when you search for Apache on the Forge. Is there a way for people to mark Forge modules as unmaintained? Not as far as I know. I ought to upload a new release with a big warning in the README. All I've done for the meantime is add a deprecated tag, which isn't a big help. There's a similar issue I have with augeasproviders. Again I've yet to update the README in domcleal/augeasproviders to indicate that herculesteam/augeasproviders is the maintained version, but it would be great to be able to mark this as such in the Forge, or even redirect to another module. redirects would be nice, I have the same problem with ripienaar/concat and puppetlabs/concat -- 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/100231099.15755.1423733538852.JavaMail.zimbra%40devco.net . For more options, visit https://groups.google.com/d/optout. -- 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/CAAAzDLe5OC2Y44_P2ovuCFnZ2iw3uZEN-Sgic_pjcamYyNVHrQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Re: Thoughts on Module Namespace Conflicts
On 2015-12-02 15:12, Erik Dalén wrote: A related ticket to the interface and redirect functionality is https://tickets.puppetlabs.com/browse/FORGE-111 There I just suggest the feature to be able to say that module B provides the interface of module A version X. So either module can satisfy a dependency on module A version X. Then if you want to have some sort of generic interface that other modules can implement, you could have a sort of virtual module with he version being the interface version. And then other modules provide or depend on that virtual module. The meaning of virtual module here is the same as for virtual packages in package managers, like ruby-interpreter or smtp-server in Debian, and the implementation would also be pretty similar. Regarding having multiple variants or versions of a module being installed at the same time I think we should change the environment loader API to provide a list of modules instead of a list of module paths. Then plugins could implement any sort of behaviour for this without jumping through hoops. I have claimed on many occasions that an environment is just like a module (with higher privileges / precedence). The set of available modules should be more of a repository kind of thing that the loader resolves modules from. Essentially this is how the new loaders work (used only for 4x functions so far). - henrik -- 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/mbii8r%24mae%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
