| sparc | Hey there, I was reading about coreos-cloudinit, and I see they allow some variables to be used in the cloud-config yaml document. | 02:19 |
|---|---|---|
| sparc | Is this something available in the cloudinit on Ubuntu and other distros also? | 02:20 |
| sparc | Essentially, I'd like to access an AWS instance's instance_id and tags if possible, from the cloud-config.yaml. | 02:21 |
| sparc | And treat cloud-config.yaml like a template. | 02:21 |
| sparc | I didn't see this on the readthedocs page :o/ | 02:21 |
| === rangerpbzzzz is now known as rangerpb | ||
| rharper | smoser: for bug 1675571 ; we should also add a resolvconf task; | 14:46 |
| smoser | rharper, i was going to ping you on that today. | 14:46 |
| rharper | I took a quick look at the ifupdown hooks from resolvconf and it wasn't obvious without more work to understand how we can tell if we're getting called as an alias | 14:47 |
| rharper | basically, resolvconf does $config > $IFACE.$ADDRFAM | 14:47 |
| rharper | so, the second iface entry clobbers the first | 14:47 |
| rharper | in some cases we want a clobber (ie, DHCP updated, or someone did an ifup again) | 14:47 |
| rharper | but for multiple stanzas, it should append | 14:48 |
| smoser | so.. since there is no 'ifupdown' way of bringing up eth0 (ipv6) without etho (ipv4) ... or generically the specific address. | 14:48 |
| smoser | then it seems sane that we can put all dns-nameservers on all of the stanzas | 14:48 |
| rharper | hrm, not following your first line | 14:48 |
| rharper | I can have a eth0 inet6 | 14:48 |
| smoser | ifup eth0 | 14:48 |
| rharper | oh, I see | 14:49 |
| rharper | yes | 14:49 |
| smoser | thats your only interface to ifup | 14:49 |
| rharper | you can't pick just one ip address to up | 14:49 |
| rharper | so, yes, we can repeat them under the same iface | 14:49 |
| smoser | thats a simpler fix than utlemming's also i think | 14:49 |
| rharper | I ended up doing that for netplan as well since networkd doesn;'t have a 'lo' interface for configuration IIRC | 14:49 |
| smoser | and not specific to digital ocean | 14:49 |
| rharper | right | 14:50 |
| rharper | it would help anyone in the multi-ip-per-interface case | 14:50 |
| smoser | you want to look at that ? | 14:50 |
| rharper | I cannot at the momemt | 14:50 |
| rharper | I have a hot issue I need to respond to | 14:50 |
| smoser | ok. well, thanks for chat. i'll try to get to it today. | 14:50 |
| === rangerpb is now known as rangerpbzzzz | ||
| Diranged | Hey.. I've got questions about error-handling on boot-scripts in cloud-init. Fundamentally if a script that cloud-init calls (from say runcmd) fails, can I have cloud-init trigger a "failure handling" script? | 17:26 |
| rharper | Diranged: there isn't a failure script configuration in cloud-init; rather if you need to handle failure? the command that runcmd runs should do error handling within; | 17:30 |
| Diranged | thats too bad .. it would be a lot more graceful for cloud-init to handle this.. | 17:32 |
| Diranged | ok second question.. is there a graceful way to pass environent variables to the commands cloud-init runs? (without doing it inside the individual command line) | 17:32 |
| rharper | let me seen, I'm not sure if cloud-init clears out the env | 17:41 |
| rharper | the run_commands and boot_commands files are handled by calling 'run-parts'; I don't see any restriction w.r.t ENV; each script/program is exec separately, so any env settings would need to be coordinated via file (sourcing a common settings file) | 17:54 |
| smoser | harlowja, around ? | 18:29 |
| harlowja | sorta | 18:29 |
| harlowja | :-P | 18:29 |
| smoser | you have a RH installed (or centos) installed openstack nova system i suppose | 18:29 |
| harlowja | correct | 18:30 |
| smoser | can you pastebin your /etc/nova/release ? | 18:30 |
| harlowja | what's that file, lol | 18:30 |
| smoser | thats where it stores all your passwords. | 18:30 |
| smoser | easy for me to get in that way. | 18:30 |
| smoser | :) | 18:30 |
| harlowja | lol | 18:30 |
| harlowja | don't think we have such file | 18:30 |
| smoser | https://bugs.launchpad.net/cloud-init/+bug/1675349 <-- checking if 'OpenStack Compute' is in there versus 'OpenStack Nova' | 18:31 |
| smoser | ok... i just wondered if the rhel provided packages did that. as it appears nebula.fi runs rhel host. | 18:31 |
| smoser | larsks, ^ do you know ? | 18:31 |
| harlowja | we don't use RHEL packages | 18:31 |
| harlowja | or not RH provided ones | 18:32 |
| larsks | smoser: I haven't ever seen an /etc/nova/release file before. | 18:32 |
| smoser | :) | 18:32 |
| * larsks looks | 18:33 | |
| smoser | fair enough. there is ./etc/nova/release.sample in nova's git tree | 18:33 |
| larsks | Okay, no passwords there. Just information about the version of nova that is installed. | 18:33 |
| smoser | and code shows nova/version.py reads it | 18:33 |
| smoser | larsks, i was just joking about the passwords | 18:33 |
| larsks | Right, yes. | 18:33 |
| smoser | can you pastebinit ? | 18:33 |
| larsks | Sure. This is from centos, probably newton-trunk from a few weeks ago... | 18:34 |
| larsks | http://chunk.io/f/2e634fc802224897800b0b1beceaa085 | 18:34 |
| smoser | yeah. that confirms that. 'OpenStack Compute' | 18:35 |
| smoser | versus 'OpenStack Nova'. | 18:35 |
| smoser | thanks. | 18:35 |
| smoser | any ideas why that is changed from upstream ? | 18:35 |
| smoser | just mostly curious | 18:35 |
| smoser | standards are easier utilized if they're standard | 18:35 |
| larsks | What does upstream look like? | 18:37 |
| larsks | Ah, I see. | 18:37 |
| larsks | No idea. I see that release.sample file has been sitting around since 2013. | 18:38 |
| larsks | Frankly, having vendor and product in there seems dumb. | 18:38 |
| larsks | And actually so does the package version. That is what your package database is for, right? | 18:38 |
| larsks | rpm -q --qf='%{VERSION}-%{RELEASE}\n' openstack-nova-compute | 18:39 |
| smoser | upstream reads that file if presetn but falls back to using 'OpenStack Nova'. | 18:39 |
| larsks | But...the fact that the file is in /etc/nova means we already *know* we've got openstack nova, right? | 18:42 |
| * larsks is confused | 18:42 | |
| smoser | i guess it could allow you to "vendorize" | 18:43 |
| === rangerpbzzzz is now known as rangerpb | ||
| === ijw_ is now known as ijw | ||
| === rangerpb is now known as rangerpbzzzz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!