[02:05] <mso> hi all, can someone point me into the right direction ?
[02:06] <mso> i have a datasoruce "nocloud" that i can (re)run when the machine is up, however, it does not work during boot
[02:07] <mso> the nocloud seed is configured in the cloud.cfg
[02:08] <mso> i am actualy totally lost where to go now, the environment is running ovirt and i am trying to deploy machines through foreman
[07:30] <kol> Hello , where do I make changes in cloud-init  ? I see a cloud-config.txt file , but it is always empty even when i run cloud-init , i'm not able to figure it out :/ 
[07:30] <kol> or is it like it like i have to edit in etc / cloud . cloud.cfg ?
[13:59] <smoser> kol, you can put config files in /etc/cloud/cloud.cfg.d or edit /etc/cloud/cloud.cfg.
[13:59] <smoser> /var/lib/cloud/instance/cloud-config.txt is written by what is read in from user-data.
[13:59] <smoser> if you've not passed any '#cloud-config' in user-datta, then it will be empty.
[14:08] <Odd_Bloke> smoser: LC_ALL was set to C because that's what it is set to in some clouds (e.g. Azure), and it changes Python's encoding/decoding behaviour.
[14:10] <smoser> hm..
[14:10] <Odd_Bloke> smoser: So I think with your change, the test in http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/1059.1.2 would pass without my fix.
[14:10] <Odd_Bloke> s/the test/the test I added/
[14:10] <smoser> why does encode/decode change?
[14:11] <smoser> is it just that encode() changes ? with no 'utf-8' arg ?
[14:11] <Odd_Bloke> Because Python determines the default encoding it should use from the environment.
[14:11] <Odd_Bloke> (If you don't specify one)
[14:11] <smoser> right. so we should always be specifying one.
[14:11] <smoser> there is lots of slop right now in that respect.
[14:12] <Odd_Bloke> smoser: Agreed; setting LC_ALL=C will help catch places we're assuming that encoding will be UTF-8 when it may actually end up as something else.
[14:13] <smoser> Odd_Bloke, yes, it will . and apparently will also catch places in other code (httpretty)
[14:13] <smoser> which idont want to catch :)
[14:14] <Odd_Bloke> smoser: :)
[14:14] <Odd_Bloke> smoser: Can we pin to an older version of HTTPretty in the meantime, or do we need some of the more recent behaviour?
[14:15] <smoser> 0.8.0 would be fine.
[14:15] <smoser> and we could pin to that.
[14:15] <smoser> (that is what is in vivid)
[14:15] <smoser> at some point in the future, it might be useful to have tox environments that describe versions of dependencies on a particular release
[14:16] <smoser> so i could:
[14:16] <smoser> tox -e trusty-34
[14:16] <smoser> er.. trusty-py34
[14:39] <smoser> hey, strikov 
[14:39] <smoser> so yeah, looking at bug 1424900
[14:39] <strikov> hey
[14:39] <smoser> the issue is that python2 made all this magic.
[14:39] <smoser> and we didn't have to think about what might be in content of a read() (whether that be http or file)
[14:39] <smoser> all "just worked"
[14:40] <smoser> but in python3 you have to be much more careful
[14:40] <strikov> correct, you need to know what you read
[14:40] <strikov> because when you read ascii but think that you read utf -- bad things happen
[14:41] <smoser> and the python3 port of cloud-init tried to keep us from having to know such things.
[14:41] <smoser> but unfortunately that just isntt going to work
[14:41] <strikov> well, it treated everything as utf
[14:42] <strikov> basically we don't want t have binary -> string -> binary convertion at all for userdata
[14:42] <strikov> can we read it to binary objject somehow?
[14:43] <strikov> because to me it looks like python-requests converting userdata to utf-8 string
[14:43] <smoser> i think we need to be able to
[14:43] <strikov> when you call it from readurl
[14:43] <smoser> python-requests definitely does support reading binary data
[14:43] <smoser> as i use that for cloud-init
[14:44] <strikov> maybe requests can handle that for us?
[14:44] <smoser> but i think the way we're using it doesnt
[14:44] <smoser> er... above, "as i use that for simplestreams"
[14:44] <strikov> yeah, i got it
[14:45] <strikov> OR we may generate correct utf-8 bitstream on the server
[14:45] <strikov> maybe that's the better way
[14:45] <strikov> because right now (I assume) server generates ascii bitstream
[14:45] <strikov> i.e. raw bytes
[14:46] <strikov> hm, i thought a bit and server-based way seems wrong
[14:55] <strikov> smoser: I wonder why userdata content is marked as text/html on metadata server
[14:56] <strikov> smoser: Not sure, but marking differently may solve the issue
[14:57] <smoser> well, we need to treat it as bytes.
[14:57] <smoser> basically, we need to treat as bytes, and try to uncompress, if that doesnt work, then try to encode as utf-8
[15:00] <strikov> smoser: how about that; read_url returns bytes all the time; we have default translator (http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/helpers/openstack.py#L256) which convert data to utf-8 string; userdata is the only field which doesn't use this translator
[15:07] <strikov> smoser: url_helper.py has UrlResponse object; right now it has only contents() method which refers to _response.text of python-requests; we may add raw() method which would refer to _reponse.raw which is a file object
[15:08] <smoser> strikov, right
[15:08] <smoser> strikov, i was investigating that
[15:08] <smoser> http://paste.ubuntu.com/10409455/
[15:08] <smoser> that is where i was right now
[15:08] <smoser> basically doing raw.read() rather than .text
[15:13] <strikov> smoser: awesome!