Puppet 3.6.1 Virtual Packages, and unrelated facts questions...

[Paul Seymour]

Hello,

Just updated the test environment to 3.6.1 and I know the changes have been made for virtual packages. But now each agent output displays this:-

Warning: The package type's allow_virtual parameter will be changing its default value from false to true in a future release. If you do not want to allow virtual packages, please explicitly set allow_virtual to false.

   (at /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:816:in `set_default')

I know we can set a top level default but does that really have to come out constantly ?

Now this may be related to 3.6.x but I cannot say for sure. A couple of facts we use are now throwing some errors.

First is:-

Could not retrieve fact='concat_basedir', resolution='<anonymous>': uninitialized constant Puppet

Which comes from:-

Facter.add("concat_basedir") do

    setcode do

        File.join(Puppet[:vardir],"concat")

    end

end

The second is:-

Error converting value for param 'config': Could not find value for $confdir

Which comes from this extract:-

          if Puppet.version.to_i >= 3

            Puppet.settings.initialize_global_settings(Puppet[:config]) unless Puppet.settings.global_defaults_initialized?

          else

            Puppet.parse_config

          end

If I set it with:-

Puppet.settings.initialize_global_settings(["--config=/etc/puppet/puppet.conf"])

Then it works fine.

So it seems they may be related in facter not reading from the puppet.conf file correctly ?

Any help would be appreciated.

Thanks

Paul

[Paul Seymour]

Now this may be related to 3.6.x but I cannot say for sure. A couple of facts we use are now throwing some errors.

First is:-

Could not retrieve fact='concat_basedir', resolution='<anonymous>': uninitialized constant Puppet

Which comes from:-

Facter.add("concat_basedir") do

    setcode do

        File.join(Puppet[:vardir],"concat")

    end

end

The second is:-

Error converting value for param 'config': Could not find value for $confdir

Which comes from this extract:-

          if Puppet.version.to_i >= 3

            Puppet.settings.initialize_global_settings(Puppet[:config]) unless Puppet.settings.global_defaults_initialized?

          else

            Puppet.parse_config

          end

If I set it with:-

Puppet.settings.initialize_global_settings(["--config=/etc/puppet/puppet.conf"])

I am of course a (hungover) idiot. Running with "facter -p" pulls those Puppet config settings in just fine..... 

[Dominic Cleal]

On 23/05/14 09:31, Paul Seymour wrote:
> Just updated the test environment to 3.6.1 and I know the changes have
> been made for virtual packages. But now each agent output displays this:-
>
> Warning: The package type's allow_virtual parameter will be changing its
> default value from false to true in a future release. If you do not want
> to allow virtual packages, please explicitly set allow_virtual to false.
> (at /usr/lib/ruby/site_ruby/1.8/puppet/type.rb:816:in `set_default')
>
> I know we can set a top level default but does that really have to come
> out constantly ?

I agree, I was thinking of filing a bug for this to request that it's
dialled down to info or notice level, if it must be printed at all.

Deprecation information at warning level might make sense if the user
must make a change, e.g. in cases where a parameter is being removed,
but it's unduly noisy at 'warning' level when in the vast majority of
cases users need to take no action.

--
Dominic Cleal
Red Hat Engineering

[Peter Meier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> I know we can set a top level default but does that really have
>> to come out constantly ?
>
> I agree, I was thinking of filing a bug for this to request that
> it's dialled down to info or notice level, if it must be printed at
> all.
>
> Deprecation information at warning level might make sense if the
> user must make a change, e.g. in cases where a parameter is being
> removed, but it's unduly noisy at 'warning' level when in the vast
> majority of cases users need to take no action.

+1 - let's file a bug report.

~pete

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlN/FzkACgkQbwltcAfKi3/4WwCdEJ1vMif1KXq4CW27HFfXrObc
77wAoILuLKVZZhpISJQtOjBHosSd50OA
=PPxv
-----END PGP SIGNATURE-----

[Paul Seymour]

+1 - let's file a bug report.

https://tickets.puppetlabs.com/browse/PUP-2650

 

[Kylo Ginsberg]

On Fri, May 23, 2014 at 2:58 AM, Paul Seymour <paul.s...@ig.com> wrote:

+1 - let's file a bug report.

https://tickets.puppetlabs.com/browse/PUP-2650

For more context here, puppet has a 'deprecation_warning' method which is used for this new message and also in a number of other places. In puppet 3.7, we're planning to introduce a number of additional deprecation messages (for functionality which will be removed in puppet 4)

So there are at least two possibilities here:

1) Make all deprecation messages Info-level rather than Warning-level. So you'd need to specify --verbose to see the deprecation messages.

2) Leave the deprecation messages at Warning-level, but add a 'warn-on-deprecation' setting (possibly with a better name).

