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