parent
4542ee5735
commit
20a7967332
@ -0,0 +1,101 @@ |
||||
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 |
||||
|
||||
|
Loading…
Reference in new issue