Anshu Kumar: ansharyan015
Officially started off with the work on 21st May. This week was mostly spent in making the regex_policy plugin dynamic. Although the plan in the proposal was a bit different and the task allotted for first week was filtered_replicator plugin, Daniel and I sorted out the plugins in the increasing order of their difficulties and hence regex_policy plugin.
Here is my first weekly report for GSoC ’12
Regex_policy
I started off with regex_policy plugin as it seems to be the most trivial one. This plugin uses regex based authorization to match policies given in the policy file. As was pointed out by Daniel, the plugin was fundamentally designed to be static and the hack to make it dynamic was supposed to be not too complex in order to avoid future confusions, this required writing new code as well as redesigning the existing code.
Work Done: The regex_policy plugin specifies a file which either is given by the user at the time of startup of server or if not specified, a default file is used. The work was to give user the facility to dynamically change the policy file on runtime so that all the policies in the system will be reloaded with the policies given in the new file. Few approaches which were tried to accomplish this were
- A lock variable (say regex_policy_autoreload) was used. Whenever user needs to change the policy file, he will have to explicitly make this lock as true and then the policy file will be refreshed every minute. This lacked the functionality of change of policy file. Also it involved some other critical issues like “what if user is still editing the file after a minute”.
- After the failure of previous idea, the autoreload variable was removed and was changed to a variable reload (i.e. regex_policy_reload). The flow was to first set the regex_policy_reload to true and then change the policy file at runtime (i.e. SET GLOBAL regex_policy_policy = “path/to/new/policy/file”). After reloading the policies, the reload variable was changed to false automatically to show that the policies have been refreshed. This use of a second variable was redundant as anyone who wants to change the policy file can change the reload variable as well (hence no real kind of lock). This was removed in the next version.
- After both the earlier approaches proved to be non optimal, finally refresh functionally was directly put into for regex_policy_policy variable and now policy file can be changed at runtime by using SET GLOBAL regex_policy_policy = “path/to/new/policy/file” or can be reloaded using SET GLOBAL regex_policy_policy = @@regex_policy_policy.
Difficulties faced: The main problem that am facing is the type of policy file in Policy class is boost file system path and there isn’t any such data type for database variables. Although this can be explicitly cast to std::string (after fs::path::string() doesn’t seems to work) but these are purely unrelated types and this may cause problems as there may be some internal fs::path methods which are being called and cannot be used with std::string. Daniel and I are still working on this to make sure this doesn’t come up in future.
URL: http://anshsays.wordpress.com/2012/05/30/weekly-report-1/
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : drizzle-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
