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

tdevelioglu/refurbish #428

Merged
merged 1 commit into from
Jun 27, 2017
Merged

Conversation

@tdevelioglu tdevelioglu force-pushed the tdevelioglu/refurbish branch 4 times, most recently from 8c39172 to 2a297ed Compare January 31, 2017 11:26
@tdevelioglu tdevelioglu force-pushed the tdevelioglu/refurbish branch 2 times, most recently from f1d99b2 to a4ad15d Compare March 3, 2017 16:58
@tdevelioglu
Copy link
Author

I know this is a rather large commit, would you like me to split it up into a number of smaller PR's instead ?

@hunner hunner mentioned this pull request Mar 23, 2017
Copy link
Contributor

@hunner hunner left a comment

Choose a reason for hiding this comment

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

The use of tag instead of path/target was so that concat_fragment resources could define their fragment WITHOUT knowing what the target would be, say in the case of various profiles creating fragments to be picked up elsewhere based on the path chosen by concat_file, or even across exported resources when the exporting hosts do not know where the collecting host will put them.

The other changes are valuable though!

@@ -58,68 +54,98 @@ def exists?
end

newparam(:order) do
desc "Controls the ordering of fragments. Can be set to alphabetical or numeric."
defaultto 'numeric'
desc "Controls the ordering of fragments. Can be set to :alpha or :numeric."
Copy link
Contributor

Choose a reason for hiding this comment

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

Docs should not have :'s for the argument values.

Copy link
Contributor

Choose a reason for hiding this comment

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

Fixed in #433

Copy link
Author

Choose a reason for hiding this comment

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

I see. The intent of my change was to allow the types to be used more easily directly but the tag normalization was making it tricky. By removing the tag and using the path or title as the target my hope was to get around it.

It is very valuable to be able to use the types without the wrappers however. My testing shows a ~10% reduction in total resource count, and ~20% decrease (2.5M -> 2M) in catalog size on one of our concat heavy roles. This adds up real quickly in real-world numbers when you consider an environment of 20-30k hosts which make heavily use of concat, especially on the inventory/puppetdb side of things, since all file content effectively gets duplicated when it gets passed through the wrappers.

Perhaps I can re-factor it to collect on both tag and target, title, how does that sound ?

Copy link
Author

@tdevelioglu tdevelioglu Mar 24, 2017

Choose a reason for hiding this comment

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

I took another look at this and concat_fragment already has to know what the target will be, it can not be declared otherwise, see:

https://github.com/puppetlabs/puppetlabs-concat/blob/master/lib/puppet/type/concat_fragment.rb#L45-L49

Ah, I missed that it only emits a warning but it makes it seem as if the intent is that fragments should target concat_file by path or title.

Copy link
Author

Choose a reason for hiding this comment

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

It does raise the question what the actual purpose of the target parameter is then, because it's not used for anything except emitting that warning.

Copy link
Contributor

@hunner hunner Mar 24, 2017

Choose a reason for hiding this comment

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

I think the target exists for backwards-compatibility reasons. We noticed that the order in the manifest defaults to alpha and that the order in the type defaults to numeric though, so I guess that it wasn't backwards-compatible with the .pp files anyway. Whoops. This is ticketed in MODULES-4600

end

newparam(:replace) do
newparam(:replace, :boolean => true, :parent => Puppet::Parameter::Boolean) do
Copy link
Contributor

Choose a reason for hiding this comment

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

I think if you make this :boolean => true then you don't need the parent?

Copy link
Contributor

Choose a reason for hiding this comment

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

Fixed in #433

Copy link
Author

Choose a reason for hiding this comment

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

:boolean => true just adds a param? method to the type, you still need the parent for value checking and coercion.

end

newparam(:backup) do
desc "Controls the filebucketing behavior of the final file and see File type reference for its use."
defaultto 'puppet'
Copy link
Contributor

Choose a reason for hiding this comment

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

Why the removal of this default? Is that backwards incompatible?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, I see that the defaultto 'puppet' is set in lib/puppet/type/file.rb in puppet's source.

@@ -85,40 +92,56 @@ def exists?
end

# Inherit File parameters
newparam(:selinux_ignore_defaults) do
end
newparam(:selinux_ignore_defaults, :boolean => true, :parent => Puppet::Parameter::Boolean)
Copy link
Contributor

Choose a reason for hiding this comment

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

No parent needed.

Copy link
Contributor

Choose a reason for hiding this comment

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

Well what do you know, apparently it does need a parent. Is this because it's a parameter, and only properties don't need a parent?

Copy link
Author

Choose a reason for hiding this comment

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

Technically no, they're not any different. It's just that setting Puppet::Property::Boolean as a parent of a property breaks the property which is why often you see the same bits copied directly into the property.

Copy link
Contributor

Choose a reason for hiding this comment

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

I removed the parent, then tests failed. It apparently accepted lots of truthy values because of :boolean => true, but didn't sanitize them on the way back. I didn't track down as to why yet though. It could have just been poorly defined behavior checking in the unit tests.

Oh how I wish we had actual manifest/catalog type & provider unit testing. Someday.

@hunner
Copy link
Contributor

hunner commented Mar 23, 2017

#433 brings in the first four commits (yay! Thank you!) with a few tweaks, so the review is just for the last commit about tag/path.

# End file parameters

# Autorequire the file we are generating below
# Why is this necessary ?
Copy link
Contributor

Choose a reason for hiding this comment

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

¯_(ツ)_/¯ I don't recall. It seems like the generated file will be contained by the concat_file resource and wouldn't need this.

@tdevelioglu
Copy link
Author

@hunner I've refactored the types to work with both tag and target only. Can you take a look and let me know what you think?

@@ -0,0 +1,115 @@
require 'spec_helper_acceptance'
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like all of the acceptance tests except warn_header_spec.rb were copied from spec/acceptance/ to spec/acceptance/native/ but the originals were not modified. Was this on purpose?

Copy link
Author

Choose a reason for hiding this comment

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

The examples in spec/acceptance/native/ test the native types directly. They're modified originals.

This commit makes it possible to use the native types directly without
the :tag parameter supplied by the defined type wrappers.

The concat_file resource uses a (re-declared) :tag parameter to find its desired
fragments, however, because the tag parameter has special requirements
on its value, the concat and concat::fragment defined types normalize the
'target' parameter before passing it to :tag. The :target parameter,
is not used at all.
This makes the native types clumsy to use directly (i.e. without the
defined types).

This commit lets the concat_file type also collect fragments by its
:target parameter (which is not used at all anymore?) while
it keeps backward compatibility with the tag design.

- It makes concat_file collect fragments of which the :target parameter
matches its resource title or :path parameter.

- It implements the parameter validations from the defined types directly
in concat_file and concat_fragment.
@hunner hunner merged commit 14db7f4 into puppetlabs:master Jun 27, 2017
hunner added a commit that referenced this pull request Jun 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants