Re: [Puppet-dev] Puppet Faces Install Location
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 the benefit. Also if they are installed as modules they can be pluginsynced to agents which can be pretty handy. On Fri, 6 Mar 2015 at 13:24 Trevor Vaughan tvaug...@onyxpoint.com wrote: 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 up my module space (and function namespace) with something that is not a module. Second, I don't want to have to add things to 'modules' if my node is simply a client where I want additional functionality (puppetdb hooks, whatever). So, I would like to propose the following: * The module tool and Forge are enhanced to support a 'face' tag * The 'face' tag will indicate that the module is installing a Face * Faces cannot co-exist with other module components (no actual puppet management code should be in a Face module) * Faces will live at $facedir, by default $confdir/faces * Face functionality will not pollute the global namespace (if possible) Thanks, Trevor -- 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%2BFoXyTmRocvMBFR3qNnzyZyuhLdjsVTFAA-9vgtiOoJ5NMg%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXyTmRocvMBFR3qNnzyZyuhLdjsVTFAA-9vgtiOoJ5NMg%40mail.gmail.com?utm_medium=emailutm_source=footer . 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/CAAAzDLc9%2BBzsAQzmq%2BUKmWxWw9VBK0STA_JAJ5xcOVgEya3xSQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Puppet 5 changes
+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 wanted to talk about some plans for the next cycle of breaking changes/deprecations that are headed for Puppet 5. 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 we're planning to deliberately NOT have language changes that would necessitate revising modules. 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 here.) This is cool because right now there are a few overlapping / conflicting subcommands like `puppet ca`, `puppet cert`, `puppet certificate_request`, etc that are pretty inconsistent, and it'll be great to have the chance to clean them up. Similarly, on the network stack, we want to consolidate on the jetty/puppet-server/jruby stack as the single way to run Puppet masters, so the built-in webrick support and Rack support layer will ride off into the sunset. The webrick one shouldn't be too controversial: it causes a lot of people to start off on a bad path because it tips over so easily. 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. But I'm interested in hearing opinions on the Rack deprecation, especially if there are significant functionality gaps between what people are currently doing in your Passenger setup and what's possible with Puppet Server. Overall it's obviously easier to support fewer, more opinionated ways of running a Puppet infrastructure but not if it comes at the price of breaking stuff without adequate replacement. There have already been some pretty substantial improvements to Puppet Server based on feedback like SERVER-18, so conversations like Hey I'm doing this cool thing with nginx right now, will that still work? are really helpful. We would need support for If-Modified-Since headers to be able to switch. Using a custom Apache config to get them working under the passenger CA (serving all CA files by apache using mod_rewrite instead of going through the Ruby code). We mostly use that for knowing when to update the CRL though, so some better mechanism for that like OCSP would work as well. 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. But really I think it would be good if the whole cert request stuff could use some standard protocol like SCEP so other CA implementations like Dogtag or even Active Directory would work as well as the puppet-server one. -- 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/CAAAzDLeRBPWsLcevR-t9rn7HW%3Dxp69Au1tQepZBKBKgN06RXOg%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CAAAzDLeRBPWsLcevR-t9rn7HW%3Dxp69Au1tQepZBKBKgN06RXOg%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%2BFoURh52CYLJVohcN5po46PhN1TCfB5c%3DWyUx5mBPz1Fatw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Puppet 5 changes
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 5.0/Puppet Server 3.0. But really I think it would be good if the whole cert request stuff could use some standard protocol like SCEP so other CA implementations like Dogtag or even Active Directory would work as well as the puppet-server one. I'm a huge fan of that suggestion... we'll at least look into it :) -- 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/CAMx1QfKNC0LYeTm%2B%3DJuzDzaBo%3DxrpjSWWegzXMqHDCQNrryryg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Autorequiring parent directories to the home directory in user resources
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
Sure, I *can* create the user without having the directory in place. But
what good does that do anyone?
Ah, a misunderstanding. It had actually not occured to me that users
might manage the $HOME dir as a file resource as well, and that we
should autorequire that. I'm all caught up in autorequiring the parent.
And yes, both these things do make sense. I see no issues with adding
the relationship to either homedir or parent. (It's parent+1 that makes
no sense, but we agree on that as well).
Thanks,
Felix
--
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/54F9B3CA.7030700%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Autorequiring parent directories to the home directory in user resources
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': 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
Sure, I *can* create the user without having the directory in place. But
what good does that do anyone?
Ah, a misunderstanding. It had actually not occured to me that users
might manage the $HOME dir as a file resource as well, and that we
should autorequire that. I'm all caught up in autorequiring the parent.
And yes, both these things do make sense. I see no issues with adding
the relationship to either homedir or parent. (It's parent+1 that makes
no sense, but we agree on that as well).
Thanks,
Felix
--
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/54F9B3CA.7030700%40alumni.tu-berlin.de
.
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%2BFoWiBpz5mKXgfNGwTpH1SmsRByRjuo_KMQVS3nY66hYKSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Autorequiring parent directories to the home directory in user resources
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
autorequire at least /export/home which, in turn, will autorequire /export.
However, the actual /export/home/$USER directory is completely irrelevant
(and should not show up in Puppet anyway).
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.
In this case, I would want the user's target directory +1 to be
autorequired and I would like to vote for that.
I couldn't come up with any scenarios that would push me past target +1.
Trevor
On Fri, Mar 6, 2015 at 5:50 AM, Felix Frank felix.fr...@alumni.tu-berlin.de
wrote:
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 = '/var/lib/vendor/toolset/vendor-tool' }
will autorequire either
File['/var/lib/vendor/toolset']
File['/var/lib/vendor']
File['/var/lib']
or
File['/var']
which is a bit much for my taste. Autorequiring the immediate parent
only would make more sense to me.
Thanks,
Felix
On 03/03/2015 10:38 PM, Trevor Vaughan wrote:
Indeed, I too apologize for the complete tangent!
And, as would be expected, I'm for the autorequires since it does what I
would expect it to do.
Which, again, is counter to what John wants ;-). But, that's my answer
to the original question.
Thanks,
Trevor
On Tue, Mar 3, 2015 at 3:37 PM, John Bollinger
john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote:
On Wednesday, February 25, 2015 at 5:41:19 PM UTC-6, Raphaël Pinson
wrote:
Hello,
As per Kylo's comment in PR for PUP-4036
https://github.com/puppetlabs/puppet/pull/3645#issuecomment-76032829,
I'd like to discuss the possibility and implications of
autorequiring parent directories of the home directory for user
resources.
As stated in the PR, the idea came from stumbling upon a code
like this one:
file { '/srv/home': ensure = directory }
file { '/home': ensure = link, target = '/srv/home' } - User
| |
where it made a lot of sense that all users should just
autorequire the nearest parent directory to their home directory.
What are your thoughts on this feature?
My sincere apologies for my part in what I now recognize as taking
this thread off on a tangent. The lively discussion we had,
however, did allow me to frame my general position on
autorequirements, which is that they should be implemented only when
they are directly indicated by the nature of the resource. If User
resources /can/ be applied without first applying the File resources
representing their home directories, then there should be no
autorequirement.
John
--
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
mailto:puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/b8d5e560-9357-4d8f-8234-3b593d9be246%40googlegroups.com
https://groups.google.com/d/msgid/puppet-dev/b8d5e560-9357-4d8f-8234-3b593d9be246%40googlegroups.com?utm_medium=emailutm_source=footer
.
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/54F98667.5040505%40alumni.tu-berlin.de
.
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%2BFoV1y%2BGbkHCh8MccFgRuYAkjb2CTBzw07awZkDqLpZf0Wg%40mail.gmail.com.
For more options, visit
Re: [Puppet-dev] Puppet Faces Install Location
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 them since I really don't think that items that are not related to the application of the system configuration should be sync'd to clients. Could the face portion be put in a 'face' directory in the module and that be pulled to the alternate location by the module tool if it exists? Thanks, Trevor On Fri, Mar 6, 2015 at 9:19 AM, Erik Dalén erik.gustav.da...@gmail.com wrote: 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 the benefit. Also if they are installed as modules they can be pluginsynced to agents which can be pretty handy. On Fri, 6 Mar 2015 at 13:24 Trevor Vaughan tvaug...@onyxpoint.com wrote: 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 up my module space (and function namespace) with something that is not a module. Second, I don't want to have to add things to 'modules' if my node is simply a client where I want additional functionality (puppetdb hooks, whatever). So, I would like to propose the following: * The module tool and Forge are enhanced to support a 'face' tag * The 'face' tag will indicate that the module is installing a Face * Faces cannot co-exist with other module components (no actual puppet management code should be in a Face module) * Faces will live at $facedir, by default $confdir/faces * Face functionality will not pollute the global namespace (if possible) Thanks, Trevor -- 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%2BFoXyTmRocvMBFR3qNnzyZyuhLdjsVTFAA-9vgtiOoJ5NMg%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXyTmRocvMBFR3qNnzyZyuhLdjsVTFAA-9vgtiOoJ5NMg%40mail.gmail.com?utm_medium=emailutm_source=footer . 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/CAAAzDLc9%2BBzsAQzmq%2BUKmWxWw9VBK0STA_JAJ5xcOVgEya3xSQ%40mail.gmail.com https://groups.google.com/d/msgid/puppet-dev/CAAAzDLc9%2BBzsAQzmq%2BUKmWxWw9VBK0STA_JAJ5xcOVgEya3xSQ%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%2BFoURo-0aZ0AtD2%3DPJbpEb%3DQRbZANSpE-aLfx2%2BFe70Ar%3Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Autorequiring parent directories to the home directory in user resources
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 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
after /export/home, otherwise the user will get a nasty surprise when
they first login
Sure, I *can* create the user without having the directory in place. But
what good does that do anyone?
Ah, a misunderstanding. It had actually not occured to me that users
might manage the $HOME dir as a file resource as well, and that we
should autorequire that. I'm all caught up in autorequiring the parent.
And yes, both these things do make sense. I see no issues with adding
the relationship to either homedir or parent. (It's parent+1 that makes
no sense, but we agree on that as well).
Won't the $HOME file resource autorequire the user resource already? At
least if $HOME is owned by $USER, which it usually is. So then you would
get a dependency loop.
--
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/CAAAzDLfcUqwhAAg-k_KF%2BGU%2B1txbSfg6%2Bbgh6Y1OXjojfK5e5w%40mail.gmail.com
https://groups.google.com/d/msgid/puppet-dev/CAAAzDLfcUqwhAAg-k_KF%2BGU%2B1txbSfg6%2Bbgh6Y1OXjojfK5e5w%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%2BFoVim-bzk3XPt0NDQxGWYCTJ5-JSBikZxm49ELLAeFxA9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Puppet 5 changes
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. 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 we're planning to deliberately NOT have language changes that would necessitate revising modules. 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 here.) This is cool because right now there are a few overlapping / conflicting subcommands like `puppet ca`, `puppet cert`, `puppet certificate_request`, etc that are pretty inconsistent, and it'll be great to have the chance to clean them up. Similarly, on the network stack, we want to consolidate on the jetty/puppet-server/jruby stack as the single way to run Puppet masters, so the built-in webrick support and Rack support layer will ride off into the sunset. The webrick one shouldn't be too controversial: it causes a lot of people to start off on a bad path because it tips over so easily. 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. But I'm interested in hearing opinions on the Rack deprecation, especially if there are significant functionality gaps between what people are currently doing in your Passenger setup and what's possible with Puppet Server. Overall it's obviously easier to support fewer, more opinionated ways of running a Puppet infrastructure but not if it comes at the price of breaking stuff without adequate replacement. There have already been some pretty substantial improvements to Puppet Server based on feedback like SERVER-18, so conversations like Hey I'm doing this cool thing with nginx right now, will that still work? are really helpful. We would need support for If-Modified-Since headers to be able to switch. Using a custom Apache config to get them working under the passenger CA (serving all CA files by apache using mod_rewrite instead of going through the Ruby code). We mostly use that for knowing when to update the CRL though, so some better mechanism for that like OCSP would work as well. 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. But really I think it would be good if the whole cert request stuff could use some standard protocol like SCEP so other CA implementations like Dogtag or even Active Directory would work as well as the puppet-server one. -- 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/CAAAzDLeRBPWsLcevR-t9rn7HW%3Dxp69Au1tQepZBKBKgN06RXOg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Autorequiring parent directories to the home directory in user resources
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
after /export/home, otherwise the user will get a nasty surprise when
they first login
Sure, I *can* create the user without having the directory in place. But
what good does that do anyone?
Ah, a misunderstanding. It had actually not occured to me that users
might manage the $HOME dir as a file resource as well, and that we
should autorequire that. I'm all caught up in autorequiring the parent.
And yes, both these things do make sense. I see no issues with adding
the relationship to either homedir or parent. (It's parent+1 that makes
no sense, but we agree on that as well).
Won't the $HOME file resource autorequire the user resource already? At
least if $HOME is owned by $USER, which it usually is. So then you would
get a dependency loop.
--
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/CAAAzDLfcUqwhAAg-k_KF%2BGU%2B1txbSfg6%2Bbgh6Y1OXjojfK5e5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Puppet Faces Install Location
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 up my module space (and function namespace) with something that is not a module. Second, I don't want to have to add things to 'modules' if my node is simply a client where I want additional functionality (puppetdb hooks, whatever). So, I would like to propose the following: * The module tool and Forge are enhanced to support a 'face' tag * The 'face' tag will indicate that the module is installing a Face * Faces cannot co-exist with other module components (no actual puppet management code should be in a Face module) * Faces will live at $facedir, by default $confdir/faces * Face functionality will not pollute the global namespace (if possible) Thanks, Trevor -- 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%2BFoXyTmRocvMBFR3qNnzyZyuhLdjsVTFAA-9vgtiOoJ5NMg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Autorequiring parent directories to the home directory in user resources
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 appears through a mount, then the user should make the User require the mount resource explicitly, not its mount point. If there is no mount resource (autofs), then requiring the mount point adds comparatively little safety, at the cost of complexity and potential surprises. Cheers, Felix -- 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/54F9A1D6.8060107%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Autorequiring parent directories to the home directory in user resources
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 with autorequiring
/export/home. I'm also not sure what complexity arises.
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
Sure, I *can* create the user without having the directory in place. But
what good does that do anyone?
Trevor
On Fri, Mar 6, 2015 at 7:47 AM, Felix Frank felix.fr...@alumni.tu-berlin.de
wrote:
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 appears through a mount, then the user should make the
User require the mount resource explicitly, not its mount point. If
there is no mount resource (autofs), then requiring the mount point adds
comparatively little safety, at the cost of complexity and potential
surprises.
Cheers,
Felix
--
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/54F9A1D6.8060107%40alumni.tu-berlin.de
.
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%2BFoWKrZQad85WfR%3D_PhRGJ5CDL-LuWniVZesT60sWGrZG9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Puppet 5 changes
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 we're planning to deliberately NOT have language changes that would necessitate revising modules. I guess that means that dynamic scoping of resource defaults will have to linger until Puppet 6, yes? This is not necessarily a problem - depending on how fast we get to Puppet 5, we may not even have the solution ready in time, anyway. On the other hand, I dearly hope that no Forge module currently relies on dynamic scoping. Cheers, Felix -- 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/54F9CD7B.4060006%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Puppet 5 changes
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 instance is great for testing. Trevor On Fri, Mar 6, 2015 at 12:01 PM, John Bollinger john.bollin...@stjude.org wrote: 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 that hypothesis. The use cases for `puppet apply` tend to be different from the use cases for agent / master. If I wanted to try out Puppet for a scenario in which agent / master was the appropriate choice, or especially if the agent / master setup itself were part of what I wanted to evaluate, then `puppet apply` would simply not be a good alternative. As light-duty as webrick may be, it has the virtue of being extremely easy get up and running. I'm not specially tied to webrick itself, but I think Puppet benefits from having a lightweight, out-of-the-box server option. John -- 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/d9061cc6-93a8-40fd-8572-d4fdfc9170cf%40googlegroups.com https://groups.google.com/d/msgid/puppet-dev/d9061cc6-93a8-40fd-8572-d4fdfc9170cf%40googlegroups.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%2BFoWjOt7UXAd%3DXqUOS-x84WdkeSnjV0ixhOcXJyVRVZReYQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Re: Puppet 5 changes
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 that hypothesis. The use cases for `puppet apply` tend to be different from the use cases for agent / master. If I wanted to try out Puppet for a scenario in which agent / master was the appropriate choice, or especially if the agent / master setup itself were part of what I wanted to evaluate, then `puppet apply` would simply not be a good alternative. As light-duty as webrick may be, it has the virtue of being extremely easy get up and running. I'm not specially tied to webrick itself, but I think Puppet benefits from having a lightweight, out-of-the-box server option. John -- 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/d9061cc6-93a8-40fd-8572-d4fdfc9170cf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Puppet 5 changes
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, 1 CPU, just to try something in a 'production-like' scenario. I'm OK with losing Rack support, but a lightweight server instance is great for testing. Trevor On Fri, Mar 6, 2015 at 12:01 PM, John Bollinger john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote: 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 that hypothesis. The use cases for `puppet apply` tend to be different from the use cases for agent / master. If I wanted to try out Puppet for a scenario in which agent / master was the appropriate choice, or especially if the agent / master setup itself were part of what I wanted to evaluate, then `puppet apply` would simply not be a good alternative. As light-duty as webrick may be, it has the virtue of being extremely easy get up and running. I'm not specially tied to webrick itself, but I think Puppet benefits from having a lightweight, out-of-the-box server option. John -- 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/54F9DFE0.7010503%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Puppet 5 changes
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 to interact with it. (See SERVER-270 for the design/requirements work here.) This is cool because right now there are a few overlapping / conflicting subcommands like `puppet ca`, `puppet cert`, `puppet certificate_request`, etc that are pretty inconsistent, and it'll be great to have the chance to clean them up. I hadn't heard about this portion of puppet 5. If some of these subcommands are going away do we have deprecation notices going into some y or z release of puppet 4? One option that we've discussed is replacing the old commands with stubs that just print out some info about how to find / use the new versions. Eric may have more thoughts re: deprecation notices, though. -- 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/CAMx1Qf%2BzYOgb-Y9WoE7AWz46MWrTgneo7KLBSuM%2BM74S%3DJ%2BYOA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Default environment_timeout preference
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 fairly sophisticated users and can deal with weird cache invalidation issues; since they're opting into this feature they should be prepared to deal with the ramifications. +1 Perhaps it would make sense for PE to be configured differently out of the box, but between the two options presented, Puppet's built-in default should be no caching. John -- 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/fbe05736-89bf-42d1-8125-dd4ea6865b45%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Puppet 5 changes
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 here.) This is cool because right now there are a few overlapping / conflicting subcommands like `puppet ca`, `puppet cert`, `puppet certificate_request`, etc that are pretty inconsistent, and it'll be great to have the chance to clean them up. I hadn't heard about this portion of puppet 5. If some of these subcommands are going away do we have deprecation notices going into some y or z release of puppet 4? -- Eric Thompson eric.thomp...@puppetlabs.com er...@puppetlabs.com Senior Software Quality Assurance Engineer -- 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/CAC3n4yQhvtnM3WB-MvpkfAswbK9uczmZ8rbtqxy9JnRXUDuMsQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Autorequiring parent directories to the home directory in user resources
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 = '/var/lib/vendor/toolset/vendor-tool' }
will autorequire either
File['/var/lib/vendor/toolset']
File['/var/lib/vendor']
File['/var/lib']
or
File['/var']
which is a bit much for my taste. Autorequiring the immediate parent
only would make more sense to me.
Thanks,
Felix
On 03/03/2015 10:38 PM, Trevor Vaughan wrote:
Indeed, I too apologize for the complete tangent!
And, as would be expected, I'm for the autorequires since it does what I
would expect it to do.
Which, again, is counter to what John wants ;-). But, that's my answer
to the original question.
Thanks,
Trevor
On Tue, Mar 3, 2015 at 3:37 PM, John Bollinger
john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote:
On Wednesday, February 25, 2015 at 5:41:19 PM UTC-6, Raphaël Pinson
wrote:
Hello,
As per Kylo's comment in PR for PUP-4036
https://github.com/puppetlabs/puppet/pull/3645#issuecomment-76032829,
I'd like to discuss the possibility and implications of
autorequiring parent directories of the home directory for user
resources.
As stated in the PR, the idea came from stumbling upon a code
like this one:
file { '/srv/home': ensure = directory }
file { '/home': ensure = link, target = '/srv/home' } - User | |
where it made a lot of sense that all users should just
autorequire the nearest parent directory to their home directory.
What are your thoughts on this feature?
My sincere apologies for my part in what I now recognize as taking
this thread off on a tangent. The lively discussion we had,
however, did allow me to frame my general position on
autorequirements, which is that they should be implemented only when
they are directly indicated by the nature of the resource. If User
resources /can/ be applied without first applying the File resources
representing their home directories, then there should be no
autorequirement.
John
--
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
mailto:puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/b8d5e560-9357-4d8f-8234-3b593d9be246%40googlegroups.com
https://groups.google.com/d/msgid/puppet-dev/b8d5e560-9357-4d8f-8234-3b593d9be246%40googlegroups.com?utm_medium=emailutm_source=footer.
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/54F98667.5040505%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Re: Puppet 5 changes
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 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 instance is great for testing. Trevor On Fri, Mar 6, 2015 at 12:01 PM, John Bollinger john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote: 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 that hypothesis. The use cases for `puppet apply` tend to be different from the use cases for agent / master. If I wanted to try out Puppet for a scenario in which agent / master was the appropriate choice, or especially if the agent / master setup itself were part of what I wanted to evaluate, then `puppet apply` would simply not be a good alternative. As light-duty as webrick may be, it has the virtue of being extremely easy get up and running. I'm not specially tied to webrick itself, but I think Puppet benefits from having a lightweight, out-of-the-box server option. John -- 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/54F9DFE0.7010503%40alumni.tu-berlin.de . 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%2BFoVu5pJB0J6A-GdM7yrNpXA3KDxa7wcFngfSZaLQgeusyA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Default environment_timeout preference
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 describing the two proposed options clouds the water a bit, as both options result in clear and consistent behavior. Described without the term caching, option 1 effectively proposes that puppet-server should read all configuration files on startup (puppet.conf, auth.conf, fileserver.conf, environments/**/*.pp, etc.), and not automatically re-read any of these files unless the user issues an explicit `service puppet-server reload` command. Described without the term caching, option 2 effectively proposes that puppet-server should read some configuration files on startup (puppet.conf, auth.conf, fileserver.conf, etc.), and that puppet-server should read directly from disk all relevant files from environments/**/*.pp when compiling a catalog, once per agent request. Both proposals move strongly away from the problem behavior we have today - a clock-based timeout. Were this a new product, either option seems like it would satisfy principle of least astonishment. The only difference between them, from an astonishment perspective, is that long-time Puppet users are accustomed to behavior resembling option 2 (though in the past implementation it's been more optimized, similar to the inotify suggestion put forth by Trevor). I don't know that thinking about it this way changes anyone's opinion, but I do want to make sure we aren't getting hung up on implementation terms in considering what the actual proposed behaviors are. Is having files live-updated (via guaranteed re-read) a value proposition itself? There seem to be some minor benefits to a reload-required behavior. In-progress requests are guaranteed not to get half files from one revision and half files from another if the catalog request timing is particularly bad, since the user won't issue a reload command mid-file-update, and if they do puppet-server will flush in-progress requests anyway. Are those benefits worth considering proposal 2 for? Does this perspective make sense, or am I missing something? ~Reid On Thursday, March 5, 2015 at 6:42:34 PM UTC-8, 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 fairly sophisticated users and can deal with weird cache invalidation issues; since they're opting into this feature they should be prepared to deal with the ramifications. On Thu, Mar 5, 2015 at 5:19 PM, Owen Rodabaugh ow...@puppetlabs.com javascript: wrote: To clarify, I am asking for opinions on whether the default environment_timeout should be 0 or unlimited in future releases of puppet. The current plan is to default to unlimited. I'm concerned that shipping with this default assumes prior experience and will be another hurdle to getting started with puppet. Anecdotally I've heard that a common question in #puppet is I changed my puppet code, why isn't it showing when I do a test run?. Conversely setting environment_timeout=0 will result in lower performance, but no need to restart puppet or hit the API to flush a cache to see code changes. The users impacted by this are likely more experienced and would already be managing, or easily able to manage this setting if they had performance concerns or a pre-existing code deployment workflow. Thanks, Owen On Thursday, March 5, 2015 at 3:56:24 PM UTC-8, Trevor Vaughan wrote: Can you use inotify to invalidate the cache via the API call when selected files in your infrastructure change? It looks like you could do this directly from the core https://launchpad.net/inotify-java. You'll just want to queue them up a bit to not go crazy. 10 seconds should probably do it, but you could make that configurable. Trevor On Wed, Mar 4, 2015 at 4:36 PM, Owen Rodabaugh ow...@puppetlabs.com wrote: We've been discussing what the default environment_timeout setting should be. There is general agreement that the current 3 minutes is not great. It's both baffling to new users and does not bring in the full performance benefits. Two main perspectives on this: 1. Performance should be the primary driver and that the default of unlimited (cache never automatically refreshes) is preferred. This assumes most users have a code deployment workflow and tooling which can be adjusted to include the steps required to update the cache. These steps are either hitting the puppetserver environment cache endpoint, or restarting the service to cause the cache to update. 2. New user experience should be the primary driver and that a default
Re: [Puppet-dev] Default environment_timeout preference
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 15 minutes. However, I think the use of implementation terms like caching in describing the two proposed options clouds the water a bit, as both options result in clear and consistent behavior. Described without the term caching, option 1 effectively proposes that puppet-server should read all configuration files on startup (puppet.conf, auth.conf, fileserver.conf, environments/**/*.pp, etc.), and not automatically re-read any of these files unless the user issues an explicit `service puppet-server reload` command. Described without the term caching, option 2 effectively proposes that puppet-server should read some configuration files on startup (puppet.conf, auth.conf, fileserver.conf, etc.), and that puppet-server should read directly from disk all relevant files from environments/**/*.pp when compiling a catalog, once per agent request. It would also be clear and consistent to say that when a manifest is changed, those changes will start being reflected in catalogs emitted by the master within 3 minutes (or 1 or 20). The exact timing is not quite as predictable, but the behavior can still be given as a rule, and without using any variant of the word cache. Both proposals move strongly away from the problem behavior we have today - a clock-based timeout. Were this a new product, either option seems like it would satisfy principle of least astonishment. Both do move away from the default behavior of 3.7, but I don't see how you can support a claim that *either* option would provide *least* astonishment, particularly inasmuch as you also claim that a timeout is more astonishing than either of the other alternatives. I do not find it self-evident, for example, that most users would be more astonished that Puppet eventually notices manifest changes, than that they have to perform some kind of manual action separate from the change itself to make Puppet notice changes. The only difference between them, from an astonishment perspective, is that long-time Puppet users are accustomed to behavior resembling option 2 (though in the past implementation it's been more optimized, similar to the inotify suggestion put forth by Trevor). I disagree. Puppet has always required a restart to recognize changes to the Ruby code of server-side custom components, but that still throws people -- sometimes even people who should know better. Not every possible behavior is equally good or predictable, even when you start with a clean slate, even when you can state it as a clear and consistent rule. (And in particular, people seem pre-disposed to expect file changes to be recognized immediately.) I don't know that thinking about it this way changes anyone's opinion, but I do want to make sure we aren't getting hung up on implementation terms in considering what the actual proposed behaviors are. I don't think the discussion is (or need be) hung up on implementation terms. I think Adrien had it exactly right that most users will be less surprised by manifest changes taking effect immediately than by them not taking effect until some form of a `notice-my-changes` command is executed. Is having files live-updated (via guaranteed re-read) a value proposition itself? From a least-astonishment perspective, yes. From some other perspectives, too. There seem to be some minor benefits to a reload-required behavior. In-progress requests are guaranteed not to get half files from one revision and half files from another if the catalog request timing is particularly bad, since the user won't issue a reload command mid-file-update, and if they do puppet-server will flush in-progress requests anyway. You are right that those are issues for which reload-required behavior is a win, but not on least-astonishment grounds. Are you stepping back from your position that least astonishment is absolutely what we should be targeting? John -- 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/874f8f69-45c6-4034-b7c9-06005dc6f963%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Default environment_timeout preference
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 hidden gotchas. When people want to do performance tuning they're probably fairly sophisticated users and can deal with weird cache invalidation issues; since they're opting into this feature they should be prepared to deal with the ramifications. +1 Perhaps it would make sense for PE to be configured differently out of the box, but between the two options presented, Puppet's built-in default should be no caching. This feels quite a bit like consensus to me, I've filed https://tickets.puppetlabs.com/browse/PUP-4094 to track the change which should hit both in Puppet 3.8 and the Puppet 4 nightlies. Thank you Owen for kicking off the discussion, and thanks everyone for your thoughtful replies. Eric Sorenson - eric.soren...@puppetlabs.com mailto:eric.soren...@puppetlabs.com - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles -- 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/06737254-6A0C-4FB9-A6D9-85F979BD2572%40puppetlabs.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Default environment_timeout preference
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 live as opposed to read-on-start. On Fri, Mar 6, 2015 at 11:06 AM, John Bollinger john.bollin...@stjude.org wrote: 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 15 minutes. However, I think the use of implementation terms like caching in describing the two proposed options clouds the water a bit, as both options result in clear and consistent behavior. Described without the term caching, option 1 effectively proposes that puppet-server should read all configuration files on startup (puppet.conf, auth.conf, fileserver.conf, environments/**/*.pp, etc.), and not automatically re-read any of these files unless the user issues an explicit `service puppet-server reload` command. Described without the term caching, option 2 effectively proposes that puppet-server should read some configuration files on startup (puppet.conf, auth.conf, fileserver.conf, etc.), and that puppet-server should read directly from disk all relevant files from environments/**/*.pp when compiling a catalog, once per agent request. It would also be clear and consistent to say that when a manifest is changed, those changes will start being reflected in catalogs emitted by the master within 3 minutes (or 1 or 20). The exact timing is not quite as predictable, but the behavior can still be given as a rule, and without using any variant of the word cache. I'll cede consistent, but I continue to hold that clock-based behavior lacks clarity. The problem is not that the behavior can't be calculated, it's that to a new user experimenting with the product the clock-based behavior hinders their ability to engage in adjust/observe/iterate experimentation. If I'm trying to understand what a product is doing, I want to make a change and observe the result to see if the change I made did what I expected. I want confidence that if I make an adjustment and a change is observed, it is due to my adjustment. This is a feedback loop. The problem with a clock is that after I make my adjustment, there usually won't be any observed change immediately. But, there will be change later. At best, my feedback loop is delayed and it takes me longer to understand what's going on. More realistically, this kind of inconsistent feedback makes me frustrated with the product and don't have confidence that what I'm doing is having the expected effect. After I figure it out, I can work with it. Both proposals move strongly away from the problem behavior we have today - a clock-based timeout. Were this a new product, either option seems like it would satisfy principle of least astonishment. Both do move away from the default behavior of 3.7, but I don't see how you can support a claim that *either* option would provide *least* astonishment, particularly inasmuch as you also claim that a timeout is more astonishing than either of the other alternatives. I do not find it self-evident, for example, that most users would be more astonished that Puppet eventually notices manifest changes, than that they have to perform some kind of manual action separate from the change itself to make Puppet notice changes. My assertion that either option provides a least-astonishment experience is indeed built on a belief that clock-based system is Bad (TM), which I first took as a given. I've provided more context for why I believe this to be the case above. Even allowing that this assumption is incorrect, I still believe that option 1 and 2 are much more similar to each other in terms of first-time-user astonishment than either is to clock-based, since both give users consistent feedback. Users expect to have to restart or refresh most services if their configuration file(s) change. I have been considering puppet manifests similar to configuration files in this way. It sounds like most people would more intuitively consider manifests more like *.php files, or something to be *served*. The general opinion in this thread supports that. Given that starting point, I can see how it would be less astonishing to people if changes made to those files were immediately impactful, rather than requiring a reload. The only difference between them, from an astonishment perspective, is that long-time Puppet users are accustomed to behavior resembling option 2 (though in the past implementation it's been more optimized, similar to the inotify suggestion put forth by Trevor). I disagree. Puppet has always
