| === cpaelzer__ is now known as cpaelzer | ||
| === MAbeeTT_ is now known as MAbeeTT | ||
| Odd_Bloke | blackboxsw: I'm not seeing those changes on #113, did you push? | 13:41 |
|---|---|---|
| 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:01 |
| meena | mock: can you show us an example of what your input and output look like? | 18:08 |
| mock | Yes, wait one... | 18:09 |
| meena | online, in some pastebin… | 18:10 |
| mock | https://paste.centos.org/view/f990169d | 18:13 |
| mock | I have several different files my file is writing. All of them are like that. | 18:16 |
| meena | what's the line endings in your input look like? | 18:17 |
| mock | I'm using vim on Fedora Linux, so just \n chars. | 18:19 |
| rharper | mock: what version of cloud-init ? | 18:20 |
| mock | Cloud-init v. 19.3-2.amzn2 | 18:20 |
| 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:22 |
| rharper | mock: ^ | 18:23 |
| 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:24 |
| 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:26 |
| rharper | np, glad we could help | 18:27 |
| mock | Thanks for the cold bucket of water. | 18:27 |
| rharper | heh | 18:27 |
| mock | :) | 18:27 |
| mock | It's all good now. Thanks again! | 18:59 |
| 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:04 |
| Odd_Bloke | the r in rharper stand for rubber duck. ;) | 19:08 |
| rharper | ... | 19:09 |
| Odd_Bloke | https://en.wikipedia.org/wiki/Rubber_duck_debugging | 19:10 |
| rharper | nice, TIL | 19:10 |
| rharper | I was sort of doing that in the vmware discussion on PR #229 (fallback datasource) | 19:11 |
| rharper | robjo: will there be a complete cloud-init.log of the failure scenario ? | 19:12 |
| 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:14 |
| rharper | the log file would help; but; it it seems plausible; looking closer at the instance_id check in stages | 19:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| rharper | the log file should confirm that for local stage, we'll see a 'cache invalid in datasource' | 19:19 |
| rharper | then we should try _get_data() on ec2, which will bring up ephemeral dhcp and crawl things; and all should be fine. | 19:20 |
| 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:21 |
| 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:22 |
| 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 | 19:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
