Hi, On Mon, Aug 02, 2010 at 11:07:46PM +0200, Lars Marowsky-Bree wrote: > On 2010-08-02T19:05:53, Dejan Muhamedagic <deja...@fastmail.fm> wrote: > > > Testing/starting/etc resources is easy, but the shell doesn't > > know about dependencies. > > I think this might not even be needed for the first step. Clearly, a > mode to run a specific single resource would be required. > > I do think "ra test" is the right level for this; but maybe the "ra" > command hierarchy should be available from configure too?
It is, because it is useful to get the RA documentation while defining resources. > ra test <rsc> <node> <op> The reason to have it running from the configure level is that that is the place where resources are defined: resource names and their parameters. The ra level has no such infrastructure. > If node is not given, run locally. If <op> is not given, run > ocf-tester. The shell doesn't have capability to run operations on other nodes. > (And really, I mean run ocf-tester - I don't want to duplicate the test > case logic in more than one place.) > > In the first step, the user would be required to ensure all dependencies > are up and available, or brought online manually before. > > > We can introduce a new sublevel at configure to allow fiddling with > > resource operations at will, but it would be better to have, say, > > ptest provide information about the order of resource operations. > > I can see the value here too - but this gets complex really quickly, if > the ordering/locations are not local only, or if clones get involved. It is true that it would be difficult to cover all the cases. > (We end up single stepping through the transition graph, basically. That > may be quite worthwhile to implement, but seems to be a quite different > scope, and may best be implemented via a "debugger" interface to the > crmd, so that the shell can interactively trace + modify the transition? > Word up for complexity! ;-) > > > order. For instance, after creating new resources, the user would > > just say "test" before commit and the shell would run the > > following: > > > > test A (ocf-tester) > > start A > > test B > > start B > > test C > > stop B > > stop A > > I _think_ we are fine if we allow the "ra test" command to operate on > groups too. > > But if we try to implement the "test" mode so that it resolves > dependencies, we will end up creating an expectation that it always > works, and that the shell figures out where to run stuff etc. I'd > rather have something simple that we can guarantee always works, than > something complex that will lead to many bug reports ;-) Not sure, but I suspect that the implementation of testing groups wouldn't be much different from gathering dependencies from some external source. At any rate, we may start with something less ambitious. Cheers, Dejan P.S. Moving the discussion to the user list and adjusting the subject. > Regards, > Lars > > -- > Architect Storage/HA, OPS Engineering, Novell, Inc. > SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > > > _______________________________________________ > Pcmk-devel mailing list > pcmk-de...@oss.clusterlabs.org > http://oss-2.clusterlabs.org/mailman/listinfo/pcmk-devel _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
