-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tendrl need to support expand cluster functionality for gluster cluster #805
Comments
@r0h4n @julienlim @mcarrano @nthomas-redhat @brainfunked |
@shtripat @r0h4n @nthomas-redhat @brainfunked @mcarrano @Tendrl/tendrl-qe With regards to expand cluster, why does a user have to accept newly discovered hosts for monitoring? If new volumes or bricks get added, does that mean user has to accept them too? IMHO, cluster expansion or changes should automatically be detected without user having to do anything -- specifically, user should not have to unmanage the cluster, then reimport the cluster, in order for the new nodes/peers to be recognized. Is there a way for automatic expansion in the Tendrl UI without the user having to unmanage and reimport the cluster? Meaning, all User does is add the peers/nodes to the Gluster cluster, then User adds the Tendrl agents onto the new nodes, and starts/enables the agents, generates relevant dashboards for the nodes. Tendrl detects and adds a notification about new nodes detected and now added for management under Tendrl. Those nodes should then automatically show up in cluster details, hosts list (for the cluster), etc. without further user intervention. |
@julienlim my bad for using the word Regarding automatic expansion in tendrl, yes its not there at the moment and this issue is for tracking changes for the same feature. |
Based on latest discussion below would be the flow for automatic expansion of the cluster
Finally the new node is part of the new cluster now. Note: As part detecting a new node in the cluster, the discovery logic needs changes to recalculate the clusterid (based on new set of peers and their pool-id from gluster) and update the cluster details. @r0h4n @julienlim @nthomas-redhat @mbukatov kindly review and ack this. |
Is the import (new_node) flow enabled automatically (or, without admin intervention)? |
@sankarshanmukhopadhyay the expansion of cluster in tendrl would be automatic, once node-agent gets installed on new node by tendrl-ansible. |
Ack @shtripat Just one thing that I mentioned in person, i.e. appropriate log messages (i.e. eventing / alerting) needs to be generated -- specifically to detect new node and provide an alert about it and tell user what they need to do, i.e. use tendrl-ansible to install tendrl agents on the node. As well, it should also provide an event for when the node begins to be under Tendrl management. |
@julienlim Ack |
This flow would be invoked from tendrl-node-agent on the additionally detected new peers of the cluster. New nodes would be provisioned with monitoring etc and imported into the cluster in tendrl system. tendrl-bug-id: Tendrl#805 Signed-off-by: Shubhendu <shtripat@redhat.com>
tendrl-bug-id: Tendrl#805 Signed-off-by: Shubhendu <shtripat@redhat.com>
This done on the backend as of Milestone 3 2018 and new nodes will be auto expanded (after peer probe and after running tendrl-ansible on new ndoes) until below TODOs are done TODO
@Tendrl/api @Tendrl/frontend @Tendrl/ux please note |
@r0h4n @Tendrl/api @Tendrl/frontend @Tendrl/ux Design updates have been posted at https://redhat.invisionapp.com/share/8QCOEVEY9. See #849 (comment) for further details. |
The peers list in tendrl central store would take sometime to reflect and initially the no od peers would be equal to no of managed nodes of cluster. So using this condition would cause issue. Rather we should check the no of managed nodes of cluster against actual peers list from underlying cluster and once they are same raise the clearing alert. tendrl-bug-id: Tendrl/commons#805 Signed-off-by: Shubhendu <shtripat@redhat.com>
The peers list in tendrl central store would take sometime to reflect and initially the no od peers would be equal to no of managed nodes of cluster. So using this condition would cause issue. Rather we should check the no of managed nodes of cluster against actual peers list from underlying cluster and once they are same raise the clearing alert. tendrl-bug-id: Tendrl/commons#805 Signed-off-by: Shubhendu <shtripat@redhat.com>
The new mockups are implemented. Please comment if any mismatch |
Expand cluster mechanism currently in tendrl is not very seamless.
User needs to un-manage the cluster and then extend the cluster by adding new peers. After this the cluster needs to be imported.
Ideally tendrl should be able to figure out new peers introduced in the cluster while cluster is being managed by tendrl. User should be prompted to accept the newly discovered host for monitoring / management through tendrl.
The text was updated successfully, but these errors were encountered: