(PDK-1339) Read or interview for analytics config

[rodjek]

On the first run of PDK if the vendor-wide analytics config file is absent ($XDG_CONFIG_HOME/puppetlabs/analytics.yml or %LOCALAPPDATA%/puppetlabs/analytics.yml) the user will be greeted with the following question.

pdk (INFO): PDK collects anonymous usage information to help us understand how it is being used and make decisions on how to improve it. You can find out more about what data we collect and how it is used in the PDK documentation at https://puppet.com/docs/pdk/.
[Q 1/1] Do you consent to the collection of anonymous PDK usage information?
--> Yes

pdk (INFO): You can opt in or out of the usage data collection at any time by editing the analytics configuration file at /home/tsharpe/.config/puppetlabs/analytics.yml and changing the 'disabled' value.

If PDK is not being run interactively (i.e. being called from a script) then the interview will be skipped and the user will be automatically opted out of analytics.

[coveralls]

Coverage increased (+0.3%) to 93.328% when pulling 072dfb8 on rodjek:pdk-1339 into d3db714 on puppetlabs:master.

[scotje]

Overall I think this is looking great @rodjek ! I think it makes a great framework to initially provide a consistent interface over a bunch of disparate config files while also letting us slowly unify/replace those config files when and where it makes sense.

I know this is still WIP so I wanted to check if it was already in your plans to have PDK read the values from the Bolt config if present on first run, but then write them out to the vendor config location so that we don't lose that config if the user later uninstalls Bolt and/or deletes their Bolt config dir?

Also where would you envision hooking in a prompt if we wanted to interactively ask them if they want to opt-out absent any existing config?

[rodjek]

I know this is still WIP so I wanted to check if it was already in your plans to have PDK read the values from the Bolt config if present on first run, but then write them out to the vendor config location so that we don't lose that config if the user later uninstalls Bolt and/or deletes their Bolt config dir?

Yep, it all happens in where the user.analytics configuration is defined. If we can't load the values from the mounted vendor-wide config, it'll default to the value from the bolt configuration (if it exists). eg https://github.com/puppetlabs/pdk/pull/657/files#diff-062b30bfb8a3ec0cbbb1df8a3e3b1df6R20

When the default_to blocks are executed, they automatically trigger the configuration to be written to disk after the value is resolved, so we basically get the config migration for free.

Also where would you envision hooking in a prompt if we wanted to interactively ask them if they want to opt-out absent any existing config?

My plan is to check for the presence of the vendor-wide config file when the CLI is instantiated but before the analytics client is instantiated. If the file doesn't exist, we'll inform the user and give them a link to the analytics documentation. It won't be an interactive prompt though, partly because that's not what's in the ticket but mostly because that would interfere with any automated --force workflows that users might have.

[scotje]

My plan is to check for the presence of the vendor-wide config file when the CLI is instantiated but before the analytics client is instantiated. If the file doesn't exist, we'll inform the user and give them a link to the analytics documentation. It won't be an interactive prompt though, partly because that's not what's in the ticket but mostly because that would interfere with any automated --force workflows that users might have.

OK, we should discuss this with @turbodog more because I think he was hoping we could have a prompt. (I think it would be reasonable to bypass the prompt on any --force invocations.)

[turbodog]

Yeah I agree that we should go with the prompt route. If --force is present and there's no setting set then maybe print a warning?

[jbondpdx]

@rodjek , the text looks good to me! Let's make the URL https://puppet.com/docs/pdk/latest/pdk_install.html.

[rodjek]

Thanks @jbondpdx, I've updated the URL!

[scotje]

Looks good to me! I left a few small comments but nothing that should block merging.

Nowhere is actually instantiating an analytics client yet correct? So I shouldn't expect to see the debug messages yet?

[scotje]

We should maybe pre-word wrap these at 80 characters or something. Right now the terminal will wrap in the middle of a word. :)

[scotje]

Also an extra newline after the "post_message" would help it to not get lost in the results of the actual command they ran.

[rodjek]

I've updated the logger formatter so that we can optionally word wrap the output (and indent the wrapped lines for readability) which gives us the following:

pdk (INFO): PDK collects anonymous usage information to help us understand how
            it is being used and make decisions on how to improve it. You can
            find out more about what data we collect and how it is used in the
            PDK documentation at
            https://puppet.com/docs/pdk/latest/pdk_install.html.

[Q 1/1] Do you consent to the collection of anonymous PDK usage information?
--> Yes

pdk (INFO): You can opt in or out of the usage data collection at any time by
            editing the analytics configuration file at
            /home/tsharpe/.config/puppet/analytics.yml and changing the
            'disabled' value.

[scotje]

Should we take this opportunity to rename this to ~/.config/puppet/analytics.yml or are there other things already using ~/.config/puppetlabs?

[rodjek]

I'm 👍 to using puppet instead of puppetlabs

[smortex]

If PDK is not being run interactively (i.e. being called from a script) then the interview will be skipped and the user will be automatically opted out of analytics.

This seems to not work as expected on Travis-CI:
https://travis-ci.com/smortex/puppet-riemann/jobs/211705608