1 |
On Wed, 2009-05-13 at 16:40 +0100, Sérgio Almeida wrote: |
2 |
|
3 |
> > This .uselect |
4 |
> > should not contain symlinks, but plain (text?) files only. |
5 |
|
6 |
> Do we really need more than one file? |
7 |
|
8 |
No, at least not to define the _values_ of a profile. |
9 |
|
10 |
> Checklist: |
11 |
> * Hostname |
12 |
> * Uname |
13 |
> * {$chost} |
14 |
> |
15 |
> Mmm... Maybe we can simplify this with a parameter like: |
16 |
> |
17 |
> # eval something |
18 |
> eval "hostname" "superhost" |
19 |
> what |
20 |
> to |
21 |
> do |
22 |
> # end something |
23 |
> |
24 |
> Then if command "hostname" outputs "superhost" we know "what-to-do". |
25 |
|
26 |
Eventually, we should pass something like "-Dhostname=superhost" as |
27 |
cmdline parameter to uselect... |
28 |
|
29 |
> |
30 |
> This way it would get ultra versatile. |
31 |
> |
32 |
> > What if there is some hierarchy in .uselect/ much like the profiles in |
33 |
> > gentoo-x86 tree, using some kind of 'parent' files to inherit/override |
34 |
> > settings for this one project, where 'parent' can contain something like |
35 |
> > $(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)? |
36 |
> > |
37 |
> |
38 |
> Would this really be necessary? We can define hierarchy into a |
39 |
> single .uselect file. Even the use of folders (folder .uselect/) isn't |
40 |
> necessary. I think a single file can handle all this... |
41 |
|
42 |
Eventually yes. |
43 |
|
44 |
> Lets see an |
45 |
> example: |
46 |
> |
47 |
> # profile something |
48 |
|
49 |
I don't like to have anything interpreted after the usual and well-known |
50 |
comment-marker, this just feels hackish. |
51 |
|
52 |
> |
53 |
> do this 3 <- override the overridden =) |
54 |
|
55 |
> The actions to be done like "do this 3" are a simple call to uselect |
56 |
> using module "do" and action "this" with "3" as parameters. |
57 |
|
58 |
fine. |
59 |
|
60 |
I do have something like this content-syntax in mind for .uselect (or |
61 |
eventually some .uprofile) file: |
62 |
|
63 |
8<8<8< |
64 |
version "0.1" |
65 |
|
66 |
include "path/to/another/uselect/file" |
67 |
|
68 |
profile "generic solaris" { |
69 |
module A actionAX "valueAX1" "valueAX2" |
70 |
module B actionBX "valueBX1" "valueBX2 |
71 |
} |
72 |
|
73 |
profile "generic host" { |
74 |
module C actionCX "valueCX1" |
75 |
} |
76 |
|
77 |
profile "superhost" { |
78 |
inherit profile "generic solaris" |
79 |
inherit profile "generic host" |
80 |
module C actionCX "newvalueCX1" |
81 |
module A actionAX "newvalueAX1" "newvalueAX2" |
82 |
module D actionDY "valueBY1" "valueBY2" |
83 |
} |
84 |
|
85 |
profile "generic user" { |
86 |
module E actionEX "valueEX1" |
87 |
} |
88 |
|
89 |
profile "user haubi" { |
90 |
inherit profile "generic user" |
91 |
module F actionFX "valueFX1" |
92 |
} |
93 |
|
94 |
profile "any user on superhost" { |
95 |
module G actionGX "valueGX1" |
96 |
} |
97 |
|
98 |
profile "fallback host" { |
99 |
inherit profile "generic host" |
100 |
module A actionAX "valueAX1" "valueAX2" |
101 |
} |
102 |
|
103 |
activation "superhost activation" { |
104 |
in category "host" |
105 |
on fallback level 0 |
106 |
when $hostname matches string "superhost" |
107 |
activate profile "superhost" |
108 |
} |
109 |
|
110 |
activation "haubi on superhost" { |
111 |
in category "user" |
112 |
on fallback level 0 |
113 |
when $username matches string "haubi" |
114 |
when $hostname matches string "superhost" |
115 |
activate profile "any user on superhost" |
116 |
activate profile "user haubi" |
117 |
} |
118 |
|
119 |
activation "haubi" { |
120 |
in category "user" |
121 |
on fallback level 1 |
122 |
when $username matches string "haubi" |
123 |
activate profile "user haubi" |
124 |
} |
125 |
|
126 |
activation "gentoo host" { |
127 |
in category "host" |
128 |
on fallback level 1 |
129 |
when $hostname matches regex ".*\.gentoo\.org" |
130 |
activate profile "fallback host" |
131 |
} |
132 |
>8>8>8 |
133 |
|
134 |
I'm not sure to have an ascending "fallback level" or descending |
135 |
"priority" value, but both should allow for negative integer values. |
136 |
|
137 |
The selection of one or more profiles is controlled by "activation" |
138 |
entries, independent for each "category". The order and selection of |
139 |
categories is done via a commandline argument, fex "--categories". |
140 |
|
141 |
Profiles are selected when all of the "when" entries (besides "category" |
142 |
and "fallback level") in "activation {}" do match. |
143 |
Selected are *all* of the matching profiles in the *lowest* "fallback |
144 |
level" *only*, which does have at least one matching profile. |
145 |
|
146 |
And I'm thinking of something like this commandline: |
147 |
$ uselect \ |
148 |
--categories host,user \ |
149 |
--define hostname=`hostname` \ |
150 |
--define username=`whoami` |
151 |
|
152 |
> |
153 |
> Remember that profile creation/storing/managing should be automatic and |
154 |
> nothing would need to be written by hand. |
155 |
|
156 |
Yes, would be fine. When using something like above configuration file |
157 |
syntax, some GUIding tool would be useful, at least to see which |
158 |
profiles are selected for specific cmdline args. |
159 |
|
160 |
> By other words, create a basic |
161 |
> profile automatically using your currently running settings and then |
162 |
> alter the profile with the util to add constrains to it. |
163 |
|
164 |
Sounds interesting... |
165 |
|
166 |
> Remember that |
167 |
> all the machines that this profile is read would need to have the same |
168 |
> uselect modules into it's /usr/share/uselect/modules or similar. |
169 |
|
170 |
Indeed, yes. |
171 |
|
172 |
> > Ha! This kind of inheritance tree could be a solution for my long |
173 |
> > standing bug here to simplify our way too complex environment script... |
174 |
> > |
175 |
> |
176 |
> This is a basic idea from softenv so it has has it's place into uselect. |
177 |
|
178 |
Don't know softenv. Found http://www.teragrid.org/userinfo/softenv/ |
179 |
Do you mean this one? |
180 |
|
181 |
> The question now is, bloat it all into uselect or create a uprofile |
182 |
> util? I like the idea of having to use only uselect for basic profiling |
183 |
> and using uprofile for further managing. |
184 |
|
185 |
That's indeed the question. |
186 |
|
187 |
> Mmmm... As you wrote I realized: Complain if module versions are |
188 |
> different is not a bad idea at all... |
189 |
|
190 |
Indeed, not only the configuration needs to be versioned, but the |
191 |
modules too. |
192 |
|
193 |
> |
194 |
> Why would we need more that one profile file per project/folder anyway? |
195 |
|
196 |
Might not be necessary, at least not for non-profiled uselect. |
197 |
|
198 |
> > Uh, so many strange ideas! |
199 |
> > More of them? |
200 |
> |
201 |
> Keep 'em coming! Thanks! |
202 |
|
203 |
Well, you have asked ;) |
204 |
|
205 |
/haubi/ |