Improve platform detection failure semantics
Improve cloud detection failure semantics
A fallback datasource may be catastrophic, since if the configured & detected data source is unavailable, cloud-init may still go ahead with ssh key generation and other configuration tasks which modify the system, when more appropriate behavior would probably be to exit or disable itself. In other words: if the known datasource is unavailable, why should cloud-init do anything at all?
Does it really make sense to always include DatasourceNone in the datasource list created by ds-identify?
Are there any known users of this datasource?
Does anybody actually package the files that this datasource uses locally on an image for use?
Does DataSourceNone.py provide something that other datasources can't provide?
Institutional knowledge suggests that this is supposed to be a "final attempt datasource". Do users really need that? Since this datasource has behavior that is undocumented and provides features that overlap with NoCloud's CIDATA capabilities (use a configuration found on a local filesystem), is DataSourceNone.py a hard requirement for the future of cloud-init? If we feel the need to keep this behavior maybe be rolled into DataSourceNoCloud.py to use as a fallback for those that really want the old None behavior?
If this behavior is so important, why has it remained undocumented since inception?
Users need docs.