Re: [Puppet-dev] metaparam question

Hi, this is me assuming the role of the weird secluded neighbor who sometimes yells incoherent ramblings over the fence. Although this is pertinent: For onlyif and friends, there is already https://tickets.puppetlabs.com/browse/PUP-1125, where John and I have already done some thoughtwork.

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

Hi, On 12/14/2015 04:12 PM, John Bollinger wrote: > So if I wanted to run some validation in the type code, where does > that get run? node or master? > > > > Validation and munging hooks for property and parameter values > definitely run on the master. If you try to specify an invali

Re: [Puppet-dev] Puppetconf 2015: pre-summit tea party

On 09/13/2015 10:17 AM, Erik Dalén wrote: > Want to join? Throw a +1 in the list so I get a rough idea of how people > are going to show. Count me in :-) -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and st

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

Oh my, you were relying on actual buggy behavior. https://projects.puppetlabs.com/issues/22800 Ah, the memories... :-) Cheers, Felix On 08/12/2015 09:00 AM, Martin Alfke wrote: > Hi Ryan, > On 11 Aug 2015, at 19:22, Ryan Whitehurst wrote: > >> > >> > Martin Alfke writes: >> > >>> >> How can

Re: [Puppet-dev] Handling failures in prefetch

Seconded! Cheers, Felix On 07/21/2015 10:05 PM, Trevor Vaughan wrote: > I like all the things you have said here. > > Trevor > > On Tue, Jul 21, 2015 at 3:40 PM, Branan Riley > wrote: > > > -- You received this message because you are subscribed to the Google

Re: [Puppet-dev] ensure property is always retrieve, even if useless

re property (it's > the case for Services, not for Files for example). > > Like Felix's patch, it doesn't break any tests and it doesn't break > puppet resource <...> (which uses collected resources) > > Can you confirm that this would work ? Do think i

Re: [Puppet-dev] PR Triage cancelled June 9th and June 16th

Hi, just realized that Bluejeans isn't free :) So we're doing the Google. https://plus.google.com/hangouts/_/grjkuzteifkqww7j5hcgviqqmia Feel free to hop in for a good time. Best, Felix On 06/16/2015 12:36 PM, Felix Frank wrote: > Hi, > > incidentally, I got some time

Re: [Puppet-dev] PR Triage cancelled June 9th and June 16th

Hi, incidentally, I got some time on my hands. I will therefor try and do an impromptu triage session in Bluejeans, but not for puppet! If you work on the puppet-community repos or have any floating PRs that you would like to discuss, then it would be great if you too have some time from about 10

Re: [Puppet-dev] Re: Announcing the Puppet Catalog Diff Viewer

On 06/02/2015 04:38 PM, Clayton O'Neill wrote: > I recently noticed that Zack Smith forked and has been maintaining > R.I.Pienaars' puppet-catalog-diff. This tool can now produce JSON > reports, which contain lots of interesting information, but are not > very readable for normal hu

Re: [Puppet-dev] Use of Puppet in cloud resource provisioning/management

On 03/27/2015 05:26 PM, Josh Pederson wrote: > For folks who utilize cloud environments (AWS, OpenStack, Azure, etc) in > your day-to-day continuous delivery (CD) and/or application deploys I'd > really appreciate any description of how you use Puppet in your process. Hi, I think you definitely w

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

On 03/23/2015 12:05 PM, Bostjan Skufca wrote: > I am not talking about changing configuration options themselves, nor > about changing how configuration file looks like (by, for example, > providing new sections). I am talking about marking configuration > settings as "basic" or "advanced" and then

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

On 03/19/2015 12:19 PM, Bostjan Skufca wrote: > > I think my note about suggesting git's way of providing "plumbing and > porcelain" interfaces as good approach still stands. I'm not so sure, actually. How exactly would you go about segregating the existing configuration options into two categori

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

On 03/19/2015 01:08 AM, Bostjan Skufca wrote: > - both agents request the same environment: one master returns the > whole system catalog, the other just bits to manage primary puppet I don't quite see why the agents would have to use identical environment names. Could you perhaps also approach yo

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

On 03/11/2015 05:56 PM, Bostjan Skufca wrote: > > I would like to hear your opinion about this, and whether this would > be useful for you. > Hi, I don't believe that such a feature would be useful to a majority of users, myself included. I do see two disadvantages to adding this: 1. It adds com

Re: [Puppet-dev] rspec and structured facts

On 03/10/2015 07:19 AM, Kylo Ginsberg wrote: > On Mon, Mar 9, 2015 at 8:21 AM, Raphaël Pinson > mailto:raphael.pin...@camptocamp.com>> > wrote: > > Hi Felix, > > By default, Puppet 3 stringifies all facts. And apparently, > "--stringify_facts false" does not work with puppet apply… >

Re: [Puppet-dev] rspec and structured facts

On 03/09/2015 04:21 PM, Raphaël Pinson wrote: > Hi Felix, > > > By default, Puppet 3 stringifies all facts. And apparently, > "--stringify_facts false" does not work with puppet apply… > > > Raphaël I see. Well that's a relief ;-) In a disturbing, not at all relieving way... Thanks again, Fe

Re: [Puppet-dev] rspec and structured facts

Hi, me I'm now utterly confused by how this (not) works in the wild. $ bundle exec puppet apply -e 'notice $os' Notice: Scope(Class[main]): {"name"=>"Debian", "family"=>"Debian", "release"=>{"major"=>"jessie/sid", "full"=>"jessie/sid"}, "lsb"=>{"distcodename"=>"sid", "distid"=>"Debian", "distdesc

Re: [Puppet-dev] Re: Modulepath and manifest in environment.conf should interpolate $environment too

On 03/09/2015 02:16 PM, Henrik Lindberg wrote: >> It would be splendid if we could define modulepath paths with >> $environment as variable part of path, like this: >> modulepath = /path/to/$environment/modules >> manifest = /path/to/$environment/manifest2/ >> >> Would there be any interest for thi

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 R

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

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

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

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/li

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

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 could even be persuaded that this could benignly default to true. -- You

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

On 02/27/2015 06:22 PM, Trevor Vaughan wrote: > I still can't come up with a scenario where this would ever be an issue. > > Auto-creating a resource (especially a directory) is a greater level > of spooky action at a distance since it's actually *doing* something > to your system and I'm very agai

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

Hi, thanks for building this. I must admit, I find the prospect a little frightening. The logic that picks the autorequire target makes sense, but I see quite some potential for surprising the user with weird dependency cycles. What I'd like to see instead would be for the user type to actually

Re: [Puppet-dev] Thoughts on Module Namespace Conflicts

On 02/10/2015 01:23 AM, Trevor Vaughan wrote: > 2) You have to create a separate environment for each host group > (potentially each host) that you want to have use the differing code. > >* Issue: This is a LOT of overhead for a couple of modules and may > have other ramifications in terms of p

