-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consul Session TTLs #524
Consul Session TTLs #524
Conversation
The design of the session TTLs is based on the Google Chubby approach (http://research.google.com/archive/chubby-osdi06.pdf). The Session struct has an additional TTL field now. This attaches an implicit heartbeat based failure detector. Tracking of heartbeats is done by the current leader and not persisted via the Raft log. The implication of this is during a leader failover, we do not retain the last heartbeat times. Similar to Chubby, the TTL represents a lower-bound. Consul promises not to terminate a session before the TTL has expired, but is allowed to extend the expiration past it. This enables us to reset the TTL on a leader failover. The TTL is also extended when the client does a heartbeat. Like Chubby, this means a TTL is extended on creation, heartbeat or failover. Additionally, because we must account for time requests are in transit and the relative rates of clocks on the clients and servers, Consul will take the conservative approach of internally multiplying the TTL by 2x. This helps to compensate for network latency and clock skew without violating the contract. Reference: https://docs.google.com/document/d/1Y5-pahLkUaA7Kz4SBU_mehKiyt9yaaUGcBTMZR7lToY/edit?usp=sharing
} | ||
|
||
if ttl < structs.SessionTTLMin || ttl > structs.SessionTTLMax { | ||
return fmt.Errorf("Invalid Session TTL '%d', must be between [%d-%d] seconds", ttl, structs.SessionTTLMin, structs.SessionTTLMax) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should probably be "[%v, %v]" and not specify seconds. This way you will get the nice formatting. Otherwise they are stored in nanoseconds, so you will get some really huge numbers.
@@ -51,6 +52,21 @@ func (s *HTTPServer) SessionCreate(resp http.ResponseWriter, req *http.Request) | |||
resp.Write([]byte(fmt.Sprintf("Request decode failed: %v", err))) | |||
return nil, nil | |||
} | |||
|
|||
if args.Session.TTL != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a test with an invalid TTL to check this code path?
LGTM :) |
…is enabled (hashicorp#524) On OpenShift, if we don't set this value, the container will not provisioned with proper privileges to run iptabels commands
The design of the session TTLs is based on the Google Chubby approach
(http://research.google.com/archive/chubby-osdi06.pdf). The Session
struct has an additional TTL field now. This attaches an implicit
heartbeat based failure detector. Tracking of heartbeats is done by
the current leader and not persisted via the Raft log. The implication
of this is during a leader failover, we do not retain the last
heartbeat times.
Similar to Chubby, the TTL represents a lower-bound. Consul promises
not to terminate a session before the TTL has expired, but is allowed
to extend the expiration past it. This enables us to reset the TTL on
a leader failover. The TTL is also extended when the client does a
heartbeat. Like Chubby, this means a TTL is extended on creation,
heartbeat or failover.
Additionally, because we must account for time requests are in transit
and the relative rates of clocks on the clients and servers, Consul
will take the conservative approach of internally multiplying the TTL
by 2x. This helps to compensate for network latency and clock skew
without violating the contract.
Reference: https://docs.google.com/document/d/1Y5-pahLkUaA7Kz4SBU_mehKiyt9yaaUGcBTMZR7lToY/edit?usp=sharing