Re: [Puppet-dev] Puppet Dev Status -- week ending Feb 21
On Mon, Feb 23, 2015 at 2:17 PM, Jeff McCune j...@puppetlabs.com wrote: On Sun, Feb 22, 2015 at 12:08 PM, Trevor Vaughan tvaug...@onyxpoint.com wrote: Yes please. Moving this out of $vardir/ssl will be quite irritating to teach existing users about the new product usage. Even if we kept it in $vardir/ssl, this would mean the path is /opt/puppetlabs/puppet/cache/ssl rather than /var/lib/puppet/ssl (Please note the agent and master vardir's in the specification). Is your concern that SSL data remain in $vardir/ssl or that they remain in /var/lib/puppet/ssl ? It does not seem like a great idea to put $vardir under /opt. /opt is only sometimes a separate file system from / and could grow much more variably. If anything, I'd rather see the some of the directories under $vardir to be moved to /var/cache/puppet, depending on whether the data is transitory or persistent. (Much of it, in fact, I would expect to be cache, but 'reports', 'bucket' and possibly 'clientbucket' stand out as non-transitory so kept in 'lib'; if ssl were not in /etc I would expect it to be in 'lib' as it is not transitory.) I agree with the hating on '/etc/opt' and '/var/opt' too. Also, if hiera, c?facter and mco are going to be installed in /opt/puppetlabs/puppet, why bother with the extra directory level and then have to bother symlinking into /opt/puppetlabs/bin? I'm guessing that there is an expectation that other projects/products will go alongside the 'puppet' level, but then it seems weird to put hiera c?facter and mco into 'puppet' instead of their own directories. I guess you're putting ruby into the 'puppet' directory, so that's why... Hrm Blue. I say it should be blue! Wil -- 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/CAMmm3r43PjKyGNbvPFYRRw5aM8XtDz%2BuQFMB6GTDdCf%2BZj%3DPcg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Thoughts on Module Namespace Conflicts
On Mon, Feb 9, 2015 at 4:23 PM, Trevor Vaughan tvaug...@onyxpoint.com
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...
...
== 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)!
== Alternative #2: Namespaced Module-Sets ==
Let's call it Namespaced Module-Sets; it's similar to the first proposal
but kinda turned on its end. The concept of the module path is extended
with optional names for any element in the module path. These names can
then be used as a namespace prefix to address classes within a particular
module-set. From within the module-set, references to classes do not need
to be qualified (or perhaps, within a named set must not be) and these
references are local-first, meaning that the set is searched before the
module path is searched.
With this scheme, 3rd party module authors do not need to change the
dependencies of their modules nor the names by which they refer to these
dependencies. Local devadmins have the ability to use multiple modules that
present internally the same top-level namespace and to mix in modules that
are dependent on specific versions of those.
Example: I'll use YAML to represent the namespaced module path, but I'm not
necessarily presenting this as the way it would actually be configured.
---
modulepath:
# Our local modules, without an attached name
- path: /etc/puppet/modules/local
# PuppetLabs modules and modules that depend on them
- path: /etc/puppet/modules/puppetlabs
name: puppetlabs
One could have a node defined to use our local apache module and another
node defined to use puppetlabs::apache, which is installed in
/etc/puppet/modules/puppetlabs. Now one could also use puppetlabs/passenger
by installing it to /etc/puppet/modules/puppetlabs. Because scope
references are local-first, passenger/manifests/init.pp's include
'::apache' refers to ::puppetlabs::apache.
The biggest problem I see with this scheme is with Ruby components that are
not Puppet-namespaced. Within a module-set there would be no problem, as
the local-first would still apply, but if, e.g., functions with the same
name were in different module-sets, then the language would need to be
extended to support namespaces in these.
And there are a number of other details that would need to be worked out,
including but not limited to:
* Hiera lookups; I have a feeling that there is some complexity here that
is escaping me
* Would it fall back to looking in named module-sets for unqualified
names? If there were an unnamed module-set after a named module-set, which
would be searched first?
* My feeling is that the use of named module-sets and the names chosen
for them should be a local-only decision. That is, distributed modules
should never assume anything about the existence of module-set names,
either by convention or technical restriction. (So, for example, one would
only expect to use them within a role or profile or node definition.) There
are probably gray areas with this that I am not seeing.
* A variation would be to not allow unnamed module-sets at the local
level, but this would be a breaking change, whereas the above should be
backwards compatible.
* Additional complexity for r10k/pmt/etc. probably?
In some ways, this is a lot like environments, but unlike environments,
which are unique at the node-level, these allow the use of multiple
module-sets and are scoping for entities at the manifest-level. As I
understand environments, they can (and probably usually should) be
relatively isolated
Re: [Puppet-dev] rspec and hiera lookup within puppet functions
On Fri, Jan 30, 2015 at 4:23 AM, Remi Ferrand
remi.mathieu.ferr...@gmail.com wrote:
I want to use hiera as described in
https://github.com/rodjek/rspec-puppet/tree/v2.0.0#hiera-integration.
This mean:
- I want to provide a hierarchy
- I want hiera to use my custom configuration file as described in
https://github.com/rodjek/rspec-puppet/tree/v2.0.0#enabling-hiera-lookups
I've already been using the method above for testing puppet code that
involves hiera lookups, and it worked as expected.
What I don't want is to stub or mock hiera function.
I just want that the hiera() lookup actually uses my custom hierarchy
specified in my configuration file (
https://github.com/riton/rspec-hiera-test-function/blob/master/spec/fixtures/hiera/hiera.yaml
)
As described in my sample repository README (
https://github.com/riton/rspec-hiera-test-function/blob/master/README.md),
right now I wasn't able to make it work.
There are a couple of problems with your test because you're doing what
should ordinarily work, rather than slavishly following the docs,
forgetting about the layers and layers of magic that is rspec and
rspec-puppet:
1. You're using the lower-level function interface directly into Puppet
rather than the rspec-puppet function-testing interface, so rspec-puppet
magic does not get called, so the setup that rspec-pupppet does for your
`c.hiera_config = ...` never happens. Instead, try:
context 'Using rspec-puppet wrapper' do
it 'should work' do
expect(subject).to run.with_params().and_return('plop')
end
end
2. Once you've worked that out, you find that you get an *undefined method*
error:
Failure/Error: expect(subject).to run.with_params().and_return('plop')
NoMethodError:
undefined method `call' for nil:NilClass
The name of the thing under test w/rspec-puppet *must* be the the top-level
`describe` argument:
describe 'test_hiera', :focus = true do
This is how rspec-puppet knows what function to make available.
Note that you can still use the `scope.function_test_hiera([])` stuff, as
long as you put it after the rspec-puppet-style function call. (If you were
still using rspec-puppet 1.0.1, you might want to duplicate the test with
this style, because rspec-puppet had a bug in the error handler that made
it impossible determine how your method call errored!)
For me, one of the most frustrating aspects of rspec and rspec-puppet is
the amount of magic that goes into making the whole thing seem like a DSL
rather than an API. For example, try changing 'plop' in the test to see it
fail and then run rspec with the --backtrace option -- you'll find no
mention of rspec-puppet at all! And don't bother trying to use ruby -rtracer
either -- I just ran it with your simple test and got a 170MiB file --
750,000 lines long.
Sorry for the rant.
Wil
--
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/CAMmm3r41iGBtiYKUfJ-N2OmjLzqP01PC-wr-45AaitBQMF04xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] rspec-puppet issues under Ruby 2
On Tue, Dec 2, 2014 at 12:15 PM, Jeff McCune j...@puppetlabs.com wrote: I plan to release rspec-puppet 1.1.0 today as per the discussion at https://github.com/rodjek/rspec-puppet/issues/213 Scratch that, looks like Tim is the only person who can push new releases to rubygems.org. I've tagged the release and got everything ready in the master branch but I can't proceed with publication. Kudos to you for taking this up Jeff! I will be especially happy to not have to rewrite function tests when they fail so I can actually see the cause of the failure (PR#142). Wil -- 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/CAMmm3r79WoK%2B_3r_iZBrMSxyZEuFZRvY%3D0VedkGMhn6LFvj4nw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Use of private in module skeleton
On Nov 22, 2014 4:22 AM, Gareth Rushgrove gar...@morethanseven.net wrote: I'd love some feedback on this PR, which adds the private function to the puppet-module-skeleton that a bunch of people use. https://github.com/garethr/puppet-module-skeleton/pull/43 ... And I'm on the fence too. Any thoughts? As a general principle, I'm not crazy about not being able to use the x::install or x::service classes independent of the main class or whatever the expected interface is. x::config or auxiliary subclasses I could see. Being able to use the subclasses is an important feature for migrating to using the module, either from an unmanaged system, a different module or even a different configuration management tool. For example, my work environment is a legacy Cfengine shop and we still have quite a number of EL5 systems co-managed with Cfengine[1]. As I add the ability to manage some service in Puppet, I can easily do so for new, pure-Puppet systems. But for systems managed originally w/Cfengine, I might not want to redo the configuration in the way that it's done with the Puppet module, but I can at least switch the service and package portions to using Puppet. Maybe this is just another facet of my belief in don't be a proprietorial asshole with data and my preference for OO languages that have no private concept, only naming conventions. [1]. I have a script that reads /var/lib/puppet/classes.txt and makes Cfengine classes by prepending puppet_ and transforming :: to underscores. Then I litter the legacy Cfengine with !puppet_x_service or whatever. -- 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/CAMmm3r4caRLmP%2B73ksNmsXdg04x30ZLsXECsw4fzXLuoXULbrQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] How to run tests on custom report parser
On Nov 4, 2014 6:32 AM, tracyde trac...@gmail.com wrote: I am new to ruby development and want to integrate my report parser with TravisCI. I have read articles and blog posts on how to integrate Puppet modules with rspec, puppet-lint, and travisci but those are not directly applicable to modules that do nothing but provide lib instances (facts, report parsers, etc.) Alas, I have had my eye out for documentation or utilities for testing report processors for a while and have seen nothing. For that matter, even figuring out what the incoming data looked like room a bit of digging -- I just read the YAML dump of a 'store' report and assumed I knew what values meant. My guess is that testing would involve one or more store report YAML files and just enough framework to deserialize that and pass the resulting data to your report processor. Then you'd need to stub the objects methods your processor calls for output. I'm not sure you'd actually need rspec-puppet -- I don't think it provides any facilities that would be useful in this case. Wil Wil -- 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/CAMmm3r5tbTuu6b3WUhGTasXsoCai3NiAaR%3D97%3DpPEKJcA%2BPgnA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Switching from YAML and PSON to JSON
On Fri, Oct 24, 2014 at 10:25 AM, Andy Parker a...@puppetlabs.com wrote: Pretty printing introduces a significant overhead. On a test catalog that we have (the one produced by our many_modules benchmark) it increases the space needed by 52% (JSON.pretty_generate(p).size == 141065 and JSON.generate(p).size == 92596) and increases the time to serialize by 24%. Yow! That sounds like a lot! For the master storing stuff for all of the agents, it certainly could a non-negligible amount of overhead. But for the agent, which is going to write 3 state files and its catalog at the end of each run, it seems insignificant. On the other hand, I'm more likely to try to run grep on the master, which does not work well with minimized JSON (I'm clever enough that I can do it, but I would curse under my breath at having to do so). (Yes, I could probably query PuppetDB for these cases, but...) I guess it doesn't matter much; the matter is on my mind because was galling with Cobbler, which stores host data in JSON and nicely commits changes made through the web UI into a local Git repo, but that's mostly useless for diff'ing/blame'ing without pretty-printed data. (Until I found the option to store pretty-printed data.) Wil -- 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/CAMmm3r4oKSq5WZfYJrWtUUQOVG7AF%3D9fSJFZYddnSfHN_YzE8Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Announce: nightly repos available
On Fri, Aug 29, 2014 at 9:17 AM, Dominic Cleal dclea...@redhat.com wrote: Another useful addition would be the Puppet gem, as Facter's is already there. I've got another battery of tests that could be run against it. I was just going to request that too; it would make testing within an RVM gemset on a non-disposable machine possible. Wil -- 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/CAMmm3r6wu1GM1wDcA8AzjQvoROQ4d8UGFk%3DzWbBtSM9iP1Ge%3DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Facter version guarantees
On Fri, Aug 29, 2014 at 2:11 PM, Kylo Ginsberg k...@puppetlabs.com wrote: There are a couple really good issues here, and I'm torn on the answers: 1) While semver clearly applies to the Facter *API*, I'm not sure if it provides guidance on Facter *values*. Yes, on the one hand, I could argue that the values are part of the Facter contract, but that seems like a contortion of API. I incline toward treating semver as API-only. From the perspective of direct clients of Facter's Ruby API, such as Puppet itself, the values might not be part of the API. (But then again they might -- what if the change broke a provider constraint?) From the perspective of someone writing manifests, Facter values are part of the API of the Puppet DSL. From this perspective, Facter's Ruby API is meaningless -- only the existence of facts and values are meaningful. Someone writing a module expects to be able to count on both the existence and the values of core facts. 2) More importantly, a strict reading of semver as applied to facts would tie our hands (or force more rapid majors). E.g. I add fact 'foo' in 3.0, and it turns out to work great on RHEL but is incoherent on, say, Windows. But it's now out in the wild, so if I'm completely strict about changes we have to leave it be until 4.0, although that may mean that more and more Windows users painfully write manifests around the 3.0 behavior. It would depend on how badly broken it is on a particular platform -- If it's so broken as to be unusable, then changing it for that platform should not be a problem. But if it's usable with work arounds or more effort than really needed, then you're probably suck with that behavior. I realize there's plenty of room for interpretation there. Of course, a strict reading of SemVer reveals that it only applies to APIs -- Not environments, user interfaces, platforms, etc. And that it is not clear about how it applies to dependencies. So, if, for example, you were the *user* of a piece of software and if one of the libraries that software depended on increased a minimum version of one of *its* dependencies, such that the whole thing ceased to work on, say, the version of a language interpreter that ships with your OS, well, that's ok and you're out of luck for several reasons. I found this out myself: https://github.com/gollum/gollum-lib/issues/44 Wil -- 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/CAMmm3r7e%2BuzgXukJp3rhRKQttiWCaX%3D%2BR5fxDv1OR2jnC_b4sw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Replacement for puppet doc
On Aug 12, 2014 1:00 PM, Daniele Sluijters daniele.sluijt...@gmail.com wrote: Please don't use `dox`. It's like a teenager who wasn't taught enough English in school, or simply doesn't care, to know that the accepted plural of doc is docs, not dox, dawg. I have to agree, if for a different reason -- dox has taken on rather more specific connotations than just a foulspelling of docs. -- 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/CAMmm3r7o7zeaOZ8ph86b5sbu1QVg%2BRX2ksyOcPhx45%2BkGyVO2Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Replacement for puppet doc
On Aug 8, 2014 5:15 PM, Hailee Kenney hai...@puppetlabs.com wrote: Right now, Charlie Sharpsteen has an awesome prototype which uses YARDoc instead of RDoc. I see that YARD does not impose a specific markup[1] and I cannot tell from Charlie's prototype which markup is intended -- I would hope that one of them would be picked as a standard and I would be happiest with something that uses some flavor of Markdown. I understand that more semantic markup is desired, but I find the proliferation of wildly incompatible text markup formats frustrating. Variations in Markdown implementations[2] are bad enough; having to mentally switch to RDoc format to write module documentation causes much wailing and gnashing of teeth. Is this intended to be used only in Puppet manifests, or would there be support (in tooling/standards, at least) for using it in Ruby exentions too? I would also like to express my concern about: Documentation blocks must immediately precede the documented code with no whitespace. -- I spent several hours that could better have been spent watching Vanilla Sky or Gigli to this little bundle of joy in the current implementation -- particularly the with no whitespace bit. As for names, how about 'moddoc'? 1. http://rubydoc.info/gems/yard/file/docs/GettingStarted.md 2. Gollum uses Github-flavored with some wiki-specific extensions; Jekyll by default uses either RedCarpet (1.x) or Kramdown (2.x), which have incompatible code blocks; then there's the GFMD that Github renders *.md with; we use Atlassian Stash internally, which renders some flavor, etc. -- 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/CAMmm3r7xtu%2BWZ_sN5x-OfKDGZc_%2B7veG%2B4oOL%3DmqPDdyDbXoxw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Decision: Near future of resource expressions
On Aug 5, 2014 6:41 PM, Reid Vandewiele r...@puppetlabs.com wrote:
Example 1 (assuming behavior whereinmerging is OK, and that explicit
parameter specification takes precedence):
apache::vhost { $servername:
port = $port,
ssl = $ssl,
attribute_defaults = $extra_opts,
}
Assuming that the semantics of 'undef' haven't changed to preclude this (I
know there are changes coming but don't quite remember what they are), an
interesting couple of cases are:
$extra_opts = { $ssl = true, ... }
apache::vhost { ...
ssl = undef,
attributes = $extra_opts,
}
And:
$extra_opts = { $ssl = undef, ... }
apache::vhost { ...
ssl = true,
attributes = $extra_opts,
}
My expectation is that in both cases 'undef' means pretend I've said
nothing about thus attribute here and that *true* wins in either case.
But what if what is intended is to explicitly *ignore* the setting in
$extra_opts, so that the type's default is used, as if the attribute had
been mentioned by neither the $extra_opts hash or the apache::vhost
declaration? I guess using a hash operation to copy and filter $extra_opts
would do it.
By the way (since the paint's not dry) I think just *attributes* as the
afforementioned metaparam would be best -- it clearly says what it is, is
short, and is meta-sounding enough that I would not even consider using it
in the field -- when developing a class, defined type, type/provider, etc.
Another alternative that occurs to me that breaks the key = val layout
and so is cognitively distinct is to use something like the facilities that
many modern languages have for passing hashes or arrays as arguments to
methods/functions:
apache::vhost { $title:
...
**$extra_opts
}
or:
apache::vhost { $title:
...
$extra_opts
}
or:
apache::vhost { $tilte:
...
*$extra_opts
}
--
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/CAMmm3r557mJAxXT0m3vXv6T9OMfQCwK9npkdnT7Ro7ttkGtgUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] PR hiera/137 - recursive hiera data item lookups
On Tue, Jul 2, 2013 at 3:27 PM, Eric Sorenson
eric.soren...@puppetlabs.com wrote:
- Reading through Wil's example is really interesting because it also
touches on module reusability and module APIs. Are others on the thread in a
similar situation, where you need to compose/abstract common config
parameters to reduce duplication across your site data hierarchy? (And Wil,
is there a reason you can't just do that 'ldap_login_server_uris' mapping at
class declaration time rather than putting the lookups into the class
definitions themselves?)
Let me make sure I understand what you are suggesting. When I declare
the class, I expressly use the hiera lookup to provide the appropriate
parameter for the class:
modules/nss_pam_ldapd/manifests/config.pp:
class nss_pam_ldapd::config {
$server_uris = hiera('nss_pam_ldapd::config::server_uris', ...), #
maybe kill explicit hiera() here for simplicity
...
}
manifests/site.pp:
node foo {
include nss_pam_ldapd
class { 'nss_pam_ldapd::config':
server_uris = hiera('ldap_login_server_uris')
}
}
Sure, you can do that, but declaring the class is a good deal messier
-- with the hiera-internal reference it would be just include
nss_pam_ldapd. From what I understand, practices are evolving towards
simplifying node declaration by putting more of the complexity in
hiera. If so, then it seems better to appeal to people's
self-interest/laziness by making it easy to do it that way.
Wil
--
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 post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev] PR hiera/137 - recursive hiera data item lookups
+1 for the feature; I like Jeff's idea about using the existing sigil,
although I like Henrik's nested-function-like suggestion.
I think there is a particular case for this when it comes to lazy/busy
sysadmins integrating 3rd party modules from Puppet Forge (and for
encouraging writing internal modules with a general enough interface that
they can easily be contributed):
Let's say I've got modules for configuring nss_pam_ldapd in EL6 and for
configuring the native Solaris ldap_cachemgr. Both need, among other
things, the list of LDAP server URIs. If I am not too lazy and thinking
seriously about contributing them to PF, I'll write them to do a hiera
lookup using the correct name for automatic parameter lookups (we're still
on 2.7 working towards 3 compatibility):
class nss_pam_ldapd::config {
$server_uris = hiera('nss_pam_ldapd::config::server_uris', ...),
...
class ldap_cachemgr::conig {
$server_uris = hiera('ldap_cachemgr::config::server_uris, ...),
...
and now I have made more work for myself because I have to duplicate
(correctly) all of the info in hiera:
nss_pam_ldapd::config::server_uris:
- ldaps://ldap1.example.com
- ldaps://ldap2.example.com
...
ldap_cachemgr::config::server_uris:
- ldaps://ldap1.example.com
- ldaps://ldap2.example.com
...
whereas what I would like is:
ldap_login_server_uris:
- ldaps://...
nss_pam_ldapd::config::server_uris: %{ldap_login_server_uris}
ldap_cachemgr::config::server_uris: %{ldap_login_server_uris}
but since I cannot do this and I am really lazy/busy, I'm going to be dumb
and just lookup 'ldap_login_server_uris' and everyone else who might have
benefited from the module can go stuff it:
class nss_pam_ldapd::config {
$server_uris = hiera('ldap_login_server_uris')
...
And I am over-simplifying, because there are more like 8 parameters, almost
all of which apply between both modules and all of which need to be
duplicated.
Wil
--
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 post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev] Kerberos authentication
On Jun 5, 2013 12:18 PM, Trevor Vaughan tvaug...@onyxpoint.com wrote: Given that you're going to be using client certs for encryption, why would you bother with Kerberos authentication? This is what I was wondering as I read this too. One benefit I could see (but at a much smaller scoped project) is the ability to securely auto-sign certs. If you're already joining a machine to a Kerberos realm, it would be one less step if you could use that trust to provide validation for signing Puppet's client cert. Might be a bigger win for Windows systems, where Kerberos is all but required. Wil -- 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 post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev] Re: Performance regression between 3.2.1-rc1 and 3.1.1?
On Wed, May 22, 2013 at 10:10 AM, Charlie Sharpsteen ch...@puppetlabs.com wrote: Thanks a bunch for the info Wil! One additional question: What is the hostname that Ruby is using to perform the lookup? I.E., what is the return value of: ruby -rsocket -e 'puts Socket.gethostname' Regardless of which state /etc/hosts is in, it always returns the short name: coolair. Wil -- 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 post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet-dev] Re: Performance regression between 3.2.1-rc1 and 3.1.1?
On Mon, May 20, 2013 at 10:22 PM, Wil Cooley wcoo...@nakedape.cc wrote: I am noticing a ~10s slow down with 3.2.1-rc1 running 'puppet apply' with a manifest that is a single notice() function. After realizing that even 'puppet --version' took ~10s, I ran the ruby profiler, noticed there were differences in the number of calls, extracted diff'd those, noticed the addition of Socket#gethostbyname and Socket#gethostname. Eventually I noticed that my /etc/hosts had myhostname.local instead of just myhostname which (I presume) was causing a DNS/mDNS lookup. So unless anyone else has this problem, forget I said anything. Wil -- 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 post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev] Re: Performance regression between 3.2.1-rc1 and 3.1.1?
On Tue, May 21, 2013 at 9:53 AM, Charlie Sharpsteen ch...@puppetlabs.com wrote: Could you provide a bit more information on what the entry in your /etc/hosts file looked like? It would be interesting to reproduce this behavior and see if everything is functioning as intended. Sure; in my /etc/hosts I had the following for my host-only vbox net: 192.168.56.1 coolair.local coolair With that in place: $ time ruby -rsocket -e Socket.gethostbyname(Socket.gethostname) real 0m10.013s And when I change it to: 192.168.56.1 coolair I get: $ time ruby -rsocket -e Socket.gethostbyname(Socket.gethostname) real 0m0.032s After a little tracing, it looks like it's the result of loading webrick in puppet/util/monkey_patches.rb: /Library/Ruby/Site/1.8/puppet/util/monkey_patches.rb:419::-: require 'webrick' Which was added in ec462b7b: (#18781) Be more tolerant of old clients in WEBrick server Since this is just twiddling a constant (does that count as monkey-patching?), wouldn't this maybe be better done in lib/puppet/network/http/webrick.rb? If I understand it correctly, these monkey-patches get applied for every invocation of puppet, even if it's just puppet --version, so it seems like it should be as minimal as possible. For that matter, the two previous sections that monkey-patch openssl seem like they would be better off elsewhere; for example, the section if Puppet::Util::Platform.windows? that starts on line 398 seems like it might be better off somewhere in lib/puppet/util/windows*. (Sorry to gripe w/o a patch; I haven't a Windows system to test on nor do I know if I have a working setup for running the Puppet unit tests.) Wil -- 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 post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet-dev] Performance regression between 3.2.1-rc1 and 3.1.1?
I am noticing a ~10s slow down with 3.2.1-rc1 running 'puppet apply' with a
manifest that is a single notice() function. I think I noticed it first
w/'puppet resource' and maybe also with other sub-commands. This slow down
might be just statistical noise in runs with a non-trivial manifest, but
it's intrusive while doing development.
I can provide the outputs of the 'puppet apply' below, but the pause seems
to happen before any output starts and all of the times that are reported
look normal (0.00s for a bunch of built-in automatic resources), with
catalog runs ending with Finished catalog run in 0.0[56] seconds.
In fact, it almost looks like someone put in a sleep(10) somewhere while
debugging and forgot to take it out.
This is on Mac OS X 10.7.5.
$ uname -a
Darwin coolair 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT
2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
$ ruby --version
ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin11.0]
$ facter --version
1.7.1
$ shasum puppet-3.{1,2}*.dmg
2a35e1f2c77049a9cacb5446be1417fa4c69a082 puppet-3.1.1.dmg
995f48bae1d86b6195d2beff30848af1eecf41ff puppet-3.2.1-rc1.dmg
$ cat test.pp
# Test manifest that does nothing but a little output
notice(This is here.)
`time` outputs:
$ puppet apply --color=false --evaltrace --debug --verbose test.pp
# 3.1.1
real 0m3.392s
user 0m1.580s
sys 0m1.033s
# 3.2.1-rc1
real 0m13.064s
user 0m1.576s
sys 0m0.947s
Wil
--
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 post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet-dev] Puppet logo for community projects?
On Tue, Jan 29, 2013 at 4:29 PM, Randall Hansen rand...@puppetlabs.com wrote: Wil, did we ever solve this for you? I am going to write to marketing@ per Nan's advice, unfortunately I've been putting out fires (literally and figuratively). In fact, I'm going to do that right now. Thanks Randall! Wil -- 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 post to this group, send email to puppet-dev@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet-dev] Puppet logo for community projects?
I am working on an open-source Puppet-centric web application and would like to display some sort of Puppet-related logo. Right now I'm using the main Puppet Labs logo from the web site, but that's not really appropriate since my app is not actually a PL product (not to mention trademark issues). Is there an existing logo/graphic for use by 3rd-party, community projects? Or a process for becoming authorized to use the logo? Or should I have just kept my mouth shut and asked forgiveness later? I am nearly ready to move in to a pre-release phase, but I feel I need to clear this up before making any announcement. Thanks! Wil -- You received this message because you are subscribed to the Google Groups Puppet Developers group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
