puppetlabs/puppetlabs-inifile

Resource types for managing settings in INI files

puppetlabs-inifile's Issues

space in setting name

rsyncd.conf has a parameter of:

hosts allow = foo, bar

It would be nice to support a setting with a space in the name. Currently, it just adds the setting over & over.

Support for section-less config files

Thanks for providing this handy class! Unfortunately I have some config files (i.e. tomcat7.conf) that do not have sections at all. Adding or changing values becomes impossible, since it always adds a [global] or [] section. Is there a fix of am I just doing it the wrong way?

Fails with Invalid resource type error on 2.6.9

I'm using an oldish version of puppet (2.6.9) and trying to use Stephen R Johnson's puppet module which requires inifile.

I get this error:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type ini_setting at /etc/puppet/environments/development/modules/puppet/manifests/agent.pp:185 on node a090.example.com

Add support for "purge"

This is a feature that Dan has been asking about. The idea is that we might provide a base type or provider that users could extend to create a custom type/provider, e.g., "PuppetDBConfIniFile". Then they could use Puppet's "purge" feature to make sure that everything was removed from the specific config file except for settings that were explicitly defined in their catalogs.

Can't set the same key twice

If I want the same key twice in an ini file (which is not, I think, a general property of ini files, but one that Openstack nevertheless uses for certain types), I can't. Can I suggest we use something of the form: value => ['a', 'b', 'c'] ?

(reported via Dan a few weeks ago, but it's not a bug here, so I'm being tidy)

Allow to set a header to the beginning of a configuration file

Use Case

I am trying to set the contents of a config file in a custom module utilizing the functionality this module provides. In order to be able to see directly what configuration file are written by puppet, I usually put a header such as #managed by puppet on the first line of the configuration file.

Describe the Solution You Would Like

I would like to have a header ini_setting that allows me to set this comment on the beginning of a file.
So that it looks like this or something similar:

# managed by puppet

[section 1]
....

Describe Alternatives You've Considered

I tried so manually do this with:

  ini_setting {"comment":
    path    => '/path/to/configuration.conf',
    section => 'Managed by Puppet',
    section_prefix => '#',
    section_suffix => '',
  }

In addition to using the inifile::create_ini_settings I use for actually writing the rest of the configuration file.
However this does put the comment in the beginning of the file. Rather it always puts the comment on the last line (which is not really helping when considering long configuration files.)
This behaviour seems independent of the positioning of the comment-ini_setting in the code (bevore or after using the function)
Additionally this brakes idempotency in the latest puppetforge version, as fixed by #483 (is there a release planned in the near future to push this change?)

Additional Context

I guess this touches a bit on #72, but as this was never resolved I wanted to reopen the discussion.
I am not sure how I would be able to influence the order of the sections.
I did look into implementing child providers. I guess my solution is somewhere there? But then we maybe can improve the documentation with a working example of such a use case? I would guess I am not the only one who would appreciate the possibility to provide a header :)
Let me know your thoughts on this :)

lines with trailing = signs are not matched

if you have a line like this in your ini file:

foo =

It will not match the regular expression and will be ignored; modifications to a "foo" setting will result in another "foo" line being written to the file, which seems wrong.

Ordering of parameters

Not sure if this is a bug, an undocumented feature, or a feature request, but I do not see a way to ensure the order of multiple additions to a file.

I was tinkering with a copy of my puppet.conf, adding a variable definition :

confdir = /tmp/foo/puppet

and then adding another definition that used it

modulepath = $confdir/custom/modules

And on repeated runs (removing the added lines each time), I cannot ensure the ordering and expect that in some cases things would break.

Getting incomplete files and lines with only 'nil'

Using this for puppetlabs-nova testing I am getting very inconsistent results. On the compute I get only a portion of the conf fille on one run, then next run chops half content out. this goes back and forth. I also get lines with nothing but 'nil' on them.

Error: Could not set 'present' on ensure: no implicit conversion from nil to integer

We get the following error, on one server, when we try to use this module:

Error: Could not set 'present' on ensure: no implicit conversion from nil to integer at 120:/etc/puppet/environments/staging/modules/emservers/manifests/webservers/papplications.pp
Error: Could not set 'present' on ensure: no implicit conversion from nil to integer at 120:/etc/puppet/environments/staging/modules/emservers/manifests/webservers/papplications.ppWrapped exception:
no implicit conversion from nil to integer
Error: /Stage[main]/Emservers::Webservers::Papplications/Ini_setting[mb_encoding_translation]/ensure: change from absent to present failed: Could not set 'present' on ensure: no implicit conversion from nil     tointeger at 120:/etc/puppet/environments/staging/modules/emservers/manifests/webservers/papplications.pp
Error: Could not set 'present' on ensure: no implicit conversion from nil to integer at 104:/etc/puppet/environments/staging/modules/emservers/manifests/webservers/papplications.pp
Error: Could not set 'present' on ensure: no implicit conversion from nil to integer at 104:/etc/puppet/environments/staging/modules/emservers/manifests/webservers/papplications.pp

Our code looks like this:

ini_setting {'mb_int_encoding':
  path     => '/etc/php5/apache2/php.ini',
  sectioin => 'mbstring',
  setting  => 'mbstring.internal_encoding',
  value    => 'UTF-8',
  ensure   => present,
}
ini_setting {'mb_http_input':
  path    => '/etc/php5/apache2/php.ini',
  section => 'mbstring',
  setting => 'mbstring.http_input',
  value   => 'UTF-8',
  ensure  => present,
}
ini_setting {'mb_http_output':
  path    => '/etc/php5/apache2/php.ini',
  section => 'mbstring',
  setting => 'mbstring.http_output',
  value   => 'UTF-8',
  ensure  => present,
}
ini_setting {'mb_encoding_translation':
  ensure  => present,
  path    => '/etc/php5/apache2/php.ini',
  section => 'mbstring',
  setting => 'mbstring.encoding_translation',
  value   => 'On',
}
ini_setting {'mb_detect_order':
  path    => '/etc/php5/apache2/php.ini',
  section => 'mbstring',
  setting => 'mbstring.detect_order',
  value   => 'auto',
  ensure  => present,
}
ini_setting {'mb_substitute_character':
  path    => '/etc/php5/apache2/php.ini',
  section => 'mbstring',
  setting => 'mbstring.substitute_character',
  value   => 'long',
  ensure  => present,
}
ini_setting {'mb_func_overload':
  path    => '/etc/php5/apache2/php.ini',
  section => 'mbstring',
  setting => 'mbstring.func_overload',
  value   => '1',
  ensure  => present,
}  

Any thoughts?

stdlib 9.x.x compat

Is your feature request related to a problem? Please describe.
With the new release of stdlib 9.x, the module dependencies should be updated

Describe the solution you'd like
Compatibility with stdlib 9.x

Describe alternatives you've considered
Staying locked at an older version

Additional context
https://forge.puppet.com/modules/puppetlabs/stdlib/changelog

init_setting resource to create an empty section breaks idempotency

Describe the Bug

When a manifests include the ini_settings resource to mange an empty section,
applying the manifests detect change in every run.

[vagrant@localhost ~]$ cat sectiononly.pp 
$testpath = '/home/vagrant/foo.ini'file { $testpath:
  ensure => present
}ini_setting { 'test':
  ensure  => present,
  section => 'test',
  path    => $testpath,
}File <||> -> Ini_setting <||>
[vagrant@localhost ~]$ puppet apply sectiononly.pp   --modulepath /usr/share/openstack-puppet/modules/
Notice: Compiled catalog for localhost.localdomain in environment production in 0.02 seconds
Notice: /Stage[main]/Main/File[/home/vagrant/foo.ini]/ensure: created
Notice: /Stage[main]/Main/Ini_setting[test]/ensure: created
Notice: Applied catalog in 0.01 seconds
[vagrant@localhost ~]$ cat foo.ini 
[test]
[vagrant@localhost ~]$ puppet apply sectiononly.pp   --modulepath /usr/share/openstack-puppet/modules/
Notice: Compiled catalog for localhost.localdomain in environment production in 0.02 seconds
Notice: /Stage[main]/Main/Ini_setting[test]/ensure: created
Notice: Applied catalog in 0.02 seconds
[vagrant@localhost ~]$ cat foo.ini 
[test]
[vagrant@localhost ~]$ puppet apply sectiononly.pp   --modulepath /usr/share/openstack-puppet/modules/
Notice: Compiled catalog for localhost.localdomain in environment production in 0.02 seconds
Notice: /Stage[main]/Main/Ini_setting[test]/ensure: created
Notice: Applied catalog in 0.02 seconds
[vagrant@localhost ~]$

