File: 2011-01-24

package info (click to toggle)
cdist 7.0.0-6
  • links: PTS, VCS
  • area: main
  • in suites: forky
  • size: 9,992 kB
  • sloc: sh: 16,815; python: 9,199; makefile: 344; awk: 261
file content (92 lines) | stat: -rw-r--r-- 2,153 bytes parent folder | download | duplicates (6)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
Steven / Nico

Type:
   - xml/
   
   - parameters/
   - optional_parameters
      me: too long

User interested it type:

   - which arguments are available
   - ls /path/to/type (steven)

Steven / proposal:

   - manifest/gencode: .meta
   - attribute directly in dir

"cdist-help" <type bla>

   - if no direct path


--------------------------------------------------------------------------------

Doc proposal (Nico):

   man cdist-type-<name>

Directory structure:
   "easy to ls -lR and understand what it does"

   ls -lR $(cdist-type-path "typename")/meta/

   ls -lR $(cdist-path type "typename")/meta/
   
--------------------------------------------------------------------------------

What consumes most type?

   - Writing types, because they are functionality
   - Define attributes
      - required/optional

Type documentation

   $type/.meta/required_parameters/path contains
      "Path in which file is created"
--------------------------------------------------------------------------------


Doc of every type:

   - required/optional parameters
   - description

--------------------------------------------------------------------------------

! Validation of type input:

   Not only required/optional parameters:

   - handling of either content/source arguments

   - validate script in type?
   - seperate validation from manifest may be senseful
--------------------------------------------------------------------------------

Explorer per type?

   - helpful or evil?
   - helps to summarise/get information near ressource that needs it
   - emphasises type specific explorers
      -> explorer should be reusable by everybody!
--------------------------------------------------------------------------------
Explorer delivers facts

   - central repo
   - not being able to override 

   - may be helpful to override facts for debugging (i.e. os=redhat)
   - one explorer returns one fact
   - facts via environment variables
   - proposal steven: UPPER_CASE
      - __fact_os (Nico)

   - DEFINE path_to_explorer
   - DEFINE explorer
--------------------------------------------------------------------------------