<div dir="ltr">In my opinion, you're not far off Scott. PuppetLabs and Red Hat are a little bit at odds with one another philosophically and it shows.<div><br></div><div>Satellite 6.0's puppet integration leaves some things to be desired in the module/environment management space. The puppet environment is automatically generated as part of a (constantly name-changing) Content View, which can also contain RPM content as well. For simpler cases, or where people want to point and click, it's not so bad. Properly written modules can take advantage of Foreman's Smart Class Parameters and matching rules to get data into the modules. Except those parameters are not auditable or (easily) versionable. </div><div><br></div><div>Satellite 6.1 is supposed to help in this area somewhat - the Content View environment and Puppet environment are going to be decoupled, so you can have a Content View of "MyCompany_RHEL_7_Production" and a Puppet environment of "development" for example. </div><div><br></div><div>Red Hat is aware of the management issues of Smart Class Parameters and are working to make those better, but I don't think that will be until at least 6.2. 6.1 is currently in a private beta and I expect a public beta any day now. </div><div><br></div><div>Going the git/hiera/r10k route is the workflow direction Puppetlabs seems to be pushing for. You can shoehorn hiera into Satellite, but it's not pretty and the ability to keep separate git branches for your puppet environments goes away. </div><div><br></div><div>If you're attending Red Hat Summit this year, there is a presentation on Thursday at 4:50 called Puppet Enterprise & Red Hat Satellite 6 which is joint between Red Hat and Puppetlabs. If you won't be at Summit, I'm sure you can find a video of it after Summit is over.</div><div><br></div><div>For what we've been doing, I've advocated for keeping the Puppet master separate from Satellite. I'm still using Satellite as the ENC to assign classes (acting as the role part of roles/profiles) by assigning a single profile class to each server. When 6.1 hits, this will make more sense as right now I end up having to create puppet environments called things like KT_Company_Production_RHEL_7 as branches in my r10k control repo.</div><div><br></div><div>Hope that helps!</div><div><br></div><div>Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 12, 2015 at 1:11 PM, Scott Merrill <span dir="ltr"><<a href="mailto:skippy@skippy.net" target="_blank">skippy@skippy.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The Puppet in Satellite 6 will be locked in at an older version, and will be very slow to upgrade. I think you're likely to miss out on a lot of the developing features of Puppet if you use Sat6.<br>
<br>
I see Sat6's Puppet+Foreman as cobbler before them: a good jump start for big, slow moving enterprises that will benefit from some level of automation, but not something super useful for more nimble customers who can tackle automation and config management on their own.<br>
<br>
But maybe I'm wrong.<br>
<div class="HOEnZb"><div class="h5"><br>
On Jun 12, 2015 12:06 PM, Rick Hornsby <<a href="mailto:richardjhornsby@gmail.com">richardjhornsby@gmail.com</a>> wrote:<br>
><br>
><br>
> > On Jun 12, 2015, at 09:41, Matthew Hyclak <<a href="mailto:hyclak@gmail.com">hyclak@gmail.com</a>> wrote:<br>
> ><br>
> > Count me in for a meetup.<br>
> ><br>
> > We're doing some things with Satellite 6 and Puppet/hiera/r10k that may be interesting. I've been spending some time rewriting modules into the roles/profiles pattern as well.<br>
><br>
> While I'm geographically unable to attend a meetup, I'm interested to hear your progress/experience/thoughts on using Satellite 6's built-in puppet master capabilities. I'm presently learning/architecting/developing Puppet on a stand-alone Puppet server, but I've been asked to look at using our coming Satellite 6 server as the more permanent puppet master. So much of Satellite comes pre-configured (Foreman, etc) that I'm a bit leery of making configuration changes under the hood to support hiera (instead of the default of letting Foreman handle the class assignments for example).<br>
><br>
><br>
> -rick<br>
><br>
><br>
> _______________________________________________<br>
> colug-432 mailing list<br>
> <a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
> <a href="http://lists.colug.net/mailman/listinfo/colug-432" rel="noreferrer" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
<br>
_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" rel="noreferrer" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
</div></div></blockquote></div><br></div>