In either case, you'd need to flip a setting to see the deprecation messages (whereas they are in your face today).

The downside to (1) is that the deprecation messages would be mixed in with other Info messages that might not be of interest to the person planning their migration to puppet 4.

The downside to (2) is it's Yet Another Setting and as such it might not be used as much (i.e. puppet 4 might take more people by surprise).

Thoughts?

Kylo

--

Kylo Ginsberg

ky...@puppetlabs.com

Join us at PuppetConf 2014, September 23-24 in San Francisco - http://puppetconf.com 

Register by May 30th to take advantage of the Early Adopter discount —save $349!

[Rob Reynolds]

On Fri, May 23, 2014 at 12:00 PM, Kylo Ginsberg <ky...@puppetlabs.com> wrote:

On Fri, May 23, 2014 at 2:58 AM, Paul Seymour <paul.s...@ig.com> wrote:

+1 - let's file a bug report.

https://tickets.puppetlabs.com/browse/PUP-2650

For more context here, puppet has a 'deprecation_warning' method which is used for this new message and also in a number of other places. In puppet 3.7, we're planning to introduce a number of additional deprecation messages (for functionality which will be removed in puppet 4)

So there are at least two possibilities here:

1) Make all deprecation messages Info-level rather than Warning-level. So you'd need to specify --verbose to see the deprecation messages.

2) Leave the deprecation messages at Warning-level, but add a 'warn-on-deprecation' setting (possibly with a better name).

How about an ignore-deprecation-warnings setting? This way it's more in your face at start but once you are familiar with the things going away you might want to turn it off?  It doesn't seem like there is an optimal way of introducing deprecation warnings without some level of surprise. 

 

In either case, you'd need to flip a setting to see the deprecation messages (whereas they are in your face today).

The downside to (1) is that the deprecation messages would be mixed in with other Info messages that might not be of interest to the person planning their migration to puppet 4.

The downside to (2) is it's Yet Another Setting and as such it might not be used as much (i.e. puppet 4 might take more people by surprise).

Thoughts?

Kylo

--

Kylo Ginsberg

ky...@puppetlabs.com

Join us at PuppetConf 2014, September 23-24 in San Francisco - http://puppetconf.com 

Register by May 30th to take advantage of the Early Adopter discount —save $349!

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CALsUZFEb9%3DF4vXxc9O6E%3D_agzjuNi_sOgx0P2W-y1C0xA1KHXA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Rob Reynolds

Developer, Puppet Labs

Join us at PuppetConf 2014, September 23-24 in San Francisco

[Felix Frank]

On 05/23/2014 07:00 PM, Kylo Ginsberg wrote:
> The downside to (2) is it's Yet Another Setting and as such it might not
> be used as much (i.e. puppet 4 might take more people by surprise).

Sure enough, but looking at all the breaking changes looming on the
Puppet 4 horizon, the release notes will want to include a section
"bootstrapping your setup for the upgrade" which outlines steps such as
"install latest 3.x release on all machines, compile all manifests" etc.

This outline could easily be extended to cover "enable the deprecation
warnings", if we go for such a solution.

Cheers,
Felix

[jcbollinger]

On Friday, May 23, 2014 2:37:16 PM UTC-5, Rob Reynolds wrote:

On Fri, May 23, 2014 at 12:00 PM, Kylo Ginsberg <ky...@puppetlabs.com> wrote:

On Fri, May 23, 2014 at 2:58 AM, Paul Seymour <paul.s...@ig.com> wrote:

+1 - let's file a bug report.

https://tickets.puppetlabs.com/browse/PUP-2650

For more context here, puppet has a 'deprecation_warning' method which is used for this new message and also in a number of other places. In puppet 3.7, we're planning to introduce a number of additional deprecation messages (for functionality which will be removed in puppet 4)

So there are at least two possibilities here:

1) Make all deprecation messages Info-level rather than Warning-level. So you'd need to specify --verbose to see the deprecation messages.

2) Leave the deprecation messages at Warning-level, but add a 'warn-on-deprecation' setting (possibly with a better name).

How about an ignore-deprecation-warnings setting? This way it's more in your face at start but once you are familiar with the things going away you might want to turn it off?  It doesn't seem like there is an optimal way of introducing deprecation warnings without some level of surprise. 

+1

By default, deprecation messages should be warnings, and they should be enabled.  It is perfectly reasonable, however, to have an option to turn them off.  Or alternatively, perhaps an option to lower (or raise) their severity level.

John

[Chuck]

The ability to turn off the deprecation messages would be great.  The only things these messages provide are a drain on logging resources, noise in the logs, and confusion from end users.

[Kylo Ginsberg]

On Tue, May 27, 2014 at 7:16 AM, Chuck <css...@gmail.com> wrote:

The ability to turn off the deprecation messages would be great.  The only things these messages provide are a drain on logging resources, noise in the logs, and confusion from end users.

Seems like we have consensus on an ignore-deprecation-warnings setting, which defaults to false. 

And I like Felix's suggestion that the (as yet unwritten) puppet-4 migration guide will recommend restoring that default.

[Andy Parker]

On Tue, May 27, 2014 at 11:33 AM, Kylo Ginsberg <ky...@puppetlabs.com> wrote:

On Tue, May 27, 2014 at 7:16 AM, Chuck <css...@gmail.com> wrote:

The ability to turn off the deprecation messages would be great.  The only things these messages provide are a drain on logging resources, noise in the logs, and confusion from end users.

Seems like we have consensus on an ignore-deprecation-warnings setting, which defaults to false. 

I think a 'deprecation-level' setting might be more in keeping with logging. It defaults to warn, but can be turned down to debug if you don't want to normally see them.

 

And I like Felix's suggestion that the (as yet unwritten) puppet-4 migration guide will recommend restoring that default.

 

Kylo

--

Kylo Ginsberg

ky...@puppetlabs.com

Join us at PuppetConf 2014, September 23-24 in San Francisco - http://puppetconf.com 

Register by May 30th to take advantage of the Early Adopter discount —save $349!

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CALsUZFFXRiQX4wDc5TjoZWXAz-q7-kdO%2Bx%2B6%3DpdsdvN4HKYFvw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Andrew Parker

an...@puppetlabs.com

Freenode: zaphod42

Twitter: @aparker42

Software Developer

Join us at PuppetConf 2014, September 22-24 in San Francisco

[Kylo Ginsberg]

On Wed, May 28, 2014 at 1:53 PM, Andy Parker <an...@puppetlabs.com> wrote:

On Tue, May 27, 2014 at 11:33 AM, Kylo Ginsberg <ky...@puppetlabs.com> wrote:

On Tue, May 27, 2014 at 7:16 AM, Chuck <css...@gmail.com> wrote:

The ability to turn off the deprecation messages would be great.  The only things these messages provide are a drain on logging resources, noise in the logs, and confusion from end users.

Seems like we have consensus on an ignore-deprecation-warnings setting, which defaults to false. 

I think a 'deprecation-level' setting might be more in keeping with logging. It defaults to warn, but can be turned down to debug if you don't want to normally see them.

