[01:39] <smoser> burgerk, it tries loading it from cache before that
[17:27] <smoser> rharper, struggling with http://paste.ubuntu.com/23906228/
[19:03] <rharper> smoser: looking
[19:07] <rharper> 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] <smoser> right now we dont really pay attention to ds_maybe
[19:21] <smoser> rharper, the issue really is just that right now the only way to read the cloud-inti configuration is with python-yaml.
[19:21] <smoser> and wanting to avoid that dearly
[19:21] <rharper> right, the python part
[19:22] <rharper> is grepping for a setting a reasonable replacement for extracting a single setting?
[19:22] <rharper> for example, we could check if we have a not_found_behavior: <string> in /etc/cloud/*  recursively
[19:23] <smoser> https://git.launchpad.net/~smoser/cloud-init/tree/tools/ds-identify?h=feature/ds-identify
[19:23] <smoser> see check_config
[19:23] <smoser> and its usage in dscheck_maas
[19:25] <rharper> yeah
[19:25] <rharper> that's roughly it
[19:27] <rharper> 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] <rharper> possibly need to handle the in-image setting vs. the user-data setting (ie, user-data should take precedence over in-image data IIUC)