[02:19] <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:20] <sparc> Is this something available in the cloudinit on Ubuntu and other distros also?
[02:21] <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/
=== rangerpbzzzz is now known as rangerpb
[14:46] <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:47] <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:48] <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:49] <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:50] <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.
=== rangerpb is now known as rangerpbzzzz
[17:26] <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:30] <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:32] <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:41] <rharper> let me seen, I'm not sure if cloud-init clears out the env
[17:54] <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)
[18:29] <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:30] <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:31] <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:32] <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:33]  * 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:34] <larsks> Sure.  This is from centos, probably newton-trunk from a few weeks ago...
[18:34] <larsks> http://chunk.io/f/2e634fc802224897800b0b1beceaa085
[18:35] <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:37] <larsks> What does upstream look like?
[18:37] <larsks> Ah, I see.
[18:38] <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:39] <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:42] <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:43] <smoser> i guess it could allow you to "vendorize"
=== rangerpbzzzz is now known as rangerpb
=== ijw_ is now known as ijw
=== rangerpb is now known as rangerpbzzzz