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

Refactor #15

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Refactor #15

wants to merge 2 commits into from

Conversation

ghoneycutt
Copy link
Member

No description provided.

@@ -1,2 +1,4 @@
Style/TrailingCommaInLiteral:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened voxpupuli/voxpupuli-test#31 as I think that's where this file is now managed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is merged, though not sure about the release process for that gem. Anyhow, this should probably stay in the commit as it will just get overwritten in the next sync and keep doing the same thing.

Copy link

@igalic igalic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙋🏻‍♀️

manifests/agent.pp Outdated Show resolved Hide resolved
if $manage_yarn {
yumrepo { 'yarn':
ensure => 'present',
baseurl => 'https://dl.yarnpkg.com/rpm/',
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how is this supposed to work for non-rpm systems?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The module only supports EL7

Comment on lines 20 to 27
is_expected.to contain_file('/opt/hyperglass').with(
{
'ensure' => 'directory',
'owner' => 'root',
'group' => 'root',
'mode' => '0755',
}
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I generally like chaining more. It's compacter and also works nicely if you add other lines like .that_requires()

Suggested change
is_expected.to contain_file('/opt/hyperglass').with(
{
'ensure' => 'directory',
'owner' => 'root',
'group' => 'root',
'mode' => '0755',
}
)
is_expected.to contain_file('/opt/hyperglass').
with_ensure('directory').
with_owner('root').
with_group('root').
with_mode('0755')

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree, mostly because I can copy/paste from the actual code and write the tests faster. I did leave the .with_this and .with_that for lines that were not too long.

@bastelfreak
Copy link
Member

I'm not a big fan of throwing most of the resources into a single class. From the official style guide:

Split your module into public and private classes and defined types where possible. Public classes or defined types should contain the parts of the module meant to be configured or customized by the user, while private classes should contain things you do not expect the user to change via parameters. Separating into public and private classes or defined types helps build reusable and readable code.

'owner' => 'hyperglass-agent',
'group' => 'hyperglass-agent',
'mode' => '0700',
'notify' => 'Systemd::Unit_file[hyperglass-agent.service]',
Copy link
Member

@alexjfisher alexjfisher Sep 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to use the relationship matchers. https://github.com/rodjek/rspec-puppet#relationship-matchers

The tests will continue to work if the way the relationships are defined are ever refactored.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a great idea!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Used those where the .with_ and .that_ were chained. Kept this as is because it makes it harder to read to use multiple formats for the same it block.

@ghoneycutt
Copy link
Member Author

I'm not a big fan of throwing most of the resources into a single class. From the official style guide:

Split your module into public and private classes and defined types where possible. Public classes or defined types should contain the parts of the module meant to be configured or customized by the user, while private classes should contain things you do not expect the user to change via parameters. Separating into public and private classes or defined types helps build reusable and readable code.

A bunch of private classes just make the code hard to use and understand. I'm emphatically against it on so many levels. Hopefully given all the extra functionality and completeness of the spec tests, the value here is greater than these ideas about splitting code into a bunch of different files.

manifests/server.pp Outdated Show resolved Hide resolved
* Add complete spec test coverage
* Default values for hyperglass::server no longer contain bogus devices
* Simplify the classes
* Make managing users and groups optional
* Make each of the service dependencies for the server optional
@ghoneycutt
Copy link
Member Author

Anything else to get this merged?

Copy link
Member

@bastelfreak bastelfreak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don't think that it's a good idea to not follow the official style guide and recommendations from Puppet. If we do not agree with them anymore they should be changed instead of being ignored. If others think this is a good approach they shall merge it.

@ghoneycutt
Copy link
Member Author

That section of the README is not very prescriptive at all. It does not say you need to scatter your resources across multiple private and public classes. I'm not opposed to doing that and do in the partner module for Sensu (https://github.com/sensu/sensu-puppet). This module is too simple to need all that and if it did, it would not be on ::config, ::install, and ::service lines.

From the docs on classes

https://puppet.com/docs/puppet/6.18/lang_classes.html

Classes generally configure large or medium-sized chunks of functionality, such as all of the packages, configuration files, and services needed to run an application.

@vox-pupuli-tasks
Copy link

Dear @ghoneycutt, thanks for the PR!

This is Vox Pupuli Tasks, 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants