Feature #6599
The client should default to using its cached catalog
| Status: | Accepted | Start date: | 03/04/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | agent | |||
| Target version: | 3.x | |||
| Affected Puppet version: | Branch: | |||
| Keywords: | ||||
| Votes: | 0 |
Description
We currently default to the client upgrading its catalog every time, and there’s no straightforward mechanism to change this default. This means that all phased roll-out work must involve working directly on the clients to control catalog updates.
We should instead switch to a model where the client can ask the server if it should update its catalog, and by default uses its existing catalog.
This should probably be done by the client sending the server its catalog version and the server returning a boolean on whether it should be retrieving a new catalog.
Alternatively, it could do something like a ‘HEAD’ request on a new catalog and compare the versions on the client, and decide to upgrade based on that.
History
Updated by Nigel Kersten 12 months ago
- Project changed from Product Roadmap to Puppet
- Category deleted (
Puppet) - Parent task deleted (
#6598)
Updated by Devon Peters 4 months ago
- Category set to agent
- Target version set to 3.x
Updated by Luke Kanies 4 months ago
Note that I think it’s important that the decision about whether to download the catalog is made by the server, not by the client.