rackview-devel — Development discussion of rackview

[Rackview-devel] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Rackview-devel] new rackview user.

[Fred Z. <fzi...@ll...>]

Hi!
I just installed rackview 0.06, and am having the same issues as Charles
Galpin was having, in his posting to this list on 2003-10-13.

namely:

 I can run rackview.cgi on the command line and it generates a page
 (although I get a bunch of warnings like these).

 [Mon Oct 13 12:32:38 2003] rackview.cgi: Pseudo-hashes are deprecated at
 /usr/lib/perl5/site_perl/5.8.0/Eidetic/Racks.pm line 242, <FH> line 22.

 Running via apache it just hangs for several minutes and I assume killed
 by apache as I get eventually get a "Premature end of script headers"
 error.

 Any ideas about what I'm doing wrong?

Thanks!



-- 
Regards,
Fred

-----
Fred R. Ziegler <fzi...@ll...>     ph:+1-781-981-1708
MIT Lincoln Laboratory                    fx:+1-781-981-5359
244 Wood St.
Lexington, MA 02420-9108
Internet Society Member (#1315080) since Feb 1992

Re: [Rackview-devel] New user with installation problems

[Bryce H. <br...@os...>]

On Mon, 13 Oct 2003, Charles Galpin wrote:
> Hi Bryce (Kees, Marcus, and anyone else out there :)
>
> I've installed rackview, Eidetic and misc dependencies (mostly through
> CPAN) on a red hat 9 system, but I'm having trouble getting the example to
> run. I have it configured to use the data file as a start since it has
> data.
>
> I can run rackview.cgi on the command line and it generates a page
> (although I get a bunch of warnings like these).
>
> [Mon Oct 13 12:32:38 2003] rackview.cgi: Pseudo-hashes are deprecated at
> /usr/lib/perl5/site_perl/5.8.0/Eidetic/Racks.pm line 242, <FH> line 22.

Hmm, I wonder if this is a change in Perl.  What version are you using?
The line in question is:

        $self->{"_$field"} = $value;

Is this a warning or an error?

> Running via apache it just hangs for several minutes and I assume killed
> by apache as I get eventually get a "Premature end of script headers"
> error.

Here's a couple diagnostic tricks.  First, /var/log/httpd/error.log or
similar is your friend.  I will always do a tail -f on that file while
working on troubleshooting.

Second, something to look out for with those hangs is that the perl
process stays around.  Run ps or top and look for perl processes; this
usually indicates there's a loop.  Killing the process sometimes causes
some errors to spew.

> This may be more about configuring Eidetic than rackview, but I'm not
> sure. I was hoping I could get the example working before trying to delve
> too deeply into it all.

Your guess is likely right.  This release of Eidetic is highly
developmental; we just got it out last week after some fairly massive
reworks of the internals and we expect there's still some bugs.  The
goal was to break out the copies of Eidetic that had been embedded into
Rackview, and try to establish Eidetic as an independent library.

If your immediate needs, you may want to install rackview 0.06, as it is
more stable and tested.  Functionally there's no major difference
between 0.06 and 0.07; the Eidetic code extraction is the main change.
Since 0.06 is more self-contained, it's probably more straightforward to
get up and running.  Meanwhile Kees and I are going to continue banging
Eidetic into better shape.

> I can do IRC if need be, just let me know which method you prefer.

You can find Kees and I on linuxnet.org at #osdl during working hours.
My preference is email, but I'm easy.  :-)

> A little about myself and my interest in rackview: I am the co-owner of a
> small hosting business that is facing some of the same management issues
> you mentioned you ran into - getting too difficult to manage in a
> spreadsheet, etc. and also have a datacenter move coming up. We have other
> tools in place to manage the customers and other services, but would like
> to integrate them closely with rackview (and nagios too :)

Good deal, I hope you're able to get the use out of it that we have.
Let us know if you come up with some good tricks for making good use out
of it.  Might inspire further enhancements.

Bryce

[Rackview-devel] New user with installation problems

[Charles G. <ch...@de...>]

Hi Bryce (Kees, Marcus, and anyone else out there :)

I've installed rackview, Eidetic and misc dependencies (mostly through
CPAN) on a red hat 9 system, but I'm having trouble getting the example to
run. I have it configured to use the data file as a start since it has
data.

I can run rackview.cgi on the command line and it generates a page
(although I get a bunch of warnings like these).

[Mon Oct 13 12:32:38 2003] rackview.cgi: Pseudo-hashes are deprecated at
/usr/lib/perl5/site_perl/5.8.0/Eidetic/Racks.pm line 242, <FH> line 22.

Running via apache it just hangs for several minutes and I assume killed
by apache as I get eventually get a "Premature end of script headers"
error.

