| 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:54 |
| redcavalier | Essentially I get AttributeError: 'dict' object has no attribute encode . Is that version of cloud-init currently compatible with openstack? | 01:56 |
| 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:01 |
| blackboxsw | 0.7.9.3 per your version feels stale compared to 0.7.9+224.g681baff-1 in our copr build service | 02:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| redcavalier | blackboxsw, still got the error, here's the full trace of it : https://pastebin.com/tmv7asfL | 02:44 |
| 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:48 |
| redcavalier | thx | 02:49 |
| === shardy is now known as shardy_afk | ||
| === shardy_afk is now known as shardy | ||
| === shardy_ is now known as shardy | ||
| 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:21 |
| larstobiweb | Can anybody help me find out how I can get cloud-init to interpolate the local ipv4 address in the cloud-config? | 10:22 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:52 |
| smoser | and then i *think* EphemeralIPv4Network unconditionally will take it down | 15:53 |
| blackboxsw | ahhh right, right on maybe_dhcp_discovery | 15:54 |
| 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:55 |
| 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 | 15:56 |
| smoser | blackboxsw, i just launched an instance. i'll import you to poke around in a minute | 16:01 |
| blackboxsw | same | 16:02 |
| smoser | ubuntu@13.58.109.199 | 16:02 |
| blackboxsw | ahh thanks | 16:02 |
| 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:03 |
| smoser | blackboxsw, wrt this breaking some-old-openstack | 16:06 |
| 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:07 |
| blackboxsw | ahh you mean we somehow die on ec2 inspecting 2016-09-02 version | 16:08 |
| blackboxsw | agreed, we can try that route. or I wonder about our test httpretty regiester_mock_metaserver | 16:09 |
| 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:11 |
| 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:23 |
| smoser | blackboxsw, i'll kill it. thanks. | 16:47 |
| 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:28 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:39 |
| rharper | blackboxsw: did you have a branch which added a subcommand to crawl/dump metadata (like openstack) ? | 18:42 |
| smoser | asthasr, the only thing i'd suggest is not bothering to build your own images. | 18:49 |
| smoser | but rather to either | 18:49 |
| 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:50 |
| smoser | "packer to make an ami" | 18:51 |
| smoser | i'm saying skip that | 18:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| rharper | blackboxsw: man, I even updated the commit message and had comments; so strange | 18:56 |
| smoser | rharper, how did you get status from systemd-resolved? | 18:59 |
| 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:00 |
| rharper | smoser: ^ | 19:01 |
| smoser | yeah. i see. thanks. | 19:01 |
| dhill_ | hey guys | 20:53 |
| dhill_ | what could make cloud-init truncate /var/log/messages? | 20:53 |
| 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:54 |
| rharper | cloud-init will use syslog; so maybe a local config that triggered logrotate ? | 20:55 |
| rharper | do you have messages.1 ? | 20:55 |
| 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:02 |
| rharper | right, and what about possible rotated files? do you know how (or if) logrotate is configured on your instance ? | 21:04 |
| blackboxsw | powersj: additional comments on https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/327646 | 22:32 |
| powersj | blackboxsw: getting the command line for your failures would be very helpful | 22:34 |
| 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:35 |
| blackboxsw | I'm with you on the 0 being returned from execute() just feels strange from within mount_image_callback | 22:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!