Michael, > Eventually, we should pass something like "-Dhostname=superhost" as > cmdline parameter to uselect... >
Didn't want to get into that detail. Afterall `hostname` will always
return the same regarding the host therefore it can be retrieved from
uselect's engine.
> I don't like to have anything interpreted after the usual and well-known
> comment-marker, this just feels hackish.
>
Agreed, it was just an "easy to read" example. Will adopt {} for those.
>
> I do have something like this content-syntax in mind for .uselect (or
> eventually some .uprofile) file:
>
> 8<8<8<
> version "0.1"
>
> include "path/to/another/uselect/file"
>
> profile "generic solaris" {
> module A actionAX "valueAX1" "valueAX2"
> module B actionBX "valueBX1" "valueBX2
> }
>
> profile "generic host" {
> module C actionCX "valueCX1"
> }
>
> profile "superhost" {
> inherit profile "generic solaris"
> inherit profile "generic host"
> module C actionCX "newvalueCX1"
> module A actionAX "newvalueAX1" "newvalueAX2"
> module D actionDY "valueBY1" "valueBY2"
> }
>
> profile "generic user" {
> module E actionEX "valueEX1"
> }
>
> profile "user haubi" {
> inherit profile "generic user"
> module F actionFX "valueFX1"
> }
>
> profile "any user on superhost" {
> module G actionGX "valueGX1"
> }
>
> profile "fallback host" {
> inherit profile "generic host"
> module A actionAX "valueAX1" "valueAX2"
> }
>
> activation "superhost activation" {
> in category "host"
> on fallback level 0
> when $hostname matches string "superhost"
> activate profile "superhost"
> }
>
> activation "haubi on superhost" {
> in category "user"
> on fallback level 0
> when $username matches string "haubi"
> when $hostname matches string "superhost"
> activate profile "any user on superhost"
> activate profile "user haubi"
> }
>
> activation "haubi" {
> in category "user"
> on fallback level 1
> when $username matches string "haubi"
> activate profile "user haubi"
> }
>
> activation "gentoo host" {
> in category "host"
> on fallback level 1
> when $hostname matches regex ".*\.gentoo\.org"
> activate profile "fallback host"
> }
> >8>8>8
>
> I'm not sure to have an ascending "fallback level" or descending
> "priority" value, but both should allow for negative integer values.
>
I'm not quite shure if this hierarchy fallback method is the most
adequate one. Again, remember that the profiles will be automatically
created and manipulation needs to be easy. I guess we can arrange for a
better way of managing this.
> The selection of one or more profiles is controlled by "activation"
> entries, independent for each "category". The order and selection of
> categories is done via a commandline argument, fex "--categories".
>
We are mixing some more complex concepts that don't need to be managed
this way. Let's see.
Types of Profiles:
something.uprofile <- local file profile
.uprofile <- folder profile
/usr/share/uprofiles/*.uprofile <- template profiles
Adding categories to a folder profile is the same as having several file
profiles into that directory and load them on demand. Why specify to
uselect --categories=something when you can "uselelect loadprofile
something" (loads .uselect folder profile first, and then overrides
settings as specified in something.uprofile).
> Profiles are selected when all of the "when" entries (besides "category"
> and "fallback level") in "activation {}" do match.
> Selected are *all* of the matching profiles in the *lowest* "fallback
> level" *only*, which does have at least one matching profile.
>
> And I'm thinking of something like this commandline:
> $ uselect \
> --categories host,user \
> --define hostname=`hostname` \
> --define username=`whoami`
>
> >
> > Remember that profile creation/storing/managing should be automatic and
> > nothing would need to be written by hand.
>
> Yes, would be fine. When using something like above configuration file
> syntax, some GUIding tool would be useful, at least to see which
> profiles are selected for specific cmdline args.
>
Mmm... later feature for more complex profiling. Let us stop now and
focus on simple profiling with easy managing.
> > By other words, create a basic
> > profile automatically using your currently running settings and then
> > alter the profile with the util to add constrains to it.
>
> Sounds interesting...
>
> > Remember that
> > all the machines that this profile is read would need to have the same
> > uselect modules into it's /usr/share/uselect/modules or similar.
>
> Indeed, yes.
>
> > > Ha! This kind of inheritance tree could be a solution for my long
> > > standing bug here to simplify our way too complex environment script...
> > >
> >
> > This is a basic idea from softenv so it has has it's place into uselect.
>
> Don't know softenv. Found http://www.teragrid.org/userinfo/softenv/
> Do you mean this one?
>
Indeed.
> > The question now is, bloat it all into uselect or create a uprofile
> > util? I like the idea of having to use only uselect for basic profiling
> > and using uprofile for further managing.
>
> That's indeed the question.
>
> > Mmmm... As you wrote I realized: Complain if module versions are
> > different is not a bad idea at all...
>
> Indeed, not only the configuration needs to be versioned, but the
> modules too.
>
On to-do!
> >
> > Why would we need more that one profile file per project/folder anyway?
>
> Might not be necessary, at least not for non-profiled uselect.
>
> > > Uh, so many strange ideas!
> > > More of them?
> >
> > Keep 'em coming! Thanks!
>
> Well, you have asked ;)
>
> /haubi/
Thanks again.
Cheers,
Sérgio
--
Sérgio Almeida <meph...@gmail.com>
mephx @ freenode
signature.asc
Description: This is a digitally signed message part