Re: [Puppet-dev] Extending the File Type to allow setting an (Amazon Web Services) s3:/// URI

Hi, I'm working on a similar feature request in order to support http:// URLs. It's nigh complete: https://github.com/puppetlabs/puppet/pull/3372/files The code points you identified sound about right. On the other hand, you would have a much easier time building your own simple type in a modul

Re: [Puppet-dev] Need some rspec and ruby assistance please.

Hi, I don't fully understand the issue at hand, but it seems to me that specs like the one for the gem provider do something similar. https://github.com/puppetlabs/puppet/blob/master/spec/unit/provider/package/gem_spec.rb#L27 HTH, Felix On 01/05/2015 07:03 PM, James Perry wrote: > I am trying t

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

On 12/22/2014 07:55 PM, Reid Vandewiele wrote: > > And does the transitional state copy/inherit anything from the > target final state given for the named resource, or does it have > only the (explicit) attributes specified in the Transition resource? > > > Yes. Right now all attribute

Re: [Puppet-dev] comments on PUP-3765 (proper selinux service support)

On 12/17/2014 08:36 PM, Eric Sorenson wrote: > It was a sorta late-night conversation on IRC, and I was the proponent > of inheriting from the base providers, but I don't feel super strongly > that it's the right path. Conversation started here: > > https://botbot.me/freenode/puppet/2014-12-15/?msg

Re: [Puppet-dev] PUP-3116 AKA Global Queues

Hey, good points - state retention at whatever granular level would be a good general purpose tool to have. If it's built in a pervasive fashion (i.e., any provider might use the cache for whetever it deems appropriate), it gains added visibility and becomes more opaque to the user - which is a go

Re: [Puppet-dev] comments on PUP-3765 (proper selinux service support)

