[01:54] Hi, I've updated my cloud-init to 0.7.9 on centos 7 with a centos 7 package I found there : https://buildlogs.centos.org/c7-extras/cloud-init/20170705233059/0.7.9-3.el7.centos.x86_64/ [01:54] I've been testing the new version and I'm getting a strange error regarding utf8 encoding when my test VM starts [01:56] Essentially I get AttributeError: 'dict' object has no attribute encode . Is that version of cloud-init currently compatible with openstack? [02:01] redcavalier: could you file a bug, I know we have builds using copr build service https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/builds/ [02:02] 0.7.9.3 per your version feels stale compared to 0.7.9+224.g681baff-1 in our copr build service [02:04] if you hit this issue again on the newer centos build, I'd be curious to see /var/log/cloud-init.log from the affected system [02:04] https://bugs.launchpad.net/cloud-init/+filebug if needed [02:05] blackboxsw, thx, I was under the impression that copr only had recent fedora builds. I'll try that build and come back if I still get an error [02:06] a shame that the official centos repo's versions are downright ancient. [02:06] per earlier meetingology discussion: 4:12 PM J<•jose> it should stick. we had an issue and I had to kill all the meetingology instances, that's why it got out [02:06] yeah, though it's hard to get every distro to update on the same schedule :) [02:44] blackboxsw, still got the error, here's the full trace of it : https://pastebin.com/tmv7asfL [02:48] hrm I guess what content was in vendordata_raw from your openstack instance. might have to dig into this a bit more, could you file a bug redcavalier (I'm end of day today) include the following if you could http://pastebin.ubuntu.com/25475835/ [02:48] sure no problem [02:48] I know you are centos && openstack and our latest copr build. but the rest would be good contxt [02:48] cheers [02:49] thx === shardy is now known as shardy_afk === shardy_afk is now known as shardy === shardy_ is now known as shardy [10:21] I am trying to get cloud-init to interpolate $local-ipv4, $local_ipv4, $private-ipv4 or $private_ipv4, but none of them work. I am booting CentOS 7 with cloud-init 0.7.9 on CloudStack. "curl -s http://10.30.5.1/latest/meta-data/local-ipv4" from within the VM shows the IP address that I want. [10:21] I also couln't locate the place in the docs where this is described. [10:22] Can anybody help me find out how I can get cloud-init to interpolate the local ipv4 address in the cloud-config? [15:44] smoser:EphemeralIPv4Network does already self.cleanup_cmds.append( [15:44] ['ip', '-family', 'inet', 'link', 'set', 'dev', self.interface, [15:44] 'down']) [15:45] that should be run via subp on __exit__ from EphemeralIPv4Network [15:45] ['ip', '-family', 'inet', 'addr', 'del', cidr, 'dev', self.interface] too [15:46] If we are seeing devices left "up" maybe cloud-init saw them up in the first place, and would have logged Skip ephemeral network setup, %s already has address %s [15:52] blackboxsw, well, i think i see a few issues. [15:52] maybe_perform_dhcp_discovery() sets link up but never sets it down [15:52] (and that state would be inherited by EphemeralIPv4Network) [15:53] and then i *think* EphemeralIPv4Network unconditionally will take it down [15:54] ahhh right, right on maybe_dhcp_discovery [15:55] hmm so, in that case I'd expect to see Skip ephemeral network setup, %s already has address %s in our ec2 logs always [15:56] and ephemeralIPv4 will leave an "up" interface up if it specifically didn't set it up [15:56] so that logic interaction between maybe_dhcp_discovery and Ephemeral needs a fix [16:01] blackboxsw, i just launched an instance. i'll import you to poke around in a minute [16:02] same [16:02] ubuntu@13.58.109.199 [16:02] ahh thanks [16:03] 2017-09-06 16:01:03,490 - util.py[DEBUG]: Running command ['ip', '-family', 'inet', 'link', 'set', 'dev', 'eth0', 'down'] with allowed return codes [0] (shell=False, capture=True) [16:03] looks like we tore it down smoser [16:06] blackboxsw, wrt this breaking some-old-openstack [16:07] theory: non-intel fell down the "fallback to ec2" path because of non-intel [16:07] then we end up trying the new api endpoint [16:07] which probably doesnt exist (that i can verify) [16:07] we should actually be able to force this failure path on server stack [16:07] or get close [16:08] ahh you mean we somehow die on ec2 inspecting 2016-09-02 version [16:09] agreed, we can try that route. or I wonder about our test httpretty regiester_mock_metaserver [16:11] hmm, server stack would be the easiest route for a real openstack env. I'm looking over DataSourceOpenStack to see what it does w/ network setup [16:23] smoser done w/ ubuntu@13.58.109.199 thanks. I'll play w/ other instances [16:23] shall I shut it down? [16:47] blackboxsw, i'll kill it. thanks. [18:28] Hi! Just a quick question. I am trying to make custom AMIs using Packer. I would like every machine that I spin up with this custom AMI to execute a cloud-init script once (to pull configuration). What is the most robust way to make this happen? [18:32] asthasr: when you say once, do you mean once per boot, or once per instance? Maybe you are talking about something like this? https://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-per-once [18:33] you can install your own scripts in an ami which run every time the machine instance id changes, or per-boot etc. [18:33] Ok, cool. [18:33] When do "per-instance" scripts run? Is that after the first boot of an instance with a new ID? [18:34] i.e. I make the AMI, put something in per-instance, and then if I build a new machine based on that, it'll run? [18:35] (I saw this list before but the difference between per-once and per-instance was not clear to me.) [18:35] asthasr, yes. [18:36] per-once will run once ever (marker files are written with no specific instance data) [18:36] correct, new intance-id is generated each time the AMI is "built/deployed" [18:36] correct, new instance-id is generated each time the AMI is "built/deployed" for per-instance [18:36] per-instance will run once per instance-id (marker files contain instance-id in their path) [18:36] per-always will run every boot [18:37] instances are things which are created from images. [18:37] ami == amazon machine image [18:37] * asthasr nods. [18:37] so each thing you launch from athis ami that you built is a unique instance [18:39] yeah. My desired workflow is: create a "template" server, run packer to make an ami, then use terraform to spin up instances based on that ami, which (upon booting) run ansible to configure themselves [18:39] so per-instance sounds right. [18:42] blackboxsw: did you have a branch which added a subcommand to crawl/dump metadata (like openstack) ? [18:49] asthasr, the only thing i'd suggest is not bothering to build your own images. [18:49] but rather to either [18:50] a.) use unmodified "Official" Ubuntu images [18:50] b.) download images from cloud-images.ubuntu.com as a starting point and make your modifications and upload. [18:50] Certainly, I intend to use an official Ubuntu 16.04 and just make some basic configuration changes to it [18:51] "packer to make an ami" [18:51] i'm saying skip that [18:52] but why? It seems like if I want to rebuild a machine it's quicker to have an image that has all the prereqs and such on it beforehand [18:52] rharper: that branch I haven't put together yet (it's a followup to https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/330115 ) [18:52] wanted to land the prerequisite first [18:53] cool [18:53] rharper: shameless plug for a review on that branch :) [18:53] I think I've given you one, no ? [18:54] refresh says no comments on this branch [18:54] noo! I must have closed the tab before submit [18:54] ok, I'll re-review [18:54] oh. asthasr i guess i didnt understand how packer worked. [18:54] i always asumed it built the image "from scratch". [18:54] bah, hopefully launchpad saved the unsaved comments [18:56] blackboxsw: man, I even updated the commit message and had comments; so strange [18:59] rharper, how did you get status from systemd-resolved? [19:00] smoser: No, you just spin up a box and then configure it how you want and then it takes that box and makes a new image from it [19:00] smoser: So, it can be based on whatever base AMI you want :) [19:00] systmed-resolved --status (but only on artful IIRC) [19:00] systemd-resolved --status [19:00] err, drop the d; systemd-resolve --status [19:01] smoser: ^ [19:01] yeah. i see. thanks. [20:53] hey guys [20:53] what could make cloud-init truncate /var/log/messages? [20:54] I looked at the code and didn't find anything... [20:54] cloud-init doesn't touch /var/log/messages ; it owns /var/log/cloud-init.log and /var/log/cloud-init-output.log [20:55] cloud-init will use syslog; so maybe a local config that triggered logrotate ? [20:55] do you have messages.1 ? [21:02] rharper, nope... and that's what I was expecting to hear from you :) [21:02] rharper, I looked at the code and nothing mentionned /var/log/messages from close or far [21:04] right, and what about possible rotated files? do you know how (or if) logrotate is configured on your instance ? [22:32] powersj: additional comments on https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/327646 [22:34] blackboxsw: getting the command line for your failures would be very helpful [22:35] common theme from the reviews I've seen is how the lxd backend returns return codes and kvm does not [22:35] that's the reason for the "0" [22:39] I'm with you on the 0 being returned from execute() just feels strange from within mount_image_callback