This seems like it might cause some confusion if users are grepping their logs and not sure if the deprecations are warning/info/debug? I'm more familiar with the model of enabling/disabling a class of warnings (a la gcc or linters, etc).

But I have no strong feelings here other than wanting to get this addressed in 3.6.2. Anyone else care to weigh in?

 

[Clayton O'Neill]

On Thu, May 29, 2014 at 11:30 AM, Kylo Ginsberg <ky...@puppetlabs.com> wrote:

I think a 'deprecation-level' setting might be more in keeping with logging. It defaults to warn, but can be turned down to debug if you don't want to normally see them.

This seems like it might cause some confusion if users are grepping their logs and not sure if the deprecations are warning/info/debug? I'm more familiar with the model of enabling/disabling a class of warnings (a la gcc or linters, etc).

But I have no strong feelings here other than wanting to get this addressed in 3.6.2. Anyone else care to weigh in?

I'd like the ability to turn off individual deprecation warnings, like a lint check would allow doing.  For example, every time I run puppet 3.6.1 right now I get warnings about setting manifest and module path, because we've not moved to directory environments yet.  I've read enough people say they're having weird issues about directory environments that I'm going to hold off a few weeks and see how things go.  I don't want to disable all deprecation warnings, because if I do something new that triggers a different one, I want to know.

[Andy Parker]

On Thu, May 29, 2014 at 8:30 AM, Kylo Ginsberg <ky...@puppetlabs.com> wrote:

On Wed, May 28, 2014 at 1:53 PM, Andy Parker <an...@puppetlabs.com> wrote:

On Tue, May 27, 2014 at 11:33 AM, Kylo Ginsberg <ky...@puppetlabs.com> wrote:

On Tue, May 27, 2014 at 7:16 AM, Chuck <css...@gmail.com> wrote:

The ability to turn off the deprecation messages would be great.  The only things these messages provide are a drain on logging resources, noise in the logs, and confusion from end users.

Seems like we have consensus on an ignore-deprecation-warnings setting, which defaults to false. 

I think a 'deprecation-level' setting might be more in keeping with logging. It defaults to warn, but can be turned down to debug if you don't want to normally see them.

This seems like it might cause some confusion if users are grepping their logs and not sure if the deprecations are warning/info/debug? I'm more familiar with the model of enabling/disabling a class of warnings (a la gcc or linters, etc).

Agreed. I didn't think about it from that angle.

In that case, let's design it as a bit more expandable of a design and have a "warnings" or "warn_on" setting that takes a list of values. Initially it will just have "deprecations" and "all", but over time we should classify various DSL warnings once we have a better analysis phase in the parser, "provider". The logical conclusion of this is that we would end up creating some mini-language there for doing exclusions. I don't really want something that complex.

The desire is really to *disable* certain classes of warnings, so a "disable-warnings" setting that defaults to nothing and can be set to "deprecations" seems like a good, straightforward, and expandable solution.

 

But I have no strong feelings here other than wanting to get this addressed in 3.6.2. Anyone else care to weigh in?

 

--

Kylo Ginsberg

ky...@puppetlabs.com

Join us at PuppetConf 2014, September 23-24 in San Francisco - http://puppetconf.com 

Register by May 30th to take advantage of the Early Adopter discount —save $349!

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CALsUZFHyt4UvcNKk0W5L1eZnN2h_qVT3UEF_muQPNz4xyH%2B3hw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Andrew Parker

an...@puppetlabs.com

Freenode: zaphod42

Twitter: @aparker42

Software Developer

Join us at PuppetConf 2014, September 22-24 in San Francisco

[Garrett Honeycutt]

Hi,

Don't mean to move the thread away from the logging issue, just wanted
to post a potential fix for others who want this solved, especially if
all of your nodes are not upgraded at the same time. To do so, I added
the following to my site.pp

if versioncmp($::puppetversion,'3.6.1') >= 0 {

$allow_virtual_packages = hiera('allow_virtual_packages',false)

Package {
allow_virtual => $allow_virtual_packages,
}
}

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658