Feature #5921
Allow ENC to dynamically define modulepath/manifest instead of static environments.
| Status: | Accepted | Start date: | 01/18/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | node | |||
| Target version: | - | |||
| Affected Puppet version: | Branch: | |||
| Keywords: | ||||
| Votes: | 0 |
Description
I’ve been told that there are fundamental architectural problems that would prevent this from working right now, in any case I wanted to raise the issue.
We have a situation where we have a lot of different modules, and versions of those modules, need to be deployed to various systems. We control this with the modulepath expressed in an environment settings. Unfortunately our environments are growing unwieldy and seem to be an unnecessary middle-man when just wanting to set the correct modulepath for a node.
We can adequately figure out our modulepath in the ENC stage, and would like to just pass this modulepath directly to the Puppetmaster for dynamic usage on a per-node-run basis. This would bypass our use of environments altogether. Any thoughts?
History
Updated by James Turnbull over 1 year ago
- Category set to node
- Status changed from Unreviewed to Needs Decision
- Assignee set to Nigel Kersten
Updated by Nigel Kersten over 1 year ago
- Subject changed from Allow ENC to specify a modulepath for a client rather than an environment to Allow ENC to dynamically define modulepath/manifest instead of static environments.
Updated by Nigel Kersten over 1 year ago
- Status changed from Needs Decision to Accepted
- Assignee deleted (
Nigel Kersten)
I’ve been wanting something like this for a while.
There are a lot of things to think about here though, and it may require some API redesign.
In the meantime, it’s certainly possible to manage a very large number of environments. My preferred solution is to have a structured data format (YAML, JSON, whatever) that contains definitions of all your environments, and a regular task that parses this file and emits the appropriate environment definitions for the config file your puppetmaster consults.
You can manage hundreds of environments this way, and your script that parses the environment definitions can contain as much business logic as you need for your particular deployment.
Updated by Nigel Kersten 4 months ago
Do you genuinely need modulepaths to be dynamic? Or would a better way of managing many environments solve your problem?
e.g. if Puppet directly supported environments being defined in json or some structured format, and you could easily write to that via an API to create new environments, would being able to easily manage many many tens of environments generally solve your problem Oliver?
Updated by Oliver Hookins 4 months ago
I guess the problem there would be how you effectively bootstrap a blank system, especially if you already assume your modules will be structured in a certain way in order to get your puppetmaster into a running order and serving the module API (when it exists).
Aside from that, a JSON-based API would be quite nice.