Re: Avoiding Docker Bridge network when using S3 discovery

[Dave Harvey]

Created https://jira.apache.org/jira/browse/IGNITE-10791 for this




--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Avoiding Docker Bridge network when using S3 discovery

[Dave Harvey]

We didn't see a way to use setLocalAddress.  Each container has a different
IP address, but the bridge network presents the same IP address to each
container.  Therefore, we would only know what to use for the local address
by enumerating all addresses, and eliminating the bridge network.

On Mon, Dec 3, 2018 at 3:31 PM Stanislav Lukyanov 
wrote:

> Hi,
>
>
>
> Have you been able to solve this?
>
> I think specifying TcpDiscoverySpi.localAddress should work.
>
>
>
> Stan
>
>
>
> *From: *Dave Harvey 
> *Sent: *17 октября 2018 г. 20:10
> *To: *user@ignite.apache.org
> *Subject: *Avoiding Docker Bridge network when using S3 discovery
>
>
>
> When we use S3 discovery and Ignite containers running under ECS using
> host networking, the S3 bucket end up with 172.17.0.1#47500 along with the
> other server addresses.   Then on cluster startup we must wait for the
> network timeout.Is there a way to avoid having this address pushed to
> the S3 bucket?
>
> Visor shows:
>
> | Address (0) | 10.32.97.32  |
>
> | Address (1) | 172.17.0.1   |
>
> | Address (2) | 127.0.0.1
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Disclaimer*
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by *Mimecast Ltd*, an innovator in Software as a
> Service (SaaS) for business. Providing a *safer* and *more useful* place
> for your human generated data. Specializing in; Security, archiving and
> compliance. To find out more Click Here
> .
>
>
>

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast Ltd, an innovator in Software as a Service 
(SaaS) for business. Providing a safer and more useful place for your human 
generated data. Specializing in; Security, archiving and compliance. To find 
out more visit the Mimecast website.

RE: Avoiding Docker Bridge network when using S3 discovery

[Stanislav Lukyanov]

Hi,

Have you been able to solve this?
I think specifying TcpDiscoverySpi.localAddress should work.

Stan

From: Dave Harvey
Sent: 17 октября 2018 г. 20:10
To: user@ignite.apache.org
Subject: Avoiding Docker Bridge network when using S3 discovery

When we use S3 discovery and Ignite containers running under ECS using host 
networking, the S3 bucket end up with 172.17.0.1#47500 along with the other 
server addresses.   Then on cluster startup we must wait for the network 
timeout.    Is there a way to avoid having this address pushed to the S3 
bucket?     
Visor shows:
| Address (0)                 | 10.32.97.32                              |
| Address (1)                 | 172.17.0.1                               |
| Address (2)                 | 127.0.0.1        






Disclaimer
The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast Ltd, an innovator in Software as a Service 
(SaaS) for business. Providing a safer and more useful place for your human 
generated data. Specializing in; Security, archiving and compliance. To find 
out more Click Here.