[00:42] parllel data source discovery is not example of failurel there [00:43] as each would just append but never pop to stack [00:44] harlowja, Odd_Bloke thanks for thoughts. [00:44] sureeee [01:13] Merged stackforge/cloud-init: tests: use cloudinit.tests.TestCase everywhere https://review.openstack.org/206688 [05:15] smoser, i'm getting 'On 2015-07-31, 7 days from now, your membership [05:15] in the cloud init development team (cloud-init-dev) Launchpad team' ohhhh my goodddddddd [05:15] oops [05:15] 'On 2015-07-31, 7 days from now, your membership [05:15] in the cloud init development team (cloud-init-dev) Launchpad team [05:15] is due to expire.' [05:15] that one, ha [05:15] i don't wanna die [05:16] keeps on sending that daily, lol === natorious is now known as zz_natorious [09:06] smoser: Each DS would push on to the stack; you'd end up with .../ec2: started, .../ec2/openstack: started, etc. [12:30] Odd_Bloke, right. [12:33] So that would be a problem, no? [14:03] claudiupopa, Odd_Bloke harlowja [14:03] lets do cloud-inti meeting here. [14:04] roadmap is https://trello.com/b/HoPNdiTI/cloud-init-development-roadmap [14:04] hey. [14:04] Isn't the reporting merged? [14:05] I saw a couple of patches getting it last night. [14:05] reviews can be seen at http://bit.ly/cloudinit-reviews-public [14:05] reporting is in-progress. [14:06] the reporting infrastructure is there with a logging backend [14:07] but we'll still need a webhook [14:07] i started looking at getting that back to cloud-init 0.7 yesterday as I actually need it there RSN [14:07] I've moved the framework to done, and added a new card for the webhook. [14:07] Odd_Bloke, thanks [14:07] smoser: I feel like we also talked about another thing that needed doing there last week, but I can't remember what it was. [14:07] my main remains in stub form https://review.openstack.org/#/c/202743/ [14:10] today i have to focus the 0.7 reporting stuff [14:10] claudiupopa, if you want to take a look and thoughts on main, i'm happy to have input. [14:10] looking right now. [14:10] there s still a lot of infrasturcture thre that we need [14:11] * tie into reporting [14:11] * actually implement the search of datasources [14:11] claudiupopa, that was the one thing i went looking for you on. [14:12] didnt' really know how those should be loaded. [14:12] didnt take a huge look, but you werent in [14:12] right, I could write a patch for this. [14:13] basically getting all the possible data sources and calling .load on them. [14:14] If it returns, that data source is good to go. [14:14] right. that'd be good. [14:14] we can do serially loaded now [14:14] Probably with some filters, since you will probably want only the net datasources. [14:14] The problem is how to discover them. [14:14] I mean, where to look for the possible data sources cloud-init has. [14:15] ok. so lets do 2 paths [14:15] a.) directory relative to __file__ [14:16] b.) osys "plugins" path [14:16] under osys.plugin_path() we'd have a 'sources' dir. [14:16] we would look i guess in 'b' first and then in 'a' ? [14:17] osys.plugin_path() for returning the path of the data sources or the plugins (config modules)? [14:17] Since the name seems to suggest the latter. [14:18] What about using namespace packages? [14:19] Let me rephrase that. [14:19] (As everyone Googles namespace packages) [14:19] :p [14:19] Scott Moser proposed stackforge/cloud-init: add cloud-init main https://review.openstack.org/202743 [14:20] If we are using a plugin mechanism, I don't think we should have data sources be importable via normal means at all. [14:20] claudiupopa, i was saying the sources woudl be loaded from osys.plugin_path() + os.path.sep + "sources" [14:20] in one way or another. [14:20] Or we need to ensure that they are _all_ importable via normal means; even those that we don't distribute with cloud-init itself. [14:21] Odd_Bloke: makes sense. [14:21] Namespace packages would be one way of doing the latter. [14:21] Though they might be PITA on Python 2.6. [14:22] Odd_Bloke, for the very clueless (smoser) explain a bit more ? [14:23] So namespace packages basically let different Python "packages" distribute modules within a particular namespace. [14:24] So 'pip install cloud-init' could install cloudinit.sources.foo, and 'pip install cloud-init-obscure-cloud' could install cloudinit.sources.obscure_cloud. [14:24] Presumably downstream packagers have tooling to mirror this. [14:24] (Certainly we do, I think oslo is distributed this way) [14:25] Odd_Bloke: how does the discovery works in that case? Is there an api for retrieving the packages from a given root point? [14:25] Not very familiar with them either ;-) [14:25] We would still need a discovery mechanism, I think. [14:25] :) [14:25] thanks for asking for me, claudiupopa . i'm aware you're just trying to make me feel like less of an idiot [14:26] Possibly our best bet here is to describe what we want from a plugin-type system, and let claudiupopa go away and work something out. [14:26] Then we can tell him he's wrong next week. ;) [14:26] ;-) [14:27] But I feel like if we're diving in to the paths that plugins will be loaded from, we may be dismissing other solutions. [14:27] ok. claudiupopa you want to think about that a bit ? you can add a card there if you want. [14:27] Odd_Bloke, how so ? [14:27] Odd_Bloke, i very much want to be able to document "if you put sources in this static directory path, then cloud-init will find them" [14:27] and the same for config modules [14:28] and part handlers [14:28] and such [14:28] Yeah, absolutely. [14:28] yeah, I'll look into this, since it's something that I should do for cloudbase-init as well. [14:28] i dont care necessarily how we get there, but that is something i want. [14:28] But, for example, do we mean static, or do we mean static-relative-to-the-cloudinit-python-package? [14:29] And if the former, where in the FHS should that live. [14:29] etc. [14:29] I'm on another call now, so I won't reply for a while. [14:29] But will catch up when I'm off. [14:30] Odd_Bloke, we mean both. [14:30] :) [14:30] as in ubuntu packages should be able to install sources alongside of cloudinit. [14:31] and vendors or developers shoudl be able to put them in /var/lib/cloudinit/sources [14:38] smoser: left a couple of comments on the main executable thing. [14:39] claudiupopa, thank you! [14:41] yeah, the last comment does not make sense. [14:41] On the review I mean. [14:42] it confused me [14:42] You mean val.get('opts', {})? Otherwise the unpacking will fail in the case opts does not exists. [14:42] isn't that what i have ? [14:42] (i was typing that there) [14:43] Yeah, I didn't notice that opts is already a tuple and for a, b in {} works, since it's empty. [14:44] ok. i see. does *not* make sense. [14:44] i completely ignored the word 'not' above [14:57] smoser: I haven't used it, but do you think it's worth having the meeting bot for these weekly meetings? [14:58] i'm not opposed to it. [14:58] i went asking for ubuntu logger bot the other day [14:58] *really* want that [14:59] i dont really care about the meeting bot so much [14:59] but want logging and "bug links" [14:59] Better record an action with the meeting bot. [14:59] ;) === zz_natorious is now known as natorious === natorious is now known as zz_natorious [17:20] sup [17:20] u guys want to have meetings? [17:21] like via http://eavesdrop.openstack.org/ ? [17:21] 'Meeting schedule' there? [17:47] I would be in favor of scheduled meetings to discuss design, direction, issues, etc. I actually have to drop now so I can't chat more, just putting my 2 cents in. [17:58] harlowja, smatzek well, we kind of have a 10:00 US/Eastern meeting on Wednesdays [17:58] and you're both invited. [17:58] ah [17:58] damn thats like super-early [17:58] lol [17:58] * smoser thinks that smaztek is less lazy than harlow and might be up then [17:58] ha [17:58] yeah, 10:00 sure is early [17:58] 7am [17:58] (my time) [17:58] relocate to where the sun shines in proper hours [17:58] lol [17:59] hey, you can probably help me [17:59] well i was gonna move into your basement [17:59] looking at my main thingy [17:59] butttt u already occuping your basement [17:59] https://review.openstack.org/#/c/202743/5 [17:59] u have killed it [17:59] lol [17:59] *killed jenkins, lol [17:59] i addressed / was addressing cladiu's request to not pass function names in but actually callables [17:59] k [18:00] but then my test started to fail because mock mocks "too late" I think [18:00] what is there + http://paste.ubuntu.com/11961057/ [18:00] shows the issue. mock doesnt realize that main_version got called [18:01] but it very clearly does [18:01] http://paste.ubuntu.com/11961063/ [18:01] hmm [18:02] ya, its probably all those functions getting captured into SUBCOMMANDS [18:02] right. [18:02] SUBCOMMANDS gets a reference [18:02] and mock doesnt patch that ref. [18:02] right [18:02] if its get_subcommands() that returns a dictionary, i wonder if it would work then [18:03] late binding them [18:03] *could even return the same dictionary, but python binding i think will then happen when the dictionary is created, and therefore mock can affect things [18:03] :) [18:04] i think i'm gonna just drop the test as it doesn't actualy do anything that wasn't done other place. [18:04] or that [18:04] as i was testing hat main_version has expected output :) [18:04] ya, those kind of tests i always wonder about [18:04] aka, sorta feel they are useless lol [18:07] Scott Moser proposed stackforge/cloud-init: add cloud-init main https://review.openstack.org/202743 === zz_natorious is now known as natorious