By all means, Pete. I'm glad it was helpful, and please feel free to reuse elsewhere.
- Jamis On 1/22/09 10:08 AM, Pete Hodgson wrote: > Great Jamis, that's exactly what I was looking for. Thanks, and thanks > for a great product! > > Hope you don't mind if I add some of this explanation to the Stack > Overflow question so others can find it. > > Cheers, > Pete > > On Jan 22, 8:14 am, Jamis Buck <[email protected]> wrote: >> On 1/22/09 4:12 AM, Gerhardus Geldenhuis wrote: >> >>> I have found this very usefull, however I do not understand the >>> difference between HOSTS and HOSTFILTER. It would be great if you >>> could explain it from another angle >> I'll give it another try. Consider this concrete example. Suppose your >> script defines three servers, A, B, and C. And it defines a task, "foo", >> that (by default) wants to run on A and B, but not C. Like this: >> >> role :app, "A", "B" >> role :web, "C" >> >> task :foo, :roles => :app do >> run "echo hello" >> end >> >> Now, if you do "cap foo", it will run the echo command on both A and B. >> >> If you do "cap HOSTS=C foo", it will run the echo command on C, >> regardless of the :roles parameter to the task. >> >> If you do "cap HOSTFILTER=C foo", it will not run the echo command at >> all, because the intersection of (A B) and (C) is an empty set. (There >> are no hosts in foo's host list that match C.) >> >> If you do "cap HOSTFILTER=A foo", it will run the echo command on only >> A, because (A B) intersected with (A) is (A). >> >> Lastly, if you do "cap HOSTFILTER=A,B,C foo", it will run the echo >> command on A and B (but not C), because (A B) intersected with (A B C) >> is (A B). >> >> To summarize: HOSTS completely overrides the hosts or roles declaration >> of the task, and forces everything to run against the specified host(s). >> The HOSTFILTER, on the other hand, simply filters the existing hosts >> against the given list, choosing only those servers that are already in >> the tasks server list. >> >> Hope that's clearer, >> >> Jamis >> >> >> >>> Regards >>> On Jan 21, 5:03 pm, Jamis Buck <[email protected]> wrote: >>>> Try the HOSTS environment variable: >>>> cap HOSTS=app2.example.com production deploy >>>> Note that doing this will treat app2 as being in every role, not just >>>> whichever role(s) it happens to be declared in. >>>> If what you want is to do a regular deploy, but only act on app2, and >>>> only as app2 is declared in your recipe file, you can use the HOSTFILTER >>>> variable instead: >>>> cap HOSTFILTER=app2.example.com production deploy >>>> Sorry if the distinction isn't clear there. Let me know if you need more >>>> clarification as to the difference between HOSTS and HOSTFILTER. >>>> - Jamis >>>> On 1/21/09 9:54 AM, Pete Hodgson wrote: >>>>> Hi Folks, >>>>> I have a system in production that has several servers in serveral >>>>> roles. I would like to test a new app server by deploying to that >>>>> specific server, without having to redeploy to every server in >>>>> production. Is there a way to ask Capistrano to deploy to a specific >>>>> server? Ideally I'd like to be able to run something like cap >>>>> SERVER=app2.example.com ROLE=app production deploy if I just wanted to >>>>> deploy to app2.example.com. >>>>> I original posted this question on Stack Overflow a few days back [1] >>>>> and got a few answers, but neither solution seemed to work for me. >>>>> Hope it's not bad form to now post here. >>>>> Cheers, >>>>> Pete >>>>> [1]http://stackoverflow.com/questions/429816/how-to-deploy-to-a-single-s... > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
