> >>> One solution could be to run 3 VMs per exechost (and each exechost >>> appears >>> triple in SGE), but only one VM at a time might receive jobs?
Hm, I read this too quickly last time. It might or might not work to have several VMs, but it implies changing our test environment more that we were planning to. > > [That would be much more convenient if you could do mutual suspension > between hosts, as we've said before.] > >> That's unfortunately not possible, partly because we need all the power >> from the servers to run the application without timing issues. > > If it must run on bare metal, and can't run stateless (when booting > might be faster than re-provisioning), is there some reason not to have > multiple configurations installed, and chroot into them for the job > concerned? > I guess we could do several things with our servers and how that configurations are handled. But our hope is that we can start using GE without changing things too much around, it would probably be a lot of work to start using some other model. The "Configuration" part involves starting our simulated server (running on the real server) and setting up a simulated test environment around it. We must have the simulated server running between test cases to save time. And the main problem seem general enough to have a solution: Several jobs depend on some common precondition, that is tied to an execution host. You want to do the job to fulfil the precondition in such a way so that you minimize the work. And you want it to happen automatically. But if we must provide some custom logic to do this, what would be a good strategy? What do you think about this: Make a complex on the execution hosts (or queue instances?) that decries the configuration that is active on that server. Make a timer triggered script that examines the jobs in the queue at a certain interval. Let the script run the configuration procedure on the test servers when it decides that it is appropriate, and then update the config complex. /Jens _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