Any ideas about what I'm doing wrong?

This may be more about configuring Eidetic than rackview, but I'm not
sure. I was hoping I could get the example working before trying to delve
too deeply into it all.

I can do IRC if need be, just let me know which method you prefer.

A little about myself and my interest in rackview: I am the co-owner of a
small hosting business that is facing some of the same management issues
you mentioned you ran into - getting too difficult to manage in a
spreadsheet, etc. and also have a datacenter move coming up. We have other
tools in place to manage the customers and other services, but would like
to integrate them closely with rackview (and nagios too :)

thanks
charles

Re: [Rackview-devel] Questions about mods/extensions etc.

[Bryce H. <br...@os...>]

On Wed, 17 Sep 2003, Bryce Harrington wrote:
> On Wed, 17 Sep 2003, Andersson, Magnus wrote:
> > Hi.
> >
> > I just joined this list and I'm wondering what features are on the to
> > do or wish list and what mods, extensions, connections to other tools
> > etc that people have made or have ideas for when it comes to rackview.

Oh, btw, one very blue-sky idea I have had is to make the top-down view
be dynamically generated.

The top down view that we did for the OSDL lab is an SVG drawing done
using Sodipodi.  I save it as a png and then manually imagemap it to
provide the rackview interface.

The idea would be to have enough data in rackview's database about exact
cabinet sizes, placements, orientations, etc. that the SVG could be
generated on the fly.

A follow-on idea would be to make the front-view into dynamically
generated SVG as well, which would permit a more artistically pleasing
display of the racks than can easily be done with HTML tables as we do
now.

Of course, since few web browsers support SVG, these drawings would also
need to be saved into png's on the fly, but this is not a major problem;
Sodipodi can be used in a commandline fashion to do this, or librsvg
could be employed.

Of course, you'd also want something which could intelligently set up
the imagemap coordinates based on info in the SVG.

One could also extrapolate even further, in that once you have position,
orientation, and size data for everything in a database, you have enough
info to do a 3D render via VRML or OpenGL or SDL something.  The
proprietary rack visualization systems I looked at have this capability,
so while I'll probably never work on that, if someone were interested in
doing it I'd definitely be in the cheering section.  ;-)

Anyway, in my eye, the above approach would give rackview a very slick
interface and would make it an order of magnitude easier for others to
use.  I wish I had the time to implement it, but unfortunately don't,
but I could probably lend a few cycles in a supporting role if someone
else wanted to have a shot at it.

Bryce

Re: [Rackview-devel] Questions about mods/extensions etc.

[Bryce H. <br...@os...>]

On Wed, 17 Sep 2003, Andersson, Magnus wrote:
> Hi.
>
> I just joined this list and I'm wondering what features are on the to
> do or wish list and what mods, extensions, connections to other tools
> etc that people have made or have ideas for when it comes to rackview.

Hi Magnus, welcome to the list.  ;-)

There is not a whole lot planned, but you can look in the PLAN file to
see what the ideas are for the next steps.  You can also look through
the Sourceforge Tracker - there's a handful of feature requests folks
have submitted there.

I am not personally actively coding new features into Rackview, since we
got what we needed out of the tool.  However, I'm available to y'all for
doing integration of patches, cutting releases, updating docs,
coordinating, etc.  So as far as setting direction and developing new
features, you guys are in the driver's seat.

In other words, if y'all have ideas for new features, send in the
patches and I'll put 'em in.  :-)

Also, anyone that's submitted more than a couple patches is welcome to
request CVS access.  I don't have a problem opening the tree to people
with demonstrated interest in doing direct development on rackview.

Where it makes sense, I personally like to see development done
modularly via Perl modules, plugins, template-sets, image-tarballs, and
the like.  That way there's less in the core package to maintain, and
ownership / maintenance of the pieces can be distributed.

> I read something about search funtionality and connection with
> nagios. What other ideas exist out there :). Would be nice to hear how
> people make use of this tool. I'm just in the beginning face of
> converting our current database into the rackview format but I see a
> lot of possibilites here. A great tool :)

Cool!  You can post your ideas to the feature request list on
Sourceforge, or right here if you'd like to open discussion on them
first.

On http://www.osdl.org if you navigate down to Lab Equipment page you
can see how we're using it.  I plugged it into our Eidetic-based
hardware inventory system so people can see what projects or tests are
being run on particular machines, etc.  That system is fairly specific
to OSDL, but I made the interface between that system and rackview loose
so folks could tack other kinds of systems (like Nagios) onto it.  I
look forward to seeing what kinds of creative uses people can employ it
for.

