FAQ
I started getting the following errors from my puppet master:
Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: Invalid parameter provider at /some/module/manifests/foo.pp

The module would vary, but the error was always the same. I started
googling, searching lists, etc. And turned up a whole bucket load of issues
that all seem related and are all unresolved:

#17814, #13858, #12173, #8750, etc.

Some go back over 2 years and some are current from within the last month,
but they're all linked.

Am I mistaken/misinterpreting or do they all seem to boil down to
"environments are broken".

If I am mistaken, what's the workaround? I was really looking forward to
mapping environments to git branches with git hooks.

--
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+unsubscribe@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.

Search Discussions

  • Jcbollinger at May 9, 2013 at 1:33 pm

    On Wednesday, May 8, 2013 8:06:27 PM UTC-5, James Kyle wrote:
    I started getting the following errors from my puppet master:
    Error: Could not retrieve catalog from remote server: Error 400 on
    SERVER: Invalid parameter provider at /some/module/manifests/foo.pp

    The module would vary, but the error was always the same. I started
    googling, searching lists, etc. And turned up a whole bucket load of issues
    that all seem related and are all unresolved:

    #17814, #13858, #12173, #8750, etc.

    Some go back over 2 years and some are current from within the last month,
    but they're all linked.

    Am I mistaken/misinterpreting or do they all seem to boil down to
    "environments are broken".

    If I am mistaken, what's the workaround? I was really looking forward to
    mapping environments to git branches with git hooks.

    I think it's fair to say that environments are a bit crippled.
    Principally, trouble with environments revolves around modules that provide
    native components (types, providers, or functions) that are not uniform
    across all defined environments. Where your environment-specific modules
    do not provide such things (and many don't), environments should work for
    you.

    These problems are unlikely to be fixed soon, as they stem from a deep
    architectural issue. Puppet really needs some kind of internal abstraction
    with which to group and separate the components associated with each
    environment, but it doesn't have one, and adding one would likely be a lot
    of work. Even if PL is persuaded to prioritize the issue, I cannot imagine
    a solution being released before Puppet 3.3 (and that may be overly
    optimistic).


    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+unsubscribe@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.
  • James Kyle at May 9, 2013 at 3:36 pm
    Hm, I started seeing this when I moved to a dynamic environment
    configuration and began incorporating the openstack modules.

    Are there workarounds or rules of thumb to avoid it while still being able
    to use environments?

    -james
    On Thursday, May 9, 2013 6:33:38 AM UTC-7, jcbollinger wrote:


    On Wednesday, May 8, 2013 8:06:27 PM UTC-5, James Kyle wrote:

    I started getting the following errors from my puppet master:
    Error: Could not retrieve catalog from remote server: Error 400 on
    SERVER: Invalid parameter provider at /some/module/manifests/foo.pp

    The module would vary, but the error was always the same. I started
    googling, searching lists, etc. And turned up a whole bucket load of issues
    that all seem related and are all unresolved:

    #17814, #13858, #12173, #8750, etc.

    Some go back over 2 years and some are current from within the last
    month, but they're all linked.

    Am I mistaken/misinterpreting or do they all seem to boil down to
    "environments are broken".

    If I am mistaken, what's the workaround? I was really looking forward to
    mapping environments to git branches with git hooks.

    I think it's fair to say that environments are a bit crippled.
    Principally, trouble with environments revolves around modules that provide
    native components (types, providers, or functions) that are not uniform
    across all defined environments. Where your environment-specific modules
    do not provide such things (and many don't), environments should work for
    you.

    These problems are unlikely to be fixed soon, as they stem from a deep
    architectural issue. Puppet really needs some kind of internal abstraction
    with which to group and separate the components associated with each
    environment, but it doesn't have one, and adding one would likely be a lot
    of work. Even if PL is persuaded to prioritize the issue, I cannot imagine
    a solution being released before Puppet 3.3 (and that may be overly
    optimistic).


    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+unsubscribe@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.
  • Jcbollinger at May 10, 2013 at 1:14 pm

    On Thursday, May 9, 2013 10:36:23 AM UTC-5, James Kyle wrote:

    Hm, I started seeing this when I moved to a dynamic environment
    configuration and began incorporating the openstack modules.

    Are there workarounds or rules of thumb to avoid it while still being able
    to use environments?
    It depends on how you are trying to use environments. If you are using any
    modules that provide native components (which might not be obvious) then
    you should avoid using different versions of those modules in different
    environments. Depending on how your master is managed, you may also need
    to manually install the Ruby bits of some or all of those modules into the
    master (more than just dropping the module into place). If that won't work
    for you, then you have a 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+unsubscribe@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.
  • Jakov Sosic at Jul 2, 2013 at 10:27 pm

    On 05/09/2013 03:33 PM, jcbollinger wrote:

    Principally, trouble with environments revolves around modules that
    provide native components (types, providers, or functions) that are not
    uniform across all defined environments.
    So, if I have prod and dev environments, how can this problem manifest?

    If I change provider in prod, and client machine is in environment=dev,
    it should have the provider from dev I presume? Or not?




    --
    Jakov Sosic
    www.srce.unizg.hr

    --
    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+unsubscribe@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.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Schmitt at Jul 4, 2013 at 6:40 am

    On 03.07.2013 00:26, Jakov Sosic wrote:
    On 05/09/2013 03:33 PM, jcbollinger wrote:

    Principally, trouble with environments revolves around modules that
    provide native components (types, providers, or functions) that are not
    uniform across all defined environments.
    So, if I have prod and dev environments, how can this problem manifest?

    If I change provider in prod, and client machine is in environment=dev,
    it should have the provider from dev I presume? Or not?
    That exactly is the problem. Ruby does not provide a internal
    partitioning for namespaces. So, depending on who hits your puppetmaster
    first, if your ruby code is not the same across environments, one of
    those will load and be used for everything.



    Regards, David

    --
    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+unsubscribe@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.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brian Hicks at Jul 5, 2013 at 5:16 pm

    On Wednesday, July 3, 2013 11:40:15 PM UTC-7, David Schmitt wrote:
    On 03.07.2013 00:26, Jakov Sosic wrote:
    On 05/09/2013 03:33 PM, jcbollinger wrote:
    That exactly is the problem. Ruby does not provide a internal
    partitioning for namespaces. So, depending on who hits your puppetmaster
    first, if your ruby code is not the same across environments, one of
    those will load and be used for everything.
    I'm not sure I get it. We are using multiple environments in our setup and
    haven't seen issues yet. Our puppetmaster has this in the config:

    modulepath = /u0/puppet/$environment/modules
    manifestdir = /u0/puppet/$environment/manifests

    and so forth, for all the various bits of config. Everything has to be
    duplicated per environment. we store the configs in subversion, then to
    create a new environment you can just svn copy production to a new branch
    and specify it during agent runs to test new code. for example like:

    puppet agent --test --environment=foo --noop

    since everything has to be duplicated, it seems like we avoid namespace
    issues. There's no cross-environment dependencies. am I missing something?

    --
    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+unsubscribe@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.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Schmitt at Jul 5, 2013 at 6:51 pm

    On 2013-07-05 19:02, Brian Hicks wrote:

    On Wednesday, July 3, 2013 11:40:15 PM UTC-7, David Schmitt wrote:
    On 03.07.2013 00:26, Jakov Sosic wrote:
    On 05/09/2013 03:33 PM, jcbollinger wrote:
    That exactly is the problem. Ruby does not provide a internal
    partitioning for namespaces. So, depending on who hits your
    puppetmaster
    first, if your ruby code is not the same across environments, one of
    those will load and be used for everything.

    I'm not sure I get it. We are using multiple environments in our setup
    and haven't seen issues yet. Our puppetmaster has this in the config:

    modulepath = /u0/puppet/$environment/modules
    manifestdir = /u0/puppet/$environment/manifests

    and so forth, for all the various bits of config. Everything has to be
    duplicated per environment. we store the configs in subversion, then to
    create a new environment you can just svn copy production to a new
    branch and specify it during agent runs to test new code. for example like:

    puppet agent --test --environment=foo --noop

    since everything has to be duplicated, it seems like we avoid namespace
    issues. There's no cross-environment dependencies. am I missing something?
    This only applies to custom types and providers which do not get loaded
    by (the) puppet (parser) but are ruby scripts which get loaded by
    directly by the ruby process.

    Sorry if I was unclear on that point.


    Regards, David

    --
    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+unsubscribe@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.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 9, '13 at 5:09a
activeJul 5, '13 at 6:51p
posts8
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase