Re: [Puppet-dev] metaparam question

[Felix Frank]

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.


Now two years have passed, and I'm a little overwhelmed by the prospect 
of building yet another complex feature (intense fretting going on over 
here). Don't hold your breath I guess? But if anyone wants to grab it, 
I'll be glad to offer whatever limited guidance I can muster.


Cheers,
Felix

On 03/03/2016 02:24 PM, Trevor Vaughan wrote:
It really seems like we want the logical extension of the Exec checks 
on all resources with additional validation.


service { 'httpd':
  ensure => 'running',
  onlyif => '/usr/bin/probe_remote_mysql', # or 'unless'
  validate => "curl -k http://${::fqdn}/service_check.html;,
  # Ok, magical asynchronous fact update here with an ACL (ponies and 
unicorns area)

  fact_update => {
'my_unique_name' => 'w00t',
# ACLs would need to be processed server side. Let's not give the 
nodes too much power here...

# This could, perhaps, be a server setting.
'acl' => {
  'allow' => $::domain,
  'deny' => 'ALL'
}
  }


  class { 'thing_that_needs_apache':
onlyif => fact_fetch('my_unique_name', 'w00t') # 
fact_fetch(, )

  }

With the async updating of facts, and individual ACL restrictions, you 
get some really neat capabilities in terms of fine grained process 
control.


Thinking about this further, you'll probably need caching proxies for 
the fact updates though.


Maybe Puppet 8 :-D.

Thanks,

Trevor




--
You received this message because you are subscribed to the Google Groups "Puppet 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5771B7F0.4050409%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 invalid value
> then catalog building will fail.  I don't recall whether they run again
> on the node.

Nope. All the compiler does is make sure that all attributes you specify
are available for the resource type in question.

All hooks are invoked by the agent. Yes, the whole catalog will fail
before any resource is checked or synced, but that's because validation
etc. is run at the very start of the agent transaction.

>  The reason why I am asking because not only do I want to validate
> that the user specified a absolute path, but also verify the file
> exists.  But this would only work if the File.exists? method in the
> validate block for the type code is executed on the node.
> 
> 
> 
> This is not a job for a validation hook, but your provider can perform
> such a test at whatever point is appropriate, and fail the resource if
> need be.  Since it is conceivable that the file of interest might itself
> be managed by Puppet, this also seems like a textbook case for an
> autorequire
> 
> -- /that/ would appear in the type, not the provider.

Agreed! Validation should be a function that yields the same result for
the same input in any circumstance.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/566EEE5F.8040009%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/55F705B4.3050200%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 r...@puppetlabs.com 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 available?
  It's not exactly the same, but this works now, using EPP instead of ERB: 
 Many thanks for pointing to EPP.
 We can not yet switch to EPP.
 We want our example42 modules to be compatible with puppet 3 and 4 and will 
 do a version bump very soon offering new language features..
 
 Besides this:
 when I saw this construct (accessing variables from another module(!! sic)) 
 my in-brain puppet parser already went nuts.
 I decided to add the variable as parameter which makes it now far more clear 
 where the value is taken from.
 
 Best,
 Martin
 
 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/55CB3699.2030805%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Handling failures in prefetch

[Felix Frank]

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 bra...@puppetlabs.com
 mailto:bra...@puppetlabs.com wrote:

 This is email 2/2 inspired by PUP-4813


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/55B00796.7040308%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

Hi,

thanks for picking this up.

I think what really needs discussing is
https://github.com/puppetlabs/puppet/pull/4038#issuecomment-119290626

I'm not sure what kind of breakage specifically Jeff noticed in
https://groups.google.com/forum/#!msg/puppet-dev/P8ReCHvmd2o/tuhzAM86wbYJ

Perhaps this is about collections of exported resources using Service|
| ? Could you make sure that still works with and without ensure
attribute set in those?

Any other ideas what might have been the issue? For all we know, the
cause might have been resolved upstream in the meantime, but it would be
nice to be sure.

Thanks,
Felix

On 07/16/2015 09:06 AM, Romain F. wrote:
 Hello,
 
 Necrobumping again this thread. Felix's wishes have been granted in
 PR-4038 https://github.com/puppetlabs/puppet/pull/4038 (PUP-4760
 https://tickets.puppetlabs.com/browse/PUP-4760) but this change is bit
 tricky/risky apparently.
 
 The original goal was to not retrieve ensure property status when we
 don't ask to. This need a change in Puppet::Type's retrieve method.
 Before the change in PR-4038
 https://github.com/puppetlabs/puppet/pull/4038, it was
 programmatically creating a ensure property when nothing is specified
 and if the type is ensurable, so it was always retrieving the ensure
 status.
 
 The change in the beginning of this thread was adding another condition
 to this : if the type is ensurable and if the ensure property have a
 should attribute.
 
 The change in PR-4038 https://github.com/puppetlabs/puppet/pull/4038
 is just skipping the creation of the ensure property when nothing is
 specified and if the type can continue without a ensure 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 it can be extended to
 some other types ?
 
 Cheers,
 
 Romain
 
 
 
 
 Le lundi 5 mai 2014 02:16:33 UTC+2, Felix Frank a écrit :
 
 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-always-retrieve-service-ensure
 
 
 So, if you guys could give it a spin, that would be awesome.
 
 Also, a ticket would be helpful, but if you can confirm that this works
 and helps, I can open one on your behalf so we can make a PR for this.
 
 Cheers,
 Felix
 
 On 12/19/2013 11:39 PM, Jeff Bachtel wrote:
 
  In the end, even just the behavior change to puppet resource
 makes
  the patch a non-starter because it is a widely used feature.
 
  I understand this feature should be kept, but that a pity this
 should
  impact other even more useful feature like apply or agent.
 
  Could it be possible that puppet resource and other like
 apply or
  agent retrieves only what they need? In apply/agent case, this
 come
  from a transaction being applied. For puppet resource I assume
 this
  is not the case. Could method parameter solve this case? And this
  could even keep the compat if this param is not specified
 
 
  I spent all day (because my Ruby is bad) doing a proof of concept
 with
  this. It touches type.rb and indirector/resource/ral.rb to add a
  seemingly transparent method variable flagging whether ensure should
  be ignored for the purpose of retrieving resources. It defaults to
  false (don't ignore ensure), which should cause the speedup Aurelien
  is needing. The resource RAL indirector is aware of the method
  parameter and sets it to true (ignoreensure), thereby exhibiting the
  old behavior when puppet resource is called from the command line.
 
  There is a nasty bit that I'm unsure of in the retrieve_resource
  method. I discovered that when running puppet agent -t --noop, if I
  tried to use my newly defined method parameter that parsing would
  choke - apparently in that state the retrieve method is targeting
  another method. I worked around it by putting in a rescue statement
  and falling back to the old way of calling retrieve which should,
  eventually, still hit the retrieve with Aurelien's improved
  conditional logic.
 
  Anyway, please find attached a diff containing the changes in
  question. Feel free to refine and submit it as a PR, my Ruby really
  isn't up for my doing so myself.
 
  Jeff
 
 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https

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

[Felix Frank]

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 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:30 PDST (i.e. 19:30 CEST or 17:30 UTC). It will last
 for about an hour, perhaps more if some of you do show up :-)

 If this works out, I will share the link to the call in this space.

 Cheers,
 Felix

 On 06/08/2015 05:46 PM, Kylo Ginsberg wrote:
 Hey folks,

 We're in a crunch time, getting puppet 4.2.0 and facter 3.0 out the
 door, so we're going to cancel the next two Tuesday PR triage sessions
 for puppet/puppet-server/facter/hiera.

 We'll resume June 23rd as usual.

 Thanks for your patience and keep those PRs coming!

 Cheers,
 Kylo

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/55805D90.5080802%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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:30 PDST (i.e. 19:30 CEST or 17:30 UTC). It will last
for about an hour, perhaps more if some of you do show up :-)

If this works out, I will share the link to the call in this space.

Cheers,
Felix

On 06/08/2015 05:46 PM, Kylo Ginsberg wrote:
 Hey folks,
 
 We're in a crunch time, getting puppet 4.2.0 and facter 3.0 out the
 door, so we're going to cancel the next two Tuesday PR triage sessions
 for puppet/puppet-server/facter/hiera.
 
 We'll resume June 23rd as usual.
 
 Thanks for your patience and keep those PRs coming!
 
 Cheers,
 Kylo

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/557FFC3C.9030204%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 human beings.
 
 I've been wanting to use the tool for Puppet environment preflight,
 and so I made a web interface to display and analyse those JSON reports.
 
 The project can be found (and forked)
 at https://github.com/camptocamp/puppet-catalog-diff-viewer
 https://github.com/camptocamp/puppet-catalog-diff-viewer and a
 live demo is available
 at http://camptocamp.github.io/puppet-catalog-diff-viewer/
 http://camptocamp.github.io/puppet-catalog-diff-viewer/. The code
 is pure Javascript (using Bootstrap and d3js) and doesn't store any
 data whatsoever, so feel free to test your own reports on the interface.
 
 The tool also allows to ack diff information (all data are loss when
 you reload the report though) to help filter out the information.
 
 
 I think this is a fantastic idea.  We use catalog diffs extensively as
 part of our pre-merge testing.  

Agree, fantastic approach.

Any chance of merging this capability into Puppet Explorer and/or
puppet-board?

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/556DD0E9.80907%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 want to take this to the broader audience at
puppet-users.

Best,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5515857D.1050300%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 using this discriminatory
 value when writing (or generating) documentation.

Yes, that is what I was thinking. What I'm saying is, I don't quite see
which existing configuration settings would belong in column A and which
in B (documentation-wise).

But I've got to say, Trevor has put it quite aptly. Will have to put
more thought into this.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5511E90C.8030603%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 categories? I don't feel that the interface lends
itself well to that.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/550DC03A.20608%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 your problem by making the
secondary agent use environment-meta or something in that vein?

 - on puppet masters server this means duplicate environment
 data/module repository clones

But does the secondary agent even require a substantial amount of data
and modules etc.?

 - puppet is a power tool, and irresponsible users that rush
 into using it, should not stand in the way of progress

 Again, that's just a thing you can say. It sounds very impressive,
 but what does it mean and how does it apply to reality?
 Irresponsible users or not, we're the ones that get flack for it,
 that need to support it, that have crying users and get a bad name
 because Puppet nuked my system. It will never be their fault, it
 will always be the fault of the system.


 Huh? :)
 Users that have systems in production they do not understand, and then
 slapping puppet on top of it using modules they do not understand,
 bricking the service (or the system) and yelling Puppet nuked my
 system belong to the h(w)all of f(sh)ame, and not to the
 decision-making process about puppet features. Please do not take this
 personally or as offensive, as I am having a rather nice chuckle here,
 with many analogies springing up on this is the tool's fault, not
 mine subject :)

There is such a thing as UX engineering. You seem to be under the
impression that it is about catering to mediocre technicians. That is
just not true.

Anyhow, I think everybody has understood that you intend to add this
functionality for use by the most advanced users only, but if this
includes but 10% of all users, and only an insignificant percentage of
those has any use for this whatsoever, then the value of maintaining it
upstream appears unimpressive.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/550A1D81.800%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 complexity, of which there is no shortage as far as
environments are concerned, at least that's my gut feeling.
2. It adds configuration options, so there is additional complexity for
the end user as well.

I'm not saying we should remove as many configuration settings and
options as possible, but we shouldn't go overboard with new ways for
users to shoot themselves in the foot.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/550213D9.1090305%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] rspec and structured facts

[Felix Frank]

On 03/10/2015 07:19 AM, Kylo Ginsberg wrote:
 On Mon, Mar 9, 2015 at 8:21 AM, Raphaël Pinson
 raphael.pin...@camptocamp.com 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…
 
 
 For any boolean setting, --some_boolean false doesn't work, and you
 instead need to use --no-some_boolean.
 
 So in this case, this seems to work:
 
 puppet apply --parser=future --no-stringify_facts -e 'notify{
 ${os['name']}: }'
 
 Kylo

Excellent. Works for me now. Not yet sure what that implies for
rspec-puppet.

Thanks Kylo!

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54FEB541.4040902%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 this feature?
 If this is implemented for modulepath setting, maybe it should be
 appropriate to implement it for manifest setting too?

 
 This scares me a bit. It looks like it has potential to open the can of
 worms known as dynamic environments we managed to put the lid on with
 directory environments. Will have to discuss if this can used to do
 harmful things. If allowed it could only be allowed inside an absolute
 path.

Agreed, there might be security implications.

I also fail to see the value in that. Do you mean to allow an
environment to extend itself to a whole different file system tree?
Wouldn't that just be horrible for organizing things?

Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54FDA5FD.3020504%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] rspec and structured facts

[Felix Frank]

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,
distdescription=Debian GNU/Linux unstable (sid),
distrelease=unstable, majdistrelease=unstable}}

OK, but

$ bundle exec puppet apply -e 'notice $os[name]'
Error: os is not a hash or array when accessing it with name at line 1
on node hypnos.mpex.net

$ bundle exec puppet apply --parser=future -e 'notice $os[name]'
Error: Evaluation Error: The value 'name' cannot be converted to
Numeric. on node hypnos.mpex.net

This is Puppet 3.7.3. Please tell me I'm Doing It Wrong.

Thanks,
Felix

On 03/09/2015 03:54 PM, Johan De Wit wrote:
 Again , I'm loosing the fight
 
 When i split up my rspec, it works, but the demo test always fails,
 There is something I overlook.
 
 Maybe someone else sees my mistake ??
 
 https://github.com/witjoh/rspec
 
 Grts
 
 Johan

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54FDB897.204%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] rspec and structured facts

[Felix Frank]

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

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54FDBB25.2040800%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

On 03/06/2015 02:45 PM, Trevor Vaughan wrote:
 file { '/export': ensure = 'directory' }
 file { '/export/home': ensure = 'directory' }
 user { 'foo': home = '/export/home/foo' } # This probably needs to come
 after /export/home, otherwise the user will get a nasty surprise when
 they first login
 
 Sure, I *can* create the user without having the directory in place. But
 what good does that do anyone?

Ah, a misunderstanding. It had actually not occured to me that users
might manage the $HOME dir as a file resource as well, and that we
should autorequire that. I'm all caught up in autorequiring the parent.

And yes, both these things do make sense. I see no issues with adding
the relationship to either homedir or parent. (It's parent+1 that makes
no sense, but we agree on that as well).

Thanks,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54F9B3CA.7030700%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

