Jira (BOLT-1550) couldn't find login name -- expanding `~' (ArgumentError) when running bolt from non-interactive process

2020-05-19 Thread Bert Hajee (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee commented on  BOLT-1550  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: couldn't find login name -- expanding `~' (ArgumentError) when running bolt from non-interactive process   
 

  
 
 
 
 

 
 See PR https://github.com/puppetlabs/bolt/pull/1829  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.359261.1589890166000.65324.1589891220032%40Atlassian.JIRA.


Jira (BOLT-1550) couldn't find login name -- expanding `~' (ArgumentError) when running bolt from non-interactive process

2020-05-19 Thread Bert Hajee (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-1550  
 
 
  couldn't find login name -- expanding `~' (ArgumentError) when running bolt from non-interactive process   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 BOLT 1.29.0  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 bolt  
 
 
Created: 
 2020/05/19 5:09 AM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Bert Hajee  
 

  
 
 
 
 

 
 When running a bolt plan command from a scheduled bolt task (e.g. a detached process) we get this error: Error: Exited 1: /opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.9.0/lib/bolt/project.rb:40:in `expand_path': couldn't find login name – expanding `~' (ArgumentError) from /opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.9.0/lib/bolt/project.rb:40:in `expand_path' from /opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.9.0/lib/bolt/project.rb:40:in `initialize' from /opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.9.0/lib/bolt/project.rb:19:in `new' from /opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.9.0/lib/bolt/project.rb:19:in `default_project' from /opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.9.0/lib/bolt/project.rb:33:in `find_boltdir' from /opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.9.0/lib/bolt/cli.rb:120:in `parse' from /opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/bolt-2.9.0/exe/bolt:9:in `' from /opt/puppetlabs/bolt/bin/bolt:23:in `load' from /opt/puppetlabs/bolt/bin/bolt:23:in `'  
 

  
 
 
 
 

 

Jira (BOLT-1549) Puppet data types not synced to target nodes

2020-05-19 Thread Bert Hajee (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee commented on  BOLT-1549  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Puppet data types not synced to target nodes   
 

  
 
 
 
 

 
 created a PR for this issue. https://github.com/puppetlabs/bolt/pull/1828    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.359095.1589816014000.65316.1589890080088%40Atlassian.JIRA.


Jira (BOLT-1549) Puppet data types not synced to target nodes

2020-05-18 Thread Bert Hajee (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet Task Runner /  BOLT-1549  
 
 
  Puppet data types not synced to target nodes   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 BOLT 1.29.0  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 2020/05/18 8:33 AM  
 
 
Priority: 
  Normal  
 
 
Reporter: 
 Bert Hajee  
 

  
 
 
 
 

 
 In https://github.com/puppetlabs/bolt/blob/master/lib/bolt/applicator.rb#L33-L37 the files are marked  that are required for running an apply on a target node. Right now it doesn't contain the puppet data types defined in the directory types with extension .pp. As a result of that puppet code that requires these puppet data types not only for catalog compilation but also for run time type checking, cannot run in a bolt apply block.  This is related to  https://tickets.puppetlabs.com/browse/PUP-7197. However, this is more harmful. We have installed the the [oci_config|https://forge.puppet.com/enterprisemodules/oci_config] on a puppetserver to let this puppetserver work like a gateway between the puppet world and the Oracle Cloud. Many of the custom types available in this module rely on Puppet data types. It works great when you run an apply on the local puppetserver. But when we want to use the power of Bolt with it, we run into this issue:   /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppet-resource_api-1.8.13/lib/puppet/resource_api/data_type_handling.rb:49:in `mungify_core': Parameter source_details failed on Oci_core_volume[blockvolumecloning (root)/ohisc/TRUSTON/BV_TRO9_BO]: oci_core_volume.source_details references an unresolved type 'Oci_config::VolumeSourceDetails' (file: /etc/puppetlabs/code/environments/block_volume_copying/modules/profile/plans/afterclone/clone_volume.pp, line: 38) (Puppet::ResourceError)    from /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/puppet-resource_api-1.8.13/lib/puppet/resource_api/data_type_handling.rb:22:in `mungify'    from /tmp/d20200518-22643-zj5onk/modules/easy_type/lib/easy_type/extended_parameter.rb:41:in `coerce' A very simple solution would be to add the

Jira (PUP-10367) Recursive copy of directory fails in file resource

2020-03-12 Thread Bert Hajee (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee commented on  PUP-10367  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Recursive copy of directory fails in file resource   
 

  
 
 
 
 

 
 So it does not occur when using the puppet agent?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.349424.1584004612000.11062.1584026520029%40Atlassian.JIRA.


Jira (PUP-10367) Recursive copy of directory fails in file resource

2020-03-12 Thread Bert Hajee (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-10367  
 
 
  Recursive copy of directory fails in file resource   
 

  
 
 
 
 

 
Change By: 
 Bert Hajee  
 

  
 
 
 
 

 
 *Puppet Version: 6.14.0* *Puppet Server Version: NA* *OS Name/Version: Centos 7*In Puppet 6.14 copying a puppet served directory fails. Here is an example file { '/a': {{  ensure  => 'directory',}} {{  source  => "puppet:///modules/test",}} {{  recurse => true,}} {{  purge   => true,}} }Now fails with this error{{[root@rcudb vagrant]# puppet apply test_case.pp}} {{Notice: Compiled catalog for rcudb.example.com in environment production in 0.05 seconds}} {{Notice: /Stage[main]/Main/File[/a]/ensure: created}} {{{color:#de350b}Error: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}} {{{color:#de350b}Error: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}} {{{color:#de350b}Wrapped exception:{color}}} {{{color:#de350b}Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}} {{{color:#de350b}Error: /Stage[main]/Main/File[/a/a.a]/ensure: change from 'absent' to 'file' failed: Could not set 'file' on ensure: Is a directory @ io_fread -{color} /etc/puppetlabs/code/environments/production/modules/test/files}} {{Notice: Applied catalog in 0.42 seconds}} *Desired Behavior:*With puppet version puppet-agent.x86_64 0:6.13.0-1.el7 This works as expected:{{ {{[ root@rcudb vagrant]# puppet apply test_case.pp}} }} {{Notice: Compiled catalog for rcudb.example.com in environment production in 0.06 seconds}}{{Notice: /Stage[main]/Main/File[/a]/seltype: seltype changed 'etc_runtime_t' to 'default_t'}}{{Notice: /Stage[main]/Main/File[/a/a.a]/ensure: defined content as '\{md5}d41d8cd98f00b204e9800998ecf8427e'}}{{Notice: Applied catalog in 0.47 seconds}}    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
  

Jira (PUP-10367) Recursive copy of directory fails in file resource

2020-03-12 Thread Bert Hajee (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-10367  
 
 
  Recursive copy of directory fails in file resource   
 

  
 
 
 
 

 
Change By: 
 Bert Hajee  
 

  
 
 
 
 

 
 *Puppet Version: 6.14.0* *Puppet Server Version: NA* *OS Name/Version: Centos 7*In Puppet 6.14 copying a puppet served directory fails. Here is an example file { '/a': {{  ensure  => 'directory',}} {{  source  => "puppet:///modules/test",}} {{  recurse => true,}} {{  purge   => true,}} }Now fails with this error{{[root@rcudb vagrant]# puppet apply test_case.pp}} {{Notice: Compiled catalog for rcudb.example.com in environment production in 0.05 seconds}} {{Notice: /Stage[main]/Main/File[/a]/ensure: created}} {{{color:#de350b}Error: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}} {{{color:#de350b}Error: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}} {{{color:#de350b}Wrapped exception:{color}}} {{{color:#de350b}Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}} {{{color:#de350b}Error: /Stage[main]/Main/File[/a/a.a]/ensure: change from 'absent' to 'file' failed: Could not set 'file' on ensure: Is a directory @ io_fread -{color} /etc/puppetlabs/code/environments/production/modules/test/files}} {{Notice: Applied catalog in 0.42 seconds}} *Desired Behavior:*With puppet version puppet-agent.x86_64 0:6.13.0-1.el7 This works as expected:{{ {{ [root@rcudb vagrant]# puppet apply test_case.pp}} }} {{ Notice: Compiled catalog for rcudb.example.com in environment production in 0.06 seconds}}{{ Notice: /Stage[main]/Main/File[/a]/seltype: seltype changed 'etc_runtime_t' to 'default_t'}}{{ Notice: /Stage[main]/Main/File[/a/a.a]/ensure: defined content as '\{md5}d41d8cd98f00b204e9800998ecf8427e'}}{{ Notice: Applied catalog in 0.47 seconds}}    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  

Jira (PUP-10367) Recursive copy of directory fails in file resource

2020-03-12 Thread Bert Hajee (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-10367  
 
 
  Recursive copy of directory fails in file resource   
 

  
 
 
 
 

 
Change By: 
 Bert Hajee  
 

  
 
 
 
 

 
 *Puppet Version: 6.14.0* *Puppet Server Version: NA* *OS Name/Version: Centos 7*In Puppet 6.14 copying a puppet served directory fails. Here is an example file { '/a': {{  ensure  => 'directory',}} {{  source  => "puppet:///modules/test",}} {{  recurse => true,}} {{  purge   => true,}}}Now fails with this error{{[root@rcudb vagrant]# puppet apply test_case.pp}} {{Notice: Compiled catalog for rcudb.example.com in environment production in 0.05 seconds}} {{Notice: /Stage[main]/Main/File[/a]/ensure: created}} {{{color:#de350b}Error: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}} {{{color:#de350b}Error: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}} {{{color:#de350b}Wrapped exception:{color}}} {{{color:#de350b}Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}} {{{color:#de350b}Error: /Stage[main]/Main/File[/a/a.a]/ensure: change from 'absent' to 'file' failed: Could not set 'file' on ensure: Is a directory @ io_fread -{color} /etc/puppetlabs/code/environments/production/modules/test/files}} {{Notice: Applied catalog in 0.42 seconds}} *Desired Behavior:*With puppet version puppet-agent.x86_64 0:6.13.0-1.el7 This works as expected: {{ [root@rcudb vagrant]# puppet apply test_case.pp }}  {{  Notice: Compiled catalog for rcudb.example.com in environment production in 0.06 seconds }}  {{  Notice: /Stage[main]/Main/File[/a]/seltype: seltype changed 'etc_runtime_t' to 'default_t' }}  {{  Notice: /Stage[main]/Main/File[/a/a.a]/ensure: defined content as '\{md5}d41d8cd98f00b204e9800998ecf8427e' }}  {{  Notice: Applied catalog in 0.47 seconds }}     
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 

Jira (PUP-10367) Recursive copy of directory fails in file resource

2020-03-12 Thread Bert Hajee (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-10367  
 
 
  Recursive copy of directory fails in file resource   
 

  
 
 
 
 

 
Change By: 
 Bert Hajee  
 

  
 
 
 
 

 
 *Puppet Version: 6.14.0* *Puppet Server Version: NA* *OS Name/Version: Centos 7*In Puppet 6.14 copying a puppet served directory fails. Here is an example {{    file { '/a': }} {{  ensure  => 'directory',}}{{  source  => "puppet:///modules/test",}}{{  recurse => true,}}{{  purge   => true,}} {{  } }}    Now fails with this error{{[root@rcudb vagrant]# puppet apply test_case.pp}}{{Notice: Compiled catalog for rcudb.example.com in environment production in 0.05 seconds}}{{Notice: /Stage[main]/Main/File[/a]/ensure: created}}{{{color:#de350b}Error: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}}{{{color:#de350b}Error: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}}{{{color:#de350b}Wrapped exception:{color}}}{{{color:#de350b}Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files{color}}}{{{color:#de350b}Error: /Stage[main]/Main/File[/a/a.a]/ensure: change from 'absent' to 'file' failed: Could not set 'file' on ensure: Is a directory @ io_fread -{color} /etc/puppetlabs/code/environments/production/modules/test/files}}{{Notice: Applied catalog in 0.42 seconds}} *Desired Behavior:*With puppet version puppet-agent.x86_64 0:6.13.0-1.el7 This works as expected:[root@rcudb vagrant]# puppet apply test_case.ppNotice: Compiled catalog for rcudb.example.com in environment production in 0.06 secondsNotice: /Stage[main]/Main/File[/a]/seltype: seltype changed 'etc_runtime_t' to 'default_t'Notice: /Stage[main]/Main/File[/a/a.a]/ensure: defined content as '\{md5}d41d8cd98f00b204e9800998ecf8427e'Notice: Applied catalog in 0.47 seconds    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 

Jira (PUP-10367) Recursive copy of directory fails in file resource

2020-03-12 Thread Bert Hajee (Jira)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Puppet /  PUP-10367  
 
 
  Recursive copy of directory fails in file resource   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 PUP 6.14.0  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 Types and Providers  
 
 
Created: 
 2020/03/12 2:16 AM  
 
 
Priority: 
  Critical  
 
 
Reporter: 
 Bert Hajee  
 

  
 
 
 
 

 
 Puppet Version: 6.14.0 Puppet Server Version: NA OS Name/Version: Centos 7 In Puppet 6.14 copying a puppet served directory fails. Here is an example {{ file { '/a':}}   ensure  => 'directory',   source  => "puppet:///modules/test",   recurse => true,   purge   => true, {{ }}}   Now fails with this error [root@rcudb vagrant]# puppet apply test_case.pp Notice: Compiled catalog for rcudb.example.com in environment production in 0.05 seconds Notice: /Stage[main]/Main/File[/a]/ensure: created Error: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files Error: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files Wrapped exception: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files Error: /Stage[main]/Main/File[/a/a.a]/ensure: change from 'absent' to 'file' failed: Could not set 'file' on ensure: Is a directory @ io_fread - /etc/puppetlabs/code/environments/production/modules/test/files Notice: Applied catalog in 0.42 seconds   Desired Behavior: With puppet version puppet-agent.x86_64 0:6.13.0-1.el7 This works as expected: [root@rcudb vagrant]# puppet apply test_case.pp Notice: Compiled catalog for rcudb.example.com in environment production in 0.06 seconds Notice: /Stage[main]/Main/File[/a]/seltype: seltype changed 'etc_runtime_t' to 'default_t' Notice: /Stage[main]/Main/File[/a/a.a]/ensure: defined content as '{m

Jira (PUP-7197) make type aliases from modules available on the agent

2019-08-14 Thread Bert Hajee (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee commented on  PUP-7197  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: make type aliases from modules available on the agent   
 

  
 
 
 
 

 
 Why validate the data type in the provider, if it's already been validated at compile time? The type is. not only checked when the catalog is compiled, but the type is also used to validate the value returned by the provider.  I would expect the type aliases to be copied along with the custom type and providers. I assume bolt doesn't know to copy them like it does with lib, facts.d, files, templates, etc?   This happens when you use bolt and agentless puppet. But you can also execute pp files as tasks using the local installation of puppet agent. Then it will compile the manifest local on the agent.    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.174775.1486632721000.55006.1565766540340%40Atlassian.JIRA.


Jira (PUP-7197) make type aliases from modules available on the agent

2019-08-10 Thread Bert Hajee (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee commented on  PUP-7197  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: make type aliases from modules available on the agent   
 

  
 
 
 
 

 
 I'll try and describe my issue Josh Cooper. The resource API allows you to specify a data type for the parameters and properties of a custom type and provider. The resource API takes care of typing the values returned from the provider and checks the values from the manifest against the specified type. On a regular puppetserver this works with both the basic types but also with type aliases. A problem, however, arises when using $ puppet resource my_custom_type Another use case is when I use bolt to execute a task that uses (parts of) puppet to execute on a remote system. Again it cannot find the specified data types and fails. On an agent system. The type alias is not available there and so the provider fails with a message it cannot find the data type. The workaround we use now is to only use basic data types and copy the value from the type alias.  This workaround causes duplication of the type alias throughout the custom type code. Hope this helps.   Regards  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.174775.1486632721000.51240.1565422440302%40Atlassian.JIRA.


Jira (PUP-7197) make type aliases from modules available on the agent

2019-08-09 Thread Bert Hajee (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Bert Hajee commented on  PUP-7197  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: make type aliases from modules available on the agent   
 

  
 
 
 
 

 
 +1   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.174775.1486632721000.49626.1565341320375%40Atlassian.JIRA.


Jira (PUP-1968) Duplicate resources can make re-usable Forge modules difficult

2016-02-02 Thread Bert Hajee (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Bert Hajee commented on  PUP-1968 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Duplicate resources can make re-usable Forge modules difficult  
 
 
 
 
 
 
 
 
 
 
We see an increase of this kind of issues. I guess that it is caused by using more and more modules from an external source and the fact that are setups and manifests are getting bigger.  
I also think that the roles and profiles pattern might have something to do with the increase. We are trying to reuse profiles in different roles. An example: We are have build a role with all supporting (profile)classes to build an Oracle database. We have als build a role for a WebLogic system. When we want to build a role that has both WebLogic and Oracle, we run into duplicate resource problems. When we own the classes, we can extract the duplicate resources into it's own classes, but when the modules are fetched from the forge, you cannot do this that easy.  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.


Jira (PUP-3800) hiera function reacts different based on order of loaded resources

2014-12-30 Thread Bert Hajee (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Bert Hajee created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-3800 
 
 
 
  hiera function reacts different based on order of loaded resources  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 PUP 3.7.3 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Attachments:
 

 hiera_error-to_puppetlabs.zip 
 
 
 

Components:
 

 Platform 
 
 
 

Created:
 

 2014/12/30 2:07 PM 
 
 
 

Environment:
 
 
any 
 
 
 

Labels:
 

 hiera 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 Bert Hajee 
 
 
 
 
 
 
 
 
 
 
when