Issue #1557 has been updated by luke. Status changed from Needs design decision to Accepted
I was already thinking about this problem, although in terms of caching the served files rather than handling load balancing. I'd been considering three basic alternatives for solving this problem: 1) Do it all on the server. I don't really like this method, because I'm not really sure it's feasible. At the least, you end up with shared state, I think. 2) Include the environment in the URI, at least for REST calls. This should be relatively straightforward, although it doesn't really allow for the server to override the client's idea of its environment. 3) Include the environment in metadata, like the content type. I don't really like this, but hey, it's an option. Would #2 work for all cases? Would it be acceptable to only support it for new-style REST calls? ---------------------------------------- Feature #1557: Puppet with environments isn't satisfactory with load balancing. http://reductivelabs.com/redmine/issues/show/1557 Author: nigelk2 Status: Accepted Priority: Normal Assigned to: luke Category: plumbing Target version: 0.25.0 Complexity: Unknown Affected version: 0.24.5 Keywords: Puppet doesn't currently work correctly with environments if you're doing load balancing across multiple puppet servers. I'm not sure if this problem is only restricted to instances where you're setting the environment via a fact as we are, but I don't think so. Illustration of the basic problem. Load balanced pair of server_a and server_b. Clients connect to a VIP that balances across the pair. Client connects to VIP, gets sent to server_a, server_a caches the fact information about the client on the filesystem, generates a manifest and sends it to the client. Due to keepalive being turned off, the client then makes separate connections for each resource request. Some of these may get sent to server_b. When a request for a file such as puppet:///modulename/filename is made to server_b, it may have no cached information about that client, and so has no idea what environment should be used for that client, and will fall back to the default environment. One option would be to put the cached client info in /var/lib/puppet/yaml on a shared filesystem or somehow make the data available to all servers in the cluster. My concern here is that this could expose potential race conditions in the puppet code. A few other ideas were tossed around in IRC that all involve the server modifying the puppet:/// urls that are sent out in the client manifest so that the subsequent requests contain the desired environment, namely: a) encode it in the form: <pre> puppet:///environmentname/modulename/filename </pre> b) encode it in the form: <pre> puppet:///modulename/filename?environment=environmentname </pre> I believe that a) is problematic due to enforcing a unique namespace for environments and modules. How do you tell what to do with: <pre> puppet:///development/foo/bar </pre> if you have a module and an environment both called "development" ? A suggestion was made to do something like: <pre> puppet:///environmentname/magicmarker/modulename/filename </pre> but that's uglier than option b) in my opinion. I'm happy to write a patch to do this, but I'd like to to be something that was actually acceptable upstream. ---------------------------------------- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
