On 2/4/2010 at 02:52 PM, Yan Gao <y...@novell.com> wrote: > > Andrew Beekhof wrote: > > On Tue, Feb 2, 2010 at 6:14 AM, Yan Gao <y...@novell.com> wrote: > > > > [snip] > > > >> A configuration example: > >> .. > >> <acls> > >> <role id="operator"> > >> <write id="operator-write-0" tag="nodes"/> > >> <write id="operator-write-1" tag="status"/> > >> </role> > >> <role id="monitor"> > >> <read id="monitor-read-0" tag="nodes"/> > >> <read id="monitor-read-1" tag="status"/> > >> </role> > > > > [snip] > > > > Quick question, have you tried using crm_mon with a configuration like > this? > > I'm pretty sure you'll get nothing sensible as it can't find the resources. > Indeed. I ever thought that the information from "<status..." could be enough > for monitoring, while then realized both of the nodes and resources from > "<configuration..." are required. > > > > > Might want to think about how to deal with that... > We could either give some well defined ACLs for that, or is it possible that > crm_mon doesn't dependent on the info from "configration"? I don't think so... cib/configuration/resources etc. is the canonical source for what's configured, and may include things for which there is no status information yet. There's nothing in cib/status yet, for example, if the cluster is just starting up, yet crm_mon will still show you the configured nodes and resources. I've followed the same logic with Hawk, too, i.e. I'm interrogating cib/configuration to see what's meant to be there, then later check cib/status to see if it actually is.
Default ACL that grants everyone read access to configuration, maybe? Regards, Tim -- Tim Serong <tser...@novell.com> Senior Clustering Engineer, Novell Inc. _______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