Expected Behavior

The resource should not break idempotency

Steps to Reproduce

The example manifest to reproduce the problem can be found in the bug description.

Environment

• Version: 5.3.1
• Puppet Version: 7.16.1
• Platform: CentOS Stream 9

Additional Context

N/A

last commit breaks inifile

08346e9 ,( #77 ) is breaking inifile, travis and downstream users

https://travis-ci.org/puppetlabs/puppetlabs-inifile/jobs/19609590#L205

Warnings about already introduced constant

When using in Puppet or even when running the specs, we often get warnings about the REGEX constants already being defined.

Enhancement: Support adding comments above ini_setting

It'd be nice to have a comment => 'some comment here' option that adds a comment right above the ini_setting.

  ini_setting { 'example of comment feature':
    ensure  => 'present',
    path    => '/etc/some.conf',
    section => 'CoolSection',
    setting => 'HandyKey',
    value   => 'UsefulValue',
    comment => 'This setting allows for blah blah blah'
  }

This would result in:

[CoolSection]
# This setting allows for blah blah blah
HandyKey = UsefulValue

inifile non longer idempotent

In the past inifile did not edit a file unless there were changes. Now it rebuild the file at every run. This massively increases the risk of system breakage as we are seeing already with the partial files and nil entries. This must be idempotent to be functional for production.

data not written to ini file on amazon linux

Hello, not sure what the underlying issue is, looking for guidance to troubleshooting this.

When running ini_setting on amazon linux, nothing is being written to the specified ini file.

[root@ip tmp]# cat test.pp

ini_setting { "sample setting":
path => '/tmp/foo.ini',
section => 'foo',
setting => 'foosetting',
value => 'FOO!',
ensure => present,
}

[root@ip tmp]# puppet apply test.pp
notice: Finished catalog run in 0.08 seconds
cat /tmp/foo.ini
[root@ip tmp]#

Spacing around settings/value causes some ini parsers to fail

I was attempting to edit my avahi-daemon.conf file with this module using code like:

ini_setting { "avahi-hostname": ensure => present, path => '/etc/avahi/avahi-daemon.conf', section => 'server', setting => 'host-name', value => $::hostname, notify => Service['avahi-daemon'], }

It ended up like
host-name = duo

This caused avahi to fail on reloads because for some stupid reason it doesn't like whitespace before/after the = sign.

I normally like the whitespace around the =, but in this case it causes failure. Perhaps you could add an param to strip whitespace?

Dealing with empty values

Hello,

The puppet openstack modules use the inifile type quite heavily. The basic pattern is that parameters are passed into the module which are then sent to a grouped type to be added to the file.

When setting a value to '', the key is added to the file and the value is empty (which makes logical sense) but upon re-running puppet, the same key is added again so now there are two keys in the file with blank values.

I'm sure empty values break ini file standards, so maybe the best way to handle this is to remove the key from the file when an empty value is given?

This, of course, can be solved with an "ensure => absent" attribute, but in the case of how inifile is being used in the puppet modules, there's no easy way to add this attribute to the grouped inifile resources. We'd have to break each resource out of the grouped resource and apply a parallel "ensure" parameter for the parameter it relates to.

"undef" will simply ignore the resource altogether. This works if the resource was always set to "undef" and you always want to ignore it. But as soon as you give it a non-undef value, you cannot use undef to remove or empty out the value -- undef will continue to ignore the value regardless of what's already in the file.

Please let me know if you need clarification on anything.

Thanks,
Joe

using different keyval separators like :

I have a properties file which I would like to manage for my resin application server but the separator is a : rather than a =. it looks like

app-0.jvm_args: -Xss1m -Xdebug -server -d64 -Xms1024m -Xmx1024m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m

So I thought the ini_subsetting type would be great for adding in extra params like -XX:MaxPermSize=256m to the line but in testing it always looks for a = and i guess keyval separator is more meant for dealing with whitespaces than other separators. I was wondering if this is something you would be implementing in the future, or if maybe i can create a child class to change the separator, or maybe if there is another puppet module more suitable for managing this type of resource? Thanks :)

