[xcat-user] Other potentially controversial xCAT 2.0 changes

[Jarrod B Johnson]

Here is a list of other potentially controversial changes in xCAT 2.0 for
people to digest and comment.  I'm personally in favor of all of them, but
the public should comment.

-The strategy of using a layer over a database instead of flatfiles.  The
layer enables us to change are minds and do powerful things not
representable in a straight SQL database, and even change our minds about
the engine underneath if necessary.  The use of SQL engines to store the
data means much more scalable interaction with the configuration, and easy
programmatic modification of the data.  The abstraction also means that we
have a chance to check any attempted changes for syntax errors before
runtime.  I feel like tabedit, tabdump, and tabrestore provide adequate
facilities to capture the meat of the way tab files have been edited, but
there is a chance to disagree.  I'd debate hard for this thing as far too
many people have come to me with problems because of ^M or the wrong number
of 'ipmi,' in nodehm.tab, and this nicely addresses those common mistakes
(as well as allows my favorite feature, regex-style configuration values
based on nodename).

-Speaking of my favorite feature, the regex-style syntax as I initially
implemented I intend to fix.  Right now if a field in a record indexed by
node looks like /<something>/<something else>/, it's taken as a plain regex
to be performed on the nodename.  In perlspeak, $node =~
s/<something>/<something else>/.  I defined an arithmetic extended syntax
like |<something>|<something else>| that would do regex and allow math
operators (for things like mp table where it might be nice to divide node
number to get MM, and take remainder for slot.  Anyway, I recognize that
the / syntax can end up ambiguous and s/// would be a better delimiter.
The question on my mind is should I forget the distinction between the
arithmetic and non-arithmetic regexes and have a unified syntax where
either s/// or s||| would do the same thing.  Since this is a feature that
can be completely ignored by people who don't like it, I feel it's a safe
enhancement to exist, but the way to describe it could be problematic if it
appears it could collide with a non-regex value.  I can't think of anything
that would be a node attribute that could otherwise look like
s/<something>/<something else>/ or s|<something>|<something else>|, so I
think it's safe.  A path with s/// in it would become a relative path, and
therefore certainly useless since evaluations should be done free of
directory context...

-The client-server behavior.  I believe this is a community-driven request,
and I feel a good job has been done of hiding the client-server nature of
the commands to the point a lot of people without reading never realized
rpower was using a SSL/TCP socket to issue and get data back rather than
talking to service processors directly.  I'm pretty certain this doesn't
represent any problem, but it is a difference that would be nice to hear
something back on.

As of this email, all the fundamental aspects of xCAT 2.0 that I can see as
being potentially controversial/jarring to xCAT 1.x users is out there, but
I'm probably wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.xcat.org/pipermail/xcat-user/attachments/20071109/60b32aae/attachment.htm