[Puppet Users] Re: Resource ordering with Hiera ENC
I have solved it as below with a wrapper to the zabbix module:
class common::zabbix {
contain zabbix::agent
Class['common::repos'] -> Class['common::zabbix']
}
and then in selected yaml environments
## YAML
---
classes:
- common
- ntp
- common::zabbix
El viernes, 17 de abril de 2015, 16:57:25 (UTC+2), Raul Macian escribió:
>
> Hi There,
>
> After a couple of years working with puppet I'm starting to use Hiera as
> ENC with the hiera_include('classes').
>
> Now I'm having problems with the resource ordering. I created a module to
> set up my repos and then use some others modules. My problem is that my
> 'common' module must run before the other modules and I don't know how to
> do it in hiera.
>
> My yaml is like
>
> ## YAML
> ---
> classes:
> - common
> - ntp
> - zabbix::agent
>
>
>
> But this drives me to
>
> Info: Applying configuration version '1429274932'
> Notice: /Stage[main]/Zabbix::Agent/Package[zabbix-agent]/ensure:
> current_value absent, should be 2.4.3-1.el6 (noop)
> Notice: /Stage[main]/common::Repos/Yumrepo[zabbix]/ensure: current_value
> absent, should be present (noop)
>
> How do I force to the common class to have procedence over the zabbix
> module? Before using hiera as ENC I would have a -> between the classes
> and an anchor if needed in my manifest, but now I don't have any manifest
> for my nodes. Where can I put it on ?
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/80f6e605-6805-4295-9fe9-40f19e957898%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Resource ordering of Execs not working as expected (SOLVED)
Hrm, well, with your help, I got this to work in the order I was expecting.
I think I had a few problems here.
1. My original ordering was:
File['Config'] -> Exec['stop'] -> Package['foo'] -> Exec['start']
I changed this to:
File['Config'] ~> Exec['stop'] -> Package['foo'] ~> Exec['start']
It helps when I RTFM on using ~> for notifications instead of -> for pure
ordering.
2. When I wasn't using that ordering syntax, I had:
exec { "stop":
path=>
"/usr/local/sbin/:/usr/local/jdk/bin:/bin:/sbin:/usr/sbin:/usr/bin",
command => '/usr/local/sbin/control.sh stop',
refreshonly => true,
logoutput => true,
subscribe => File['Config'],
require => File['/usr/local/sbin/control.sh'"]
}
This is because there are cases when the foo::config is created, but foo is
not (meaning the control files are not created). I figured this would
create the proper order, but it doesn't seem to have.
3. Using different types of configuration patterns. I kept flipping
between using subscribe/notify and ->/~> ordering syntax and most likely
screwed something up in the interim. I eventually made a mistake and got
some dependency cycle issues which actually helped quite a bit in figuring
out my error in logic.
BTW, "refreshonly => true" is still set on both execs and is working
properly.
Thank you for the help!!!
Jake
On Monday, September 22, 2014 7:44:34 AM UTC-7, jcbollinger wrote:
>
>
>
> On Friday, September 19, 2014 12:59:34 PM UTC-5, Jake Lundberg wrote:
>>
>> Puppet 3.6.2
>>
>> First, I understand that Execs try not to run multiple times if called
>> many times by many resources and typically wait until they've all been
>> "collected" from all resources
>>
>
>
> Not exactly. Execs run at most twice per Puppet run. They run at most
> once if they are refreshonly or if they do not receive any events from
> other resources. (If they are refreshonly then they run *only* if they
> receive an event from another resource.) When they run relative to when
> other resources are applied (and whether resources send them events) is
> shaped by resource relationships, just as with all other resource types.
>
> ObYoda: "Do... or do not. There is no 'try'."
>
>
>
>> , but I have a specific case where I need different Execs to run in a
>> particular order based on a set of resources that change.
>>
>>
>
> That's what resource relationships are for. Cristian has showed you how.
> If that doesn't seem to be working for you then it would help us help you
> if you present a complete -- but simple -- example that demonstrates your
> problem.
>
>
> John
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/7a4f2132-2f53-47bf-afb1-80e5d25988d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Resource ordering of Execs not working as expected
On Friday, September 19, 2014 12:59:34 PM UTC-5, Jake Lundberg wrote: > > Puppet 3.6.2 > > First, I understand that Execs try not to run multiple times if called > many times by many resources and typically wait until they've all been > "collected" from all resources > Not exactly. Execs run at most twice per Puppet run. They run at most once if they are refreshonly or if they do not receive any events from other resources. (If they are refreshonly then they run *only* if they receive an event from another resource.) When they run relative to when other resources are applied (and whether resources send them events) is shaped by resource relationships, just as with all other resource types. ObYoda: "Do... or do not. There is no 'try'." > , but I have a specific case where I need different Execs to run in a > particular order based on a set of resources that change. > > That's what resource relationships are for. Cristian has showed you how. If that doesn't seem to be working for you then it would help us help you if you present a complete -- but simple -- example that demonstrates your problem. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9a9f750a-3cf8-4d62-90ed-409c0d10d22e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: Resource ordering only using Hiera?
On Monday, December 16, 2013 10:38:27 AM UTC-6, Joseph Swick wrote: > > On 12/16/2013 10:59 AM, jcbollinger wrote: > > > > > > On Friday, December 13, 2013 3:56:50 PM UTC-6, Joseph Swick wrote: > > > > [...] > > > > What am I missing to get Puppet to evaluate the $resourceX_type > >> variables as a resource type [e.g: File, Service, etc.] to get this to > >> work? > > > > > > > > Puppet DSL does not provide such a feature. It is conceivable -- > likely, > > even -- that you could instead create a custom function to apply generic > > ordering constraints such as you want but you should beware that unlike > > relationships declared via the DSL, relationships applied via a function > > would probably be sensitive to manifest evaluation order. > > > > > >>> > > > > I suspect that the use case for the functionality you describe is not > > nearly so general as you suppose. Module portability is more typically > > approached in Puppet by using facts -- custom facts, if necessary -- to > > probe the relevant characteristics of the target machine, and by using a > > small number of higher-level alternatives to determine what to declare. > > > For example, it is common to use the $::osfamily fact to guide what > > declarations to make, coding appropriate specifics for each supported OS > > family. > > > > > > John > > > > Thank you for the reply. However, I think you may not be fully > understanding what I was trying to describe (or I didn't describe it > well enough). What I'm trying to do has nothing do do with resource > facts on the system within a module. We're already using various facts > to define which portions of the hieradata should be considered for a > particular node. I would like to ensure that the resources that get > defined as a result are created in the correct order when required. > > On the contrary, you were clear about that the first time. You are looking for a general-purpose way to encode generic resource relationships in your hiera data. You cast the reason for wanting to do so in terms of module portability. As I wrote the first time, Puppet DSL+hiera does not support what you hope to do, though likely you could achieve it with the help of a custom function. The rest of what I wrote was basically a recommendation against doing it even with a custom function. I don't think it will serve your portability objective very well. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/991cbf7b-103a-41ac-be99-4b79516ec5f9%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Resource ordering only using Hiera?
On 12/16/2013 10:59 AM, jcbollinger wrote: > > > On Friday, December 13, 2013 3:56:50 PM UTC-6, Joseph Swick wrote: > > [...] > > What am I missing to get Puppet to evaluate the $resourceX_type >> variables as a resource type [e.g: File, Service, etc.] to get this to >> work? > > > > Puppet DSL does not provide such a feature. It is conceivable -- likely, > even -- that you could instead create a custom function to apply generic > ordering constraints such as you want but you should beware that unlike > relationships declared via the DSL, relationships applied via a function > would probably be sensitive to manifest evaluation order. > > >>> > > I suspect that the use case for the functionality you describe is not > nearly so general as you suppose. Module portability is more typically > approached in Puppet by using facts -- custom facts, if necessary -- to > probe the relevant characteristics of the target machine, and by using a > small number of higher-level alternatives to determine what to declare. > For example, it is common to use the $::osfamily fact to guide what > declarations to make, coding appropriate specifics for each supported OS > family. > > > John > Thank you for the reply. However, I think you may not be fully understanding what I was trying to describe (or I didn't describe it well enough). What I'm trying to do has nothing do do with resource facts on the system within a module. We're already using various facts to define which portions of the hieradata should be considered for a particular node. I would like to ensure that the resources that get defined as a result are created in the correct order when required. Tl;dr;: I'm looking to see if I can achieve resource chaining wholly within hiera definitions without having to create singular manifests/classes for nodes to include via hiera, which the sole purpose is to order resources that are being realized and configured via hiera. It's quite likely what I'm trying to achieve isn't currently possible in Puppet, but I was hoping that someone could point out something I overlooked. If not, I'll have to find an appropriate place in our puppet site to create the resource ordering classes for various nodes where the order of resource creation is critical. Thank you. -- Joseph Swick Operations Engineer Meltwater Group signature.asc Description: OpenPGP digital signature
[Puppet Users] Re: Resource ordering only using Hiera?
On Friday, December 13, 2013 3:56:50 PM UTC-6, Joseph Swick wrote:
[...]
What am I missing to get Puppet to evaluate the $resourceX_type
> variables as a resource type [e.g: File, Service, etc.] to get this to
> work?
Puppet DSL does not provide such a feature. It is conceivable -- likely,
even -- that you could instead create a custom function to apply generic
ordering constraints such as you want but you should beware that unlike
relationships declared via the DSL, relationships applied via a function
would probably be sensitive to manifest evaluation order.
> I'd like to try do it this way so that I don't have to make a
> very long, messy and hard to maintain class with a lot of nested case
> statements to perform a similar function. That is, unless there's some
> other method that I haven't considered/found/thought of.
>
> sample nested case code (this will get ugly fast and isn't very flexible):
> case $resource1_type {
> 'File': {
> case $resource2_type {
> 'Service': {
> if $notify {
> File[$resource1_name] ~> Service[$resource2_name]
> } else {
> File[$resource1_name] -> Service[$resource2_name]
> }
> }
> default: {fail("Unknown resource type '${resource2_type}' for
> \$resource2_type")}
> }
> }
> default: {fail("Unknown resource type '${resource1_type}' for
> \$resource1_type")}
> }
>
>
I suspect that the use case for the functionality you describe is not
nearly so general as you suppose. Module portability is more typically
approached in Puppet by using facts -- custom facts, if necessary -- to
probe the relevant characteristics of the target machine, and by using a
small number of higher-level alternatives to determine what to declare.
For example, it is common to use the $::osfamily fact to guide what
declarations to make, coding appropriate specifics for each supported OS
family.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/4198aa51-3ad3-40e7-86dd-3f3a60c9ec78%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Resource ordering problem...
After all that, it looks like the function was doing exactly what it was
designed to... Filtering out irrelevant data...
However feeding it incorrect filters meant that it was filtering
everything... Doh...
Cheers
Gavin
On Thursday, 31 January 2013 22:37:30 UTC, jcbollinger wrote:
>
>
>
> On Thursday, January 31, 2013 11:52:41 AM UTC-6, Gavin Williams wrote:
>>
>> Afternoon all
>>
>> I'm sure this is probably a nice n easy one, but I can't work it out for
>> the life of me...
>>
>> Anyhow, I've got the following code:
>> # Load db yaml data
>> $db_details = loadyaml('/etc/puppet/data/databases.yaml')
>>
>> notify{"DB Details loaded... About to parse.":}
>> ->
>> notify{"DB Details = ${db_details}.":}
>>
>> #$hostname = lookupvar('{hostname}')
>> # Parse data and filter to only primary databses for this server
>> $databases = parse_databases($db_details, 'database_primay_server',
>> $::hostname)
>>
>> notify{"Parsed db details, creating resources.":}
>> ->
>> notify{"Databases = ${databases}":}
>>
>> # Create required resources...
>> if $::oracle_netapp {
>> notify{"\$::oracle_netapp is true.":}
>> create_resources( act::env::oracle::instance::netapp, $databases)
>> }
>>
>> Parse_databases() is a custom function within one of my modules..
>>
>> The problem I've got is that parse_databases appears to be running before
>> loadyaml...
>> Example client run:
>> Notice: DB Details loaded... About to parse.
>> Notice: /Stage[main]/Act::Server::Linux::Db::Oracle/Notify[DB Details
>> loaded... About to parse.]/message: defined 'message' as 'DB Details
>> loaded... About to parse.'
>> Notice: Parsed db details, creating resources.
>> Notice: /Stage[main]/Act::Server::Linux::Db::Oracle/Notify[Parsed db
>> details, creating resources.]/message: defined 'message' as 'Parsed db
>> details, creating resources.'
>> Notice: Databases =
>> Notice: /Stage[main]/Act::Server::Linux::Db::Oracle/Notify[Databases =
>> ]/message: defined 'message' as 'Databases = '
>> Notice: $::oracle_netapp is true.
>> Notice:
>> /Stage[main]/Act::Server::Linux::Db::Oracle/Notify[$::oracle_netapp is
>> true.]/message: defined 'message' as '$::oracle_netapp is true.'
>> Notice: DB Details =
>> PUTEST01oracle_version11.2.0.3netapp_primary_controlleract-star-nactl02volumesoractrlsize1goradatasize100goraarchsnapscheduleminutes0which-hours0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23days0weeks0which-minutes0hours36size50gnetapp_snapmirror_controlleract-bun-nactl02database_primary_serveract-star-db05.
>> Notice: /Stage[main]/Act::Server::Linux::Db::Oracle/Notify[DB Details =
>> PUTEST01oracle_version11.2.0.3netapp_primary_controlleract-star-nactl02volumesoractrlsize1goradatasize100goraarchsnapscheduleminutes0which-hours0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23days0weeks0which-minutes0hours36size50gnetapp_snapmirror_controlleract-bun-nactl02database_primary_serveract-star-db05.]/message:
>>
>> defined 'message' as 'DB Details =
>> PUTEST01oracle_version11.2.0.3netapp_primary_controlleract-star-nactl02volumesoractrlsize1goradatasize100goraarchsnapscheduleminutes0which-hours0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23days0weeks0which-minutes0hours36size50gnetapp_snapmirror_controlleract-bun-nactl02database_primary_serveract-star-db05.'
>>
>> So how can I get the ordering right???
>>
>>
>
> The ordering is probably right already. At least, I don't see how we're
> supposed to infer otherwise from the agent's output. Functions execute on
> the master, at catalog compile time. The relative order in which resources
> are applied on the client, however, is constrained only by the
> relationships declared among them -- it does not inform about the order in
> which the resources were parsed, and informs only indirectly about the
> order in which functions in the declaring manifests were run.
>
> Class bodies are parsed left-to-right, top-to-bottom. You could use the
> notice() function to emit messages to the *master's* log about your
> evaluation order, but if you don't trust functions to be evaluated
> according to parse order then you'll want to include something in the
> notice() messages to prove it.
>
>
> John
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Resource ordering problem...
On Thursday, January 31, 2013 11:52:41 AM UTC-6, Gavin Williams wrote:
>
> Afternoon all
>
> I'm sure this is probably a nice n easy one, but I can't work it out for
> the life of me...
>
> Anyhow, I've got the following code:
> # Load db yaml data
> $db_details = loadyaml('/etc/puppet/data/databases.yaml')
>
> notify{"DB Details loaded... About to parse.":}
> ->
> notify{"DB Details = ${db_details}.":}
>
> #$hostname = lookupvar('{hostname}')
> # Parse data and filter to only primary databses for this server
> $databases = parse_databases($db_details, 'database_primay_server',
> $::hostname)
>
> notify{"Parsed db details, creating resources.":}
> ->
> notify{"Databases = ${databases}":}
>
> # Create required resources...
> if $::oracle_netapp {
> notify{"\$::oracle_netapp is true.":}
> create_resources( act::env::oracle::instance::netapp, $databases)
> }
>
> Parse_databases() is a custom function within one of my modules..
>
> The problem I've got is that parse_databases appears to be running before
> loadyaml...
> Example client run:
> Notice: DB Details loaded... About to parse.
> Notice: /Stage[main]/Act::Server::Linux::Db::Oracle/Notify[DB Details
> loaded... About to parse.]/message: defined 'message' as 'DB Details
> loaded... About to parse.'
> Notice: Parsed db details, creating resources.
> Notice: /Stage[main]/Act::Server::Linux::Db::Oracle/Notify[Parsed db
> details, creating resources.]/message: defined 'message' as 'Parsed db
> details, creating resources.'
> Notice: Databases =
> Notice: /Stage[main]/Act::Server::Linux::Db::Oracle/Notify[Databases =
> ]/message: defined 'message' as 'Databases = '
> Notice: $::oracle_netapp is true.
> Notice:
> /Stage[main]/Act::Server::Linux::Db::Oracle/Notify[$::oracle_netapp is
> true.]/message: defined 'message' as '$::oracle_netapp is true.'
> Notice: DB Details =
> PUTEST01oracle_version11.2.0.3netapp_primary_controlleract-star-nactl02volumesoractrlsize1goradatasize100goraarchsnapscheduleminutes0which-hours0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23days0weeks0which-minutes0hours36size50gnetapp_snapmirror_controlleract-bun-nactl02database_primary_serveract-star-db05.
> Notice: /Stage[main]/Act::Server::Linux::Db::Oracle/Notify[DB Details =
> PUTEST01oracle_version11.2.0.3netapp_primary_controlleract-star-nactl02volumesoractrlsize1goradatasize100goraarchsnapscheduleminutes0which-hours0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23days0weeks0which-minutes0hours36size50gnetapp_snapmirror_controlleract-bun-nactl02database_primary_serveract-star-db05.]/message:
>
> defined 'message' as 'DB Details =
> PUTEST01oracle_version11.2.0.3netapp_primary_controlleract-star-nactl02volumesoractrlsize1goradatasize100goraarchsnapscheduleminutes0which-hours0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23days0weeks0which-minutes0hours36size50gnetapp_snapmirror_controlleract-bun-nactl02database_primary_serveract-star-db05.'
>
> So how can I get the ordering right???
>
>
The ordering is probably right already. At least, I don't see how we're
supposed to infer otherwise from the agent's output. Functions execute on
the master, at catalog compile time. The relative order in which resources
are applied on the client, however, is constrained only by the
relationships declared among them -- it does not inform about the order in
which the resources were parsed, and informs only indirectly about the
order in which functions in the declaring manifests were run.
Class bodies are parsed left-to-right, top-to-bottom. You could use the
notice() function to emit messages to the *master's* log about your
evaluation order, but if you don't trust functions to be evaluated
according to parse order then you'll want to include something in the
notice() messages to prove it.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Resource ordering
For the most part, execs is it, but sometimes you might use it for a
file or for a custom type.
I suppose that it could be built into each type as necessary with just
as much effectiveness.
In this case though, we might want to set up logging for the exec only
on specific failure states.
I.e. 2 is no logging but 1 is logging.
Trevor
On Wed, Jul 22, 2009 at 09:31, Nigel Kersten wrote:
>
> On Wed, Jul 22, 2009 at 5:03 AM, Trevor Vaughan wrote:
>>
>> I was thinking of this in a very fine grained way, such as a metaparameter.
>>
>> The situation that made me think of this is:
>>
>> class foo {
>> file { 'super/important':
>> ensure => 'file',
>> content => 'something great\n'
>> }
>>
>> exec { 'nice to have happen':
>> command => 'check stuff and set a file',
>> fail => 'soft'
>> }
>> }
>>
>> class bar {
>> require 'foo'
>>
>> # stuff that requires super/important file
>> }
>>
>> Basically, the exec in 'foo' is there because it's logical to place it
>> there, but some of it (the exec) just doesn't matter if it fails or
>> not.
>>
>> I see this being most relevant in the case of execs, but could apply
>> to some situations where everything might be a soft failure except for
>> a service starting.
>
> I was thinking about this the other day, that sometimes it would be
> useful to be able to specify that you don't care about the return code
> of an exec.
>
> Alternatively, being able to specify a list of acceptable return codes
> like [ 0, 1, 4] would also give us close to the same functionality as
> far as soft failures go with execs.
>
> I'm wracking my brains, and I really can't think of anything other
> than execs that I'd want this for personally.
>
>
>>
>> Trevor
>>
>> On Wed, Jul 22, 2009 at 02:38, Luke Kanies wrote:
>>>
>>> On Jul 21, 2009, at 5:31 PM, Trevor Vaughan wrote:
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is going to be a great feature.
Over time, I've been struggling with trying to keep things extremely
modular (perhaps too much so) but still well ordered.
When I can make every class that needs apache just 'require apache', I
will be quite happy.
However, I think that this means that if *anything* in the class
fails,
the dependent classes will fail too, is this correct?
>>>
>>> Yes, the dependent classes will be skipped if any resources in the
>>> required classes fail.
>>>
Is there any way to make some things fail softly so that they can be
less hard than class-wise fatal?
>>>
>>> Hmm, no one's ever asked before.
>>>
>>> It seems reasonable that we could mark some resources as non-fatal,
>>> but what resources would you mark this way?
>>>
Thanks,
Trevor
On 07/21/2009 05:31 PM, James Turnbull wrote:
> Burkholder, Peter wrote:
>> I just finished listening to the Configuration Management panel from
>> OSBridge (on blip.tv).
>>
>> Near the end of it, Adam Jacob states that Puppet's resource
>> dependency
>> ordering is non-deterministic,
>> and that manifests that work fine 19 times will fail the 20th time.
>>
>> Is this true? I'm puzzled that what Luke considers one of Puppet's
>> strong suits is derided by
>> others as its Achille's heel.
>>
>
> There is a change in 0.25.0 that I also should have mentioned
> because it
> impacts this discussion.
>
> In 0.25.0 we've added a 'require' function. The doco is here:
>
> "Evaluate one or more classes, adding the required class as a
> dependency.
>
> The relationship metaparameters work well for specifying
> relationships
> between individual resources, but they can be clumsy for specifying
> relationships between classes. This function is a superset of the
> 'include' function, adding a class relationship so that the requiring
> class depends on the required class.
>
> .. Warning:: using require in place of include can lead to unwanted
> dependency cycles. For instance the following manifest, with
> 'require'
> instead of 'include' would produce a nasty dependence cycle, because
> notify imposes a before between File[/foo] and Service[foo]::
>
> class myservice {
> service { foo: ensure => running }
> }
>
> class otherstuff {
> include myservice
> file { '/foo': notify => Service[foo] }
> }
> "
>
> This takes some of the (potential) pain out of the ordering by
> allowing
> class level dependencies. This adds dependency resolution higher
> than
> between individual resources. It doesn't solve issues where you
> haven't
> built the right dependencies at a resource level but does provide
> more
> flexibility.
>
> This isn't the same as Chef - as Adam has pointed out Chef has top-
> down
> ordering rather than Puppet's dependency
[Puppet Users] Re: Resource ordering
On Wed, Jul 22, 2009 at 5:03 AM, Trevor Vaughan wrote:
>
> I was thinking of this in a very fine grained way, such as a metaparameter.
>
> The situation that made me think of this is:
>
> class foo {
> file { 'super/important':
> ensure => 'file',
> content => 'something great\n'
> }
>
> exec { 'nice to have happen':
> command => 'check stuff and set a file',
> fail => 'soft'
> }
> }
>
> class bar {
> require 'foo'
>
> # stuff that requires super/important file
> }
>
> Basically, the exec in 'foo' is there because it's logical to place it
> there, but some of it (the exec) just doesn't matter if it fails or
> not.
>
> I see this being most relevant in the case of execs, but could apply
> to some situations where everything might be a soft failure except for
> a service starting.
I was thinking about this the other day, that sometimes it would be
useful to be able to specify that you don't care about the return code
of an exec.
Alternatively, being able to specify a list of acceptable return codes
like [ 0, 1, 4] would also give us close to the same functionality as
far as soft failures go with execs.
I'm wracking my brains, and I really can't think of anything other
than execs that I'd want this for personally.
>
> Trevor
>
> On Wed, Jul 22, 2009 at 02:38, Luke Kanies wrote:
>>
>> On Jul 21, 2009, at 5:31 PM, Trevor Vaughan wrote:
>>
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> This is going to be a great feature.
>>>
>>> Over time, I've been struggling with trying to keep things extremely
>>> modular (perhaps too much so) but still well ordered.
>>>
>>> When I can make every class that needs apache just 'require apache', I
>>> will be quite happy.
>>>
>>> However, I think that this means that if *anything* in the class
>>> fails,
>>> the dependent classes will fail too, is this correct?
>>
>> Yes, the dependent classes will be skipped if any resources in the
>> required classes fail.
>>
>>>
>>> Is there any way to make some things fail softly so that they can be
>>> less hard than class-wise fatal?
>>
>> Hmm, no one's ever asked before.
>>
>> It seems reasonable that we could mark some resources as non-fatal,
>> but what resources would you mark this way?
>>
>>>
>>> Thanks,
>>>
>>> Trevor
>>>
>>> On 07/21/2009 05:31 PM, James Turnbull wrote:
Burkholder, Peter wrote:
> I just finished listening to the Configuration Management panel from
> OSBridge (on blip.tv).
>
> Near the end of it, Adam Jacob states that Puppet's resource
> dependency
> ordering is non-deterministic,
> and that manifests that work fine 19 times will fail the 20th time.
>
> Is this true? I'm puzzled that what Luke considers one of Puppet's
> strong suits is derided by
> others as its Achille's heel.
>
There is a change in 0.25.0 that I also should have mentioned
because it
impacts this discussion.
In 0.25.0 we've added a 'require' function. The doco is here:
"Evaluate one or more classes, adding the required class as a
dependency.
The relationship metaparameters work well for specifying
relationships
between individual resources, but they can be clumsy for specifying
relationships between classes. This function is a superset of the
'include' function, adding a class relationship so that the requiring
class depends on the required class.
.. Warning:: using require in place of include can lead to unwanted
dependency cycles. For instance the following manifest, with
'require'
instead of 'include' would produce a nasty dependence cycle, because
notify imposes a before between File[/foo] and Service[foo]::
class myservice {
service { foo: ensure => running }
}
class otherstuff {
include myservice
file { '/foo': notify => Service[foo] }
}
"
This takes some of the (potential) pain out of the ordering by
allowing
class level dependencies. This adds dependency resolution higher
than
between individual resources. It doesn't solve issues where you
haven't
built the right dependencies at a resource level but does provide
more
flexibility.
This isn't the same as Chef - as Adam has pointed out Chef has top-
down
ordering rather than Puppet's dependency graph - but I think it'll
make
life easier for some people.
Regards
James Turnbull
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>>
>>> iEYEARECAAYFAkpmXc4ACgkQyjMdFR1108BPnwCbBAYZ+kFWaKrORho1NOZK6+Ij
>>> bNQAn2bb0SDw0aofNRH0wKf/fv5iDpzw
>>> =eDIA
>>> -END PGP SIGNATURE-
>>>
>>> >
>>
>>
>> --
>> In our civilization, and under our republican form of government,
>> intelligence is so highly honored that it is rewarded by exemption from
>> the cares of office. --Ambrose Bierc
[Puppet Users] Re: Resource ordering
It's not semi-satisfied in cases where you might be waiting for cross-system semaphores to complete and you don't want to fire anything else off until they are. Trevor > On Wed, Jul 22, 2009 at 08:26, Peter Meier wrote: >> Hi >> >>> [discussion about soft failing] >> >> hmm I don't see why you'd like to have your environment in a semi-satisfied >> state. Either your environment is in the state is broken or you have to fix >> it. Everything else is imho just scary... >> >> cheers pete >> > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
Hi > [discussion about soft failing] hmm I don't see why you'd like to have your environment in a semi-satisfied state. Either your environment is in the state is broken or you have to fix it. Everything else is imho just scary... cheers pete --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
I was thinking of this in a very fine grained way, such as a metaparameter.
The situation that made me think of this is:
class foo {
file { 'super/important':
ensure => 'file',
content => 'something great\n'
}
exec { 'nice to have happen':
command => 'check stuff and set a file',
fail => 'soft'
}
}
class bar {
require 'foo'
# stuff that requires super/important file
}
Basically, the exec in 'foo' is there because it's logical to place it
there, but some of it (the exec) just doesn't matter if it fails or
not.
I see this being most relevant in the case of execs, but could apply
to some situations where everything might be a soft failure except for
a service starting.
Trevor
On Wed, Jul 22, 2009 at 02:38, Luke Kanies wrote:
>
> On Jul 21, 2009, at 5:31 PM, Trevor Vaughan wrote:
>
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> This is going to be a great feature.
>>
>> Over time, I've been struggling with trying to keep things extremely
>> modular (perhaps too much so) but still well ordered.
>>
>> When I can make every class that needs apache just 'require apache', I
>> will be quite happy.
>>
>> However, I think that this means that if *anything* in the class
>> fails,
>> the dependent classes will fail too, is this correct?
>
> Yes, the dependent classes will be skipped if any resources in the
> required classes fail.
>
>>
>> Is there any way to make some things fail softly so that they can be
>> less hard than class-wise fatal?
>
> Hmm, no one's ever asked before.
>
> It seems reasonable that we could mark some resources as non-fatal,
> but what resources would you mark this way?
>
>>
>> Thanks,
>>
>> Trevor
>>
>> On 07/21/2009 05:31 PM, James Turnbull wrote:
>>> Burkholder, Peter wrote:
I just finished listening to the Configuration Management panel from
OSBridge (on blip.tv).
Near the end of it, Adam Jacob states that Puppet's resource
dependency
ordering is non-deterministic,
and that manifests that work fine 19 times will fail the 20th time.
Is this true? I'm puzzled that what Luke considers one of Puppet's
strong suits is derided by
others as its Achille's heel.
>>>
>>> There is a change in 0.25.0 that I also should have mentioned
>>> because it
>>> impacts this discussion.
>>>
>>> In 0.25.0 we've added a 'require' function. The doco is here:
>>>
>>> "Evaluate one or more classes, adding the required class as a
>>> dependency.
>>>
>>> The relationship metaparameters work well for specifying
>>> relationships
>>> between individual resources, but they can be clumsy for specifying
>>> relationships between classes. This function is a superset of the
>>> 'include' function, adding a class relationship so that the requiring
>>> class depends on the required class.
>>>
>>> .. Warning:: using require in place of include can lead to unwanted
>>> dependency cycles. For instance the following manifest, with
>>> 'require'
>>> instead of 'include' would produce a nasty dependence cycle, because
>>> notify imposes a before between File[/foo] and Service[foo]::
>>>
>>> class myservice {
>>> service { foo: ensure => running }
>>> }
>>>
>>> class otherstuff {
>>> include myservice
>>> file { '/foo': notify => Service[foo] }
>>> }
>>> "
>>>
>>> This takes some of the (potential) pain out of the ordering by
>>> allowing
>>> class level dependencies. This adds dependency resolution higher
>>> than
>>> between individual resources. It doesn't solve issues where you
>>> haven't
>>> built the right dependencies at a resource level but does provide
>>> more
>>> flexibility.
>>>
>>> This isn't the same as Chef - as Adam has pointed out Chef has top-
>>> down
>>> ordering rather than Puppet's dependency graph - but I think it'll
>>> make
>>> life easier for some people.
>>>
>>> Regards
>>>
>>> James Turnbull
>>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iEYEARECAAYFAkpmXc4ACgkQyjMdFR1108BPnwCbBAYZ+kFWaKrORho1NOZK6+Ij
>> bNQAn2bb0SDw0aofNRH0wKf/fv5iDpzw
>> =eDIA
>> -END PGP SIGNATURE-
>>
>> >
>
>
> --
> In our civilization, and under our republican form of government,
> intelligence is so highly honored that it is rewarded by exemption from
> the cares of office. --Ambrose Bierce
> -
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
Luke Kanies wrote: > On Jul 21, 2009, at 5:31 PM, Trevor Vaughan wrote: >> Is there any way to make some things fail softly so that they can be >> less hard than class-wise fatal? > > Hmm, no one's ever asked before. > > It seems reasonable that we could mark some resources as non-fatal, > but what resources would you mark this way? Probably stuff like setting up logrotate? That's not really critical to the operation of the webserver. Of course, in an ideal world, that hypothetical problem with logrotate would be fixed before using the server in production, but ... Regards, DavidS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luke Kanies wrote: > Is there any way to make some things fail softly so that they can be > less hard than class-wise fatal? > >> Hmm, no one's ever asked before. > >> It seems reasonable that we could mark some resources as non-fatal, >> but what resources would you mark this way? Could you mark an include or require as non-fatal? Would that achieve the same end? Regards James Turnbull - -- Author of: * Pro Linux Systems Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpmuLgACgkQ9hTGvAxC30DlSgCglgaRghC8SMp+IBfTyBv3OAzS RLMAoJf/9XyPqLkEFdVBJFNBgu+lyTeH =NHy2 -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
On Jul 21, 2009, at 5:31 PM, Trevor Vaughan wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This is going to be a great feature.
>
> Over time, I've been struggling with trying to keep things extremely
> modular (perhaps too much so) but still well ordered.
>
> When I can make every class that needs apache just 'require apache', I
> will be quite happy.
>
> However, I think that this means that if *anything* in the class
> fails,
> the dependent classes will fail too, is this correct?
Yes, the dependent classes will be skipped if any resources in the
required classes fail.
>
> Is there any way to make some things fail softly so that they can be
> less hard than class-wise fatal?
Hmm, no one's ever asked before.
It seems reasonable that we could mark some resources as non-fatal,
but what resources would you mark this way?
>
> Thanks,
>
> Trevor
>
> On 07/21/2009 05:31 PM, James Turnbull wrote:
>> Burkholder, Peter wrote:
>>> I just finished listening to the Configuration Management panel from
>>> OSBridge (on blip.tv).
>>>
>>> Near the end of it, Adam Jacob states that Puppet's resource
>>> dependency
>>> ordering is non-deterministic,
>>> and that manifests that work fine 19 times will fail the 20th time.
>>>
>>> Is this true? I'm puzzled that what Luke considers one of Puppet's
>>> strong suits is derided by
>>> others as its Achille's heel.
>>>
>>
>> There is a change in 0.25.0 that I also should have mentioned
>> because it
>> impacts this discussion.
>>
>> In 0.25.0 we've added a 'require' function. The doco is here:
>>
>> "Evaluate one or more classes, adding the required class as a
>> dependency.
>>
>> The relationship metaparameters work well for specifying
>> relationships
>> between individual resources, but they can be clumsy for specifying
>> relationships between classes. This function is a superset of the
>> 'include' function, adding a class relationship so that the requiring
>> class depends on the required class.
>>
>> .. Warning:: using require in place of include can lead to unwanted
>> dependency cycles. For instance the following manifest, with
>> 'require'
>> instead of 'include' would produce a nasty dependence cycle, because
>> notify imposes a before between File[/foo] and Service[foo]::
>>
>>class myservice {
>> service { foo: ensure => running }
>>}
>>
>>class otherstuff {
>> include myservice
>> file { '/foo': notify => Service[foo] }
>>}
>> "
>>
>> This takes some of the (potential) pain out of the ordering by
>> allowing
>> class level dependencies. This adds dependency resolution higher
>> than
>> between individual resources. It doesn't solve issues where you
>> haven't
>> built the right dependencies at a resource level but does provide
>> more
>> flexibility.
>>
>> This isn't the same as Chef - as Adam has pointed out Chef has top-
>> down
>> ordering rather than Puppet's dependency graph - but I think it'll
>> make
>> life easier for some people.
>>
>> Regards
>>
>> James Turnbull
>>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkpmXc4ACgkQyjMdFR1108BPnwCbBAYZ+kFWaKrORho1NOZK6+Ij
> bNQAn2bb0SDw0aofNRH0wKf/fv5iDpzw
> =eDIA
> -END PGP SIGNATURE-
>
> >
--
In our civilization, and under our republican form of government,
intelligence is so highly honored that it is rewarded by exemption from
the cares of office. --Ambrose Bierce
-
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is going to be a great feature.
Over time, I've been struggling with trying to keep things extremely
modular (perhaps too much so) but still well ordered.
When I can make every class that needs apache just 'require apache', I
will be quite happy.
However, I think that this means that if *anything* in the class fails,
the dependent classes will fail too, is this correct?
Is there any way to make some things fail softly so that they can be
less hard than class-wise fatal?
Thanks,
Trevor
On 07/21/2009 05:31 PM, James Turnbull wrote:
> Burkholder, Peter wrote:
>> I just finished listening to the Configuration Management panel from
>> OSBridge (on blip.tv).
>>
>> Near the end of it, Adam Jacob states that Puppet's resource dependency
>> ordering is non-deterministic,
>> and that manifests that work fine 19 times will fail the 20th time.
>>
>> Is this true? I'm puzzled that what Luke considers one of Puppet's
>> strong suits is derided by
>> others as its Achille's heel.
>>
>
> There is a change in 0.25.0 that I also should have mentioned because it
> impacts this discussion.
>
> In 0.25.0 we've added a 'require' function. The doco is here:
>
> "Evaluate one or more classes, adding the required class as a dependency.
>
> The relationship metaparameters work well for specifying relationships
> between individual resources, but they can be clumsy for specifying
> relationships between classes. This function is a superset of the
> 'include' function, adding a class relationship so that the requiring
> class depends on the required class.
>
> .. Warning:: using require in place of include can lead to unwanted
> dependency cycles. For instance the following manifest, with 'require'
> instead of 'include' would produce a nasty dependence cycle, because
> notify imposes a before between File[/foo] and Service[foo]::
>
> class myservice {
>service { foo: ensure => running }
> }
>
> class otherstuff {
>include myservice
>file { '/foo': notify => Service[foo] }
> }
> "
>
> This takes some of the (potential) pain out of the ordering by allowing
> class level dependencies. This adds dependency resolution higher than
> between individual resources. It doesn't solve issues where you haven't
> built the right dependencies at a resource level but does provide more
> flexibility.
>
> This isn't the same as Chef - as Adam has pointed out Chef has top-down
> ordering rather than Puppet's dependency graph - but I think it'll make
> life easier for some people.
>
> Regards
>
> James Turnbull
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpmXc4ACgkQyjMdFR1108BPnwCbBAYZ+kFWaKrORho1NOZK6+Ij
bNQAn2bb0SDw0aofNRH0wKf/fv5iDpzw
=eDIA
-END PGP SIGNATURE-
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
On Jul 17, 2009, at 6:08 AM, Burkholder, Peter wrote: > > I just finished listening to the Configuration Management panel from > OSBridge (on blip.tv). > > Near the end of it, Adam Jacob states that Puppet's resource > dependency > ordering is non-deterministic, > and that manifests that work fine 19 times will fail the 20th time. > > Is this true? I'm puzzled that what Luke considers one of Puppet's > strong suits is derided by > others as its Achille's heel. Dependency ordering is entirely deterministic. Ordering of unrelated items, just like in any other topological sort of a graph, is currently nondeterministic. We could trivially add deterministic ordering for unrelated items: Just sort any equivalent resources based on name. Ten seconds after you do this, you'll have people naming resources things like '1myservice' because they want to use alphabetic sorting instead of declared dependencies, and then they'll complain when specified dependencies get preference. Basically, once we start saying "unrelated resources will always happen in a predictable order", we can never change the internal implementation or add parallelism. There might be some ways to increase consistency without sacrificing these, but no one besides Adam has complained much about it, and he was never willing to actually contribute code to fixing it. -- It's very hard to predict things . . . Especially the future. -- Prof. Charles Kelemen, Swarthmore CS Dept. - Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
Burkholder, Peter wrote:
> I just finished listening to the Configuration Management panel from
> OSBridge (on blip.tv).
>
> Near the end of it, Adam Jacob states that Puppet's resource dependency
> ordering is non-deterministic,
> and that manifests that work fine 19 times will fail the 20th time.
>
> Is this true? I'm puzzled that what Luke considers one of Puppet's
> strong suits is derided by
> others as its Achille's heel.
>
There is a change in 0.25.0 that I also should have mentioned because it
impacts this discussion.
In 0.25.0 we've added a 'require' function. The doco is here:
"Evaluate one or more classes, adding the required class as a dependency.
The relationship metaparameters work well for specifying relationships
between individual resources, but they can be clumsy for specifying
relationships between classes. This function is a superset of the
'include' function, adding a class relationship so that the requiring
class depends on the required class.
.. Warning:: using require in place of include can lead to unwanted
dependency cycles. For instance the following manifest, with 'require'
instead of 'include' would produce a nasty dependence cycle, because
notify imposes a before between File[/foo] and Service[foo]::
class myservice {
service { foo: ensure => running }
}
class otherstuff {
include myservice
file { '/foo': notify => Service[foo] }
}
"
This takes some of the (potential) pain out of the ordering by allowing
class level dependencies. This adds dependency resolution higher than
between individual resources. It doesn't solve issues where you haven't
built the right dependencies at a resource level but does provide more
flexibility.
This isn't the same as Chef - as Adam has pointed out Chef has top-down
ordering rather than Puppet's dependency graph - but I think it'll make
life easier for some people.
Regards
James Turnbull
--
Author of:
* Pro Linux Systems Administration
(http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet
(http://tinyurl.com/pupbook)
* Pro Nagios 2.0
(http://tinyurl.com/pronagios)
* Hardening Linux
(http://tinyurl.com/hardeninglinux)
signature.asc
Description: OpenPGP digital signature
[Puppet Users] Re: Resource ordering
I'm not biased and I also agree with Paul and James. While I have had trouble with getting my order right in some cases, it was generally a failing of the item that I was trying to configure *not* a problem with Puppet. It comes down to ordering something in a file implicitly or explicitly and I actually prefer to tap explicit order for the potential optimization benefits. I.e. when Ruby 1.9 is in widespread use with native threads then you'll be able to get much better performance overall on multi-processor systems because everything that isn't explicitly serialized can be done in parallel. Trevor On Mon, Jul 20, 2009 at 18:17, James Turnbull wrote: > Paul Lathrop wrote: >>> Is this true? I'm puzzled that what Luke considers one of Puppet's >>> strong suits is derided by >>> others as its Achille's heel. >> >> This is true w/o being the whole story. Puppet obeys declared >> dependencies, but if you choose not to declare your dependencies, you >> are running the risk of things happening in the wrong order. To me, >> this is a bug in your manifests, not a bug in Puppet. Adam doesn't >> believe this is a good thing. However, I have found that it gives me a >> couple advantages: a) it forces me to really think about the order of >> events and determine what is actually dependent on what; b) it allows >> me to ignore the order of things when it doesn't matter, but often >> reveals situations where it *does* matter and I didn't think of it; c) >> there is potential for future optimization; d) I find explicitly >> declaring dependencies to be preferable to re-arranging lines in a >> file and finding things magically working. > > Whilst personally immensely biased I strongly agree with Paul. I was > taught (had beaten into me?) as a sys-admin to think through my actions, > plan them and understand sequencing and consequences (old school > mainframe shop). I think that's a critical skill for a sysadmin and if > Puppet forces people to do this when order matters... it's not a bad thing. > > Regards > > James Turnbull > > -- > Author of: > * Pro Linux Systems Administration > (http://tinyurl.com/linuxadmin) > * Pulling Strings with Puppet > (http://tinyurl.com/pupbook) > * Pro Nagios 2.0 > (http://tinyurl.com/pronagios) > * Hardening Linux > (http://tinyurl.com/hardeninglinux) > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
Paul Lathrop wrote: >> Is this true? I'm puzzled that what Luke considers one of Puppet's >> strong suits is derided by >> others as its Achille's heel. > > This is true w/o being the whole story. Puppet obeys declared > dependencies, but if you choose not to declare your dependencies, you > are running the risk of things happening in the wrong order. To me, > this is a bug in your manifests, not a bug in Puppet. Adam doesn't > believe this is a good thing. However, I have found that it gives me a > couple advantages: a) it forces me to really think about the order of > events and determine what is actually dependent on what; b) it allows > me to ignore the order of things when it doesn't matter, but often > reveals situations where it *does* matter and I didn't think of it; c) > there is potential for future optimization; d) I find explicitly > declaring dependencies to be preferable to re-arranging lines in a > file and finding things magically working. Whilst personally immensely biased I strongly agree with Paul. I was taught (had beaten into me?) as a sys-admin to think through my actions, plan them and understand sequencing and consequences (old school mainframe shop). I think that's a critical skill for a sysadmin and if Puppet forces people to do this when order matters... it's not a bad thing. Regards James Turnbull -- Author of: * Pro Linux Systems Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) signature.asc Description: OpenPGP digital signature
[Puppet Users] Re: Resource ordering
On Fri, Jul 17, 2009 at 6:08 AM, Burkholder, Peter wrote: > > I just finished listening to the Configuration Management panel from > OSBridge (on blip.tv). > > Near the end of it, Adam Jacob states that Puppet's resource dependency > ordering is non-deterministic, > and that manifests that work fine 19 times will fail the 20th time. > > Is this true? I'm puzzled that what Luke considers one of Puppet's > strong suits is derided by > others as its Achille's heel. This is true w/o being the whole story. Puppet obeys declared dependencies, but if you choose not to declare your dependencies, you are running the risk of things happening in the wrong order. To me, this is a bug in your manifests, not a bug in Puppet. Adam doesn't believe this is a good thing. However, I have found that it gives me a couple advantages: a) it forces me to really think about the order of events and determine what is actually dependent on what; b) it allows me to ignore the order of things when it doesn't matter, but often reveals situations where it *does* matter and I didn't think of it; c) there is potential for future optimization; d) I find explicitly declaring dependencies to be preferable to re-arranging lines in a file and finding things magically working. --Paul --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
2009/7/17 Burkholder, Peter > > I just finished listening to the Configuration Management panel from > OSBridge (on blip.tv). > > Near the end of it, Adam Jacob states that Puppet's resource dependency > ordering is non-deterministic, > and that manifests that work fine 19 times will fail the 20th time. > > Is this true? I'm puzzled that what Luke considers one of Puppet's > strong suits is derided by > others as its Achille's heel. > > -Peter > > If you use a bit of common sense when writing your manifests and set order the same way you would when installing this on the command line it will work 20 out of 20 times. You just set eg the require parameter or before parameter, easy and straight forward. It's not that different from programming either. Calling a function that does not yet exist can easily throw an error.. It's better to have a system letting you set the order explicitly when needed than having a system trying to figure out this in some automagically way and wind up being a pain to use. Regards --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
Burkholder, Peter wrote: > I just finished listening to the Configuration Management panel from > OSBridge (on blip.tv). > > Near the end of it, Adam Jacob states that Puppet's resource dependency > ordering is non-deterministic, > and that manifests that work fine 19 times will fail the 20th time. > > Is this true? I'm puzzled that what Luke considers one of Puppet's > strong suits is derided by > others as its Achille's heel. Puppet's ordering of how it'll apply resources is only deterministic up to the specified dependencies in the manifest. Not requiring more determinism allows puppet to optimize resource application (in the future; see e.g. the thread about coalescing package installations). Of course, this might allow situations like those Adam talks about if the manifest doesn't state all the implicit dependencies explicitly. Like trying to start a service before the daemon is installed. Regards, DavidS --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Resource ordering
Perhaps if you didn't declare the dependencies accurately, some orderings would work and some orderings would fail. Seems no different to a declarative build tool in that respect. Julian. 2009/7/17 Burkholder, Peter : > > I just finished listening to the Configuration Management panel from > OSBridge (on blip.tv). > > Near the end of it, Adam Jacob states that Puppet's resource dependency > ordering is non-deterministic, > and that manifests that work fine 19 times will fail the 20th time. > > Is this true? I'm puzzled that what Luke considers one of Puppet's > strong suits is derided by > others as its Achille's heel. > > -Peter > > > -- > Peter Burkholder > AARP | Web Strategy & Operations | 601 E Street, NW | Washington, DC > 20049 > email: pburkhol...@aarp.org | aim: peterbtech | ph: 202-434-3530 | cell: > 202-344-7129 | > > > > -- Julian Simpson Software Build and Deployment http://www.build-doctor.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
