a lot of more thoughts

Signed-off-by: Nico Schottelius <nico@kr.ethz.ch>
This commit is contained in:
Nico Schottelius 2010-11-09 22:08:01 -08:00
parent fb3edeaa3d
commit dbffd1404c

View file

@ -41,6 +41,9 @@ 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.
@ -102,3 +105,76 @@ cdist installation / paths:
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