Re: [Rdo-list] Creating rpms for Tempest

On 02/03/2014 02:27 PM, Lon Hohberger wrote: > On 02/03/2014 10:50 AM, David Kranz wrote: >> There has been a lot of interest in running tempest against real RDO >> clusters. Having an rpm would make that a lot easier. There are several >> issues peculiar to tempest that need to be resolved. >> >> 1. The way tempest configures itself and does test discovery depends >> heavily on the tests being run from a directory containing the tests. >> 2. Unlike OpenStack python client libraries, tempest changes from >> release to release in incompatible ways, so you need "havana tempest" to >> test a havana cluster and an "icehouse tempest" to test icehouse. >> >> The tempest group has little interest in changing either of these >> behaviors. Additionally, it would be desirable if a tempest user could >> install tempest rpms to test different RDO versions on the same machine. >> Here is a proposal for how this could work and what the user experience >> would be. >> >> Dealing with these tempest issues suggests that the the tempest code >> should be copied to /var/lib/tempest/{4.0,5.0, etc.} and the user should >> configure a separate directory for each OpenStack cluster to be tested. >> Each directory needs to contain: >> >> .testr.conf >> an etc directory containing the tempest.conf and logging.conf files >> a symlink to the tempest test modules for the appropriate version >> a copy of the test run scripts that are in the tools directory of >> tempest >> >> To help the user create such directories, there should be a global >> executable "configure-tempest-directory" that takes an optional version. >> If multiple versions are present in /var/lib/tempest and no version is >> specified then the user will be asked which version to configure. > Would it make sense to make the package name itself to have it? > > This way, you could say install tempest for grizzly and update tempest > for havana - e.g.: > > yum install tempest-grizzly > yum update -y tempest-havana > > ... and the RPMs would not obsolete each other. If we use RPM > versioning, "yum update" will blow away testing environments of "older" > tempest versions. > > We could perhaps do it using sub-rpms - which would allow us to add and > remove tempest suites as we move along: > > * ship no files except perhaps license in 'tempest' itself > and stand-up environment bits > * use subpackages for > tempest-grizzly/tempest-havana/tempest-icehouse/... > * get a special exception to *not* make tempest-* child > RPMs require a fully-versioned tempest base package all > the time just in case you wanted to have older tempest > for a given release > e.g. tempest-2.0.0 > tempest-grizzly-1.0.0 > tempest-havana-2.0.0 > > ... could all be installed, and if done right, you could > 'yum update -y tempest-grizzly' to 3.0.0 without breaking > the tempest-havana-2.0.0 package. > > Just a thought. > >> User experience: >> >> 1. Install tempest rpm: yum install tempest-4.0 > The above would mean: > > yum install -y tempest-havana > yum install -y tempest-grizzly > > etc. > > >> 2. Run configure-tempest-directory >> 3. Make changes to tempest.conf to match the cluster being tested (and >> possibly logging.conf and .testr.conf as well) >> 4. Run tempest with desired test selection using >> tools/pretty_tox_serial.sh or tools/ pretty_tox_serial >> >> Does any one have any comments/suggestions about this? >> > -- Lon > Lon, I was not clear enough but I was proposing something very similar to your suggestion, just without subpackages which I don't understand well. Now that I understand the rules a little better and that the base package names should not have things that look like version numbers, I propose: package-names: tempest-havana.{version stuff}, tempest-icehouse.{version stuff} And a tempest-base package on which they all depend that creates "/var/lib/tempest" and the configure-tempest-directory script. -David