On 12/15/2014 10:18 AM, eric gisse wrote: > I'm opening this up to thoughts on how to do PUP-3765 > properly. Am I going > in the right direction or is there a better way? > > Note: stuff like separate providers was discussed and I hate it deeply > d

puppet-dev@googlegroups.com

On 12/05/2014 10:28 AM, Igor Galić wrote: > * directory needs to be created and chowned to the correct user > * udev|devfs entry needs to be made and udev needs to be reloaded > > the first case is easy and platform independent (i.e.: it works on all Unix > platforms equally, and traffic server on

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

On 11/24/2014 04:37 PM, John Bollinger wrote: > A (say) Group_membership resource type could allow group membership to > be expressed the same way for all systems, and it would dovetail > nicely with the new ideas for client-side queries and resource > purging. I think you still end up with a slig

Re: [Puppet-dev] Use of private in module skeleton

On 11/22/2014 01:22 PM, Gareth Rushgrove wrote: > Hey all > > I'd love some feedback on this PR, which adds the private function to > the puppet-module-skeleton that a bunch of people use. > > https://github.com/garethr/puppet-module-skeleton/pull/43 > > A few people commented on Twitter and it's p

Re: [Puppet-dev] Puppet PR Triage starting in 30 minutes

Hi, I think this is a great way of handling this. It liberates us from the secondary queue that was the notes document, getting dragged from one week to the next. In fact, I think it would be even better to do away with the whole notion of holding over PRs. Instead, we could now quite easily 1. V

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

On 11/20/2014 12:17 PM, Daniele Sluijters wrote: > First question is, can you gracefully deprecate a line of agents, i.e. > retain 3.x agent compatibility throughout 4.x masters, and drop it > at 5.0. > I shall assume that the engineering effort to go such a route would > be a

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

On 11/18/2014 08:04 PM, Eric Sorenson wrote: > 4. We are planning to break cross-major-version compatibility over the > network. The amount of change we need to support in order to keep moving > components to the Puppet Server and out of Ruby is the main driver for > this, but generally, if you can

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

On 11/05/2014 06:46 PM, Andy Parker wrote: > I get the impression that the general consensus here (and has been > expressed in other threads) is in favor of consistency of behavior > across the applications even when it might cause some pain for some > users because of different usage patterns. Tha

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

On 11/14/2014 07:09 PM, Henrik Lindberg 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 probably > means you don’t want to be updating puppet itself with “ensure => latest” :) > Hi, point taken, but

Re: [Puppet-dev] Setting log levels in puppet.conf

On 11/04/2014 10:46 PM, Josh Cooper wrote: > 2. Change --test to imply --debug instead of --verbose I don't think this is an option. Many users are likely in the habit of using --test whenever actually testing or even manually running the catalog from the master. The percentage of those that woul

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

On 11/07/2014 05:59 AM, Luke Kanies wrote: >> To get a behavior that matches today's resources type, we'd need to >> > explicitly query unmanaged resources. >> > >> > User<~| managed == false |~> { ensure => absent } >> > >> > This has the advantage of being more explicit about the unmanaged part

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

On 11/06/2014 12:04 PM, Luke Kanies wrote: > A fourth option would be to combine the best of Resources and exported > resources: Build a querying system akin to exported resources, but > against the current system, rather than against the catalog. Or really, > take the exact same querying we alre

Re: [Puppet-dev] Leaving Puppet Labs

Hey Andy, best of luck on whatever it is that you're going to tackle next. See if you can hop into the occasional hangout :) You'll be missed on those. Cheers, Felix On 11/05/2014 06:28 PM, Andy Parker wrote: > This is one of the hardest emails that I've ever had to write, but the > best way, I

Re: [Puppet-dev] Re: Question about Puppet 3.7 -- where in the code does it read directory environment contents (modules, manifests, and environment.conf)?

On 10/28/2014 10:52 PM, Joshua Partlow wrote: > > And what terrible thing will happen if I simply keep 'certname' > disabled? > > > The master will end up using a default certname, which I believe will > consist of the 'hostname.domain' returned by facter. Yeah. From experience, it relies

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

file - leaving normal puppet apply test.pp type behaviour as > is. Either way they would enable the masterless mode used to manage the > machine > using a special set of steps and those steps would include enabling an ENC > > So for me at least if I configure apply to use an ENC then t