On 03/06/2015 12:20 PM, Trevor Vaughan wrote:
 
 If, for some reason, /export/home was *not* controlled by Puppet, then I
 would want User['foo'[ to autorequire /export as well as /export/home.

Hi Trevor,

I see your example, but don't really see the value in requiring /export.

If /export/home appears through a mount, then the user should make the
User require the mount resource explicitly, not its mount point. If
there is no mount resource (autofs), then requiring the mount point adds
comparatively little safety, at the cost of complexity and potential
surprises.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54F9A1D6.8060107%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Puppet 5 changes

[Felix Frank]

On 03/06/2015 05:30 AM, Eric Sorenson wrote:
 There are two main areas of change, both related to continuing to move 
 server-side functionality into Puppet Server: the certificate authority and 
 the network stack.  There may be other semver-major breaks that get rolled 
 in, but at this point we're planning to deliberately NOT have language 
 changes that would necessitate revising modules.

I guess that means that dynamic scoping of resource defaults will have
to linger until Puppet 6, yes?

This is not necessarily a problem - depending on how fast we get to
Puppet 5, we may not even have the solution ready in time, anyway.

On the other hand, I dearly hope that no Forge module currently relies
on dynamic scoping.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54F9CD7B.4060006%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Puppet 5 changes

[Felix Frank]

Seconded. For debugging purposes, the webrick master is still useful as
well.

On 03/06/2015 06:04 PM, Trevor Vaughan wrote:
 I was going back and forth on this and I have to agree with John.
 
 There have been several times where I pushed out a lightweight Puppet
 server on a VM running 512M RAM, 1 CPU, just to try something in a
 'production-like' scenario.
 
 I'm OK with losing Rack support, but a lightweight server instance is
 great for testing.
 
 Trevor
 
 On Fri, Mar 6, 2015 at 12:01 PM, John Bollinger
 john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote:
 
 
 
 On Thursday, March 5, 2015 at 10:30:47 PM UTC-6, Eric Sorenson wrote:
 
 My hypothesis is if you're just dipping a toe in the water to
 try out Puppet, running standalone with `puppet apply` is
 probably going to work better than a webrick agent/server setup.
 
 
 
 I'm doubtful of the validity of that hypothesis.  The use cases for
 `puppet apply` tend to be different from the use cases for agent /
 master.  If I wanted to try out Puppet for a scenario in which agent
 / master was the appropriate choice, or especially if the agent /
 master setup itself were part of what I wanted to evaluate, then
 `puppet apply` would simply not be a good alternative.
 
 As light-duty as webrick may be, it has the virtue of being
 extremely easy get up and running.  I'm not specially tied to
 webrick itself, but I think Puppet benefits from having a
 lightweight, out-of-the-box server option.
 
 
 John

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54F9DFE0.7010503%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

Since we're winding down :)

As nobody seems to love generated resources as passionately as I do
(it's OK, we still have each other), I would still ask for a compromise:
Autorequire does make sense, but can we tone it down?

As I understand it, the following resource

user { 'foo': home = '/var/lib/vendor/toolset/vendor-tool' }

will autorequire either
File['/var/lib/vendor/toolset']
File['/var/lib/vendor']
File['/var/lib']
or
File['/var']

which is a bit much for my taste. Autorequiring the immediate parent
only would make more sense to me.

Thanks,
Felix

On 03/03/2015 10:38 PM, Trevor Vaughan wrote:
 Indeed, I too apologize for the complete tangent!
 
 And, as would be expected, I'm for the autorequires since it does what I
 would expect it to do.
 
 Which, again, is counter to what John wants ;-). But, that's my answer
 to the original question.
 
 Thanks,
 
 Trevor
 
 On Tue, Mar 3, 2015 at 3:37 PM, John Bollinger
 john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote:
 
 
 
 On Wednesday, February 25, 2015 at 5:41:19 PM UTC-6, Raphaël Pinson
 wrote:
 
 Hello,
 
 
 As per Kylo's comment in PR for PUP-4036
 
 https://github.com/puppetlabs/puppet/pull/3645#issuecomment-76032829,
 I'd like to discuss the possibility and implications of
 autorequiring parent directories of the home directory for user
 resources.
 
 As stated in the PR, the idea came from stumbling upon a code
 like this one:
 
 file { '/srv/home': ensure = directory }
 file { '/home': ensure = link, target = '/srv/home' } - User | |
 
 
 where it made a lot of sense that all users should just
 autorequire the nearest parent directory to their home directory.
 
 What are your thoughts on this feature?
 
 
 
 My sincere apologies for my part in what I now recognize as taking
 this thread off on a tangent.  The lively discussion we had,
 however, did allow me to frame my general position on
 autorequirements, which is that they should be implemented only when
 they are directly indicated by the nature of the resource.  If User
 resources /can/ be applied without first applying the File resources
 representing their home directories, then there should be no
 autorequirement.
 
 
 John
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Puppet Developers group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to puppet-dev+unsubscr...@googlegroups.com
 mailto:puppet-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 
 https://groups.google.com/d/msgid/puppet-dev/b8d5e560-9357-4d8f-8234-3b593d9be246%40googlegroups.com
 
 https://groups.google.com/d/msgid/puppet-dev/b8d5e560-9357-4d8f-8234-3b593d9be246%40googlegroups.com?utm_medium=emailutm_source=footer.
 
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54F98667.5040505%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54F5851B.10804%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 against that when possible. (It also
 bloats your catalog, but that's not as much of an issue).

I don't agree. You are not changing the system, you are changing
Puppet's behavior (towards being more consistent, I believe).

Another contrived example of an issue that could arise:

user { 'apprunner':
home = '/opt/vendor/main-app',
}

file { '/opt': owner = 'sysadmin' }

user { 'sysadmin': require = User['apprunner'] }

Yes, unlikely that such a require would be used. It might emerge from
class interdependencies, though, as part of a larger cycle.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54F36D7C.7060605%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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
spawn a file resource that manages the home directory when managehome =
true is in use.

There would be some perks to such an approach:
1. This would be backwards compatible (manifests that contain the home
directory will keep the resource from being generated again)
2. You get the autorequire for free (from the very file resource)
3. If issues arise, the user is presented with a very clear message
about just what resource just blew up in their face.

The key would be the additional resources generator. I did something
similar to the naginator types a while ago.

Cheers,
Felix

On 02/26/2015 12:41 AM, Raphaël Pinson wrote:
 Hello,
 
 
 As per Kylo's comment in PR for PUP-4036
 https://github.com/puppetlabs/puppet/pull/3645#issuecomment-76032829,
 I'd like to discuss the possibility and implications of autorequiring
 parent directories of the home directory for user resources.
 
 As stated in the PR, the idea came from stumbling upon a code like this one:
 
 file { '/srv/home': ensure = directory }
 file { '/home': ensure = link, target = '/srv/home' } - User | |
 
 
 where it made a lot of sense that all users should just autorequire the
 nearest parent directory to their home directory.
 
 What are your thoughts on this feature?
 
 
 Cheers,
 
 Raphaël

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54F0A279.20006%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 performance as you get up in number.

Hi,

call me slow, but is this not the exact problem that users of r10k do
*not* face?

Yes, I've never tried it, for shame.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54DBE144.8030606%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 module. Have you looked into available modules such as

https://forge.puppetlabs.com/branan/s3file

Having the support in the core file type is mainly useful if you expect
to require regular checksum based probes for upstream changes etc.

HTH,
Felix

On 01/22/2015 01:26 PM, Peter Foley wrote:
 Hi,
 
 I am looking for some guidance on how easy it might be to add a new
 source type to the File puppet type in the puppet code base.
 
 Essentially it would work something like:
 
 |
 node 'aws-ec2-instance'{
   file {/etc/puppet/secure/keys/private_key.pkcs7.pem:
 owner  =puppet,
 group =puppet,
 mode   =0400,
 *source **=s3://myorg-puppetmaster/hiera-eyaml.key*
   }
 }
 |
 
 (I assume that this would run locally on the agent aws-ec2-instance'
 and not the puppetmaster.  So the agent could leverage the credentials
 provided by the IAM role).
 
 Using the AWS SDK for Ruby it seems like it would be straight forward to
 add to puppet.  However I am new to the puppet code base (and have
 limited Ruby programming experience).
 
 I have been trying to find areas of the code base I think I would either
 need to modify or add files to.  Here is a list of files I believe I
 would need to extend:
 
 https://github.com/puppetlabs/puppet/blob/master/lib/puppet/file_serving/terminus_selector.rb
 
   * Add the new s3 terminus
 
 https://github.com/puppetlabs/puppet/blob/master/lib/puppet/indirector/request.rb
 
   * Update set_uri_key to detect the new s3 URI scheme
   * Make changes to do_request?
 
 
 https://github.com/puppetlabs/puppet/tree/master/lib/puppet/indirector
 
   * Add a new s3.rb file describing how to interact with the s3 service
 
 
 Is there other areas I would need to modify?
 
 Is this something that would ultimately make it into the application?
 
 I have looked
 at https://docs.puppetlabs.com/guides/install_puppet/from_source.html is
 there any other good references (blog posts) which would assist with
 developing puppet.
 
 Thanks,
 
 Peter

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54C0F09F.7030100%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 to add some functionality to the HP-UX user provider module.
  In the past I was able to submit changes that allowed it to check for
 trusted computing and find the password crypt properly.  Unfortunately,
 even through the password was updated, HP-UX was not resetting the
 password age back to 0 days.  I have the commands required to do that
 and the rspec tests work fine on HP-UX boxes, it fails elsewhere as I am
 using specific commands to test and get data. 
 
 I still cannot seem to wrap my head around what is passed in and how to
 use rspec to verify the function works on HP-UX without trying to run
 the command.
 
 I know the trusted method fails to Trusted, I have not fixed that yet as
 I am trying to figure out how to properly code it so that I can override
 it in rspec to make sure nothing else is broken.
 
 What I have added to the modify command works by checking if the HP-UX
 server is trusted or not by running the trusted method.  
 
 I am completely confused on the right ways to make rspec work with the
 code.  I know the code works on the HP-UX hosts without issue, so that
 part is functional, I just cannot test it with rspec on Linux. 
 
 Any help / suggestions would be greatly appreciated! 

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54AAD67F.3020803%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 defaults in the transition resource are
 inherited from the target final state resource. Now that you mention
 it I can imagine that this might not always be the desired behavior,
 so it could make sense to introduce a parameter that affected whether
 or not the transitional state had this implicit relationship to the
 target state. The current behavior was mostly chosen for convenience.
 I'd be curious to think through a specific scenario where the
 difference was important. One doesn't spring to mind immediately for
 me. Obviously it's possible already to be explicit about many/all
 attributes in the transition declaration.

I would prefer for the transition to operate only on the properties that
are specified.

Using your original example, it would be very confusing for the user to
observe the transition manage the enable property of Service[myapp]. I
have not looked at your code, so I don't know about the specifics and
how feasible this behavior is, but this would be my ideal design.

Speaking of properties - transitions for classes and defines don't seem
to make sense to me, because they don't have properties, only
parameters. Sure, the compiler could try and figure out what property
values are influenced by a given parameter, but that seems very complex
to me, both in terms of implementation and user experience.

Generally, I will join the chorus - this feature shows amazing promise!

Thanks,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5498C462.3010603%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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=27586083page=4

Awesome, thanks for that link, Eric. I didn't read it all right now,
honestly, but the first pages give a good introduction.

So while we're in wishlist mode, how about this: Since the requirement
is so pervasive, would it not be nice to extend
Puppet::Provider::Command in such a way that
 * it is aware of whether Puppet is in a SElinux environment
 * providers can specify whether run_init is required or forbidden for a
given command
 * the command behaves accordingly, no change to its invocation from the
provider needed

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54920709.6000206%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 good thing, and addresses one of the major concerns
I'm having with this. The other being that it needs to be tunable for
the user in some fashion.

I have no qualms about disk I/O - after all, the user can choose
whatever block backend they want. Users who depend on low latency or
need to save IOPS can employ a tmpfs, for example.

Cheers,
Felix

On 12/17/2014 12:56 AM, Trevor Vaughan wrote:
 I'm happy with catalog lifetime.

 I'm really not happy with doing anything that involves disk I/O.

 This would be key to getting providers to be able to save state in a
 non-hacky way as well.

 Trevor

 On Tue, Dec 16, 2014 at 6:45 PM, Michael Smith
 michael.sm...@puppetlabs.com mailto:michael.sm...@puppetlabs.com
 wrote:

 I don't like any of the ideas I raised, but this will take some
 digging. We need to determine what life-time the cache should
 have, and what interface. I'm leaning towards either a cached read
 API in the FileSystem utilities, or a cache tied to the catalog
 lifetime.


-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5490D048.7020702%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

On 12/15/2014 10:18 AM, eric gisse wrote:
 I'm opening this up to thoughts on how to do PUP-3765
 https://tickets.puppetlabs.com/browse/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
 due to maintainability/usability concerns. Keeping it in the provider
 feels like the way to go, I'm just having a bit of an issue with a
 proper implementation. 

Hi,

where was this discussed? The ticket has no comments and no links.

A separate set of providers seems undesirable to me as well. We would be
looking at a) lots of code duplication or b) a layer of inheritance that
serves a pretty weak purpose.

The question of is SELinux enabled or not is independent of which
tool chain should be used to manage OS services. Anyway, I see no
reason why anyone would not want any given provider to Just Work,
SELinux or not.

What is your implementation's approach and what issues are you facing?

Thanks,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/548F5A2A.3060408%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Handling Interdependent Files in a typeprovider

[Felix Frank]

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 only runs on Unix, so it's fine ;)
 
 the second case however is more problematic as it means we need to keep two
 syntactically distinct files in sync. it also means that we need to verify, 
 and
 possibly recreate that secondary file if *nothing* in the primary file at all
 has changed.

Hi,

I'm not sure that I fully understand a problem, but if at all possible,
I like to try and solve such things by generating additional resources.
The idea is roughly:
* add a generate hook to the trafficserver_storage type
* make it invariably generate a file resource for the directory
* depending on the agent platform, it can
 * generate file resources for the udev config
 * generate a service resource for the udev refresh

If the user manages any of those in their own manifest, the respective
resource will not be added to the catalog. This might be problematic, of
course. For the service reload, but you might be able to accomodate
using Trevors autonotify hooks.

As for the files, those might fail silently (fail only if the manifest
manages a state that is not sufficient for your type's needs;, otherwise
it will Just Work). You might want to raise exceptions if the files are
managed already, so that the user is aware of possible trouble. (You
could even inspect the resources in the catalog and raise very specific
problems that the user can address in their manifest.)

HTH,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5481894B.8040603%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 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.  On such systems, the Group_membership resource would manage
 only secondary groups, just as User.groups does now.

+1 would use. :-)

We can even avoid a breaking change - yay for deprecations.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5473B1EC.8050203%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 prety much 50/50.

 https://twitter.com/garethr/status/535526875477839872

 And I'm on the fence too. Any thoughts?

 Gareth

+1 for helping module authors help their users avoid shooting their own
feet.

That's what this is about, right?

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5470F145.4090604%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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. That line of reasoning
 leads in the direction of option 3, I believe, which is what puppet
 apply currently does.

 Does puppet currently emit a warning or other message that it is
 ignoring one environment in favor of the environment from the ENC? If
 not maybe that would be enough to clarify what is happening.

Well, there is still no clear consensus that I can see, but there has
been no negative feedback regarding the proposed shift towards option 3.

I shall try and prepare a PR towards implementing it. Please raise any
more concerns or veto before Wednesday, when it will hopefully be triaged.

Thanks,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5467E757.2050904%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 what will the update plan look like for a large
installation? Will users be required to incorporate MCollective or
similar to be able to upgrade their agents?

Or should they try making all their agents update themselves until each
last one won't talk to the master again, which can then be safely updated.

The latter will not fly.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/546646E0.8030302%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 than
  
  resources { 'user': purge = true }
 Agreed.
 
 We do need some way to make it clear that this query happens on the client, 
 rather than on the server, and then the catalog needs some way to store that 
 query.
 
 The only other way to do it would be to have the server be able to do 
 real-time queries against the client, but I think that would have too many 
 crazy consequences.
 
 It’s been a long time, but I seem to remember trying to treat the resource as 
 a query; something like:
 
 user { *:
   uid = 100,
   purge = true
 }
 
 But I think this is not the right answer.
 
 Maybe something like:
 
 user { | uid  100 |:
   purge = true
 }
 
 Then the title is the query, and the parameters get applied to all resources 
 that match that title.
 
 Thoughts?
 

I think I would prefer a mix of both approaches:

user { 'arbitrary-purger-title':
match  = | uid  100  !managed |,
ignore = | title == sysmaint |,
ensure = absent,
}

This would have the benefit that the user can

exec { 'tidy-all-home-dirs: require = User['arbitrary-purger-title'] }

at the expense of more metaparameters, putting restraints on type
authors wrt. attribute names that they can use for their own types.
Hell, we have at least one core type that uses ignore even today.

So perhaps a more dedicated syntax like

user { 'arbitrary-purger-title':
| uid  100  !managed |,
...
}

has more merit.

On 11/07/2014 05:39 AM, Luke Kanies wrote: On Nov 7, 2014, at 2:02 PM,
Joshua Hoblitt jhobl...@cpan.org wrote:
 How would make use of that information on the agent if expressions are
  evaluated on the master?  As an example, I'd like to be able to 'query'
  the home dir of a role account (without having to install a fact) and
  interpolate it into a string to form a path.  I've always found this
  scenario a bit frustrating as the type has the data I want; it's just
  inaccessible while the catalog is built.
 As others have mentioned, the only way this is possible is if we find
a way to send the query down to the client.  We need different queries
for different locations, but hopefully similar enough that it doesn’t
like a completely different system, like it is today.

There be dragons.

System entities are queried at the start of the agent transaction at the
moment. The transaction starts after the catalog has been retrieved. We
would have to intertwine these steps, and this would raise a plethora of
problems, I imagine.

For example - you cannot be sure what provider the catalog will end up
assigning to the resource that you are querying before everything is
properly resolved. It would be awkward if a query is performed using the
default provider, but the catalog ends up specifying that the user in
question be managed through LDAP, for example.

The compiler calling back to the agent during its catalog request would
be a major game changer. I'm thinking whole new paradigm.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/545C88B5.7020707%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 would want to get the debug details all over
their terminals each and every time is most likely insignificant.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/545CD4DA.1090507%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Leaving Puppet Labs

[Felix Frank]

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 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 November 14th.
 
 My reason for leaving is pretty non-spectacular: after working remotely
 for over a year and a half the isolation really started to weigh on me.
 After struggling with this for a while, I've come to the decision to
 make a change where I can work in an office again. I love what I work on
 here at Puppet Labs. I love the team that I work with. I love working
 with everyone on this list (we really are a pretty civil bunch). I think
 that Puppet Labs and puppet have a great future. Unfortunately it is one
 that I won't get to directly take part it. I hope to continue to watch
 as puppet moves forward. Maybe I'll even continue on some of my
 experiments in my free time and submit some pull requests :)

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/545B2FBB.2000700%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 already have, but provide the ability to
 control where it's searching against, and what to do with the results.
 
 This is my preferred solution.  It makes querying more powerful, and
 separates the concept of querying from the source of the data.

This is a very attractive idea.

Currently the purging through resources is likely to appear entirely too
mystical to most users.

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 than

resources { 'user': purge = true }

With that said, if we end up staying on the resources type track, I'd
lean towards Raphael's suggestion from his reply: Add providers to for
the resources type. Take the magic from the type, add a slew of
providers. This would move this problem into the space of, say, things
like package installation options, for which there are patterns in place.

I think I would prefer that over making resources a core concept.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/545B5DCE.5000205%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 on the fqdn fact, which on Linux is
pretty much the output of `dnsdomainname -f`.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54503348.1040903%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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, provider = gem }
 
 ...which is awful I guess. Anyway, relationship targets will not be
 jeopardized (that I can see).
 
 
 
 It is more than awful.  It either overloads the package title in
 dangerous ways, or else it deeply undermines Puppet's protections
 against duplicate resources.  Consider, what is the meaning of this:
 
 package { 'mysql-gem': package_name = 'mysql', provider = 'yum' }
 ?

Sorry, I should have been more clear. The resource title is supposed to
be arbitrary here. These manage the same resource:

package { 'mysql-gem': package_name = 'mysql', provider = 'gem' }
package { 'mysql-foo': package_name = 'mysql', provider = 'gem' }
package { 'apache':package_name = 'mysql', provider = 'gem' }

 Does it duplicate any or all of these resources?
 
 package { 'mysql-yum': package_name = 'mysql', provider = 'yum' }
 package { 'mysql-rpm': package_name = 'mysql', provider = 'rpm' }
 package { 'mysql-gem': package_name = 'mysql' }
 ?

Only titles clash, so these three could share one catalog. If yum is
your default provider, then the first and third do manage the same resource.

 To me, this proposal seams like the most pragmatic way to alleviate the
 problem without a major retool of how the Package type works. At the
 moment, I'm not convinced that opening up the possibility of accidental
 misuse outweighs the current issues surrounding the workarounds people
 have to use in order to install a package and a gem that happen to share
 the same name.

Thanks for this summary Charlie, it mirrors my feeling quite exactly.

If we open Pandora's box, users will have ample new opportunity to shoot
their own feet. I don't think that there can be a solution that prevents
abuse in the form of conflicting resources, but we do allow a use case
that we know is problematic for several if not many users.

So in response to Andy's request for a pick, I feel that making packages
non-isomorphic and allow namevar != title would be a fair compromise.

package { 'mysql-foo': name = 'mysql', provider = 'gem' }

