On Tue, 2017-01-31 at 21:15 +0100, Spyros Trigazis wrote:
> Hi,
>
> The hack-ish way is to check if the current master has a different ip
> than the
> swarm_api_api and based on that decide whether to swarm init or join.
> The
> proper way is to have two resource groups (as you said) one for the
>
Hi,
The hack-ish way is to check if the current master has a different ip than
the
swarm_api_api and based on that decide whether to swarm init or join. The
proper way is to have two resource groups (as you said) one for the primary
master and one for the secondary masters. This requires some plum
On Tue, 2017-01-31 at 17:01 +0100, Spyros Trigazis wrote:
> Hi.
>
> I have done it by checking the ip address of the master. The current
> state of
> the heat drivers doesn't allow the distinction between master > 1 or
> master=1.
>
Please, could you elaborate on this ?
Also what is your opinio
Hi.
I have done it by checking the ip address of the master. The current state
of
the heat drivers doesn't allow the distinction between master > 1 or
master=1.
Spyros
On 31 January 2017 at 16:33, Kevin Lefevre wrote:
> Hi, Docker 1.13 has been released with several improvements that brings
Hi, Docker 1.13 has been released with several improvements that brings
swarm mode principles closer to Kubernetes such as docker-compose
service swarm mode.
I'd like to implement a v2 swarm template. I don't know if it's already
been discussed.
Swarm mode is a bit different but a lot simpler to
