[12:16] smoser, Odd_Bloke: any reason why cloudinit.logging is called `logging`? [12:16] Are we expecting it to always replace the builtin logging module? [15:16] Scott Moser proposed stackforge/cloud-init: add unregister and reset to DictRegistry and use https://review.openstack.org/209696 [15:17] Odd_Bloke, https://review.openstack.org/#/c/209696/ [15:17] it is nonobvious to me how to test the udpate_configuration [15:18] could you quickly add 2 ? [15:18] smoser: 2? [15:18] id ont know why i said 2 [15:19] i guess 3 [15:19] smoser: Oh, add some tests? [15:19] why isn't the reset separated? [15:19] one for reset, update and update_with_null [15:19] claudiupopa, as in you want to reset with no config [15:19] right? [15:19] yeah. [15:20] I tend to not like boolean flags that modifies something. [15:20] I mean functions with boolean flags. [15:21] Just a question, is expected from DictRegistry to be thread safe? [15:27] claudiupopa: No. [15:28] claudiupopa: But only because there was no reason to at this point, rather than from some deep opposition to thread-safe data structures. :p [15:33] claudiupopa, i think i'd just drop the 'reset' [15:34] and if you want reset, you just instantiated_handler_registry.reset() [15:34] smoser: yeah, that would be better imo. [15:41] smoser: If you still want me to add tests after that, let me know when I can pull the change to play with it. :) [15:42] Odd_Bloke, if you could, i'd really appreciate it. [15:43] smoser: Cool, give me a shout when it's ready. [15:44] Scott Moser proposed stackforge/cloud-init: add unregister and reset to DictRegistry and use https://review.openstack.org/209696 [15:44] Odd_Bloke, ^ [15:46] by the way. any reason why cloudinit.logging is called `logging`? [15:48] smoser: ^ [15:50] to be like loggin [15:50] logging [15:50] So we'll use that instead of the builtin logging module? [15:51] yeah. by name it is the same and the intent is it looks the same. [15:51] Because in that case, it should be made explicit in url_helper and templater. [15:51] as in from cloudinit import logging instead of a plain `import logging`. [15:52] Since absolute import is not activated in those modules. [15:52] you're right. those should use tcloudinit.logging [15:52] at least that is the intent. [15:52] good catch claudiupopa [16:00] smoser: Going in to a meeting now; will look at those tests in ~30 minutes. [16:05] k. [16:56] Claudiu Popa proposed stackforge/cloud-init: Add an API for loading a data source https://review.openstack.org/209520 [16:58] Odd_Bloke, smoser ^ still work in progress, but I'll appreciate a review regarding the direction. [16:59] so as you suggest4ed, https://review.openstack.org/#/c/209520/2/cloudinit/plugin_finder.py [16:59] shoudl have [16:59] from . import logging [16:59] right ? [17:00] Yeah, I noticed right now that. [17:00] Thanks. [17:03] https://review.openstack.org/#/c/209520/2/cloudinit/sources/openstack/httpopenstack.py [17:03] can we jsut tlak here.. ? [17:03] yeah. [17:03] Claudiu Popa proposed stackforge/cloud-init: Use an explicit absolute import for importing the logging module https://review.openstack.org/210035 [17:04] Daniel Watkins proposed stackforge/cloud-init: Add unregister and reset to DictRegistry and use https://review.openstack.org/209696 [17:05] so there, data_sources() does not know if it should do network data sources or local ? [17:05] smoser: I think it just needed the one test, which I've pushed up. [17:05] No, not at that point. [17:05] That was the intent of the strategies. [17:06] Which is a fancy word for implementing filters. [17:06] The idea is that if you want the network data sources only or any other kind of data source, you implement a strategy and you pass it to get_data_source. [17:06] Now I'm EOD'ing. :) [17:06] Odd_Bloke, htanks [17:07] I did it in this way since it really separates the concerns. [17:07] Each data source will not be interested in how it will be chosen. [17:08] claudiupopa, ok, i think thats probably fine, but the example strategy of 'serial' implied to me 'parallel' [17:08] yep. [17:08] At that point you can combine network + parallel. [17:08] Or any other combination you like [17:09] https://review.openstack.org/#/c/209520/2/cloudinit/sources/base.py [17:09] check valid_data_sources. [17:09] i think that is ok. ... but i want to be clear somehow when loading the datasource to search [17:09] that it does not have (or is not guaranteed) functional network [17:09] ie, the network could be wrong at this poitn an dit shoudlnt consider using it [17:10] yep, I see your point. Probably the actual strategies that will be used will be specific per each step in the stages. [17:28] claudiupopa, thats the real extent of my comemnts then i think [17:29] no other obvious issue? [17:31] thanks! [17:31] I'll push the tests tomorrow. [17:32] claudiupopa, can you https://review.openstack.org/#/c/209696/ ? [17:32] just as it is mine, i think you agree with it at this point. [17:32] can you push yes for workflow ? [17:33] yep, looks nice. [17:46] Merged stackforge/cloud-init: Add unregister and reset to DictRegistry and use https://review.openstack.org/209696