Happy new year, Puppet-y friends!
I haven't been terribly active in the Puppet community for a few years now,
as my job focus has shifted quite a bit.
Namecheap was just nice enough to remind me that I registered
howtopuppet.com back in February 2014, with plans of turning it into an FAQ
site.
If this was just a troll, I'll speak the unfortunate truth - please keep
that on the puppet-users list, which is increasingly filling with it.
If this was a legitimate question, I'd guess you have some horrible
misconfiguration
- ActiveRecord was barely functional at best, and riddled with problem
On Sat, Aug 9, 2014 at 11:16 AM, Nan Liu wrote:
>
> +1, anything dry that makes documentation less of a chore. There's a lot
> of things we can already infer from the module layout, and I like docco
> style embedding of documentation because you need to reference the puppet
> source code in a lot
+10, shipit for both.
setting trusted_node_data turns "$facts" into a reserved variable and
triggers a nice warning as such if you try to use it. Seems that such
behavior should happen automatically for any reserved word (in puppet4, I
assume).
On Sat, Jul 19, 2014 at 4:44 AM, David Schmitt wro
FWIW,
On Thu, Jul 24, 2014 at 8:32 PM, Andy Parker wrote:
>
> DECISION TWO
>
> Resource instantiations are value producing expressions
>
> The expression based grammar that puppet 4 will be based on changed almost
> everything into a general expression, which allowed a lot of composition
> t
On 02/21/2014 11:53 AM, Andy Parker wrote:
On Fri, Feb 21, 2014 at 5:13 AM, Jason Antman <mailto:ja...@jasonantman.com>> wrote:
My heart stopped when I read this, though after reading the
tickets, I think I'm a little more clear on it, and less concerned.
Yes
My heart stopped when I read this, though after reading the tickets, I
think I'm a little more clear on it, and less concerned.
Just to confirm, the existing functionality will continue to work until
the new directory-based environments are feature complete, correct?
My specific concerns are
I had a pull request [1] to "fix" version comparison for yum and rpm
packages, as the current behavior is far from what yum does. The PR's
more or less stalled waiting for me to rework it, but I feel pretty
strongly that before we implement flexible versioning like this, we need
to make sure ve
Thanks for the clarifications.
On 01/22/2014 11:51 PM, Michael Stahnke wrote:
As such, for the benefit of the community, I'd suggest that
anything that (a) isn't fully tested and vetted by PL (whatever
that means) or (b) is known to be broken (i.e. naginator) be split
out into t
Re: Deepak's message about community maintainers... that sounds
wonderful to me. I'm not sure they'd even need commit access, perhaps it
would be feasible to operate on a model where all PRs against a given
provider are handled by a maintainer, and once they sign off a PL
employee does the merge. T
Dustin,
Yeah, you sure have. I reached out to the puppetagain/releng list (and
maybe also puppet-users) a few months ago when I first started this
project. Your advice was probably pretty much the same, so I hope my
replies are.
On 01/14/2014 09:25 PM, Dustin J. Mitchell wrote:
> I could have swo
ke this
easier? I work with one of the pip/virtualenv maintainers, and there's a
strong desire to have a canonical way to manage them in Puppet, whether
it be in core or a module.
Thanks in advance for any advice, guidance, or explanations of my
insanity. This is my first real attempt at type/
he various
tools that support it), but it's unclear to me how this would work if,
for example, the FreeBSD package provider version wasn't inextricably
tied to the puppet version.
Just some thoughts. I'm very excited to see this change, both for the
implications it has around nagi
13 matches
Mail list logo
