On 1 Sep 2014, at 12:41 pm, Patrick Hemmer <pacema...@feystorm.net> wrote:
> From: Andrew Beekhof <and...@beekhof.net> > Sent: 2014-08-31 19:57:43 EDT > To: The Pacemaker cluster resource manager <pacemaker@oss.clusterlabs.org> > Subject: Re: [Pacemaker] pacemaker-remote container as a clone resource > >> On 31 Aug 2014, at 6:09 pm, Patrick Hemmer <pacema...@feystorm.net> >> wrote: >> >> >>> I'm interested in creating a resource that will control host containers >>> running pacemaker-remote. The catch is that I want this resource to be a >>> clone, so that if I want more containers, I simply increase the `clone-max` >>> property. >>> >> What kind of container? > Well I would hope the solution is generic enough to work with any container. > But in my specific case, EC2 instances. Plus maybe docker for development > work. > >> Most development was done with VirtualMachine which needs a unique name >> anyway (ie. cant be cloned). > With EC2 (and docker), you create an instance/container and the name & > address is returned after creation. Thats going to be challenging then. Since there is no way to know which containers are allowed to be attempting a connection or even which ones match up to the implicit connection managers we have started. I assume all of these containers are doing the same thing? > >> Interesting concept though, I'm sure we can figure out some way to get it >> done. >> >> >>> The problem is that the `remote-node` meta parameter is set on the clone >>> resource, and not the children. So I can't see a way to tell pacemaker the >>> address of all the clone children containers that get created. >>> The only way I can see something like this being possible is if the >>> resource agent set an attribute on the clone child when the child was >>> started. >>> >>> Is there any way to accomplish this? Or will I have to create separate >>> resources for every single container? If this isn't possible, would this be >>> considered as a future feature? >>> >>> Thanks >>> >>> -Patrick >>> _______________________________________________ >>> Pacemaker mailing list: >>> Pacemaker@oss.clusterlabs.org >>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>> >>> >>> Project Home: >>> http://www.clusterlabs.org >>> >>> Getting started: >>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>> >>> Bugs: >>> http://bugs.clusterlabs.org >> >> >> _______________________________________________ >> Pacemaker mailing list: >> Pacemaker@oss.clusterlabs.org >> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >> >> >> Project Home: >> http://www.clusterlabs.org >> >> Getting started: >> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >> >> Bugs: >> http://bugs.clusterlabs.org > > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
