16:05 <ijw> #startmeeting networking-vpp
16:05 <meetingology> Meeting started Mon Jul 23 16:05:02 2018 UTC.  The chair is ijw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
16:05 <meetingology> 
16:05 <meetingology> Available commands: action commands idea info link nick
16:06 <ijw> OK, my punishment for that was crashing my client...
16:09 <smoser> :)
16:09 <smoser> penance paid
16:10 <rharper> lol
16:36 <smoser> mgerdts: you missed one set notation
16:36 <smoser> https://jenkins.ubuntu.com/server/job/cloud-init-ci/172/consoleFull
16:36 <smoser> cloudinit/sources/tests/test_init.py
17:12 <smoser> rharper: a review of https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/349359 would be good. its redhat specific and at redhat request, and i agree with it :)
18:01 <rharper> smoser: looking
18:19 <mgerdts> thanks smoser.  I'll get to that over the next day or so.  Just about to pack up to hop on a plane.
20:05 <smoser> filed https://bugs.launchpad.net/cloud-init/+bug/1783198
20:05 <ubot5> Ubuntu bug 1783198 in cloud-init "transient failures during lxc test during shutdown" [Medium,Confirmed]
20:05 <smoser> looking at it.
18:41 <dubuc> hello guys! :)
18:41 <dubuc> is this the correct place if we have some questions regarding cloud-init?
18:41 <dubuc> or there is a better medium?
18:43 <rharper> yes
18:43 <rharper> dubuc: ask away
18:43 <dubuc> thanks! :)
18:45 <dubuc> well, I am trying to change some mount points on an Azure VM running OpenLogic CentOS 7.4 (we manually install cloud-init with packer and save the Azure VM Image). When I specify the mount location of the ephemeral disk of that machine, it generates an /etc/fstab that does not match the location Azure mounts the ephemeral disk (/mnt/resource). This causes the mnt.mount to fail because of the wrong /etc/fstab
18:46 <dubuc> https://gist.github.com/dubuc/2db3dc3efc27750b1d43e8b28eabc64a this is the cloud-init.txt I pass when I create the VM with Azure CLI (az vm create --image ... --custom-data cloud-init.txt ...)
19:56 <rharper> dubuc: sorry for the delay;  had some meetings, let's see what's going on
19:57 <dubuc> yeah well rharper, I read the docs
19:58 <dubuc> apparently cloud-init does not support changing the mount point of the resource disk (ephemeral) on azure, and the waagent is supposed to handle that. could you confirm?
19:58 <dubuc> http://cloudinit.readthedocs.io/en/latest/topics/datasources/azure.html#waagent-conf-config
20:02 <rharper> do you have the cloud-init.log from the failure ? and can you confirm what cloud-init version you're running ?  I know we've seen some issues w.r.t empheral storage config so it may be resolved in master or might be a new issue
20:02 <dubuc> yes
20:02 <dubuc> give me a sec
20:03 <dubuc> but I did find the fix for my issue of failed mnt.mount service by following the `/mnt` location instead of the default waagent.conf `/mnt/resource`.
20:04 <dubuc> cloud-init 0.7.9
20:05 <rharper> ok, there's definitely newer cloud-init that has had some changes w.r.t azure ephmeral devices
20:06 <rharper> https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/
20:06 <rharper> you could try from the cloud-init-dev repo; that's a daily build from master
20:07 <rharper> if you can't then I suggest filing a bug with the cloud-init logs (/var/log/cloud-init* /var/lib/cloud/*) and your cloud-config you already pasted;
20:08 <dubuc> will try that
20:08 <dubuc> thank you rharper
20:08 <rharper> dubuc: sure
13:04 <nspmangalore> Hi all
13:04 <nspmangalore> I went through the cloud-init documentation
13:06 <nspmangalore> I've ported an AWS EC2 instance into my local xenserver setup
13:07 <nspmangalore> Now looking to modify cloud-init to work on this setup. So I wrote a small custom datasource on the ported VM
13:08 <nspmangalore> After reboot of the VM, I'm expecting that at least the VM's hostname should change. But that is not happening
13:08 <nspmangalore> First of all, I'd like to understand if what I'm expecting is valid
13:09 <nspmangalore> Is it?
21:02 <smoser> ugh.
21:02 <smoser> i'm am at a loss for this transient failure https://bugs.launchpad.net/cloud-init/+bug/1783198
21:02 <ubot5> Ubuntu bug 1783198 in cloud-init "transient failures during lxc test during shutdown" [Medium,Confirmed]
21:04 <smoser> i was sure that we were calling LXDInstance.destroy() multiple times or referencing a LXDInstance.pylxdcontainer after it'd been deleted
21:04 <smoser> bt i sure can't reproduce that
21:26 <rharper> smoser: when all else fails, blame systemd
13:06 <m00c0w> Hi! I'm new to using cloud-init and I have success with CentOS 7.  But when I try to spin up Ubuntu 18.04 using the CLoudImage I end up with KVM console saying that there is no boot partition. Is anything special required to do cloud-init with kvm/Ubuntu Bionic other than converting the img file to qcow2?
13:36 <smoser> m00c0w: that seems unlikely related to cloud-init
13:36 <smoser> i suspect you have an entry in /etc/fstab that is not right.
13:37 <smoser> fwiw, i would always using offiicial downloadable images from cloud-images.ubuntu.com
13:37 <smoser> if you have to modify them, I'd suggest modifying the images rather than building yourself elsewhere.
13:38 <smoser> caribou: do you need anything from me ?
16:28 <m00c0w> smoser: I figured it out. There are many different cloud images available for Ubuntu and while the filename was the exact same for the image I had, it was found in the wrong folder on the mirror site. Took a while to figure out
16:34 <m00c0w> m00c0w: https://paste.ee/p/4tHJ9    Confusing, right? ;)
18:08 <smoser> powersj: i want to run https://jenkins.ubuntu.com/server/job/cloud-init-integration-lxd-c
18:08 <smoser> against https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/351371
18:08 <smoser> in order to catch bug 1783198
18:08 <ubot5> bug 1783198 in cloud-init "transient failures during lxc test during shutdown" [Medium,Confirmed] https://launchpad.net/bugs/1783198
18:08 <smoser> any thoughts on how best to do that ?
18:09 <powersj> https://github.com/CanonicalLtd/server-jenkins-jobs/blob/master/cloud-init/integration-lxd.yaml#L56
18:10 <smoser> powersj: well, i want to run it on on c-i hardware
18:10 <smoser> i've not caught the failure here.
18:10 <powersj> you have ssh to torkoal ;)
18:10 <smoser> thats fine
18:11 <powersj> would you prefer a debug job? like we do for vmtest
18:11 <smoser> i guess that'd be nice. but i'm ok for now to just run on taht system.
15:21 <smoser> powersj: https://jenkins.ubuntu.com/server/view/cloud-init,%20curtin,%20streams/job/cloud-init-integration-lxd-c/
15:22 <smoser> how often / how does that run ?
15:22 <smoser> it looks like it just stopped running on the 20th
15:22 <powersj> lxd is daily
15:22 <powersj> hmmm
15:24 <powersj> hmm xenial is running daily, but not set to kick the bionic test
15:24 <powersj> doh: set to kick project: cloud-init-integration-lxd-a
15:25 <smoser> hm..
15:26 <powersj> fixed
16:15 <[42]> can you point me somewhere for getting started creating a debian template image to be used with qemu (proxmox)?
16:33 <blackboxsw> smoser, time to reset cloud-init status meeting date. it doesn't look like we had one since 07/02
16:34 <blackboxsw> and it looks like someone kicked off a meeting start a couple days ago by accident
16:34 <blackboxsw> https://ubottu.com/meetingology/logs/cloud-init/2018/cloud-init.2018-07-23-16.05.log.txt
16:34 <blackboxsw> #endmeeting