[17:16] rharper: finally got to what you were saying in standup about UserDataProcessor for read_file_or_url [17:17] cool [17:17] yeah looks like we handle the exception without raising it [17:17] and log the warning anyway. [17:17] so it's a no fail attempt [17:17] we either have processed user-data or not and log an error. [17:18] this would be a problem if we created a semaphore for set_hostname module, but since we're calling it directly we don't have to worry ™ [17:18] so, ideally we [17:18] d want to know in stages if we failed to process all user-data parts [17:19] and if so, call update a second time; [17:19] or, if we keep that inside the update() method (even in the userdata class, not sure about where we capture that knowledge) [17:19] but a second call would do nothing if it already processed everything, vs a second call (after networking is up) and it would "finish" processing [17:20] blackboxsw: yeah; that does work well [17:20] right it feels like UserDataProcessor would need an instance attr that says "fail hard in error" or something. [17:20] so we could react to a failed #include [17:20] will see where it makes sense [17:21] can we have gzip'd #includes too? [17:21] I dunno [17:21] nope doesn't look like it gzip exploding happens after #include attempts [17:22] ok I'll put something up and test it [17:22] thanks again gents