#cloud-init 2013-12-23
<ikkeT> smoser, thanks, good to know to avoid banging head to wall any more than necessary...
<cheddar> Hello cloud-init peeps.  I've got a question about how to turn off some functionality.  Specifically, cloud-init keeps adding things to my /etc/fstab on EC2 and from the docs I've been able to find online, it looks like it always tries to add a swap and a /mnt to fstab.  I have my fstab exactly how I want it in my AMI and want cloud-init to stop editting it when I fire up a new instance.  I can't seem to find the default configurat
<cheddar> however, so I'm not sure what to edit to make it not do that anymore.
<cheddar> I have seen that I can override this with user-data, but user-data means something else to my AMI, so I cannot use that.
<cheddar> is there a directory I can place a cloud-init config yaml file under /var/lib/cloud/ or something that it will pick up?
<cheddar> btw, I'm on ubuntu 13.10 if that helps
<cheddar> oh, think I found it.  google got me to a random blog post that happened to talk about installing cloud-init, which also included the config file in /etc/cloud/cloud.cfg  Would be great to have a man page for this thing...
<cheddar> Yup, that worked.  Problem solved.
<harmw> harlowja: did you try your fbsd instance yet?
<harlowja> negative, sean seems to be out on vacation :-/
<harlowja> as i guess most people are today
<harmw> darn
<harmw> stupid vacations
<harmw> whats wrong with going to work
#cloud-init 2013-12-24
<kwadronaut> probably a more common situation:
<kwadronaut> debian vm (in an openstack environment) gets launched from a base image, generates new sshd keys, so far so good.
<kwadronaut> but when snapshotting and resetting, it generates new keys again, but shouldn't.
<kwadronaut> (it gets a new instance-id)
<harmw> if it wouldn't do that, you'd endup with multiple hosts using the same sshd keys
<kwadronaut> what'd be the recommended way to deal with that?
<harmw> which would be insecure
<kwadronaut> true, but snapshot â revert, means we also remove the original one.
<harmw> hm, so reverting an instance would endup destroying it and creating a new one?
<kwadronaut> let me put it differently
<kwadronaut> i have a base image, from which i launch new instances. they always get fresh sshd keys. That's good.
<kwadronaut> now, i want to snapshot an instance from some known 'good' state, then I give access to someone so she can play with it, make modifications by hand, make mistakes,...
<kwadronaut> so we end up with a vm with lots of hand-labor, and want to go back to the first 'good' state. but keeping the sshd_keys.
<kwadronaut> basically, we boot from the snapshot and destroy the original one.
<kwadronaut> so yes, that means a new instance-id from openstacks pov, but not from the developers point of view.
<kwadronaut> Am I making myself more clear?
<harmw> yes :)
<kwadronaut> am i making sense? ;-)
<harmw> hm, so cloudinit should keep its hands off the sshd keys
<kwadronaut> i could of course purge cloud-init after the first run ;-)
<harmw> unless it's already capable of doing just that, it shouldn't be that hard to built
<kwadronaut> but then, there are other modulesâ¦
<harmw> that'll work, ofc :)
<harmw> for now I'd suggest looking through the docs on cloud-init.cfg
<harmw> http://cloudinit.readthedocs.org/en/latest/topics/examples.html#configure-instances-ssh-keys
<harmw> this will force the instance to come up with the specified keys
<kwadronaut> yes, but that means getting them off the instances first in the admins computers.
<kwadronaut> opening extra attack vectors :-(
<harmw> no, instead of having cloud-init generate keys for you, you do that for cloud-init
<kwadronaut> hmmmmm so you suggest that i do that with user-data on the first run?
<harmw> eg. cloud-init (or even sshd startupscripts) have logic to run ssh-key-gen (?) which generates the keys found in /etc/ssh/
<kwadronaut> correct
<harmw> yep, cloud-init will see -you- want to have specific sshd keys assigned with this instance and as such it will configure those (instead of generating random keys)
<kwadronaut> hmhm 
<kwadronaut> not entirely happy
<harmw> why not :)
#cloud-init 2013-12-27
<anuaimi> I want to use cloud-init with kvm to create ubuntu guests.  I can't seem to find any settings in cloud-init to set the network.  I'd like to set a static ip for each guest
<harmw> argh, why don't people just wait for an answer
#cloud-init 2014-12-23
<tennis> anyone here?  
<tennis> if I have a file which starts with "#cloud-config", where should it be located? In what directory?
#cloud-init 2015-12-21
<danielbruno> Hi, I'm using Ubuntu 12 with cloud-init 0.6.3, and I'm trying to create an user but it is not working. The same cloud-init file works fine on Ubuntu 14 with cloud-init 0.7.5.
<danielbruno> There is some difference betwwen these versions to do it?
#cloud-init 2015-12-26
<openstackgerrit> janonymous proposed openstack/cloud-init: py26 is no longer supported by Infra's CI  https://review.openstack.org/261718
#cloud-init 2016-12-28
<erick3k_> hi
<erick3k_> can someone help me am cloud-init stupid
<erick3k_> getting https://i.imgur.com/8Gm6DyN.png
<erick3k_> although the network works after
<erick3k_> is there a way to redude that no net time wait?
<erick3k_> and also the waiting for network configuration?
<erick3k_> anyone?
#cloud-init 2016-12-29
<magicalChicken> erick3k_: if you give cloud-init networking configuration and make sure the datasource is accessible and configured right that shouldn't happen
<magicalChicken> erick3k_: cloud-init just tries to find any device it can get a connection on if it doesn't see anything early on
#cloud-init 2019-12-23
<joshualyle> turns out I was looking in the wrong place. the setup.py install script uses system_info() as well to determine the OS variant and then just sets that in the cloud.cfg file at the time of setup.py install. If it is removed in cloud.cfg, it will fallback to ubuntu
<Goneri> https://github.com/canonical/cloud-init/pull/62 is ready for review
#cloud-init 2019-12-24
<wyoung> Gaffel: People still use NetBSD?
<Goneri> meena, thanks for the review
<wyoung> 5
#cloud-init 2019-12-26
<meena> updates: https://hackmd.io/3-YBj1t9TAeKhmfLBQUjXQ?view#Revisiting-modules
#cloud-init 2019-12-28
<meena> https://www.python.org/psf/press-release/pr20191220/ cowards
#cloud-init 2019-12-29
<hetii> Hello :)
<hetii> I have couple question about cloud-init/config files.
<hetii> First I use terraform template_cloudinit_config data object where I can provide multiple parts that are encoded to multipart mime object. Each part of this message container header for eg for filename like:
<hetii> Content-Disposition: attachment; filename="cloudinit.yaml"
<hetii> how this file or content is then reference in boot process?
<hetii> for eg can I embed https certificate for nginx daemon and use that mime object as a source data?
<hetii> the second question is about cloud init portability. So by default my openstack provider have ubuntu images that support cloud-init, but do I assume correctly that cloud-init from ubuntu have different subset of stuff then for eg. cloudinit for rancheros?
<meena> hetii: wha
<hetii> ?
<meena> â¦ typing in phones is hard
<hetii> ok
<meena> anyway, given that rancher os advertises itself as being configurable via cloud-init, i don't think you have to worry
<hetii> Well I need to know basic thing regarding boot process and paths handling in mime mix of cloud-init
<meena> that's probably one of the areas i cannot help :( i try to avoid needing multiple files
<hetii> ok, dont worry I will figureout
<meena> extrapolating from my cloud provider, your nginx cert will end up in /var/lib/cloud-init/instance/
<hetii> ok thx will check it also:)
<meena> i just installed https://pypi.org/project/pipx/ â and saw Creator/Maintainer Chad Smith. and it's not blackboxsw. Apparently there's more than one.?!
<hetii> re