Yes this might get abused by Forge modules. Nothing we can do about
that, as far as I can tell.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/543697D3.8010207%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54372AEF.4020701%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 about resources - especially the purging options don't live
up to some users' expectations, and we encouraged at least one
contributor to take his enhancements to a separate type in his own
module. The reason being that resources is a high-ish maintenance type.
Perhaps this would be an opportune time to yank this metatype out of the
core as well.

 So, feedback? Should we move anything else out of core? If so, what and
 based on which criteria? Does PL want to carry them in their own
 namespace or should we move most of this to puppet-community?
 
 
 P.S The puppet-community space on Github is open to everyone who wants
 to contribute to it, include PL employees. It's just not tied to Puppet
 Labs, governance wise, which gives us a bit more freedom to move things
 around and break stuff every now and then.

I'm not actively opposed to transferring this to the community, but I
see value in PL retaining the proverbial reigns. We do get a fair say in
many things as it stands, no particular need to stretch our wings
further. And on the other hand, it can be useful to have an
authoritative voice at the table, in such times when we fail to reach
clear consent. (Granted, I can't recall a particular example for such a
situation in this particular community.)

This does boil down to Puppet Tier Modules as discussed early in the,
yes? Sounds all the more sensible to leave the modules with PL.

Thanks for getting this under way.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5434E75B.7010603%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 understand Andy correctly, we might have something like

package { 'mysql-gem': package_name = mysql, provider = gem }

...which is awful I guess. Anyway, relationship targets will not be
jeopardized (that I can see).

 Types of Users: the usual, htaccess, htdigest, tomcat, ldap(posix),
 ldap(other), weblogic, mysql, postgres, dovecot, postfix, (pretty much
 you name it)
 
 Personally, I don't want all of these smashed into the same high level
 interface.

Hmm, I think I agree (right now...let's see about next week ;-)

But we *do* need a subtyping system then. You wouldn't want to implement
each of those as their own independent thing, would you?

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54352621.7050200%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 all, except when no explicit package name is given. I
thought that was what Andy was suggesting.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54353D47.8040108%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 option 2a is the safest. Allowing command line and
 configuration files to override an ENC makes the most sense when it
 comes to running down a configuration issue with puppet. Instead of
 going to the ENC to find that it is overriding a local configuration
 change you have a limited number of files to search on a node before
 consulting the ENC itself.
 
 Even if 2a does not get chosen the command line arguments should rule
 over any ENC or configuration file because that is what the user is
 explicitly requesting.

Sounds like a trend. Thanks for the feedback, guys.

I took a tentative look at the code. While we can easily find out
whether the :environment setting was specified on the command line,
there is no obvious way to find out whether a value was set in the
configuration files rather than left at its default.

I do feel that variant 2 would be much more restrictive and confusing
than 2a by now. So I we may have to patch the settings subsystem to
allow for this.

Am I missing something in the existing tool chain?

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5433A8DC.9000902%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 = 'generic'
notify { 'test': message = $message }
}

class specific inherits generic {
$message = 'specific'
Notify['test'] { message = $message }  # - override
}

Replacing the variable locally is fairly pointless.

class specific inherits generic {
Notify['test'] { message = 'specific' } # - exact same result
}

HTH,
Felix

On 10/05/2014 06:01 PM, Олег Сиденко wrote:
 I want to write the following structure: 

 class CLASSA {
 $ = AAA 
 notify {$:} 
 } 
 class ClassB inherits CLASSA {
 $ = BBB 
 } 



 Summoning of nodes 
 class {ClassB:} 

 expect to see a BBB notifah but Puppet hard shoves 
 Note: AAA 
 Note: / Stage [main] / Classa / Notify [AAA] / message: defined by
 'message' as 'AAA' 


 What am I doing wrong?

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54319C5C.4010608%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 configured environment, replaced its :manifest setting
with what's chosen on the commandline, and makes that the only available
environment.

https://github.com/puppetlabs/puppet/blob/fea22be6a957e62005cab649537b39af0d0bda74/lib/puppet/application/apply.rb#L185-190

Puppet 3.7.0 is less stringent in that regard. It retains the set of
available environments.

https://github.com/puppetlabs/puppet/blob/master/lib/puppet/application/apply.rb#L193

This apparently causes an error when the ENC returns an environment (any
environment), which happens just below the linked code line in apply.rb.
This environment is looked up, bypassing the override of the :manifest.
I suggested a fix for this: Force the node (external or not) to use the
overridden environment.

https://github.com/ffrank/puppet/commit/39b78a8d25fa96c98f81227cd3ef6b48010fab68

During PR triage (sorry for vanishing suddenly, something came up), we
got some doubts whether this was the right thing to do. It is probably
in keeping with former behavior, but it contradicts a decision that was
made wrt. a classic bug.

http://projects.reductivelabs.com/issues/3910

When using agent, not apply, the puppet master may invoke an ENC. The
environment returned from the classifier takes precedence over any
:environment configuration on the agent (both file and commandline).
This is to allow users to use their ENC in contexts that are relevant
for security.

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.
2. Flexible - use the ENC environment, but allow overriding it via --env
on the commandline
3. Strict - always use the ENC environment (except for the overridden
:manifest)

We might even go for a 2a, that would allow config files to override the
ENC as well (if we can easily discern such values from the defaults at
this point in the code).

Personally, I feel that the strict behavior would be very inconvenient.
An attacker could likely circumvent the ENC after all, so the security
aspect doesn't really apply here.

My vote is for the 2nd approach.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5431F0B6.4070700%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 precipitated this. I kind of like the current look at
whats up with Facter, Hiera and finally Puppet thing and going through
the PRs in whatever order. In a perfect world, we'd have enough headway
at most times to touch on almost all open PRs.

ad-hoc sessions, well - sure, if someone can just drag the PR team from
IRC to a hangout, that could be worthwhile. Other than that, I
personally like to be able to plan for the main event triages (leaving
from work early, not doing other things etc.)

 2) We're trying out putting the triage notes up on github (we'll still
 send out email as well). E.g. last triage's notes are at:

Here's another idea - I feel that held over PRs are limiting triage
throughput. It might just be me, but we're usually spending more than
half the time revisiting the stuff that was not yet concluded. Perhaps
it would be easier to

1. restructure the notes to form a lookup list, that allows the
moderator to look for notes on a specific PR when that PR comes up
2. use a strict least recently updated order of PRs to look at
3. perhaps prefaced with a most recently updated for such PRs that had
activity within the last seven days, i.e. since the previous triage

Additionally, the week to-do list for the PR team should likely
separated from the triage notes, so that it's more easier for you guys
to check things off it.

I'm not sure that this would work any better than what we do now,
looking forward to more discussion.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/542BF555.50607%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Auto*

[Felix Frank]

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 that's willing to externally
 verify would be most appreciated.

 Thanks, and hope everyone is having a good conference!

 Trevor

Autonotify...?

I like your way of thinking big and building good things but...this
makes me shudder a bit.

Are you sure we want that? Are you sure *you* do? ;-)

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5421C417.2060506%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Auto*

[Felix Frank]

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 are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5421D360.2000500%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Auto*

[Felix Frank]

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() function?
I'm not falling for that :)

I can see the pain point (although I cannot say I feel the pain, really).

It would be neat if this would come with a batch of matching
metaparameters, so that I can set 'autonotify = false' if I'm chicken.
This should perhaps even be the default. Thoughts?

Best,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5421D4B1.3010900%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] PR Triage canceled today

[Felix Frank]

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

Hi,

I suspect we'll be skipping next week too because of the conference
going on?

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/541B5A2C.8080705%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 redmine has the most history
 (http://projects.puppetlabs.com/issues/5876) and unfortunately it
 doesn't look like there was a clear decision about what the correct
 behavior is. I think John's description of the semantics are pretty
 good, but I find it a little hard to unravel it into what needs to change.

 Adrien's solution is to make it so that a resource *does not process
 refresh events* when it is being skipped. Skipping can happen because
 of failed dependencies or because the resource isn't scheduled. I'm
 going to keep looking over it and will try it out some, but I think
 others should kick these tires a bit as well.

Oh, the nostalgia.

The issue got somewhat watered down back in the day, with questions
about the semantics of refreshonly execs especially when they don't get
triggered. I don't think this belongs into this discussion at all and
can be regarded after the refresh madness itself is sorted out.

Which this fix will. I think.

There are other exciting cases in there, such as is a resource failed
if it's in sync but the refresh fails and so forth. I feel that those
are more relevant, but should probably be handled on their own. This
should be possible, and I don't see that it would be contradictory for
the proposed design. In other words, fixes for related issues can likely
be implemented independently of merging this one.

Specifically, one of the more disturbing examples from the ticket is this:

http://projects.puppetlabs.com/issues/5876#note-16

This one is not fixed through the proposed change. It will need another
change to the effect that a failure to refresh constitutes a resource
failure as well, I assume. Which it should. But, and I repeat myself on
purpose, this should be a different discussion.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5419DA51.1080405%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Puppetlabs Firewall

[Felix Frank]

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 think it does, anyway. It targets packages
that are neither TCP nor Port 22, so all of TCP would still be accepted.
Also udp/22 :-)

 firewall { '000 drop all':
 action  = 'drop',
 iniface = 'eth0',
 proto   = 'all'
 }
 
 and
 
 firewall { '000 accept TCP 22':
 action  = 'accept',
 iniface = 'eth0',
 proto   = 'tcp'
 port = [22],
 }

