cdist-backup/doc/internal/logs/2010-11-09

181 lines
5.2 KiB
Text
Raw Normal View History

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