[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Socket activation



Hi David,

Comments inline

--Krishna

On Sep 4, 2013, at 11:06 AM, David Strauss <david davidstrauss net> wrote:

> On Wed, Aug 28, 2013 at 9:28 AM, Krishna Raman <kraman gmail com> wrote:
>> So this is the current plan:
>> 
>> 1) Idle the container and have sockets for each cartridge listening on a 169.254.*.* address on the container
>> 2) When a SYN request comes in container is unidled and openshift container init process is started
>> 3) Process triggers changes in IPtables which sets up a forwarding rule from the 169.254.*.* to the NAT'd address the cartridge is listening on
>>        - SYN times out, and tcp retry sends another SYN which is sent to the cartridge
>>        - connection is established as usual
> 
> I just got back from Burning Man, so I can reply now.
> 
> I share Clayton's concern about SYN-based un-idling. I manage the
> network at my office with smart routers and switches, and their
> failure-detection might trip if SYNs consistently get ignored.

It would only be the first SYN that would be ignored and would be picked up upon the next retry once the container is started.
If the container takes longer to start than the SYN timeout, then even the socat approach would result in timeout at your router level.
Would the router's failure-detection trip based on a single SYN failure?

> Have you looked into environment-based socket passing with a shim like
> socat? socat already supports specifying a socket using a file
> descriptor, and it can forward to and from sockets in the container's
> network namespace. It seems like it would be equivalent in
> functionality and compatibility with SYN timeout and iptables but
> without breaking the TCP spec or requiring global firewall changes at
> container start-up time.

A socat based approach has a few issues:
1) I am trying to avoid having to route packets through a user level program. Would rather keep it in kernel space and use IPTables.
2) Even tough it is small, socat and other programs will add overhead to each gear
2) Based on some tested a we did a while ago socat becomes unresponsive is there is heavy load. Rob can elaborate on this.

> 
> -- 
> David Strauss
>   | david davidstrauss net
>   | +1 512 577 5827 [mobile]



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]