On 1 Sep 2014, at 1:32 pm, Patrick Hemmer <pacema...@feystorm.net> wrote:
> From: Andrew Beekhof <and...@beekhof.net> > Sent: 2014-08-31 23:16:10 EDT > To: The Pacemaker cluster resource manager <pacemaker@oss.clusterlabs.org> > Subject: Re: [Pacemaker] pacemaker-remote container as a clone resource > >> 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. >> > That was the reason for my thought about setting an attribute on the clone > child from within the resource agent. The resource agent would start the > container, the container management service would respond with the address, > and the resource agent would call `crm_attribute` on itself (the clone child) > to set the `remote-node` property to the address of the container (like > master/slave resource agents do for setting scores). Except, by design, the clone child doesn't exist as an addressable entity in the cib. What settings do you have for globally-unique=false and clone-node-max btw? Even ignoring pacemaker-remote, I suspect you're going to have issues with reprobes (which can happen at any time). This is because you need a way to match the clone child's name to the specific container it started. Normally the resource name is in some way related to the container's - have you got some equivalent in the case of clones? If not, the cluster will get horribly confused on a regular basis (because multiple monitor ops will find the same container and report themselves as active). > > Though I don't follow on what you mean on "which containers are allowed to be > attempting a connection". The pacemaker-remote connection is initiated by the > host, not the remote. So no container should be connecting, Right, I managed to confuse myself for a moment there. > and the resource agent will instruct the host who it should be connecting to. > >> I assume all of these containers are doing the same thing? > Basically yes. They'll all be capable of running resources as instructed by > pacemaker. > >> >>>> 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 >> >> >> _______________________________________________ >> 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
