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