We had used it originally for planning out our lab move.  In addition to
moving we were redoing the entire machine rack layout, but had too many
machines for it to be feasible to lay out in spreadsheets or on paper.
Rackview allowed us to dynamically lay everything out, and then generate
all the printed views for people to use in assembling the racks.  It
worked pretty well for us.  I don't know of any other open source tools
designed for assisting with hardware moves in this way.  Maybe if others
are considering doing a data center move, they could build on this tool
to help them.

Bryce

Re: [Rackview-devel] Re: Model Images

[Bryce H. <br...@os...>]

On Wed, 17 Sep 2003, mgvogt wrote:
> Hi,
>
> Yep, works fine and dandy.  Many thanks.
>
> I also have a few images that people might
> find handy - mainly compaq and Sun equipment.
> Is it worth maintaining an images tar ball
> of these?

It certainly could, as long as there's no copyright
or trademark issues to be concerned with.

If you want to create a CVS module in the rackview
project for these, give me your sourceforge ID and
I'll add you to it.

> The next thing I'd like to add (if I get the time)
> is a search feature.  This could help people who are
> not intimately familiar with the equipment to locate
> the host.
>
> It could also be a nice way of linking back from
> nagios back into rackview (via hostextinfo) i.e.
> http://localhost/cgi-bin/rackview.cgi?search="host_x"
>
> Another thing that would be nice is that if there are
> no arguments provided it goes into a search page where
> they can select what they want.  Makes it easier for first
> time users maybe.
>
> When I get the time, I'll put something together and
> forward it.

Cool, looking forward to seeing it.

Bryce

[Rackview-devel] Questions about mods/extensions etc.

[Andersson, M. <mag...@ed...>]

Hi.

I just joined this list and I'm wondering what features are on the to do or wish list and what mods, extensions, connections to other tools etc that people have made or have ideas for when it comes to rackview.

I read something about search funtionality and connection with nagios. What other ideas exist out there :). Would be nice to hear how people make use of this tool. I'm just in the beginning face of converting our current database into the rackview format but I see a lot of possibilites here. A great tool :) 

/Magnus

Re: [Rackview-devel] Re: Model Images

[mgvogt <mg...@te...>]

Hi,

Yep, works fine and dandy.  Many thanks.

I also have a few images that people might
find handy - mainly compaq and Sun equipment.
Is it worth maintaining an images tar ball
of these?

The next thing I'd like to add (if I get the time)
is a search feature.  This could help people who are
not intimately familiar with the equipment to locate
the host.

It could also be a nice way of linking back from
nagios back into rackview (via hostextinfo) i.e.
http://localhost/cgi-bin/rackview.cgi?search="host_x"

Another thing that would be nice is that if there are
no arguments provided it goes into a search page where
they can select what they want.  Makes it easier for first
time users maybe.

When I get the time, I'll put something together and
forward it.

Cheers,


Marcus.

----- Original Message -----
From: Bryce Harrington <br...@os...>
Date: Thursday, September 11, 2003 2:46 am
Subject: Re: [Rackview-devel] Re: Model Images

> On Thu, 4 Sep 2003, mgvogt wrote:
> > Hi,
> >
> > Sorry for the delay, I've been away on holidays too.
> >
> > The rackview.cgi will not work with images in the current 
> configuration>
> > lines 67-84 need to go after line 131 - the reason being is that 
> $racks> has not yet been evaluated when the javascript function is 
> called.  This
> > means it never generates any javascript functions for swapping 
> the images.
> 
> Okay, thanks.  I've updated CVS to reflect this.  Would you mind
> checking once more?  If the new Javascript feature is now working
> properly, I'll cut the next release.
> 
> > Hope you had a good holiday.
> 
> I sure did.  Hope you did too!
> 
> Bryce
> 
> > Cheers,
> >
> >
> > Marcus.
> >
> > > Hi Marcus,
> > >
> > > I've incorporated your changes into Rackview.  I've wrappered 
> them so
> > > that the use of javascript for the images can be chosen as an 
> option> > either in the config file or via a cgi parameter.  The 
> changes are
> > > checked into CVS.  I haven't tested them (I'm about to head 
> out for
> > > vacation) so would love it if you had a chance to do so.
> > >
> > > Thanks again!
> > > Bryce
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Rackview-devel mailing list
> > Rac...@li...
> > https://lists.sourceforge.net/lists/listinfo/rackview-devel
> >
> 
> 
                                                                      

Re: [Rackview-devel] Re: Model Images

[Bryce H. <br...@os...>]

On Thu, 4 Sep 2003, mgvogt wrote:
> Hi,
>
> Sorry for the delay, I've been away on holidays too.
>
> The rackview.cgi will not work with images in the current configuration
>
> lines 67-84 need to go after line 131 - the reason being is that $racks
> has not yet been evaluated when the javascript function is called.  This
> means it never generates any javascript functions for swapping the images.