They share the same priority. Why? The Whitelisting rule should always
precede the catch-all drop.

Have you tried '999 drop all'?

Best,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/541067CD.9060107%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 will be retired. 

Yes, facter-2 ended up somewhat messy, but puppet-4 was really useful to
stay on top of things with the pull requests. Postponing non-Puppet-3.x
merges until after 3.7 landed would have been rather impractical.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54064682.5000609%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 values returned in response to
certain arguments are of great import.
If I take the opposite assumption (fact values are not part of the API)
to its extreme, then we could take the liberties of making arbitrary
changes to fact values independently of release versions.

On 08/30/2014 02:59 PM, Daniele Sluijters wrote:
 By now, most if not all, DSL consumers are aware of the 'correct' way
 to do this, str2bool($::is_virtual). As long as str2bool() with a bool
 returns that bool I see no issue with changing all the boolean facts
 to be actual booleans, even in a .Z release. If you're still comparing
 it as a string, too bad, we've had a better way for over 2 years now.

Well, yes, but there should really be a stern warning in the release
notes to that effect, so that users can audit their code for missing
wrappings in their Puppet code.

I don't think this should be a bugfix release, either - even though you
could consider the rampant maltyping to be bugs, then those still have
been introduced years ago, so the fix should be deferred to the next
feature release.

Best,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/54025415.3070202%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 eclipse with geppetto, i am running into an error
 
 I have a file structure like this..
 
 module_a
   |
   |
   manifests
   |
   |
   folder_b
  | 
  |
  file_c.pp  
  | 
  |
  file_d.pp
 
 #/module_a/manifests/folder_b/file_d.pp 
 class{'module_a::folder_b::file_c': parama = 'something'}
 class{'module_a::folder_b::file_c': parama = 'somethingelse'}   
 class{'module_a::folder_b::file_c': parama = 'somethingelsemore'}   
 
 I keep getting the following error:
 unknown class: 'module_a::folder_b::file_c'

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53FEE1FD.8080906%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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?

 https://tickets.puppetlabs.com/browse/PUP-1515 (Invalid parameter
 provider for custom types/providers)

 Basically it makes very hard do manage multiple environments when
 using custom types/providers.

 Miguel

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53E5553C.1000303%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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-users kind of question, yes?

Sorry, I have no feedback beyond that.

Thanks,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53DF7AD3.4060007%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53D1224D.9010208%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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.

  Can we disallow whitespace between the two @ ?
 +1

And this.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53C92A10.2060905%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 by my assertion that we can model many such *resource* 
crossdependency situations using the virtual resource feature. Enabling
conditional class inclusion is the actual holy grail here, I feel.

On 06/19/2014 12:22 AM, Joachim Thuau wrote:
 What I would be after is the ability to have a module masquerade as
 a different name. so I can say require auth in some moduleA, and
 have ModuleAuth1 and ModuleAuth2 both say I can provide auth, and
 let the manager/user of the system define which one they want. 
 ...
 Now, all that being said, I have absolutely no knowledge of the way
 the parser works internally, so this could be very silly, and
 completely off the realm of possibilities...

Eh, no, that sounds actually pretty neat, but should be the subject of a
whole nother thread. I feel that such a feature could be designed
independently from the catalog introspection discussion.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53A34592.5060203%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 on Windows in its current state.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53A346AA.9030306%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 certainly turn
 into quite the recursive memory hog if not done properly.

Yes, as Henrik mentioned, you'd basically need an advanced resolution
mechanism to it right. I predict that there may well be cases that the
system will not just get right.

 However, I really do think that this is needed in the language as it
 seems to be a place where people frequently stumble when putting
 together what should be a straightforward thought process.

While those are cool ideas (and I'm still rooting for a lazy
evaluator...anyone? no?) I'd like to contend the proposition that actual
support for this style of solving problems should be supported (and by
extension, recommended).

We are currently trying to teach users that in order to model a system,
they typically need to find a way to non-ambiguously define what does
and what does not need to be part of the catalog. This may often boil
down to introducing a flag value in Hiera or somesuch.

In other words, there seems to be a consensus that reflection (for
lack of a better term) in manifests should be avoided in favor of a
common data source in which to base your queries.

And yes, I do realize that there are edge cases where this is quite
painful in comparison to `if defined(Class[x])`, but I guess this is us
discussing if those are worth the burden of supporting the scheme.

Final aside (although I believe that you are aware of this, still got
the urge to point this out): 'Don't reverse these two' will work on the
node level, but as soon as you're two or three levels of `include` deep,
it's wishful thinking at best. One should never rely on evaluation
order. This is precisely why we need defined() gone.

...rereading, the whole message has a distinct Get Off My Lawn feel to
it - sorry. Guess I'm that dude by now :-)

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53A14820.3080907%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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

  firewall::rule { whatever:
 lazy = true,
 trigger = Class[firewall],
  }

*but* this will not work for includes (no, not even using the
resource-like declaration syntax) for much the same reason (I believe)
that class parameter overrides cannot work.

Also, Puppet can do this already, we just call it virtual resources. I
do feel though that many module interoperability use cases of the
firewall variety could be solved using a virtual resources based approach.

