[00:48] hello everyone [00:50] I want to commit my code, but the CLA always verified error,who can help me,thanks! === vrubiolo1 is now known as vrubiolo === MAbeeTT_ is now known as MAbeeTT === hjensas|afk is now known as hjensas === hjensas_ is now known as hjensas|lunch === hjensas_ is now known as hjensas [13:01] Hey folks, I'm trying to run the integration tests locally to test a refactor, and I'm running into this error (even in trunk): https://paste.ubuntu.com/p/5z364gWqVG/ [13:01] My command line is `tox -e citest -- run --verbose --preserve-data --data-dir results --os-name xenial --test modules/ntp.yaml --preserve-instance`. [13:01] (I'm trying a focal run right now.) [13:01] Any ideas what might be going on? [13:26] Is this what the kernel cmdline should look like for nocloud-net? `linuxefi /vmlinuz-3.10.0-1062.4.3.el7.x86_64 root=/dev/mapper/centos_centos--15388761-root ro crashkernel=auto rd.lvm.lv=centos_centos-15388761/root rd.lvm.lv=centos_centos-15388761/swap rhgb quiet LANG=en_US.UTF-8 ds=nocloud-net;s=http://hyperv01:5000` [13:26] It doesn't seem to be working unless there's something else I need to do with cloud-init besides just installing it (it is running but not using nocloud-net) [13:32] compufreak: Are you able to access the instance? If so, a pastebin of /var/log/cloud-init.log would be really handy. [13:32] & log https://pastebin.com/qnkpKFdV [13:33] Hah. [13:33] The datasource seems to work `[root@vmcent77template log]# curl http://hyperv01:5000/meta-data/hostname; echo ""vmcent77cloud-init-test` [13:35] & full grub.cfg https://pastebin.com/Wv08n2v1 [13:37] compufreak: To confirm: does the DS configuration show up in /proc/cmdline? [13:41] oof # cat /proc/cmdlineBOOT_IMAGE=/vmlinuz-3.10.0-1127.13.1.el7.x86_64 root=/dev/mapper/centos_centos--15388761-root ro crashkernel=auto rd.lvm.lv=centos_centos-15388761/root rd.lvm.lv=centos_centos-15388761/swap rhgb quiet LANG=en_US.UTF-8 ds=nocloud-net [13:41] does it need quotes? [13:43] I'm not sure, I'm afraid. [13:43] But I would try backslash-escaping the semicolon, perhaps? [13:52] blackboxsw: that pastebin from yesterday for lxd VMs on xenial, where does "/var/lib/cloud/scripts/per-once/setup-lxc.sh" come from? [14:09] `grubby --update-kernel=ALL --args='ds=nocloud-net\\;s=http://hyperv01:5000'` so it needed double-escaped [14:14] compufreak: And you're seeing it work now? [14:17] it was also missing a trailing / on the url. It's sort of working--it pulls meta-data and user-data. I think I have a problem with my user data tho, ha [14:27] Ah yeah, I've seen people being caught out by the trailing / thing before; it's there to enable e.g. s=http://example.com/my- to fetch http://example.com/my-metadata and .../my-user-data. [14:32] yup, last problem was powershell defaults to utf-16le but my python meta-data server was reading as utf-8... [15:25] falcojr: ahh that is the write_files b64 content in #cloud-config in the vm profile - path: /var/lib/cloud/scripts/per-once/setup-lxc.sh [15:26] falcojr: so that decoded script is this: https://paste.ubuntu.com/p/fgTpfhC2Sf/ [15:27] I just ran it through "base64 myscript.sh" and dropped that into content of the user.vendor-data config provided [15:28] so the lxc profile provides the user.vendor-data #cloud-config lines 6-22 https://paste.ubuntu.com/p/pxtbd4fjph/ , which still sort of allows us to provide normal user-data cloud-config if we want (though user-data would override the write_files content or power_state [15:29] rharper: per "To start it now, unmount this filesystem and run: systemctl start lxd-agent-9p lxd-agent" yeah I tried that yesterday without the reboot and systemd blewup and didn't like that for either service directly run [15:29] directly started [15:30] I'll try again today with a fresh cup of coffee and see if I can avoid the costly reboot [15:30] blackboxsw: hrm, I've had two experiences [15:30] first, I skipped the reboot and manually ran them; all was fine; then I adjusted my script to just start these services as it mentions; and it rebooted the instance anhow [15:30] anyhow [15:30] wasn't sure if that was the agent's doing or something else. [15:31] though today it looks like I need to resolve some zpool storage issues https://paste.ubuntu.com/p/vptTmFH9Zf/ [15:31] rharper: I think I saw that automatic reboot while restarting the service manually as well. [15:32] ok [15:32] I mistakenly thought that it was my cloud-config hit the power_state: mode: reboot [15:32] yeah, I'm testing without that [15:36] blackboxsw: this is what I've ended up with; https://paste.ubuntu.com/p/Rb9qRBq5nN/ [15:50] rharper: and that also reboots the system right? [15:51] yeah [15:51] at least that's what I keep seeing when I run systemctl start lxd-agent-9p lxd-agent [15:51] it's part of the agent I think [15:51] ok yeah [15:51] wfm [15:51] =( [15:51] yeah costly [15:51] I mean for other systems sure; for cloud-init it;s annoying to see the two boots; [15:52] though rharper were you testing on bionic [15:52] we don't have to use the the agent though; instead you can query lxd for the IP; [15:52] or xenial. my xenial agent hasn't come back up [15:52] blackboxsw: yeah, the focal image has the agent in it [15:52] bionic that works fine, I can test on xenial [15:52] yeah I think I still run into the issue on xenial with that approach. but adjusting my profile [15:53] once cloud-init SRU actually publishes, we can use jinja template in the vm profile [15:53] and only add the vendor data on bionic/xenial [15:53] oh, right, needs to be vendor data [15:53] * rharper fixes local profile [15:54] blackboxsw: what's the lxd key for that user.vendor-data ? [15:54] yep [15:54] ok [15:54] rharper: also I think there's a bug to stock lxd --vm [15:54] vendor-data and user-data both default to "#cloud-config\n" [15:54] which causes simple tracebacks [15:54] should be "#cloud-config\n{}\n" [15:55] otherwise cloud-init balks at trying to pop None [15:55] cloud-init bug I suppose to better handle non case [15:55] None case [15:56] so if you are editing a profile, might as well set user.vendor-data and user-data to "#cloud-init\n{}" to avoid that trace in logs [15:59] blackboxsw: did you file an issue ? [15:59] I've seen that as well [16:00] +1 rharper I'll file it now. [16:01] btw, your script is +1 for me on xenial [16:01] reboot was triggered [16:01] by the lxd-agent service I think. (not a cloud-config setting) [16:01] looks like on xenial the virtio-vsock module isn't present/loaded [16:02] # /run/lxd_config/9p/lxd-agent [16:02] Error: Failed to listen on vsock: listen vsock: open /dev/vsock: no such file or directory [16:14] blackboxsw: yeah, I think the agent on stock Xenial is not going to happen until vhost_vsock module is built for 4.4 ... if you wanted to follow up with the kernel team; they could confirm whether or not they can have virtio_vsock enabled for 4.4 (it's likely not going to be backported) ... [16:17] blackboxsw: https://github.com/canonical/cloud-init/pull/460 <-- oops, missed a test case in my Travis testing, so we need to revert part of my previous change [16:21] rharper: https://github.com/lxc/lxd/issues/7587 [16:27] merged Odd_Bloke if something else crops up, we can continue to iterate [16:28] Thanks! [16:33] community-notice: So all manual validation for cloud-init SRU 20.2.45 is complete, we are awaiting an automated 7+ hour test run for cloud-init by our solutionsQA department against various customer OpenStack datasource configurations. That run looks like it expected to complete early next week. We are in the sit and wait part of the SRU verification [16:34] a great many thanks all those who participated so far in SRU verification for cloud-init [16:34] will update and publish as soon as we see a green light from solutionsQA [16:35] expectation is probably Mon/Tuesday. [16:35] ... and upstream has a policy of not releasing on Fridays anyway [16:38] blackboxsw: thanks [16:38] I suspect stgraber has closed it already =P [16:38] heh [16:38] it's good bug mgmt resposiveness ;0 [16:39] already assigned ;) [18:08] ahh right rharper I forgot that we need packages: [linux-generic-hwe-16.04] on xenial cloud-config so this is what I'm using on xenial https://paste.ubuntu.com/p/27T6HPmKt6/ [18:08] at least for testing [18:25] blackboxsw: that's not built into the image [18:25] you install and reboot? [18:25] rharper: yeah on xenial only :/ [18:25] boo [18:26] you should file a bug/issue with kernel and cloud-images [18:26] very much and all those kernel pkgs take a long time to install [18:26] yes will do [18:26] for lxd at least and see if they can push vhost_Vsock into 4.4 or have something lxd vm specific if they want the agent to work out of the box [18:26] it's really a rotten experience coming from containers [18:27] the sneaky (imho) trick of building their own custom cloud images on images:ubuntu/$release/cloud isn't great; now one doesn't know why the former works but ubuntu:$release does not. [18:28] "out of the box" is a bit of a stretch too, given the profiles we need to setup for vms [18:32] we could suggest that lxd update to have a default vm profile with reasonable things enabled ... [18:54] rharper: I'm going to startup conversation in lxc-dev and see where it goes [18:55] k