Re: [Puppet-dev] Platform Team Week of October 6th, 2014

On 10/09/2014 09:24 PM, Andy Parker wrote: > I'm waiting with baited breath for the conclusion :) Then I hope you're in Portland these days, so that someone can check your vital signs occasionally ;-) -- You received this message because you are subscribed to the Google Groups "Puppet Developer

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

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 { 'mysql-gem': package_name => mysql, prov

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

On 10/08/2014 03:23 PM, Trevor Vaughan wrote: > > If you go with the descriptive namevar, you'll need to make the > separator something that won't show up in a package name. So probably > one of '+/,|' etc... That's not what I'm saying. I'm saying let the namevar no longer be the package name at

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

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' |> Not that it matters - having two Package[mysql] resources will *never* be a thing. If I understa

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

Hi there, agree with most of this, see comments below. On 10/08/2014 04:36 AM, Daniele Sluijters wrote: > > I would also keep resources, notify, stage and schedule around and the > filebucket because of how they influence Puppet's behaviour and the > behaviour of other resources. I'm not sure a

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

On 10/07/2014 04:05 AM, Britt Gresham wrote: > I think we should do 2a because there should be rough parity between > the configuration files and the command line arguments. We should > do 2 or 2a because as John says, Puppet should, "Stop getting in my > way!" > > > I think that

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

Hi all, when we recently fixed a regression that had to do with directory environments and ENC (PUP-3258) I noticed that the handling is weird when the ENC actually picks an environment for the local machine. As far as I can tell, puppet apply ignored that until now. The apply command used the co

Re: [Puppet-dev] Overriding inheritance variables. How to make a redefinition of variable inheritance class?

Hi, this type of question would be better suited for the puppet-users list. The problem is that variable values *cannot* be overridden. You just replace its value in the scope of the inheriting class. Only resources can be overridden, so that is what you must do. class generic { $message = '

Re: [Puppet-dev] Core Pull Request Triage time / format

On 10/01/2014 04:01 AM, Kylo Ginsberg wrote: > * a later-in-the-day time (so US East Coast people could chime in > after work) *mumble, grumble* Well, I guess that would free up my Wednesday every other week... ;-) > * pre-announced focus for triage sessions (or ad-hoc sessions?) Not sure what p

Re: [Puppet-dev] Auto*

On 09/23/2014 10:08 PM, Trevor Vaughan wrote: > More importantly, when I want to notify a service *but it might not > exist*, I need autonotify because the Puppet DSL doesn't allow me to > not care if a resource exists. Hey Trevor, are you trying to goad me into speaking out for the defined() fun

Re: [Puppet-dev] Auto*

On 09/23/2014 09:19 PM, David Schmitt wrote: >> >> Are you sure we want that? Are you sure *you* do? ;-) > > "We only supply the guns, people kill people." Then this is us I guess: https://soundcloud.com/nightvaleradio/25-one-year-later-1#t=08:55 ;-) -- You received this message because you a

Re: [Puppet-dev] Auto*

On 09/23/2014 08:47 PM, Trevor Vaughan wrote: > Sitting here at PuppetConf and I just added a PR for the ability to > use autorequire, autobefore, autonotify, and autosubscribe to > custom/native types. > > https://tickets.puppetlabs.com/browse/PUP-3331 > > It worked during my testing, but anyone t

Re: [Puppet-dev] PR Triage canceled today

On 09/17/2014 04:57 PM, Kylo Ginsberg wrote: > Sorry for the late notice, but Ethan and I are both working hard on > our PuppetConf talks. As always, feel free to ping one of us on IRC re > any PRs in flight or other questions. > > And looking forward to seeing some of you next week in SF! > > Kylo

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

On 09/17/2014 07:12 PM, 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 think the original bug in r

Re: [Puppet-dev] Puppetlabs Firewall

Hi, this is more of a puppet-users question, actually. On 09/10/2014 04:16 PM, Marco wrote: > firewall { '000 drop all except TCP 22': > action => 'drop', > iniface => 'eth0', > proto => '! TCP' > port => ['! 22'], > } This would not do what you thi

Re: [Puppet-dev] Re: Announce: nightly repos available

