[09:50] smoser: Yeah, I can't really understand it. [09:50] I'm not sure why the failure would only appear once, either. [09:51] It's not the only test that uses custom data. === shardy is now known as shardy_lunch === shardy_lunch is now known as shardy === rangerpbzzzz is now known as rangerpb [16:08] larsks, i think that fedora 24 (and i'm guessing 25) has a newer httpretty than is released on pypi (0.8.14). [16:09] is that plausible ? [16:10] smoser: I don't think so. I was running from a virtualenv (there is no httpretty package installed on my host). [16:10] well that is odd. [16:10] smoser: I'm going to work on reproducing et al this afternoon. [16:10] Maybe my computer is insane. [16:10] well, i see code in fedora24 that shows this [16:10] and it definitely acts differently than pypi version [16:11] If I were to install the python-httpretty package, I get 0.8.14-1.20161011git70af1f8, so that may be newer than pypi. But I don't have that installed locally. [16:11] (This is in F25) [16:23] larsks, i updated bug. and opened an httpretty issue === shardy is now known as shardy_afk [19:16] quick question: as I do not know enough about python. [19:17] what actually gets started by python by: [19:17] #!/opt/bin/python [19:17] # EASY-INSTALL-SCRIPT: 'cloud-init==0.7.5','cloud-init' [19:17] __requires__ = 'cloud-init==0.7.5' [19:17] __import__('pkg_resources').run_script('cloud-init==0.7.5', 'cloud-init') [19:17] sorry for the multi-line. thought I had cut it down to the last line [19:19] aixtools: that runs cloudinit.cmd.main:main (possibly /usr/lib/python2.7/site-packages/cloudinit/cmd/main.py) [19:19] so, in the sources - main.py [19:20] Right. [19:20] Specifically, cloudinit/cmd/main.py [19:20] thx very much. [19:20] single-step I go... [19:45] hey there! i was wondering if i could ask a quick cloud-init question; if I have an ec2 datasource, is it possible to template out some of that information into a file using the write_files module? [19:51] ssalevan: write_files just writes out specified content, it doesn't have a template system afaik [19:51] ssalevan: there may be other ways to achieve that though, which parts of the config do you need written out? [19:52] magicalChicken: right now i basically need to stick eth0's private IP into a JSON configuration file [19:55] ssalevan: I don't know of a good way to handle that that's currently built in, althought someone else may [19:55] One option would be to write a script that handles that and runs after the eni has been written [19:56] ssalevan: for the *private* ip, seems like you could as easily parse the output of 'ip addr'. [19:56] And do that in a runcmd script or something. [19:56] ah, good point, could just rig up a bash session [19:57] well hey thanks much for your time y'all, much appreciated === shardy_afk is now known as shardy [21:46] i was wondering if i could trouble you for one last question: i've packed up my user-data into a base64-encoded YANL, but cloud-init is returning the following error: __init__.py[WARNING]: Unhandled non-multipart (text/x-not-multipart) userdata: '---\npreserve_hostname: f...' [21:46] i suspect this may be related to a MIME typing issue [21:48] ssalevan: why are you providing a base64-encoded yaml? Why not just pass in the unencoded yaml? [21:49] Also, does your userdata start with a "#cloud-config" marker? It doesn't look like it from that output... [21:49] larsks: so when i try and send up the raw YAML user-data as part of a call to Amazon's RunInstances call, it returns an error that it was unable to encode into base64. t [21:49] ahhh that's probably it [21:49] ssalevan: interesting. I suspect my second comment is more relevant, yeah. [21:53] larsks: that was totally it. thank you so much! [21:53] Glad it worked! [21:54] larsks, thanks for helping ssalevan [21:54] smoser: sure! === rangerpb is now known as rangerpbzzzz