[Pacemaker] #kind eq container matches bare-metal nodes
Vladislav Bogdanov
bubble at hoster-ok.com
Fri Oct 24 03:54:57 UTC 2014
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 <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'.
>
> 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 at 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 at 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 at 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 at 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
>
More information about the Pacemaker
mailing list