-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Finishing touches for multi-instance support #343
Conversation
@fraenki Great work! Could you please add some acceptance tests that show this is working with multiple instances? That would make this easy to merge and greatly help ensure that the functionality remains in tact. |
@ghoneycutt Sure, I'll add some acceptance tests :) |
@ghoneycutt So I took a look at the acceptance tests and the existing tests (this) already have good coverage for multi instance support and they ran successfully for this PR. Is there anything else I should add? |
@ghoneycutt I've addressed all issues:
|
This comment has been minimized.
This comment has been minimized.
3 similar comments
Dear @fraenki, thanks for the PR! This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase? You can find my sourcecode at voxpupuli/vox-pupuli-tasks |
This comment has been minimized.
This comment has been minimized.
Dear @fraenki, thanks for the PR! This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase? You can find my sourcecode at voxpupuli/vox-pupuli-tasks |
spec/acceptance/suites/default/redis_multi_instances_one_host_spec.rb
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a related note, I'm sure you've noticed that more recent Debian (Buster) and Ubuntu (Bionic) versions have started to ship the redis(-server)@
service. I'd like to use those since they also contain various security hardening features. Not a blocker to this, but have you had a look at this and what are your thoughts?
Not at all, actually I'm not doing anything with Debian or Ubuntu. |
Absolutely. However, I do wonder if we could deploy a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small last nitpicks, but this is shaping up to be a good PR.
service_ensure => 'running', | ||
port => $port, | ||
bind => $facts['networking']['ip'], | ||
dbfilename => "${port}-dump.rdb", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes me wonder if we should have some code in instance.pp
that does this and appendfilename so they're unique. Defaulting to the same file for multiple instances sounds like a bad idea. We can pass the default in config.pp
as we do for other *file
parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I agree, I think having $port
as the one and only unique identifier for Redis instances is sufficient. Adding $bind
to the mix by introducing it as unique identifier could make things pretty complicated. I think this would only add choice (which is usually a good thing), but without real benefits.
I took a look at this. It sure is an improvement. I took note and will implement it in a follow-up PR, because this one is already too big and I don't want to see all checks break again. :) (The follow-up PR would also be a good opportunity to convert the service template to EPP, as suggested by @bastelfreak.) Now that all checks are working... is this ready for merge? :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Trivial nit, but feel free to leave that. I'll also give other reviewers that were involved time for a last look (@bastelfreak, @ghoneycutt).
# Only necessary for Puppet < 6.1.0, | ||
# See https://github.com/puppetlabs/puppet/commit/f8d5c60ddb130c6429ff12736bfdb4ae669a9fd4 | ||
if Puppet.version < '6.1' | ||
is_expected.to contain_augeas('Systemd redis ulimit'). | ||
with_incl("/etc/systemd/system/#{service_name}.service.d/limit.conf"). | ||
with_lens('Systemd.lns'). | ||
with_changes(['defnode nofile Service/LimitNOFILE ""', 'set $nofile/value "7777"']). | ||
that_notifies('Class[systemd::systemctl::daemon_reload]') | ||
else | ||
is_expected.to contain_augeas('Systemd redis ulimit'). | ||
with_incl("/etc/systemd/system/#{service_name}.service.d/limit.conf"). | ||
with_lens('Systemd.lns'). | ||
with_changes(['defnode nofile Service/LimitNOFILE ""', 'set $nofile/value "7777"']) | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternative with less duplication
is_expected.to contain_augeas('Systemd redis ulimit').
with_incl("/etc/systemd/system/#{service_name}.service.d/limit.conf").
with_lens('Systemd.lns').
with_changes(['defnode nofile Service/LimitNOFILE ""', 'set $nofile/value "7777"'])
# Only necessary for Puppet < 6.1.0,
# See https://github.com/puppetlabs/puppet/commit/f8d5c60ddb130c6429ff12736bfdb4ae669a9fd4
if Puppet.version < '6.1'
is_expected.to contain_augeas('Systemd redis ulimit').
that_notifies('Class[systemd::systemctl::daemon_reload]')
You can probably even add an else with not_to
Finishing touches for multi-instance support
Pull Request (PR) description
This is essentially a stripped-down re-submission of #230. The original author of #230 seems to have abandoned his efforts (the repository is gone).
This PR contains the following enhancements:
Exec
to reload systemdHowever, this re-submission does not include the
redis-shutdown.erb
template that was present in the original PR, because some users noted that this is not required. I can confirm this from my own testing.Tested on CentOS 7.7 with Puppet 6.11 and Redis 5.
FWIW, this is the dependency cycle that may occur without the proposed modifications when using multiple instances:
This Pull Request (PR) fixes the following issues
n/a