[01:54] <redcavalier> 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] <redcavalier> I've been testing the new version and I'm getting a strange error regarding utf8 encoding when my test VM starts
[01:56] <redcavalier> Essentially I get AttributeError: 'dict' object has no attribute encode . Is that version of cloud-init currently compatible with openstack?
[02:01] <blackboxsw> 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] <blackboxsw> 0.7.9.3 per your version feels stale compared to 	0.7.9+224.g681baff-1 in our copr build service
[02:04] <blackboxsw> 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] <blackboxsw> https://bugs.launchpad.net/cloud-init/+filebug if needed
[02:05] <redcavalier> 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] <redcavalier> a shame that the official centos repo's versions are downright ancient.
[02:06] <blackboxsw> 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] <blackboxsw> yeah, though it's hard to get every distro to update on the same schedule :)
[02:44] <redcavalier> blackboxsw, still got the error, here's the full trace of it : https://pastebin.com/tmv7asfL
[02:48] <blackboxsw> 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] <redcavalier> sure no problem
[02:48] <blackboxsw> I know you are centos && openstack and our latest copr build. but the  rest would be good contxt
[02:48] <blackboxsw> cheers
[02:49] <redcavalier> thx
[10:21] <larstobiweb> 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] <larstobiweb> I also couln't locate the place in the docs where this is described.
[10:22] <larstobiweb> Can anybody help me find out how I can get cloud-init to interpolate the local ipv4 address in the cloud-config?
[15:44] <blackboxsw> smoser:EphemeralIPv4Network does already             self.cleanup_cmds.append(
[15:44] <blackboxsw>                 ['ip', '-family', 'inet', 'link', 'set', 'dev', self.interface,
[15:44] <blackboxsw>                  'down'])
[15:45] <blackboxsw> that should be run via subp on __exit__ from EphemeralIPv4Network
[15:45] <blackboxsw>                 ['ip', '-family', 'inet', 'addr', 'del', cidr, 'dev', self.interface] too
[15:46] <blackboxsw> 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] <smoser> blackboxsw, well, i think i see a few issues.
[15:52] <smoser> maybe_perform_dhcp_discovery() sets link up but never sets it down
[15:52] <smoser> (and that state would be inherited by EphemeralIPv4Network)
[15:53] <smoser> and then i *think* EphemeralIPv4Network unconditionally will take it down
[15:54] <blackboxsw> ahhh right, right on maybe_dhcp_discovery
[15:55] <blackboxsw> 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] <blackboxsw> and ephemeralIPv4 will leave an "up" interface up if it specifically didn't set it up
[15:56] <blackboxsw> so that logic interaction between maybe_dhcp_discovery and Ephemeral needs a fix
[16:01] <smoser> blackboxsw, i just launched an instance. i'll import you to poke around in a minute
[16:02] <blackboxsw> same
[16:02] <smoser> ubuntu@13.58.109.199
[16:02] <blackboxsw> ahh thanks
[16:03] <blackboxsw> 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] <blackboxsw> looks like we tore it down smoser
[16:06] <smoser> blackboxsw, wrt this breaking some-old-openstack
[16:07] <smoser> theory: non-intel fell down the "fallback to ec2" path because of non-intel
[16:07] <smoser> then we end up trying the new api endpoint
[16:07] <smoser> which probably doesnt exist (that i can verify)
[16:07] <smoser> we should actually be able to force this failure path on server stack
[16:07] <smoser> or  get close
[16:08] <blackboxsw> ahh you mean we somehow die on ec2 inspecting 2016-09-02 version
[16:09] <blackboxsw> agreed, we can try that route. or I wonder about  our test httpretty regiester_mock_metaserver
[16:11] <blackboxsw> 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] <blackboxsw> smoser done w/ ubuntu@13.58.109.199 thanks. I'll play w/ other instances
[16:23] <blackboxsw> shall I shut it down?
[16:47] <smoser> blackboxsw, i'll kill it. thanks.
[18:28] <asthasr> 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] <blackboxsw> 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] <blackboxsw> you can install your own scripts in an ami which run every time the machine instance id changes, or per-boot etc.
[18:33] <asthasr> Ok, cool.
[18:33] <asthasr> When do "per-instance" scripts run? Is that after the first boot of an instance with a new ID?
[18:34] <asthasr> 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] <asthasr> (I saw this list before but the difference between per-once and per-instance was not clear to me.)
[18:35] <smoser> asthasr, yes.
[18:36] <smoser> per-once will run once ever (marker files are written with no specific instance data)
[18:36] <blackboxsw> correct, new intance-id is generated each time the AMI is "built/deployed"
[18:36] <blackboxsw> correct, new instance-id is generated each time the AMI is "built/deployed" for per-instance
[18:36] <smoser> per-instance will run once per instance-id (marker files contain instance-id in their path)
[18:36] <smoser> per-always will run every boot
[18:37] <smoser> instances are things which are created from images.
[18:37] <smoser> ami == amazon machine image
[18:37]  * asthasr nods.
[18:37] <smoser> so each thing you launch from athis ami that you built is a unique instance
[18:39] <asthasr> 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] <asthasr> so per-instance sounds right.
[18:42] <rharper> blackboxsw: did you have  a branch which added a subcommand to crawl/dump metadata (like openstack) ?
[18:49] <smoser> asthasr, the only thing i'd suggest is not bothering to build your own images.
[18:49] <smoser> but rather to either
[18:50] <smoser> a.) use unmodified "Official" Ubuntu images
[18:50] <smoser> b.) download images from cloud-images.ubuntu.com as a starting point and make your modifications and upload.
[18:50] <asthasr> Certainly, I intend to use an official Ubuntu 16.04 and just make some basic configuration changes to it
[18:51] <smoser> "packer to make an ami"
[18:51] <smoser> i'm saying skip that
[18:52] <asthasr> 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] <blackboxsw> 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] <blackboxsw> wanted to land the prerequisite first
[18:53] <rharper> cool
[18:53] <blackboxsw> rharper: shameless plug for a review on that branch :)
[18:53] <rharper> I think I've given you one, no ?
[18:54] <blackboxsw> refresh says no comments on this branch
[18:54] <rharper> noo! I must have closed the tab before submit
[18:54] <rharper> ok, I'll re-review
[18:54] <smoser> oh. asthasr i guess i didnt understand how packer worked.
[18:54] <smoser> i always asumed it built the image "from scratch".
[18:54] <blackboxsw> bah, hopefully launchpad saved the unsaved comments
[18:56] <rharper> blackboxsw: man, I even updated the commit message and had comments; so strange
[18:59] <smoser> rharper, how did you get status from systemd-resolved?
[19:00] <asthasr> 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] <asthasr> smoser: So, it can be based on whatever base AMI you want :)
[19:00] <rharper> systmed-resolved --status (but only on artful IIRC)
[19:00] <rharper> systemd-resolved --status
[19:00] <rharper> err, drop the d; systemd-resolve --status
[19:01] <rharper> smoser: ^
[19:01] <smoser> yeah. i see. thanks.
[20:53] <dhill_> hey guys
[20:53] <dhill_> what could make cloud-init truncate /var/log/messages?
[20:54] <dhill_> I looked at the code and didn't find anything...
[20:54] <rharper> cloud-init doesn't touch /var/log/messages ;  it owns /var/log/cloud-init.log and /var/log/cloud-init-output.log
[20:55] <rharper> cloud-init will use syslog;  so maybe a local config that triggered logrotate ?
[20:55] <rharper> do you have messages.1 ?
[21:02] <dhill_> rharper, nope... and that's what I was expecting to hear from you :)
[21:02] <dhill_> rharper, I looked at the code and nothing mentionned /var/log/messages from close or far
[21:04] <rharper> right, and what about possible rotated files?  do you know how (or if) logrotate is configured on your instance ?
[22:32] <blackboxsw> powersj: additional comments on https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/327646
[22:34] <powersj> blackboxsw: getting the command line for your failures would be very helpful
[22:35] <powersj> common theme from the reviews I've seen is how the lxd backend returns return codes and kvm does not
[22:35] <powersj> that's the reason for the "0"
[22:39] <blackboxsw> I'm with you on the 0 being returned from execute() just feels strange from within mount_image_callback