[Pacemaker] #kind eq container matches bare-metal nodes

Andrew Beekhof andrew at beekhof.net
Fri Oct 24 02:46:31 EDT 2014


> On 21 Oct 2014, at 5:38 pm, Vladislav Bogdanov <bubble at 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 <bubble at 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 :)



More information about the Pacemaker mailing list