Skip to content
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

Merged
merged 1 commit into from
Feb 18, 2020
Merged

Finishing touches for multi-instance support #343

merged 1 commit into from
Feb 18, 2020

Conversation

fraenki
Copy link
Member

@fraenki fraenki commented Jan 21, 2020

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:

  • Add an example for multiple instances to the README
  • Fix a dependency cycle by using camptocamp/systemd instead of Exec to reload systemd
  • Updates to the systemd template
  • Update tests accordingly

However, 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:

Error: Found 1 dependency cycle:
(Exec[systemd-reload-redis] => Class[Redis] => Redis::Instance[6379] => File[/etc/systemd/system/redis-server-6379.service] => Exec[systemd-reload-redis])

This Pull Request (PR) fixes the following issues

n/a

@ghoneycutt
Copy link
Member

@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.

@fraenki
Copy link
Member Author

fraenki commented Jan 23, 2020

@ghoneycutt Sure, I'll add some acceptance tests :)

@fraenki
Copy link
Member Author

fraenki commented Jan 28, 2020

@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?

README.md Show resolved Hide resolved
.fixtures.yml Outdated Show resolved Hide resolved
manifests/instance.pp Outdated Show resolved Hide resolved
README.md Show resolved Hide resolved
templates/service_templates/redis.service.erb Outdated Show resolved Hide resolved
@bastelfreak bastelfreak added enhancement New feature or request needs-work not ready to merge just yet labels Jan 30, 2020
@fraenki
Copy link
Member Author

fraenki commented Feb 9, 2020

@ghoneycutt I've addressed all issues:

  • Update acceptance tests to use new example code from README
  • Re-enable multi-instance acceptance tests on Debian (because they are working fine)
  • Add spec test for systemd service file
  • Add condition to reload systemd only on Puppet < 6.1.0
  • Rebase against current master

@bastelfreak bastelfreak removed the needs-work not ready to merge just yet label Feb 9, 2020
@vox-pupuli-tasks

This comment has been minimized.

3 similar comments
@vox-pupuli-tasks
Copy link

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

@vox-pupuli-tasks

This comment has been minimized.

@vox-pupuli-tasks
Copy link

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

Copy link
Member

@ekohl ekohl left a 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?

spec/classes/redis_spec.rb Show resolved Hide resolved
manifests/ulimit.pp Outdated Show resolved Hide resolved
@fraenki
Copy link
Member Author

fraenki commented Feb 18, 2020

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.
So I'd prefer if this could be integrated with another PR. :)

@ekohl
Copy link
Member

ekohl commented Feb 18, 2020

Not at all, actually I'm not doing anything with Debian or Ubuntu.
So I'd prefer if this could be integrated with another PR. :)

Absolutely. However, I do wonder if we could deploy a redis(-server)@ unit file on platforms that are missing it and utilize that. Since you're not a Debian/Ubuntu user, how would you feel about that?

Copy link
Member

@ekohl ekohl left a 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.

manifests/ulimit.pp Outdated Show resolved Hide resolved
metadata.json Outdated Show resolved Hide resolved
service_ensure => 'running',
port => $port,
bind => $facts['networking']['ip'],
dbfilename => "${port}-dump.rdb",
Copy link
Member

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.

Copy link
Member Author

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.

.fixtures.yml Show resolved Hide resolved
@fraenki
Copy link
Member Author

fraenki commented Feb 18, 2020

Absolutely. However, I do wonder if we could deploy a redis(-server)@ unit file on platforms that are missing it and utilize that. Since you're not a Debian/Ubuntu user, how would you feel about that?

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? :)

spec/classes/redis_spec.rb Outdated Show resolved Hide resolved
Copy link
Member

@ekohl ekohl left a 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).

Comment on lines +120 to +133
# 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
Copy link
Member

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

@ghoneycutt ghoneycutt merged commit ef7c4e6 into voxpupuli:master Feb 18, 2020
@ekohl ekohl linked an issue May 11, 2020 that may be closed by this pull request
cegeka-jenkins pushed a commit to cegeka/puppet-redis that referenced this pull request Feb 16, 2021
Finishing touches for multi-instance support
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Type forking causes service timeout
4 participants