Okay, thanks.  I've updated CVS to reflect this.  Would you mind
checking once more?  If the new Javascript feature is now working
properly, I'll cut the next release.

> Hope you had a good holiday.

I sure did.  Hope you did too!

Bryce

> Cheers,
>
>
> Marcus.
>
> > Hi Marcus,
> >
> > I've incorporated your changes into Rackview.  I've wrappered them so
> > that the use of javascript for the images can be chosen as an option
> > either in the config file or via a cgi parameter.  The changes are
> > checked into CVS.  I haven't tested them (I'm about to head out for
> > vacation) so would love it if you had a chance to do so.
> >
> > Thanks again!
> > Bryce
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Rackview-devel mailing list
> Rac...@li...
> https://lists.sourceforge.net/lists/listinfo/rackview-devel
>

[Rackview-devel] Re: Model Images

[mgvogt <mg...@te...>]

Hi,

Sorry for the delay, I've been away on holidays too.

The rackview.cgi will not work with images in the current configuration

lines 67-84 need to go after line 131 - the reason being is that $racks
has not yet been evaluated when the javascript function is called.  This
means it never generates any javascript functions for swapping the images.

Hope you had a good holiday.

Cheers,


Marcus.

> Hi Marcus,
> 
> I've incorporated your changes into Rackview.  I've wrappered them so
> that the use of javascript for the images can be chosen as an option
> either in the config file or via a cgi parameter.  The changes are
> checked into CVS.  I haven't tested them (I'm about to head out for
> vacation) so would love it if you had a chance to do so.
> 
> Thanks again!
> Bryce
 

Re: [Rackview-devel] Model images

[Bryce H. <br...@os...>]

Hi Marcus,

I've incorporated your changes into Rackview.  I've wrappered them so
that the use of javascript for the images can be chosen as an option
either in the config file or via a cgi parameter.  The changes are
checked into CVS.  I haven't tested them (I'm about to head out for
vacation) so would love it if you had a chance to do so.

Thanks again!
Bryce

On Fri, 8 Aug 2003, Marcus Vogt wrote:

> Hi,
>
> I'll check out the patch tool later, so here are the files:
>
> rackview.cgi is modified to allow the javascript image flipping - allows
> users to actually see the
> item.  I've hardcoded it to be jpg's for the moment.  It would be nice
> to have a seperate data
> structure for models, as you could then say I have n of model Y and
> these are the power/cooling/image/etc.
>
> Racks.pm is modified to allow for more of the javascript stuff and also
> to do a search and replace
> on rackview.conf to replace the host name as well.  This allows for the
> integration into nagios - works just fine here.
>
> Appologies in advance for the sloppy coding :)
>
> Cheers,
>
>
> Marcus.
>
>
> Bryce Harrington wrote:
>
> >Cool!  You can post it here to the list or upload it to the patch tool
> >on SF if that'd be more convenient.
> >
> >Looking forward to seeing it!
> >
> >Bryce
> >
> >On Fri, 8 Aug 2003, Marcus Vogt wrote:
> >
> >
> >>Hi all,
> >>
> >>I've made a few patches to the 0.5 sources that allow you to integrate
> >>with nagios and also have the images of the actual models show up
> >>when you put the mouse over it.
> >>
> >>How do I go about submitting this?
> >>
> >>Cheers,
> >>
> >>
> >>Marcus.
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> >>Data Reports, E-commerce, Portals, and Forums are available now.
> >>Download today and enter to win an XBOX or Visual Studio .NET.
> >>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> >>_______________________________________________
> >>Rackview-devel mailing list
> >>Rac...@li...
> >>https://lists.sourceforge.net/lists/listinfo/rackview-devel
> >>
> >>
> >>
> >
> >
> >
> >
>
>

Re: [Rackview-devel] Model images

[Marcus V. <mg...@bi...>]

Hi,

I'll check out the patch tool later, so here are the files:

rackview.cgi is modified to allow the javascript image flipping - allows 
users to actually see the
item.  I've hardcoded it to be jpg's for the moment.  It would be nice 
to have a seperate data
structure for models, as you could then say I have n of model Y and 
these are the power/cooling/image/etc.

Racks.pm is modified to allow for more of the javascript stuff and also 
to do a search and replace
on rackview.conf to replace the host name as well.  This allows for the 
integration into nagios - works just fine here.

Appologies in advance for the sloppy coding :)

Cheers,


Marcus.


Bryce Harrington wrote:

>Cool!  You can post it here to the list or upload it to the patch tool
>on SF if that'd be more convenient.
>
>Looking forward to seeing it!
>
>Bryce
>
>On Fri, 8 Aug 2003, Marcus Vogt wrote:
>  
>
>>Hi all,
>>
>>I've made a few patches to the 0.5 sources that allow you to integrate
>>with nagios and also have the images of the actual models show up
>>when you put the mouse over it.
>>
>>How do I go about submitting this?
>>
>>Cheers,
>>
>>
>>Marcus.
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>Data Reports, E-commerce, Portals, and Forums are available now.
>>Download today and enter to win an XBOX or Visual Studio .NET.
>>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>>_______________________________________________
>>Rackview-devel mailing list
>>Rac...@li...
>>https://lists.sourceforge.net/lists/listinfo/rackview-devel
>>
>>    
>>
>
>
>  
>

Re: [Rackview-devel] Model images

[Bryce H. <br...@os...>]

Cool!  You can post it here to the list or upload it to the patch tool
on SF if that'd be more convenient.

Looking forward to seeing it!

Bryce

On Fri, 8 Aug 2003, Marcus Vogt wrote:
> Hi all,
>
> I've made a few patches to the 0.5 sources that allow you to integrate
> with nagios and also have the images of the actual models show up
> when you put the mouse over it.
>
> How do I go about submitting this?
>
> Cheers,
>
>
> Marcus.
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Rackview-devel mailing list
> Rac...@li...
> https://lists.sourceforge.net/lists/listinfo/rackview-devel
>

[Rackview-devel] Model images

[Marcus V. <mg...@bi...>]

Hi all,

I've made a few patches to the 0.5 sources that allow you to integrate
with nagios and also have the images of the actual models show up
when you put the mouse over it.

How do I go about submitting this?

Cheers,


Marcus.

[Rackview-devel] Release 0.06

[Bryce H. <br...@os...>]

Rackview 0.06 is released and available for download from the
SourceForge site.

    http://sf.net/projects/rackview/

Bryce

[Rackview-devel] Question on installing GD perl modules

[Bryce H. <br...@os...>]

---------- Forwarded message ----------
Date: Thu, 12 Jun 2003 07:52:22 -0700 (PDT)
From: Bryce Harrington <br...@os...>
To: black shadow <sol...@ho...>
Subject: Re: Rackview

You also need the perl bindings for GD.  For instance, on my system I
installed:

perl-GD-1.38-1.i386.rpm
perl-GDGraph-1.33-10.i386.rpm
perl-GDTextUtil-0.80-10.i386.rpm

Hope this helps,
Bryce

On Thu, 12 Jun 2003, black shadow wrote:

> Hi Bryce,
>
> I=B4ve downloaded & en unpacked  rackview-0.05.tar.gz, but when I try t=
o do
> the following=B1
>
> [root@recoil rackview-0.05]# perl Makefile.PL
> Checking if your kit is complete...
> Looks good
> MakeMaker FATAL: prerequisites not found (GD not installed)
>
>                Please install these modules first and rerun 'perl
> Makefile.PL'.
>
> And that=B4s the error it gives me, I isntalled =B4GD Graphics Library=B4=
 but that
> won=B4t help, can you please help me out here
>
> Greetz
>
> SOLO
>
> _________________________________________________________________
> MSN Zoeken, voor duidelijke zoekresultaten! http://search.msn.nl
>

[Rackview-devel] Use of Rackview to support the OSDL Move

[Bryce H. <br...@os...>]

For the past month, we've been working at moving the OSDL-US facility to
a new location, which meant the move of over 120 servers in roughly 50
racks.  To take advantage of the increased size/shape of the new data
center room, we decided to redesign the layout.

Previously, all the equipment had been mounted in two main racks and a
few auxilliaries.  We had been managing to track the main racks via two
spreadsheets.  Unfortunately, this approach had a few problems.  First,
in practice really only a single person could do updates to the
spreadsheet, since otherwise there'd be risk of divergent copies
appearing.  Second, we maintain the host listing in a mysql db, so
adding a new machine required updating both the db and a spreadsheet.
Third, the spreadsheet approach did not lend itself to searching for
where a machine was installed; it hadn't been that big of a deal for the
two-frame arrangement, but the new layout broke things out into 14
frames, and the idea of having to browse through 14 sheets in a workbook
to find a piece of equipment did not seem very appealing!  Fourth,
unless you were the owner of the spreadsheet, you never really knew for
sure if you were looking at the most up to date stuff.  Finally, as it
was in a Gnumeric spreadsheet, it wasn't possible for us to show it
publically, except with extra contortions to convert it into pdf or html
and upload it regularly.

