=== cpaelzer__ is now known as cpaelzer
=== MAbeeTT_ is now known as MAbeeTT
[13:41] <Odd_Bloke> blackboxsw: I'm not seeing those changes on #113, did you push?
[18:01] <mock> Hello. I have searched online yet I cannot find any reference to having the write_files module not add extra line feeds into the files it produces. Can it write the files without those extra line feeds? Is there a trick to it?
[18:08] <meena> mock: can you show us an example of what your input and output look like?
[18:09] <mock> Yes, wait one...
[18:10] <meena> online, in some pastebin…
[18:13] <mock> https://paste.centos.org/view/f990169d
[18:16] <mock> I have several different files my file is writing. All of them are like that.
[18:17] <meena> what's the line endings in your input look like?
[18:19] <mock> I'm using vim on Fedora Linux, so just \n chars.
[18:20] <rharper> mock: what version of cloud-init ?
[18:20] <mock> Cloud-init v. 19.3-2.amzn2
[18:22] <rharper> are you running this on ec2 ? how are you getting your user-data into the instance ?
[18:22] <rharper> do you paste in the user-data ?  or upload a file?
[18:23] <rharper> mock: ^
[18:24] <mock> Oh, I think it might how I'm reading the file via Python. Let me try to adjust that and see what I get.
[18:26] <mock> Nevermind. That's what it is.
[18:26] <rharper> cool, glad it was easy
[18:26] <mock> Me too, but I wish I had thought to check that earlier.
[18:27] <rharper> np, glad we could help
[18:27] <mock> Thanks for the cold bucket of water.
[18:27] <rharper> heh
[18:27] <mock> :)
[18:59] <mock> It's all good now. Thanks again!
[19:04] <robjo> blackboxsw: Maybe a brief chat about https://bugs.launchpad.net/cloud-init/+bug/1883907 this afternoon? Or anyone else from the core team that matter
[19:04] <ubot5> Ubuntu bug 1883907 in cloud-init "EC2 data source does not properly return the instance ID when cached data exists" [Undecided,New]
[19:08] <Odd_Bloke> the r in rharper stand for rubber duck. ;)
[19:09] <rharper> ...
[19:10] <Odd_Bloke> https://en.wikipedia.org/wiki/Rubber_duck_debugging
[19:10] <rharper> nice, TIL
[19:11] <rharper> I was sort of doing that in the vmware discussion on PR #229 (fallback datasource)
[19:12] <rharper> robjo: will there be a complete cloud-init.log of the failure scenario ?
[19:14] <Odd_Bloke> I have one of these sitting on my desk, so the expression is always top-of-mind for me: https://codewith.mu/img/en/howto/debug_duck.png
[19:14] <robjo> rharper: No, I can request one but based on my understanding of the context I have done all the digging and more or less am looking for confirmation that I didn't miss anything
[19:15] <rharper> the log file would help; but; it it seems plausible;  looking closer at the instance_id check in stages
[19:16] <rharper> robjo: what version of cloud-init ?
[19:16] <robjo> As far as I can interpret what I received in a bug is 1.) Start instance 2.) Create AMI from Instance 3.) Start instance from new AMI
[19:16] <robjo> that's 19.4
[19:17] <robjo> but that code hasn't change since so master shold have the same behavior
[19:17] <robjo> In the instance from the new AMI initially we load the cahced data source and thus get_instance_id() returns the incorrect value
[19:18] <robjo> but I added some debug code and have proof that get_instance_id() eventually returns the new instance data
[19:18] <robjo> and that the user data script gets executed
[19:18] <rharper> just checking;  looking at stages.py:_restore_from_checked_cache();  I would expect us to throw away the cache file at local time;   we do restore the object, then we check /run/cloud-init/.instance_id  to ds.get_instance_id();  this fails as run isn't present on new image;  ec2 does not have a check_instance_id() method; so invalidate the datasource cache
[19:19] <rharper> the log file should confirm that for local stage, we'll see a 'cache invalid in datasource'
[19:20] <rharper> then we should try _get_data() on ec2, which will bring up ephemeral dhcp and crawl things; and all should be fine.
[19:21] <robjo> That's what I found in my test, i.e. the initial incorrect information get's discarded and things fix themselves
[19:21] <rharper> robjo: ok, so what's the bug then ?  this happens early in local, so all of the module stages run like new instance; (because it is)  ?
[19:21] <robjo> I think we're OK and would tend to close the bug
[19:22] <rharper> OK.
[19:22] <rharper> I can paste this discussin in the bug and mark it invalid?
[19:22] <robjo> As said I wanted confirmation that I didn't miss anything and a bug appeared the natural place for me to capture my data
[19:23] <robjo> Yes you can close it as invalid, or I can
[19:23] <rharper> Sure, let me respond there and answer your questions
[19:23] <robjo> OK, thanks