[14:08] <smoser> claudiupopa, lets just do this here then.
[14:08] <smoser> i owe you some stuff and let me do that now.
[14:08] <smoser> the thing i found yesterday was that trunk was not running 'tox' for me. complaining about windows dlls
[14:08] <claudiupopa> Okay, don't know what's with my sound.
[14:09] <claudiupopa> cloud-init v2 trunk?
[14:10] <smoser> yeah
[14:10] <smoser> i'll get pastbin
[14:11] <smoser> Odd_Bloke, was seeing it too.
[14:13] <openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add the data source base classes and the HTTP OpenStack implementation  https://review.openstack.org/188327
[14:14] <smoser> claudiupopa, http://paste.ubuntu.com/11767934/
[14:14] <claudiupopa> does it still reproduces?
[14:14] <smoser> yeah. that is trunk on my system right now.
[14:14] <smoser> ImportError: cannot import name 'windll'
[14:15] <smoser> which isnt terribly surprising :)
[14:16] <claudiupopa> Yeah, will take a look, thanks. ;-)
[14:16] <claudiupopa> So..back to bussiness. The openstack stuff should be finally done, after Joshua's final comments.
[14:16] <claudiupopa> I didn't had time to work on other things yet, had some issues with cloudbase-init which needed to be fixed.
[14:17] <claudiupopa> Did you had time to work on the executable part?
[14:19] <smoser> no. because i'm not very productive.
[14:19] <smoser> i will look at your openstack stuff now.
[14:25] <claudiupopa> the crash makes sense. sphinx-autodoc tries to import the modules in order to build the documentation.
[14:25] <claudiupopa> but windll exists only on windows.
[14:26] <claudiupopa> Either we can ignore windows-specific files, but that's hard, since they can be all over the place, or we can write something that does this statically.
[14:26] <claudiupopa> without needing to import the module.
[14:28] <smoser> its not something ew can easily fudge either.
[14:29] <smoser> ie, we can't just make a load_os_specific('windll', 'windows')
[14:29] <smoser> that would just return garbage on linux. because you use stuff from it right away
[14:29] <smoser>  windll.kernel32.GetLastError
[14:29] <claudiupopa> Right, that's the case.
[14:31] <smoser> we could proably manage it.
[14:31] <smoser> but if this is just going to be a endless path doesn'st sound like fun
[14:32] <claudiupopa> so doing something statically makes the most sense.
[14:32] <claudiupopa> I'll try to see if I can come up with a sphinx plugin.
[14:32] <claudiupopa> Which operates on ast instead of objects.
[14:35] <smatzek> this is a complete hack but it may work as a temporary solution, something like this in kernel32.py: if os.name == 'posix':
[14:35] <smatzek>     import mock
[14:35] <smatzek>     sys.modules['ctypes.windll'] = mock.MagicMock()
[14:36] <smatzek> I've temporarily done the same in reverse to mock out Linux/posix only python modules to run things on Windows
[14:50] <smoser> claudiupopa, on 'ast' ?
[14:50] <claudiupopa> abstract syntax trees
[14:50] <smoser> will it be an endless path ?
[14:51] <smoser> ie, if we mock those names to None on non-windows, ould that be an endless amount of ongoing work
[14:51] <claudiupopa> yeah, that definitely could be.
[14:54] <patcable> stupid question: do i have to run the brpm scripts on a rhel/centos machine when building cloud-init?
[14:55] <patcable> wasnt sure if there was a way to just run it on my ubuntu dev box as well. figure i just need to make stuff work over in RH land.
[15:08] <smoser> patcable, ?
[15:08] <smoser> the brpm is just a way to get you an rpm. that would hopefully work.
[15:08] <smoser> on ubuntu you can get a deb with bdeb
[15:09] <patcable> smoser: right-- bddeb works great on an ubuntu box, brpm complains about not having some centos packages around. I suspect that I probably need to build the rpms on a centos box, but I wanted ot check
[15:11] <smoser> ah. i understand the question now
[15:12] <smoser> yeah, you need to run that on centos. if you got it to run on ubuntu, patches would probably be accepted, but generally i'd expect to build it on centos.
[15:12] <patcable> that's fine, just wanted to make sure I wasn't missing anything
[15:14] <patcable> thanks!
[15:17] <patcable> we've been hacking to see if we can add support in for handling a user config that has been encrypted, to sort of make a "trusted" cloud init. it's very young right now, though it does work
[15:21] <smoser> patcable, neat.
[15:23] <patcable> yeah. Looking forward to writing about it/proposing patches when we have something that actually works for real :)
[15:39] <smoser> claudiupopa, still there?
[15:39] <smoser> what is _METADATA_NETWORK_KEY = "content_path"
[15:46] <claudiupopa> content_path is an entry from under network_config, with a path for a debian interfaces file.
[15:46] <claudiupopa> http://sprunge.us/KDRX something along these lines
[15:54] <smoser> claudiupopa, ok. i have some very tiny comments.
[15:54] <claudiupopa> sure thing
[15:54] <smoser> i think i'm fine to pull it because i've taken so long, and we can fix them later if you want.
[15:55] <claudiupopa> if it's not too time consuming, I could fix them right away.
[15:56] <smoser> http://paste.ubuntu.com/11768400/
[15:56] <smoser> claudiupopa, ^
[15:57] <smoser> metadata_network_key was just confusing to me since its not network specific in any way. its more "referenced_payload_key" or something.
[15:57] <claudiupopa> cool, thanks!
[15:59] <smoser> i did not test that regex. its probably wrong
[15:59] <smoser> i just figure if we're looking for YYYY-MM-DD, we might as well check for that expicitly
[15:59] <smoser> rather than 2339595-2939395995595-12224
[15:59] <claudiupopa> Yeah, makes sense. :D
[15:59] <smoser> i'd even say you can limit it to a '2' in the first digit. realizing that future humans will laugh histerically at my short sitedness in the year 3000
[16:06] <openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add the data source base classes and the HTTP OpenStack implementation  https://review.openstack.org/188327
[16:08] <claudiupopa> smoser: should be fixed. I prefered to leave http_client.CONFLICT as is for now.
[16:12] <smoser> how come ? it just seems wierd to me to have to go elsewhere for that little thing.
[16:12] <smoser> i'm not strongly opposed just curious
[16:15] <openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add the data source base classes and the HTTP OpenStack implementation  https://review.openstack.org/188327
[16:15] <claudiupopa> yeah, I guess you're right, url_helper should have already what we need.
[16:16] <smoser> claudiupopa, VERSION_REGEX.match(version)
[16:16] <smoser> that will currently match 2015-05-23344555666
[16:16] <smoser> this is completely nit picky, i do accept :)
[16:16] <claudiupopa> right, I was using .search.
[16:17] <smoser>  r'^\d{4}-\d{2}-\d{2}$'
[16:17] <smoser> that does the right thing
[16:18] <claudiupopa> yeah, fixing right now.
[16:20] <openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add the data source base classes and the HTTP OpenStack implementation  https://review.openstack.org/188327
[16:20] <smoser> woot
[16:20] <claudiupopa> finally.
[16:20] <claudiupopa> :D
[16:23] <claudiupopa> now we need a couple of config modules and that main executable and we're set for the ci. ;-)
[16:25] <smoser> thank you claudiupopa
[16:25] <openstackgerrit> Merged stackforge/cloud-init: Add the data source base classes and the HTTP OpenStack implementation  https://review.openstack.org/188327
[17:44] <smoser> so i'm trying to solve
[17:44] <smoser>  http://stackoverflow.com/questions/23663070/setup-https-proxy-for-pip-install-command-within-tox-environment
[17:44] <smoser> in a windows friendly way.
[17:44] <smoser> i tried
[17:46] <smoser> tried http://paste.ubuntu.com/11768965/
[17:46] <harlowja> what windows
[17:46] <harlowja> *whats windows
[17:46] <harlowja> :-P
[17:46] <smoser> but tox 1.6 (in Ubuntu 14.04) doesn't want to substitute {toxinidir} for me.
[17:47] <smoser> any suggestions there?
[17:47] <smoser> remember httpretty and doesn't work so well when http_proxy is set.
[17:48] <smoser> hm.. wonder if maybe we could use no_proxy..
[17:48] <Odd_Bloke> smoser: Could you paste the tox.ini you're having problems with?
[17:48] <smoser> http://paste.ubuntu.com/11768965/
[17:54] <smoser> it works as expected on wily
[17:54] <smoser> basic issue that i was wanting to solve is this:
[17:54] <smoser>  http://paste.ubuntu.com/11769000/
[17:54] <Odd_Bloke> smoser: What do you see on trusty?
[17:55] <smoser> it tries to execute the string {toxinidir}/tools/foo
[17:55] <smoser> just no substitution
[17:55] <Odd_Bloke> Try doing "changedir = {toxinidir}" and then just "./tools/..." for the command.
[17:55] <smoser> the paste above shows that tox doesnt run if http_proxy / https_proxy is set, but i need it set when i build in this environment (serverstack has no access to intertubes other than via proxy)
[17:56] <Odd_Bloke> Right, so you just want the proxy set for the pip call.
[17:57] <smoser> its funny, cause it says "default: {toxinidir}" but that is not the case either on 1.6
[18:11] <smoser> Odd_Bloke, it doesnt do it.
[18:11] <Odd_Bloke> smoser: Doesn't do what?
[18:11] <smoser> doc says "when executing the test command".
[18:11] <smoser> it doesnt change the dir.
[18:12] <smoser> cwd at that point is the .tox/<toxenv>/
[18:13] <Odd_Bloke> smoser: Hmm, sounds like we might need to bump the tox version after all. :/
[18:14] <smoser> or i can just live with having to hack the full path in that case.
[20:24] <openstackgerrit> Scott Moser proposed stackforge/cloud-init: tox: disable proxies when running nosetests  https://review.openstack.org/195294
[20:36] <smoser> Odd_Bloke, ^ theres a solution there if you want to review
[20:39] <Odd_Bloke> smoser: Just did.
[20:39] <Odd_Bloke> Looks good apart from some missing words in a comment. :)