[13:49] morning [13:51] good morning sir. [13:51] I'd noticed the decorator properties in the http ds are not in the parent class. Is that intentional? [13:53] also noticed what you were referring to w/ network config returning and I'll fix that in the existing merge req [13:54] re prop decorator, I was thinking that would change the method signature and therfore not inherit/override [14:03] ok. [14:03] cloud-init meeting [14:03] hi. [14:03] hello natorious smoser claudiupopa [14:03] jgrimm, [14:03] Odd_Bloke, [14:03] o/ [14:03] \o [14:04] my bit.ly url for cloudinit-reviews somehow busted. :-( [14:04] so [14:05] http://bit.ly/cloudinit-reviews-public [14:05] i finally got around to reading claudiupopa's proposal at https://review.openstack.org/#/c/220095/ yesterday [14:06] talked with him a bit. i think we agree that openstack's config-drive and MD are odd fellows. [14:06] natorious, wonder if you have thoughts on that. [14:06] would xenstore on rackspace still be a possible datasource ? [14:06] yea, I don't see why not [14:07] the image would have to have some baked in deps to be able to access it like a store [14:07] but thats essentially how the openstack guest agents use it today [14:07] it woudl be the preferred one there ? [14:08] or do they now have openstack MD everywhere. [14:08] likely, yeah. Citrix makes it dead easy as a preferred [14:08] were doing http and configdrive too [14:08] citrix ? [14:08] XenServer [14:09] ok. [14:09] ok. so... how about this. [14:09] the one topic we have from last week was python2.6 . [14:09] and Odd_Bloke quickly pointed out that there are official python2.7 sources for centos and for redhat [14:10] in 'SCL's [14:11] that still leaves me sles to look at, but i went and built some images last week and have them in a local cloud so i can easily poke around. [14:12] so i think we can say 2.7 [14:12] then i guess move on./ [14:12] um [14:13] um ? [14:13] as in you dont like that? [14:13] to clarify, the products I'm currently working on dont use xenstore [14:13] at all [14:13] dunno the full context [14:13] does rackspace have any that to do your knowledge? [14:14] yea, their public cloud [14:14] this is how they mine that source too [14:14] https://github.com/rackerlabs/openstack-guest-agents-unix [14:15] so right now to get cloud-init to work w/ this guest agent [14:15] you have to tweak the boot order and deps [14:16] bc cloud-init pretty much requires networking to function properly and unless the guest agent has configured it, it wouldn't work [14:17] right. 0.7.x definitely does. [14:17] we were managing that ordering outside of the pkgs though [14:17] that is a primary goal to be addressed. [14:17] k, cool [14:18] i kind of talked a bit to the plan for that in my response to claudio [14:18] on boot, we have something that goes looking for "network config sources" [14:19] that thing blocks boot until it decides how your networking shoudl be configured. [14:19] it configures it, and then lets boot continue. [14:19] later in boot (when network comes up) [14:19] cloud-init again goes looking for a datasource for user-data, meta-data ... other things. [14:20] makes sense [14:20] i'll start trying to write this better into a spec [14:20] it is tricky [14:20] because figuring out what networking is supposed to be is not easy [14:21] and figuring out if this is config you've found should be applied (and possibly overwrite the user's config) is not easy either. ie, if this was a reboot. [14:21] honestly, ditching the "snapshot without clean" thing... woudl make things so much easier. [14:25] natorious, i'll look back above at your questions here in a minute. [14:25] and will try to write down my theory on boot order for cloud-init into a spec for review. [14:26] ty [14:35] I'd like to get this WIP configdrive merge request in today and have a few low fruit hangers left [14:36] or we still waiting for discussion? [14:37] natorious, i think we're done with meeting [14:37] ok... so wht do you want me to look at [14:37] oh, lol [14:37] so is the taskflow bit a + now that 2.7 works? [14:38] I'm finishing load and _get_data for the cd ds and I'll submit it as a WIP. There were some properties defined in the http ds that were not defined as properties in the base [14:39] wasn't sure if that was intentional [14:40] wrt taskflow, i dont know. still need to lok at that. it has quite a dependency chain. [14:40] also was hoping to chat a bit about BaseOpenStackSource.network_config [14:41] and my virutal-env pip install of taskflow jsut failed here... doign a c compile [14:42] i'll see if we can't strike that ctaskflow conversation up with Odd_Bloke later. who appears non-present. [14:42] ok. your questions. you want to go down the list of what you wrote before meeting ? [14:42] really its just _is_password_set in the http ds is set as a property but the BaseDataSource._is_password_set is not [14:43] smoser, are you cancelling next week meeting? or still planning to have while you are travelling? [14:44] well, yeah, i'm not going to be there. [14:44] but willsend mail to that affect and say that it can occur in my absense. [14:45] k [14:46] and the network_config bit which w/ network_json being its own format, should we still plan on returning the json data in those cases and the file content in the other? [14:46] like type check on the receiving end whatnot? [14:47] i think it shoudl be a property in the base class. [14:47] as we use it as one in the tests [14:48] ah right, I'll include that change in here then too [14:48] natorious and "file_content" ? you mean /etc/network/itnerfaces file ? [14:48] yea [14:50] the projects I'm working on are moving away from that to using network json but the way the ds classes are modeled would mean network_config could then return either or [14:50] just want to make sure that was acceptable [14:50] the end goal in my head is for cloud-init to read that network_json from its "network config source" (which here is an http source... see the tricky-ness of network config sources ? ) [14:51] and then turn that into an interneal representation of networking configuration and then render it. [14:51] right, so dhcp to static [14:51] since we have multiple different formats we're going to have to read. [14:52] network_json, /etc/network/interfaces, ec2 metadata format .. [14:52] if the ds class is to process each, its going to take me a bit longer on this [14:53] well, dont worry about "rendering" the network config for now. [14:54] k, so I'll just return it as is and look at either processing it outside of the ds or add to it when I get there [14:54] just have the datasource fetch it. have it available. and some future "render networking" thing will take that as input and do its job. [14:55] yeah. i think so. [14:55] for the configdrive ds there were a few base methods that didn't make sense too. Like post_password and is_password_changed [14:55] the base doesn't raise an exc so there could be unexpected results down the road [14:56] i think NotImplementedError makes sense at least initially [14:57] and thats all I got for now. Will try and get this w/ some tests in today sometime. I'll look at some network config bits after this too. Hopefully get something to test w/ :) [14:57] k [14:58] where are you traveling to? [14:58] seattle next week. [15:00] ah sweet. If you all end up going to the Austin, TX OpenStack Summit 2016, we should get up for sure [15:00] I live an hour away from Austin [18:20] claudiupopa, what would you use to render your specs/.rst ? [18:25] smoser https://pypi.python.org/pypi/restview [18:25] what i do is [18:25] restview -l :5000 specs/ [18:26] the open a webbrowsr @ localhost:5000 [18:26] and bam [18:26] 'Every time you reload the page, restview will reload the document from disk and render it. This is very convenient for previewing a document while you’re editing it.' is nice [18:27] thanks harlowja [18:27] np [18:36] Aaa, cool, didn't know about that, thanks. [18:36] its pretty nice [18:36] what i use for all my rst specs stuffs [19:12] i'm guessing there are other tools that do this, and you will just laugh at me, but i had 'venv' to do things like this. [19:12] https://gist.github.com/smoser/2d4100a6a5d230ca937f [19:12] then i just have a 'restview' file in my ~/bin/ [19:12] #!/bin/sh [19:12] exec venv restview restview "$@" [21:07] smoser cool, no idea, i have a tool that looks for a .venv on every 'cd' and tries to source it, and on leaving that directory exits the venv [21:07] that way i can have each repo i work on have a different venv, and just cd .. and all that will enter/exit it [21:08] https://gist.github.com/garyjohnson/394c58e22a2adfa103e2 and similar [21:08] various ones of those around === Guest62625 is now known as mfisch === mfisch is now known as Guest49167 === Guest49167 is now known as mfisch