Can set value for a section contaning quotes

Describe the Bug

Setting values for a section name containing a quote (") fails when running puppet second time.

Expected Behavior

Multiple runs should not fail.

Steps to Reproduce

Steps to reproduce the behavior:

1. I'm trying to set a configuration key under a section named:
   plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options
2. Run puppet once, this works fine when the section did not exist before.
3. Run puppet second time, now it fails with:
   Error: /Stage[main]/Labb/Ini_subsetting[containerd_systemd]: Could not evaluate: undefined method `+' for nil:NilClass

Environment

• Puppet version 7.21.0
• Ubuntun 20.04

Additional Context

Please add a LICENSE file

Can you please add a license to this module? I'd like to use the puppetlabs OpenStack modules, and they depend on this module. I know that the Modulefile says that it's using the "Apache" license, but the legal team at $work are sticklers and they'll want me to make sure there's an actual license available before I use this module.

Thanks very much.

Dangling section headers persist in INI files when sections contain whitespace

Describe the Bug

When removing the only setting in a section, the section header still remains when the section contains whitespace. As a result, trailing section headers (i.e. sections without any settings) will persist in INI files like below and eventually cause unnecessary clutter:

# cat /tmp/test.ini
[section1]

[section2]

Expected Behavior

We would expect to see section headers to be removed when we are removing the last and only setting in a section.

Steps to Reproduce

Here is an example of a section with a singular setting, in which the empty section header still remains upon ensuring the setting is absent:

1. We created two files (/tmp/test.ini, /tmp/test_remove_setting.pp) as shown below, in which we aimed to remove setting1 and the [section1] header:

# cat /tmp/test.ini
[section1]
setting1 = value1

[section2]
setting2 = value2

# cat /tmp/test_remove_setting.pp
ini_setting { 'remove setting1':
  ensure  => 'absent',
  path    => '/tmp/test.ini',
  section => 'section1',
  setting => 'setting1',
}

2. Applied Puppet:

# puppet apply /tmp/test_remove_setting.pp
Notice: Compiled catalog for <redacted> in environment production in 0.09 seconds
Notice: /Stage[main]/Main/Ini_setting[remove setting1]/ensure: removed
Notice: Applied catalog in 0.69 seconds

3. Observe that while setting1 was removed, the [section1] header still persisted:

# cat /tmp/test.ini
[section1]

[section2]
setting2 = value2

However, when removing the newline after setting1, both the setting AND section header are removed correctly:

4. Modified test.ini to not include a newline after the first setting:

# cat /tmp/test.ini
[section1]
setting1 = value1
[section2]
setting2 = value2

5. Applied Puppet:

# puppet apply /tmp/test_remove_setting.pp
Notice: Compiled catalog for <redacted> in environment production in 0.04 seconds
Notice: /Stage[main]/Main/Ini_setting[remove setting1]/ensure: removed
Notice: Applied catalog in 0.28 seconds

6. Observe that both setting1 and the [section1] header are removed as expected:

# cat /tmp/test.ini
[section2]
setting2 = value2

Environment

• Version: 7.14.0
• Platform: Ubuntu 20.04.1

Additional Context

We also stepped through the puppetlabs-inifile code with pry to observe the IniFile::Section object in the reproduced problem (steps 1-3 above). Initially, we saw that section1 consisted of @start_line=0 and @end_line=2.

[4] pry(#<Puppet::Util::IniFile>)> section
=> #<Puppet::Util::IniFile::Section:<redacted> @additional_settings={}, @end_line=2, @existing_settings={"setting1"=>"value1"}, @indentation=0, @name="section1", @start_line=0>

The start and end lines correspond to the lines with the [section1] header and the newline before the [section2] header, respectively, in the test.ini file:

[5] pry(#<Puppet::Util::IniFile>)> @lines
=> ["[section1]\n", "setting1 = value1\n", "\n", "[section2]\n", "setting2 = value2\n", "\n"]

After removing setting1, we observed in remove_setting() that the section was not registered as empty.

[11] pry(#<Puppet::Util::IniFile>)> next

From: /opt/puppetlabs/puppet/cache/lib/puppet/util/ini_file.rb:137 Puppet::Util::IniFile#remove_setting:

    120: def remove_setting(section_name, setting)
    121:   section = @sections_hash[section_name]
    122:   return unless section.existing_setting?(setting)
    123:   # If the setting is found, we have some work to do.
    124:   # First, we remove the line from our array of lines:
    125:   remove_line(section, setting)
    126:
    127:   # Then, we need to tell the setting object to remove
    128:   # the setting from its state:
    129:   section.remove_existing_setting(setting)
    130:
    131:   # Finally, we need to update all of the start/end line
    132:   # numbers for all of the sections *after* the one that
    133:   # was modified.
    134:   section_index = @section_names.index(section_name)
    135:   decrement_section_line_numbers(section_index + 1)
    136:
 => 137:   return unless section.empty?
    138:   # By convention, it's time to remove this newly emptied out section
    139:   lines.delete_at(section.start_line)
    140:   decrement_section_line_numbers(section_index + 1)
    141:   @section_names.delete_at(section_index)
    142:   @sections_hash.delete(section.name)
    143: end

[12] pry(#<Puppet::Util::IniFile>)> section.empty?
=> false

However, looking at the final state of the Puppet::Util::IniFile::Section object, we saw that section1 now had @start_line=0 and @end_line=1.

[11] pry(#<Puppet::Util::IniFile>)> section
=> #<Puppet::Util::IniFile::Section:<redacted> @additional_settings={}, @end_line=1, @existing_settings={}, @indentation=0, @name="section1", @start_line=0>

[13] pry(#<Puppet::Util::IniFile>)> @lines
=> ["[section1]\n", "\n", "[section2]\n", "setting2 = value2\n", "\n"]

Furthermore, in the section.rb code here, the section.empty? function returns true if the section's start_line == end_line. Thus, this shows that sections containing whitespace are not getting removed correctly, as the code counts the whitespace in the start and end lines to determine if the section is empty.

detect leading whitespace in section

If every setting in a section has a certain amount of leading whitespace, we should be able to detect that and then use that same indentation for any settings that we write out. This shouldn't have any sort of impact on functionality but it will make the end-user experience nicer.

Add tests for key-val-separator in ini_file_spec

Because there aren't any yet.

The 1.0.1 tarball on the forge is dirty

The 1.0.1 tarball downloadable from the puppet forge contains the files:

lib/puppet/provider/ini_setting/.ruby.rb.swp
lib/puppet/provider/ini_subsetting/.ruby.rb.swp
lib/puppet/type/.ini_setting.rb.swp
lib/puppet/type/.ini_subsetting.rb.swp
lib/puppet/util/.setting_value.rb.swp
spec/acceptance/.ini_setting_spec.rb.swp
spec/acceptance/.ini_subsetting_spec.rb.swp

Please look at using something like

git archive --prefix=puppetlabs-inifile-$version --format=tar \
  --output=puppetlabs-inifile-$version HEAD

…to build packages. That way, you don't get a dirty tarball when the working directory is not clean.

Puppet::Util is not properly defined before use in tests (possibly elsewhere)

Describe the Bug

In a MayTheSourceBeWithYou rubocop clean up I attempted to clean Style/ClassAndModuleChildren on this repository, and found that for puppet modules, the rubocop is configured for compact, but if you do class Puppet::Util::IniFile instead of module Puppet:Util\n class IniFile tests fail with a NameError uninitialized constant Puppet::Util::IniFile to which @binford2k suggested I make a ticket because "Maybe raise a ticket for someone to investigate because basically what this means is that this is being loaded before Puppet's fully initialized and that seems potentially problematic too."

Expected Behavior

I expected to have tests run successfully

What I got

pdk (INFO): Using Ruby 2.7.7
pdk (INFO): Using Puppet 7.23.0
[✔] Preparing to run the unit tests.
/opt/puppetlabs/pdk/private/ruby/2.7.7/bin/ruby -I/home/jstraw/.pdk/cache/ruby/2.7.0/gems/rspec-core-3.12.2/lib:/opt/puppetlabs/pdk/share/cache/ruby/2.7.0/gems/rspec-support-3.12.0/lib /home/jstraw/.pdk/cache/ruby/2.7.0/gems/rspec-core-3.12.2/exe/rspec --pattern spec/\{aliases,classes,defines,functions,hosts,integration,plans,tasks,type_aliases,types,unit\}/\*\*/\*_spec.rb --format progress

An error occurred while loading ./spec/unit/puppet/provider/ini_setting/inheritance_spec.rb.
Failure/Error: class Puppet::Util::IniFile::Section

Puppet::Error:
  Could not autoload puppet/type/inherit_ini_setting: Could not autoload puppet/provider/inherit_ini_setting/ini_setting: Could not autoload puppet/type/ini_setting: Could not autoload puppet/provider/ini_setting/ruby: uninitialized constant Puppet::Util::IniFile
# ./lib/puppet/util/ini_file/section.rb:6:in `<top (required)>'
# ./lib/puppet/util/ini_file.rb:4:in `<top (required)>'
# ./lib/puppet/provider/ini_setting/ruby.rb:3:in `<top (required)>'
# ./lib/puppet/type/ini_setting.rb:6:in `<top (required)>'
# ./spec/fixtures/inherit_ini_setting/lib/puppet/provider/inherit_ini_setting/ini_setting.rb:3:in `<top (required)>'
# ./spec/fixtures/inherit_ini_setting/lib/puppet/type/inherit_ini_setting.rb:1:in `<top (required)>'
# ./spec/unit/puppet/provider/ini_setting/inheritance_spec.rb:9:in `<top (required)>'
# ------------------
# --- Caused by: ---
# NameError:
#   uninitialized constant Puppet::Util::IniFile
#   ./lib/puppet/util/ini_file/section.rb:6:in `<top (required)>'

An error occurred while loading ./spec/unit/puppet/provider/ini_setting/ruby_spec.rb.
Failure/Error: class Puppet::Util::IniFile::Section

Puppet::Error:
  Could not autoload puppet/provider/ini_setting/ruby: uninitialized constant Puppet::Util::IniFile
# ./lib/puppet/util/ini_file/section.rb:6:in `<top (required)>'
# ./lib/puppet/util/ini_file.rb:4:in `<top (required)>'
# ./lib/puppet/provider/ini_setting/ruby.rb:3:in `<top (required)>'
# ./spec/unit/puppet/provider/ini_setting/ruby_spec.rb:6:in `<top (required)>'
# ------------------
# --- Caused by: ---
# NameError:
#   uninitialized constant Puppet::Util::IniFile
#   ./lib/puppet/util/ini_file/section.rb:6:in `<top (required)>'

An error occurred while loading ./spec/unit/puppet/provider/ini_subsetting/ruby_spec.rb.
Failure/Error: class Puppet::Util::IniFile::Section

Puppet::Error:
  Could not autoload puppet/type/ini_subsetting: Could not autoload puppet/provider/ini_subsetting/ruby: uninitialized constant Puppet::Util::IniFile
# ./lib/puppet/util/ini_file/section.rb:6:in `<top (required)>'
# ./lib/puppet/util/ini_file.rb:4:in `<top (required)>'
# ./lib/puppet/provider/ini_subsetting/ruby.rb:3:in `<top (required)>'
# ./lib/puppet/type/ini_subsetting.rb:5:in `<top (required)>'
# ./spec/unit/puppet/provider/ini_subsetting/ruby_spec.rb:6:in `<top (required)>'
# ------------------
# --- Caused by: ---
# NameError:
#   uninitialized constant Puppet::Util::IniFile
#   ./lib/puppet/util/ini_file/section.rb:6:in `<top (required)>'

An error occurred while loading ./spec/unit/puppet/util/ini_file_spec.rb.
Failure/Error: class Puppet::Util::IniFile::Section

NameError:
  uninitialized constant Puppet::Util::IniFile
# ./lib/puppet/util/ini_file/section.rb:6:in `<top (required)>'
# ./lib/puppet/util/ini_file.rb:4:in `<top (required)>'
# ./spec/unit/puppet/util/ini_file_spec.rb:5:in `<top (required)>'```


## Steps to Reproduce
Steps to reproduce the behavior:
1. Remove the disable of the rubocop for Style/ClassAndModuleChildren
2. Update the 4 classes in question using either autocorrect or manually (using concise rather then nested)
3. run pdk validate and find that the rubocop is no longer failing
4. run pdk test unit and get the errors above

## Environment
 - PDK 2.7.1
 - (Module on 2.7.0)
 - Debian Testing