search

sous-chefs / sql_server

Development repository for the sql_server cookbook
https://supermarket.chef.io/cookbooks/sql_server
Apache License 2.0
63 stars 124 forks source link

add tempdb extra parameters #165

Closed JHBoricua closed 3 years ago

JHBoricua commented 3 years ago

Signed-off-by: Jose Hernandez jhboricua@gmail.com

Description

Issues Resolved

The current version of the cookbook allows to customize the location of the TempDB files but not their composition. Starting with SQL 2016 we have the ability to customize the number of TempDB data files and the size | autogrowth settings for them during installation. This allows for defining more sane settings for this crucial component of SQL, as the default values are often inadequate.

Check List

the-label-bot[bot] commented 3 years ago

Kind Prediction: docs Confidence: 0.285

Provide the bot with feedback using a :thumbsup: or :thumbsdown:!

the-label-bot[bot] commented 3 years ago

Size Prediction: small Confidence: 0.999

Nice! This should be quick to review

Provide the bot with feedback using a :thumbsup: or :thumbsdown:!

the-label-bot[bot] commented 3 years ago

Size Prediction: medium Confidence: 0.999

Nice! This should be quick to review

Provide the bot with feedback using a :thumbsup: or :thumbsdown:!

JHBoricua commented 3 years ago

Looks like your tests are running into the same issue mine were. The error is:

Chef::Exceptions::DeprecatedFeatureError
       ----------------------------------------
       Deprecation CHEF-33 from C:/Users/vagrant/AppData/Local/Temp/kitchen/cache/cookbooks/windows/resources/certificate_binding.rb

         The  resource in the windows cookbook should declare `unified_mode true`

       Please see https://docs.chef.io/deprecations_unified_mode/ for further details and information on how to correct this problem. (raising error due to treat_deprecation_warnings_as_errors being set)

The link being referenced throws a 404, of course. The only thing I could find on chef deprecations was at https://docs.chef.io/chef_deprecations_client/ but there's no CHEF-33 listed in there. I was able to test successfully by flipping the setting 'deprecations_as_errors' to false in the kitchen.yml file.

It looks like this is an issue with the windows cookbook that the sql_server cookbook depends on. Hopefully it is resolved soon.

JHBoricua commented 3 years ago

This PR is blocked until #168 is merged, as it resolves the issues with the ci jobs and removes the dependency with the now abandoned windows cookbook.

JHBoricua commented 3 years ago

@ramereth Now that the CI jobs are fixed, I've merged the changes in this branch and updated the changelog. Please review at your convenience.

JHBoricua commented 3 years ago

Looks like the CI jobs are failing with a http code 429 (too many requests?) error when trying to download the vagrant images. Might be a rate-limiting feature on the Vagrant site hosting the images.

JHBoricua commented 3 years ago

Can one of the maintainers kick off the CI jobs again to see if the issue with the download of the vagrant windows images happens again? Maybe it was a transient issue with the vagrant website.

majormoses commented 3 years ago

@JHBoricua I have kicked the tests, if you ever need to test without waiting for a maintainer you can create an empty commit to trigger CI git commit --allow-empty -m "trigger CI"

JHBoricua commented 3 years ago

@majormoses Didn't know that. I'll keep it in mind for next time. Thanks.

JHBoricua commented 3 years ago

Ok, CI jobs are failing again with the same error (429) when attempting to download the vagrant image. Per Vagrant's Cloud API page, we are being rate-limited. What's unclear to me is, if one of the successful CI jobs already downloaded the image for say, windows-2019, why are the other CI jobs using the same platform attempting to download the image again instead of using the one that's already downloaded?

detjensrobert commented 3 years ago

Due to the way our GH Actions are configured all the tests run in separate runners and don't share a cache.

JHBoricua commented 3 years ago

Due to the way our GH Actions are configured all the tests run in separate runners and don't share a cache.

That makes sense. Is there a way to control how many of the integrations are launched at once to slow down the image requests and not trigger the rate limit?

ramereth commented 3 years ago

@JHBoricua I'm going to try and do some manual tests on my end so we can get this merged.

kitchen-porter commented 3 years ago

Released as: 7.1.0