On 08/28/2014 06:17 PM, Henrik Lindberg wrote: > We really hope that the puppet4 and facter2 branches were a special > circumstance. It is not our intention to have long running feature > branches. As soon as 3.7.0 is released, the puppet4 branch will be > merged to master, and the puppet4 branch w

Re: [Puppet-dev] Re: Facter version guarantees

On 08/30/2014 01:00 AM, Henrik Lindberg wrote: > API is really what we define it to be. > IMO, values should be included. Agreed. Facter.value() is very generic and unlikely to undergo any drastic changes soon (I assume). But it really forms the heart of the API, as far as I'm concerned, and the v

Re: [Puppet-dev] Noob question structure and calling a class

Hi, this question would be more appropriate on the puppet-users list. I suspect that the cause for your issue got lost during anonymization. Does the module/subdirectory/class name contain some unusual character outside the [a-zA-Z0-9_] range? On 08/28/2014 01:25 AM, Abel Paz wrote: > in using e

Re: [Puppet-dev] Some attention for PUP-1515

Hi, such things can be hard to crack. Could this be related to https://tickets.puppetlabs.com/browse/PUP-731 ? In that case, almost impossible to fix right away. Sorry, Felix On 08/08/2014 04:17 PM, Miguel Di Ciurcio Filho wrote: > Hello folks, > > Could someone give some attention for PUP-1515

Re: [Puppet-dev] Presenting a custom error message if source file in module does not exist

On 08/02/2014 07:55 AM, Craig Barr wrote: > TL;DR How do I output a custom error message for a failed assertion that > a source file exists. In other words, how do I display a nice error > message when puppet:///modules/mymodule/mysourcefile.txt does not exist Hi, this feels like more of a puppet

Re: [Puppet-dev] how to comment and uncomment lines in a file with puppet

On 07/24/2014 05:05 PM, Supriya Uppalapati wrote: > *Please help me* While I'm not averse to that, I really think you should renew your inquiry to the users list. Cross-posting is frowned upon, and this is not a development issue. Best, Felix -- You received this message because you are subscri

Re: [Puppet-dev] RFC - Grammar quirks I want to remove...

On 07/18/2014 09:47 AM, Peter Meier wrote: >> Can we get rid of this, it is bad enough that all other keywords >> > can be used (if, unless, case, class, define, etc. etc.) > Couldn't we ban them as well? I think in most other "programming" > languages this won't work as well. I second this. >> >

Re: [Puppet-dev] Puppet PR Triage Notes 2014-06-18

On 06/18/2014 08:49 PM, Andy Parker wrote: > 2756: (PUP-1177) make sure ssh_known_hosts is not created with mode 0600 > - Some questions about windows, but Peter thinks it should be fine Yes, also even though the provider is not restricted to *NIX explicitly, I doubt that it will be functional o

Re: [Puppet-dev] Re: Solving `if defined(Resource['name'])`

On 06/19/2014 03:13 AM, Trevor Vaughan wrote: > It just so happens that you can manipulate the catalog once applied to > the system in various parts of custom types and I've hacked around > this a bit by creating random resources as necessary in the past. Yes, I cringed. "Well" done ;-) I stand b

Re: [Puppet-dev] Re: Solving `if defined(Resource['name'])`

On 06/18/2014 12:56 PM, Trevor Vaughan wrote: > e) Use the new proposed magic => Woo, it "just works" if *anything* in > the catalog includes 'firewall'. This way, if I don't want it, I don't > get it in an intuitive fashion. FWIW, I can see this happen rather easily with a metaparameter like f

Re: [Puppet-dev] Re: Solving `if defined(Resource['name'])`

Hi, putting on my manifest design philosopher's hat :-) On 06/18/2014 04:11 AM, Trevor Vaughan wrote: > It does get hairy when you mix the callbacks with the reverse > dependencies. I can see having to iterate over the stack (mesh?) and > check for loops and correctness while doing so. It could c

Re: [Puppet-dev] Platform Team Week of June 2nd, 2014

On 06/10/2014 05:37 PM, Andy Parker wrote: > I feel like we've been falling behind in our pull request handling. > The hangouts on Wednesdays have been a great forum for talking over > and making decisions about them, but we haven't been too great about > actually following through all of the time.

Re: [Puppet-dev] Pull request triage - 2014-06-04

