[01:39] burgerk, it tries loading it from cache before that [17:27] rharper, struggling with http://paste.ubuntu.com/23906228/ [19:03] smoser: looking [19:07] smoser: we've discussed that ds-identify may need to parse the on-disk cloud-config; that would certainly handle the config in one-place issue; it could be triggered only in the maybe paths (only check config if we're not sure); we may need a different not_found_behavior (disabled would be fully disabled and require detect to not result with any maybe answers?) [19:16] right now we dont really pay attention to ds_maybe [19:21] rharper, the issue really is just that right now the only way to read the cloud-inti configuration is with python-yaml. [19:21] and wanting to avoid that dearly [19:21] right, the python part [19:22] is grepping for a setting a reasonable replacement for extracting a single setting? [19:22] for example, we could check if we have a not_found_behavior: in /etc/cloud/* recursively [19:23] https://git.launchpad.net/~smoser/cloud-init/tree/tools/ds-identify?h=feature/ds-identify [19:23] see check_config [19:23] and its usage in dscheck_maas [19:25] yeah [19:25] that's roughly it [19:27] with that in place, on maybe, check if there's an overriding setting on what to for not_found_behaviors; on EC2 lookalike, it hits maybe , reads in-image config for not_found_behavior: and uses that if found, else uses the default (which is disabled). [19:28] possibly need to handle the in-image setting vs. the user-data setting (ie, user-data should take precedence over in-image data IIUC) === nacc_ is now known as nacc