I just have setup a clean foreman-1.4.2 server on Centos-6.5 and
everything seems to work OK. I have added a compute resource oVirt to it
and have produced my first VM on it using Foreman. Then I started
testing some things, like hostgroups and classes on it, using both a
production and a development environment, starting ofcourse by using dev
first. First few were no problem but then I hit an error.
err: /File[/etc/vim/vimrc]: Could not evaluate: Could not retrieve
information from environment production source(s)
puppet:///modules/nwld_vim/vimrc at
/etc/puppet/environments/development/modules/nwld_vim/manifests/init.pp:29
Thats weird. Puppet is right, there is no module nwld_vim, yet, in the
production env but this host is in the development env so is its
hostgroup then why is it referencing productions?
All other modules didn't have problems but why does this one? This one
uses puppet:///modules/nwld_vim/vimrc to copy vimrc to /etc all others
don't use puppet:///.
Digging a bit I found that on that host /etc/puppet.conf says that the
environment=production. Setting this to development and rerunning puppet
agent --test and now it works.
Why is puppet.conf still having production as an env and why have
modules that don't use puppet:/// no problems with it?
What are they using, if not puppet:///? Templates?
···
On 03/04/14 15:14, jvandewege wrote:
> Hi All,
>
> I just have setup a clean foreman-1.4.2 server on Centos-6.5 and
> everything seems to work OK. I have added a compute resource oVirt to it
> and have produced my first VM on it using Foreman. Then I started
> testing some things, like hostgroups and classes on it, using both a
> production and a development environment, starting ofcourse by using dev
> first. First few were no problem but then I hit an error.
> err: /File[/etc/vim/vimrc]: Could not evaluate: Could not retrieve
> information from environment production source(s)
> puppet:///modules/nwld_vim/vimrc at
> /etc/puppet/environments/development/modules/nwld_vim/manifests/init.pp:29
>
> Thats weird. Puppet is right, there is no module nwld_vim, yet, in the
> production env but this host is in the development env so is its
> hostgroup then why is it referencing productions?
> All other modules didn't have problems but why does this one? This one
> uses puppet:///modules/nwld_vim/vimrc to copy vimrc to /etc all others
> don't use puppet:///.
> Digging a bit I found that on that host /etc/puppet.conf says that the
> environment=production. Setting this to development and rerunning puppet
> agent --test and now it works.
>
> Why is puppet.conf still having production as an env and why have
> modules that don't use puppet:/// no problems with it?
>> Hi All,
>>
>> I just have setup a clean foreman-1.4.2 server on Centos-6.5 and
>> everything seems to work OK. I have added a compute resource oVirt to it
>> and have produced my first VM on it using Foreman. Then I started
>> testing some things, like hostgroups and classes on it, using both a
>> production and a development environment, starting ofcourse by using dev
>> first. First few were no problem but then I hit an error.
>> err: /File[/etc/vim/vimrc]: Could not evaluate: Could not retrieve
>> information from environment production source(s)
>> puppet:///modules/nwld_vim/vimrc at
>> /etc/puppet/environments/development/modules/nwld_vim/manifests/init.pp:29
>>
>> Thats weird. Puppet is right, there is no module nwld_vim, yet, in the
>> production env but this host is in the development env so is its
>> hostgroup then why is it referencing productions?
>> All other modules didn't have problems but why does this one? This one
>> uses puppet:///modules/nwld_vim/vimrc to copy vimrc to /etc all others
>> don't use puppet:///.
>> Digging a bit I found that on that host /etc/puppet.conf says that the
>> environment=production. Setting this to development and rerunning puppet
>> agent --test and now it works.
>>
>> Why is puppet.conf still having production as an env and why have
>> modules that don't use puppet:/// no problems with it?
> Which version of Puppet? 2.7 or 3.x?
3.x
> What are they using, if not puppet:///? Templates?
>
Its just code. This one module is using puppet:///
Joop
···
On 3-4-2014 17:08, Dominic Cleal wrote:
> On 03/04/14 15:14, jvandewege wrote:
Hm, I've only seen this on 2.x agents which would request a catalog
(which would come from development) but believed locally that the
environment was production, so would fetch files from there.
3.x should handle this correctly - it will check the master's designated
environment first and print a message saying that it's switching to the
master's environment, then pull files from there.
···
On 03/04/14 20:21, jvandewege wrote:
> On 3-4-2014 17:08, Dominic Cleal wrote:
>> On 03/04/14 15:14, jvandewege wrote:
>>> Hi All,
>>>
>>> I just have setup a clean foreman-1.4.2 server on Centos-6.5 and
>>> everything seems to work OK. I have added a compute resource oVirt to it
>>> and have produced my first VM on it using Foreman. Then I started
>>> testing some things, like hostgroups and classes on it, using both a
>>> production and a development environment, starting ofcourse by using dev
>>> first. First few were no problem but then I hit an error.
>>> err: /File[/etc/vim/vimrc]: Could not evaluate: Could not retrieve
>>> information from environment production source(s)
>>> puppet:///modules/nwld_vim/vimrc at
>>> /etc/puppet/environments/development/modules/nwld_vim/manifests/init.pp:29
>>>
>>> Thats weird. Puppet is right, there is no module nwld_vim, yet, in the
>>> production env but this host is in the development env so is its
>>> hostgroup then why is it referencing productions?
>>> All other modules didn't have problems but why does this one? This one
>>> uses puppet:///modules/nwld_vim/vimrc to copy vimrc to /etc all others
>>> don't use puppet:///.
>>> Digging a bit I found that on that host /etc/puppet.conf says that the
>>> environment=production. Setting this to development and rerunning puppet
>>> agent --test and now it works.
>>>
>>> Why is puppet.conf still having production as an env and why have
>>> modules that don't use puppet:/// no problems with it?
>> Which version of Puppet? 2.7 or 3.x?
> 3.x
Is there a switch that I can use to see what it is doing? (-d) didn't
reveal much to me but that could just be me overlooking something.
Joop
···
On 4-4-2014 9:49, Dominic Cleal wrote:
> On 03/04/14 20:21, jvandewege wrote:
>> On 3-4-2014 17:08, Dominic Cleal wrote:
>>> On 03/04/14 15:14, jvandewege wrote:
>>>> Hi All,
>>>>
>>>> I just have setup a clean foreman-1.4.2 server on Centos-6.5 and
>>>> everything seems to work OK. I have added a compute resource oVirt to it
>>>> and have produced my first VM on it using Foreman. Then I started
>>>> testing some things, like hostgroups and classes on it, using both a
>>>> production and a development environment, starting ofcourse by using dev
>>>> first. First few were no problem but then I hit an error.
>>>> err: /File[/etc/vim/vimrc]: Could not evaluate: Could not retrieve
>>>> information from environment production source(s)
>>>> puppet:///modules/nwld_vim/vimrc at
>>>> /etc/puppet/environments/development/modules/nwld_vim/manifests/init.pp:29
>>>>
>>>> Thats weird. Puppet is right, there is no module nwld_vim, yet, in the
>>>> production env but this host is in the development env so is its
>>>> hostgroup then why is it referencing productions?
>>>> All other modules didn't have problems but why does this one? This one
>>>> uses puppet:///modules/nwld_vim/vimrc to copy vimrc to /etc all others
>>>> don't use puppet:///.
>>>> Digging a bit I found that on that host /etc/puppet.conf says that the
>>>> environment=production. Setting this to development and rerunning puppet
>>>> agent --test and now it works.
>>>>
>>>> Why is puppet.conf still having production as an env and why have
>>>> modules that don't use puppet:/// no problems with it?
>>> Which version of Puppet? 2.7 or 3.x?
>> 3.x
> Hm, I've only seen this on 2.x agents which would request a catalog
> (which would come from development) but believed locally that the
> environment was production, so would fetch files from there.
>
> 3.x should handle this correctly - it will check the master's designated
> environment first and print a message saying that it's switching to the
> master's environment, then pull files from there.
>
I don't think so. Usually the message I mentioned appears at warning or
notice level, so when running the agent interactively it's very
noticeable. I'd perhaps double check all of your Puppet versions are
3.x, both master and agent, as I would expect this to work.
Else perhaps ask puppet-users or raise a ticket there, if you can show
that the ENC (Foreman's node.rb) is specifying the development
environment in its output.
···
On 04/04/14 13:04, jvandewege wrote:
> On 4-4-2014 9:49, Dominic Cleal wrote:
>> On 03/04/14 20:21, jvandewege wrote:
>>> On 3-4-2014 17:08, Dominic Cleal wrote:
>>>> On 03/04/14 15:14, jvandewege wrote:
>>>>> Hi All,
>>>>>
>>>>> I just have setup a clean foreman-1.4.2 server on Centos-6.5 and
>>>>> everything seems to work OK. I have added a compute resource oVirt to it
>>>>> and have produced my first VM on it using Foreman. Then I started
>>>>> testing some things, like hostgroups and classes on it, using both a
>>>>> production and a development environment, starting ofcourse by using dev
>>>>> first. First few were no problem but then I hit an error.
>>>>> err: /File[/etc/vim/vimrc]: Could not evaluate: Could not retrieve
>>>>> information from environment production source(s)
>>>>> puppet:///modules/nwld_vim/vimrc at
>>>>> /etc/puppet/environments/development/modules/nwld_vim/manifests/init.pp:29
>>>>>
>>>>> Thats weird. Puppet is right, there is no module nwld_vim, yet, in the
>>>>> production env but this host is in the development env so is its
>>>>> hostgroup then why is it referencing productions?
>>>>> All other modules didn't have problems but why does this one? This one
>>>>> uses puppet:///modules/nwld_vim/vimrc to copy vimrc to /etc all others
>>>>> don't use puppet:///.
>>>>> Digging a bit I found that on that host /etc/puppet.conf says that the
>>>>> environment=production. Setting this to development and rerunning puppet
>>>>> agent --test and now it works.
>>>>>
>>>>> Why is puppet.conf still having production as an env and why have
>>>>> modules that don't use puppet:/// no problems with it?
>>>> Which version of Puppet? 2.7 or 3.x?
>>> 3.x
>> Hm, I've only seen this on 2.x agents which would request a catalog
>> (which would come from development) but believed locally that the
>> environment was production, so would fetch files from there.
>>
>> 3.x should handle this correctly - it will check the master's designated
>> environment first and print a message saying that it's switching to the
>> master's environment, then pull files from there.
>>
> Is there a switch that I can use to see what it is doing? (-d) didn't
> reveal much to me but that could just be me overlooking something.
I'll look into it and if give feedback on how thing go.
Thanks for the help sofar.
Joop
···
On 4-4-2014 14:36, Dominic Cleal wrote:
> I don't think so. Usually the message I mentioned appears at warning
> or notice level, so when running the agent interactively it's very
> noticeable. I'd perhaps double check all of your Puppet versions are
> 3.x, both master and agent, as I would expect this to work. Else
> perhaps ask puppet-users or raise a ticket there, if you can show that
> the ENC (Foreman's node.rb) is specifying the development environment
> in its output.
Had 2.7 on the client and 3.4.3 on the server. Updated the client and I
now get a warning that the envs are not the same but thats OK and
according to puppet.conf also true. Things now work without having
production populated with new untested files
Thanks,
Joop
···
On 4-4-2014 14:36, Dominic Cleal wrote:
> On 04/04/14 13:04, jvandewege wrote:
>> On 4-4-2014 9:49, Dominic Cleal wrote:
>>> On 03/04/14 20:21, jvandewege wrote:
>>>> On 3-4-2014 17:08, Dominic Cleal wrote:
>>>>> On 03/04/14 15:14, jvandewege wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I just have setup a clean foreman-1.4.2 server on Centos-6.5 and
>>>>>> everything seems to work OK. I have added a compute resource oVirt to it
>>>>>> and have produced my first VM on it using Foreman. Then I started
>>>>>> testing some things, like hostgroups and classes on it, using both a
>>>>>> production and a development environment, starting ofcourse by using dev
>>>>>> first. First few were no problem but then I hit an error.
>>>>>> err: /File[/etc/vim/vimrc]: Could not evaluate: Could not retrieve
>>>>>> information from environment production source(s)
>>>>>> puppet:///modules/nwld_vim/vimrc at
>>>>>> /etc/puppet/environments/development/modules/nwld_vim/manifests/init.pp:29
>>>>>>
>>>>>> Thats weird. Puppet is right, there is no module nwld_vim, yet, in the
>>>>>> production env but this host is in the development env so is its
>>>>>> hostgroup then why is it referencing productions?
>>>>>> All other modules didn't have problems but why does this one? This one
>>>>>> uses puppet:///modules/nwld_vim/vimrc to copy vimrc to /etc all others
>>>>>> don't use puppet:///.
>>>>>> Digging a bit I found that on that host /etc/puppet.conf says that the
>>>>>> environment=production. Setting this to development and rerunning puppet
>>>>>> agent --test and now it works.
>>>>>>
>>>>>> Why is puppet.conf still having production as an env and why have
>>>>>> modules that don't use puppet:/// no problems with it?
>>>>> Which version of Puppet? 2.7 or 3.x?
>>>> 3.x
>>> Hm, I've only seen this on 2.x agents which would request a catalog
>>> (which would come from development) but believed locally that the
>>> environment was production, so would fetch files from there.
>>>
>>> 3.x should handle this correctly - it will check the master's designated
>>> environment first and print a message saying that it's switching to the
>>> master's environment, then pull files from there.
>>>
>> Is there a switch that I can use to see what it is doing? (-d) didn't
>> reveal much to me but that could just be me overlooking something.
> I don't think so. Usually the message I mentioned appears at warning or
> notice level, so when running the agent interactively it's very
> noticeable. I'd perhaps double check all of your Puppet versions are
> 3.x, both master and agent, as I would expect this to work.
>
