| === jroll is now known as Guest54515 | ||
| === rangerpb is now known as rangerpbzzzz | ||
| erick3k | can someone help me with a problem | 01:53 |
|---|---|---|
| === Guest54515 is now known as jroll | ||
| jgrimm | rharper, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1645644 | 14:52 |
| rharper | jgrimm: hrm, so pre-existing ntp.conf .. when dpkg installs, it will divert the package conf to a new file (where as cloud-init moves the original out of the way and replaces). Do you suppose we should do the same here? | 15:14 |
| jgrimm | not sure, i just wasn't sure if you'd noticed that bug yet | 15:15 |
| rharper | I had not | 15:15 |
| rharper | so, they're clearly adding 'ntp' key to trigger the install | 15:15 |
| rharper | but not using the existing pool or server list | 15:15 |
| rharper | so, not quite sure why; though possible that they want to tweak things... | 15:16 |
| jgrimm | indeed | 15:16 |
| === rangerpbzzzz is now known as rangerpb | ||
| powersj | magicalChicken: what was the decision re: to many files open? | 18:11 |
| magicalChicken | powersj: It was caused by polling for the system to be up using lots of calls to execute() | 18:21 |
| magicalChicken | it went away once i switched back to polling in the instance | 18:21 |
| powersj | ah ok so you are going to go the route of updating your code | 18:22 |
| magicalChicken | there's a new bug in centos with setting hostname, but it looks like its a cloud-inti issue | 18:22 |
| magicalChicken | powersj: yeah, it is a bug in pylxd most likely, but the fix in the test suite is simple, so no sense in waiting until it can be fixed in pylxd | 18:22 |
| powersj | ok! | 18:22 |
| magicalChicken | I've pushed the fix | 18:23 |
| powersj | is the fix committed such that I can keep testing? | 18:23 |
| powersj | ah :) | 18:23 |
| powersj | thank you! | 18:23 |
| magicalChicken | The centos tests will still fail due to hostnamectl timing out when cloud-init tries to run cc_set_hostname thought | 18:23 |
| vans163 | hello. Is there a general way to disable cloud-init after first init? | 19:08 |
| vans163 | Im having a problem where if I take a snapshot of a cloud disk, boot up another Vm with it, it freezes upon boot because cloud init is looking for things again | 19:08 |
| === X-Istence is now known as x58 | ||
| rharper | if you're booting a snapshot with the same UUID/instance-id, then it won't attempt to re-init; but if you change the instance-id then it will try to run again. That's by design as you don't want the same ssh keys and other generated data to be the same between different instances. | 19:36 |
| rharper | if you want, you can append cloud-init=disabled to the kernel command line, or if you modify your image, you can touch /etc/cloud/cloud-init.disabled which will prevent cloud-init from running | 19:38 |
| vans163 | rharper: is there something without touchng the system much. If i understood correct I can add touch /etc/cloud/cloud-init.disabled to the end of my cloud-init script? | 20:06 |
| vans163 | i saw tutorials that say to uninstall cloud-init, but for different distros the command will be different so this is not as portable | 20:06 |
| vans163 | rharper: im booting the snapshot WITHOUT attaching the ISO again | 20:07 |
| vans163 | im using the ISO method to use cloud init | 20:07 |
| vans163 | so I launch the fedora_24_cloud.raw disk image with a cloud-init.iso attached. Everythings fine. now I snapshot the .raw disk, and spin up a new VM with it. WITHOUT the cloud-init.iso | 20:08 |
| vans163 | and now it hangs indefinetaly | 20:08 |
| rharper | and if you boot your image without a cdrom in the first place, it will likely do the same (it's looking for a datasource) and takes quite a while to timeout; I suspect, somehow the instance_id in your second boot is different than the first; the cloud-init.log in the second boot will confirm; you should be able to just wait it out (like 10 or so minutes) or even just boot the snapshot image with the cdrom | 20:33 |
| rharper | bbiab | 20:33 |
| vans163 | rharper: no cdrom attached yea. Hum.. okay i need to try touching the cloud-init.disabled | 20:51 |
| vans163 | yea no go | 21:19 |
| vans163 | touching that does nothing | 21:20 |
| vans163 | its hanging at boot | 21:20 |
| vans163 | this is fedora24 cloud image | 21:20 |
| rharper | do you see any boot messages to serial console ? | 21:32 |
| rharper | I usually do a "-serial telnet:localhost:2446:,nowait,server" to my qemu command, then when you launch it, you can telnet localhost 2446 and see boot messages and interact with serial console of the guest | 21:33 |
| vans163 | rharper: humm i had VNC opened and I see nothing except the first line of the boot | 21:37 |
| rharper | if the image isn't booting properly, maybe its not cloud-init related | 21:38 |
| vans163 | image boots fine if I attach the cloud-init.iso to it | 21:44 |
| vans163 | i think its just looking for the iso/trying to connect to EC2 ip | 21:45 |
| vans163 | i need to find how to tell it to not do that | 21:45 |
| vans163 | (once its booted the first time in its life) | 21:45 |
| vans163 | yum erase cloud-init at the end of the config script seems to be the solution but this is not portable | 21:45 |
| vans163 | (havent tried it, just read blog about it) | 21:46 |
| rharper | well, it will eventually timeout trying to reach EC2; having the cloud-init.log of the second boot can help understand what's going on; | 21:46 |
| vans163 | hum let me get that then sec | 21:47 |
| vans163 | well not sec.. 10 min :po | 21:47 |
| rharper | hehe | 21:48 |
| rharper | yeah, it's a long timeout | 21:48 |
| vans163 | brb going to store | 21:48 |
| vans163 | not so slow actually | 21:54 |
| vans163 | got dressed and its done | 21:54 |
| vans163 | it spent 2 minutes trying to reach /latest/meta-data/instance-id on the gateway IP DHCP gave it | 21:54 |
| vans163 | maybe more | 21:55 |
| vans163 | DataSourceEc2.py[CRITICAL]: Giving up on md from ['http://169.254.169.254/2009-04-04/meta-data/instance-id'] after 21630 seconds | 21:55 |
| vans163 | first that, then trying to reach the gateway ip 2 minutes, then it booted | 21:55 |
| rharper | yeah, I was interested in /var/log/cloud-init.log and /var/lib/cloud/instances/ | 21:55 |
| rharper | trying to recreate here | 21:56 |
| vans163 | cloud-init.log is empty | 21:56 |
| rharper | that seems very wrong | 21:56 |
| vans163 | (i added the touch .../.disabled | 21:56 |
| rharper | oh | 21:56 |
| rharper | though the first boot one should have run though | 21:56 |
| rharper | and it wouldn;'t have tried ec2 if it was disabled | 21:57 |
| vans163 | instances has 1 UUID folder, and iid-datasource-none | 21:57 |
| rharper | it's like it never ran at all | 21:57 |
| rharper | your cdrom image would have included a meta-data file with an instance-id in it | 21:57 |
| rharper | that should be in /var/lib/cloud/instances/<instance id> | 21:57 |
| rharper | from the first boot | 21:57 |
| vans163 | df -h shows me /dev/vda1 50G 446M 47G so the drive was expanded | 21:57 |
| rharper | if that's not there, then your snapshot isn't getting captured | 21:57 |
| vans163 | or.. | 21:58 |
| rharper | yeah, cloud-init does that | 21:58 |
| vans163 | yea it ran right the first time, because the SSHkeys i set are there | 21:58 |
| vans163 | then i powerdown the instance + snapshot the disk | 21:58 |
| rharper | maybe I don't know what the fedora cloud-init is doing but the instance dir should be persistent | 21:58 |
| vans163 | so basically the same thing as booting the instance again without the cloud-init.iso cdrom attached | 21:58 |
| rharper | right but it's not recording the instance data where cloud-init looks (at least on ubuntu) | 21:59 |
| rharper | inside the instance dir, includes a pickled datasource object that it re-uses on subsequent boots | 21:59 |
| vans163 | obj.pkl is there i see it | 21:59 |
| rharper | then you have to have a /var/lib/cloud/instances/ ... | 22:00 |
| vans163 | yes isntances folder has 2 folders in it | 22:00 |
| vans163 | 1 is a UUID folder, the other is iid-datasource-none | 22:00 |
| rharper | ok, that makes sense | 22:00 |
| rharper | what I suspect is that without a way to specify the instance-id to cloud-init, it won;t know to use the previous uuid as a datasource | 22:01 |
| rharper | I'll confirm locally | 22:01 |
| vans163 | somethign strange I see my cloud-config is truncated | 22:01 |
| vans163 | cloud-config.txt in that uuid folder is missing a few things | 22:01 |
| vans163 | ... it shows at the end | 22:01 |
| vans163 | let me show you sec in gist | 22:02 |
| rharper | so unless we have a way to persist the instance-id (via a permanent datasource) I don't think cloud-init can know that it should use it; | 22:03 |
| rharper | you may want to look at using the nocloud seed (write out your user-data/metadata to /var/lib/cloud/seed/nocloud-net dir in the image itself | 22:03 |
| vans163 | well upon the snapshot boot, it should ignore cloud init | 22:04 |
| vans163 | as the instance is already configured | 22:04 |
| rharper | that;s not how cloud-init works | 22:04 |
| vans163 | ah | 22:04 |
| rharper | it only knows it's configured if it finds that it's the same instance | 22:04 |
| rharper | in real clouds, the meta-data provides the instance-id; that's ephemeral , each time you launch a new vm, it's a new instance | 22:04 |
| vans163 | and the ISO or webserver it tries to query tells it the id | 22:04 |
| rharper | it had a meta-data file | 22:04 |
| rharper | you can embed the same config from the iso in a dir inside the image | 22:05 |
| rharper | that will achieve what you want | 22:05 |
| vans163 | i think that is exactly what I need | 22:05 |
| vans163 | thanks for explaining | 22:05 |
| rharper | http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html | 22:05 |
| rharper | sure | 22:05 |
| vans163 | but I have this 1 wierd thing | 22:05 |
| rharper | that link shows it via iso, but if you just put the contents of the iso at /var/lib/cloud/seed/nocloud-net/{user-data,meta-data} | 22:06 |
| vans163 | that solves alot of problems yea | 22:07 |
| vans163 | https://gist.github.com/anonymous/5e47847afa56cdd01f88ef0d27aa62a4 this gist, the top is the cloud-config i passed the ISO, the bottom is what was in the instances /var/lib/cloud/instances/d2ffab6d-7ac9-423a-bc8a-023402a2d7a0/cloud-config.txt | 22:08 |
| vans163 | why is there so many spaces in the root password, guessing its fine tho? | 22:08 |
| vans163 | brb | 22:09 |
| rharper | not sure; possible your original cloud-config has trailing white space ? | 22:17 |
| === rangerpb is now known as rangerpbzzzz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!