Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
A
autoradio
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
ale
autoradio
Commits
d65d469d
Commit
d65d469d
authored
5 years ago
by
ale
Browse files
Options
Downloads
Patches
Plain Diff
Add a note on what the Node implementation does
parent
1b202d9d
No related branches found
No related tags found
1 merge request
!1
v2.0
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
node/node.go
+20
-0
20 additions, 0 deletions
node/node.go
with
20 additions
and
0 deletions
node/node.go
+
20
−
0
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
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment