=== powersj_ is now known as powersj [04:38] Hi [04:42] I have a ubuntu-16.04 on google cloud platform, and I give it a multi-mime userdata which I know works on aws. cloud-init configuration seems fine on the server and cloud-init version is 18.2. It executes the first portion which is #cloud-config format but doesn't execute the text/x-shellscript part. Any idea why? I've check /var/log and I don't find any errors. I'm executing a simple 'touch somefile.txt' and there's no file on === catmando_ is now known as catmando === cyphermo1 is now known as cyphermox === r-daneel_ is now known as r-daneel [15:16] powersj: I'm struggling to work out how to make this "get the SSH key on to the instance" change in an appropriate manner. [15:17] powersj: I was wondering if you might be able to implement a basic disable_root test (which would enable SSHing to the instance under test from the instance itself), and then I can expand on that once the test framework functionality is in place? [15:51] Odd_Bloke: I'm not sure I see other tests re-using that functionality [15:51] Odd_Bloke: can you show me what you have? [15:52] powersj: I haven't got anything, because I couldn't work out where to add it. [15:54] (AFAICT, I can't just do it for one test, because tests don't define any Python code that runs on the testing host, so the framework would need to change somehow.) [16:14] rezroo: stderr of scripts get emitted to /var/log/cloud-init-output.log so there may be error messages hiding in there. If you think there is a bug (because you say is works on aws but not on gce) you could file a bug with "ubuntu-bug cloud-init" on the commandline with the details [17:11] rharper: I'll need to steal you for a little bit today on the netplan match question for Azure. when's a good time? [17:43] blackboxsw: sorry, what's this about? [17:47] cyphermox: cloud-init uses to netplan's match: macaddress as we expect that mac will be persistent and unique for a single device even despite any logical versus persistnet network naming. this causes an issue for azure instances which end up dropping the original nic and attaching a new nic to the instance. cloud-init doesn't regenerate netplan network config for this instance, because azure doesn't expose a new UUID [17:47] for the instance (which would trigger a netplan config regeneration), so cloud-init doesn't update network config containing the mac address of the new device [17:48] * blackboxsw needs to understand azure's use-case for dropping existing nic and replacing with a new nic. As this feels like an infrequent use-case. [18:33] blackboxsw: I'm back now [18:33] now is fine for chat [18:33] good, deal, grabbing a quick coffee [18:38] rharper: jumping into cloud-init hangout [18:38] k [18:39] blackboxsw: hangout or meet ? [19:11] blackboxsw: I filed a bug with google. I don't think it's ubuntu's fault. I think gce uses cloud-init in how it provisions ubuntu in it's infrastructure in such a way that subsequent x-shellscripts from the user don't run. If I understand it correctly these are only run once, and if gce runs its own shellscript then there would be a marker in /var/lib/cloud/instance that would stop another script to run. I'm [22:24] I'm starting down the path of backports to trusty. git clone ; git checkout -b trusty-joyent remotes/origin/ubuntu/trusty; make deb [22:24] And it wants to use bzr. Ugh. Never done that before [22:24] mgerdts: :) [22:24] I can't find any instructions that help me check out this branch from bzr. README.rst in that branch has instructions that are too terse for a first time bzr user. Any hints? [22:25] Or should I realize that it is after 5 pm and go find a beer instead? I'm really ok if that is the right answer tonight. :) [22:27] mgerdts: which branch? [22:27] mgerdts: can you point me at the README.rst? [22:28] ubuntu/trusty [22:29] https://github.com/cloud-init/cloud-init/blob/ubuntu/trusty/HACKING.rst [22:29] sorry, HACKING.rst [22:32] It was missing the launchpad-login step, so did that, then got a key that works with launchpad, added that to my keyring [22:33] https://hastebin.com/fiqulimuwi.rb [22:53] thanks that helps [22:54] ah, I see [22:54] we switched to git [22:55] so, your first step there is failing, you are trying to checkout in effect the 'trunk' branch of the repository, but that is now in git. [22:58] I know that for trusty, things are still in flux, as you'll notice there is no branch in the upstream git repo for 'ubuntu/trusty'. [22:58] like there is for 'ubuntu/xenial' [22:59] mgerdts: tl;dr, for trusty, I think you should get that beer and ask when folks are around tomorrow. :) [23:00] Good plan. :)