[Puppet-dev] Re: Ephemeral resources

On Monday, April 16, 2018 at 10:38:55 AM UTC-5, Trevor Vaughan wrote: > > How difficult would it be to create a third type of resource which is an > 'ephemeral resource' whose only purpose is data collection on a host to be > used by some other collector? > > These items would not be part of

[Puppet-dev] Re: Has anyone already developed an Elasticsearch backend to Hiera?

On Saturday, March 31, 2018 at 5:59:12 AM UTC-5, nick@countersight.co wrote: > > Thanks for your response John, > > I appreciate you taking a quick look around to see if anyone else has > already done this. I had come to the same conclusion, that if someone has > already, they mostly

[Puppet-dev] Re: Has anyone already developed an Elasticsearch backend to Hiera?

On Wednesday, March 28, 2018 at 12:19:58 AM UTC-5, nick@countersight.co wrote: > > Hi, > > I'd like to be able to store (and more importantly) retrieve Hiera hash > data from Elasticsearch for my Puppet runs. Does anyone know if this has > already been done? > I haven't heard of such

[Puppet-dev] Re: Rspec giving no implicit conversion of Hash into String for an array

On Wednesday, August 16, 2017 at 11:51:30 AM UTC-5, James Perry wrote: > > I am getting an odd error when running rake spec on my module. The > functions work fine when setup in Puppet, but when I try to test it rspec > is kicking out an error about my $myarr arrays. When I comment it out,

[Puppet-dev] Re: So how exactly the immutable hashes are supposed to be used?

On Friday, July 14, 2017 at 9:52:37 AM UTC-5, Mariusz Gronczewski wrote: > > Hi, > > I've been slowly converting old 3.x codebase (which has seen days of > 0.24...) to 4.x and there is a lot of following pattern used for hashes:' > > $hash = { > "some" => "defaults" > } > >

Re: [Puppet-dev] Puppet 5 release planning

On Friday, March 24, 2017 at 5:09:31 PM UTC-5, Eric Sorenson wrote: > > Well, that was the whole collections idea in a nutshell, but every one of > those new repos would inevitably leave some people stranded on an old one. > Terrifyingly, there are still something like 100,000 hosts[1] hitting

Re: [Puppet-dev] Re: Draft for new type and provider API

On Monday, February 27, 2017 at 8:59:46 AM UTC-6, David Schmitt wrote: > > Hi folks, > > I've written down the design in README format now. This should make for a > easier to ingest from a module developer's perspective. Meanwhile I've also > had a shot at a hardcoded implementation of this,

[Puppet-dev] Re: Ephemeral Resources

On Wednesday, December 7, 2016 at 7:54:44 AM UTC-6, Trevor Vaughan wrote: > > I was looking through the puppetlabs-concat module as well as some of my > modules that have aggregation functionality and I realized that the catalog > really shouldn't be sending the intermediary resources to the

Re: [Puppet-dev] Re: Systemd vs RedHat service providers on is-enabled=static

On Monday, April 11, 2016 at 12:20:22 PM UTC-5, Michael Smith wrote: > > > > On Mon, Apr 11, 2016 at 8:35 AM, John Bollinger <john.bo...@stjude.org > > wrote: > > Let's be very careful here. I think part of the problem is that systemd >> and Puppet have sl

[Puppet-dev] Re: Systemd vs RedHat service providers on is-enabled=static

On Thursday, April 7, 2016 at 1:44:47 PM UTC-5, Michael Smith wrote: > > PUP-5353 notes an > inconsistency between the RedHat and Systemd providers (on EL7) in how they > treat the `static` state returned by `systemctl is-enabled`. > > Based on

[Puppet-dev] Re: Puppet RFC 23 - XPP Files

