Change 262742 had a related patch set uploaded (by Thcipriani):
Puppet provider for scap3

https://gerrit.wikimedia.org/r/262742

Change 262742 had a related patch set uploaded (by Dduvall):
Puppet provider for scap3

https://gerrit.wikimedia.org/r/262742

http://garylarizza.com/blog/2013/12/15/seriously-what-is-this-provider-doing/ has a lot of good explanations of how providers work.

It looks like we can't use package_settings in the provider because that feature was added in puppet 3.5 and Trusty uses puppet 3.4.

I can think of two alternative ways to set the username for a given scap package:

1. Pass the username in the package resource's install_options attribute
2. Manage the top-level directory (/srv/deployment/{package}) with a regular File resource in puppet, and then have the package provider only deal with the subdirectories within /srv/deployment/{package}/*

@akosiaris & @dduvall: What do you guys think about these options? Or am I missing something with regards to the package_settings feature? Do we not need to support puppet versions < 3.5?

Actually there is a third option: https://github.com/ptomulik/puppet-backport_package_settings

I tried to install the backport on my test instance (deploy.eqiad.wmflabs) but I got an error: https://github.com/ptomulik/puppet-backport_package_settings/issues/1

In T113072#2006936, @mmodell wrote:

It looks like we can't use package_settings in the provider because that feature was added in puppet 3.5 and Trusty uses puppet 3.4.

I can think of two alternative ways to set the username for a given scap package:

1. Pass the username in the package resource's install_options attribute
2. Manage the top-level directory (/srv/deployment/{package}) with a regular File resource in puppet, and then have the package provider only deal with the subdirectories within /srv/deployment/{package}/*

@akosiaris & @dduvall: What do you guys think about these options? Or am I missing something with regards to the package_settings feature? Do we not need to support puppet versions < 3.5?

Yes, we need to support versions <3.5. We use 3.4.3 right now. I 've developed the draft for the scap3 package provider on a jessie system which has 3.7, where it works just fine. I 've considered abusing install_options back then as well. It was mostly the fact that package_settings seemed easier to abuse due to the single hash argument it receivers according to the documentation whereas install_options receives an array of strings, hashes, etc. I think we should update the provider for that instead of backporting package_settings.

@akosiaris: I agree, the backport doesn't seem to work right and I can come up with something that uses install_options easily enough. Thanks for your feedback.

Ok I updated the patch at https://gerrit.wikimedia.org/r/#/c/262742/18, works on labs with some minor hacks to get around environment-related peculiarities.

@akosiaris said he'd give the patch one last review, after that I'll merge it and babysit patches for phab deployment as long as @mmodell is around.

@ArielGlenn: I'm almost done with T125851: Refactor phabricator module in puppet to remove git tag pinning behavior

Change 269560 had a related patch set uploaded (by 20after4):
scap::target to configure scap3 deployment repository and deploy-user.

https://gerrit.wikimedia.org/r/269560

Change 262742 merged by ArielGlenn:
Puppet provider for scap3

https://gerrit.wikimedia.org/r/262742