On Tue, Mar 01, 2011 at 02:07:25PM +0100, Michael Hanselmann wrote: > Am 1. März 2011 11:32 schrieb Iustin Pop <[email protected]>: > > On Tue, Mar 01, 2011 at 11:00:01AM +0100, Michael Hanselmann wrote: > >> What do you think of such an implementation? > > > > If that's all what all LUs will do, then I fail to see why adding this > > I assume you didn't really mean all LUs here. It'd just be the LUs > generating other jobs (e.g. NodeEvacStrategy).
Yep. > > line (as a code line) to all such LUs is better than a declarative > > approach, e.g. (whatever the name): > > self.generated_jobs = ops > > I don't like code with side-effects where they can be avoided. Hah, that's why you gave an example that specifically had side-effects? ;) > If you > don't want the jobs to be submitted directly from the opcode, how > about returning a list of opcodes from Exec? > > If they're stored in a recognizable (as in isinstance()) container > class, mcpu.Processor or a wrapper function can submit them. That's also fine. Note we already have dry_run_result as a "side-effect" (why you call it that I'm not sure). thanks, iustin
