Rethinking ideas of last talk. What if types are formal / have formal arguments? What if cdist can do all the parsing stuff and the real functionality comes out of the library (similar to cfengine)? What if the library is integral part of cdist? conf/lib/$name/ attributes/ a b c -------------------------------------------------------------------------------- I'm not sure whether this design is in fact helpful. But it's clearly necessary to have a directory per type, so a type can have helpers. conf/lib/$name/ init? Prepare some very minimal (non functional) framework for library integration? Like parsing for command line arguments? -------------------------------------------------------------------------------- Real configurations versus types: Types are reusable code: For instance etc_resolv. Configurations are types used and configured. -------------------------------------------------------------------------------- Style __type <id> --option1 <arg1> <id> = everything your filesystem permits, but may not start with a period ("."). If <id> == ., it setups the standard attributes. seems to be quite good usable. cdist can easily -----parse--- this. Nope. We don't parse. We let the shell execute. So whatever is __type will get executed. __type must probably be part of some cdist specific path. Which again could be conf/lib/$name Which could result in the directory conf/lib/.$name for helpers That style could include a mandority --help, --args arguments and would thus be independent of the language used (can, but does not must be shell). How to solve standard configurations that way? EASY AS WELL! __type <either option or magic> --option1 <arg1> for instance __type . --option1 <arg1> -------------------------------------------------------------------------------- Type paths At least (at maximum)? 2: user + system Easy to do. -------------------------------------------------------------------------------- Types: Name types types or name types modules? -------------------------------------------------------------------------------- Where to place/start the configuration? wherever it is: name it configuration! -------------------------------------------------------------------------------- cdist installation / paths: /etc/cdist/ # CDISTBASEDIR config/ # CDISTCONFIGDIR types/ # CDISTUSERTYPEDIR $prefix/lib/cdist/types/ # CDISTSYSTYPEDIR cdist environment: $__loaded_from # path where $type has been loaded from PATH=$CDISTUSERTYPEDIR:$CDISTSYSTYPEDIR:$PATH -------------------------------------------------------------------------------- Recommendation (not a must): Put helpers for types into the typedir/.$typename All types should be prefixed by "__" to prevent clashes with the system binaries. -------------------------------------------------------------------------------- Type commands (__bla) could get generated by cdist and cdist could use that to generate the actual cconfig part. This leads up to the next section -------------------------------------------------------------------------------- How to write my own type named "coffee": Create the directory /etc/cdist/types/coffee/ Create the file /etc/cdist/types/coffee/README containing a description of the type. If your type supports attributes, create the directory /etc/cdist/types/coffee/attributes. For each attribute, create the file /etc/cdist/types/coffee/attributes/$attribute_name which contains a short description on the first line then a blank line then a long description (probably over several lines) If you think your type may be useful for others, submit it for inclusion into cdist at cdist -- at -- l.schottelius.org. Create /etc/cdist/types/coffee/init which reads $configinput (either via cconfig or via environment) and outputs a block of shell code suitable for running on the client. -------------------------------------------------------------------------------- cdist exec steps: - check for valid types, abort if user (re-)defined system types - generate __type binaries (aliases?), which contains cdist logic to analyse types and check for correct arguments - execute /etc/cdist/config/init (MAIN CONFIG) which in turn calls __type binaries - __type binaries (which are all the same, multicall!) generate cconfig - Run real type/init binaries with respective cconfig dir as path, which must generate shellcode to be executed. - Create the temporary shellscript containing all the code and execute it on the client. -------------------------------------------------------------------------------- Support metaargs like --depends? If so, they need to be forbidden for types. -------------------------------------------------------------------------------- Shell code generator: - use subshells for each shellcodeblock - create one main function (to ensure transfer is complete) Example: cdist_apply_$hostname() { # repeat this block for every type/id defined echo "Executing block from $type_$id ..." ( code ) } cdist_apply_$hostname