On Mon, 2009-06-22 at 09:13 -0400, David Huff wrote: > Lucas Meneghel Rodrigues wrote: > > I've been trough the changes, thank you for your work David: > > Comments/questions: > > > > * Any particular reason why you guys wrote the PXE boot setup as a > > shell script instead of a python module (that could be also used as a > > stand alone program)? > > We decided to use environmental scripts to set up any host specific > prerequisite priour to execution any tests. This way there would be a > standard/preferred way for tests to set up a specific environment on the > host. > > I am including a snippet form a previous email explaining why we went > down this path... > > Michael Goldish wrote: > > The solution I had in mind was to add pre/post-processor parameters > 'pre_command' and 'post_command' that represent shell commands to be > executed before/after the test. A typical shell command would be one > that runs an environment specific script that sets up mount points or > whatever is needed for the test. This parameter would be provided for > each test (in the config file) so one can 'variant' on it, to make > different variants of the test (e.g. 'dbench' with local storage, and > then with NFS storage, ...). There can also be pre/post-processing > scripts for the entire job, that run before the first test and after the > last one. I agree to the reasoning made here in general, but ultimately we do have to maintain all external scripts. On the coding style document: http://autotest.kernel.org/browser/trunk/CODING_STYLE "Please use Python where possible. It's not the ideal language for everything, but it's pretty good, and consistency goes a long way in making the project maintainable. (Obviously using C or whatever for writing tests is fine)." This particular case (environment setup) is not a reason good enough to break this principle - we are doing high level stuff, so it ends up being the same coding it in python or shell script, and in such cases, the general principle says we should go python. > > If you use a setup_<testname> function you require the user to change > kvm-autotest code in order to perform environment specific setup (and > you also limit the user to python). I personally prefer to leave all > environment specific stuff in external scripts outside the code, but I > may be wrong. See comment above. Limiting the choice of languages here is good maintainability wise, and it's compliant with the upstream guidelines. Good to stress at this point that I have nothing against shell, perl, ruby and other fine languages (I actually like them). This is just an attempt to be consistent. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
