Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool

[Michael Haubenwallner <haubi@gentoo.org>]

On Wed, 2009-05-13 at 16:40 +0100, Sérgio Almeida wrote:

> > This .uselect 
> > should not contain symlinks, but plain (text?) files only.

> Do we really need more than one file? 

No, at least not to define the _values_ of a profile.

> Checklist:
> * Hostname
> * Uname
> * {$chost}
> 
> Mmm... Maybe we can simplify this with a parameter like:
> 
> # eval something
> eval "hostname" "superhost"
> what
> to
> do
> # end something
> 
> Then if command "hostname" outputs "superhost" we know "what-to-do". 

Eventually, we should pass something like "-Dhostname=superhost" as
cmdline parameter to uselect...

> 
> This way it would get ultra versatile.
> 
> > What if there is some hierarchy in .uselect/ much like the profiles in
> > gentoo-x86 tree, using some kind of 'parent' files to inherit/override
> > settings for this one project, where 'parent' can contain something like
> > $(CHOST), $(UNAME), $(HOSTNAME), $(USERNAME)?
> > 
> 
> Would this really be necessary? We can define hierarchy into a
> single .uselect file. Even the use of folders (folder .uselect/) isn't
> necessary. I think a single file can handle all this... 

Eventually yes.

> Lets see an
> example:
> 
> # profile something

I don't like to have anything interpreted after the usual and well-known
comment-marker, this just feels hackish.

> 
> do this 3 <- override the overridden =)

> The actions to be done like "do this 3" are a simple call to uselect
> using module "do" and action "this" with "3" as parameters.

fine.

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.

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".

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.

>  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?

> 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.

> 
> 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/