>
> I am looking at integrating Foreman into an existing Puppet deployment of
> several hundred hosts. One of the things I really like about the way I
> manage puppet currently is the ability to control and version changes to
> the nodes. Since I do not currently use an ENC with puppet I use some node
> puppet files to define all the hosts. Since these files are in version
> control a change to a node goes through a testing phase before being pushed
> to the production deployment. Also in the event of an error the changes can
> be quickly rolled back to a previously known good state. My question is how
> this can be accomplished with Foreman? I don't see any versioning of
> objects nor do I see an easy way to make changes to a development Foreman
> deployment and then after testing push the same changes to a
> production deployment.
Some objects are versonable, (e.g. provisioning templates), most of them
have audit trail (which makes it possible to view older values, and in some
cases revert back (e.g templates).
My initial thought was to write some glue code that could read some custom
> configuration files about the parameters then use the API to set those
> parameters on the appropriate location, domain, hostgroup, etc. Digging
> into the API while it is easy to query/change basic information about
> objects modifying the parameters associated with objects is not as well
> supported.
Which kind of data do you have in mind parameters? classes ?
Most of the time, you can abstract most of the host state within your
puppet manifest, and by supporting multiple puppet environments, you
already have that kind of separation.
> For example I plan to set several global parameters on a domain. In my
> current setup we set several globally scoped variables in node definitions
> then we have some wrapper classes that use those global params to include
> parameterized classes. My thinking was to basically pull all the parameter
> definitions from the node puppet files and format them into a simple ini
> config file(manually). Then when we push those changes a script would read
> the config file and using the API set the parameters on the domain. The API
> in its current state allows you to set parameters on the domain, but it
> does not allow deleting or modification of existing parameters. It does not
> allow queering of the parameters on a domain either.
>
why not use smart variables (or puppet class variables)? you could easily
add mixtures of conditions, for example:
match: domain = example.com, environment = development
value: my special value for dev machines at example.com
>
> Is there a better way to have versioning control of the objects in Foreman
> or should I consider improving the API to support my needs?
>
I'm sure there is an improvement opportunity here, but I'm a bit unsure of
what exactly you are asking for, can you define which kind of data would
you like to version (e.g. I want hostgroup XYZ in Dev mode with all of its
related data?) or I just care about these sub parts (e.g. parameters etc).
thanks!
Ohad
···
On Fri, May 31, 2013 at 5:51 PM, Nathaniel Cook wrote:Nathaniel
–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.