On 06/06/2014 09:31 AM, Brice Figureau wrote: >> - dubious value, and other higher priority work on environments >> > ongoing > I can't help thinking I fell in a trap. Why open a ticket, asking for a > contribution on the mailing list, if nobody thinks it's a good idea. I > spent a bit of time co

Re: [Puppet-dev] Help debugging Ruby 2.0 issue

On 05/27/2014 06:05 PM, Trevor Vaughan wrote: > https://www.onyxpoint.com/storing-puppet-provider-metadata-for-single-instance-application/. > > However, I've run into a bit of an issue with Ruby 2 in that I can't > determine the proper method for keeping this technique properly > functional and g

Re: [Puppet-dev] Notes from Puppet PR Triage for 2014-05-14

On 05/21/2014 08:43 PM, Eric Sorenson wrote: >> Discussion: can we add `unless` and `onlyif` as metaparameters for all >> resources? Discussion outcome: ...maybe? >> > > That's interesting, how did this come up? Where did the discussion leave off? > I'm interested because it's an old, highly vot

Re: [Puppet-dev] Constraints beta

Hi, you're giving me some interesting ideas. Note that the constraint approach mainly concerns itself with module interoperability, and I do believe that the problem you are describing is orthogonal to that. I could see something like this take shape if you manage to combine the autorequire feat

Re: [Puppet-dev] ensure property is always retrieve, even if useless

Hi, necro-bumping yet another thread, I took another stab at that old problem. I molded Jeff's approach into a form that I hope to be more palatable. It does not break any tests that I have tried (which is not saying it won't break any whatsoever). https://github.com/ffrank/puppet/tree/dont-alwa

[Puppet-dev] Constraints beta

Hi, hoping to reach some of the more prolific module authors via this list, I'm most pleased to announce the initial release of the constraints module at https://forge.puppetlabs.com/ffrank/constraints I shall try and reach even more authors via the users' list in time, but if some early adopter

Re: [Puppet-dev] Rubygems in Puppet modules, revisited

On 04/28/2014 05:45 PM, R. Tyler Croy wrote: > class { > 'jenkins' : > require => Package[mygem]; > } > > This iwll require *two* Puppet runs to operate correctly, one to install the > gem properly, and the second to load the gem properly into the Puppet runtime > environment. > > T

Re: [Puppet-dev] Environment Caching - RFC

On 04/21/2014 11:29 PM, Henrik Lindberg wrote: > > * Any use cases you feel strongly about? Scenarios we need to consider... Following the ongoing discussion, I start to feel that we are really setting ourselves up for quite some additional pleas for help on the mailing lists. Whenever people whi

Re: [Puppet-dev] Re: Environment Caching - RFC

On 04/22/2014 02:59 PM, Henrik Lindberg wrote: > On 2014-22-04 8:06, Thomas Hallgren wrote: >> Would a MANUAL strategy make sense? I.e. instead of rebooting the >> master, just tell it to clear the cache (perhaps per environment). >> >> - thomas >> > > We discussed that - either as a command, or b

Re: [Puppet-dev] Can I make my entire module "depend" on rubygems being installed?

On 04/20/2014 03:52 AM, R. Tyler Croy wrote: > Warning: Puppet.features.rubygems? is deprecated. Require rubygems in > your application's entry point if you need it. >(at /usr/lib/ruby/vendor_ruby/puppet/util/feature.rb:17:in `add') > Failed to load feature test for rubygems: no such file to lo

Re: [Puppet-dev] Puppet Templates - RFC

On 04/16/2014 08:53 PM, Andy Parker wrote: > Another way to improve it would be if the % and-or <> flags were > passed to the ERB builder. % enables Ruby code processing for lines > beginning with %. <> omit newline for lines starting with <% and > ending in %>. They would allow you

Re: [Puppet-dev] Constraints

Thanks for all the positive feedback, guys. Trevor raises some interesting points, but I guess Andy has it right by proposing that we should let this unfold outside the core until we deem it ready. I have some code on hand to hook us into the transaction, but as always, building tests is the hard

Re: [Puppet-dev] Same methods in two providers - how to optimize it?

On 04/17/2014 02:27 PM, Jakov Sosic wrote: > Hi, I'm forwarding my question from puppet-users because it didn't get > many answers there... Dude. That was yesterday. Evening. Impatient much? ;-) Also you apparently sent this in response to an answer in the Heredoc RFC thread, which is very bad fo

Re: [Puppet-dev] Notes from PR triage 2014-04-16

On 04/16/2014 08:29 PM, Andy Parker wrote: > Joined: Alex, Andy, Felix, Henrik, Joshua, Kylo, Rob, Adrien, Brian Actually, I was there only in spirit - it was Bowling night, sorry ;) Happy Easter and hope to catch you guys next week. -- You received this message because you are subscribed to th

Re: [Puppet-dev] Constraints

On 04/15/2014 03:01 AM, Andy Parker wrote: > I'm wondering if there is a way of either doing this in a module (do > the constraint check in a provider), or if there is a change we can > make to allow this to be in a module. It would be great to be able to > have the extension points so that these k

[Puppet-dev] Constraints

Hi, bumping an old thread with a some news: I've built a proof-of-concept implementation of John's constraint scheme. Enjoy: https://github.com/ffrank/puppet/tree/constraints I'd be grateful for any feedback. Constraints can currently be added as normal resources to a manifest as shown in the REA

Re: [Puppet-dev] Re: Best practices for ensure property values

On 04/02/2014 01:11 AM, Felix Frank wrote: >> Are hashes as property values out of the question? > I'll go on a limb and answer this with a strong affirmative ;-) Good lord... More to the point: Hash values in and of themselves are fine. Not for ensure though, and especially not

Re: [Puppet-dev] Re: Best practices for ensure property values

On 04/01/2014 08:41 PM, Robin Bowes wrote: > Are hashes as property values out of the question? I'll go on a limb and answer this with a strong affirmative ;-) Good lord... As for held vs. hold, I guess John's points have more merit than mine after all. I vote to keep held out of ensure. It rea

Re: [Puppet-dev] Re: Best practices for ensure property values

Hi, well, no and no. The "hold" state is (to my knowledge and at least pertaining to apt/dpkg) independent of the installation status. I can remove a held package, it just won't update to a newer version. Even if we were to keep 'held' as an ensure value, this would even still work thanks to the

Re: [Puppet-dev] Re: Best practices for ensure property values

On 04/01/2014 01:44 AM, Trevor Vaughan wrote: > I have to say that I like 'hold' better than 'held' based on the way I > would actually read this. Right, and I don't agree about John's point about property names. There are counter-examples that work very well like service/enable, file/purge, file/

Re: [Puppet-dev] Re: Best practices for ensure property values

Hi, On 03/28/2014 08:14 PM, Jesse Hathaway wrote: > > If you allow the resources file { "/tmp": } and directory { > "/tmp": } to > coexists, you are bound to face trouble. Since both represent the same > file system entry, puppet should handle them with exactly one > resource.

Re: [Puppet-dev] Re: Best practices for ensure property values

On 03/28/2014 04:01 PM, Jesse Hathaway wrote: > Thanks for pointing out this definition. I think asking whether an > ensure parameter models a fundamental aspect of a resource is a > helpful litmus test for what values an ensure parameter should have > for a resource. Nitpick: Ensure is universall

Re: [Puppet-dev] We're changing the module community triage/meeting date and time!

On 03/18/2014 05:18 PM, David Schmitt wrote: > Hi, > > am I correct that 10:00 PST is this: > http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140320T10&p1=137 > ? > > Regards, David Nope :) What you linked to is summer time aka Daylight Saving time. PST is in fact *not* summer time b

Re: [Puppet-dev] non-unique resource names: systemd user services, ssh keys

On 03/18/2014 10:20 AM, David Schmitt wrote: > # parse user "flubb" from title, comment will be "power_key" > "flubb: power_key": > ensure => present, > key=> "..."; This kinda made me frown. What would this manifest express then: Ssh_authorized_key { ensure => present, us

Re: [Puppet-dev] Re: The 4x scope

On 03/17/2014 05:25 PM, John Bollinger wrote: > https://jira.puppetlabs.com/browse/PUP-731 > ? > > > > Yes, though the issue description seems to focus on types rather than > functions. The title mentions functions, and the issue is basically

Re: [Puppet-dev] non-unique resource names: systemd user services, ssh keys

On 03/17/2014 08:41 AM, David Schmitt wrote: > as a follow-up to the recent non-unique package name discussion, I've > noticed two further instances where this is a problem: > > * ssh_authorized_key, which is has only the comment ("name") as > namevar. This is obviously easy to avoid in prac

  1   2   >