Re: [Stp-devel] STP - proposed next steps

[Cliff W. <cl...@os...>]

> I think one thing that isn't clear is the combination of step 3 and 6.
> Step 3 by itself makes sense because it sounds like it'll be like
> robokern.  Step 6 seems unclear, it sounds like you're considering the
> build and installation of postgresql as something special, which doesn't
> seem to fit the methodology of robokern and what you've implied for
> sysstat. It also sounds like you're considering the creation of a
> database as part of the installation of postgresql.  What I'm looking
> for is the separation of the installation of postgresql and the creation
> of a database.  The former would be generic, while the latter would be
> test specific.


Okay. I do think sysstat and postgres are separate cases, and should be
handled a bit differently. 
For sysstat, the package is instrumentation, and not test-specific,
so installation should be handled by the framework, since all the tests need
access to sysstat. The build-install part
_should be trivial. Most of the tests that use sysstat won't requre a specific
PLM number for sysstat, we will need a 'default' setup, so that sysstat Just 
Works,
regardless of what the user chooses. 

The database is test-specific, and should be installed only for DB tests. 
 i don't think placing the install 
knowledge in the framework is the right thing to do. I think
the database install knowledge should be tied to the specific PLM (somehow)

In a perfect would, the test author would call something like:

app_install()
or
app_install( <PLM location>, <PLM ID> )

and it would Just Work.

I agree that db install and db setup should be separate.

cliffw

> 
> Also, I don't quite understand what step 9 means.
> 
> Mark
> 
> On 19 Jul, Cliff White wrote:
> [snip]
> > Steps so far, not necessarily in order.
> > 
> > 0. Talk to Rich Lindsley, agree on base tree.
> > 
> > 1. Add PLM for sysstat.
> >
> > 2. Create BK tree for Rich's PLM patches.
> > 
> > 3. Add sysstat-builder to STP client side
> > 
> > 4. Add systat choice to Web interface with default
> > 
> > 5. Remove systat setups from existing tests
> > 
> > 6. Decide on how best to do PLM query/install for postgres -
> > 	- done by wrap.sh?
> > 	- done by stp_client.pl?
> > 	Instrumentation setups ( sysstat ) are common for all tests,
> > 	really can be considered part of the OS install. 
> > 	Will one database install script work for all database tests,
> > 	or does the db install need to be test-specific?
> > 
> > 7. Web interface will have to be reworked. 
> > 
> > 8. Add PLM for postgres - 
> > 
> > 9. Add PLM methods to DBT postgres tests.
> > 
> > Comments, please
> > cliffw
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Stp-devel mailing list
> Stp...@li...
> https://lists.sourceforge.net/lists/listinfo/stp-devel
>