Redesign of ARC.CONF Configuration for Improved Functionality
The ARC.CONF configuration file used in NorduGrid's Technical Meeting in June 2016 is undergoing a redesign for better clarity and usability. Proposed changes include restructuring block organization, consistent naming, and dropping ambiguous parameter values. The timeline for rolling out these changes spans from early collection of real-life examples to potential implementation in the next major release. Follow the progress and improvements in the ARC.CONF file for enhanced server-side functionality.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
ARC.CONF: redesign ARC.CONF: redesign NorduGrid Technical meeting, June 2016, Kosice
What is ARC.CONF? What is ARC.CONF? THE server-side configuration file of ARC One shared file for all server-side components & functionality Composed of blocks [common] and sub-blocks [infosys/queue] containing parameters given as variable= value within quotes Described in the sysadmin guide and documented in the arc.conf.reference Grown organically: 437 configuration objects! (block headers & parameters) related stuff) Several attempts in the past to replace it with something else (e.g. xml) Several services use arc.conf to generate other config files Some parameters are inherited from 3rd party software (e.g. X509 31/5/2016 www.nordugrid.org 2
What is wrong with it? What is wrong with it? We noticed sysadmin blindly copying files from each other... Unclear scope of the blocks, confusing block headers, parameters affecting cross-block behaviour Inconsistent, non-intuitive, sometimes contradicting parameter naming Terrible parameter overloading parameter= varA 12, varB 24 Difficult if not impossible to grasp blocks: the famous [vo] block! unclear defaults, mandatory parameters, multivalue options You don t know which block you need to configure for certain service or functionality Syntactical sloopiness: case sensitive or not, order depenent or not... Lots of dead parameters 31/5/2016 www.nordugrid.org 3
Proposed changes Proposed changes Every block and parameter is properly defined in the arc.conf.reference! Drop the around parameter values: variable= value value value Revised block structure. Every major service/interface/functionality defined in its own block. Enabling a service/functionality is DONE via having the corresponding block in the config file Consistent block and parameter naming (resulting in lots of renaming, 157 out of the 437 objects are affected!) Added new blocks and config parameters where it was needed (e.g. in Jura block) DELETED 52 parameters The result: http://svn.nordugrid.org/trac/nordugrid/browser/arc1/branches/arcconf_restr ucturing/src/doc/arc.conf.reference Default value, Mandatory, Multivalued 31/5/2016 www.nordugrid.org 4
Rolling out the changes: timeline Rolling out the changes: timeline The work started more than a year ago with collecting real-life example arc.conf from sites January 2016 F2F meeting at Bodrogi Kuria: reviewed the config parameter by parameter! Couple of skype sessions during spring 2016 to fnalizing the structure, arrive to a frozen arc.conf.reference_NEW Summer, Autumn 2016: start implement the changes... End of 2016 (?) include the new structure in the next major release 31/5/2016 www.nordugrid.org 5
