=== jroll is now known as Guest54515
=== rangerpb is now known as rangerpbzzzz
[01:53] <erick3k> can someone help me with a problem
=== Guest54515 is now known as jroll
[14:52] <jgrimm> rharper, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1645644
[15:14] <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:15] <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:16] <rharper> so, not quite sure why;  though possible that they want to tweak things...
[15:16] <jgrimm> indeed
=== rangerpbzzzz is now known as rangerpb
[18:11] <powersj> magicalChicken: what was the decision re: to many files open?
[18:21] <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:22] <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:23] <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
[19:08] <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
=== X-Istence is now known as x58
[19:36] <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:38] <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
[20:06] <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:07] <vans163> rharper: im booting the snapshot WITHOUT attaching the ISO again
[20:07] <vans163> im using the ISO method to use cloud init
[20:08] <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:33] <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:51] <vans163> rharper: no cdrom attached yea.  Hum.. okay i need to try touching the cloud-init.disabled
[21:19] <vans163> yea no go
[21:20] <vans163> touching that does nothing
[21:20] <vans163> its hanging at boot
[21:20] <vans163> this is fedora24 cloud image
[21:32] <rharper> do you see any boot messages to serial console ?
[21:33] <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:37] <vans163> rharper: humm i had VNC opened and I see nothing except the first line of the boot
[21:38] <rharper> if the image isn't booting properly, maybe its not cloud-init related
[21:44] <vans163> image boots fine if I attach the cloud-init.iso to it
[21:45] <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:46] <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:47] <vans163> hum let me get that then sec
[21:47] <vans163> well not sec.. 10 min :po
[21:48] <rharper> hehe
[21:48] <rharper> yeah, it's a long timeout
[21:48] <vans163> brb going to store
[21:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[22:00] <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:01] <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:02] <vans163> let me show you sec in gist
[22:03] <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:04] <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:05] <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:06] <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:07] <vans163> that solves alot of problems yea
[22:08] <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:09] <vans163> brb
[22:17] <rharper> not sure; possible your original cloud-config has trailing white space ?
=== rangerpb is now known as rangerpbzzzz