=== praneshp_ is now known as praneshp
=== harlowja is now known as harlowja_away
=== pquerna_ is now known as pquerna
[11:08] <mhroncok> smoser: hi, got a minute?
[13:20] <smoser> mhroncok, whats up?
[13:21] <mhroncok> smoser: I wan to talk with you about cloud-init and Python 3
[13:21] <mhroncok> smoser: cloud-init is the last thing in Fedora cloud stack, that doesn't support Python 3
[13:21] <mhroncok> smoser: and we would like to make it happen
[13:22] <mhroncok> how can we help?
[13:22] <smoser> its on a list, and it should have been done alrady.
[13:23] <smoser> i'm open to patches for that. we've done some work in that direction (dropping boto and cheetah recently)
[13:23] <mhroncok> there are several relevant issues opened, but it seems nothing is happening, so we we would be happy to help with patches - however we are not sure what should we focus on first
[13:23] <mhroncok> BTW boto now supports Python 3
[13:24] <mhroncok> I've seen this: https://code.launchpad.net/~harlowja/cloud-init/changeable-templates/+merge/208994
[13:25] <mhroncok> so now it should only be about cloud-init itself?
[13:26] <smoser> i didn't know about boto and python3, thats good. yeah, it should be only cloud-init itself.
[13:27] <mhroncok> is there any branch for python 3 porting or stuff liek tyhat, or we should just start with trunk?
[13:27] <mhroncok> s/liek tyhat/like that/
[13:27] <smoser> trunk. 
[13:28] <smoser> harlowja_away, may have taken some further look at it.
[13:28] <mhroncok> smoser: ok, thanks for info
[13:30] <smoser> i think it makes sense to get to python3 support in cloud-init.
[13:31] <smoser> there is some discussion about doing a cloud-init 2.0, which would start with python3 as the starting point.
[13:31] <smoser> and probably not bother with python2 support
[13:31] <mhroncok> smoser: is there a way to send patches, but don  not sign CCA?
[13:33] <smoser> i'm sorry, there is not. 
[13:33] <smoser> contributors agreement are required i many projects.
[13:34] <mhroncok> I'm not even sure I can sign that, will consult my boss :)
[14:14] <jfontan> hi
[14:14] <jfontan> I am doing some modifications to a cloud init datasource
[14:15] <jfontan> but I am unable to get the error
[14:15] <jfontan> I only get a warning saying "Getting data from <clas...
[14:15] <jfontan> I only get a warning saying "Getting data from <clas...> failed
[14:16] <jfontan> is there any way I can see the errors?
[14:38] <smoser> jfontan, maybe /var/log/cloud-init.log has an error ?
[14:45] <jfontan> nope, that is the only error
[14:46] <jfontan> I've added a traceback print to may copy of cloud-init
[14:46] <jfontan> in find_source
[14:46] <jfontan> may=my
[16:03] <smoser> jfontan, you should get something else along side that error.
[16:06] <jfontan> it only said it failed
[16:06] <jfontan> it was an error in the code
[16:07] <jfontan> but the exception blod just printed that it could not get the data
[16:07] <jfontan> block
[16:08] <jfontan> here
[16:08] <jfontan> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/__init__.py#L255
[16:57] <smoser> harmw, what do you need me to merge ?
[16:57] <smoser> jfontan, yeah, but it should log a stack trace
[16:57] <jfontan> it didn't for me
[17:02] <smoser> can you pastebinit ?
[17:02] <smoser> the whole log ?
[17:08] <jfontan> I'll have to create the image again
[17:10] <jfontan> as I don't have the error in the code anymore and it has the trace print in. I'll check if I have an old vm
[17:18] <jfontan> smoser, https://gist.github.com/jfontan/bcf18f262cd06252ff1a#file-gistfile1-txt-L13
[17:19] <jfontan> it only says that it failed but no stacktrace
[17:19] <jfontan> I'm using trunk
[17:20] <smoser> so the error you see there is the one you added ?
[17:20] <smoser> the stack trace 
[17:21] <harlowja> smoser did i hear python3
[17:21] <harlowja> lol
[17:21] <jfontan> nope, I took out the strack trace printing code
[17:21] <jfontan> the error is in OpenNebula Data source
[17:21] <jfontan> and just tells it failed
[17:22] <jfontan> no stacktrace
[17:22] <smoser> hm.. that is odd. i dont know why. 
[17:22] <jfontan> there is an stacktrace for openstack but that's something I'm not working on
[17:22] <smoser> yeah, and that is wrong. 
[17:22] <smoser> you're using turnk her e?
[17:22] <jfontan> yes
[17:22] <smoser> harlowja, you see that ^ . 
[17:22] <smoser> that should probably not be a fail
[17:22] <harlowja> whats the trace?
[17:22] <smoser> but rather a "no datasource here, move along"
[17:23] <smoser> https://gist.githubusercontent.com/jfontan/bcf18f262cd06252ff1a/raw/960d80f5263ebbe909ab786ef1ece8bc5d04cda6/gistfile1.txt
[17:23] <harlowja> smoser hmmm, will fix
[17:23] <jfontan> it's a failure. I mistyped a variable
[17:23] <smoser> and any idea why we wouldnt get a log
[17:23] <smoser> of that failure there.
[17:24] <smoser> for the 'DataSourceOpenNebula' line
[17:24] <jfontan> it could be the code in data source
[17:24] <jfontan> maybe it's catching all exceptions
[17:24] <smoser> well, it is.
[17:24] <jfontan> I'll take a look
[17:25] <smoser> but then it calls 
[17:25] <smoser>  util.logexc(LOG, "Getting data from %s failed", cls)
[17:26] <jfontan> so that logexc should print the trace, isn't it?
[17:26] <smoser> yeah.
[17:30] <jfontan> I have to go
[17:30] <jfontan> good luck
[17:37] <harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/mini-os-fixes/+merge/233399
[18:02] <harlowja> mhroncok also https://code.launchpad.net/~harlowja/cloud-init/py2-3 for your py3 messages
[18:02] <harlowja> thats the branch that imho will enable mixed py2/py3 mode
[18:03] <harlowja> which will be required for older distros that aren't all py3 yet
[18:03] <mhroncok> harlowja: great, thanks
[18:03] <harlowja> i did some basic testing from what i remember with py3 and pretty sure i nailed most of the issues down
[18:03] <mhroncok> BTW harlowja smoser, cannot I just give you my patches as Public domain?
[18:04] <harlowja> mhroncok smoser  probably knows better than i all that stuff, i never got into the legal stuff :-P
[18:04] <smoser> mhroncok, i dont think so.
[18:04] <mhroncok> ok, waiting to hear from our legal :D
[19:03] <smoser> harlowja, i don think you fixed https://gist.githubusercontent.com/jfontan/bcf18f262cd06252ff1a/raw/960d80f5263ebbe909ab786ef1ece8bc5d04cda6/gistfile1.txt
[19:03] <smoser> in mini-os
[19:03] <smoser> mini-os-fixes
[19:04] <harlowja> k, maybe i misunderstand ?
[19:04] <smoser> so in that log
[19:04] <smoser> hm..
[19:04] <smoser> oldd.
[19:04] <harlowja> 'openstack.py[ERROR]: Failed reading mandatory path /tmp/tmpX2lt9o/openstack/latest/meta_data.json' ?
[19:04] <harlowja> thats now demoted to debug
[19:04] <smoser> i have to look at this more. i didn't hitnk he had a config drive there.
[19:05] <smoser> oh i see.
[19:05] <smoser> so that would be debug, but then there is / should be no ERROR 
[19:05] <harlowja> _fetch_available_versions() takes exactly 1 argument (2 given) also should be fixed
[19:05] <smoser> agreed there.
[19:05] <smoser> i thought what had happend there was that there was no config drive
[19:06] <smoser> and that should result in the DSs' _get_data() returnning False
[19:06] <smoser> with only debug messages
[19:07] <harlowja> sure, i just think the differeniation between searching for get_data that will work and actually using a get_data that then fails isn't clear
[19:07] <harlowja> thats probably part of it
[19:07] <harlowja> maybe should be refactored to find_data (which then only outputs debug messages) and get_data (which actually outputs errors)
[19:08] <harlowja> sepearting the non-failure find process from the actual problems get_data 
[19:08] <harlowja> there sorta munged together at this point 
[19:16] <smoser> well, _get_data returns True on "I've found"
[19:17] <smoser> and False on "nope"
[19:19] <harlowja> right, but say it had a finding method, this one would return True/False, then it had a read method that would read from the previous location found (if it was) and would log errors and such
[19:19] <harlowja> the find method would be expected to never log errors and such
[19:20] <harlowja> but the read method could (instead of what we currently do is make everything debug, since we are doing both find and read in the same method)
[19:25] <smoser> i agree, it can be better.
[19:28] <smoser> harlowja, can you fix that though ?
[19:28] <harlowja> hehe, what i'm supposed to fix? 
[19:28] <harlowja> lol
[19:29] <smoser> it needs to be debug only on "not found"
[19:29] <smoser> and ideally not stack trace :)
[19:30] <harlowja> right, https://code.launchpad.net/~harlowja/cloud-init/mini-os-fixes/+merge/233399 switches those to debug ?
[19:30] <harlowja> with no stack-trace
[19:31] <harlowja> but i might still be confused, lol
[19:31] <harlowja> oh, i think i see one more
[19:34] <harlowja> ok, think i got them (reuploaded)
[20:00] <smoser> how did it do no stacktrace
[20:03] <harlowja> except openstack.NonReadable:
[20:03] <harlowja>             return False
[20:03] <harlowja> probably that
[20:03] <harlowja> except openstack.NonReadable:
[20:03] <harlowja>             return False
[20:03] <harlowja>         except (openstack.BrokenMetadata, IOError) as e:
[20:03] <harlowja>             LOG.debug("Broken metadata address %s: %s",
[20:03] <harlowja>                       self.metadata_address, e)
[20:03] <harlowja>             return False
[20:04] <harlowja> shall that be changed?
[20:04] <harlowja> or similar in 'DataSourceConfigDrive'
[20:15] <harmw> smoser: https://code.launchpad.net/~harmw/cloud-init/freebsd-fixes
[20:15] <harmw> https://code.launchpad.net/~harmw/cloud-init/freebsd-fixes/+merge/233247 
[20:23] <smoser> harmw, tried to build the cirros with patched busybox
[20:23] <smoser> but busubox didn't get patched
[20:23] <smoser> not sure why
[21:07] <harmw> sorry man, this time it's me beeing way to busy :)
[21:16] <smoser> harmw, no worries.
[21:16] <smoser> it seems like an easy fix
[21:16] <smoser> http://paste.ubuntu.com/8253590/
[21:53] <harmw> hm, that makefile change... can't recall i needed that
[22:11] <smoser> no
[22:11] <smoser> you didn't
[22:11] <smoser> that was debug
=== gondoi is now known as zz_gondoi