-
Notifications
You must be signed in to change notification settings - Fork 531
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
Refactor Orch class to separate recorder implementation #2837
Conversation
…iables Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
tagging @qiluo-msft, @yxieca |
extern ofstream gRecordOfs; | ||
extern bool gLogRotate; | ||
extern string gRecordFile; | ||
int gBatchSize = 0; |
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.
I see you move the definition of this global variable from main.cpp to orch.cpp. Is it really necessary? #Closed
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.
Yes, if not every daemon that inherits from Orch should define this.
None of the cfgmgrs require the use of gBatchSize var, so it is defined as zero. Only orchagent needs to updated this and thus it is linked with "extern" and update in main.cpp
lib/recorder.h
Outdated
bool enable_rec; | ||
bool log_rotate; | ||
std::string location; | ||
std::string filename; |
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.
lib/recorder.h
Outdated
std::string getName() { return m_name; } | ||
|
||
private: | ||
bool enable_rec; |
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.
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.
m_name is just the user readable name of the type of recorder. "SwSS", "Response Publisher" & "SaiRedis". Used while printing the logs
Eg:
SWSS_LOG_NOTICE("%s Recorder: Recording started at %s", getName().c_str(), fname.c_str());
Jun 23 19:26:15.741815 sonic NOTICE swss#orchagent: :- startRec: SwSS Recorder: Recording started at /var/log/swss/swss.rec
class SaiRedisRec : public RecBase { | ||
public: | ||
SaiRedisRec(); | ||
}; |
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.
All 3 classes share the same interfaces. They fit better into 3 objects of class RecWriter. #WontFix
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.
And that's why we have a Recorder interface to access these
/* Interface to access recorder classes */
class Recorder {
public:
static std::unique_ptr<SwSSRec> swss;
static std::unique_ptr<SaiRedisRec> sairedis;
static std::unique_ptr<ResPubRec> respub;
};
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.
The proposal "3 objects of class RecWriter" allow you to the same thing.
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.
Having 3 separate interfaces is flexible since we can easily extend the functionality for any one of these separately, if required.
lib/recorder.h
Outdated
|
||
class RecBase { | ||
public: | ||
RecBase() {} |
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.
use default keyword {}
lib/recorder.h
Outdated
static std::unique_ptr<SwSSRec> swss; | ||
static std::unique_ptr<SaiRedisRec> sairedis; | ||
static std::unique_ptr<ResPubRec> respub; |
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.
i would prefer to not have those static objects
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.
What would you recommend? The only other option i could think of is to define a singleton of Recorder and have these as public member objects.
But to access the singleton everytime, we might need to define a method like getInstance() and use it to access the object and their methods, kinds like the logger class under swsscomon
Eg: Recorder::getInstance().swss.startRec()
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.
you dont need actually singleton, just a instance of recorder in Orch class, if you have more static members, its harder to test
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.
Defining recorder instance as a member of Orch class will not work. There are multiple orch classes and all write to a same file.
So, logically the scope of recorder is the daemon/process and not just orch. Even if we can workaround with using an instance of the recorder class per orch, we would still need static members for handing ofstream, path etc.
Best case scenario is one static Recorder instance and using it as singleton.
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.
ok
orchagent/orch.h
Outdated
@@ -216,7 +220,7 @@ class Orch | |||
Orch(swss::DBConnector *db, const std::vector<std::string> &tableNames); | |||
Orch(swss::DBConnector *db, const std::vector<table_name_with_pri_t> &tableNameWithPri); | |||
Orch(const std::vector<TableConnector>& tables); | |||
virtual ~Orch(); | |||
virtual ~Orch() {}; |
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.
use default keyword
Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
/azpw run Azure.sonic-swss |
/AzurePipelines run Azure.sonic-swss |
Azure Pipelines successfully started running 1 pipeline(s). |
@kcudnik , @qiluo-msft . I've handled your comments. Please check |
/azpw run Azure.sonic-swss |
/AzurePipelines run Azure.sonic-swss |
Azure Pipelines successfully started running 1 pipeline(s). |
@qiluo-msft @kcudnik could you please help to review following comments? |
@qiluo-msft Can you please review and signoff? |
**What I did** 1) Removed the recorder implementation from the Orch class and added a new Recorder Interface 2) Removed the exposure of recorder related global variables from the CfgMgrs and Orchagent 3) Writing the Kfv tuple to the Rec file was moved from the Orch class into the ConsumerBase 4) Moved the gBatchSize declaration into the Orch and thereby removing the need to explicitly declare the global variable in CfgMgrs **Why I did it** Recorder implementation should not be tied to Orchagent **How I verified it** Install the swss on the switch and verified ``` root@r-lionfish-16:/home/admin# show logging | grep Recorder Jun 23 19:26:15.741815 sonic NOTICE swss#orchagent: :- startRec: SwSS Recorder: Recording started at /var/log/swss/swss.rec Jun 23 19:29:09.514177 sonic INFO swss#orchagent: :- logfileReopen: SwSS Recorder: LogRotate request handled ``` **Verify Logrotate:** ``` root@r-lionfish-16:/home/admin# ls -l /var/log/swss/ total 2752 -rw-r--r-- 1 root root 999877 Jun 23 19:26 sairedis.rec -rw-r--r-- 1 root root 1559947 Jun 23 19:11 sairedis.rec.1 -rw-r--r-- 1 root root 110563 Jun 23 19:27 swss.rec -rw-r--r-- 1 root root 141713 Jun 23 19:16 swss.rec.1 root@r-lionfish-16:/home/admin# logrotate -f /etc/logrotate.conf (Force Logrotate) root@r-lionfish-16:/home/admin# ls -l /var/log/swss/ total 1232 -rw-r--r-- 1 root root 140 Jun 23 19:28 sairedis.rec -rw-r--r-- 1 root root 999877 Jun 23 19:26 sairedis.rec.1 -rw-r--r-- 1 root root 126798 Jun 23 19:11 sairedis.rec.2.gz -rw-r--r-- 1 root root 0 Jun 23 19:28 swss.rec -rw-r--r-- 1 root root 110563 Jun 23 19:27 swss.rec.1 -rw-r--r-- 1 root root 13089 Jun 23 19:16 swss.rec.2.gz <After some time> root@r-lionfish-16:/home/admin# ls -l /var/log/swss/ total 1476 -rw-r--r-- 1 root root 242404 Jun 23 19:29 sairedis.rec -rw-r--r-- 1 root root 999877 Jun 23 19:26 sairedis.rec.1 -rw-r--r-- 1 root root 126798 Jun 23 19:11 sairedis.rec.2.gz -rw-r--r-- 1 root root 1764 Jun 23 19:29 swss.rec -rw-r--r-- 1 root root 110645 Jun 23 19:29 swss.rec.1 -rw-r--r-- 1 root root 13089 Jun 23 19:16 swss.rec.2.gz ```
**What I did** 1) Removed the recorder implementation from the Orch class and added a new Recorder Interface 2) Removed the exposure of recorder related global variables from the CfgMgrs and Orchagent 3) Writing the Kfv tuple to the Rec file was moved from the Orch class into the ConsumerBase 4) Moved the gBatchSize declaration into the Orch and thereby removing the need to explicitly declare the global variable in CfgMgrs **Why I did it** Recorder implementation should not be tied to Orchagent **How I verified it** Install the swss on the switch and verified ``` root@r-lionfish-16:/home/admin# show logging | grep Recorder Jun 23 19:26:15.741815 sonic NOTICE swss#orchagent: :- startRec: SwSS Recorder: Recording started at /var/log/swss/swss.rec Jun 23 19:29:09.514177 sonic INFO swss#orchagent: :- logfileReopen: SwSS Recorder: LogRotate request handled ``` **Verify Logrotate:** ``` root@r-lionfish-16:/home/admin# ls -l /var/log/swss/ total 2752 -rw-r--r-- 1 root root 999877 Jun 23 19:26 sairedis.rec -rw-r--r-- 1 root root 1559947 Jun 23 19:11 sairedis.rec.1 -rw-r--r-- 1 root root 110563 Jun 23 19:27 swss.rec -rw-r--r-- 1 root root 141713 Jun 23 19:16 swss.rec.1 root@r-lionfish-16:/home/admin# logrotate -f /etc/logrotate.conf (Force Logrotate) root@r-lionfish-16:/home/admin# ls -l /var/log/swss/ total 1232 -rw-r--r-- 1 root root 140 Jun 23 19:28 sairedis.rec -rw-r--r-- 1 root root 999877 Jun 23 19:26 sairedis.rec.1 -rw-r--r-- 1 root root 126798 Jun 23 19:11 sairedis.rec.2.gz -rw-r--r-- 1 root root 0 Jun 23 19:28 swss.rec -rw-r--r-- 1 root root 110563 Jun 23 19:27 swss.rec.1 -rw-r--r-- 1 root root 13089 Jun 23 19:16 swss.rec.2.gz <After some time> root@r-lionfish-16:/home/admin# ls -l /var/log/swss/ total 1476 -rw-r--r-- 1 root root 242404 Jun 23 19:29 sairedis.rec -rw-r--r-- 1 root root 999877 Jun 23 19:26 sairedis.rec.1 -rw-r--r-- 1 root root 126798 Jun 23 19:11 sairedis.rec.2.gz -rw-r--r-- 1 root root 1764 Jun 23 19:29 swss.rec -rw-r--r-- 1 root root 110645 Jun 23 19:29 swss.rec.1 -rw-r--r-- 1 root root 13089 Jun 23 19:16 swss.rec.2.gz ```
What I did
Why I did it
Recorder implementation should not be tied to Orchagent
How I verified it
Install the swss on the switch and verified
Verify Logrotate:
Details if related