Not replacing issue references are closed issues won't be moved.

Signed-off-by: Balasankar "Balu" C <balasankar@gitlab.com>

When the Consul service is disabled, Omnibus will delete the Consul service so Prometheus will no long try to discover it and collect metrics.

When Consul is enabled on a given node, Omnibus will register each
enabled exporter as a service in Consul. Then, when Consul is enabled on
the Prometheus server, Prometheus will be configured to pull job
configuration from Consul.

Next release is 12.0, so we can now delete the code that cleans up the
old env directories.

The changes were originally made in
1b6b1790 and in
d091e077 there was indicated these
needed to be deleted in 12.0.

Closes https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4268

Takuya Noguchi authored 5 years ago and Ian Baum committed 5 years ago

Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

Move env directory of all services to /opt/gitlab/etc/<service>/env

Gitaly actually handles the `env` node differently, as noted in it's attributes file.
Due to this, move the setting from the attributes to the enable recipe.

The missing PYTHONPATH means the gitaly-ruby process can't render
non-Markdown Wiki pages.

Closes #3678

Change ownership to root:git and permissions to 0640

Closes #3347

* Upgrades from chef 12.21.31 to 13.6.4, including dependent gems
* Updates chefspec to 7.1.1
* Fixes usage of node.default.gitaly in gitaly recipe
* Fixes logging configuration under chef 13
* Updates CHANGELOG
* Multiple rspec fixes
** Changes uses of `old_run_action` to a more compatible call
** More complete Kernel.load mocking
** Globally mocks `#freeze` on helper instances
** Reset the Gitlab singleton in global `before`
** Fixes bad cache interactions in `services_spec`
** Remove pending from Chef 13 dependent example

= Chef 13.6.4

  $EDITOR Gemfile # pin Chef to 13.6.4
  bundle upgrade chef
  git add --patch Gemfile Gemfile.lock
  $EDITOR config/software/*.rb # reflect changes in Gemfile.lock
  git add config/software

13.6.4 is the most-recent-but-one release in the `stable` series of chef
releases. https://downloads.chef.io/chef/stable

We had tried with the latest `stable` release of chef 13, 13.7.16, but
hit issues with the defaulting of array properties:

https://github.com/chef/chef/issues/6784
https://github.com/chef/chef/issues/6792

Care should be taken to upgrade over 13.7.16 to the next stable release,
though we do have examples that will fail if these bugs are not fixed.

= Chefspec 7.1.1

It's necessary to upgrade to chefspec >= 7 to support chef 13.  We take
the opportunity to go to 7.1.1 which is the latest stable version.  7.1
auto-generates matchers, so we are able to remove
`spec/support/matchers.rb` and `package/libraries/matchers.rb`

== Fixes usage of node.default.gitaly in gitaly recipe

Chef 13 no longer auto-generates accessors on the `attributes` Mashes,
and instead expects you to access them using the `#[]=` method.

We had one use in the gitaly recipe, which has been corrected to follow
common style.

= Be more explicit about the run mode for chef-client

The run-mode of the chef-client was not configured explcitly, and
instead relies on `interval` not being specified to mean 'run once and
exit', rather than using the `once` configuration option.

Additionally, when specifying `once` it also makes sense to specify
`client_fork false` as it avoids a needless fork.

= Fixes logging configuration under chef 13

Due to some refactorings in the development of chef 13, it is no longer
possible to have just a logfile and logging formatter configured
*without* an additional STDOUT logger.

This issue has been raised upstream as
https://github.com/chef/chef/issues/6889 in the interim we monkey-patch
the application class to surpess the creation of the STDOUT logger.

= rspec fixups

== Fix uses of `ruby_block('example').old_run_action(:run)`

We were using the (internal to chefspec) `old_run_action` method to test
the behaviour of the wrapped ruby blocks in `ruby_block` resources.

Due to internal refactorings in chefspec 7.1 `old_run_action` is no
longer available to us.

Here we change uses of the `ruby_block('example').old_run_action(:run)`
pattern to the more compatible `ruby_block('example').block.call`.

== More complete Kernel.load mocking

Chef 13 freezes modules as it loads them.  This prevents accidental
redefinition of the methods, but was initially clashing with itself as
during a chefspec run the cookbook compiler was attempting to load all
libraries after we had already loaded them in the chef_helper for ease
of mocking.

We extended our existing mocking of Kernel.load to be consistent with
the loads of libraries from cookbooks other than the gitlab one.

== Globally mocks `#freeze` on helper instances

Related to the changes to mocking Kernel.load, once this was implemented
we are bitten by default values in LWRPs being frozen in the attribute
validator.  In order to keep on being able to mock all instances of
`PgHelper` and related classes we add a mock of `#freeze` to several
helper classes.

== Reset the Gitlab singleton in global `before`

The Gitlab global object was carrying state from one example group to
another, this was causing subtle issues when running example groups that
mutated the global Gitlab configuration in incompatible ways.

Here we save the empty state of the Gitlab configuration singleton at
the start of the test run, and then reset back to that state in the
global `before`.

== Fixes bad `cached` interaction in `services_spec`

As a knock-on effect of resetting the Gitlab singleton for every
example, we hit problems with how the `services_spec` was making use of
the `cached` rspec helper.

== Remove pending from Chef 13 dependent example

An example that had initially raised awareness of the need for a chef13
upgrade started working.  As this was a pending rspec example this made
the tests fail.  Here we remove the pending qualifier.

This reverts commit eb78019b2ec79babb24160fc379221fba33e5cf4.

And better comment the environment settings for gitaly

The package does not include the executable itself at this time.

We intend to initially ship it seperatly, to allow it to iterate
in production on a seperate schedule from GitLab, at least initially.

But if you have the executable installed, and you enable the service,
It should now be run using RunIt and available during gitlab-ctl status/up/down/restart

This allows configuring the settings that were added in: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/922

Fixes issue https://gitlab.com/gitlab-org/omnibus-gitlab/issues/508

This also makes sure TERM gets sent to the process group of the
wrapper script, not just the wrapper itself. That will take down
'sleep' processes.

Repo
https://github.com/opscode/omnibus-chef-server.git
Path
config/software/chef-server-cookbooks.rb
Revision
6a11fd840045a7ae7961e5a37439371b7407f3e9