[Puppet Users] Re: puppetlabs/mount_providers Could not autoload puppet/type/mountpoint: Attempt to redefine entity
Looked like a contention of some kind, i removed the module and installed it again to see if i can run "puppet describe mountpoint", it is now working. On Tuesday, December 20, 2016 at 11:34:19 PM UTC+2, Erez Zarum wrote: > > Hey, > I'm trying to use puppetlabs/mount_providers, it works fine on a puppet > agent 1.6.2 (apply), when when i try to compile the catalog on the > puppetserver (2.6.0), i receive the following error: > 2016-12-20 21:20:30,321 ERROR [qtp2009689149-149188] [puppetserver] Puppet > Evaluation Error: Error while evaluating a Resource Statement, Evaluation > Error: Error while evaluating a Resource Statement, Could not autoload > puppet/type/mountpoint: Attempt to redefine entity ' > http://puppet.com/2016.1/runtime/type/mountpoint'. Originally set at file: > /etc/puppetlabs/code/environments/production/modules/mount_providers/lib/ > puppet/type/mountpoint.rb?line=1. at /etc/puppetlabs/code/environments/ > production/modules/mountt/manifests/mount.pp:55:5 at /etc/puppetlabs/code/ > environments/production/modules/mountt/manifests/init.pp:6 on node node01. > example.com > > I don't have it defined already. > > Thanks! > > > -- 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/95fd9a85-b896-44cc-a1c1-d102d454c829%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppetlabs/mount_providers Could not autoload puppet/type/mountpoint: Attempt to redefine entity
Hey, I'm trying to use puppetlabs/mount_providers, it works fine on a puppet agent 1.6.2 (apply), when when i try to compile the catalog on the puppetserver (2.6.0), i receive the following error: 2016-12-20 21:20:30,321 ERROR [qtp2009689149-149188] [puppetserver] Puppet Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Resource Statement, Could not autoload puppet/type/mountpoint: Attempt to redefine entity 'http://puppet.com/2016.1/runtime/type/mountpoint'. Originally set at file: /etc/puppetlabs/code/environments/production/modules/mount_providers/lib/ puppet/type/mountpoint.rb?line=1. at /etc/puppetlabs/code/environments/ production/modules/mountt/manifests/mount.pp:55:5 at /etc/puppetlabs/code/ environments/production/modules/mountt/manifests/init.pp:6 on node node01. example.com I don't have it defined already. Thanks! -- 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/86503f76-1cf2-4fd9-ae29-764889602393%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Facts and Resource relationships
It was just an example to reproduce it.
On Thursday, October 6, 2016 at 12:49:11 PM UTC+3, Rob Nelson wrote:
>
> I do not know that a workaround is needed. I believe that when a package
> is upgraded, the old and new versions should show up in the logs already,
> so the notify may not be needed.
>
> On Thursday, October 6, 2016, Erez Zarum <erez...@gmail.com >
> wrote:
>
>> Ok, so the workaround is to use a variable (set default), if that fails,
>> try the fact.
>>
>> Thanks!
>>
>> On Thursday, October 6, 2016 at 10:45:26 AM UTC+3, R.I. Pienaar wrote:
>>>
>>>
>>>
>>> - Original Message -
>>> > From: "Erez Zarum" <erez...@gmail.com>
>>> > To: "puppet-users" <puppet...@googlegroups.com>
>>> > Sent: Thursday, 6 October, 2016 09:40:44
>>> > Subject: [Puppet Users] Facts and Resource relationships
>>>
>>> > I'm not sure if it's a bug or an expected behavior.
>>> >
>>> > I have written a simple fact for a module that returns a version of a
>>> > binary file, it executes: "binary --version" and then parses the
>>> version,
>>> > no issues there, it works.
>>> >
>>> > The issue i am having is relying on this fact in case the binary file
>>> gets
>>> > upgraded during a package installation (this is the simple example)
>>> >
>>> > package { 'package':
>>> > ensure => '1.3.8'
>>> > } ->
>>> > notify { "version: ${::binary_version}": }
>>> >
>>> > If the previous version was 1.3.7 the fact "binary_version" will
>>> return
>>> > 1.3.7, the next run it will return 1.3.8 as expected.
>>> > The biggest issue is if i rely on this fact to pick up a template to
>>> use,
>>> > if this package is not yet installed the fact won't work and will work
>>> only
>>> > on the second run.
>>> >
>>> > I can only assume this happens because the facts are being "compiled"
>>> > before the catalog is.
>>> >
>>> > I have tried different ways to declare the relationship but it doesn't
>>> work.
>>>
>>> yes, you cant use facts for something that changes during a run. It's
>>> for facts
>>> about your node that influence the creation of the catalog.
>>>
>>> things the catalog changes - well thats after the catalog was created
>>>
>> --
>> 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/1af175d0-ba5d-4626-8fcc-986f6c7fc8f3%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/puppet-users/1af175d0-ba5d-4626-8fcc-986f6c7fc8f3%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Rob Nelson
> rnel...@gmail.com
>
>
--
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/d1112795-2e3c-4552-ac9a-648d0f77eae7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Facts and Resource relationships
Ok, so the workaround is to use a variable (set default), if that fails,
try the fact.
Thanks!
On Thursday, October 6, 2016 at 10:45:26 AM UTC+3, R.I. Pienaar wrote:
>
>
>
> - Original Message -
> > From: "Erez Zarum" <erez...@gmail.com >
> > To: "puppet-users" <puppet...@googlegroups.com >
> > Sent: Thursday, 6 October, 2016 09:40:44
> > Subject: [Puppet Users] Facts and Resource relationships
>
> > I'm not sure if it's a bug or an expected behavior.
> >
> > I have written a simple fact for a module that returns a version of a
> > binary file, it executes: "binary --version" and then parses the
> version,
> > no issues there, it works.
> >
> > The issue i am having is relying on this fact in case the binary file
> gets
> > upgraded during a package installation (this is the simple example)
> >
> > package { 'package':
> > ensure => '1.3.8'
> > } ->
> > notify { "version: ${::binary_version}": }
> >
> > If the previous version was 1.3.7 the fact "binary_version" will return
> > 1.3.7, the next run it will return 1.3.8 as expected.
> > The biggest issue is if i rely on this fact to pick up a template to
> use,
> > if this package is not yet installed the fact won't work and will work
> only
> > on the second run.
> >
> > I can only assume this happens because the facts are being "compiled"
> > before the catalog is.
> >
> > I have tried different ways to declare the relationship but it doesn't
> work.
>
> yes, you cant use facts for something that changes during a run. It's for
> facts
> about your node that influence the creation of the catalog.
>
> things the catalog changes - well thats after the catalog was created
>
--
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/1af175d0-ba5d-4626-8fcc-986f6c7fc8f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Facts and Resource relationships
I'm not sure if it's a bug or an expected behavior.
I have written a simple fact for a module that returns a version of a
binary file, it executes: "binary --version" and then parses the version,
no issues there, it works.
The issue i am having is relying on this fact in case the binary file gets
upgraded during a package installation (this is the simple example)
package { 'package':
ensure => '1.3.8'
} ->
notify { "version: ${::binary_version}": }
If the previous version was 1.3.7 the fact "binary_version" will return
1.3.7, the next run it will return 1.3.8 as expected.
The biggest issue is if i rely on this fact to pick up a template to use,
if this package is not yet installed the fact won't work and will work only
on the second run.
I can only assume this happens because the facts are being "compiled"
before the catalog is.
I have tried different ways to declare the relationship but it doesn't work.
--
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/ca95130b-51b2-4d33-8919-a3977615ed25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Defined Resource types and Relationship
Thanks! On Wednesday, September 21, 2016 at 11:26:57 AM UTC+3, R.I. Pienaar wrote: > > > > - Original Message - > > From: "Erez Zarum" <erez...@gmail.com > > > To: "puppet-users" <puppet...@googlegroups.com > > > Sent: Wednesday, 21 September, 2016 10:19:24 > > Subject: Re: [Puppet Users] Defined Resource types and Relationship > > > If i understand correctly, I do not have to contain (declare contain) on > > the defined resource (like in app::server)? > > As in my example it will work as expected? > > yes, your example is fine, i mean containment if you were to include > anything > in the define > -- 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/7089e3e7-1cbc-401e-9f8c-6b9ef75f8907%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Defined Resource types and Relationship
If i understand correctly, I do not have to contain (declare contain) on
the defined resource (like in app::server)?
As in my example it will work as expected?
On Wednesday, September 21, 2016 at 10:59:27 AM UTC+3, R.I. Pienaar wrote:
>
>
>
> - Original Message -
> > From: "Erez Zarum" <erez...@gmail.com >
> > To: "puppet-users" <puppet...@googlegroups.com >
> > Sent: Wednesday, 21 September, 2016 09:16:18
> > Subject: [Puppet Users] Defined Resource types and Relationship
>
> > Is it the same behavior as classes?
> > Example:
> >
> > define app::server {
> > ::app::server::config { '/etc/app.conf': }
> > ::app::server::service { 'app': }
> >
> > App::Server::Config['/etc/app.conf'] -> App::Server::Service['app']
> > }
> >
> > define app::server::config {
> > file { $name:
> >ensure => present
> > }
> > }
> >
> > define app::server::service {
> > service { $name:
> >ensure => 'running'
> > }
> > }
> >
> > Will this work as expected, what happens if i have dependency resources
> > inside the defined types? will it contain it as well?
>
> yes with the same caveats as classes and class containment
>
--
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/e9f7d63d-73fa-44e0-b7c2-900c3b6c48c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Defined Resource types and Relationship
Is it the same behavior as classes?
Example:
define app::server {
::app::server::config { '/etc/app.conf': }
::app::server::service { 'app': }
App::Server::Config['/etc/app.conf'] -> App::Server::Service['app']
}
define app::server::config {
file { $name:
ensure => present
}
}
define app::server::service {
service { $name:
ensure => 'running'
}
}
Will this work as expected, what happens if i have dependency resources
inside the defined types? will it contain it as well?
--
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/e06eb5f0-3613-4d23-a898-3342eb086e31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: yumrepo difference in behaviour between CentOS 6 and 7
It's a known bug, the best option i have come with is to create a module to
manage the base repositories using augeas instead of yumrepo.
On Monday, September 12, 2016 at 6:48:15 PM UTC+3, Jonathan Gazeley wrote:
>
> Hi folks,
>
> I'm working on a manifest that manages the stock yum.repos.d definitions
> from CentOS and can override some settings. This is tested and working
> on CentOS 7 but produces different behaviour on CentOS 6.
>
> This is the repo definition:
>
> yumrepo { 'CentOS-Base':
>name => 'base',
>target => '/etc/yum.repos.d/CentOS-Base.repo',
>baseurl=> $baseurl,
>mirrorlist => $mirrorlist,
>descr => 'CentOS-$releasever - Base',
>enabled=> $enabled,
>gpgcheck => '1',
>gpgkey =>
> "file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-${::repo_centos::releasever}",
> }
>
> On CentOS 7 this produces a file "CentOS-Base.repo". On CentOS 6 this
> produces a file "base.repo". Both platforms are running Puppet 3.8.7. Is
> this a bug?
>
> Full code here if anyone is interested:
> https://github.com/uobnetops/repo_centos/blob/repo_naming/manifests/base.pp
>
> Thanks,
> Jonathan
>
> --
> Jonathan Gazeley
> Senior Systems Administrator
> IT Services
> University of Bristol
>
--
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/f69b79fd-a0da-4f97-9b34-a4b5640f4326%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
