Re: [ClusterLabs] Coming in Pacemaker 1.1.17: container bundles

[Ken Gaillot]

On 07/01/2017 06:47 AM, Valentin Vidic wrote:
> On Fri, Jun 30, 2017 at 12:46:29PM -0500, Ken Gaillot wrote:
>> The challenge is that some properties are docker-specific and other
>> container engines will have their own specific properties.
>>
>> We decided to go with a tag for each supported engine -- so if we add
>> support for rkt, we'll add a  tag with whatever properties it
>> needs. Then a  would need to contain either a  tag or a
>>  tag.
>>
>> We did consider a generic alternative like:
>>
>>   
>>  
>>  
>>  ...
>>  
>>  ...
>>   
>>
>> But it was decided that using engine-specific tags would allow for
>> schema enforcement, and would be more readable.
>>
>> The  and  tags were kept under  because we
>> figured those are essential to the concept of a bundle, and any engine
>> should support some way of mapping those.
> 
> Thanks for the explanation, it makes sense :)
> 
> Now I have a working rkt resource agent and would like to test it.
> Can you share the pcmk:httpd image mentioned in the docker example?

Sure, we have a walk-through on the wiki that I was going to announce
after 1.1.17 final is released (hopefully later this week), but now is
good, too :-)

   https://wiki.clusterlabs.org/wiki/Bundle_Walk-Through

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Coming in Pacemaker 1.1.17: container bundles

[Valentin Vidic]

On Fri, Jun 30, 2017 at 12:46:29PM -0500, Ken Gaillot wrote:
> The challenge is that some properties are docker-specific and other
> container engines will have their own specific properties.
> 
> We decided to go with a tag for each supported engine -- so if we add
> support for rkt, we'll add a  tag with whatever properties it
> needs. Then a  would need to contain either a  tag or a
>  tag.
> 
> We did consider a generic alternative like:
> 
>   
>  
>  
>  ...
>  
>  ...
>   
> 
> But it was decided that using engine-specific tags would allow for
> schema enforcement, and would be more readable.
> 
> The  and  tags were kept under  because we
> figured those are essential to the concept of a bundle, and any engine
> should support some way of mapping those.

Thanks for the explanation, it makes sense :)

Now I have a working rkt resource agent and would like to test it.
Can you share the pcmk:httpd image mentioned in the docker example?

-- 
Valentin

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Coming in Pacemaker 1.1.17: container bundles

[Ken Gaillot]

On 06/30/2017 12:10 PM, Valentin Vidic wrote:
> On Fri, Mar 31, 2017 at 05:43:02PM -0500, Ken Gaillot wrote:
>> Here's an example of the CIB XML syntax (higher-level tools will likely
>> provide a more convenient interface):
>>
>>  
>>
>>   
> 
> Would it be possible to make this a bit more generic like:
> 
>   
> 
> so we have support for other container engines like rkt?

The challenge is that some properties are docker-specific and other
container engines will have their own specific properties.

We decided to go with a tag for each supported engine -- so if we add
support for rkt, we'll add a  tag with whatever properties it
needs. Then a  would need to contain either a  tag or a
 tag.

We did consider a generic alternative like:

  
 
 
 ...
 
 ...
  

But it was decided that using engine-specific tags would allow for
schema enforcement, and would be more readable.

The  and  tags were kept under  because we
figured those are essential to the concept of a bundle, and any engine
should support some way of mapping those.

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Coming in Pacemaker 1.1.17: container bundles

[Valentin Vidic]

On Fri, Mar 31, 2017 at 05:43:02PM -0500, Ken Gaillot wrote:
> Here's an example of the CIB XML syntax (higher-level tools will likely
> provide a more convenient interface):
> 
>  
> 
>   

Would it be possible to make this a bit more generic like:

  

so we have support for other container engines like rkt?

-- 
Valentin

___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [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  schrieb am 01.04.2017 um 00:43 in 
>>> Nachricht
 <981d420d-73b2-3f24-a67c-e9c66dafb...@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  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)


pgpaCxj5jmjOz.pgp
Description: PGP signature
___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org

Re: [ClusterLabs] Coming in Pacemaker 1.1.17: container bundles

[Jan Pokorný]

On 03/04/17 09:47 -0500, Ken Gaillot wrote:
> On 04/03/2017 02:12 AM, Ulrich Windl wrote:
> Ken Gaillot  schrieb am 01.04.2017 um 00:43 in 
> Nachricht
>> <981d420d-73b2-3f24-a67c-e9c66dafb...@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  so it can be reused seemlessly when switching to other
possible containerization backends in the future?

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

-- 
Jan (Poki)


pgpsScYQcSbMr.pgp
Description: PGP signature
___
Users mailing list: Users@clusterlabs.org
http://lists.clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org