Unmanged clusters should have a property 'task_id' which will correspond to import task in clusters API.

[gnehapk]

This is required to fetch import task details for unmanaged cluster.

[shtripat]

@gnehapk As discussed I would certainly support to have a global tasks list, which dont belong to a specific cluster. The import cluster tasks could be under this kind of tasks and there could be a separate accessor set in UI for these tasks (may be at op right corner icon). @julienlim need your suggestions here.

As a workaround as you suggested @gnehapk , under detected cluster entity there could a task_id field which should be populated and returned. This field would be populated only in scenario when import is still under progress and cluster is un-managed / not imported yet.

@r0h4n suggestions?

[julienlim]

@gnehapk @shtripat @Tendrl/tendrl-core @Tendrl/tendrl-qe @mcarrano

Both proposals mentioned above by @shtripat would work. With regards to the global tasks list, there are some tasks that are not cluster specific, e.g. CRUD user, configure SNMP, configure SMTP, change user settings. You could certainly add important cluster as a task in this scenario, whereby until a cluster "is managed."

My concern from a UI/UX perspective is that with exception to the import cluster task, the others don't seem to lend themselves that well as tasks unless we handle some kind of cluster-to-cluster operations (excluding geo-replication) some day.

For the UI, we do have an existing design where we provide a way to see Global tasks lists (as part of the bell icon in the top right to see both alerts and tasks in the drawer widgit). However, until we have a good case for a global tasks list, I'd be reluctant to expose a separate way to access these global tasks just for handing Import Tasks, especially since we'll be providing a way to access the Import Task Details in context of the cluster itself.

Related References:

• Enable unmanage cluster in tendrl

[shtripat]

@gnehapk I would suggest to have indexes created like indexes/tasks/{int-id} and this would maintain a list of tasks on the cluster. @r0h4n comments?

Similarly in other places for bricks etc we should have indexes/bricks/nodes/{node-id} and this maintains a list of brick-ids. At cluster level it could be like indexes/bricks/clusters/{int-id} and this maintains list of brick-ids for cluster.

@r0h4n comments?

[r0h4n]

please use Cluster.import_job_id , it is the original task id