Skip to content
GitLab
Projects
Groups
Snippets
Help
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
A
autoradio
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
2
Issues
2
List
Boards
Labels
Service Desk
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Operations
Operations
Incidents
Environments
Analytics
Analytics
CI / CD
Repository
Value Stream
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
ale
autoradio
Commits
d65d469d
Commit
d65d469d
authored
Apr 13, 2019
by
ale
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add a note on what the Node implementation does
parent
1b202d9d
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
20 additions
and
0 deletions
+20
-0
node/node.go
node/node.go
+20
-0
No files found.
node/node.go
View file @
d65d469d
...
...
@@ -48,6 +48,26 @@ type Node struct {
// New returns a new Node with a controlling Context, scoped to an etcd
// Session.
func
New
(
parentCtx
context
.
Context
,
session
*
concurrency
.
Session
,
ice
Icecast
,
nodeID
string
,
publicAddrs
[]
net
.
IP
,
peerAddr
net
.
IP
,
gossipPort
int
,
lbSpec
string
,
maxBandwidth
,
maxListeners
int
)
(
*
Node
,
error
)
{
// Creating a Node starts a number of background goroutines and etcd
// watchers. Here's how those parts interact:
//
// The main task of the Node is to manage the Icecast daemon by
// ensuring its configuration is in sync with the contents of our
// configuration (in etcd). The Node controls Icecast by generating
// its configuration and sending it a SIGHUP to reload it.
//
// Changes in the Icecast configuration originate from two sources:
// changes in the mount configuration, or state transitions of the
// Icecast leader. So we listen on both the configuration and the
// election notification channels, and use a third channel to send the
// new configuration to Icecast: in both cases, the other half of the
// configuration is cached and looked up asynchronously.
//
// The second part of the Node functionality has to do with
// maintaining a view of the state of all nodes so that we can use it
// for load balancing decisions. This is delegated to the loadBalancer
// type.
// Create a sub-Context that can be canceled when Stop is called. This
// Context controls the lifetime of the Node itself, and all the
// associated background goroutines: canceling it immediately
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment