23.10.2014 22:39, David Vossel wrote: > > > ----- Original Message ----- >> 21.10.2014 06:25, Vladislav Bogdanov wrote: >>> 21.10.2014 05:15, Andrew Beekhof wrote: >>>> >>>>> On 20 Oct 2014, at 8:52 pm, Vladislav Bogdanov <bub...@hoster-ok.com> >>>>> wrote: >>>>> >>>>> Hi Andrew, David, all, >>>>> >>>>> It seems like #kind was introduced before bare-metal remote node >>>>> support, and now it is matched against "cluster" and "container". >>>>> Bare-metal remote nodes match "container" (they are remote), but >>>>> strictly speaking they are not containers. >>>>> Could/should that attribute be extended to the bare-metal use case? >>>> >>>> Unclear, the intent was 'nodes that aren't really cluster nodes'. >>>> Whats the usecase for wanting to tell them apart? (I can think of some, >>>> just want to hear yours) >>> >>> I want VM resources to be placed only on bare-metal remote nodes. >>> -inf: #kind ne container looks a little bit strange. >>> #kind ne remote would be more descriptive (having now them listed in CIB >>> with 'remote' type). >> >> One more case (which is what I'd like to use in the mid-future) is a >> mixed remote-node environment, where VMs run on bare-metal remote nodes >> using storage from cluster nodes (f.e. sheepdog), and some of that VMs >> are whitebox containers themselves (they run services controlled by >> pacemaker via pacemaker_remoted). Having constraint '-inf: #kind ne >> container' is not enough to not try to run VMs inside of VMs - both >> bare-metal remote nodes and whitebox containers match 'container'. > > remember, you can't run remote-nodes nested within remote-nodes... so > container nodes on baremetal remote-nodes won't work.
Good to know, thanks. That imho should go into the documentation in bold red :) Is that a conceptual limitation or it is just "not yet supported"? > > You don't have to be careful about not messing this up or anything. > You can mix container nodes and baremetal remote-nodes and everything should > work fine. The policy engine will never allow you to place a container node > on a baremetal remote-node though. > > -- David > >> >>> >>>> _______________________________________________ >>>> 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
