smoser | parllel data source discovery is not example of failurel there | 00:42 |
---|---|---|
smoser | as each would just append but never pop to stack | 00:43 |
smoser | harlowja, Odd_Bloke thanks for thoughts. | 00:44 |
harlowja | sureeee | 00:44 |
openstackgerrit | Merged stackforge/cloud-init: tests: use cloudinit.tests.TestCase everywhere https://review.openstack.org/206688 | 01:13 |
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:15 |
harlowja_still_a | keeps on sending that daily, lol | 05:16 |
=== natorious is now known as zz_natorious | ||
Odd_Bloke | smoser: Each DS would push on to the stack; you'd end up with .../ec2: started, .../ec2/openstack: started, etc. | 09:06 |
smoser | Odd_Bloke, right. | 12:30 |
Odd_Bloke | So that would be a problem, no? | 12:33 |
smoser | claudiupopa, Odd_Bloke harlowja | 14:03 |
smoser | lets do cloud-inti meeting here. | 14:03 |
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:04 |
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:05 |
smoser | the reporting infrastructure is there with a logging backend | 14:06 |
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:07 |
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:10 |
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:11 |
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:12 |
claudiupopa | basically getting all the possible data sources and calling .load on them. | 14:13 |
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:14 |
smoser | ok. so lets do 2 paths | 14:15 |
smoser | a.) directory relative to __file__ | 14:15 |
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:16 |
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:17 |
Odd_Bloke | What about using namespace packages? | 14:18 |
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:19 |
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:20 |
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:21 |
smoser | Odd_Bloke, for the very clueless (smoser) explain a bit more ? | 14:22 |
Odd_Bloke | So namespace packages basically let different Python "packages" distribute modules within a particular namespace. | 14:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
smoser | and vendors or developers shoudl be able to put them in /var/lib/cloudinit/sources | 14:31 |
claudiupopa | smoser: left a couple of comments on the main executable thing. | 14:38 |
smoser | claudiupopa, thank you! | 14:39 |
claudiupopa | yeah, the last comment does not make sense. | 14:41 |
claudiupopa | On the review I mean. | 14:41 |
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:42 |
claudiupopa | Yeah, I didn't notice that opts is already a tuple and for a, b in {} works, since it's empty. | 14:43 |
smoser | ok. i see. does *not* make sense. | 14:44 |
smoser | i completely ignored the word 'not' above | 14:44 |
Odd_Bloke | smoser: I haven't used it, but do you think it's worth having the meeting bot for these weekly meetings? | 14:57 |
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:58 |
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 | ;) | 14:59 |
=== zz_natorious is now known as natorious | ||
=== natorious is now known as zz_natorious | ||
harlowja | sup | 17:20 |
harlowja | u guys want to have meetings? | 17:20 |
harlowja | like via http://eavesdrop.openstack.org/ ? | 17:21 |
harlowja | 'Meeting schedule' there? | 17:21 |
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:47 |
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:58 |
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 | 17:59 |
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:00 |
smoser | but it very clearly does | 18:01 |
smoser | http://paste.ubuntu.com/11961063/ | 18:01 |
harlowja | hmm | 18:01 |
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:02 |
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:03 |
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:04 |
openstackgerrit | Scott Moser proposed stackforge/cloud-init: add cloud-init main https://review.openstack.org/202743 | 18:07 |
=== zz_natorious is now known as natorious |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!