/srv/irclogs.ubuntu.com/2015/02/25/#cloud-init.txt

msohi all, can someone point me into the right direction ?02:05
msoi have a datasoruce "nocloud" that i can (re)run when the machine is up, however, it does not work during boot02:06
msothe nocloud seed is configured in the cloud.cfg02:07
msoi am actualy totally lost where to go now, the environment is running ovirt and i am trying to deploy machines through foreman02:08
=== harlowja_ is now known as harlowja_away
=== rcj is now known as Guest72514
kolHello , 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
kolor is it like it like i have to edit in etc / cloud . cloud.cfg ?07:30
=== shardy_afk is now known as shardy
=== Odd_Blok1 is now known as Odd_Bloke
smoserkol, 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
smoserif you've not passed any '#cloud-config' in user-datta, then it will be empty.13:59
=== Guest72514 is now known as rcj
=== rcj is now known as Guest22529
Odd_Blokesmoser: 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:08
smoserhm..14:10
Odd_Blokesmoser: 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_Blokes/the test/the test I added/14:10
smoserwhy does encode/decode change?14:10
smoseris it just that encode() changes ? with no 'utf-8' arg ?14:11
Odd_BlokeBecause Python determines the default encoding it should use from the environment.14:11
Odd_Bloke(If you don't specify one)14:11
smoserright. so we should always be specifying one.14:11
smoserthere is lots of slop right now in that respect.14:11
Odd_Blokesmoser: 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:12
smoserOdd_Bloke, yes, it will . and apparently will also catch places in other code (httpretty)14:13
smoserwhich idont want to catch :)14:13
Odd_Blokesmoser: :)14:14
Odd_Blokesmoser: Can we pin to an older version of HTTPretty in the meantime, or do we need some of the more recent behaviour?14:14
smoser0.8.0 would be fine.14:15
smoserand we could pin to that.14:15
smoser(that is what is in vivid)14:15
smoserat some point in the future, it might be useful to have tox environments that describe versions of dependencies on a particular release14:15
smoserso i could:14:16
smosertox -e trusty-3414:16
smoserer.. trusty-py3414:16
smoserhey, strikov 14:39
smoserso yeah, looking at bug 142490014:39
strikovhey14:39
smoserthe issue is that python2 made all this magic.14:39
smoserand we didn't have to think about what might be in content of a read() (whether that be http or file)14:39
smoserall "just worked"14:39
smoserbut in python3 you have to be much more careful14:40
strikovcorrect, you need to know what you read14:40
strikovbecause when you read ascii but think that you read utf -- bad things happen14:40
smoserand the python3 port of cloud-init tried to keep us from having to know such things.14:41
smoserbut unfortunately that just isntt going to work14:41
strikovwell, it treated everything as utf14:41
strikovbasically we don't want t have binary -> string -> binary convertion at all for userdata14:42
strikovcan we read it to binary objject somehow?14:42
strikovbecause to me it looks like python-requests converting userdata to utf-8 string14:43
smoseri think we need to be able to14:43
strikovwhen you call it from readurl14:43
smoserpython-requests definitely does support reading binary data14:43
smoseras i use that for cloud-init14:43
strikovmaybe requests can handle that for us?14:44
smoserbut i think the way we're using it doesnt14:44
smoserer... above, "as i use that for simplestreams"14:44
strikovyeah, i got it14:44
strikovOR we may generate correct utf-8 bitstream on the server14:45
strikovmaybe that's the better way14:45
strikovbecause right now (I assume) server generates ascii bitstream14:45
strikovi.e. raw bytes14:45
strikovhm, i thought a bit and server-based way seems wrong14:46
strikovsmoser: I wonder why userdata content is marked as text/html on metadata server14:55
strikovsmoser: Not sure, but marking differently may solve the issue14:56
smoserwell, we need to treat it as bytes.14:57
smoserbasically, we need to treat as bytes, and try to uncompress, if that doesnt work, then try to encode as utf-814:57
strikovsmoser: 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 translator15:00
strikovsmoser: 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 object15:07
smoserstrikov, right15:08
smoserstrikov, i was investigating that15:08
smoserhttp://paste.ubuntu.com/10409455/15:08
smoserthat is where i was right now15:08
smoserbasically doing raw.read() rather than .text15:08
strikovsmoser: awesome!15:13
=== strikov is now known as strikov-lunch
=== strikov-lunch is now known as strikov
=== Guest22529 is now known as rcj
=== rcj is now known as Guest62484

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!