This bug was initially created as a copy of Bug #1637020

(In reply to Ken Gaillot from comment #9)
> (In reply to Patrik Hagara from comment #7)
> <snip>
> > > [root@virt-042 ~]# crm_resource --help
> > [...]
> > >      --validate		Call the validate-all action.  There are two different things that can be validated.  One
> > > 				method is to validate the resource given by the -r option.  The other method is to validate
> > > 				a not-yet-existing resource.  This method requires the --class, --agent, and --provider
> > > 				arguments, plus at least one --option argument.
> > [...]
> > 
> > * option present in manual page:
> > 
> > > [root@virt-042 ~]# man crm_resource
> > [...]
> > >    Commands:
> > >        --validate
> > >               Call  the  validate-all  action.   There  are  two  different  things  that can be validated.  One method is to validate the resource given by the -r option.  The other method is to validate a
> > >               not-yet-existing resource.  This method requires the --class, --agent, and --provider arguments, plus at least one --option argument.
> > [...]
> 
> These should say something like "and may take any number of --option
> arguments"
> 
> <snip>
> 
> > Issue #1: Is there any technical reason for having these 3 separate options
> > instead of using the pcs-esque syntax (ie. a single
> > "<class>:<provider>:<agent>" string, passed to eg. the "--agent" option
> > while getting rid of the others)? It really seems like a bad decision to me,
> > UX-wise.
> 
> Good point -- no, but it's already been released upstream, so it has to be
> kept for backward compatibility. I suppose we could accept either style. In
> any case, it's intended more for pcs to call rather than end users, so it
> won't really affect anyone.
>  
> > * validate not-yet-existing resource, no --option used:
> > 
> > > [root@virt-042 ~]# crm_resource --validate --class ocf --provider heartbeat --agent Delay
> > > Operation validate-all for test (ocf:heartbeat:Delay) returned: 'ok' (0)
> > > [root@virt-042 ~]# echo $?
> > > 0
> > 
> > Issue #2: Notice how the help text and manual page lie about the requirement
> > for --option usage.
> 
> as mentioned above
>  
> > * validate not-yet-existing resource, option name unknown to RA:
> > 
> > > [root@virt-042 ~]# crm_resource --validate --class ocf --provider heartbeat --agent Delay --option foodelay=2
> > > Operation validate-all for test (ocf:heartbeat:Delay) returned: 'ok' (0)
> > > [root@virt-042 ~]# echo $?
> > > 0
> > 
> > Issue #3: crm_resource reports 'ok' and successful exit code, even though an
> > option name unknown to the resource agent is used. If administrator decides
> > to actually create a resource with such option, an error is (correctly)
> > raised:
> > 
> > > [root@virt-042 ~]# pcs resource create foodelay ocf:heartbeat:Delay foodelay=1
> > > Error: invalid resource option 'foodelay', allowed options are: 'mondelay', 'startdelay', 'stopdelay', 'trace_file', 'trace_ra', use --force to override
> > 
> > I see no reason to ever use --force in the above command, and consequently
> > for crm_resource --validate to return success in such a situation.
> 
> This is actually an artifact of how the different components interact. pcs
> is the one enforcing the allowed options, not pacemaker or the resource
> agent -- so calling crm_resource directly skips that. When pcs implements
> its interface to this capability, it should do the same enforcement there.
> 
> It would also be possible for resource agents to make their validate action
> fail if given unrecognized parameters, but at this point, no resource agent
> does.
>  
> It's probably too late to get a new build just to update the help/man text,
> so we can open a separate BZ for that.