Puppet users - May 2013 - Are multiple environments broken in puppet?

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.

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.

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.

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.

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.

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.

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.

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.