[15:29] <catmando> hey all
[15:35] <rharper> howdy
[15:39] <catmando> does anyone have experience with cloud-init on power?
[15:54] <rharper> catmando: yeah;  though cloud-init's python, it's generally the same everywhere; is there a specific environment ?
[15:56] <catmando> yes, ubuntu 16.04 on ppc. the issue is likely in documentation
[15:57] <catmando> i am trying to work out how to set the hostname of a new instance to be the name of the instance if the dns reverse lookup does not work
[16:02] <rharper> catmando: interesting problem
[16:04] <catmando> powervc has a custom module that allows set_hostname_from_dns
[16:04] <rharper> cloud-init isnt going to do any hostname reverse lookup validation; none that I'm aware of
[16:04] <catmando> (and also set_hostname_from_interface // set_dns_shortname)
[16:04] <catmando> https://www.ibm.com/support/knowledgecenter/SSXK2N_1.4.0/com.ibm.powervc.standard.help.doc/powervc_custom_modules.html
[16:05] <catmando> but I am wondering how to deal with the case when that module failes
[16:05] <catmando>  s/failes/fails
[16:13] <smoser> blackboxsw: did you want to talk about ssh keys ?
[16:14] <blackboxsw> yeah will rejoin. thought powersj needed to be there but let's chat
[17:42] <blackboxsw> hrm, was just deploying azure bionic and I expected to see the traceback about ifdown/ifup not working.... but the bionic images in azure have net-tools now. hmm
[17:43] <smoser> blackboxsw: are you sure ?
[17:43] <smoser> i have absolutely seen the warn before
[17:43] <smoser> oh. yeah, we talked about htis yesterday
[17:43] <smoser> byobu
[17:43] <smoser> :)
[17:43]  * blackboxsw checks what brought that in https://pastebin.ubuntu.com/26216372/
[17:43] <blackboxsw> ohh right
[17:44] <blackboxsw> but I'm wondering why this failed before... didn't we always have byobu on artful when you filed  https://bugs.launchpad.net/cloud-init/+bug/1722668
[17:44] <ubot5`> Launchpad bug 1722668 in cloud-init (Ubuntu) "Azure: bouncing of network device/publishing of hostname fails on artful" [Critical,Confirmed]
[17:45] <blackboxsw> nevermind
[17:45] <blackboxsw> I crossed my stream
[17:45] <blackboxsw> I crossed my streams
[17:45] <blackboxsw> that's from ifupdown which byobu doesn't depend on
[17:45] <blackboxsw> and still isn't in the bionic images
[17:46]  * blackboxsw will  find another reason why bionic azure images didn't traceback like in the bug above.
[17:47] <smoser> bionic images (lxc) definitely do have net-tools
[17:47] <blackboxsw> maybe I just need to provide a hostname in cloud-config to reproduce the issue with bounce
[17:48] <smoser> http://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-arm64.squashfs.manifest
[17:48] <smoser> but id' think you'd still see a warning or something
[17:49] <smoser> as even if it weret there the bounce would use it
=== r-daneel_ is now known as r-daneel
[18:06] <blackboxsw> https://pastebin.ubuntu.com/26216469/
[18:06] <blackboxsw> ok able to reproduce if my cloud-config contains a hostname different than the hostname I created the vm with on the cmdline
[21:28] <blackboxsw> paulmey: have a couple mins for some Azure questions? The datasource currently bounces the network interface across hostname changes (from user-data) to update DDNS with the new hostname record on the interface. It relies on ifdown ifup utils that are now abset(deprecated) in artful and bionic because ifupdown package is no longer in cloud images in factor of moving to the iproute2 package in a systemd world.
[21:28] <blackboxsw> The question is, it seems in artful and and bionic a simple call to hostname (without the ifdown ifup) has properly updated ddns as I can nslookup <mynewhostname> and get the authoritative answer.
[21:29] <blackboxsw> I mean the question is can we drop the bounce in the systemd world because my only understanding about the hostname bounce was that it was used to inform DDNS, which seems to work.
[21:30] <blackboxsw> I'll run through xenial test without the bounce versus artful test without the bounce and see if anything differs. What I have found is that even if we get a Traceback on missing ifdown/ifup cmdline utils, hostname of the machine is still set properly, and nslookup <myhostname> is being properly reported by ddns
[21:37]  * powersj is in vpc hell
[21:37] <rharper> powersj: nuke it
[21:37] <powersj> heh
[21:46] <blackboxsw> powers nukes hell.... story at 11
[22:10] <blackboxsw> just noted on xenial if we set hostname via #cloud-config, DDNS is not updated properly. artful and bionic do handle it (despite the ifdown/ifup Traceback)
[22:10] <blackboxsw> might open a bug against xenial azure for this
[22:51] <blackboxsw> hrm de-opped because of my nick registration maybe?
[22:51] <blackboxsw> powersj: rharper can you op me again?
[22:51] <rharper> yeah
[22:51] <blackboxsw> I think I've sorted IRC nick registration
[22:51] <powersj> how does on OP someone
[22:51] <blackboxsw> like that ;)
[22:51] <powersj> so if my nick is registered does that mean I keep op?
[22:51] <blackboxsw> for us powersj click their nick on the right and click 'op'
[22:51] <rharper>  /OP <nick>
[22:52] <rharper> powersj: the ChanServ handles that
[22:52] <blackboxsw> or that ;)
[22:52] <blackboxsw> :)
[22:52] <powersj> ah
[22:52] <rharper> once you have a registered nic via NickServ, then the channel owner says the following registered nics have these ops, etc
[22:52]  * rharper regrets giving too much power to blackboxsw 
[22:53] <powersj> ah so if smoser has it setup to give us OP it will auto-give us op?
[22:53] <rharper> yeah
[22:53] <rharper> prolly needs to poke some config in the ChanServ bot
[22:53] <blackboxsw> my children regret the same.... and their fighting against the "dad power" ever since
[22:54] <powersj> he should do that for #curtin as well
[22:55] <rharper> yeah
[23:11] <blackboxsw> rharper: are yahoo employees covered under our CLA?
[23:12] <blackboxsw> we just got a branch from someone at yahoo
[23:46] <rharper> blackboxsw: not sure