This class allows last-second configuration without having to generate or update class files to support the new fields. It
is both YAML and Json compatible, and it allows you to treat non-YAML-standard embedded strings as key-value pairs.
Note |
The flags must include double quotes (for example, flag: "VariableName: 123" and flag: "AnotherVariableName: x45").
|
Currently defined values (flags in the current config.json file):
- flag: "StartUp_PopulateDb: True"
* This is used by the ovsdb-plugin startup code. If not present, the value defaults to False.
This value tells the plugin to attempt to build its own OVSDB based on existing switch configuration.
Sometimes it might be useful to toggle to False to allow the plugin to take a fresh
configuration from the controller.
* The default value is True.
Other available configuration flags that are supported but are not currently being set (that is, the default values are being
used):
- flag: "DB_minElapsedTimeBeforeLogging: NNN"
* At one point in time, we were concerned about database performance.
This flag allowed us to track every database call that took MORE than
a certain time. For example, setting this value to 400 would cause any
db call that took MORE than 400 ms to be logged (so it could be tracked).
* The default value is 150 aka 150 msecs.
- flag: "JP_HowOftenToLogSocketConnectFailuresInMs: NNNNN"
* For each connection (or ManagerInfo) in the config.json file, certain code
will attempt to make a socket connection to each of those records.
For some connections (like the utility connection used to support the ovsdb cli),
it is VERY VERY likely NOT to make a connection. However, each connection
failure causes logging. This setting HOW OFTEN (in ms) we should SHOW an error.
Use of this feature will reduce the amount of uninformative logging data generated.
* Note that the current defalut value is grossly = Show Errors every 20th time.
- flag: "JP_OffsetFromInactivyProbeTimeInMs: NNNNN"
* This is a millisecond value used by the JSON Peers.
* The ManagerInfo record in the config file (as well as the data conveyed to us by a controller)
contains an InactivityProbe value.
* This value describes how long (in milliseconds) it will take of inactivity before the
specified connection will send us a probe (aka echo) message "to keep the socket warm"
(i.e., to maintain the connection".
* The JSON Peer uses this same value. If it sees this InactivityProbe amount of time without
any activity, it will decide to send an echo.
* So, back to this flag. This flag allows us to control who will send the echo.
(because, basically, both sides are "agreeing" to send it at, say, 60 seconds; so it is
INCREDIBLY arbitrary which "end" will end up sending the actual echo/probe message).
* This configured value ends up being SUBTRACTED from the configured (or provided) inactivity
probe value and it is this calculated value that ends up being used in the JSON Peers
calculations.
* (Assume here that the configured Inactivity Probe Time = 60 seconds).
* So, if you set this value to 2000, you are telling the JSON Peer to use, say, 60-2 or 58
seconds as its calculated value. That means, most likely, that the JSON Peer will end up
sending the echo to the controller.
* Alternatively, you could set this value to -2000. This means that the JSON Peer will use
( 60 - (-2) ) or 62 seconds as its probe time. This would mean that, most likely, the
controller will end up sending echoes to the JSON Peer.
* This value defaults -2000 aka -2 seconds aka the controller will probably send us echoes.
- flag: "JP_ManageJsonPeersLoopTimeInMs: NNNNN"
* This millisecond value determines what the delay (in milliseconds) between subsequent loops
for the ManagerJJsonPeers code should be.
* This value defaults to 1500 (aka 1.5 seconds).
- flag: "JP_ReportManageJJsonPeerStatusTimeInSeconds: 20000"
* This SECONDS value determines approximately how often the "Manager Json Peer logging report"
should be generated.
* This should be a value more than 45 seconds, since the "report" is not really that useful.
* Also, this thread is constantly running; setting this to N seconds means that you will get a
1 line log of ManagerJJsonPeer status information FOR THE ENTIRE ANDROMEDA RUN.
* This value defaults to 120 which means you would get a report every 2 minutes.
* Setting this value to 0 means generate no reports.
- flag: "JP_ReportThreadCountTimeInMs: NNNNN"
* The system has an ability to occasionally generate a log statement which
indicates how many Threads are currently in use and what the peak usage has been.
This flag defaults = -1 = do not display.
* Note that this is not a "fine tuned" time value; I would suggest not to expect
any more accuracy (or granularity) than about a second (aka 1000).
* I have typically set this to 10000 or 15000 (aka 10 or 15 seconds).
* The log statment would look like:
(timestamp) [ManageJJsonPeers] INFO jsonrpc.util.ManageJJsonPeers | Java Thread Count:
Current = 30, Peak = 33
- flag: "JP_ReportThreadInfoTimeInMs: NNNNN"
* The system has an ability to occasionally generate a log statement which
provides *detailed* information on *every* thread that is currently running.
* This option takes a bit of time to generate and can easily generate over 100 lines of logging output.
Therefore, it is felt that this should not be set to any value less than about 20000.
* This flag defaults = -1 = do not display.
* Note that this is not a "fine tuned" time value; I would suggest not to expect
any more accuracy (or granularity) than about a second (aka 1000).
* I have typically set this to 20000 or 30000 (aka 20 or 30 seconds).
- flag: "JP_SocketTimeoutValue: 60000"
* This is used by the JJsonPeer to set the SocketTimeout value used by the JSON Peers.
* This value defaults to 0.
* 0 means NO TIMEOUT (i.e., block forever)
- flag: "JPSR_SingleSocketReadSize: 10000"
* This value determines the size for each read attempt on the JSON Peer socket".
* A too large value will slow the average read times down; a too small value will cause too many
reads to be performed.
* There is no "absolultely correct" value.
* However, values < about 2000 or > about 20000 probably are not very efficient.
* If not set, this value defaults to 5000.
- flag: "JpSupport_ThreadPoolSize: 10"
* This value determines how many threads are used to support JSON Peer support threads.
* If not set, this value defaults the "maximumNumJJsonPeerThreads" value + 2.
- flag: "JpSupportJP_WaitPoolTermination: 5"
* This weirdly-named value determines how long the Jp Support shutdown code waits for the thread
pool to terminate.
* If not set, this value defaults to 3.
- flag: "JP_TimeBetweenLongRunningCmdsLoggingInMs: NNNNN"
* When the JJSonPeer receives a command, it passes it to the "SA" to determine a response.
Another thread (specifically, ManageJJsonPeers) watches over the JJsonPeers.
If this value is set to NNN, any time we are waiting for LONGER than NNN milliseconds
for the SAL to generate a response, a log statement would be generated.
* This defaults to 10000 aka 10 seconds.
* This log statement will look something like:
(timestamp) [(who)] WARN jsonrpc.util.JJsonPeerStatus | JP=(connection descriptor): has been
building a Response to a rcvd command for (amountOfTime) ms. !!!!!!
- flag: "LoadDbFromSwitchMaxWaitTimeInMs: NNNN"
* This value is only to be used in a Worst Case Scenario.
* The value indicates the Maximum Time that the "Load DB" code should take under ANY circumstances.
* If the code EVER takes this long,
- the code waiting for this process to complete will be returned to
- a failure will be returned.
* This integer number of milliseconds value defaults to 5*60*1000 (aka 5 minutes).
- flag: "LoadDbFromSwitchSingleSleepTimeInMs: NNNN"
* This value indicates how long each sleep time should be while waiting for the "Load DB" code to complete.
* If the value is configured too small the code waiting will spend too much CPU waiting and looping.
* If the value is configured too large then it is likely that (on average) half of the configured time
will be "wasted" because the code is done but the waiting code is unneccessarily sleeping too long.
* This integer number of milliseconds value defaults to 500.
- flag: "MAIN_DelayBeforeRunMatrixInSecs: NN"
* This value is used by the main routine (AndromedaMain) to determine how many seconds to delay
(after everything else is done) before calling The Matrix.
* This integer number of seconds value defaults to 0.
- flag: "maximumNumJJsonPeerThreads: NNN”
* This is used by the JJsonPeerThreadBoss to determine the maximum
number of JJsonPeer threads that should exist at any one time.
* Note, without this flag present, (or if it has a value of -1) the value is auto calculated.
- flag: "NOTIF_ThreadPoolSize: 10"
* This value determines how many threads are used to support the internal event Notifiation system.
* If not set, this value defaults to 6.
- flag: "NOTIF_WaitPoolTermination: 5"
* This value determines how long the notification shutdown code waits for the thread pool to terminate.
* If not set, this value defaults to 3.
- flag: "NX_AaaRefreshCycleInSecs: NNNNN"
* This value determines how often the "AAA Refresh" (to the switch) should be done.
* This value defaults to 540 seconds.
- flag: "NX_AaaRefreshStartDelayInMsecs: NNNNN"
* This value determines a start delay the "AAA Refresh" (to the switch) should be done.
* This value defaults to 5500 seconds.
- flag: "NX_CheckConnectivityTimeout: NNNNN"
* This millisecond value determines how long to "sleep" between subsequent attempts to connect
to the switch.
* This value defaults to 10000 (aka 10 seconds).
- flag: "NX_ConnectionRetryCount: N"
* This value determines how many times several low-level NXAPI calls are made BEFORE an error is logged.
* The affected routines (in the NXAPITLServiceImpl class) are:
+ attemptToReconnectAsNeeded
+ ensureConnectedToWebsocket
+ checkSocketConnectivity
* This value defaults to 2.
- flag: "NX_ConnectTimeout: NNNNN"
* This millisecond value determines what the connect timeout value for the socket to the switch should be.
* This value defaults to 20000 (aka 20 seconds).
- flag: "NX_ReadTimeout: NNNNN"
* This millisecond value determines what the read timeout value for the socket to the switch should be.
* This value defaults to 20000 (aka 20 seconds).
- flag: "Port_Vlan_Batching_Config: NNN"
* This value determines how many port-vlan pairs are gathered together in a single batched NXAPI call.
* The code sends the SMALLER of (the num avail and this configured size) in a single NXAPI call.
* This value defaults to 100.
- flag: "Vnid_Vlan_Batching_Config: NNN"
* This value determines how many vlan-vnid pairs are gathered together in a single batched NXAPI call.
* The code sends the SMALLER of (the num avail and this configured size) in a single NXAPI call.
* This value defaults to 100.
- flag: "SHUT_OkToStopLoggingAtShutdown: False"
* This TRUE/FALSE value determines whether or to suppress all logging once a shutdown occurs.
* If not set, this value defaults to TRUE.
- flag: "StartUp_PopulateDb: True"
* This flag is used by the "Load DB" code to determine whether or not the code should run at all.
* If not set, this value defaults to TRUE.
* If set to False, "Load DB" simply returns without doing anything.
- flag: "StartUp_SystemReadyDelayInMs: 60000"
* This is used by the ovsdb-plugin code. It used to be used at startup, but now it is used
whenever we need to wait for a given switch to return a good ConfigReady value.
* If not present, the value defaults to 10000.
* Note that there is no range-checking on this value.
- flag: "SUB_GoodSubscriptionRefreshRateInMsecs: NNNNN"
* This millisecond value determines approximately how often the Subscription Refresh
threads run "when things are going well".
* This value defaults to 40000 (aka 40 seconds).
- flag: "SUB_BadSubscriptionRefreshRateInMsecs: NNNNN"
* This millisecond value determines approximately how often the Subscription Refresh
threads run "when things are going poorly".
* It seems like this value should be smaller than the "good" value
of SUB_GoodSubscriptionRefreshRateInMsecs.
* This value defaults to 15000 (aka 15 seconds).
- flag: "SUB_NumErrsBeforeDeclareBad: N"
* This counter value determines how many consecutive errors a Subscription Refresh
Thread should see before it declares the NXAPI connection as down.
* Note that crossing this threshhold puts the Subscription Refresh thread in "probe mode",
where it is in a loop, probing the nxapi connection and waiting for it to come up.
* See NumSuccessesToEscapeProbeMode for related info.
* This value defaults to 4.
- flag: "SUB_NumSuccessesToEscapeProbeMode: 5"
* This counter value determines how many consecutive successes a Subscription Refresh
Thread should see (once it has declared the connection down and is in "probe mode").
* See SUB_NumFailuresToDeclareBad for related info.
* This value defaults to 5.
- flag: "SUB_SocketConnectTimeoutInMsecs: 60000"
* This is used by the SubscriptionRefreshThread as its "connection timeout" value.
* This value is only used by the Single Subscription code in the Subscription Refresh Thread.
* This value defaults to 20000 aka 20 seconds.
- flag: "SUB_SocketReadTimeoutInMsecs: NNNNN"
* This millisecond value determines what the read timeout value for the socket to the switch should be.
* This value is only used by the Single Subscription code in the Subscription Refresh Thread.
* This value defaults to 20000 (aka 20 seconds).
- flag: "SUB_ProbeModeDelayInMsecs: NNNNN"
* This millisecond value determines how often the "probe the nxapi connection until it comes back up"
code will loop.
* This value defaults to 10000 (aka 10 seconds).
- flag: "TL_ConnectionDownSleepInMs: NNNNN"
* This millisecond value is used by the AsyncTaskWork (which sends batch information to the switch).
* The AsyncTaskWorker, once it finds the NXAPI connection to be down, it sits in a loop and keeps waiting
for an UP.
* This value is the sleep time (in milliseconds) between subsequent connection checks.
* This value defaults to 20000 aka 20 seconds.
The following flags are not supported:
- flag: "DoNewAndromedaStatusFormat: True"
- flag: "JP_NumBadMsgCounterThreshHold: 10"
- flag: "JP_NumEndOfStreamReadsThreshHold: 10000"
- flag: "JP_NumGenSocketExceptThreshHold: 10"
- flag: "JP_NumSocketTimeoutExceptThreshHold: 10"
- flag: "NX_MaxDebugLogOutput: NNNNN"
- flag: "Startup_SystemReadyIgnoreResults: False"
- flag: "StartUp_SystemReadyNumTries: 3"
- flag: "VPC_BeanRequestDelayInSecs: NNN"
- flag: "VPC_BeanRequestTimeoutInSecs: NNNN"
- flag: "VPC_DoWeAllowNonVpcSwitches: True"
- flag: "VPC_HowManyBeanErrsBeforeDeclarePrimary: NNN"