FAQ
Why does this:

Class['network::base'] -> Class['apt::base'] -> Class['lvm::setup'] ->
Class <| |>

generate this error?

err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Resource type class doesn't exist at
/truth/sauce/env/prod/modules/role/manifests/common.pp:18 on node
mon01.ap1.xxx.com
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

I've been repeatedly told to stop using run stages, and use resource
chaining instead. However, without putting the Class <| |> at the end,
to indicate that every other class should come afterwards, the
functionality is not the same. With run stages, I could specify that
classes A, B and C should applied first, before everything else.

Omitting the Class <| |> from the end gets rid of the error. However,
this means that there is no guarantee that these three classes will be
applied before the rest.

Hoping Mr Pienaar doesn't thing that such a scandalous and negative
question is not considered anti social behaviour.

Doug.

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Calvin Walton at Sep 10, 2012 at 8:47 pm

    On Mon, 2012-09-10 at 12:34 -0700, Douglas Garstang wrote:
    Why does this:

    Class['network::base'] -> Class['apt::base'] -> Class['lvm::setup'] ->
    Class <| |>

    generate this error?

    err: Could not retrieve catalog from remote server: Error 400 on
    SERVER: Resource type class doesn't exist at
    /truth/sauce/env/prod/modules/role/manifests/common.pp:18 on node
    mon01.ap1.xxx.com
    warning: Not using cache on failed catalog
    err: Could not retrieve catalog; skipping run
    Classes are not resources. As a result, you cannot use the resource
    collection syntax <| |> on classes.

    Even if it worked, this wouldn't do what you wanted! Class <| |> would
    include Class['network::base'] and all the others, giving dependency
    cycles, like this:

    Class['network::base'] -> Class['apt::base'] -> Class['lvm::setup'] -> Class['network::base']
    I've been repeatedly told to stop using run stages, and use resource
    chaining instead. However, without putting the Class <| |> at the end,
    to indicate that every other class should come afterwards, the
    functionality is not the same. With run stages, I could specify that
    classes A, B and C should applied first, before everything else.
    If you're sure that you will always need these classes run before
    everything else, a run stage might still make sense. You would want to
    have one run stage in addition to main, perhaps like this:

    stage { 'early_setup':
    before => Stage['main'],
    }

    class { 'network::base':
    stage => 'early_setup',
    }
    class { 'apt::base':
    stage => 'early_setup',
    }
    class { 'lvm::setup':
    stage => 'early_setup',
    }

    Class['network::base'] -> Class['apt::base'] -> Class['lvm::setup']

    (In your case, you'd want to put the exec for apt-get update into the
    same 'early_setup' stage as well, for example by putting it into the
    apt::base class). If you later add additional apt repositories, you'd
    have to put them into the same early stage as well, so they can be
    configured before doing the apt-get update.

    Everything else can then go in the main stage, and should be ordered
    only relative to each-other.

    The general advice that I've seen is that you should use a limited
    number of stages only for cases like this where you need some system
    setup that is independent of the other things that you'll be installing
    on the system, and must be ordered before (or after) *everything* else.

    Do keep in mind the things listed in
    http://docs.puppetlabs.com/puppet/2.7/reference/lang_run_stages.html#limitations-and-known-issues
    in particular, make sure that the classes in the non-main stage don't
    include other classes without setting the stage on them as well!

    --
    Calvin Walton <calvin.walton@kepstin.ca>

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Douglas Garstang at Sep 10, 2012 at 9:14 pm

    On Mon, Sep 10, 2012 at 1:41 PM, Calvin Walton wrote:
    On Mon, 2012-09-10 at 12:34 -0700, Douglas Garstang wrote:
    Why does this:

    Class['network::base'] -> Class['apt::base'] -> Class['lvm::setup'] ->
    Class <| |>

    generate this error?

    err: Could not retrieve catalog from remote server: Error 400 on
    SERVER: Resource type class doesn't exist at
    /truth/sauce/env/prod/modules/role/manifests/common.pp:18 on node
    mon01.ap1.xxx.com
    warning: Not using cache on failed catalog
    err: Could not retrieve catalog; skipping run
    Classes are not resources. As a result, you cannot use the resource
    collection syntax <| |> on classes.

    Even if it worked, this wouldn't do what you wanted! Class <| |> would
    include Class['network::base'] and all the others, giving dependency
    cycles, like this:

    Class['network::base'] -> Class['apt::base'] -> Class['lvm::setup'] -> Class['network::base']
    I've been repeatedly told to stop using run stages, and use resource
    chaining instead. However, without putting the Class <| |> at the end,
    to indicate that every other class should come afterwards, the
    functionality is not the same. With run stages, I could specify that
    classes A, B and C should applied first, before everything else.
    If you're sure that you will always need these classes run before
    everything else, a run stage might still make sense. You would want to
    have one run stage in addition to main, perhaps like this:

    stage { 'early_setup':
    before => Stage['main'],
    }

    class { 'network::base':
    stage => 'early_setup',
    }
    class { 'apt::base':
    stage => 'early_setup',
    }
    class { 'lvm::setup':
    stage => 'early_setup',
    }

    Class['network::base'] -> Class['apt::base'] -> Class['lvm::setup']

    (In your case, you'd want to put the exec for apt-get update into the
    same 'early_setup' stage as well, for example by putting it into the
    apt::base class). If you later add additional apt repositories, you'd
    have to put them into the same early stage as well, so they can be
    configured before doing the apt-get update.

    Everything else can then go in the main stage, and should be ordered
    only relative to each-other.

    The general advice that I've seen is that you should use a limited
    number of stages only for cases like this where you need some system
    setup that is independent of the other things that you'll be installing
    on the system, and must be ordered before (or after) *everything* else.

    Do keep in mind the things listed in
    http://docs.puppetlabs.com/puppet/2.7/reference/lang_run_stages.html#limitations-and-known-issues
    in particular, make sure that the classes in the non-main stage don't
    include other classes without setting the stage on them as well!
    Calvin,

    Thanks. Your describing exactly what I had, before I was told to stop
    using run stages and use resource chaining instead. Apparently
    resource chaining provides the same functionality as run stages. Seems
    that it indeed does not.

    Doug.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • David Schmitt at Sep 11, 2012 at 6:29 am

    On 2012-09-10 23:14, Douglas Garstang wrote:
    Calvin,

    Thanks. Your describing exactly what I had, before I was told to stop
    using run stages and use resource chaining instead. Apparently
    resource chaining provides the same functionality as run stages.
    IIUIC, stages "only" add dependencies between the underlying resources
    and act as a shortcut to specifying those dependencies manually.

    The downside of such shotgun approaches is that it is very easy to run
    into dependency cycles if one doesn't carefully restrict what goes
    where. But in this case there is no difference between using stages and
    manually creating dependencies, as the same cycles will be created.



    Best Regards, D.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedSep 10, '12 at 7:39p
activeSep 11, '12 at 6:29a
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase