> On 21 Oct 2014, at 5:38 pm, Vladislav Bogdanov <bub...@hoster-ok.com> wrote: > > 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'.
Thats what I was waiting for you to say :) _______________________________________________ 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
