WIP : Elektron Logging library #16
|
|
@ -14,10 +14,10 @@ var formatter ElektronFormatter
|
|||
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
var ElektronLog *LoggerImpl
|
||||
var logDir logDirectory
|
||||
|
||||
func BuildLogger(prefix string) {
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
func BuildLogger(prefix string, logConfigFilename string) {
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
|
||||
// read configuration from yaml
|
||||
config.GetConfig()
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
config.GetConfig(logConfigFilename)
|
||||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
|
||||
// create the log directory
|
||||
startTime := time.Now()
|
||||
|
|
|
|||
|
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
Logger and Log are synonyms and therefore should not be used interchangeably. Logger and Log are synonyms and therefore should not be used interchangeably.
Comments should start with capital letters and should end with a full stop. Comments should start with capital letters and should end with a full stop.
The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the The second argument to GetLogDir() is a prefix. How is "_" a prefix? This is probably why the log directory name is not ending up prefixed with the one specified with the `-logPrefix` flag.
What is the rationale behind having a dummy node as the head of the chain? What is the rationale behind having a dummy node as the head of the chain?
Done Done
Nothing specific. I had kept Nothing specific. I had kept `ElektronLog` as `LoggerImpl` type. But I have changed to `ConsoleLogger` rather. Works fine now
Done Done
Changed Changed `ElektronLog` to `ElektronLogger`
|
||||
|
|
@ -13,7 +13,7 @@ type Logger interface {
|
|||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
type LoggerImpl struct {
|
||||
Type int
|
||||
AllowOnConsole bool
|
||||
LogFile *os.File
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
LogFile *os.File
|
||||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
next Logger
|
||||
}
|
||||
|
||||
|
|
|
|||
|
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here. If the code isn't needed it shouldn't be left here. If the commented out code is still needed there should be some justification for it still being here.
Okay. Will remove the unnecessary code Okay. Will remove the unnecessary code
As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all. As fields are optional, it is better to either have them as the last argument or not have them in the argument list at all.
I would in fact also maintain an internal data structure to store Fields that is cleared only after the log operation passes through the entire chain. You can then add a `WithFields(...)` method that wraps around `logrus.WithFields(...)`.
I have created [this sample code](https://play.golang.org/p/RILTxcZtT2w) for reference. The sample code also shows how formatted strings are corresponding args can be passed and we can wrap around `logrus.Logf(...)` for that.
Refactor to Refactor to `LogFile` as it is a pointer to os.File and not string.
Done Done
Done Done
|
||||
|
|
@ -2,7 +2,6 @@ package elektronLogging
|
|||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
|
||||
import (
|
||||
log "github.com/sirupsen/logrus"
|
||||
elekEnv "github.com/spdfg/elektron/environment"
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
"gopkg.in/yaml.v2"
|
||||
"io/ioutil"
|
||||
)
|
||||
|
|
@ -48,9 +47,9 @@ type LoggerConfig struct {
|
|||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
Format []string `yaml:"format"`
|
||||
}
|
||||
|
||||
func (c *LoggerConfig) GetConfig() *LoggerConfig {
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
func (c *LoggerConfig) GetConfig(logConfigFilename string) *LoggerConfig {
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
|
||||
yamlFile, err := ioutil.ReadFile(elekEnv.LogConfigYaml)
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
yamlFile, err := ioutil.ReadFile(logConfigFilename)
|
||||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
if err != nil {
|
||||
log.Printf("Error in reading yaml file #%v ", err)
|
||||
}
|
||||
|
|
|
|||
|
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
Are column headers being added if enabled? Are column headers being added if enabled?
Refactor to TaskDistrConfig for semantics. Refactor to TaskDistrConfig for semantics.
ditto. ditto.
The error message does not do justice in indicating the reason for the error. The error message does not do justice in indicating the reason for the error.
ditto. ditto.
That was for future purpose. But I have removed it now That was for future purpose. But I have removed it now
Done Done
Done Done
Changed the error message Changed the error message
Done Done
|
||||
|
|
@ -26,5 +26,3 @@ var RaplPassword = "RAPL_PSSWD"
|
|||
|
||||
// Location of the script that sets the powercap value for a host.
|
||||
var RaplThrottleScriptLocation = "RAPL_PKG_THROTTLE_SCRIPT_LOCATION"
|
||||
|
||||
var LogConfigYaml = "logConfig.yaml"
|
||||
|
|
|
|||
|
|
@ -55,6 +55,7 @@ var fixFirstSchedPol = flag.String("fixFirstSchedPol", "", "Name of the scheduli
|
|||
var fixSchedWindow = flag.Bool("fixSchedWindow", false, "Fix the size of the scheduling window that every deployed scheduling policy should schedule, provided switching is enabled.")
|
||||
var schedWindowSize = flag.Int("schedWindowSize", 200, "Size of the scheduling window if fixSchedWindow is set.")
|
||||
var schedPolSwitchCriteria = flag.String("schedPolSwitchCriteria", "taskDist", "Scheduling policy switching criteria.")
|
||||
var logConfigFilename = flag.String("logConfigFilename", "logConfig.yaml", "Log Configuration file name")
|
||||
|
||||
// Short hand args
|
||||
func init() {
|
||||
|
|
@ -76,6 +77,7 @@ func init() {
|
|||
flag.BoolVar(fixSchedWindow, "fixSw", false, "Fix the size of the scheduling window that every deployed scheduling policy should schedule, provided switching is enabled (shorthand).")
|
||||
|
change the shorthand to change the shorthand to `logCfg`
Done Done
|
||||
flag.IntVar(schedWindowSize, "swSize", 200, "Size of the scheduling window if fixSchedWindow is set (shorthand).")
|
||||
flag.StringVar(schedPolSwitchCriteria, "spsCriteria", "taskDist", "Scheduling policy switching criteria (shorthand).")
|
||||
flag.StringVar(logConfigFilename, "lgConfigName", "logConfig.yaml", "Log Configuration file name (shorthand).")
|
||||
}
|
||||
|
||||
func listAllSchedulingPolicies() {
|
||||
|
|
@ -223,7 +225,7 @@ func main() {
|
|||
if strings.Contains(*pcplogPrefix, "/") {
|
||||
log.Fatal("log file prefix should not contain '/'.")
|
||||
}
|
||||
elekLog.BuildLogger(*pcplogPrefix)
|
||||
elekLog.BuildLogger(*pcplogPrefix, *logConfigFilename)
|
||||
|
||||
// Starting PCP logging.
|
||||
if noPowercap {
|
||||
|
|
|
|||
Logger and Log are synonyms and therefore should not be used interchangeably.