[Puppet - Bug #22643] (In Topic Branch Pending Review) Document /env/file_metadata/*
Issue #22643 has been updated by Kylo Ginsberg. Status changed from Investigating to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet/pull/1961 Bug #22643: Document /env/file_metadata/* https://projects.puppetlabs.com/issues/22643#change-98240 * Author: Kylo Ginsberg * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: Kylo Ginsberg * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: https://github.com/puppetlabs/puppet/pull/1961 -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #15062] puppet fails if template contains invalid utf-8
Issue #15062 has been updated by Mariusz Gronczewski.
At this point even having sensible default would help, as if for some reason
environment isnt right puppet just fails with cryptic (for new user) message.
Could encoding just be made parameter to template ? like
template('some/file.erb','ISO-8859-2') ? Then default could be UTF8 but few
files needing specific encodunf could be easily fixed
Bug #15062: puppet fails if template contains invalid utf-8
https://projects.puppetlabs.com/issues/15062#change-98181
* Author: Chris Price
* Status: Needs Decision
* Priority: Normal
* Assignee: eric sorenson
* Category: templates
* Target version:
* Affected Puppet version: 2.7.16
* Keywords: character encoding binary utf8
* Branch:
If you attempt to use a file resource with a 'content' parameter pointing at a
template, and the template contains binary content, you may get an error like
this:
Error: Failed to apply catalog: Parameter content failed: Munging failed
for value ...
invalid byte sequence in UTF-8
I've reproduced the failure in 2.7.16 and 3.x, though the error messages differ
slightly between the two (and also depending on whether you repro via 'apply'
or via master/agent run).
I'm attaching the binary file that I'm using to repro. Save it into a
directory structure like this:
modules/mymod/templates/mytemplate.erb
Add the modules directory to your module path and then you can repro with the
following manifest:
file { /tmp/myfile:
mode = 755,
content = template(mymod/mytemplate.erb),
}
Note that if you use the 'source' parameter rather than the 'content' parameter
(and avoid calling the template function), the manifest can be applied
successfully; so the issue is when bringing in binary data as a string.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22646] Hiera-2 hiera.yaml/binder_config.yaml - use named attributes, set defaults
Issue #22646 has been updated by Henrik Lindberg.
Branch set to https://github.com/puppetlabs/puppet/pull/1957
https://github.com/puppetlabs/puppet/pull/1957
Feature #22646: Hiera-2 hiera.yaml/binder_config.yaml - use named attributes,
set defaults
https://projects.puppetlabs.com/issues/22646#change-98184
* Author: Henrik Lindberg
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: databinding
* Target version:
* Affected Puppet version: 3.3.0
* Keywords: databindings language usability
* Branch: https://github.com/puppetlabs/puppet/pull/1957
Currently three entries in a hiera.yaml category specification are needed to
specify a contribution to to a category.
For humans it is far easier if all elements have a name (unless being a true
multiple value attribute).
i.e. you have to write something like:
pre
['osfamily', '${osfamily}', 'data/osfamily/${osfamily}']
/pre
This makes it difficult to add smart defaults, and support a private (nested
hierarchy). (Separate issues)
Suggests that is done like this:
pre
hiera.yaml
---
version: 3# (since are making changes)
hierarchy:
-
category: 'name'
paths:
- 'path 1'
- 'path 2'
-
category: 'name2'
value: 'some interpolated value'
path: 'a single path'
/pre
The element 'datadir' should also be added to enable defaults to refer to this
location.
When format is change it needs a new version.
The same type of change should be made to binder_config.yaml to make it look
like this:
pre
---
version: 2
layers:
-
name: 'site'
include:
- 'confdir-hiera:/'
- 'confdir:/default?optional'
-
name: 'modules'
include:
- 'module-hiera:/*/'
- 'module:/*::default'
exclude:
- 'module-hiera:/bad_boy/*'
categories:
-
name: 'node'
value: '${fqdn}'
-
name: 'operatingsystem'
value: '${operatingsystem}'
-
name: 'osfamily'
value: '${osfamily}'
-
name: 'environment'
value: '${environment}'
-
name: 'common'
value: true
/pre
Also see #22647 regarding smart default values.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22648] (In Topic Branch Pending Review) hiera-2 - support nested / private hierarchy in a module
Issue #22648 has been updated by Henrik Lindberg.
Status changed from Accepted to In Topic Branch Pending Review
Branch set to https://github.com/puppetlabs/puppet/pull/1957
https://github.com/puppetlabs/puppet/pull/1957
Feature #22648: hiera-2 - support nested / private hierarchy in a module
https://projects.puppetlabs.com/issues/22648#change-98187
* Author: Henrik Lindberg
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee:
* Category: databinding
* Target version:
* Affected Puppet version:
* Keywords: databinding hiera-2 language
* Branch: https://github.com/puppetlabs/puppet/pull/1957
Many modules have the need to differentiate on several facts related to
osfamily, operatingsystem, cpu, cores etc.
Modules may also come with their own facts that are needed in order to
correctly configure the module.
If these are mixed into the overall composed hierarchy, there is the
undesirable effect that these must also
be added as categories in the overall binder_config.yaml.
There is a very simple solution to this - simply allow multiple paths to be
used in the hiera-2 hiera.yaml for a contribution in a given category.
The typical scenario is that the values represents defaults and they can thus
be contributed in the common category. Manual override of these
is then up to whoever uses them, and this user can then either set up the same
elaborate structure, or simply override in the category that they find suitable.
This can be specified in hiera.yaml like this:
pre
hierarchy:
-
category: 'common'
paths:
- 'data/cores/${operatingsystem}/${cores}
- 'data/operatingsystem/${operatingsystem}
- 'data/osfamily/${osfamily}
-
/pre
Thus, all values set in the flattened subhierarchy are contributed to the
common category.
Requires issue #22646 to support multiple paths.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22647] (In Topic Branch Pending Review) Add smart defaults in Hiera-2 hiera.yaml / binder_config.yaml
Issue #22647 has been updated by Henrik Lindberg.
Status changed from Accepted to In Topic Branch Pending Review
Branch set to https://github.com/puppetlabs/puppet/pull/1957
https://github.com/puppetlabs/puppet/pull/1957
Feature #22647: Add smart defaults in Hiera-2 hiera.yaml / binder_config.yaml
https://projects.puppetlabs.com/issues/22647#change-98186
* Author: Henrik Lindberg
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee:
* Category: databinding
* Target version:
* Affected Puppet version:
* Keywords: databinding hiera-2 usability
* Branch: https://github.com/puppetlabs/puppet/pull/1957
Currently, a level in the hierarchy needs to be defined with:
pre
- ['osfamily', '${osfamily}', 'data/osfamily/${osfamily}']
/pre
By using smart defaults, this could be reduced to:
pre
- 'osfamily'
/pre
If the `value` is missing, use the name of the category as the name of the
variable to interpolate, and
use `'datadir/category-name/'${category-name}'` as the default path.
This depends on #22646 where the format is changed to a format with named
attributes instead of an anonymous array of data.
Also add the corresponding smart defaults to binder_config.yaml, to enable a
compact listing of the categories like this:
pre
categories:
- 'node'
- 'operatingsystem'
- 'osfamily'
- 'environment'
- 'common'
/pre
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #22646] (In Topic Branch Pending Review) Hiera-2 hiera.yaml/binder_config.yaml - use named attributes, set defaults
Issue #22646 has been updated by Henrik Lindberg.
Status changed from Accepted to In Topic Branch Pending Review
Feature #22646: Hiera-2 hiera.yaml/binder_config.yaml - use named attributes,
set defaults
https://projects.puppetlabs.com/issues/22646#change-98185
* Author: Henrik Lindberg
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee:
* Category: databinding
* Target version:
* Affected Puppet version: 3.3.0
* Keywords: databindings language usability
* Branch: https://github.com/puppetlabs/puppet/pull/1957
Currently three entries in a hiera.yaml category specification are needed to
specify a contribution to to a category.
For humans it is far easier if all elements have a name (unless being a true
multiple value attribute).
i.e. you have to write something like:
pre
['osfamily', '${osfamily}', 'data/osfamily/${osfamily}']
/pre
This makes it difficult to add smart defaults, and support a private (nested
hierarchy). (Separate issues)
Suggests that is done like this:
pre
hiera.yaml
---
version: 3# (since are making changes)
hierarchy:
-
category: 'name'
paths:
- 'path 1'
- 'path 2'
-
category: 'name2'
value: 'some interpolated value'
path: 'a single path'
/pre
The element 'datadir' should also be added to enable defaults to refer to this
location.
When format is change it needs a new version.
The same type of change should be made to binder_config.yaml to make it look
like this:
pre
---
version: 2
layers:
-
name: 'site'
include:
- 'confdir-hiera:/'
- 'confdir:/default?optional'
-
name: 'modules'
include:
- 'module-hiera:/*/'
- 'module:/*::default'
exclude:
- 'module-hiera:/bad_boy/*'
categories:
-
name: 'node'
value: '${fqdn}'
-
name: 'operatingsystem'
value: '${operatingsystem}'
-
name: 'osfamily'
value: '${osfamily}'
-
name: 'environment'
value: '${environment}'
-
name: 'common'
value: true
/pre
Also see #22647 regarding smart default values.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22744] (Unreviewed) static compiler does not filter exported resources from the catalog
Issue #22744 has been reported by R.I. Pienaar.
Bug #22744: static compiler does not filter exported resources from the catalog
https://projects.puppetlabs.com/issues/22744
* Author: R.I. Pienaar
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 3.3.0
* Keywords:
* Branch:
Usually you'd want to not include resources a node is exporting in its catalog:
pre
node foo {
@@notify{x: }
}
/pre
should not have the notify. The static compiler though does not have a filter
method in the node terminus and so the notify is present whenever the static
compiler is used.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22744] static compiler does not filter exported resources from the catalog
Issue #22744 has been updated by R.I. Pienaar.
Simply adding
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/indirector/catalog/compiler.rb#L54-58
to the static_compiler fixes it
Bug #22744: static compiler does not filter exported resources from the catalog
https://projects.puppetlabs.com/issues/22744#change-98188
* Author: R.I. Pienaar
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 3.3.0
* Keywords:
* Branch:
Usually you'd want to not include resources a node is exporting in its catalog:
pre
node foo {
@@notify{x: }
}
/pre
should not have the notify. The static compiler though does not have a filter
method in the node terminus and so the notify is present whenever the static
compiler is used.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22593] future parser lexer does not handle all kinds of interpolated expressions
Issue #22593 has been updated by Andrew Parker.
Branch changed from https://github.com/puppetlabs/puppet/pull/1908 to
https://github.com/puppetlabs/puppet/pull/1958
Updated the tests some to catch a case that wasn't covered. Reworked some of
the code to make sure that there wasn't any code that can't be exercised.
https://github.com/puppetlabs/puppet/pull/1958
Bug #22593: future parser lexer does not handle all kinds of interpolated
expressions
https://projects.puppetlabs.com/issues/22593#change-98192
* Author: Henrik Lindberg
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: Henrik Lindberg
* Category: language
* Target version: 3.4.0
* Affected Puppet version: 3.0.0
* Keywords: language lexer interpolation variables brace
* Branch: https://github.com/puppetlabs/puppet/pull/1958
There are several problems with the future parser's lexer wrt. interpolation.
(The same problem exist in the old lexer, but is
less of a concern as the parser will give bad errors anyway).
* Interpolation does not honor nesting of braces, takes the first r-brace to be
end of interpolated expression. This leads
to an hard to understand syntax error (because the lexer told the parser a
lie). I.e. the marked section is what is lexed as
an epression, the first '}' ends the interpolation.
pre
${x ? { true = 'hi', default = 'goodbye'}}
^--^
/pre
* Since the first bare word is lexed as a variable unless followed by '(' (i.e.
a function call), it is impossible to use
the expressions if, unless, case, undef, true, false without having to
enclose them in parentheses. The lexer should translate these
to the respective keywords instead of treating them as variables (other
keywords does not matter as much - node in particular is
used as a variable. In 3.x. the expressions are not r-values, but in 4x they
will be.
This is bad because it gives the wrong error message when it can do much better
in 3.x, and it prevents a selector expression from being
used in interpolation. For 4.x. it is bad because it also prevents using if,
unless, and case expressions in interpolation.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22593] (Merged - Pending Release) future parser lexer does not handle all kinds of interpolated expressions
Issue #22593 has been updated by Andrew Parker.
Status changed from In Topic Branch Pending Review to Merged - Pending Release
Merged into master in
[67d7e0fa61a](https://github.com/puppetlabs/puppet/commit/67d7e0fa61a92b57e1e9de8694c8766098d7f498)
Bug #22593: future parser lexer does not handle all kinds of interpolated
expressions
https://projects.puppetlabs.com/issues/22593#change-98194
* Author: Henrik Lindberg
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Henrik Lindberg
* Category: language
* Target version: 3.4.0
* Affected Puppet version: 3.0.0
* Keywords: language lexer interpolation variables brace
* Branch: https://github.com/puppetlabs/puppet/pull/1958
There are several problems with the future parser's lexer wrt. interpolation.
(The same problem exist in the old lexer, but is
less of a concern as the parser will give bad errors anyway).
* Interpolation does not honor nesting of braces, takes the first r-brace to be
end of interpolated expression. This leads
to an hard to understand syntax error (because the lexer told the parser a
lie). I.e. the marked section is what is lexed as
an epression, the first '}' ends the interpolation.
pre
${x ? { true = 'hi', default = 'goodbye'}}
^--^
/pre
* Since the first bare word is lexed as a variable unless followed by '(' (i.e.
a function call), it is impossible to use
the expressions if, unless, case, undef, true, false without having to
enclose them in parentheses. The lexer should translate these
to the respective keywords instead of treating them as variables (other
keywords does not matter as much - node in particular is
used as a variable. In 3.x. the expressions are not r-values, but in 4x they
will be.
This is bad because it gives the wrong error message when it can do much better
in 3.x, and it prevents a selector expression from being
used in interpolation. For 4.x. it is bad because it also prevents using if,
unless, and case expressions in interpolation.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #16686] File-Serving Configuration parser does not implement allow_ip statements in fileserver.conf
Issue #16686 has been updated by Daniele Sluijters. Could someone at least update: http://docs.puppetlabs.com/guides/file_serving.html#ip-addresses then? It's confusing people now since it's telling them it's only a bug in 3.0.x. Bug #16686: File-Serving Configuration parser does not implement allow_ip statements in fileserver.conf https://projects.puppetlabs.com/issues/16686#change-98210 * Author: Wolfgang Miedl * Status: Accepted * Priority: Normal * Assignee: * Category: fileserving * Target version: 3.x * Affected Puppet version: 3.0.0 * Keywords: * Branch: In the current 3.0.0 release, the file serving configuration parser incorrectly handles allow_ip statements in fileserver.conf. Both an allow and allow_ip statement will result in Puppet::FileServing::Configuration::Parser.allow being called, which again calls Puppet::Network::AuthStore.allow. This will raise an AuthStoreError in case of an allow_ip statement, as Puppet::Network::AuthStore::Declaration.parse fails to parse the parameter. The fix is to call Puppet::Network::AuthStore.allow_ip instead in case an allow_ip statement is read, which will delegate the parsing to the correct method (Puppet::Network::AuthStore::Declaration.parse_ip) The attached diff illustrates the issue and a possible fix. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22529] (Re-opened) apt package ensure absent/purged causes warnings on 3.3.0
Issue #22529 has been updated by Josh Partlow.
Status changed from Merged - Pending Release to Re-opened
Fails on later dpkg-query versions (1.16+) such as on Wheezy, Raring. Working
on a patch.
Bug #22529: apt package ensure absent/purged causes warnings on 3.3.0
https://projects.puppetlabs.com/issues/22529#change-98213
* Author: Lauri Tirkkonen
* Status: Re-opened
* Priority: Normal
* Assignee: Josh Partlow
* Category:
* Target version: 3.3.1
* Affected Puppet version: 3.3.0
* Keywords:
* Branch: https://github.com/puppetlabs/puppet/pull/1909
Since upgrading to 3.3.0 my Ubuntu agents are reporting new warnings on every
run. This does not happen on 3.2.4 so this is a regression.
# puppet apply -e package {'deja-dup': ensure = purged }
Notice: Compiled catalog for test-precise.niksula.hut.fi in environment
production in 0.10 seconds
Warning: Failed to match dpkg-query line No packages found matching
deja-dup.\n
Notice: Finished catalog run in 0.32 seconds
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22752] (Unreviewed) Namevar over 1024 characters is not caught and results in invalid yaml with accompanying errors
Issue #22752 has been reported by Zachary Stern.
Bug #22752: Namevar over 1024 characters is not caught and results in invalid
yaml with accompanying errors
https://projects.puppetlabs.com/issues/22752
* Author: Zachary Stern
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version:
* Keywords: customer
* Branch:
Puppet resources with namevars over 1024 characters result in the generation of
invalid yaml.
For example, this nonsense resource:
ssh_authorized_key {
'':
ensure = present,
user = 'root',
type = 'rsa',
key = 'foo',
}
Results in the following:
[root@pe-301-master pe-301-master.puppetdebug.vlan]# puppet agent --test
...
Info: Applying configuration version '1380664174'
Notice:
/Stage[main]//Ssh_authorized_key[]/ensure:
created
Info: Creating
[Puppet - Bug #22529] (In Topic Branch Pending Review) apt package ensure absent/purged causes warnings on 3.3.0
Issue #22529 has been updated by Josh Partlow.
Status changed from Re-opened to In Topic Branch Pending Review
Patched by https://github.com/puppetlabs/puppet/pull/1960
Bug #22529: apt package ensure absent/purged causes warnings on 3.3.0
https://projects.puppetlabs.com/issues/22529#change-98223
* Author: Lauri Tirkkonen
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: Josh Partlow
* Category:
* Target version: 3.3.1
* Affected Puppet version: 3.3.0
* Keywords:
* Branch: https://github.com/puppetlabs/puppet/pull/1909
Since upgrading to 3.3.0 my Ubuntu agents are reporting new warnings on every
run. This does not happen on 3.2.4 so this is a regression.
# puppet apply -e package {'deja-dup': ensure = purged }
Notice: Compiled catalog for test-precise.niksula.hut.fi in environment
production in 0.10 seconds
Warning: Failed to match dpkg-query line No packages found matching
deja-dup.\n
Notice: Finished catalog run in 0.32 seconds
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22529] (Merged - Pending Release) apt package ensure absent/purged causes warnings on 3.3.0
Issue #22529 has been updated by Kylo Ginsberg.
Status changed from In Topic Branch Pending Review to Merged - Pending Release
Bug #22529: apt package ensure absent/purged causes warnings on 3.3.0
https://projects.puppetlabs.com/issues/22529#change-98226
* Author: Lauri Tirkkonen
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Josh Partlow
* Category:
* Target version: 3.3.1
* Affected Puppet version: 3.3.0
* Keywords:
* Branch: https://github.com/puppetlabs/puppet/pull/1909
Since upgrading to 3.3.0 my Ubuntu agents are reporting new warnings on every
run. This does not happen on 3.2.4 so this is a regression.
# puppet apply -e package {'deja-dup': ensure = purged }
Notice: Compiled catalog for test-precise.niksula.hut.fi in environment
production in 0.10 seconds
Warning: Failed to match dpkg-query line No packages found matching
deja-dup.\n
Notice: Finished catalog run in 0.32 seconds
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
[Facter - Bug #22322] (Merged - Pending Release) facter should suppress stderr from swap commands on Solaris
Issue #22322 has been updated by Adrien Thebo. Category set to solaris Status changed from In Topic Branch Pending Review to Merged - Pending Release Assignee deleted (Lee Lowder) Target version set to 1.7.4 Keywords changed from solaris customer to solaris swap stderr Merged into stable in f457f59; this should be released in 1.7.4. Bug #22322: facter should suppress stderr from swap commands on Solaris https://projects.puppetlabs.com/issues/22322#change-98227 * Author: Lee Lowder * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: solaris * Target version: 1.7.4 * Keywords: solaris swap stderr * Branch: https://github.com/puppetlabs/facter/pull/530 * Affected Facter version: [ from a customer ] facter should suppress stderr from swap commands on Solaris (2/dev/null) as this causes the pe-mcollective-metadata cron job to spew out many unnecessary emails to root on a system with no swap device. This cron entry causes output (and conversely, an email to root every time it runs): # Puppet Name: pe-mcollective-metadata 0,15,30,45 * * * * /opt/puppet/sbin/refresh-mcollective-metadata Here's the junk from facter, when you do not have swap devices configured. Facter no longer errors when there's no swap device, however it shouldn't output any message (the swap command actually does this, so it needs to be redirected to null --- 2/dev/null) root@mndevadm02 puppetlabs # /opt/puppet/sbin/refresh-mcollective-metadata No swap devices configured No swap devices configured No swap devices configured No swap devices configured -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22752] Namevar over 1024 characters is not caught and results in invalid yaml with accompanying errors
Issue #22752 has been updated by Nick Walker.
Keywords changed from customer to customer support
Bug #22752: Namevar over 1024 characters is not caught and results in invalid
yaml with accompanying errors
https://projects.puppetlabs.com/issues/22752#change-98229
* Author: Zachary Stern
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version:
* Keywords: customer support
* Branch:
Puppet resources with namevars over 1024 characters result in the generation of
invalid yaml.
For example, this nonsense resource:
ssh_authorized_key {
'':
ensure = present,
user = 'root',
type = 'rsa',
key = 'foo',
}
Results in the following:
[root@pe-301-master pe-301-master.puppetdebug.vlan]# puppet agent --test
...
Info: Applying configuration version '1380664174'
Notice:
[Puppet - Bug #22699] (Merged - Pending Release) Boolean parameters/properties (introduced in 3.3) no longer create value_collections
Issue #22699 has been updated by Adrien Thebo. Status changed from In Topic Branch Pending Review to Merged - Pending Release Assignee deleted (Dustin Mitchell) Target version set to 3.4.0 Keywords changed from regression to regression boolean parameter valuecollection reference Merged into master in 80e1bab; this should be released in 3.4.0. Bug #22699: Boolean parameters/properties (introduced in 3.3) no longer create value_collections https://projects.puppetlabs.com/issues/22699#change-98233 * Author: Nick Fagerlund * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: * Target version: 3.4.0 * Affected Puppet version: 3.3.0 * Keywords: regression boolean parameter valuecollection reference * Branch: https://github.com/puppetlabs/puppet/pull/1947 Commit ba7576d3ca6ec681301de83562ec8fd3b8207a8d (Add DRY support for boolean parameters, first shipped in 3.3.0-rc1) caused boolean parameters to bypass the `value_collection` mechanism for declaring allowed values. (The `newvalue` and `newvalues` methods inside a parameter block cause new values to be added to the `value_collection` attr of that parameter; the `value_collection` can be queried once the type is loaded.) This broke the type reference. The #doc method of Puppet::Parameter expects that all valid values will be queryable from the `value_collection` (`@doc += value_collection.doc` around line 119-ish), and now that it's empty, boolean parameters look like they take arbitrary strings instead of strictly limited values. This should be fixed by causing boolean parameters to fill in their `value_collection` appropriately, so we can have a single reliable way to determine allowed values. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- 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 http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #22752] (Investigating) Namevar over 1024 characters is not caught and results in invalid yaml with accompanying errors
Issue #22752 has been updated by Charlie Sharpsteen.
Category set to zaml
Status changed from Unreviewed to Investigating
Assignee set to Charlie Sharpsteen
Bug #22752: Namevar over 1024 characters is not caught and results in invalid
yaml with accompanying errors
https://projects.puppetlabs.com/issues/22752#change-98236
* Author: Zachary Stern
* Status: Investigating
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: zaml
* Target version:
* Affected Puppet version:
* Keywords: customer support
* Branch:
Puppet resources with namevars over 1024 characters result in the generation of
invalid yaml.
For example, this nonsense resource:
ssh_authorized_key {
'':
ensure = present,
user = 'root',
type = 'rsa',
key = 'foo',
}
Results in the following:
[root@pe-301-master pe-301-master.puppetdebug.vlan]# puppet agent --test
...
Info: Applying configuration version '1380664174'
Notice:
[Puppet - Bug #22752] Namevar over 1024 characters is not caught and results in invalid yaml with accompanying errors
Issue #22752 has been updated by Zachary Stern.
I'd be careful about attributing this to zaml per se - same problem occurs
with the core ruby YAML library.
Bug #22752: Namevar over 1024 characters is not caught and results in invalid
yaml with accompanying errors
https://projects.puppetlabs.com/issues/22752#change-98237
* Author: Zachary Stern
* Status: Investigating
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: zaml
* Target version:
* Affected Puppet version:
* Keywords: customer support
* Branch:
Puppet resources with namevars over 1024 characters result in the generation of
invalid yaml.
For example, this nonsense resource:
ssh_authorized_key {
'':
ensure = present,
user = 'root',
type = 'rsa',
key = 'foo',
}
Results in the following:
[root@pe-301-master pe-301-master.puppetdebug.vlan]# puppet agent --test
...
Info: Applying configuration version '1380664174'
Notice:
[Puppet - Bug #22752] Namevar over 1024 characters is not caught and results in invalid yaml with accompanying errors
Issue #22752 has been updated by Charlie Sharpsteen.
Agreed. In truth, I just slapped `zaml` on there because it was the closest
thing to YAML that I could find :P
Bug #22752: Namevar over 1024 characters is not caught and results in invalid
yaml with accompanying errors
https://projects.puppetlabs.com/issues/22752#change-98239
* Author: Zachary Stern
* Status: Investigating
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: zaml
* Target version:
* Affected Puppet version:
* Keywords: customer support
* Branch:
Puppet resources with namevars over 1024 characters result in the generation of
invalid yaml.
For example, this nonsense resource:
ssh_authorized_key {
'':
ensure = present,
user = 'root',
type = 'rsa',
key = 'foo',
}
Results in the following:
[root@pe-301-master pe-301-master.puppetdebug.vlan]# puppet agent --test
...
Info: Applying configuration version '1380664174'
Notice:
