=== shardy_afk is now known as shardy
=== shardy is now known as shardy_afk
=== shardy_afk is now known as shardy
[12:40] <nakul> Hi all
[12:40] <nakul> does cloud-init supports Debian 7 (wheezy) ?
[12:41] <nakul> specially 32 bit arch
[12:45] <nakul> i have created an deb 7 (32bit) kvm based image and installed cloud-init cloud-utils and cloud-initramfs-growroot packages from "http://ftp.debian.org/debian wheezy-backports main" repo
[12:45] <nakul> and uploaded in glance to work with userdata and config drive but its not accepting any credentials either
[12:47] <nakul> but i can curl to metadata url http://169.254.169.254 and can see the config drive as well
[12:49] <nakul> i am not sure whats wrong here and i dont have such issues with debian 8 and debian 9 release
[13:11] <powersj> nakul: and you please share the logs in /var/log/cloud-init*?
[13:19] <nakul> [....] Starting Cloud service: cloud-init[....] Starting NFS common utilities: statd idmapd[?25l[?1c7[1G[[32m ok [39;49m8[?25h[?0c. [....] Starting rpcbind daemon...[....] Already running.[?25l[?1c7[1G[[32m ok [39;49m8[?25h[?0c. [....] Starting enhanced syslogd: rsyslogd[?25l[?1c7[1G[[32m ok [39;49m8[?25h[?0c. [....] Starting ACPI services...[?25l[?1c7[1G[[32m ok [39;49m8[?25h[?0c. [....] Starting deferred execution scheduler: atd
[13:19] <nakul> hi powersj
[13:20] <nakul> i am able to share the full logs here
[13:20] <nakul> not*
[13:21] <nakul> Traceback (most recent call last):   File "/usr/bin/cloud-init", line 509, in <module>     sys.exit(main())   File "/usr/bin/cloud-init", line 505, in main     return functor(name, args)   File "/usr/bin/cloud-init", line 256, in main_init     iid = init.instancify()   File "/usr/lib/python2.7/dist-packages/cloudinit/stages.py", line 311, in instancify     return self._reflect_cur_instance()   File "/usr/lib/python2.7/dist-package
[13:22] <nakul> @powerj : do you have any mail id to share the logs ?
[13:23] <nakul> i followed this url for image creation : https://thornelabs.net/2014/04/07/create-a-kvm-based-debian-7-openstack-cloud-image.html
[13:25] <blackboxsw> nakul: if possible to redact the /var/log/cloud-init.log  to something that could be shared it would be helpful to file a bug at https://bugs.launchpad.net/cloud-init/+filebug with any information you can provide
[13:26] <blackboxsw> so others could benefit from the fix too. we can contact you with more requests if the bug filed doesn't have enough information to understand the problem
[13:32] <nakul> blackboxsw: ok but i am not sure weather its a bug or some misconfiguration  or something else
[13:39] <blackboxsw> nakul: that howto is really dated (2014)... maybe this would help https://asciinema.org/a/132009
[13:40] <blackboxsw> rewriting that cloud.cfg file is potentially dated/broken in that howto you referenced
[13:44] <nakul> dont think so..still let me try once more else i'll post the issue in +filebug site
[13:44] <nakul> thanks blackboxsw
[13:44] <nakul> ohh..thanks Chad Smith
[13:52] <blackboxsw> no problemo nakul  that'd be smoser to thank
[13:53] <blackboxsw> :0
[13:53] <blackboxsw> :)
=== shardy is now known as shardy_mtg
=== shardy_mtg is now known as shardy
[15:38] <utlemming> smoser: around?
[15:38] <utlemming> https://gist.github.com/utlemming/288607e974f597d89d940474874551df
[15:39] <utlemming> smoser: looks like SysConfig rendering for network configuration is broken for IPv6 default routs
[15:39] <utlemming> I can't tell whether its Fedora/RH or Debian/Ubuntu that is not following the spec
[15:39] <utlemming> since network_data.json is not well documented
[15:59] <robjo> smoser: Could you please give https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/331149 another look? Would like to get this finished so I can put the patch into the 17.1 SUSE package.
[16:00] <blackboxsw> will give it a pass robjo
[16:01] <robjo> blackboxsw: thanks, I just fixed the alpha order issue I hope, as I couldn't reproduce that locally, so the bot will need to do another run
[18:07] <benray> Hope it's OK to ask a general question here. How to populate ifcfg file with 'DHCP_HOSTNAME=<hostname>' prior to network start? If I use bootcmd it gets overwritten
[18:15] <rharper> benray: we don't currently have a way to do that;  ifupdown doesn't support DHCP_HOSTNAME, but it doe support hostname <hostname value> which should get passed to the client
[18:15] <benray> Thanks! I might be able to live with rc.local
[18:15] <rharper> *ifupdown in ubuntu at least
[18:16] <benray> RHEL in this case
[18:16] <benray> I believe ubuntu is a little more elegant in this regard
[18:16] <rharper> ok; so for the sysconfig backend
[18:17] <rharper> but generally, it appears there are some client dhcp options we should support (hostname, lease, client, vendor) strings that dhcp clients would submit in their request IIUC
[18:17] <benray> That would be cool. Thought I would ask in case it was just hiding somewhere
[18:18] <benray> :)
[18:21] <rharper> benray: ok, I filed a bug https://bugs.launchpad.net/cloud-init/+bug/1720426
[18:21] <ubot5> Ubuntu bug 1720426 in cloud-init "network-config should allow dhcp client option values" [Undecided,New]
[18:21] <benray> Nice! Thanks for looking into it
[18:22] <rharper> benray: sure, thanks for pointing it out
[18:22] <benray> Keep up the great work
[19:24] <rispa> hello. I'm trying to figure out how to disable different cloud-init datasources. Not sure why, but I can't seem to figure out from the docs.
[19:25] <rispa> Basically, we're using cloud-init on internal vms with a cloud-config drive. When the cloud-config drive isn't there or is misconfigured, cloud-config tries to hit a bunch of metadata urls and eventually times out
[19:25] <rispa> this really slows down boot time -- takes around 10 minutes
[20:53] <blackboxsw> rispa:  on your vms you can either dpkg-reconfigure cloud-init  to enable/disable
[20:54] <blackboxsw> rispa:  on your vms you can either dpkg-reconfigure cloud-init  to enable/disable datasources....
[20:54] <blackboxsw> or you can edit your /etc/cloud/cloud.cfg.d/90_dpkg.cfg datasource_list
[20:54] <blackboxsw> and remove any datasources in your images you don't want to try
[20:55] <blackboxsw> rispa: I'll add a work item for additional docs on this as I can't find them either
[21:02] <rispa> blackboxsw: datasource_list is working great -- thanks very much!
[21:02] <smoser> rispa, just fwi, there really should not be a reason to do that.
[21:02] <smoser> if it is timing out, its due to the ec2 datasource, which should be done last.
[21:02] <smoser> wonder if you could post a cloud-init.log
[21:04] <smoser> rispa, oh. yes. if you remove the disk it will do that.
[21:05] <smoser> you can set in the image "manual_cache_clean: true"
[21:05] <smoser> and that means that if there is a cached datasource cloud-init will not go looking again
[21:05] <smoser> so you can boot once with the disk, and then take it away
[21:05] <smoser> but if you do that then you have to clean yourself, or cloud-init will never go looking again.
[21:08] <rispa> smoser: thanks! it's definitely only a problem when the cloud config drive is missing or broken. more of annoyance than anything else