So...  the idea for rackview was born.  We figured a spreadsheet-like
interface could be drawn in HTML tables from our database, via either a
cronjob or CGI script.  While the tool was being developed, three of my
co-workers started plugging data into the database.  The fact that all
three could do it in parallel was very helpful.  A person could update
an entire column-full of data about all of the machines, or could take a
subset (all the clients) and fill in several columns at once.  Splitting
the work up allowed us to finish the work quickly, which was important
because we were under the gun.

When it came time for the move, we quickly printed out copies of
rackview for each rack.  We got plastic see-thru envelopes and
doublesided tape, and put a copy of the plan up at the end of each of
the frames, showing what equipment should go where.  This proved to be
invaluable because we had a lot of people helping who weren't really
familiar with our equipment, but since everything was labelled this let
them easily figure out where to put things.

A few glitches were discovered.  First, it was difficult to determine
exactly which U a piece of equipment was to be mounted in, since I'd
just left the open areas blank, and didn't add a U-ruler along the side
to measure off of.  Kees addressed this by making a database dump
showing each machine and it's precise U location, that we taped
underneath the diagram.  After the move we fixed rackview to better
include this info via a U ruler & lines in the open areas - this is now
available in rackview 0.05.  Second, printing out each of the pages was
a real hassle, since you had to click on each frame, print, etc.  Last
week Kees figured out the changes needed to make it possible for html2ps
to work, so that we can script the creation of a postscript document
with all the frames shown.

When we first moved in, most of the A/C was not turned on correctly
(several units had their fans installed backwards!)  So we were not able
to power everything on.  The heat summary shown on rackview was useful
in helping us determine which machines would be most worth turning off.
Kees has added some additional capabilities for heat reporting.  Our A/C
finally got fixed right, fortunately!

Now that the move is complete and all the hardware set up and purring
away, much of the pressure driving rackview development is off.  But we
know others will also find this to be a useful tool, and we'd love to
see development of it remain active.  There are two ways this can be
achieved.  First, if others contribute their ideas and improvements.
Second, since OSDL has the mission of seeking out ways to increase use
of open source in the enterprise, if we get feedback from enterprise
users that this tool has helped them, it will help us justify to
management & the board to continue development of it.  Feature requests,
bug reports, patches, or even a simple, "It worked for us," will
directly help further development of it.

Bryce

[Rackview-devel] Re: [Ops] Lab layout & rack location stuff for web (fwd)

[Bryce H. <br...@os...>]

Another still-pending feature was display of front/back mounted
equipment.  This email includes a description of an idea for how it
could be handled in HTML.

---------- Forwarded message ----------
Date: Tue, 4 Jun 2002 09:33:00 -0700 (PDT)
From: Bryce Harrington <br...@os...>
To: Aaron Burt <aa...@os...>
Cc: op...@os...
Subject: Re: [Ops] Lab layout & rack location stuff for web

On Tue, 4 Jun 2002, Aaron Burt wrote:
> On Mon, 3 Jun 2002, Bryce Harrington wrote:
> > Here are some additional thoughts regarding what I mentioned in the
> > staff meeting regarding integrating the lab layout and rack location
> > stuff on the web.
>
> <snip cool stuff about databases and diagrams>
>
> I definitely favor keeping the master info in the database and generating
> graphics/maps from there.
>
> Currently, the rack diagrams are generated by coloring cells in Gnumeric.
>
> Whaddaya think of using HTML tables?  (The VRML comes later ;)

I think it is definitely doable.  In fact for curiousity's sake I rigged
up a demo to prove to myself that it'll work and look okay.  The script
to "draw" that table should be pretty easy to make.

The top-down layout would be more challenging to do as HTML, though, and
probably would prefer itself being done as a graphic.

> Can you think of a good way to indicate that an item is mounted at the
> back rather than the front of a rack?

Hmm, good point, I hadn't thought about that.  How are these things
currently represented in gnumeric?

If the rack layout is done as HTML, then an isometric appearance can be
done by using triangular graphics on the right side of the HTML table,
that will imply depth.  Unfortunately, we don't track front/back
locationing info in the database currently, so I'm not sure how we'd
tackle this.

How many rear-mounted things do we have currently?  How many of those
have things mounted in front of them?  If we don't have a lot of
instances of front and rear mounted things, could this be left to a v.2
goal for later?

Bryce

_______________________________________________
Ops mailing list
Op...@li...
http://lists.osdl.org/mailman/listinfo/ops

[Rackview-devel] [Ops] Lab layout & rack location stuff for web

[Bryce H. <br...@os...>]

Here's the original proposal for rackview, almost a year to the date of
its release. :-)

I'm forwarding it because it includes some description of a more
advanced interface to it than we have currently, that might be of
interest.

