Import Cluster: Changing from 2 options checkbox to 3 options radio button

[julienlim]

This enhancement and bug fix is spawned from Volume profile enabled/not-started info in tendrl #551, which has to do with confusion with enabling / disabling volume profiling during Import Cluster.

Related bugs that can provide further background information:

• Enable/Disable profiling doesn't work consistently #405
• BZ 'Disable' Volume Profiling during cluster import behavior

In addition to the 2 options of Enable Volume Profiling and Disable Volume Profiling, we need to allow for a 3rd option of Leave existing Volume Profiling configuration as-is (which may be a mix of volume profiling enabled and disabled within a given cluster).

Updated mockup for Import Cluster showing these 3 options in a radio button may be found at: Import Cluster Mockup.

Note: The expected behavior of the 3 options are as follow:

• Enable volume profiling - all volumes have volume profiling enabled
• Disable volume profiling - all volumes have volume profiling disabled
• Keep current configuration (of volume profiling) - leave existing volume profiling on the volumes as-is

See Volume profile enabled/not-started info in tendrl #551 for further details.

@gnehapk @a2batic @cloudbehl @mcarrano

[gnehapk]

Depends on Tendrl/api#350

[shtripat]

Depends on Tendrl/gluster-integration#553

[shtripat]

Based on @julienlim 's suggestion to have 3 options while import cluster flow for volume profiling enable/disable/leave as-is, I would suggest below changes in backend data model

Have two fields namely volume_profiling_flag and volume_profiling_state in Cluster object. The option selected while import cluster flow, would be maintained under volume_profiling_flag of cluster object which will have possible values of enable/disable/leave-as-is. Now as part of cluster data sync by GI, the value of volume_profiling_state at cluster level would be set based on the current state of volume reporting from CLI. The logic could be something like

if cluster.volume_profiling_flag == "enable":
    Enable profiling for all the volumes underlying
    cluster.volume_profiling_state = 'enabled'
if cluster.volume_profiling_flag == "disable":
    Disable profiling for all the volumes underlying
    cluster.volume_profiling_state = "disabled"
if cluster.volume_profiling_flag == "leave-as-is":
    Check the profiling state of underlying volumes and based on that
    if profiling enabled for all the volumes:
        cluster.volume_profiling_state = 'enabled'
    if profiling not enabled for any of the volumes:
        cluster.volume_profiling_state = 'disabled'
    if profiling enabled for few volumes:
        cluster.volume_profiling_state = 'mixed'
    Mark the volume.profiling_enabled field based on profiling enabled for underlying volume
cluster.save

UI should use the field volume_profiling_state for cluster and profiling_enabled for volume to show details in views.

@r0h4n @nthomas-redhat @julienlim @GowthamShanmugam comments?? suggestions??

[shtripat]

For backward compatibility, with older versions of glusterfs, as get-state doesnt report the profiling enabled information for volumes, all the volume.profiling_enabled would be set as None. In such a scenarios if user selects leave-as-is while import cluster for profiling, the value of volume_profiling_state for cluster could be marked as unkown as in reality its not known to us in this case.

[julienlim]

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

Ack. Looks good to me, and +1 on how to deal with older version of glusterfs that don't have the get-state for volume profiling support.

[gnehapk]

@julienlim @mcarrano @shtripat @nthomas-redhat @r0h4n How "Enable/Disable Profiling" action should work for cluster's mixed volume profiling status?

[julienlim]

@julienlim @mcarrano @shtripat @nthomas-redhat @r0h4n @gnehapk

Good question @gnehapk.

At the cluster level (after import), if supported by get-state, when enable profiling performed, volume profiling should be enabled on all volumes in the cluster even if it's mixed.

If disable profiling performed, then volume profiling should be disabled on all volumes in the cluster even if it's mixed.

If mixed and user wants to retain the existing mixed profiling, the user should not enable/disable the profiling. I think we may need to provide some kind "i" (infotip) or document this somehow.

Thoughts?

[shtripat]

Sorry fir just a thumps up above.
So I am in agreement with @julienlim here.

If after import the cluster level value if mixed we should have both enable and disable options available at cluster level. Back-end would take care of enabling/disabling accordingly as part sync for all the volumes of the cluster.

[gnehapk]

@julienlim Fixed with the milestone 3 release. Hence, closing it. Please open, if you see any issue,