I'd certainly be interested in working this through more at PuppetConf if
there's time.
I also don't see why this needs to wait until 5.0. It should be 100%
backward compatible with the 4.x series in theory (it would be nice anyway).
Thanks!
Trevor
On Thu, Jun 19, 2014 at 6:41 PM, Henrik Lindb
On Thursday, June 19, 2014 1:18:30 PM UTC-7, Felix Frank wrote:
>
> 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
On 2014-19-06 23:25, John Bollinger wrote:
On Wednesday, June 18, 2014 6:07:02 PM UTC-5, henrik lindberg wrote:
On 2014-18-06 22:44, John Bollinger wrote:
>
> Puppet already has a tool for separating the details of a
resource from
> the decision about whether to include it
On Wednesday, June 18, 2014 6:07:02 PM UTC-5, henrik lindberg wrote:
>
> On 2014-18-06 22:44, John Bollinger wrote:
> >
> > Puppet already has a tool for separating the details of a resource from
> > the decision about whether to include it in the catalog: virtual
> > resources. Those decision
On 06/19/2014 03:13 AM, Trevor Vaughan wrote:
> It just so happens that you can manipulate the catalog once applied to
> the system in various parts of custom types and I've hacked around
> this a bit by creating random resources as necessary in the past.
Yes, I cringed. "Well" done ;-)
I stand b
Just to make everyone cringe heartily, I've found that I *can* do what I
want but not in a way that's really reusable/understandable by others.
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 cr
On 2014-18-06 22:44, John Bollinger wrote:
On Wednesday, June 18, 2014 4:22:16 AM UTC-5, Trevor Vaughan wrote:
Hi Felix,
Yes, I'm very aware that the current recommendations are to very
cleanly model your system to be able to non-ambiguously define your
catalog.
However,
Every time I look at this, I keep thinking about the way Debian implement
"feature packages" or "virtual packages". The Debian packages "providing a
feature", which can then be depended upon by other packages. Some package
that requires a MTA shouldn't care if I use exim, postfix or sendmail, as
On Wednesday, June 18, 2014 4:22:16 AM UTC-5, Trevor Vaughan wrote:
>
> Hi Felix,
>
> Yes, I'm very aware that the current recommendations are to very cleanly
> model your system to be able to non-ambiguously define your catalog.
>
> However, there have always been arguments that the Puppet lang
On 06/18/2014 12:56 PM, Trevor Vaughan wrote:
> e) Use the new proposed magic => Woo, it "just works" if *anything* in
> the catalog includes 'firewall'. This way, if I don't want it, I don't
> get it in an intuitive fashion.
FWIW, I can see this happen rather easily with a metaparameter like
f
Grr:
Also 'include' *would* accept hashes and include the specified module. In
the case that two are present on the system, you would need to deconflict
your include code or somehow be able to set a default for your system
(better due to legacy code). Perhaps, a 'default' entry in the Modulefile
o
Sorry to reply to myself but I just thought of the perfect example of why I
want this.
puppetlabs-firewall
So, pretty much all modules need to call out to a firewall if one is
enabled for obvious reasons.
However, you may have very real scenarios where you don't want
puppetlabs-firewall managing
Hi Felix,
Yes, I'm very aware that the current recommendations are to very cleanly
model your system to be able to non-ambiguously define your catalog.
However, there have always been arguments that the Puppet language should
be declarative throughout which makes for more maintainable and intuiti
Hi,
putting on my manifest design philosopher's hat :-)
On 06/18/2014 04:11 AM, Trevor Vaughan wrote:
> It does get hairy when you mix the callbacks with the reverse
> dependencies. I can see having to iterate over the stack (mesh?) and
> check for loops and correctness while doing so. It could c
Henrik, you 100% nailed everything that I wanted.
In my mind, I was envisioning the system of callbacks that you described as
a stack with pointers (file:line?) portions of the code. When the catalog
pass is complete, refer back to the callback stack(s) and process them down
until empty.
Basicall
On 2014-17-06 22:14, Trevor Vaughan wrote:
Do you like dead threads? like dead threads
Only some of them (like this one)...
So, I was looking back over this and there's one thing that we
desperately need as a community.
We need defined(Class['foo']) and it needs to know about ALL classe
Do you like dead threads? like dead threads
So, I was looking back over this and there's one thing that we desperately
need as a community.
We need defined(Class['foo']) and it needs to know about ALL classes in the
catalog at compile time, not just the ones that got included before it.
Thi
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.
On
> I'm not very fond of the idea of hardwiring special support for
> Package resources into Puppet (nor for resources of any other specific
> type). I still like my "constraints" idea, to which Felix directed
> your attention, but if something like that is ever implemented then
> adopting it will
On Wed, Feb 19, 2014 at 1:58 PM, Wolf Noble wrote:
>
>
> One thing I've seen done is something like the following contrived example:
>
> class core{
> @package { 'build essential':
> ensure => 'installed',
> tag=> 'core_packages'
> }
> Package <| tag == 'core_packages' |>
autocorrect changed 'buildessential' to 'build essential'..
mental note to not send to puppet-dev from my phone. ;)
On Wed, Feb 19, 2014 at 3:58 PM, Wolf Noble wrote:
>
>
> One thing I've seen done is something like the following contrived example:
>
> class core{
> @package { 'build esse
One thing I've seen done is something like the following contrived example:
class core{
@package { 'build essential':
ensure => 'installed',
tag=> 'core_packages'
}
Package <| tag == 'core_packages' |>
}
>From my probably incomplete understanding, virtualizing and realizin
On Wednesday, February 19, 2014 5:16:00 AM UTC-6, Daniele Sluijters wrote:
>
> Hi everyone,
>
> As I was browsing through a few modules on the Forge I noticed that more
> and more people seem to have taken to the `if ! defined(Package['name'])
> {}` to ensure their module doesn't cause a duplic
23 matches
Mail list logo
