When using F5::Cm::Sync, the end user is required to dictate a specific DSG they want to sync, but what is reported as success is the global device sync status. This is an error. Either we remove the DSG as an import property and globally sync the device, or we leave it and build in the logic to understand what must be done to fulfill the end user request.
Since the iControl REST API does not expose the individual DSG sync state, if we are going to continue to require the end user to include the DSG they wish to sync, then we must also include the logic to make synchronizing a possibility. For instance... if there is different DSG then the one specified to F5::Cm::Sync which must be manually synchronized by design which would block the global sync state from becoming 'in-sync', then the appropriate behavior would be to force sync those DSGs and then the one specified by the end user. Only then can the global device sync state have a possibility of reaching 'in-sync' for the end user.
When using F5::Cm::Sync, the end user is required to dictate a specific DSG they want to sync, but what is reported as success is the global device sync status. This is an error. Either we remove the DSG as an import property and globally sync the device, or we leave it and build in the logic to understand what must be done to fulfill the end user request.
Since the iControl REST API does not expose the individual DSG sync state, if we are going to continue to require the end user to include the DSG they wish to sync, then we must also include the logic to make synchronizing a possibility. For instance... if there is different DSG then the one specified to F5::Cm::Sync which must be manually synchronized by design which would block the global sync state from becoming 'in-sync', then the appropriate behavior would be to force sync those DSGs and then the one specified by the end user. Only then can the global device sync state have a possibility of reaching 'in-sync' for the end user.