Well, faces can be installed as gems as well if they are packaged that way.
Some modules include both functions and faces though, my puppetdbquery
module would be an example of that. It could of course be split into
different parts for the functions and the face, but I'm not entirely
convinced of
+1 to OCSP support!
Trevor
On Fri, Mar 6, 2015 at 9:41 AM, Erik Dalén erik.gustav.da...@gmail.com
wrote:
On Fri, 6 Mar 2015 at 05:30 Eric Sorenson eric.soren...@puppetlabs.com
wrote:
Hi all, this may seem a bit far-out since we haven't pushed Puppet 4
completely out of the nest, but I
On Fri, Mar 6, 2015 at 6:41 AM, Erik Dalén erik.gustav.da...@gmail.com
wrote:
Also a solution to https://tickets.puppetlabs.com/browse/SERVER-115 is
really needed. It can sort of be solved in the Ruby version by only using a
single worker instance.
This is definitely slated for Puppet
On 03/06/2015 02:45 PM, Trevor Vaughan wrote:
file { '/export': ensure = 'directory' }
file { '/export/home': ensure = 'directory' }
user { 'foo': home = '/export/home/foo' } # This probably needs to come
after /export/home, otherwise the user will get a nasty surprise when
they first login
Sorry for the confusion. That's what I get for typing prior to the morning
caffeine.
Trevor
On Fri, Mar 6, 2015 at 9:03 AM, Felix Frank felix.fr...@alumni.tu-berlin.de
wrote:
On 03/06/2015 02:45 PM, Trevor Vaughan wrote:
file { '/export': ensure = 'directory' }
file { '/export/home':
Interestingly, I ran into just this issue yesterday.
The scenario was using autofs.
Autofs home directories get installed in /export/home/$USER.
Autofs takes care of $USER.
However, puppet takes care of /export and /home.
So, if all resources are managed by Puppet, then User['foo'] should
Hi Erik,
I was thinking of just having the 'module' subcommand shove things into
$confdir/faces/facename if the module is tagged as a face.
Installing them as a gem is irritating, but doable. It doesn't really keep
things tidy within the ecosystem though.
I actually don't like pluginsync'ing
That's a really good point and an unfortunate situation, kind of like the
group/user dependency chain for removals.
So, there goes that thread :-)
On Fri, Mar 6, 2015 at 9:23 AM, Erik Dalén erik.gustav.da...@gmail.com
wrote:
On Fri, 6 Mar 2015 at 15:04 Felix Frank
On Fri, 6 Mar 2015 at 05:30 Eric Sorenson eric.soren...@puppetlabs.com
wrote:
Hi all, this may seem a bit far-out since we haven't pushed Puppet 4
completely out of the nest, but I wanted to talk about some plans for the
next cycle of breaking changes/deprecations that are headed for Puppet 5.
On Fri, 6 Mar 2015 at 15:04 Felix Frank felix.fr...@alumni.tu-berlin.de
wrote:
On 03/06/2015 02:45 PM, Trevor Vaughan wrote:
file { '/export': ensure = 'directory' }
file { '/export/home': ensure = 'directory' }
user { 'foo': home = '/export/home/foo' } # This probably needs to come
Hi All,
I was building a custom Face and realized that there really should be
another way to handle these in the local filesystem.
The current method for adding Faces, as evidenced by 'strings', seems to be
to drop them in as a module.
I dislike this for two reasons. First, they're cluttering
On 03/06/2015 12:20 PM, Trevor Vaughan wrote:
If, for some reason, /export/home was *not* controlled by Puppet, then I
would want User['foo'[ to autorequire /export as well as /export/home.
Hi Trevor,
I see your example, but don't really see the value in requiring /export.
If /export/home
Oh, no, we would be requiring /export/home, not /export.
user { 'foo':
home = '/export/home/foo
}
/export/home/foo = Autofs controlled
/export/home = Something Puppet creates
If it doesn't create it, then nothing happens, no added complexity.
I'm not sure what kind of surprise you could have
On 03/06/2015 05:30 AM, Eric Sorenson wrote:
There are two main areas of change, both related to continuing to move
server-side functionality into Puppet Server: the certificate authority and
the network stack. There may be other semver-major breaks that get rolled
in, but at this point
I was going back and forth on this and I have to agree with John.
There have been several times where I pushed out a lightweight Puppet
server on a VM running 512M RAM, 1 CPU, just to try something in a
'production-like' scenario.
I'm OK with losing Rack support, but a lightweight server
On Thursday, March 5, 2015 at 10:30:47 PM UTC-6, Eric Sorenson wrote:
My hypothesis is if you're just dipping a toe in the water to try out
Puppet, running standalone with `puppet apply` is probably going to work
better than a webrick agent/server setup.
I'm doubtful of the validity of
Seconded. For debugging purposes, the webrick master is still useful as
well.
On 03/06/2015 06:04 PM, Trevor Vaughan wrote:
I was going back and forth on this and I have to agree with John.
There have been several times where I pushed out a lightweight Puppet
server on a VM running 512M RAM,
On Fri, Mar 6, 2015 at 8:46 AM, Eric Thompson er...@puppetlabs.com wrote:
Currently there are two separate certificate authority implementations,
one in Ruby and one in Clojure. Puppet 5 will consolidate onto the new
Clojure CA, removing the Ruby CA code and building new command-line tools
On Thursday, March 5, 2015 at 8:42:34 PM UTC-6, Adrien Thebo wrote:
To me, following the principle of least astonishment indicates that
caching be disabled by default; it'll work correctly for new users and has
no hidden gotchas. When people want to do performance tuning they're
probably
Currently there are two separate certificate authority implementations,
one in Ruby and one in Clojure. Puppet 5 will consolidate onto the new
Clojure CA, removing the Ruby CA code and building new command-line tools
to interact with it. (See SERVER-270 for the design/requirements work
Since we're winding down :)
As nobody seems to love generated resources as passionately as I do
(it's OK, we still have each other), I would still ask for a compromise:
Autorequire does make sense, but can we tone it down?
As I understand it, the following resource
user { 'foo': home =
John, Felix, and I agreemarking on calendar
On Fri, Mar 6, 2015 at 12:12 PM, Felix Frank
felix.fr...@alumni.tu-berlin.de wrote:
Seconded. For debugging purposes, the webrick master is still useful as
well.
On 03/06/2015 06:04 PM, Trevor Vaughan wrote:
I was going back and forth on
The principle of least astonishment is absolutely what we should be
targeting. The use of any kind of timer upon whose ticks behavior changes
is in inarguable opposition to this, whether it's 10 seconds, 3 minutes, or
15 minutes. However, I think the use of implementation terms like caching
in
On Friday, March 6, 2015 at 11:36:03 AM UTC-6, Reid Vandewiele wrote:
The principle of least astonishment is absolutely what we should be
targeting. The use of any kind of timer upon whose ticks behavior changes
is in inarguable opposition to this, whether it's 10 seconds, 3 minutes, or
On Mar 6, 2015, at 9:06 AM, John Bollinger john.bollin...@stjude.org wrote:
On Thursday, March 5, 2015 at 8:42:34 PM UTC-6, Adrien Thebo wrote:
To me, following the principle of least astonishment indicates that caching
be disabled by default; it'll work correctly for new users and has no
As Eric said there seems to be clear consensus and an issue has been opened
to make the change. I think it is still be useful for me to respond in
detail to John, but just to wrap up the thoughts - not to further advocate
for reload behavior. There seem to be good reasons to choose to serve files
26 matches
Mail list logo
