Matt,

I just read this one again. I have a comment: since the [, ] characters (or
whatever 'open/close' symbols you use) dont match up, things seem wierd.
When I say dont match up, I mean in the "the number of opens != number of
closes" which is counter intuitive in some way, and feels unnatural:

/[country/China/]group/cpu/]metric/number

Of course I have a computer scientist's bias, I admit to that. However, I
suggest a simpler notation, like that of ldap:

/Country=China/group=cpu/metric=number

You could have the outer space class names capitalized, while the inner
space class names are all lowercase.

Does this seem cleaner?

-Federico
----- Original Message -----
From: "Matt Massie" <[EMAIL PROTECTED]>
To: "Ganglia Developers" <ganglia-developers@lists.sourceforge.net>
Sent: Thursday, October 14, 2004 3:09 PM
Subject: [Ganglia-developers] ganglia 3.0.0. ramble

guys-

i thought i'd take the time to explain how i envision the filesystem
namespace working for gangliad.  feedback is welcome.

there really are two general spaces that gangliad needs to merge in a
logical way.. call it outer space and inner space... everything has both
(even an electron has inner space).  it reminds me a lot of fractals but
that's another discussion all together.

so we have a host somewhere in the world that we want to monitor.  we
need to be able to find it.  DNS helps us with that.  it is an outer
space tool.  mm01.millennium.berkeley.edu tells me that a host is
1. at an educational institution.. 2. UC Berkeley  3. a computer science
project at Berkeley 4. "mm01" is the name of this host.

there should be a way for many outer spaces to point to the same host.
DNS does that too.  you have lots of names for the same computer.  i'm
not looking for ganglia to replace DNS (for now) but outspace needs to
be more flexible.

there is also an inner space.  once we find the "thing" (host/network
hardware etc) in the world, we need to be able to peak inside it to
learn about what going on inside.  this inner space should be
standardized so that no matter what i want to know.. i can get the
answer even though i'm looking inside different "things".

one of the assumptions i'm making is that we are monitoring a near
symmetric inner space on every thing connected in outer space.  we, for
example, want to know the number of cpus of everything, the total
memory, etc.

.........

the file system will have the following rules.  you can name "things"
anything you want as long as the first letter of the name is
alpha-numeric and doesn't contain a '/' since that is the filesystem
delimiter.  "My Cluster" ok.  ".My Grid" is not.

for the filesystem, all outer space classes start with "[".  for example

"[country"
"[state"
"[county"
"[cluster"
"[grid"

you can create any number of outer space classes that you need/like.
the sky is the limit. (seriously.. the sky is the limit of outer space)

for the filesystem all inner space classes start with "]".  for example

"]group"
"]metric"

so the order of the path is class then instance, class then instance,
class then instance...

for example,  here is the path for the number of processors in china

/[country/China/]group/cpu/]metric/number

of the number of processors for a particular state in the united states

/[country/United States/[state/California/]group/cpu/]metric/number

of the number of processor for a particular host

/[state/California/[school/Berkeley/[host/mm04/]group/cpu/]metric/number

or something like that.

we can also add the time dimension here as well with time variables

/[state/CA/[school/UCLA/]group/cpu/]metric/number?at=1097791459
/[state/CA/[school/UCLA/]group/cpu/]metric/number?from=1097791459&amp;to=109
77933493

or something like that.

given the structure of gangliad, we have servers attaching to a common
in-memory content tree, we can have format modules that export the
content tree in different formats (LDIF, XML, S-expressions, etc).

i'll show you this space in action with mod_ganglia2_xml and
mod_ganglia2_xdr soon.

-matt

--
PGP fingerprint 'A7C2 3C2F 8445 AD3C 135E F40B 242A 5984 ACBC 91D3'


Reply via email to