-
Notifications
You must be signed in to change notification settings - Fork 1
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
Scheduled Confiugurations #1
base: master
Are you sure you want to change the base?
Conversation
created schedulermgrd and schedulermgr files
Fixed minor and return task_process_status Added systemd infrastructure functions to reload and update Removed options for schedulermgrd application
- Fixed bug where endtime was used for enable cronjob - Fixed bug where EOL was not added to crontab file, causing cron to not be able to read the file - Removed extra c in writeContabFile() funcname - Removed unnecessary scheduledConfigurationTable in schedulermgr - Changed type of m_stateTimeRangeStatusTable from ProducerStateTable to Table in order for set command to work correctly - Formatted code
Forgot an ending quote when adding a runOnce==true boolean
Switching to ";" allows the configuration to be deleted after a "runOnce" whether or not the configuration changes succeed or not.
{ | ||
// Removing quotes from primitive types to match the expected format | ||
string value = item.value().dump(); | ||
if (value.front() == '"' && value.back() == '"') |
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.
extract to utility function, reuse in join
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.
same as schedulermgr.cpp, which one do you want to review?
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.
timerangemgr.cpp is the current name. Need to remove schedulermgr.cpp.
} | ||
|
||
// Create systemd files for time range and enable them | ||
// TODO sanitize inputs |
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, verify time ranges validity.
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.
Need to strictly validate and sanitize time range since this can be a security vulnerability since we are running cron commands as root (albeit only in swss container).
// TODO sanitize inputs | ||
if (task_process_status::task_need_retry == createCronjobs(rangeName, start, end, (runOnce == "true"))) | ||
{ | ||
return task_process_status::task_need_retry; |
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 if succeeded in creating one file but failed on the second?
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.
Will implement a rollback mechanism in case of OS and possibly a validation errors.
using namespace swss; | ||
|
||
/* SELECT() function timeout retry time, in millisecond */ | ||
#define SELECT_TIMEOUT 1000 |
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.
why do we need to "wake up" every second?
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 timeout will end up calling the doTask() function again with all the consumables still in the queue. This is usually used for "retrying" tasks that did not succeed the first time, but select will not return because no changes have been made to the DB to trigger it again.
cfgmgr/timerangemgrd.cpp
Outdated
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 was expecting somewhere in this file to "receive" events from cron, if not - how does enable/disable (active/inactive) status is updated? by polling?
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.
timerangemgrd does not receive events from cron, it writes the cron files. It receives the time ranges from the user, and cron will activate/deactivate the ranges by writing to the STATE_DB. Scheduledconfigmgrd then receives an event from redis that a change has occured.
Also clean up code, and began validation of cron syntax
- Added 3 new files to help with cron validation & time checking. Leaning to use croncpp.h and removing cronhelper.cpp ands cronhelper.h - Added check that scheduled configuration does not already exist when adding a scheduled configuration - Automatically apply scheduled configuration if time range is currently active - Save scheduled configurations in "unboundConfiguration" hashmap when time range is deleted - Check if scheduled configurations saved in "unboundConfiguration" hashmap should be bound to newly created time range, and then add it to that new time range if applicable - Added if statement to not process time range/scheduled configuration if an invalid field is found in the asssociated table - Implemented DEL operation processing for scheduled configuration and time range deletion - New function "isTimeRangeActive()" in scheduledconfigmgr.cpp to check TIME_RANGE_STATUS table if the time range is active according to the field - New function "is_time_in_range()" that uses the croncpp.h file in order to test if the local time is within the scheduled time range interval -- NOT TESTED - Implemented DEL operation for when time range key is deleted from CONFIG_DB
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.
Wouldn't it be better to have the implementations in .cpp file
cfgmgr/croncpp.h
Outdated
static const cron_int CRON_MAX_YEARS_DIFF = 4; | ||
|
||
#ifdef CRONCPP_IS_CPP17 | ||
static const inline std::vector<std::string> DAYS = { "SUN", "MON", "TUE", "WED", "THU", "FRI", "SAT" }; |
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.
Wouldn't it be easier (maybe better) to define DAYS and MONTHS as enums have have replace_ordinals be a bit smarter? What is the benefit of doing it this way?
also, these (and a few more) types/functions can be defined in a "more global" scope, so you won't have to define them twice
inline std::tm to_tm(CRONCPP_STRING_VIEW time) | ||
{ | ||
std::tm result; | ||
#if __cplusplus > 201103L |
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 is the purpose of these compiler version checks? isn't it simpler to write to the currently supported compiler
bool is_time_in_range(const cronexpr& startExpr, const cronexpr& endExpr, const std::tm& currentTM) { | ||
std::time_t currentTime = mktime(const_cast<tm*>(¤tTM)); // Convert currentTM to time_t | ||
time_t previousMinute = currentTime - 60; // Go back one minute to ensure full coverage | ||
|
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.
Doesn't this add risk of getting an "event" for something that you already activate here? do you handle such case?
- Added license to croncpp.h - Removed static qualifier from replace_ordinals() in croncpp.h - Done in order to remove warning saying this function isn't used - change "enabled" and "disabled" to "active" and "inactive" respectively
- Changed DB to use a nested unordered_map instead of a vector of pairs - Surrounded replace_ordinals() in croncpp.h to remove unused fxn warning - Surrounded make_cron() usage with try-catch
Will now correctly add and remove configurations when time range becomes active/inactive. Time range status will be updated to active immediately if the current time is within the newly set time range. Added internal database to keep track of active/inactive scheduled configurations in case of delete.
Phase two first implementation is complete, but needs debugging since ACL table is not being configured as expected.
This phase implements the ability to add to the CONFIG_DB a TIME_RANGE table. Once this configuration is sent, the schedulermgrd will pick up the changes, and call schedulermgr. This process will parse the interval, and create cron files under /etc/cron.d/ within the swss container. It will also create a default TIME_RANGE_STATUS_TABLE entry with the time range name, and give it the default field-value of "status": disabled.
To configure you may use this template json file:
{ "TIME_RANGE": { "rangeTest": { "start": "*/2 * * * *", "end": "1-59/2 * * * *" }, "runOnceTest": { "start": "20 * * * *", "end": "21 * * * *", "runOnce": "true" } } }
Then call this command on the json file:
sonic-cfggen -j <json-file-name> --write-to-db
.This will trigger the code found in this PR.
Note this PR also needs changes from two other PRs in other repos. Since this is just phase 1, i decided to wait until both phases are complete before creating all the other PRs