We will address this patch in the next release. I really prefer the idea of allowing plugins to specify their order as we discussed on irc rather then relying on objdb ordering which could change with the effects of plugin load/unloading.
Regards -steve On Wed, 2009-05-06 at 09:55 +0200, Andrew Beekhof wrote: > On Tue, May 5, 2009 at 11:26 AM, Chrissie Caulfield <ccaul...@redhat.com> > wrote: > > David Teigland wrote: > >> On Wed, Apr 29, 2009 at 02:28:05PM +0200, Andrew Beekhof wrote: > >>> At the moment, startup and shutdown ordering is controlled by the > >>> plugin's position in an objdb list. > >>> > >>> This is particularly problematic for cluster resource managers which > >>> must be unloaded/stopped first. > >>> The reason for this is that they (or the resources they control) need > >>> access to at least some of the other services provided by Corosync. > >>> > >>> Based on input from Steve, this patch resolves the shutdown side of > >>> the equation and if its acceptable I'll work on the startup side of > >>> things. > >> > >> I wonder if the recent cfg shutdown api from chrissie would be relevant to > >> this? > >> > >> It also brings up the question of whether corosync should have a program to > >> start/stop the corosync daemon? > > Personally I'd favor the corosync daemon itself having the smarts to do this. > I don't have a problem with the current method of sending it a signal > and it unloading service engines. > > My only gripe is the order :-) > > >> "corosync_tool join" to set a config method and start corosync > >> > >> "corosync_tool leave" to stop corosync if it's not being used by apps > >> (would use the cfg api) > >> > > > > > > I think this would be nice. One thing that would also be helpful, I > > think, would be to notify plugins of the shutdown. Currently only cfg > > library users get these notifications which seems a little wrong maybe. > > It depends what you mean here. > Plugins already get the opportunity to do something before corosync > exits, but they only find out once the plugins before it have been > notified and unloaded. > > Pacemaker relies on this behavior and I believe it was largely my > moaning that convinced Steve to add it :-) > The problem this patch was attempting to solve was the order in which > the notification/unloading happened. > > > The problem with that is that it would change the corosync API, and I > > don't particularly fancy a horses head on my pillow just at the moment, > > it might frighten the cats. > > > > A tidy shutdown of corosync is on my "to do" list so I'm open to > > suggestions. > > > > Chrissie > > _______________________________________________ > > Openais mailing list > > Openais@lists.linux-foundation.org > > https://lists.linux-foundation.org/mailman/listinfo/openais > > > _______________________________________________ > Openais mailing list > Openais@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
