Thanks . I filed a new ticket . Can you comment how you're are generating that output on the new ticket, including which version of the mysql module you're using?

This change caused a regression. The option --to_yaml no longer generates syntactically valid YAML.

Before pull request #7718:

After pull request #7718:

Merged to 5.5.x in https://github.com/puppetlabs/puppet/commit/0cfcb63c4599ee50e1a664c850e46d281f2bf68d

I have also been seeing this with a client. They're using `puppet resource pe_node_group` on PE which outputs:

The classes parameter is a Hash internally.

YAML implementations can't parse the above output. As a workaround we found that a simple s/=>/:/g fixes the problem, but obviously that's not ideal.

The --to_yaml option in Puppet::Application::Resource ends up invoking Puppet::Resource.to_hierayaml. This function outputs the YAML with the following code:

The Puppet::Parameter.format_value_for_display function formats the Hash in a Puppet style, which is why we get the mixed syntax. The format_value_for_display function doesn't take any additional parameters currently that would easily allow us to do YAML-specific formatting.

Puppet::Parameter.format_value_for_display does the following:

Based on my reading, it seems that using DEFAULT_PARAMETER_FORMAT will cause the StringConvert to default to DEFAULT_HASH_FORMAT (shown below).

This format is appropriate for Puppet code but the ' => ' separator does not work for YAML output.

One possible fix would be to provide Puppet::Pops::Types::StringConverter.convert with a format hash that overrides the separator2 field. It would also require either altering Puppet::Parameter.format_value_for_display to accept the overrides or create a new function (e.g. format_value_for_yaml) as appropriate.

I think that would be sufficient to make this work. I don't know of any other spots where the manifest output would break YAML parsing, but I also haven't done a comprehensive check on that.

I've been working through converting a brownfield AWS environment to Puppet managed and there's a significant amount of nested json coming through when using the --to_yaml (-y) flag with puppet resource. Having the output correctly formatted at all layers in yaml would be a huge help.

The gist links are identical?

What I'm getting from a custom resource is the following, which is a reasonable translation into a .pp format.

dpw_wsendpointremoterewriterules { 'BAR:FOO_WEBSERVICE':
  ensure => 'present',
  domain => 'BAR',
  rules => [
  {
    'ServicePortMatchRegexp' => '^{https://foo/webservice/}barGet$',
    'RemoteEndpointProtocol' => 'https',
    'RemoteEndpointHostname' => 'mock',
    'RemoteEndpointPort' => 8443,
    'RemoteEndpointURI' => '/webservice/bar.asmx',
    'RemoteMQQM' => '',
    'RemoteTibcoEMS' => '',
    'RemoteWebSphereJMS' => ''
  }, ...

But when I specify --to_yaml, I'm getting this half/n/half translation.  The rules, which are an array of hashes are not being translated correctly.

dpw_wsendpointremoterewriterules:
  BAR:FOO_WEBSERVICE:
    ensure: 'present'
    domain: 'BAR'
    rules : [
  {
    'ServicePortMatchRegexp' => '^{[https://foo/webservice/]}barGet$',
    'RemoteEndpointProtocol' => 'https',
    'RemoteEndpointHostname' => 'mock',
    'RemoteEndpointPort' => 8443,
    'RemoteEndpointURI' => '/webservice/bar.asmx',
    'RemoteMQQM' => '',
    'RemoteTibcoEMS' => '',
    'RemoteWebSphereJMS' => ''
  }, ...

I would instead expect to see the following:

dpw_wsendpointremoterewriterules:
  BAR:FOO_WEBSERVICE:
    ensure: 'present'
    domain: 'BAR'
    rules:
      - 'ServicePortMatchRegexp' => '^{[https://foo/webservice/]}barGet$',
        'RemoteEndpointProtocol' => 'https',
        'RemoteEndpointHostname' => 'mock',
        'RemoteEndpointPort' => 8443,
        'RemoteEndpointURI' => '/webservice/bar.asmx',
        'RemoteMQQM' => '',
        'RemoteTibcoEMS' => '',
        'RemoteWebSphereJMS' => ''
      - ...