[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 th

[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 like

[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 a

[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, th

[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, an

Re: [Puppet-dev] Ephemeral Resources

On Thursday, December 8, 2016 at 9:29:00 AM UTC-6, Trevor Vaughan wrote: > > So, in theory, ephemeral resources would only have relationships on items > that need them for data and/or building purposes. > Meaning that ephemeral resources / shared_data will not have relationships at all, then?

[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 cl

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 > wrote: > > Let's be very careful here. I think part of the problem is that systemd >> and Puppet have slightly different idea

[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 t

[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++, r

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'] > * No

[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 least

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 duplicat

[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 unsubscribe

[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 > wrote: > >> >> On Friday, July 3, 2015 at 2:25:15 AM UTC-5, Chris Price wrote: >> >> >>> I have a question / thought experiment r

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, unt

[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

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: 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 mess

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 handl

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')}

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

[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 traversin

[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 ha

[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 ab

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 a

[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

[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 direct

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] 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 > proba

[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

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 n

[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 > , > I'd like to discuss the possibility and implications of autorequiring > parent direct

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. Un

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

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

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 *a

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,

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. F

[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 associa

[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 , the > host type has some serious issues. Major issues with the current design: > >1. The namevar: >- It's currently the canonical hostname. This means

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

On Monday, December 22, 2014 11:11:24 AM UTC-6, John Bollinger wrote: > > I went looking for holes to poke in this approach, and didn't find any. > Having just posted that, I thought of this: use of a Transition resource makes sense only if all the 'prior_to'

[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 >

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] 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 relyi

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 > wrote: > >> Additionally, avoiding hardcoded paths and avoiding the assumption that >> Puppet has a private Ruby to play around in will be help

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 m

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' =>

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 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 a

[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 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 th

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 > wrote: > >> >> >> On Nov 19, 2014, at 11:20 AM, Trevor Vaughan > > wrote: >> >> > Hmm...Facter and MCollective not being independently upgradable isn't >> super exciting.

[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 someth

[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" res

[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 lega

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 choos

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

On Tuesday, October 21, 2014 3:40:19 PM UTC-5, Felix Frank wrote: > > Hey everyone, > > thanks for your feedback. We appear to see some support for all options > except #1. That one is apparently universally despised. > > I'll try and summarize the discussion. Pros get a + plus and cons a - >

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

On Monday, October 13, 2014 6:13:53 PM UTC-5, Charlie Sharpsteen wrote: > > > On Thursday, October 9, 2014 3:10:55 PM UTC-7, John Bollinger wrote: >> >> >> >> On Thursday, October 9, 2014 9:12:41 AM UTC-5, Felix Frank wrote: >>> >>> So in respon

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 > O

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 > wrote: > > That depends heavily on how you characterize the problem. To me, the >> clash between packages of different types is primaril

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

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

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

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. Mo

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 > wrote: > >> >> >> On Thursday, March 13, 2014

[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 specif

[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. >

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 t

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? > >

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 notwithstandin

[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

[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

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: 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 t

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 > 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 >>&g

[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 > wrote: > >> Howdy, >> >> Henrik, David, Erik, John, and others have been having some pretty epic >> conversations around resource expressions, precedence, order of evaluation, >> a

[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 kno

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 > wrote: > >> On 2014-25-07 2:32, Andy Parker wrote: >> >>> >>> >>> DECISION SEVEN >>> >>>undef is not allowed as a title >>> >>> Not much to say h

[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 loo

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

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* -- b

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 > > 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 (about 30 lines): >> >>

[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 real

[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 >

[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

  1   2   >