Hi list
A few questions regarding the scope of test scripts that have been requested:
- is there a git repository or similar source that contains all of the currently available test scripts? It would be helpful to know that, given my copious spare time, I'm not re-inventing any wheels or contributing the 57th LAMP install script.
- relating to package installation test scripts, would there be any appreciable benefit to simply throwing everything + kitchen sink at the wall and see what _doesn't_ stick? (i.e., yum install every single available package one after the other and record any failures?) This seems like a more...comprehensive method of uncovering package installation issues than me simply picking "my top 10 favourite/most well known" yum packages.
- is the scope for test scripts "anything you can think of that performs some kind of configuration change with a measurable return value" - e.g, tests that cover (for example) networking configuration, partition/filesystem creation, package installation, firewall configuration, user/group account creation/deletion/editing, SSH key generation etc etc etc?
- at present, each test script needs to be self-contained. To reduce the amount of code duplication/maintenance is there any intention (or objection) to developing a library of helper functions?
Thank you!
Steve
On Sun, 2011-05-01 at 08:41 +1000, Steve Barnes wrote:
Hi list
A few questions regarding the scope of test scripts that have been requested:
- is there a git repository or similar source that contains all of the currently available test scripts? It would be helpful to know that, given my copious spare time, I'm not re-inventing any
wheels or contributing the 57th LAMP install script.
- relating to package installation test scripts, would there be any appreciable benefit to simply throwing everything + kitchen sink at the wall and see what _doesn't_ stick? (i.e., yum install
every single available package one after the other and record any failures?) This seems like a more...comprehensive method of uncovering package installation issues than me simply picking "my top 10 favourite/most well known" yum packages.
- is the scope for test scripts "anything you can think of that performs some kind of configuration change with a measurable return value" - e.g, tests that cover (for example) networking
configuration, partition/filesystem creation, package installation, firewall configuration, user/group account creation/deletion/editing, SSH key generation etc etc etc?
- at present, each test script needs to be self-contained. To reduce the amount of code duplication/maintenance is there any intention (or objection) to developing a library of helper functions?
Thank you!
Steve
+1
I look forward to some comprehensive discussion with regards to this! I do like the kitchen sink idea - But not all packages can co exist, with default setups, like MTA's and such - Just my 2pence
On Sunday 01 May 2011 03:06:00 Mister IT Guru wrote:
On Sun, 2011-05-01 at 08:41 +1000, Steve Barnes wrote:
Hi list
A few questions regarding the scope of test scripts that have been requested:
- is there a git repository or similar source that contains all of the
currently available test scripts? It would be helpful to know that, given my copious spare time, I'm not re-inventing any wheels or contributing the 57th LAMP install script.
- relating to package installation test scripts, would there be any
appreciable benefit to simply throwing everything + kitchen sink at the wall and see what _doesn't_ stick? (i.e., yum install every single available package one after the other and record any failures?) This seems like a more...comprehensive method of uncovering package installation issues than me simply picking "my top 10 favourite/most well known" yum packages.
- is the scope for test scripts "anything you can think of that performs
some kind of configuration change with a measurable return value" - e.g, tests that cover (for example) networking configuration, partition/filesystem creation, package installation, firewall configuration, user/group account creation/deletion/editing, SSH key generation etc etc etc?
- at present, each test script needs to be self-contained. To reduce the
amount of code duplication/maintenance is there any intention (or objection) to developing a library of helper functions?
Thank you!
Steve
+1
I look forward to some comprehensive discussion with regards to this! I do like the kitchen sink idea - But not all packages can co exist, with default setups, like MTA's and such - Just my 2pence
Karanbir have one repository with kickstart files:
https://nazar.karan.org/cgit/bluecain/tree/README
Hi Steve,
On 04/30/2011 11:41 PM, Steve Barnes wrote:
- is there a git repository or similar source that contains all of the currently available test scripts? It would be helpful to know that, given my copious spare time, I'm not re-inventing any
wheels or contributing the 57th LAMP install script.
Not at the moment, but lets try and get something setup in the next few days. The setup we have at the moment does some of the provisioning, setup and then the tests. We need to isolate the tests from that git repo and setup something new, publicly visible. Should happen real soon.
- relating to package installation test scripts, would there be any appreciable benefit to simply throwing everything + kitchen sink at the wall and see what _doesn't_ stick? (i.e., yum install
every single available package one after the other and record any failures?) This seems like a more...comprehensive method of uncovering package installation issues than me simply picking "my top 10 favourite/most well known" yum packages.
That depends on what you are trying to achieve. Not every packages needs to be installable at the same time as everything else.
- is the scope for test scripts "anything you can think of that performs some kind of configuration change with a measurable return value" - e.g, tests that cover (for example) networking
configuration, partition/filesystem creation, package installation, firewall configuration, user/group account creation/deletion/editing, SSH key generation etc etc etc?
sure. Go for it.
- at present, each test script needs to be self-contained. To reduce the amount of code duplication/maintenance is there any intention (or objection) to developing a library of helper functions?
there is a common set of lib + functions that can be used to make life easier, we then just need to make sure its well documented and maintained. At the moment they all go into <root dir>/functions/ and are 'sourced' before the tests are copied / moved / run. Which also makes them very bash specific.
- KB