Skip to content
Snippets Groups Projects
  • Richard Clamp's avatar
    d2d2df0ecc7d
    Update to Chef 12.21.31 · d2d2df0ecc7d
    Richard Clamp authored
    * Updates the Gemfile.lock used by `bundle` CI tasks and rspec
    * Updates the software definitions to match Gemfile.lock
    * Tweaks Ohai Logging to supress noise in the rspec run
    * Fix deprecations in `account` and `templatesymlink` LWRPs
    
    = Gemfile and software definitions
    
    Initially generated by
    
        $ bundle upgrade chef
    
        $ git add --patch Gemfile.lock
    
    Reflecting pinning changes from Gemfile.lock into the software
    definitions.
    
        $ git add config/software
    
    This let us rely on bundler doing the hard work of solving for transient
    dependencies, but also allowed us to keep the versions of chef used for
    rspec testing aligned with the versions of components we add to the
    packages.
    
    = Ohai Logging
    
    With the update to ohai 8.26.1 we started to see an additional logging
    line during test startup:
    
      $ bundle exec rspec spec/chef/recipes/unicorn_spec.rb
      [2018-02-13T09:27:01+00:00] INFO: The plugin path /etc/chef/ohai/plugins does not exist. Skipping...
      Platform mac_os_x 10.13.3 not supported. Falling back to ubuntu 14.04
    
    Here we configure the loglevel of Ohai down to error before we call it
    to find our current platform, to tidy up the test output.
    
    = `account` LWRP's use of user type
    
    In Chef 12.14 the supports property of the user type was deprecated, to
    be removed in Chef 13.  Here we avoid this deprecation by changing our
    single use of the accounts LWRP to take/pass a manage_home property,
    rather than the previous `user_supports manage_home: false` property.
    
    https://docs.chef.io/deprecations_supports_property.html
    
    = `templatesymlink` LWRP property deprecations
    
    In moving to Chef 12.21.31 we are alerted of deprecations that will
    become fatal errors in moving to Chef 13.
    
    For `templatesymlink` they were both of the class of shadowing
    properties, as `sensitive` and `notifies` are both defined as methods in
    Chef::Resource which is an eventual parent class of the LWRPs.
    
    Fixing `sensitive` was simple, as the parent property behaves like a
    simple setter, so we can remove our and simply make use of the inherited
    behaviour from the baseclass, and just call `new_resource.sensitive`.
    
    https://github.com/chef/chef/blob/v12.21.33/lib/chef/resource.rb#L456-L466
    
    `notifies` was a little more complex.  Instead of attempting to supply
    this property, we instead use `new_resource.updated_by_last_action` if
    the wrapped templates :create action reported an update via
    `#updated_by_last_action?`
    
    This moves the thing that generates the notification from the wrapped
    template to the instance of `templatesymlink`, so some tests needed to
    be updated.
    
    This has also been manually tested by editing
    /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml and then
    observing that the reconfigure ran 'execute[clear the gitlab-rails cache]'
    d2d2df0ecc7d
    History
    Update to Chef 12.21.31
    Richard Clamp authored
    * Updates the Gemfile.lock used by `bundle` CI tasks and rspec
    * Updates the software definitions to match Gemfile.lock
    * Tweaks Ohai Logging to supress noise in the rspec run
    * Fix deprecations in `account` and `templatesymlink` LWRPs
    
    = Gemfile and software definitions
    
    Initially generated by
    
        $ bundle upgrade chef
    
        $ git add --patch Gemfile.lock
    
    Reflecting pinning changes from Gemfile.lock into the software
    definitions.
    
        $ git add config/software
    
    This let us rely on bundler doing the hard work of solving for transient
    dependencies, but also allowed us to keep the versions of chef used for
    rspec testing aligned with the versions of components we add to the
    packages.
    
    = Ohai Logging
    
    With the update to ohai 8.26.1 we started to see an additional logging
    line during test startup:
    
      $ bundle exec rspec spec/chef/recipes/unicorn_spec.rb
      [2018-02-13T09:27:01+00:00] INFO: The plugin path /etc/chef/ohai/plugins does not exist. Skipping...
      Platform mac_os_x 10.13.3 not supported. Falling back to ubuntu 14.04
    
    Here we configure the loglevel of Ohai down to error before we call it
    to find our current platform, to tidy up the test output.
    
    = `account` LWRP's use of user type
    
    In Chef 12.14 the supports property of the user type was deprecated, to
    be removed in Chef 13.  Here we avoid this deprecation by changing our
    single use of the accounts LWRP to take/pass a manage_home property,
    rather than the previous `user_supports manage_home: false` property.
    
    https://docs.chef.io/deprecations_supports_property.html
    
    = `templatesymlink` LWRP property deprecations
    
    In moving to Chef 12.21.31 we are alerted of deprecations that will
    become fatal errors in moving to Chef 13.
    
    For `templatesymlink` they were both of the class of shadowing
    properties, as `sensitive` and `notifies` are both defined as methods in
    Chef::Resource which is an eventual parent class of the LWRPs.
    
    Fixing `sensitive` was simple, as the parent property behaves like a
    simple setter, so we can remove our and simply make use of the inherited
    behaviour from the baseclass, and just call `new_resource.sensitive`.
    
    https://github.com/chef/chef/blob/v12.21.33/lib/chef/resource.rb#L456-L466
    
    `notifies` was a little more complex.  Instead of attempting to supply
    this property, we instead use `new_resource.updated_by_last_action` if
    the wrapped templates :create action reported an update via
    `#updated_by_last_action?`
    
    This moves the thing that generates the notification from the wrapped
    template to the instance of `templatesymlink`, so some tests needed to
    be updated.
    
    This has also been manually tested by editing
    /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml and then
    observing that the reconfigure ran 'execute[clear the gitlab-rails cache]'