>
> For more info I'm half through writing a doc now: http://cern.ch/go/pr9D
>
> I've reviewed your document, and you did find some important issues.
>
> 1. a hostgroup does not contain a list of classes per environment
> this is correct, and I'm wondering what should be the right handling here, i see a couple of options.
> a. keep the list as is.
> b. manage a puppet class list per env.
> c. make sure the suggested classes are part of the selected env before returning the class list.
>
> which one would you prefer? each one has its pro and cons, my preference would be option C, its trivial to implement and would require the least amount of maintenance, however, there is still a chance of a conflict (e.g out of date imported classes etc).
>
> option b. might require a lot of work, maybe it can be done with some ui enchantments.
>
C definitely makes sense , there's a horrible case where you add a class X every where and it breaks every environment of nodes not
containing that class.
As for B maybe at some places but the list will not be in step with the git files, i.e when I do 'git merge myfeature' into production I might also want the class list to be in step. I certainly want to
be testing the same class as I then have in production.
> 2. dividing which classes are defined in foreman, vs. which are included via a manifest.
> I guess this is a fine line, where a design decision needs to be taken, I personal would not want to expose any internal class (e.g. app::config) or a infrastructure module (e.g. module that is only included by another module.
>
> I normally filter them out on my foreman instance (see config/ignored_environments.yml.sample for details).
>
I was not aware of the filter (would be good to add to rpm), that makes a lot of sense, my doc did not
mention but the explosion of classes was certainly unattractive with the web interface but not a main reason for us checking.
>
> I guess at the end, it depends who uses foreman (if its the same guy who does the puppet manifests or rather someone else who has no idea about the manifests and just want to consume it as a service.
>
git branches and environments work incredibly well for isolating your configurations. So anything
outside that same mechanism is then a mismatch against that.
> I would eventually select classes that users might want to override their value (via plain parameters or class parameters), and let all of the rest to be managed via puppet.
>
The tricky ones are e.g apache::vhost{'myservice': template => 'foot':} which describes a whole service perfectly well and could go in a site.pp just like that.
···
On Dec 17, 2012, at 3:28 PM, Ohad Levy wrote:
> On Mon, Dec 17, 2012 at 3:47 PM, Steve Traylen wrote:
Feedback?
thanks,
Ohad
–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/foreman-users?hl=en.
:c':}