102 lines
2.4 KiB
Text
102 lines
2.4 KiB
Text
|
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>
|
||
|
|
|
||
|
|
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/ # CDIST_DIR
|
||
|
|
config/ # CONFIGDIR
|
||
|
|
types/ # USERTYPEDIR
|
||
|
|
|
||
|
|
$prefix/lib/cdist/types/ # SYSTYPEDIR
|
||
|
|
|
||
|
|
|