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
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 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
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
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'
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 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.
I want the version to be '1.1'.
I want to hold it fast.
I want it held fast works as well, but just sits funny with me somehow.
Not much
On Monday, March 31, 2014 12:56:26 PM UTC-5, Jesse Hathaway wrote:
>
> I think the discussion has petered out, I propose the following.
>
> Given that held is arguably not an essential state of a package nor
> version, we should move to the following package declaration,
>
> package { 'foo':
>
I think the discussion has petered out, I propose the following.
Given that held is arguably not an essential state of a package nor
version, we should move to the following package declaration,
package { 'foo':
ensure => installed,
version => '1.1',
hold => true,
}
thoughts?, objections?
On Sat, Mar 29, 2014 at 10:05 AM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:
> 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.
>
true, I think I would be somewhat more co
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.
On Fri, Mar 28, 2014 at 11:12 AM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:
> 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.
>
True, but that is not how you think about
On Thu, Mar 27, 2014 at 12:22 PM, Daniele Sluijters <
daniele.sluijt...@gmail.com> wrote:
> Hey,
>
> As far as package is concerned I prefer Adrien's suggestion of ensure =>
> held, version => 0.4. This is entirely personal but I think ensure is a
> good place to model the 'state' of a package and
My commments on the topic of ensure property values are not specific to
any of the particular previous comments, so I am top posting.
The boundary between which part of the resource's life-cycle that should
be described by the ensure parameter, and other parameters/properties is
very blurry. T
On 03/28/2014 04:01 PM, Jesse Hathaway wrote:
> Thanks for pointing out this definition. I think asking whether an
> ensure parameter models a fundamental aspect of a resource is a
> helpful litmus test for what values an ensure parameter should have
> for a resource.
Nitpick: Ensure is universall
>
> The language reference describes 'ensure' as managing "the most
> fundamental aspect of the resource on the target system." For many types,
> simple presence or absence fits that description, but I don't necessarily
> call it abuse to support finer gradations of "present", as File does. On
>
Hey,
As far as package is concerned I prefer Adrien's suggestion of ensure =>
held, version => 0.4. This is entirely personal but I think ensure is a
good place to model the 'state' of a package and when it comes to apt that
state is either held, removed, purged or installed. I would go as far
On Wednesday, March 26, 2014 1:12:33 PM UTC-5, Jesse Hathaway wrote:
>
> In my discussion with @adrienthebo on my pull request:
> https://github.com/puppetlabs/puppet/pull/2309 I raised the question of
> what should be the allowable or suggested values for the ensure property?
>
> My pull reque
23 matches
Mail list logo
