Released April 1, 2014. (RC1: February 28; RC2: March 12; RC3: March 25; RC4:
March 28.)
Facter 2.0.1 is the first release in the Facter 2 series.
Headline Features
- Fact values can now be arbitrarily complex data structures instead of simple
strings.
- There's a new API for adding facts, whi
On 04/02/2014 01:11 AM, Felix Frank wrote:
>> Are hashes as property values out of the question?
> I'll go on a limb and answer this with a strong affirmative ;-) Good lord...
More to the point: Hash values in and of themselves are fine. Not for
ensure though, and especially not in a way that make
On 04/01/2014 08:41 PM, Robin Bowes wrote:
> Are hashes as property values out of the question?
I'll go on a limb and answer this with a strong affirmative ;-) Good lord...
As for held vs. hold, I guess John's points have more merit than mine
after all.
I vote to keep held out of ensure. It rea
On Tuesday, April 1, 2014 11:09:23 AM UTC-5, Ken Barber wrote:
>
> >> Isn't that the opposite of what you've been asking for as the default,
> >> do you mean "environment = $::environment" here or have you changed
> >> your mind about the default?
> >>
> >
> > I think the default when you le
Are hashes as property values out of the question?
eg.
ensure => {
installed => true,
version => '1.2.3',
held => true,
bikeshed => 'green',
}
R.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and
I'm losing track of this conversation. Let's try to bring it in for a
landing so that we can move forward with the pull request from Jesse.
Is there a general consensus that this is the correct direction?
package { 'foo':
ensure => installed,
version => '1.1',
held => true,
}
I c
On Tue, Apr 01, 2014 at 05:09:23PM +0100, Ken Barber
wrote:
Isn't that the opposite of what you've been asking for as the default,
do you mean "environment = $::environment" here or have you changed
your mind about the default?
I think the default when you leave out a parameter from a query
On Monday, March 31, 2014 6:44:35 PM UTC-5, Trevor Vaughan wrote:
>
> I have to say that I like 'hold' better than 'held' based on the way I
> would actually read this.
>
> This is package 'foo'.
> I want to ensure that it is installed.
>
"is"
> I want the version to be '1.1'.
>
"be"
On Tuesday, April 1, 2014 8:25:21 AM UTC-5, Felix Frank wrote:
>
> 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
On 1 April 2014 17:52, Ken Barber wrote:
> >> >> This seems a bit backwards to me, for all other parts of the query
> you
> >> >> just leave it out if you don't want to match on it. There's no need
> for
> >> >> a
> >> >> explicit tags=='*' if you want to match on all tags for example. So I
> >>
>> Isn't that the opposite of what you've been asking for as the default,
>> do you mean "environment = $::environment" here or have you changed
>> your mind about the default?
>>
>
> I think the default when you leave out a parameter from a query should be to
> not match on that parameter, like it
>> >> This seems a bit backwards to me, for all other parts of the query you
>> >> just leave it out if you don't want to match on it. There's no need for
>> >> a
>> >> explicit tags=='*' if you want to match on all tags for example. So I
>> >> don't
>> >> see why environment matching would work th
On Mon, Mar 31, 2014 at 1:47 PM, Ken Barber wrote:
> > Coarser grained too, perhaps? That is, for the case where puppetdb is
> > configured with collection_environments = 'same', does it not make sense
> to
> > support, say,
> >
> > Nagios_host<<| environment == * |>>
> >
> > to collect reso
On 1 April 2014 15:59, Ken Barber wrote:
> > I... kinda like that suggestion. I would keep current behaviour intact,
> so
> > collection would work 'as expected though weirdly' and not break current
> > manifests. People who are up to date on this can explicitly select an
> > environment to colle
On 2014-04-01 15:59, Ken Barber wrote:
I... kinda like that suggestion. I would keep current behaviour
intact, so
collection would work 'as expected though weirdly' and not break
current
manifests. People who are up to date on this can explicitly select
an
environment to collect.
I also think
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
On 2014-01-04 11:11, Erik Dalén wrote:
On 1 April 2014 03:43, Ken Barber mailto:k...@puppetlabs.com>> wrote:
>> Upon reflection, I think it would be wise to control which
resources are
>> collected strictly via search expressions. I disfavor a
configuration
>> setting aff
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.
On Tuesday, 1 April 2014 15:25:21 UTC+2, Felix Frank wrote:
>
> On 04/01/2014 01:44 AM, Trevor Vaughan wrote:
> > I have to say that I like 'hold' better than 'held'
> I... kinda like that suggestion. I would keep current behaviour intact, so
> collection would work 'as expected though weirdly' and not break current
> manifests. People who are up to date on this can explicitly select an
> environment to collect.
>
> I also think that this approach works better
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/
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> wrote:
> If we go down this road, how does 'purged' fit in. Should
If we go down this road, how does 'purged' fit in. Should we have purge =>
true, or ensure => 'purged'?
On Wednesday, 26 March 2014 19:12:33 UTC+1, Jesse Hathaway wrote:
>
> In my discussion with @adrienthebo on my pull request:
> https://github.com/puppetlabs/puppet/pull/2309 I raised the quest
I... kinda like that suggestion. I would keep current behaviour intact, so
collection would work 'as expected though weirdly' and not break current
manifests. People who are up to date on this can explicitly select an
environment to collect.
I also think that this approach works better for comm
On 1 April 2014 03:43, Ken Barber wrote:
> >> Upon reflection, I think it would be wise to control which resources are
> >> collected strictly via search expressions. I disfavor a configuration
> >> setting affecting that, because if there were one then it would be
> likely
> >> that different m
24 matches
Mail list logo
