[18:09] <cjp256> holmanb:  i noticed that with the ds_detect changes that the datasource no longer will fall back to None as it had with is_platform_viable() check in get_data().  Specifically in the case of Azure, the ds-identify or user ds config would be [Azure, None] and get_data would bail if detection failed with something like "No local datasource found".   End result is customers using that config on non-Azure platforms now end up 
[18:09] <cjp256> executing the _get_data() path as if on Azure, causing some issues
[18:11] <cjp256> I notice that ds-identify detection for Azure is broader than the ds_detect method, which I think we need to unify too
[18:42] <holmanb> cjp256: agreed on ds-identify / ds_detect disparity - those should match
[18:44] <holmanb> cjp256: iirc checking datasource_list in override_ds_detect was proposed during review as an optimization do avoid re-checking what ds-identify already checked - in that case [Azure, None] is expected I think
[18:46] <holmanb> cjp256: if [Azure, None], I believe it will still fall back to None whenever get_data() times out
[18:46] <holmanb> *to avoid re-checking
[18:52] <holmanb> cjp256: When customer provides [Azure, None] and cloud-init runs _get_data() is this just a change in expected behavior in a failure path? Or is fallback to DataSourceNone a normal behavior in user workflow?
[18:52] <cjp256> normal behavior if image is used outside Azure
[18:54] <cjp256> right now that timeout is a pretty long wait so ideally we’d like to go back to skipping that path if detection determines it won’t (shouldn’t) work
[21:09] <cjp256> holmanb: what do you think about https://github.com/canonical/cloud-init/pull/4426
[21:45] <holmanb> cjp256: seems reasonable to me, I think