On Sunday, April 3, 2016 at 8:21:46 PM UTC-5, Henrik Lindberg wrote: In the long run, in general, we want it to be possible to express as > much as possible using the Puppet Language itself, and where that is not > practical, that it is easy to integrate an implementation (written in > c++,

Re: [Puppet-dev] Re: How strict do you want puppet to be?

On Wednesday, March 16, 2016 at 12:06:08 PM UTC-5, Hunter Haugen wrote: > > > On Thursday, February 25, 2016 at 7:45:46 PM UTC-6, Trevor Vaughan wrote: >>> >>> Sorry about that. >>> >>> What I mean is this: >>> >>> A -> [] -> B is not equivalent to A -> B since failures in A will not >>> affect

Re: [Puppet-dev] Re: How strict do you want puppet to be?

On Thursday, February 25, 2016 at 7:45:46 PM UTC-6, Trevor Vaughan wrote: > > Sorry about that. > > What I mean is this: > > A -> [] -> B is not equivalent to A -> B since failures in A will not > affect B. > > However, it would be equivalent to [A,B] which I am reading as A before B > but not

Re: [Puppet-dev] Re: How strict do you want puppet to be?

On Thursday, February 25, 2016 at 8:55:01 AM UTC-6, Trevor Vaughan wrote: > > Hmm. > > I think, as long as it is documented, then whatever behavior is > deterministic is fine. > ' > I think that there is value in the following resolutions: > > Notify['left'] -> [] -> Notify['right'] > *

[Puppet-dev] Re: Puppet 4: defined resource types and epp template

On Monday, February 1, 2016 at 12:15:12 PM UTC-6, henrik lindberg wrote: Contrast this with the inline_epp, which you can think of as a > lambda/code-block. Here the code block gets to see the variables in > scope, since it is itself in that scope (part of the same piece of code). > > Hmmm.

Re: [Puppet-dev] RFC - A specification for module schemas

On Sunday, January 31, 2016 at 2:37:53 PM UTC-6, Corey Osman wrote: > I think we have strayed off topic here. Being able to validate hiera > should be something that can easily be done by anyone no matter which > version of puppet they use. > I agree that being able to validate Hiera data

Re: [Puppet-dev] Re: using commands with generated path

On Monday, December 14, 2015 at 10:29:23 AM UTC-6, Felix Frank wrote: > > Hi, > > On 12/14/2015 04:12 PM, John Bollinger wrote: > [...] > > Nope. All the compiler does is make sure that all attributes you specify > are available for the resource type in question. &

[Puppet-dev] Re: using commands with generated path

On Friday, December 11, 2015 at 3:09:49 PM UTC-6, Corey Osman wrote: > > > > On Friday, December 11, 2015 at 10:49:40 AM UTC-8, John Bollinger wrote: >> >> >> >> On Friday, December 11, 2015 at 11:08:08 AM UTC-6, Corey Osman wrote: >>> >>&

[Puppet-dev] Re: using commands with generated path

On Friday, December 11, 2015 at 11:08:08 AM UTC-6, Corey Osman wrote: > > Hi, > > I am curious on a few things > > 1. Is the custom type code run on the node or master, makes sense the > provider is but not sure about the type code. > As I understand it, a custom type's own code -- or at

Re: [Puppet-dev] Re: utilizing custom type for fact values

On Friday, September 18, 2015 at 8:54:24 AM UTC-5, Trevor Vaughan wrote: > > Hi Kylo, > > I've never used this approach since I took the assumption that my facts > may be used outside of/before all of my Puppet manifests were fully > installed. > > It did, at times, dictate either code

[Puppet-dev] Re: Display the contents of a yaml file

Please don't cross-post the same question to puppet-users and puppet-dev. It is rarely appropriate. John -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To

[Puppet-dev] Re: 'application' is now a reserved word? wtf

On Thursday, August 13, 2015 at 9:57:31 AM UTC-5, Chris Rigby wrote: Hi, So I have a class called `application`, and literally hundreds of subclasses called `application::something` and now I've just learnt that 'application' is now a reserved keyword in a point release. (3.8.2).

Re: [Puppet-dev] Accessing variables from templates in wrapped defines

On Tuesday, August 11, 2015 at 12:39:49 PM UTC-5, Ryan Whitehurst wrote: Martin Alfke writes: How can I access the variable from the first define? I can change the second define to have another parameter so it knows about the template variable. Is there any other solution

Re: [Puppet-dev] Caching catalogs

On Tuesday, July 7, 2015 at 11:56:24 AM UTC-5, Trevor Vaughan wrote: I was thinking exactly the same as Eric. It seems like we're repeating what Git does. Perhaps I am too influenced by the last known good designation for something that in fact is *not* necessarily known to be good.

Re: [Puppet-dev] Caching catalogs

On Tuesday, July 7, 2015 at 10:28:42 AM UTC-5, Chris Price wrote: On Mon, Jul 6, 2015 at 3:55 PM, John Bollinger john.bo...@stjude.org javascript: wrote: On Friday, July 3, 2015 at 2:25:15 AM UTC-5, Chris Price wrote: I have a question / thought experiment related to this, and would

Re: [Puppet-dev] Caching catalogs

On Friday, July 3, 2015 at 2:25:15 AM UTC-5, Chris Price wrote: I have a question / thought experiment related to this, and would really love to hear some feedback from the community: What would you think about a setup where your master never saw any of your code changes at all, until

[Puppet-dev] Re: Default Puppet 4 settings for file locations

On Thursday, June 18, 2015 at 9:36:23 AM UTC-5, Chris Spence wrote: Whilst evaluating a move to puppetsever/puppet 4 I couldn't help but notice that the default location for 'vardir' has moved to /opt/puppetlabs/puppet/cache This is a bit worrisome, because that's not either /var or

[Puppet-dev] Re: puppet4 regressions or features?

On Thursday, May 14, 2015 at 5:59:49 PM UTC-5, Joshua Hoblitt wrote: It appears that classes are no longer a first class resource. Classes have *never* been a first class resource, though for a time there was a concerted effort to give that impression. John -- You received this message

Re: [Puppet-dev] Validation Resources

On Thursday, May 14, 2015 at 2:45:52 PM UTC-5, Trevor Vaughan wrote: Hmmwhat about a concept of deferred actions? I.e. Try this resource, can't do it, shove it (and it's dependencies) to the bottom of the stack and do everything else, then come back to it. Yes. If there's a

Re: [Puppet-dev] Re: Announce: Hiera 2.0.0 available

On Thursday, April 2, 2015 at 10:33:02 AM UTC-5, Thomas Hallgren wrote: John, The HI-14's requested behavior was not implemented as an afterthought. On the contrary. Since all facts have been available in the top scope since Puppet 3.5, there was simply no need for a specific handling

Re: [Puppet-dev] Re: Announce: Hiera 2.0.0 available

On Wednesday, April 1, 2015 at 5:17:54 PM UTC-5, Thomas Hallgren wrote: John, We're seem to be talking past each other here. The description in HI-14 mentions facts specifically and that too is available. I can declare this for instance: days_up: %{scope('system_uptime.days')} or

Re: [Puppet-dev] Re: Announce: Hiera 2.0.0 available

On Wednesday, April 1, 2015 at 9:01:52 AM UTC-5, Thomas Hallgren wrote: On 2015-03-31 14:57, John Bollinger wrote: On Thursday, March 26, 2015 at 8:24:30 AM UTC-5, John Bollinger wrote: Would someone please explain a little more about HI-14, though, and especially about how

[Puppet-dev] Re: Announce: Hiera 2.0.0 available

On Thursday, March 26, 2015 at 8:24:30 AM UTC-5, John Bollinger wrote: Would someone please explain a little more about HI-14, though, and especially about how the change implemented to fix that issue actually addresses it at all? The issue description is about traversing structured

[Puppet-dev] Re: SELinux and Puppet Subcommands

On Thursday, March 26, 2015 at 2:25:38 PM UTC-5, Melissa Stone wrote: The current pull request uses the following environment variables: - NO_PUPPET_SELINUX_DTRANS - PUPPET_SELINUX_MASTER_DOMAIN - PUPPET_SELINUX_CA_DOMAIN Maybe it's just a knee-jerk reaction, but I'm having

[Puppet-dev] Re: Announce: Hiera 2.0.0 available

On Wednesday, March 25, 2015 at 7:46:38 PM UTC-5, Kylo Ginsberg wrote: Hiera 2.0.0 is a new major version that includes several new features that expand Hiera's abilities. It also includes one breaking change so please read the release notes linked below. New features include the ability

Re: [Puppet-dev] Feature proposal: external environment locator (EEL)

On Thursday, March 19, 2015 at 6:19:19 PM UTC-5, Bostjan Skufca wrote: [...] This is the reason why I came up with the EEL idea. The more I think about it, the more natural it seems for puppet. Maybe it is just me. I'm afraid responses seem to indicate that it's mostly just you. Perhaps