Bryce

---------- Forwarded message ----------
Date: Mon, 3 Jun 2002 17:51:47 -0700 (PDT)
From: Bryce Harrington <br...@os...>
To: op...@os...
Cc: rk...@os...
Subject: [Ops] Lab layout & rack location stuff for web

Here are some additional thoughts regarding what I mentioned in the
staff meeting regarding integrating the lab layout and rack location
stuff on the web.

Currently we have fields in the database for each host, which specifies
which room it's in, which rack, and what position in the rack.  The
reason why we would bother to keep this info in the database is mainly
for administration (keeping all info about the host in a centrally
viewable location); an extra benefit is that we can display it to
external users, which probably has some marketing benefit.

We also have a pair of documents to help us plan and visualize how
things are organized: a dia diagram showing the layout of the lab and
where racks are positioned, and a gnumeric spreadsheet showing what
hosts are in what rack positions.

Thus, if something gets moved, we need to update both the diagram and
the information in the database, else one or the other will quickly grow
out of date.  This does not seem like a very viable long term solution,
though.

There's several ways to eliminate this redundancy.  One, of course, is
to simply remove the information from the database, and live without
it.  We could have a static graphic showing the lab layout generally,
and call it good enough.

A second approach, that would let us keep the database, is to
auto-generate the graphics from data.  However, this really reduces the
amount of flexibility we currently have in being able to edit the
diagram in an editor.  Heck, maybe some would see that as an advantage!
;-)

A third approach would be to put tags into the layout diagrams that will
let us write a script that can extract that information for sending to
the database.  Then, whomever is updating the layout diagram would
merely need to run the script on their updated diagram for the data to
get entered into the database.  (Potential would exist for integrating
this script into the doc sys and/or web build system to further automate
it, if desired.)

So how would this actually work?  First, the graphic editing program we
use must do two things: It must be allow "tagging" regions of the
diagram so that we can link those things with hosts, racks, etc., and it
must export that information in a way that allows a script to access and
use it.  The script could then use a simple intersection algorithm to
map out where the host is.  In other words, if the box representing
khack overlaps the two boxes 'A4-03' and 'A4-04', then we know khack is
in rack A4 at position 3, with a height of 2.  :-)

A file format that I've used before for something like this, is Scalable
Vector Graphics (SVG), an XML-syntax format that can be exported by a
variety of different graphics editors.  The editor I've used and would
recommend is "Sodipodi", which uses SVG as its primary format, but
there's other applications out there such as Illustrator, Gimp, etc.

Here's what an SVG enty looks like:

...
  <rect
     style="stroke:none; fill:#7f7f7f; fill-opacity:100%;
     fill-rule:evenodd; stroke-opacity:100%; stroke-width:1px;
     stroke-linejoin:miter; stroke-linecap:butt; "
     id="host stp8-003"
     x="273.583802"
     y="591.995501"
     width="285.975253"
     height="120.269966">
  </rect>
  <rect
     style="stroke:none; fill:#7f7f7f; fill-opacity:100%;
     fill-rule:evenodd; stroke-opacity:100%; stroke-width:1px;
     stroke-linejoin:miter; stroke-linecap:butt; "
     id="location Arctic-A4-07"
     x="273.5987"
     y="592.0011"
     width="286.00"
     height="120.00">
  </rect>
...

So the script would extract the rect's with id's like "host*" and then
look for "location*" rects that it overlaps, and from this calculate
which room, rack, and position it's in.  This info can then be fed to
the database.

The reason we would bother with the intersection/overlap mechanism is
that it makes it very easy for you to move things around graphically -
just drag and drop the 'khack' rect to its new location.

The script also needs to produce the "highlighted" versions of the
diagrams that can be displayed on the website.  As the script scans the
source SVG, it would produce additional SVG's, one for each host,
adjusted appropriately.  For example, the given host's rect could be
made yellow, with a thicker border, via the fill and stroke-width
properties.  These output SVG's are then run through imagemagick or gimp
to produce PNG's of the image.  In addition, the script would produce an
image-map HTML snippet to go with the PNG's; this will allow folks to
click on the image and be able to view the host at that position.

SVG has some other nice features, such as alpha blending, which can
allow you to make some really nice looking graphics.  On the other hand,
most SVG editors won't have certain other handy diagramming features -
such as generating UML flowcharts from a SQL schema, so it may not be a
good choice for some situations.  But because it's XML based it is
ameniable to being hooked in with other tools, as we would like in this
case.

Bryce



_______________________________________________
Ops mailing list
Op...@li...
http://lists.osdl.org/mailman/listinfo/ops

[Rackview-devel] Rackview 0.05 Released

