| openstackgerrit | Scott Moser proposed stackforge/cloud-init: add cloud-init main https://review.openstack.org/202743 | 01:23 |
|---|---|---|
| openstackgerrit | Scott Moser proposed stackforge/cloud-init: add ReportingEventStack https://review.openstack.org/209045 | 01:50 |
| openstackgerrit | Scott Moser proposed stackforge/cloud-init: add ReportingEventStack https://review.openstack.org/209045 | 01:51 |
| openstackgerrit | Scott Moser proposed stackforge/cloud-init: add ReportingEventStack https://review.openstack.org/209045 | 01:52 |
| arnaud_orange | smoser: thanks for the tip yesterday | 07:39 |
| openstackgerrit | Claudiu Popa proposed stackforge/cloud-init: Make ReportingHandler a proper base class https://review.openstack.org/209454 | 10:49 |
| openstackgerrit | Claudiu Popa proposed stackforge/cloud-init: Make ReportingHandler a proper base class https://review.openstack.org/209454 | 11:12 |
| openstackgerrit | Merged stackforge/cloud-init: Make ReportingHandler a proper base class https://review.openstack.org/209454 | 11:26 |
| openstackgerrit | Claudiu Popa proposed stackforge/cloud-init: Add an API for loading a data source https://review.openstack.org/209520 | 13:40 |
| smatzek | smoser: Last week you mentioned a weekly 10ET Wed meeting. Is that going to be held here or on one of the openstack-meeting channels? | 14:02 |
| smoser | it'd be here. | 14:02 |
| smoser | and that is now. | 14:02 |
| smoser | and ... hm.. | 14:02 |
| Odd_Bloke | smoser: We're in the hangout. :) | 14:03 |
| claudiupopa | hey guys. | 14:03 |
| smoser | claudiupopa, Odd_Bloke i'm sprinting, not erally available for call. | 14:03 |
| claudiupopa | We're already here. | 14:03 |
| Odd_Bloke | smoser: Ack. | 14:03 |
| smoser | :-( | 14:03 |
| claudiupopa | Ah. | 14:03 |
| Odd_Bloke | smoser: Available for IRC meeting instead? | 14:03 |
| smoser | i've been working on the reporting stuff. | 14:03 |
| claudiupopa | Well, I think we can talk on IRC then. | 14:03 |
| Odd_Bloke | Or just plain busy? | 14:03 |
| smatzek | I'm on the phone on a sprint scrum as well. | 14:03 |
| smoser | Odd_Bloke, probably i can sort of do this. but i need to change location . so 5 minutes ? | 14:04 |
| Odd_Bloke | Well claudiupopa and I have abandoned the hangout. | 14:04 |
| Odd_Bloke | So we can meet here. :) | 14:04 |
| smoser | k | 14:05 |
| smoser | k. back. | 14:10 |
| Odd_Bloke | Cool. | 14:11 |
| Odd_Bloke | So I'm planning on _actually_ getting the webhook stuff done by the end of the week. | 14:11 |
| Odd_Bloke | At the very least an implementation without support for any sort of complex auth. | 14:11 |
| Odd_Bloke | And hopefully a patch on top of that to add OAuth. | 14:12 |
| smoser | Odd_Bloke, that would be fabulous | 14:12 |
| smoser | Odd_Bloke, i have a oauthhelper that i had worked on last niht that might be useful for you | 14:12 |
| smoser | the gist of it is in http://paste.ubuntu.com/12007052/ | 14:12 |
| Odd_Bloke | smoser: Oh, if you're already working on a web hook handler, why don't you just take that all the way and I can start looking at something else? | 14:14 |
| smoser | Odd_Bloke, and then the use of it http://paste.ubuntu.com/12007107/ | 14:14 |
| smoser | in that first paste, i changed the reporting a bit.. we can talk later. | 14:14 |
| smoser | claudiupopa, 'childrens_finish_info' is "the children's finish info" | 14:15 |
| smoser | as opposed to multiple childrens | 14:16 |
| smoser | that make sense > | 14:16 |
| smoser | wrt https://review.openstack.org/#/c/209045/4/cloudinit/reporting/__init__.py | 14:16 |
| claudiupopa | Ah, it wasn't obvious. ;-) | 14:16 |
| claudiupopa | smoser: by the way, a review of this and the general approach will be appreciated: https://review.openstack.org/#/c/209520/ | 14:17 |
| smoser | k. | 14:17 |
| smoser | if you want me to drop the s, i can do that. | 14:17 |
| claudiupopa | it's okay, it's not a big deal. | 14:18 |
| smatzek | can you refresh my memory on where / how the reporting framework will be used? I see it being used to write log entries. Will it also be used to send events for parallel datasource discovery? Is it also intended to be used if we do post-first boot configruation changes via some notifiation from the metadata service? | 14:22 |
| Odd_Bloke | smatzek: The intent is that it will be used to report on events that are happening in cloud-init; the log is the simplest case. | 14:23 |
| Odd_Bloke | smatzek: It will also be used to update MAAS/Juju on the status of instances as they come up. | 14:23 |
| smatzek | ok, and I could see a future use to notify OpenStack Heat? | 14:23 |
| smoser | primarily its "status" at this event. | 14:24 |
| smoser | so something (in this case maas or juju) could see that stuff is happening | 14:24 |
| smoser | or failing | 14:24 |
| Odd_Bloke | smatzek: Yeah, I don't see why not in principle. | 14:24 |
| smatzek | so given https://trello.com/b/HoPNdiTI/cloud-init-development-roadmap is the general direction of the work to get several of the datasources working and then move into the stages like the network stage and get the OS distros in likely as part of that? | 14:26 |
| smoser | yeah, we'd like to get the 'main' going. . i have a very stub branch for that | 14:27 |
| smoser | but we'd like a basic main first. | 14:27 |
| smoser | one that can find a datasource, and import ssh keys as iminila | 14:27 |
| smoser | Odd_Bloke, i'd appreciate your thoughts on these changes | 15:03 |
| smoser | http://paste.ubuntu.com/12007369/ | 15:03 |
| smoser | claudiupopa, what does list_all_modules actually do ? | 15:04 |
| claudiupopa | Getting all the modules that it can find, while list_valid_modules will return only those which are interesting for a particular finder. | 15:05 |
| claudiupopa | I'm working on changing the API, since I don't like it so much that implementation details leak outside (finder from pkgutil). | 15:05 |
| smoser | :) | 15:06 |
| smoser | but what does it do ? | 15:06 |
| smatzek | I've been studying that code for the past 30+ minutes and was working on some comments. | 15:07 |
| smoser | i dont basically want to stat every single possible python path | 15:07 |
| smatzek | We intend to reuse the finders for config modules and possibly distros right? We probably don't want to have the design be that the import of the module does some registration of the module given that. | 15:08 |
| smoser | that will be slow | 15:08 |
| smoser | right | 15:08 |
| claudiupopa | It will not stat every possible path, only those starting from a given root, such as cloudinit.sources. | 15:08 |
| smoser | ok, that wasnt clear. | 15:08 |
| claudiupopa | smatzek: yeah, that's the point, to reuse the same infrastructure for config modules. | 15:09 |
| claudiupopa | While distros are already loaded specifically. | 15:09 |
| claudiupopa | smoser: check cloudinit.sources.base.DataSourceLoader, that's the place where list_all_modules is used. | 15:10 |
| smoser | because of 'search_paths' | 15:11 |
| smatzek | my comment was in reply to Odd_Bloke's comment on BaseModuleFinder's find_module method. | 15:12 |
| smatzek | v0.7 has the ability to set the datasource list in cloud.cfg. This is very handy in customized images in private clouds. Could we get the ability to trim the datasource list before class initialization based on that in a future patch set? | 15:13 |
| claudiupopa | yeah, why not. | 15:14 |
| Odd_Bloke | smoser: It's much easier to see what the changes are if you submit a WIP code review. :p | 15:17 |
| Odd_Bloke | smatzek: I'm not sure I follow; if the registration is performed by the module, then the plugin loading code can be even more generic (as it doesn't need to know _what_ it's importing, just where it should be looking). | 15:18 |
| Odd_Bloke | I still don't actually have a strong opinion either way though. :p | 15:18 |
| Odd_Bloke | Except to say that if we want {meta,user,vendor}-data to supply plugins, then we are going to need to have a way for them to register themselves anyway. | 15:19 |
| === natorious is now known as zz_natorious | ||
| Odd_Bloke | smoser: So if you take the webhook stuff, I can look at what the next step towards getting something bootable is. | 15:23 |
| Odd_Bloke | Whether that is picking up your main stuff, or looking at a distro for Ubuntu. | 15:23 |
| smoser | i'd say picking up main, Odd_Bloke . | 15:24 |
| smoser | i will want some of your help... but i'll try to get you a review proposal | 15:24 |
| smatzek | I see your point. One thought is that we let the modules do the initialization / registering it would make it harder to use cloud.cfg to trim out datasources from beinig inited that you don't want or need in private clouds. | 15:25 |
| Odd_Bloke | True. | 15:30 |
| Odd_Bloke | Yeah, in fact, sold. | 15:30 |
| Odd_Bloke | We will need to do things differently for config though, I think. | 15:30 |
| Odd_Bloke | (Though probably not that differently) | 15:31 |
| openstackgerrit | Scott Moser proposed stackforge/cloud-init: add ReportingEventStack https://review.openstack.org/209045 | 15:33 |
| smoser | claudiupopa, or Odd_Bloke if you could review ^ | 15:49 |
| smoser | that'd be good. i have somethign to stack on top of it. | 15:49 |
| smoser | i think i addressed each of your concerns. | 15:49 |
| smoser | fudge. | 15:52 |
| smoser | and i jsut realize that having reporting/__init__.py call 'add_configuration' is a pita | 15:52 |
| smoser | as anyuthing that imports that gets the default config added | 15:52 |
| Odd_Bloke | smoser: Yeah, that's not necessarily a long-term thing. | 16:44 |
| Odd_Bloke | (As in, once we have actual configuration stuff, that should disappear) | 16:44 |
| smoser | Odd_Bloke, well, i think i have that coming | 16:46 |
| smoser | this is just so painful. | 16:46 |
| smoser | just getting there (not your code) | 16:46 |
| Odd_Bloke | smoser: A module should only get imported once, and be cached from then on. | 16:47 |
| Odd_Bloke | smoser: Are you seeing something other than that? | 16:48 |
| smoser | oh. | 16:49 |
| smoser | embarrasing i didn't know this. | 16:49 |
| smoser | so then your | 16:50 |
| smoser | add_configuration(DEFAULT_CONFIG) | 16:50 |
| smoser | will only be called once | 16:50 |
| Odd_Bloke | That _should_ only happen once. | 16:50 |
| smoser | thank you. | 16:50 |
| Odd_Bloke | Unless we're doing something weird (i.e. plugin loading). | 16:50 |
| smoser | right | 16:51 |
| Odd_Bloke | And even then, we might hit the module cache depending on how we do it. | 16:51 |
| Odd_Bloke | Looking at #209045 now. | 16:54 |
| smoser | https://gist.github.com/smoser/6714b6c741a6f658b41e | 17:30 |
| smoser | hey | 21:57 |
| smoser | harlowja, around ? | 21:58 |
| harlowja | sup dawg | 21:58 |
| smoser | http://paste.ubuntu.com/12010061/ | 21:58 |
| harlowja | cool | 21:59 |
| harlowja | u been busy | 21:59 |
| harlowja | ha | 21:59 |
| clouduser_ | hey. what is the key for setting the hostname. i see two are there. 'hostname' and 'local-hostname' does anyone know where these should be user-data/meta-data | 21:59 |
| harlowja | smoser feel free to use https://github.com/openstack/taskflow/blob/master/taskflow/types/tree.py if u want :-P | 21:59 |
| harlowja | seems like u made a tree like thing, ha | 22:00 |
| harlowja | if u so desire | 22:00 |
| smoser | i want to do update_configuration(DEFAULT_CONFIG, reset=True) to set instantiated_handler_registry | 22:00 |
| smoser | but it wants to set the local variable instantiated_handler_registry | 22:00 |
| smoser | what is the proper way to do that ? | 22:00 |
| harlowja | global instantiated_handler_registry in 'update_configuration' | 22:01 |
| harlowja | first line | 22:01 |
| harlowja | global instantiated_handler_registry | 22:01 |
| harlowja | *makes python know to look for global | 22:01 |
| smoser | i dint' know if that was generally considered accetpab.e | 22:01 |
| harlowja | other option | 22:02 |
| harlowja | make update_configuration a method on DictRegistry | 22:02 |
| smoser | clouduser_, https://github.com/openstack/taskflow/blob/master/taskflow/types/tree.py | 22:02 |
| harlowja | seeing that its like def update_configuration(config, reset=False): | 22:02 |
| harlowja | that makes me wonder if it should be `def update_configuration(self, reset=False):` | 22:02 |
| smoser | thanks i'll look at that | 22:05 |
| harlowja | suree | 22:06 |
| harlowja | smoser https://review.openstack.org/#/c/209661/ since i know u care, haha | 22:09 |
| harlowja | * no haha, serious talk only | 22:10 |
| === ijw_ is now known as ijw | ||
| smoser | harlowja, help my gerrit foo | 22:35 |
| harlowja | smoser ? | 22:36 |
| harlowja | whats up | 22:36 |
| smoser | http://paste.ubuntu.com/12010267/ | 22:36 |
| harlowja | git-review -R ? | 22:39 |
| harlowja | try that one instead i thnk | 22:39 |
| smoser | same thing | 22:39 |
| smoser | i have the the one review at https://review.openstack.org/#/c/209045/4 | 22:40 |
| smoser | and wanted to put another one that depended on it | 22:40 |
| openstackgerrit | Merged stackforge/cloud-init: add ReportingEventStack https://review.openstack.org/209045 | 22:40 |
| harlowja | hmmm | 22:41 |
| harlowja | typically what i do is say checkout the code @ https://review.openstack.org/209045 | 22:41 |
| harlowja | then add new code, commit it locally, then git-review -R | 22:41 |
| harlowja | which creates new review with parent of the other review | 22:42 |
| harlowja | typically that works for me :-/ | 22:42 |
| openstackgerrit | Scott Moser proposed stackforge/cloud-init: add unregister and reset to DictRegistry and use https://review.openstack.org/209696 | 22:51 |
| smoser | got there one way or another | 22:51 |
| smoser | https://review.openstack.org/209696 | 22:51 |
| harlowja | cools | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!