Re: [Puppet-dev] Feature proposal: external environment locator (EEL)

On Wednesday, March 18, 2015 at 7:08:17 PM UTC-5, Bostjan Skufca wrote: On Monday, 16 March 2015 14:01:58 UTC+1, Daniele Sluijters wrote: Hi, It would really help if you elaborated on your use cases in this thread. I read the one message you linked but I'm still not sure about it and I

[Puppet-dev] Re: Feature proposal: external environment locator (EEL)

On Thursday, March 12, 2015 at 5:33:35 PM UTC-5, Bostjan Skufca wrote: On Thursday, 12 March 2015 20:30:23 UTC+1, John Bollinger wrote: On Wednesday, March 11, 2015 at 11:56:44 AM UTC-5, Bostjan Skufca wrote: Hi all, I would like to propose a new feature for puppet master: External

[Puppet-dev] Re: Feature proposal: external environment locator (EEL)

On Wednesday, March 11, 2015 at 11:56:44 AM UTC-5, Bostjan Skufca wrote: Hi all, I would like to propose a new feature for puppet master: External Environment Locator (EEL) The main objective would be to make locating puppet environment locations more flexible compared to directory

[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

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

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

Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources

On Tuesday, March 3, 2015 at 4:34:43 PM UTC-6, Stefan Schulte wrote: I am not saying that the current behaviour is correct/better or that your argument is invalid (you have a good point IMHO). I just wanted to point out that it is implemented for quite a while now and personally I am not

Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources

On Tuesday, March 3, 2015 at 3:55:44 AM UTC-6, Felix Frank wrote: On 03/02/2015 10:55 PM, Trevor Vaughan wrote: So, can I vote for adding '/validate_link = :boolean/' as a parameter to File to effect the state above? (/Is anyone else happy with this?/) Yes, this does appeal to me. I

[Puppet-dev] Re: Autorequiring parent directories to the home directory in user resources

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

Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources

On Tuesday, March 3, 2015 at 1:35:28 PM UTC-6, Stefan Schulte wrote: Hello On 02.03.2015 22:21, John Bollinger wrote: *Disadvantages to symlinks autorequiring their targets*: 1. Many unneeded resource relationships are generated. 2. Under some circumstances, Puppet

Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources

On Monday, March 2, 2015 at 1:50:08 PM UTC-6, Trevor Vaughan wrote: Well, there's my concrete example of where dangling symlinks are used in the wild Ok, back to autorequires. I'm still not convinced that it's beneficial to not have it in place. I am unlikely to persuade you if I

Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources

On Friday, February 27, 2015 at 2:51:03 PM UTC-6, Trevor Vaughan wrote: Ok, you certainly have a working counter example, but I feel that it *should* actually fail and that this is a bug. [...] I would like to propose that symlinks should naturally (i.e. autorequire*) come *after*

Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources

On Thursday, February 26, 2015 at 2:28:22 PM UTC-6, David Schmitt wrote: On 2015-02-26 20:31, John Bollinger wrote: Symbolic links do _not_ have the same kind of relationship with their targets. A link can be managed entirely independently of its target, therefore Puppet should

Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources

On Wednesday, February 25, 2015 at 6:06:33 PM UTC-6, Trevor Vaughan wrote: I think I filed a bug about this a while back. +1 for autorequiring targets I'm inclined to disagree. Autorequiring should be reserved for cases where the requirement is inherent in the resource's nature. Files'

[Puppet-dev] Re: The host type has unexpected behavior and is not idempotent

On Tuesday, January 27, 2015 at 10:02:06 PM UTC-6, Eli Young wrote: On Tuesday, January 27, 2015 at 2:53:46 PM UTC-8, John Bollinger wrote: As far as I can tell, it is a design characteristic of the current hosts file format that it associates each address with exactly one canonical

[Puppet-dev] Re: The host type has unexpected behavior and is not idempotent

On Monday, January 26, 2015 at 7:06:33 PM UTC-6, Eli Young wrote: As per PUP-3901 https://tickets.puppetlabs.com/browse/PUP-3901, the host type has some serious issues. Major issues with the current design: 1. The namevar: - It's currently the canonical hostname. This means that a

[Puppet-dev] Re: Dealing with transitional states in Puppet

On Friday, December 19, 2014 3:14:23 PM UTC-6, Reid Vandewiele wrote: This thread is introducing a simple workaround for an observed limitation in Puppet's ability to automate inelegant but real configuration requirements. The desired outcome is to get feedback on the suitability of the

Re: [Puppet-dev] Puppet 4 delivery and upgrades

On Sunday, December 14, 2014 4:25:51 PM UTC-6, Eric Shamow wrote: I think it’s worth asking the question of whether you want PL to spend their time building good CM software or dealing with and QA’ing the myriad combinations of Rubies and gems that they are currently forced to support

Re: [Puppet-dev] Modifying property names

On Thursday, December 11, 2014 10:22:41 AM UTC-6, Geoffrey Gardella wrote: Okay, I see. I can't add new keys while I am iterating, which makes sense. So, I need to create a new hash and then do a .merge when I'm done. No, you don't quite see. Puppet variables cannot (should not) be

Re: [Puppet-dev] Puppet 4 delivery and upgrades

On Wednesday, December 10, 2014 1:00:14 PM UTC-6, Jeff McCune wrote: On Wed, Dec 10, 2014 at 10:27 AM, John Bollinger john.bo...@stjude.org javascript: wrote: Additionally, avoiding hardcoded paths and avoiding the assumption that Puppet has a private Ruby to play around

Re: [Puppet-dev] Puppet 4 delivery and upgrades

On Thursday, December 11, 2014 3:34:17 PM UTC-6, John Bollinger wrote: If I cannot install Puppet into a Ruby installation of my choice (of sufficiently recent version) and have it work correctly, or if its installation alters the behavior of other software relying on that Ruby, then I

Re: [Puppet-dev] Puppet 4 delivery and upgrades

On Tuesday, December 9, 2014 12:58:01 PM UTC-6, Eric Sorenson wrote: We're not going to ship deb and rpm metapackages, to address the last points on the thread. We _will_ make it as easy as possible to build AIO with different combinations of component versions so you can compose your

Re: [Puppet-dev] Modifying property names

On Tuesday, December 2, 2014 4:53:42 PM UTC-6, Geoffrey Gardella wrote: Hey Josh, thanks for the reply. I'm still struggling with this. I have a hash of the values passed in from the manifest with the keys including '_' which need to be re-written. properties = {'john_wayne' = '1',

Re: [Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?

On Wednesday, November 26, 2014 12:03:09 PM UTC-6, Rob Reynolds wrote: Making a switch to non-authoritative would be in the realm of possibility for Puppet 4 given the short timeline. I think the group_membership resource type could be something that could be done at any time, and then

[Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?

On Friday, November 21, 2014 3:21:15 PM UTC-6, Rob Reynolds wrote: When we originally set out to do PUP-2628[1] for Puppet 4, we were going to change the group resource default to not authoritative for Windows (e.g. the specified members would be the minimum), because the thinking is that

[Puppet-dev] Re: Puppet 4 delivery and upgrades

On Friday, November 21, 2014 2:47:05 PM UTC-6, Eric Sorenson wrote: 5 - Why not use a metapackage which has no content of its own, but has requirements on specific versions of the other 'real' packages that contain the actual programs? • Avoiding a coordinated major version

[Puppet-dev] Re: Group Resource auth_membership defaults to true - should this change?

On Monday, November 24, 2014 9:37:38 AM UTC-6, John Bollinger wrote: purging. I think you still end up with a slightly leaky abstraction, in that only some systems have a concept of users' primary group, but support for that could and probably should be recast as a provider feature

Re: [Puppet-dev] Puppet 4 delivery and upgrades

On Thursday, November 20, 2014 9:38:35 AM UTC-6, Erik Dalén wrote: On Wed Nov 19 2014 at 8:36:46 PM Eric Sorenson eric.s...@puppetlabs.com javascript: wrote: On Nov 19, 2014, at 11:20 AM, Trevor Vaughan tvau...@onyxpoint.com javascript: wrote: Hmm...Facter and MCollective not

[Puppet-dev] Re: puppet-dev status the week ending 14-11-14

On Tuesday, November 18, 2014 3:35:25 AM UTC-6, Mike Hendon wrote: * Please note that some changes in puppet 4 mean that puppet 3 agents won’t be able to talk to puppet 4 masters (or vice-versa). This might cause an issue. I would suggest that the puppet RPMs are renamed to something

[Puppet-dev] Re: Improving the Resources Resource Type

On Wednesday, November 5, 2014 8:37:08 PM UTC-6, henrik lindberg wrote: Hi, I am bringing up this topic because of a recent discussion and PR for the ticket https://tickets.puppetlabs.com/browse/PUP-1486 Here is a recap. The Resources resource is used to manage unmanaged resources of

[Puppet-dev] Re: Leaving Puppet Labs

On Wednesday, November 5, 2014 11:28:23 AM UTC-6, Andy Parker wrote: This is one of the hardest emails that I've ever had to write, but the best way, I suppose, is to get the really hard part out of the way first. I've decided to move on from my time at Puppet Labs. My last day will be

[Puppet-dev] Re: The string to number torture never stops

On Friday, October 31, 2014 8:22:36 PM UTC-5, henrik lindberg wrote: [...] Yet again someone was bit by the automatic String to Numeric conversion that is in Puppet (and also in --parser future). I must confess to a certain dark amusement at Puppet struggling with its weak-typing legacy

Re: [Puppet-dev] How should apply behave under an ENC

On Tuesday, October 21, 2014 3:40:19 PM UTC-5, Felix Frank wrote: All things considered, we find ourselves in a fine position to choose our poison. There were more votes from the 2/2a camps, but also good points from RI in favor of 3. This leads me to believe that whatever we choose, a

Re: [Puppet-dev] Package duplicate resource issue - PUP-1073

On Friday, October 10, 2014 8:31:30 AM UTC-5, Drew Blessing wrote: I greatly favor anything else over making Package non-isomorphic. I completely appreciate what you're saying. However, I don't think this was the intent of the provider abstraction. It was intended to make the

Re: [Puppet-dev] Package duplicate resource issue - PUP-1073

On Thursday, October 9, 2014 6:36:49 PM UTC-5, Andy Parker wrote: On Thu, Oct 9, 2014 at 3:10 PM, John Bollinger john.bo...@stjude.org javascript: wrote: That depends heavily on how you characterize the problem. To me, the clash between packages of different types is primarily

Re: [Puppet-dev] Package duplicate resource issue - PUP-1073

On Thursday, October 9, 2014 9:12:41 AM UTC-5, Felix Frank wrote: On 10/08/2014 10:34 PM, Charlie Sharpsteen wrote: On Wednesday, October 8, 2014 11:51:32 AM UTC-7, John Bollinger wrote: On Wednesday, October 8, 2014 6:55:19 AM UTC-5, Felix Frank wrote: package

Re: [Puppet-dev] Removing types/providers from core

On Wednesday, October 8, 2014 5:46:31 AM UTC-5, Trevor Vaughan wrote: I agree with your assessment of what should stay and what should not with the exception of tidy and mount. Those two are not platform specific from what I can tell. I agree that Tidy is not platform-specific.

Re: [Puppet-dev] Package duplicate resource issue - PUP-1073

On Wednesday, October 8, 2014 6:55:19 AM UTC-5, Felix Frank wrote: On 10/08/2014 01:23 PM, Trevor Vaughan wrote: service { 'my_service': require = Package['mysql']{ :provider = 'gem' } } How about require = Package| title == 'mysql' and provider == 'gem' | I filed a feature

Re: [Puppet-dev] Package duplicate resource issue - PUP-1073

On Wednesday, October 8, 2014 1:43:09 PM UTC-5, Andy Parker wrote: My proposal allows package { 'mysql-gem': name = mysql, provider = gem, ensure = installed } package { 'mysql': ensure = installed } Such statements would have previously collided because both would have created a

Re: [Puppet-dev] Package duplicate resource issue - PUP-1073

On Monday, October 6, 2014 5:13:43 PM UTC-5, Andy Parker wrote: Sorry to resurrect an old thread, but this came to my attention again today. On Fri, Mar 14, 2014 at 6:20 AM, John Bollinger john.bo...@stjude.org javascript: wrote: On Thursday, March 13, 2014 8:50:19 AM UTC-5, Trevor

[Puppet-dev] Re: How should apply behave under an ENC

On Sunday, October 5, 2014 8:30:32 PM UTC-5, Felix Frank wrote: We're now looking for feedback on whether apply should get the same semantics, for masterless operation. There are three alternatives here that I can see: 1. Status quo - ruthlessly override whatever the ENC specifies.

[Puppet-dev] Re: Is this the right fix for PUP-1106?

On Wednesday, September 17, 2014 12:12:31 PM UTC-5, Andy Parker wrote: Adrien has put together a change to address PUP-1106 (failed dependencies are not honored on refresh), however this is a really thorny issue and I'd like to get some more eyes on it before committing to the change. I

Re: [Puppet-dev] Numbers and Representation - Lets talk about BigDecimal

On Thursday, September 11, 2014 8:24:13 PM UTC-5, Trevor Vaughan wrote: I'm voting for putting all your notes somewhere very easy to find in the future and then leaving everything the way it has been working. Agreed. If Puppet does not actually support BigDecimal now, then I don't think

Re: [Puppet-dev] Re: A question about numbers and representation

Thanks again, Ken. On Thursday, September 4, 2014 2:14:25 PM UTC-5, Ken Barber wrote: Thanks, Ken. Could you devote a few words to how PuppetDB chooses which of those alternative columns to use for any particular value, and how it afterward tracks which one has been used? So

Re: [Puppet-dev] Re: A question about numbers and representation

On Thursday, September 4, 2014 9:40:43 AM UTC-5, Ken Barber wrote: Every Puppet value is potentially a Big now. What new cost is involved? I'm having trouble seeing how a database can deal efficiently with Puppet's current implicit typing anyway, Big values notwithstanding.

[Puppet-dev] Re: A question about numbers and representation

On Wednesday, September 3, 2014 12:40:45 PM UTC-5, henrik lindberg wrote: On 2014-02-09 22:23, John Bollinger wrote: On Monday, September 1, 2014 3:55:03 AM UTC-5, henrik lindberg wrote: Hi, Recently I have been looking into serialization of various kinds

Re: [Puppet-dev] Facter version guarantees

On Saturday, August 30, 2014 3:10:14 AM UTC-5, David Schmitt wrote: Hi, I really like the points Eric, Wil and Henrik have brought up. Here're some more from me. On 2014-08-29 23:11, Kylo Ginsberg wrote: [Splitting this out of the original thread which was the Facter 2.2.0

[Puppet-dev] Re: A question about numbers and representation

On Monday, September 1, 2014 3:55:03 AM UTC-5, henrik lindberg wrote: Hi, Recently I have been looking into serialization of various kinds, and the issue of how we represent and serialize/deserialize numbers have come up. [...] Proposal I would like to cap a Puppet

[Puppet-dev] Re: Syntax of resource expressions (was: Decision: Near future of resource expressions)

On Tuesday, August 5, 2014 7:51:20 PM UTC-5, Andy Parker wrote: I'm pulling this discussion out into a new thread so that we can become more focussed. I'm also going to start a thread about one other topic that has been brought to my attention so that a decision can be reached. In this

Re: [Puppet-dev] Re: Decision: Near future of resource expressions

On Wednesday, July 30, 2014 4:21:37 PM UTC-5, Andy Parker wrote: On Wed, Jul 30, 2014 at 1:02 PM, John Bollinger john.bo...@stjude.org javascript: wrote: On Tuesday, July 29, 2014 1:23:09 PM UTC-5, Andy Parker wrote: On Thu, Jul 24, 2014 at 5:32 PM, Andy Parker an...@puppetlabs.com

[Puppet-dev] Re: Decision: Near future of resource expressions

On Tuesday, July 29, 2014 1:23:09 PM UTC-5, Andy Parker wrote: On Thu, Jul 24, 2014 at 5:32 PM, Andy Parker an...@puppetlabs.com javascript: wrote: Howdy, Henrik, David, Erik, John, and others have been having some pretty epic conversations around resource expressions, precedence,

[Puppet-dev] Re: Decision: Near future of resource expressions

On Friday, July 25, 2014 5:15:30 PM UTC-5, henrik lindberg wrote: We reasoned that we already have create_resources in frequent use to solve real issues, so it is needed. I don't think create_resources is used simply because you can. Instead, it is because you do not statically know the

[Puppet-dev] Re: Decision: Near future of resource expressions

On Thursday, July 24, 2014 7:32:13 PM UTC-5, Andy Parker wrote: Howdy, Henrik, David, Erik, John, and others have been having some pretty epic conversations around resource expressions, precedence, order of evaluation, and several other topics. What kicked all of that off was us looking

Re: [Puppet-dev] Re: Decision: Near future of resource expressions

On Friday, July 25, 2014 11:25:37 AM UTC-5, Andy Parker wrote: On Thu, Jul 24, 2014 at 6:04 PM, Henrik Lindberg henrik@cloudsmith.com javascript: wrote: On 2014-25-07 2:32, Andy Parker wrote: DECISION SEVEN undef is not allowed as a title Not much to say here. notify {

Re: [Puppet-dev] Metaparam Warning

On Monday, July 21, 2014 3:00:11 PM UTC-5, Andy Parker wrote: On Mon, Jul 21, 2014 at 10:37 AM, Nan Liu nan...@gmail.com javascript: wrote: I'm using puppet-system module and the usage of the schedule metaparameter is generating a large amount of warnings similar to the one below

Re: [Puppet-dev] Metaparam Warning

On Monday, July 21, 2014 3:32:47 PM UTC-5, Nan Liu wrote: https://github.com/erwbgy/puppet-system/blob/master/manifests/packages.pp Oh, I see. The class declares its *own* parameter 'schedule'. Given that I'm not sure offhand what the semantics of that will -- or even *should* -- be, I

Re: [Puppet-dev] Metaparam Warning

On Monday, July 21, 2014 3:32:47 PM UTC-5, Nan Liu wrote: Similar to the discussion of collect resources realize + override, I wish the metaparameters weren't magically passed to the resources, and we could choose to use them and pass the behavior on as needed. Sadly, it's not that

[Puppet-dev] Re: RFC2 - Resource Defaults

On Friday, July 11, 2014 9:50:47 PM UTC-5, henrik lindberg wrote: On 2014-11-07 10:55, David Schmitt wrote: [...] * 'Type| expr |' is the list of local resources of type 'type' in the current compilation where 'expr' evaluates true. As a side-effect, it realizes all

[Puppet-dev] Re: RFC2 - Resource Defaults

On Tuesday, July 8, 2014 3:16:46 PM UTC-5, henrik lindberg wrote: On 2014-08-07 18:09, John Bollinger wrote: I tried hard to not like this, but then I recognized how congruent it is -- or could be -- with one of my pet ideas: resource constraints. Felix implemented part of that idea

[Puppet-dev] Re: RFC2 - Resource Defaults

On Sunday, July 6, 2014 8:26:28 PM UTC-5, henrik lindberg wrote: Thank you everyone that commented on the first RFC for Resource Defaults (and Collection) - some very good ideas came up. I am creating a new thread because I wanted to take the Collection part in a separate discussion

[Puppet-dev] Re: RFC - Resource Defaults and Collection

On Thursday, July 3, 2014 8:29:48 PM UTC-5, henrik lindberg wrote: On 2014-03-07 22:57, John Bollinger wrote: Here's another idea: how about removing resource defaults altogether? My take on them has always been that their dynamic scope was their most important feature. If that's

[Puppet-dev] Re: RFC: Remove resource default support for classes?

On Friday, July 4, 2014 9:42:00 AM UTC-5, henrik lindberg wrote: Next up in the quest to understand and specify how defaults work / should work is the support to set class parameters via the resource default expression. You can do this, to set defaults on classes class a ($x) {

[Puppet-dev] Re: RFC - Resource Defaults and Collection

On Monday, July 7, 2014 9:39:06 AM UTC-5, henrik lindberg wrote: On 2014-07-07 15:43, John Bollinger wrote: [...] Consider: class mymodule { File { group = 'example' } } class mymodule::example { file { '/tmp/example': owner = 'root', ensure = 'file

Re: [Puppet-dev] Re: RFC - Resource Defaults and Collection

Here's another idea: how about removing resource defaults altogether? My take on them has always been that their dynamic scope was their most important feature. If that's going away then what's left is just a minor piece of syntactic sugar, and keeping them in that restricted form is certain

  1   2   >