[ClusterLabs] Coming in Pacemaker 1.1.17: container bundles

[Jan Pokorný]

On 17/04/17 09:51 -0500, Ken Gaillot wrote:
> On 04/13/2017 07:04 AM, Jan Pokorný wrote:
>> On 03/04/17 09:47 -0500, Ken Gaillot wrote:
>>> On 04/03/2017 02:12 AM, Ulrich Windl wrote:
>>>>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 01.04.2017 um 00:43 in Nachricht
>>>> <981d420d-73b2-3f24-a67c-e9c66dafb48f at redhat.com>:
>>>> 
>>>> [...]
>>>>> Pacemaker 1.1.17 introduces a new type of resource: the "bundle". A
>>>>> bundle is a single resource specifying the Docker settings, networking
>>>>> requirements, and storage requirements for any number of containers
>>>>> generated from the same Docker image.
>>>> 
>>>> I wonder: Is a "bundle" just a kind of special "group template"? It
>>>> looks as if I could do it with a group also, but would have to
>>>> write a bite more to get it configured. Did I miss something?
>>> 
>>> With a group, you could reproduce most of this functionality, though it
>>> would be more verbose: you'd need to configure ocf:heartbeat:docker,
>>> ocf:heartbeat:IPaddr2, and ocf:pacemaker:remote resources, plus a
>>> primitive for your service, as well as constraints that restrict the
>>> primitive to the guest node and prevent any other resource from running
>>> on the guest node.
>>> 
>>> However, this can do something that a group can't: launch multiple
>>> instances of a single container image, while associating floating IPs
>>> and storage mappings specific to each replica. This puts it somewhere
>>> between a group and a specialized form of clone.
>> 
>> In that case, wouldn't it be more systemic to factor any generic
>> clone/master-like controls (replicas, replicas-per-host, masters) out
>> of <docker> so it can be reused seemlessly when switching to other
>> possible containerization backends in the future?
> 
> We did consider that. It's not clear how much of the functionality (or
> terminology) will be applicable to other technologies (currently known
> and potential future ones). We decided that it would be cleaner to
> duplicate those fields in other technology tags than to have them not
> work for certain technologies.

Then I am confused about this double standard in comparison to
{port,storage}-mapping sections that are already hoisted out.

>> 
>>> Also, it will be shown differently in the cluster status, which is
>>> helpful.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20170418/8b46d131/attachment.sig>