[Bryce H. <br...@os...>]

Version 0.05 of rackview has been released and is available for
download.  See the NEWS section on the website for the new features and
the download link

    http://rackview.sf.net/

Bryce

[Rackview-devel] rackview updates

[Bryce H. <br...@os...>]

That printing enhancement is definitely da bomb.  ;-)

Bryce

---------- Forwarded message ----------
Date: Wed, 28 May 2003 16:32:20 -0700
From: Kees Cook <ke...@os...>
Reply-To: op...@os...
To: Operations <op...@li...>
Subject: [Ops] rackview updates

Okay, after today's work, rackview has some more features:

- per-frame summary of heat/cooling (with frame_heat=1, or heat=1)
- per-rack summyar of heat/cooling controlled with (rack_heat=1/0)
- can optionally be run with "frame=..." instead of "rack_ids=..,..,.."
- uses a "1U" image for spacing, allowing html2ps to format correctly (and
     lets use automate the printing!)
- warnings can be turned on and off (warn=1, warn=0)
- alphabetical list of machines in a frame (with rack and U report) can
     be appended if alpha=1
- all options (except frame/rack_ids) have defaults in the rackview.conf file

I'm going to print this stuff out now and go verify the lab... :P

-- 
Kees Cook
_______________________________________________
Ops mailing list
Op...@li...
http://lists.osdl.org/mailman/listinfo/ops

[Rackview-devel] 0.04 Release & now publically usable at OSDL

[Bryce H. <br...@os...>]

Two announcements -

First, I've cut a 0.04 release.  This incorporates the aforementioned
changes to make it possible to generate an RPM of the tool.  An example
specfile is included.  If people would be interested in having the RPM's
available let me know.  The Freshmeat announce should hit the site
soonish.

Second, we now have rackview installed at www.osdl.org for y'all to play
with.  Click on the Lab Equipment link, or navigate their directly via:

    http://www.osdl.org/lab_equipment/

Click on the rack frames to see the hardware, and then click on the
hardware to see the metadata on it - including links to the project
that's using the hardware (for project machines) and to recent test
requests (for STP testing machinery.)

Finally, if anyone is having installation problems please let us know
and we'll help you work through them.  If you have successfully
installed it, or plan to do so, we'd also love to know.

Bryce

[Rackview-devel] rackview 0.04 development objectives

[Bryce H. <br...@os...>]

Hi all,

Thanks for everyone who have tried out rackview.  This is the right
place to post questions, report installation problems, etc. etc.
Patches can also be posted here.

Currently, I'm working on getting rackview installed onto our production
website.  The gating item here is that our standard process is to manage
everything through RPM, but cpan2rpm does not handle things like
installation to custom cgi-bin, document root, etc. well enough.  Kees
and I were digging into it this afternoon, and I'm hopeful I'll be able
to get it tackled tomorrow.

So for 0.04, I expect that the main change will be mostly fixes to
Makefile.PL to get it to collaborate with rpm a bit better.

Kees and I have tossed a few ideas around for things to add in the
future.

0.  Currently the tool has a built-in assumption of 1 host per rack U
    max, and does not cope well with the idea of having things mounted
    both in the front of the rack and the back.  We have some ideas for
    how to address this, but since it complexifies things we chose to
    not go into that for the 0.03 release.

1.  Kees is currently working on algorithms and database tables for
    tracking rack and frame properties (i.e., dimensions), with the
    objective of developing a tool for calculating cable lengths.  This
    may be distributed separately from rackview.

2.  The 'front end' for rackview is an imagemap generated from an SVG
    file.  An idea I've had since before this even started was to be
    able to dynamically generate (or at least dynamically alter) the
    SVG.  The problem, of course, is how to convert the SVG into a PNG
    on the fly.  The current imagemap was produced by taking a screen
    capture in The Gimp.  But just yesterday I learned that tvon
    released mod_rsvg, an Apache module for generating PNG's from SVG's
    dynamically in the web server.  The most interesting implication of
    this is that it would *also* permit generating a much more visually
    sophisticated front-view of the rack as well.

3.  As a packaging matter, Kees and I hope to break out some of the
    Eidetic::* Perl modules into a separate dependency at some point.
    We've established a SF project for doing this but have not yet had
    time to do more than think about what we'd like to do if we had the
    time.  ;-)

4.  In addition to calculation of BTU's and cooling load, Kees
    speculated that it'd make sense to also include mass summaries.
    OSDL's new data center has some structural limits regarding how much
    weight we can put on the floor beams, so this'd be a sensible
    addition.

Anyway, if one of these things strikes your fancy and you'd like to take
the challenge of doing it, just shout.  :-)

Bryce