Added spec specs/unmanage_cluster.adoc

[shtripat]

Signed-off-by: Shubhendu shtripat@redhat.com

[shtripat]

@r0h4n @nthomas-redhat @julienlim @mbukatov plz check and ack

[shtripat]

Very understandable specification. Thanks

Thanks Jeff :)

[julienlim]

@shtripat @r0h4n @nthomas-redhat @mbukatov @jjkabrown1

The spec overall looks good. Just a couple things.

Is there a section for Logging impact? I'm guessing this is indirectly assumed right now.

How do we handle error handling? Specifically, if a user is looking at a Grafana dashboard about the cluster that is going to be unmanaged, what happens? I know some of this is out of our control, but it would be good to set some expectations on the expected behavior and if we have to document what to expect. Since it may provide a possible awkward experience on Grafana dashboard (where you're looking at a Dashboard and suddenly the data is archived and I'm assuming Grafana throws some kind of error message), do we want to consider some kind of warning message as part of the "Unmanage Cluster" action -- this depends on what kind of behavior we get from Grafana. Note: This may be an edge case we may say we choose to handle via documentation and take up later when users provide feedback about it.

Thoughts?

[shtripat]

@julienlim may be I would details under acceptance criteria about some expected behaviour on this. Also document impact I would add so that admin guide can set the proper expectations.

[julienlim]

@shtripat Sounds good!

[shtripat]

@julienlim the final alert raised post un-manage of the cluster, may mention that details from grafana dashboard and grafana alert dashboard would vanish post this. This would make sure user is aware of the expected behavior of this flow.

[shtripat]

@julienlim I have added few more expected behavior details as suggested above. Please check.

[julienlim]

@shtripat I reviewed the updates which include a few more expected behavior details. Looks good. Thanks.

[julienlim]

@shtripat @r0h4n @nthomas-redhat

Just noting some of our comments and questions that came up earlier: Unmanage cluster

• includes cleanup of data and will not stop any agents
• some of the cluster data is archived, i.e. logs and notifications
• what happens when you import again (to the notifications and logs tied to the old cluster id)? We will need maintain cluster entity so we don't end up with orphaned archived data.
• What happens with graphite archived data? Currently, there is no easy way to bring it back with current cluster, and we will leave it archived. Notification should provide link to where the data is archived (and we can address provide manual instructions if needed).

[shtripat]

Added UI impact details as well as part of spec. @julienlim @r0h4n @a2batic @nthomas-redhat @gnehapk please have a look.

[shtripat]

@gnehapk regarding jobs running for the cluster at a time, I have given a thought and find that at a time there would only one task active for cluster. I would suggest to rename the field import_job_id to cluster_job_id.

This field would get updated while import/unmanage and any other cluster flow happening for the cluster and UI can consume the same for any purpose.

@r0h4n @nthomas-redhat comments/suggestions?

[a2batic]

@shtripat @nthomas-redhat @r0h4n @gnehapk @cloudbehl, as discussion with @julienlim, we can add following points : -

For milestone 2:-

1. If cluster import fails or misconfigured, import button and unmanage button will be enabled. When user clicks on import button, user lands in import cluster view/page. If there was a previous import failed job, then modal shows up the and message should read something like "Import cluster previously failed with . Before Import, you need to correct the issue and then Unmanage the cluster." Followed by OK and cancel button.

2. In case of unmanage failure, provide a tooltip/info tip over failure message to say, "If unmanage fails, resolve the issue, then try Unmanage cluster again." We should show a message to say Unmanage Cluster failed followed by "View details (hyperlink)" in the cluster list.

Note: The design might change for milestone 3 as the cleanup option will be introduced @rghatvis, It might be a good idea to add these points as troubleshooting tips in docs.

[shtripat]

@a2batic ack. will update the spec accordingly

[shtripat]

@a2batic @julienlim I have added the points mentioned in https://github.com/Tendrl/specifications/pull/255#issuecomment-365674264 to the specifications document as well.

[mcarrano]

@julienlim and I have updated the wireframe designs on InVision to address how this should work for Milestone 3. https://redhat.invisionapp.com/share/8QCOEVEY9

Changes are included in the Cluster list view, Import page, and Import Task Details pages. Let us know if you have any questions.

[julienlim]

@a2batic @shtripat @gnehapk @r0h4n @nthomas-redhat @Tendrl/tendrl-qe @mcarrano

Please note that the Task Details design has changed to allow for showing multiple tasks within the same view through the use of a master-detail (table) design. Even if there is a single task, we would also follow this same design for consistency.

[nthomas-redhat]

Please note that the Task Details design has changed to allow for showing multiple tasks within the same view through the use of a master-detail (table) design. Even if there is a single task, we would also follow this same design for consistency.

@a2batic , can you create a separate issue to track this?

[r0h4n]

@Tendrl/specs Please approve individually