[04:38] <rezroo> Hi
[04:42] <rezroo> 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
[15:16] <Odd_Bloke> 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] <Odd_Bloke> 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] <powersj> Odd_Bloke: I'm not sure I see other tests re-using that functionality
[15:51] <powersj> Odd_Bloke: can you show me what you have?
[15:52] <Odd_Bloke> powersj: I haven't got anything, because I couldn't work out where to add it.
[15:54] <Odd_Bloke> (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] <blackboxsw> 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] <blackboxsw> 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] <cyphermox> blackboxsw: sorry, what's this about?
[17:47] <blackboxsw> 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] <blackboxsw> 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] <rharper> blackboxsw: I'm back now
[18:33] <rharper> now is fine for chat
[18:33] <blackboxsw> good, deal, grabbing a quick coffee
[18:38] <blackboxsw> rharper: jumping into cloud-init hangout
[18:38] <rharper> k
[18:39] <rharper> blackboxsw: hangout or meet ?
[19:11] <rezroo> 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] <mgerdts> 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] <mgerdts> And it wants to use bzr.  Ugh.  Never done that before
[22:24] <dpb1> mgerdts: :)
[22:24] <mgerdts> 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] <mgerdts> 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] <dpb1> mgerdts: which branch?
[22:27] <dpb1> mgerdts: can you point me at the README.rst?
[22:28] <mgerdts> ubuntu/trusty
[22:29] <mgerdts> https://github.com/cloud-init/cloud-init/blob/ubuntu/trusty/HACKING.rst
[22:29] <mgerdts> sorry, HACKING.rst
[22:32] <mgerdts> 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] <mgerdts> https://hastebin.com/fiqulimuwi.rb
[22:53] <dpb1> thanks that helps
[22:54] <dpb1> ah, I see
[22:54] <dpb1> we switched to git
[22:55] <dpb1> 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] <dpb1> 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] <dpb1> like there is for 'ubuntu/xenial'
[22:59] <dpb1> mgerdts: tl;dr, for trusty, I think you should get that beer and ask when folks are around tomorrow. :)
[23:00] <mgerdts> Good plan.  :)