Red Hat Bugzilla – Bug 221869
Adding an existing cluster via luci - unauthenticated node accepted as cluster member - cannot be deleted via luci
Last modified: 2009-04-16 18:33:55 EDT
Description of problem: Adding an existing cluster via luci - unauthenticated node accepted as cluster member - cannot be deleted via luci See the steps below and screen shot-attachments for the sequence of actions. Version-Release number of selected component (if applicable): ricci-0.8-26.el5 luci-0.8-26.el5 How reproducible: 100% Steps to Reproduce: 1. Create a multiple node cluster outside of luci. For my testing, I used a 5-node cluster (tng3-1.lab.msp.redhat.com thru tng3-5) 2. Start up the ricci service on all nodes, also start up the luci service on one node (in my case, tng3-5) 3. Access luci, select 'add an existing cluster' 4. Intentionally specify an invalid password for one of the nodes to cause an authentication error (in my case, node tng3-2) 5. luci reports the authentication failure, but adds the cluster to its cluster list. (see screenshot attachment #1 [details]) 6. The unauthenticated node is listed in the cluster's node list (see screenshot attachment #2 [details]) - but it's display does not list the cluster daemons (see screenshot 3) 7. Luci correctly reports that the node is not authenticated if the user attempts to retrieve a log from the node (see screenshot attachment #4 [details]) 8. But the user cannot delete the node from the cluster via luci as luci cannot authenticate to the node (see screenshot #5) 9. The user can clear up the situation by deleting the unauthenticated node from the 'manage systems' menu, and then re-adding it, this time with the correct password. Actual results: See the screenshots. Expected results: I would have expected luci to not add the cluster to its list if all the nodes were up, but failed to authenticate. Or, is this really a usability issue? The luci web app does not include an explicit "reauthenticate" option - instead, the user deletes and adds back the unthenticated node. But - if the node is unauthenticated, should it really appear in the system list at all? Additional info: See the screenshots.
Created attachment 145078 [details] Screenshot 1 of 5
Created attachment 145080 [details] Screenshot 2 of 5
Created attachment 145081 [details] Screenshot 3 of 5
Created attachment 145082 [details] Screenshot 4 of 5
I think everything here is working as expected. Luci needs to be able to add existing clusters with nodes that are either down or where ricci is not working correctly (or else one down or misbehaving node would prevent management of the whole cluster by Luci). Nodes that are not properly authenticated will not be fully functional as far as Luci is concerned, but they may be perfectly functional cluster members. In the latest scratch build of Luci, there is a checkbox option "add this cluster as-is" with the note that any nodes that are not authenticated will need to be authenticated later via the reauthenticate functionality in the manage systems section. I think there may also be some confusion regarding the authenticate functionality provided in the manage systems page. The purpose of this is only to reauthenticate to systems that either could not be propertly authenticated upon addition or systems that may have been reimaged causing their SSL certs to either change or be lost. In the latest scratch build, the header was changed from "Authenticate to ..." to "Reauthenticate to ..." to try to make this more clear. No systems are actually added to Luci using this form; it's strictly for reauthentication when something has gone wrong. Could you try this again using the lastest scratch build and re-open the bug if you think something is still wrong?
Created attachment 145084 [details] Screenshot 5 of 5
I think that the two changes that you mention: -> Title "add cluster as is" -> Title "reauthenticate" Will help avoid user confusion. But, how does a user re-authenticate a node? Which tab/menu/selection? Thanks!
P.S. Here's a related problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221881