But this is essentially derailing the thread. If we find that we *do*
want this for classes, we'll have to kiss *some* frog.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53A17E98.6050101%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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. To be honest it is a
 problem of cost :( It actually takes us a lot of effort to get changes
 in. Most of this comes down to unforeseen consequences of the changes.
 Some of this we discover in review (which takes time), some we
 discover when all of our tests get to run against the changes. I'm not
 sure what I can be done right now to lower the cost. The other
 possibility is that I'm off base here and we are keeping up just fine :)

Well, I think the only new ones we tackled today were some Facter PRs
and that on from cprice. So yes, we're getting relatively little headway
(although, we *did* manage to merge many of the held over ones).

Perhaps we need to keep a more strict discipline and not allow ourselves
to get derailed, at least as long as there is a significant number of
unreviewed PRs.

Mind you, I  do enjoy the side discussions and am prone to start those
myself, still - we may want to restrict ourselves a little depending on
the overall respective PR situation.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5398BC19.2070607%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 contributing this code I could have spent on other
 things :(

For what it's worth - the discussion rather concerned itself with the
issues with *any* cache invalidation that is no graceful webserver
restart. Favoring your implementation over the timeout based approach is
definitely on the table (and would be my personal preference). It'll
definitely be a load of work to review and merge it, obviously.

But please also bear in mind that as contributors, we always carry the
risk that our designs don't pass by all gatekeepers. Even if one
developer asks for an implementation, there is always a consensus to be
reached, and this will not always be possible before looking at PoC
code, or will just not happen in time because it's a logistic
impossibility that the whole team monitors all threads and tickets.

TL;DR I feel your pain and hope this works out, but some times things won't.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53922D78.60001%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 getting rid of the following warning warning: class
 variable access from toplevel.
 
 This is generated each and every time that I access a class variable and
 I'm not quite sure what the correct technique is for fixing the code.

I'll be honest - the whole scoping in Ruby is pretty mysterious to me at
times.

If I understood and remember correctly, @@ only does what you need when
used inside instance methods. In class methods or outside of methods, it
would actually refer a member of the class's class (which is Class? or
something...), so it's only @ for the declaration at class scope.

Again, I may be totally on the wrong track.

Best,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5384BA0D.5000803%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 voted bug:

 http://projects.puppetlabs.com/issues/651

I butted heads with this one recently in yet another effort to solve
some popular request, and took this chance to ask for advice.

We agreed to first gather more user feedback in
https://tickets.puppetlabs.com/browse/PUP-1125 and probably the users'
list later.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/537CF596.4030709%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Constraints beta

[Felix Frank]

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 feature with the additional resource generator (one of my
favorite facilities, so cool).

Generating resources already has many of the semantics you sketched:
- it's a noop if the resource in question is puppet managed anyway
- otherwise it models the current state of the entity in question
(barring modifications such as manipulating ensure for purging)

I can picture a metaparameter such as

service { foo:
  autorequire = { Package[foo] = { ensure = installed } }
}

that would cause the package to be generated, checked for matching
property (is-)values and required by the service resource.

This would suffer the same limitation that constraints will introduce,
unfortunately, which is a certain loss of self-containment. Modules may
not Just Work out of the box anymore, because they depend on the
provisioning of constrained or autorequired resources by means that are
external to the module.

As far as constraints are concerned, those seem to be our best shot at
solving the steaming mess that is defined/ensure_resource, so we may
have to pay this price.
The autorequire metaparameter would be a very powerful way of easing
manifest design, but I'm not quite sure if we can justify paying the
same price.

Or perhaps I'm wrong. That would be cool then :-)

Cheers,
Felix

On 05/06/2014 11:53 AM, Craig Dunn wrote:
 
 This is a lot nicer than the existing workarounds using ensure_resource
 and defined.   Previously I was thinking about something along similar
 lines but with slightly different behavior.  I was thinking of some
 mechanism whereby if you define a constraint then it will be
 autorequired *if* it is in the catalog,  then the provider will use the
 RAL to determine the currently configured state and throw a meaningful
 error if its not configured.
 
 This opens up the posibility of adding a pre-req, but not enforcing that
 the resource is managed through Puppet.  Eg: if someone isn't managing a
 package resource in Puppet because it's part of the base OS install,
 then the pre-req will still pass because it exists.  If it's a Puppet
 managed resource it will be autorequired and therefore will exist before
 the provider quieres the RAL.
 
 I couldn't find an easy way to do dynamic autorequires this way so gave
 up on it a bit.
 
 I like what you've done here though, I'll have a play with it soon.
 
 Craig

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5368CD41.4070407%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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-always-retrieve-service-ensure

So, if you guys could give it a spin, that would be awesome.

Also, a ticket would be helpful, but if you can confirm that this works
and helps, I can open one on your behalf so we can make a PR for this.

Cheers,
Felix

On 12/19/2013 11:39 PM, Jeff Bachtel wrote:

 In the end, even just the behavior change to puppet resource makes
 the patch a non-starter because it is a widely used feature.

 I understand this feature should be kept, but that a pity this should
 impact other even more useful feature like apply or agent.

 Could it be possible that puppet resource and other like apply or
 agent retrieves only what they need? In apply/agent case, this come
 from a transaction being applied. For puppet resource I assume this
 is not the case. Could method parameter solve this case? And this
 could even keep the compat if this param is not specified


 I spent all day (because my Ruby is bad) doing a proof of concept with
 this. It touches type.rb and indirector/resource/ral.rb to add a
 seemingly transparent method variable flagging whether ensure should
 be ignored for the purpose of retrieving resources. It defaults to
 false (don't ignore ensure), which should cause the speedup Aurelien
 is needing. The resource RAL indirector is aware of the method
 parameter and sets it to true (ignoreensure), thereby exhibiting the
 old behavior when puppet resource is called from the command line.

 There is a nasty bit that I'm unsure of in the retrieve_resource
 method. I discovered that when running puppet agent -t --noop, if I
 tried to use my newly defined method parameter that parsing would
 choke - apparently in that state the retrieve method is targeting
 another method. I worked around it by putting in a rescue statement
 and falling back to the old way of calling retrieve which should,
 eventually, still hit the retrieve with Aurelien's improved
 conditional logic.

 Anyway, please find attached a diff containing the changes in
 question. Feel free to refine and submit it as a PR, my Ruby really
 isn't up for my doing so myself.

 Jeff



-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5366D861.1040304%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Constraints beta

[Felix Frank]

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 adopters could take this for a spin, we may be able to
iron out some quirks even before that.

As for the general support of this idea - there is currently a PR for
puppet proper to add native support for types that pre-validate the
whole catalog. In the meantime, the module does support current versions
back to 2.6.x (using a clean workaround). I don't expect a merge of the
constraint functionality into the core before the Puppet 4 release, but
this ultimately depends on the overall resonance in the community.

TL;DR thanks in advance for using constraints in your modules and
providing feedback.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53656437.1010602%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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.
 
 The best solution I have to prevent this 2-run problem is to vendor my ruby 
 gem
 into the Puppet module and hope that I can keep track of upstream properly for
 necessary bug fixes and security patches :(

I vaguely remember talk of providers coming available during the agent
run. Perhaps this is what you're looking for here. If so, it would
probably Just Work.

 Is there no better way to depend on shared Ruby code for my module? Does the
 Modulefile allow for declaring a dependency like this to be installed at
 `puppet module install` time?

I believe this question is not valid. The gem is required agent side,
yes? puppet module install will operate master side, where gem support
should be of no relevance.

Regards,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/535E78DD.7040603%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 by touching a directory or
 file. Maybe that is part of the commands that lets you modify the settings.
 
 We also discussed having MANUAL as the only option, but we ruled that
 out as it would be too irritating when trying things out (i.e. better to
 set NONE for the testing/dev environments).
 
 If people want a MANUAL strategy we can add one.

If accidental cache clearing does not worry you, I feel that
ENVDIRCHANGE *is* pretty much MANUAL.

Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/535668D8.4080902%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 load --
 rubygems 

Hi,

I'm not sure about the whole context, but reading this error gives me
the idea that you're simply supposed to

require 'rubygems'

and just let the type/provider's initialization fail if it's not present.

HTH,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/535416B1.2020006%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/534F8409.3090900%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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

I shall respond on the users' list when I get a chance. Let's not derail
this thread any further.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/534FD2E9.3020804%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Constraints

[Felix Frank]

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 harder half of the work. I hope that a PR will
appear over the course of Easter.

Furthermore, I shall teach myself about authoring on the Forge and see
to releasing the constraints module stat.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/534FD5B4.8010708%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Puppet Templates - RFC

[Felix Frank]

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 to skip a lot of the %- -% tags.
 
 
 I'm not too keen on this. I think that I'd rather keep the single way to
 do it instead of branching out into various aliases for functionality.

Strongly agreed.

Templates are challenging to some users as is. Making it so that
different templates require different parameters to the template()
function call (or differently flavored functions) in the manifest to
work properly will make it (much) harder.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/534FF300.9050907%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Constraints

[Felix Frank]

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

Each is limited to targetting a single resource. I'd be interested in
amending this so that metaparameter-like declarations such as

  resource = Package[foo,bar]
  resource = [ Package[foo], Service[bar] ]

are supported. There's also some TODOs such as tight validation (i.e.
syntax checks).

An idea for extending the concept is weak constrains that won't fail
if a targeted resource is not part of a catalog.

A PR is pending once these additions are complete.

Thanks in advance to anyone who takes a closer look.

Cheers,
Felix

On 02/20/2014 10:17 AM, Daniele Sluijters wrote:
 I like a constrains style solution much better myself to, wasn't aware
 of it at the time.

 I think with Puppet 4 we could introduce some additional pain, semver
 wise we'd be
 allowed to do that. If that helped fix this issue once and for all I'm
 pretty sure the
 community would support it too.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/534C6A4B.8020408%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Constraints

[Felix Frank]

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 kinds of things don't have to
 go into the puppet repository in order to be tried out.

Thanks for the input.

I even *had* been thinking of hacking the constraint evaluation into the
new type's generate hook. This way, the agent would naturally run them
before the transaction, thinking it was a constraint's way to do
generate additional resources.

This has two limitations, though:
1. The cosmetic issue that the error output alludes to the generation of
additional resources and
2. the critical problem that this hook has no way to interrupt the
transaction.

Usually, exceptions that are raised from types and providers are handled
as resource local problems. They will fail the resource, but not the
transaction as a whole.

I currently see no way to do this without patching the transaction code.
Of course, we could just introduce an appropriate hook into the core and
do everything else in modules for a time then.

Seeing as the lonterm goal of the feature would be to serve as the
mortar between third party modules, I'd still see it in tier 1, but
that's just my gut feeling.

It may just become a very common dependency such as concat_file I guess.
But can we deprecate defined() in favor of an external module? :-)

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/534CC263.2070403%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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/recurse etc. The inconsistency with yumrepo/enabled is
unfortunate.

When I read those, I think 'imperative', which really is what the
manifest represents. Ensure this! Hold that! :-)

On 04/01/2014 03:20 PM, Trevor Vaughan wrote:
 I like hold and purge as separate parameters for readability (which
 translates to being easier to parse with external scripts if necessary).

 Trevor


 On Tue, Apr 1, 2014 at 9:09 AM, Daniele Sluijters
 daniele.sluijt...@gmail.com mailto:daniele.sluijt...@gmail.com wrote:

 If we go down this road, how does 'purged' fit in. Should we have
 purge = true, or ensure = 'purged'?

Hmm, no.

Seeing as 'purged' in this context is an installation state competing
with installed or removed, it should stay in the ensure property, which
is what manages installation states. E.g., this makes little sense:

package { 'foo': ensure = 'installed', purge = true }

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/533ABE41.1080809%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 introduction of the version property. I don't think
it would be a good idea though.

Regards,
Felix

On 04/01/2014 04:39 PM, Daniele Sluijters wrote:
 By that same logic held/hold should also stay in ensure but that's not
 feasible because you can't hold at a specific version then.

 Hmm, no.
 
 Seeing as 'purged' in this context is an installation state competing
 with installed or removed, it should stay in the ensure property, which
 is what manages installation states. E.g., this makes little sense:
 
 package { 'foo': ensure = 'installed', purge = true }

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/533AD26A.3090008%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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.
 It's a sane design in the given domain.


 That is a problem puppet could alert on, or puppet could just let the
 managed OS tell whether that state is permissible.

I may be missing something, but that can never be a consistent single
state on any platform.
A path will always lead to a file *or* a directory *or* a symlink.

Allowing a directory { } syntax might be conceivable if directory and
link were basically aliases for the file resource type. They would munge
the ensure values differently.

I don't think that would add much value though, because behind the
scenes, they would map back to the file type. To the user, this would
potentially be very confusing. (Also, I sense much opportunity for weird
bugs in the implementation.)

Regards,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5336E12E.7070803%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 universally a property, not a parameter, i.e. it is
quite capable to go out of sync, which will prompt a reaction from
Puppet. This in and of itself can be an indicator as to what values may
make (no) sense.

 My problem with the file type is that though you might
 be able to access directories and symbolic links as files in Unix,
 they model different abstractions. I think you see evidence of this
 abstraction in the separate Unix and Windows cli tools, mkdir, ln,
 mklink. That is why I find it a strange mental model that when I need
 to create a directory
 or a symbolic link I need to use the file type.

