----- 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. 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