Description of problem: The guide contains the correct steps for setting up a "cumin" user in the cumin/broker configs, but it does not explicitly state why. Failure to do so will leave cumin operational assuming it has a valid broker connection but operations on jobs (submit, hold, remove, release, edit attributes) will not be possible. Find an appropriate place/way to make this explicit so that users are better informed. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Note to self re content, Because of BZ #693845, setting user/password information for cumin when connecting to a broker that allows anonymous authentication will actually cause cumin to receive no objects if the anonymous method is chosen Therefore, in the current state of the art these are rules: 1) user/password must be used for cumin to have job ops work. user must be cumin, no other. 2) sasl-mech-list in cumin.conf should always be restricted to PLAIN to make sure that anon is never used. 3) if PLAIN is not enabled by the broker, user/password must NOT be specified. In this configuration, cumin will not be able to use job ops but will see objects. So, users really ought to create the cumin user, set up the broker for PLAIN, and configure broker/sasl-mech-list in cumin.conf accordingly. Anything less than all three will not work satisfactorily and is strongly discouraged. Make this clear and concise.
Created attachment 528856 [details] Changes in new section 3.1.2
The issue was fixed in the upcoming version 2.1. -> VERIFIED
This book is now available on redhat.com/docs. Please raise a new bug if you spot any issues. Thanks, LKB