We're getting side-tracked ;) but here's why those should really be the
same to Puppet: What the catalog refers to as a 'file' is actually a
file system entry.

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.
It's a sane design in the given domain.

On 03/28/2014 05:00 PM, Andy Parker wrote:
 I have no idea how this translates to other package managers though.
 
 
 I think the crux of the matter is how well the proposal would translate
 to other package managers. I think that the proposed separation of
 ensure and version makes sense, but it also opens up a few edge cases
 that having all of it in ensure doesn't. For instance, what should be
 expected to happen if the package is ensure = held, version = 1.4.3
 but version 2.1 is actually installed? I expect the answer is to
 downgrade to 1.4.3 and do whatever the package manager can do for
 holding. But is that a universal enough capability?

I agree with the sentiment that this is indeed the crux.

However, since the semantics in the described scenario are so
intuitively clear, I would actually expect Puppet to fail the resource
if my package manager is incapable of performing the necessary steps.

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53359F79.60709%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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, user = customer }
ssh_authorized_key { admin: masterkey: key = ... }

(Also, what would a user expect it to express?)

As for migration...this would be us looking at deprecating key names
of the proposed form first. Granted, those are unlikely picks, but any
user that *is* afflicted by such a deprecation will have to make some
handstands to cleanly move to a different naming scheme.

Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/532812D6.3030901%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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=20140320T10p1=137
 ?
 
 Regards, David

Nope :)

What you linked to is summer time aka Daylight Saving time. PST is in
fact *not* summer time but winter time instead, so the delta is 9 hours
instead of 8. 10 PST is 19:00 CET.

Regards,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5328729A.705%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

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 practice, but might run
 into weird edge cases, e.g. blocking proper purge support.

Good point. Note that crontab had different but related issues wrt.
purging. We came up with a workaround then that we can likely apply to
authorized keys as well, i.e. mangle the titles of generated resources
into a shape that is unlikely to clash with real-word resources (and
other generated resources).

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5327046A.9090305%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

On 03/17/2014 05:25 PM, John Bollinger wrote:
 https://jira.puppetlabs.com/browse/PUP-731
 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 the
 same for them.

Yes. Note that the original RedMine ticket was referred to what is now
https://tickets.puppetlabs.com/browse/PUP-1033 and pertains to functions
only.

Regards,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/532722AB.4090500%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

On 03/12/2014 11:23 PM, Trevor Vaughan wrote:
 
 package_yum
 package_gem
 etc
 
 This would probably be pretty quick work overall and, of course,
 eliminates all of the conflict issues.
 
 Butit doesn't feel like a good solution.

I agree that the implementation you sketched is messy, but the basic
idea has actually occured to me as well when I read John's latest reply.

The assumption that the regular old system will only ever use one
provider for a given type holds true for many use cases. Package is a
notable exception insofar as it can now be used to manage things that
are not OS packages (but also gems and what have you).

IMO the source of the issues here is that a gem is fundamentally a
different kind of package than the rpm/deb/... your OS uses for native
software. (So are CPAN modules, puppet modules etcpp.)

Creating new types that explicitly name the type of package they deal
with would handle this, yes (although I would vote that yum/apt/dpkg/rpm
and friends stay in the pure package domain if we should ever go that
route).

It would be nice if we had a system were the compiler could infer the
subtype from the value of the provider parameter. Because really, we are
only prone to hit conflicts when non-OS packages are requested via
providers like gem/cpan/pecl/pear/forge/whatever.

The generic enhancement of the Model would allow to auto-switch to
subtypes via arbitrary rules, where going by the provider value would
likely suffice for the package type.

Regards,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53219896.6080206%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

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

[Felix Frank]

 On Thu, Mar 13, 2014 at 9:23 AM, John Bollinger
 john.bollin...@stjude.org mailto:john.bollin...@stjude.org wrote:
  That would work for me.  Alternatively, there could be just one new
  type, say SecondaryPackage, that rolled up gem, pip, fink, etc.

On 03/13/2014 02:50 PM, Trevor Vaughan wrote:
 SecondaryPackage wouldn't fix it if you wanted to install using pip and
 gem on the same system.

Huge +1. John, would you have us dance this one again in a year or two? ;-)

 This gets hairy with RPM since Debian, etc... can
 all install and use the RPM command so I'm not sure quite how to handle
 that one.

Ugh, that is a much better point than I'd like to admit.

It could be handled by the pick subtype based on provider value rule I
sketched earlier, if we opt to *not* let dpkg, rpm and friends remain
un-subtyped.

It's not even that much of an outer edge case, because given a Debian
box on which you want/have to use this RPM from Corporate IT, this would
be a likely manifest:

package {
  puppet: provider = dpkg, ensure = absent;
  puppet: provider = rpm, ensure = present;
}

And yes, specifying that the rpm should require the dpkg would be hella
non-intuitive (require Package[puppet:dpkg]? Dpkg_package[puppet]?
Code readability anyone?) In that vein, it would indeed be helpful to
allow the alternative syntax of

dpkg_package { puppet: } vs. rpm_package { puppet: }

...but that will introduce new pitfalls for users, I believe. Full
vicious circle.

Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5321BD0F.5090507%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] unknown message digest algorithm, who can help to explain this issue? thanks a lot!

[Felix Frank]

On 02/19/2014 04:38 PM, Monir Miloudi wrote:
 Thank you for your response.
 
 As a workaround, do you think that using an alternate CA (as described
 here:
 http://docs.puppetlabs.com/puppet/3/reference/config_ssl_external_ca.html)
 that is SHA1-compliant would work ?

Hi,

as this thread has fallen silent, I will go ahead and point out that,
yes, this would likely work.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/530B4B69.2000909%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Felix Frank]

Hi Daniele,

thanks for bringing this up. Again :-)

On 02/19/2014 12:16 PM, Daniele Sluijters wrote:
 I'm not sure if it's even desirable or possible to solve this issue in
 the first place but I was curious if anyone has given any more thought
 to this?

They have. I managed to dig up these two monsters from the past, but
there are more, I believe:

RFC: Deprecate defined() function for Telly.
https://groups.google.com/forum/#!searchin/puppet-users/cross-module/puppet-users/YncxKD3MSms/fHOhIqat0u4J

Cross-module dependencies
https://groups.google.com/forum/#!searchin/puppet-users/cross-module/puppet-users/Fvl0aOe4RPE/-k60j2QSID0J

Take special note of John's constraint sketch in the latter.

Cheers,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53049570.9020200%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet-dev] Flexible version matching for packages?

[Felix Frank]

On 02/12/2014 12:18 PM, Jason Antman wrote:
 
 - explicit version specification is a very good thing, if version
 comparison is reliable and in step with the underlying package system.
 I'd love to be able to specify = 1.2.3

I'm torn. The sync action would be update to latest, no? So I'm not
sure the overhead is justified, seeing as puppet can do that without
problems already.

What the $VERSION scheme introduces is behavioral ambiguity, I feel,
and while it may seem neat to be able and jot such information down in a
module, again, the benefit is limited, seeing as such matchers won't stack.

Btw., from PUP-1519

package { 'foo': ensure='4.0' }

would act as 'installed' if version is 4.0 but would produce an error
otherwise.

This doesn't fit with puppet's MO at all. Out-of-sync properties should
really have a way to get in sync, imho, and provoking resource failures
to notify the user of manual actions required just feels very wrong.

Regards,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/52FB5F10.8080204%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet-dev] Default values for properties - good or goblin?

[Felix Frank]

On 02/10/2014 07:16 PM, Andy Parker wrote:

 As far as I can tell, the defaults are only necessary for cases in
 which
 ensure changes from absent to present (or another non-absent
 value, for
 some types). Would it make sense to try and limit their use to
 exactly 

 those times?


 Are you asking about in general or just for the specific case of the
 ssh_authorized_keys code?
Yes, I think this is a general issue we're facing with all types.

Thanks,
Felix

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/52F93A3A.90706%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet-dev] Default values for properties - good or goblin?

[Felix Frank]

Hi,

today I butted heads with yet another cron issue [1] that was caused by
the fact that the cron type specifies a default value for the user
property. It made me think of a fundamental issue I had jotted down some
time ago in a gist [2].

I propose that default values for properties are dangerous, at least in
the way they work right now. What happens is that a manifest that does
not specify a value for a property that has a default value leads to a
catalog with this default as the should-value for that property. See the
gist for an example. Puppet will mercilessly sync systems to the default
values.

As far as I can tell, the defaults are only necessary for cases in which
ensure changes from absent to present (or another non-absent value, for
some types). Would it make sense to try and limit their use to exactly
those times?

Cheers,
Felix

[1] https://tickets.puppetlabs.com/browse/PUP-1624
[2] https://gist.github.com/ffrank/8327298

-- 
You received this message because you are subscribed to the Google Groups 
Puppet Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/52F81A86.7%40Alumni.TU-Berlin.de.
For more options, visit https://groups.google.com/groups/opt_out.