On Mon, Apr 7, 2014 at 5:17 AM, Andy Parker wrote:
> Once they are on should it be the behavior that showed up in 3.5.0
> (directory -> legacy) or should it have directory envs replace legacy envs?
Is there functionality implemented by legacy that can't be replicated
by directory (at the cost of
Agreed with Spencer -- this is pretty much exactly what feature flags
were designed for. That the need for such a flag only became obvious
after the release doesn't change that.
I assume this feature flag would default to true in 4.0, with suitable
warnings. That bit of the migration to 4.0 woul
Thanks for the clarification.
Dustin
--
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 th
On Wed, Jan 15, 2014 at 4:20 PM, Andy Parker wrote:
> * Tier2 code ideally won't live inside the puppet repo at all
..
> 1. create a "modules" directory that is a peer of "lib" in the puppet repo
These seem contradictory..
Dustin
--
You received this message because you are subscribed to t
Hah, so I was looking in the wrong mail account. I'm glad I'm not going crazy!
I agree with all of the limitations you've outlined. I don't see any
good fixes, sadly, but hopefully someone else does.
Dustin
--
You received this message because you are subscribed to the Google Groups
"Puppet
I could have sworn I've said some of this before, but I'm not sure
where. So sorry if this is repetitive.
First, I think what your implementation is missing is a resource name
that's globally unique to the host. Let's say I want to install
different versions of sqlalchemy in /venvs/staging and /
How about something as simple as a top-level "modules" directory in
the puppet source, which is installed separately and dynamically
appended to the modulepath at runtime? That avoids any problems for
users who set modulepath, allows modules in users' modulepaths to
override the built-in modules,
On Fri, Jan 10, 2014 at 12:45 PM, Andy Parker wrote:
> Tier-1 types: user, service, file, group, package, host, cron, exec, stage,
> tidy
> Tier-1 providers: dpkg, apt, gem, msi, rpm, windows, yum, useradd,
> windows_adsi, groupadd, crontab
>
> everything else is tier-2.
I'd like to see augeas be
For what it's worth, Python at least has struggled with modules being
in and out of the Python distribution. Riding Python's trains means
stringent compatibility constraints, long support durations (many
years), and a long commit-to-ship delay. Puppet certainly moves
faster than Python, so maybe
I understand the rename of master -> next and stable -> master, and
the backporting of some features from next, but what's to become of
next in general? If a patch in that branch doesn't come to someone's
attention in 2.0.0 or 2.1.0, will it ever make it into a release?
I'm not terribly invested
The idea is to run the exec if the unless command fails.
As in most programming languages where it's a keyword, "unless" mean
"if not". Process return codes are the opposite of boolean: 0 is
success and nonzero is failure.
So all of these pseudocodes are equivalent:
unless => "some_command"
unl
This is an exciting and deep conversation, and very relevant to
Mozilla's interests, as we've been struggling with the narrow pinhole
of permissions that is mode.
The general concept that I would like to emphasize is that the puppet
language has facilities for abstraction, and that can make
conver
It should not be notifying the service if the content has not changed.
Is your template generating different content each time?
Dustin
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving email
That is neat, and shows some interesting trends, particularly the
large spike in pull request lifetime around March, and the subsequent
drawdown. Clicking on merged/closed the pie chart, it looks like most
of those were closed, so I assume that was a backlog of stale pull
requests that the new sys
The security of the puppetmaster is, indeed, important, although to
varying degrees depending on the details of the implementation.
However, puppet itself does not manage modifications to the manifests
on the masters - that's up to the implementation.
I don't think it's inherently any safer to cr
This isn't just an optimization. There are cases where you must
resort to exec'ing yum when, for example, two interdependent packages
must be installed in the same transaction, or one incompatible package
must be replaced by another. Note that the latter entails installing
and removing in the sam
I know - I suffered through that slowness. It was bad, but my puppet
runs finished eventually!
I suppose it all depends on (a) how much work it is to write an
API-compatible, plist-based library and (b) how difficult users will
find installing an external copy of CFP. If that's (a) lots and (b)
On Mon, Sep 2, 2013 at 12:40 PM, Henrik Lindberg
wrote:
> How would you ensure this? The fact that it seems to work? Do you have
> perfect test coverage? (The parser checks all code paths, not just the ones
> that are executed in tests).
I'd run a copy of Puppet-7.3 and parse each .pp file. If i
On Wed, Aug 28, 2013 at 1:20 PM, Luke Kanies wrote:
> That implies that we can't ship it until 4.0, which would be a tragedy
> worth fighting hard to avoid.
At the risk of sounding impertinent, I think you have it backward.
When a desirable feature or enhancement requires a
backward-incompatible
On Fri, Aug 30, 2013 at 9:24 AM, Henrik Lindberg
wrote:
> Yes, that makes sense. What I am asking is if we also want to be able to
> tell if code makes use of features that are newer than what the user would
> *like* to use. (My code has to work in both puppet 4 and puppet 3, I am
> marking my mod
First, a vote against reverting to explicit loading -- the module
autoloader is *awesome* from a user perspective.
Second, to the idea of doing a better job of invalidating caches
between runs, I don't think anyone (except perhaps Henrik, in the
comment that I, like Luke, can't quite parse) has co
First let me apologize for *not* submitting my patches upstream (and
thanks, Christian, for merging them!). Given the appearance of
"Puppet" throughout the library, I assumed that it had actually been
forked, not vendored. Not that that's a great excuse for not
submitting to the other fork. Anyw
The switch to semantic versioning has been pretty broadly announced
and discussed. It will benefit from being seen in action, and from a
smooth start. Which means sooner rather than later, and fewer
compatibility breakages rather than more. It's easier for users to
work off a short list of "BREA
It's not quite *static* content. I can see a lot of ways that this
might be useful to users. For example, I host yum/apt/DMG repos (and
maybe nuget too!) on my puppet masters, and as I scale puppet masters
I will want to use shared storage for those - probably NFS. So being
able to add the stat
The current situation is that master monitoring basically consists of
a no-op HTTP request. We'd like to get to a point where it includes
live status of the master. It makes sense for that live status to
include among other things some manually-flippable "in_service?" kind
of switch.
My understa
Yes - examples will definitely clear up confusion for anyone who has
the same experience as me (which may be very few people!)
Dustin
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails
On Sun, Aug 25, 2013 at 6:47 PM, Henrik Lindberg
wrote:
> At the technical parsing level, yes. This is then validated to only include
> what we want to allow. The first implementation is very permissive.
Oh! Then, my reading of the ARM was wrong - I thought that "Puppet
DSL" referred to the Pupp
On Sun, Aug 25, 2013 at 5:45 PM, Henrik Lindberg
wrote:
>> This may be silly, but "Extended Puppet Templates" seems more logically
>> abbreviated "EPT" - why "EPP"?
>>
> Does it say "Extended Puppet Templates" somewhere? The idea is to do the
> same as in Ruby, i.e. "Embedded Ruby" = ERP, "Embedde
That's a perfectly reasonable question. I think that one answer is,
"everyone else does it" - JEPs, PEPs, RFCs, and so on. There's some
value to that: easy, unambiguous, and short.
Note, too, that there's a process for getting a number assigned early,
before you start writing - for example, I ha
Something I thought of afterward is, there's room for commentary on
the format and language of the ARM itself, as well as on the technical
content it describes.
Presumably both are welcome, but the distinction may be worth calling
out occasionally. Basically, if an ARM doesn't make sense, it's
pe
You could probably use a simple semaphore file to indicate the status
- perhaps just a YAML file, the contents of which are returned by the
indirector?
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop
One option may be to configure the 'sendmail' option to point to an
executable that can perform SMTP auth over TLS. Barring that, you'll
probably need to add additional support to puppet, possibly including
either an extension of the 'smtpserver' configuration or a new
configuration variable. I'm
I thought I'd kick off discussion of this ARM,
https://github.com/puppetlabs/armatures/pull/60/files
(I started discussion in the pull req, but this is probably a better
place for it)
First, the summary is about the implementation - it should probably
start with the goal: "load balancers should
I had no awareness of the office hours (which is probably also my fault),
but that sounds like a great idea.
I struggle with the same problem in Buildbot: how do I keep people informed
and solicit meaningful feedback without overwhelming them?
One, perhaps unorthodox, technique is something you'r
This is regarding ticket 5517. Briefly, that ticket identifies a corner
case of parameterized classes and inheritance that behaves unexpectedly
with no warnings or error messages. The ticket has evolved from "please
fix" to "please warn or treat as an error" to "parameterized classes were
never a
On Thu, Jul 11, 2013 at 9:21 PM, Rob Reynolds wrote:
> My initial thought is that we should use something like win_ but I wanted to
> check to see if there is a better prefix that we should use.
I think that makes a lot more sense than "sp_", which doesn't, to me,
suggest OS X.
Dustin
--
You r
On Mon, Jul 1, 2013 at 12:58 PM, Andy Parker wrote:
> I would be very concerned if the security system of puppet were based on
> untrusted information from the agent. Unless we have a bug in this system,
> which we don't as far as I know, then the security is all based on the CN of
> the certifica
On Thu, Jun 27, 2013 at 5:54 PM, Andy Parker wrote:
> The reason I'm calling this out is because it might be an unexpected
> requirement. We always say that a newer master can talk to an older agent,
> but not that an older master can talk to a newer agent. In this case we will
> really be making
On Wed, Jun 12, 2013 at 1:11 AM, Mike Hancock wrote:
> If .../api/nodes is no longer defined in v3 then:
>
> get .../api/nodes
> Accept: version=3
>
> :returns 404
Well, we've painted this bikeshed enough to get it through the winter.
I don't expect to use the API myself, so I don't actually h
On Tue, Jun 11, 2013 at 9:52 PM, michael hancock wrote:
> That is not what I asked for. The discussion is about alternative designs
> for handling REST API versioning. For REST API's I see versioning as content
> negotiation.
>
> For example,
>
> GET .../api/nodes
> Accept: version=2.0
>
> is like
On Tue, Jun 11, 2013 at 7:13 PM, Rags wrote:
> Puppet manifests today don't specify the version of DSL they are writing to,
> afaik. This will likely lead to the classic versioning problem. Imagine a
> new language construct gets added and not all Puppet versions can support
> this language constr
On Tue, Jun 11, 2013 at 12:41 PM, Daniel Pittman wrote:
>> There should be a /latest/ link that points to the latest API version,
>> too. If such a thing does not exist in PuppetDB, then I think that'd
>> be the better feature request to make.
>
> This would be a fundamental mistake, however. Wh
On Tue, Jun 11, 2013 at 12:16 PM, David Schmitt wrote:
> As if anybody who has enough configurations specifying an endpoint that
> changing the version number is a problem would be in the position to speak
> the current API at /latest/ everywhere at the same time.
The OP indicated they wanted to
On Tue, Jun 11, 2013 at 9:42 AM, michael hancock wrote:
> I just noticed that the API version is embedded in the URL like:
>
> curl -H "Accept: application/json" http://puppetdb.domain/v2/nodes
>
> I suppose it's too late to implement this so the client would do:
>
> curl -H "Accept: application/
This is a *very* useful kind of post to make regularly, so I know what
to expect in future releases and can arrange my deployment schedule to
suit, when necessary.
Enjoy Seattle, once again! Maybe it's just time to rename to "The
Latest Results From Puppet Labs" or something less location-suggest
Does strace help to figure that out?
Dustin
--
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,
On Sun, May 12, 2013 at 7:07 AM, Shreejit Nair wrote:
> Please help me with these questions and give me a detailed solution as i am
> new to puppet and mcollective.
You may have better luck asking such questions on the puppet-users
list: http://groups.google.com/group/puppet-users
Dustin
--
Yo
How large is the file?
The hash must be performed on the master and the agent, and is
performed over the whole file regardless of the checksum option (bugs
13199 and 18333).
Dustin
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubs
Nan, you're right - I remember looking at this a while ago, so perhaps
it was in some old version.
Dustin
--
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 p
On Thu, May 2, 2013 at 9:46 PM, Alex Harvey wrote:
> I need to submit a patch to fix #18393 as it is affecting about half my
> fleet - turns out AIX<=5.3, Solaris<=8, and all HP-UX don't have a diff with
> -u. I would like to submit a patch that allows us to specify diff args in
> the configurati
It seems like this could be done pretty easily in stdlib - no need to
modify core puppet. At worst, this is a custom type, but can probably
be done with define and an exec of some sort. The former solution
probably has fewer portability issues.
Dustin
--
You received this message because you a
On Mon, Sep 10, 2012 at 3:11 AM, Rajeev Iyer wrote:
> err: Failed to apply catalog: Parameter path failed: File paths must
> be fully qualified, not 'tmp/testfile' at /etc/puppet/manifests/site.pp:7
First, this question is better-suited to the puppet-users mailing list.
Second, the problem is th
I think this would come down to what the most common type of managed
OS X system is, based on the number of users on the system, and the
portion of those users managed by puppet.
Personally, I have only two users (root and a non-privileged user),
and they're both managed, so the prefetching makes
On Sat, Sep 1, 2012 at 1:11 PM, R. Tyler Croy wrote:
> If you've got other questions I find popping onto #puppet-dev (on Freenode)
> can be helpful to
> make progress rapidly on these kind of "bootstrapping" problems :)
I did find that channel after sending this - thanks!
Actually, bundler does
54 matches
Mail list logo
