[00:38] <dngray[m]1> does anyone have an example of passing in a directory with 9p like a home directory?
[00:38] <dngray[m]1> for some reason i can't find one anywhere
[00:40] <dngray[m]1> maybe these have to be defined in my virsh xml file instead.
[02:09] <dngray[m]1> https://pcocc.readthedocs.io/en/latest/manpages/man7/9pmount-tutorial.html
[02:10] <dngray[m]1> i'm confused, it looks like you can specify 9p mounts
[02:10] <dngray[m]1> though i didn't see it mentioned on https://cloudinit.readthedocs.io/en/latest/topics/modules.html#mounts
[02:11] <dngray[m]1> sudo mount -t 9p works
[04:01] <Gurjeet> Hi @all,
[04:02] <Gurjeet> Hi @all, I am trying to run a shell script using cloud-init, but unable to do so for an offline system
[04:03] <Gurjeet> Will you please help me in this, thanks in advance.
[06:26] <Gurjeet> Hi all,
[06:27] <Gurjeet> I am trying to run a shell script using cloud-config for modifying a ubuntu-iso, but that is not working for me. Will you please help me in this
[06:28] <Gurjeet> d
[13:52] <minimal> could PRs #1081, #1082, and #1083 be considered for the 21.4 release? they are each minor changes
[13:53] <minimal> hmm, the ubottu bot doesn't map references to cloud-init PRs
[14:18] <falcojr> minimal: I'll try to get them in this week, though I'll probably have some questions on the PRs themselves
[14:20] <minimal> falcojr: no panic, if they don't make the release its not the end of the world :-) I've submitted these simple ones to reduce any potential impact on the release, I'll keep more complicated PRs until after the release
[14:23] <dngray[m]1> hey, so i'm trying to pass in a home directory from my host
[14:23] <dngray[m]1> is 9p the right thing to do that? I'm using kvm/libvirtd
[14:24] <dngray[m]1> i'm using a filesystem declaration like so https://clbin.com/tiuJ6
[14:25] <dngray[m]1> this goes in my file so when i do "virsh -c qemu:///system define vm.xml" it is available
[14:25] <minimal> dngray: that's not really a cloud-init question though? more a libvirtd one
[14:26] <dngray[m]1> i've got a fairly simple cloud-init
[14:26] <dngray[m]1> https://clbin.com/Zm4EU
[14:27] <dngray[m]1> if i type "mount -t 9p dngray /home/dngray/somefolder" it does mount, so 9p is working
[14:27] <dngray[m]1> but i am actually just passing wanting to pass the home directories in
[14:28] <dngray[m]1> i figured "no_create_home" would be appropriate, as i don't want to create a homedirectory
[14:28] <dngray[m]1> well it is i'm trying to get cloud init to mount it on boot
[14:29] <dngray[m]1> what i am saying is i've verified it works when defining/mounting manually, but that's not really what i want, i want to pass in my home directory
[14:29] <dngray[m]1> so t hat when i spool up a new vm, my home directory is always the same
[14:29] <minimal> dngray: this is alpine, right?
[14:29] <dngray[m]1> the line that seems to be not working is
[14:29] <dngray[m]1> mounts:
[14:29] <dngray[m]1>   - [ dngray, /home/dngray, 9p, 'trans=virtio,version=9p2000.L,msize=262144,nofail', '0', '0']
[14:30] <cpaelzer> dngray[m]1: if you can use modern host consider using virtiofsd instead of 9p
[14:30] <dngray[m]1> i can't find much documentation, on someone using 9p to mount their home directory inside a vm created with cloud-init
[14:31] <minimal> dngray[m]1: this is an Alpine VM, right?
[14:31] <cpaelzer> https://virtio-fs.gitlab.io/ + https://libvirt.org/kbase/virtiofs.html if you want to look at virtiofsd
[14:36] <dngray[m]1> minimal: host is alpine, guest is archlinux
[14:37] <dngray[m]1> cpaelzer: oh maybe i shouldn't use 9p then. i just thought that was what i needed.
[14:37] <dngray[m]1> oh i was already doing that i think
[14:38] <dngray[m]1> except i didn't set <driver type='virtiofs'/>
[14:38] <minimal> dngray[m]1: ok, so that probably rules out busybox mount command (on alpine by default busybox provides mount command which has some limitations)
[14:38] <cpaelzer> dngray[m]1: it is quite similar to configure, but if the host is new enough to have all you need for virtiofsd then IMHO it is preferable
[14:39] <dngray[m]1> it certainly should be the host is alpine linux 3.14.2
[14:40] <minimal> dngray[m]1: did you try manually doing "mount -t 9p dngray -o trans=virtio,version=9p2000.L,msize=262144,nofail /home/dngray/somefolder" to verify the full command that cloud-init will try
[14:40] <dngray[m]1> i didn't manually do the whole command no, i just did "mount -t 9p dngray /home/dngray/directory"
[14:40] <dngray[m]1> so maybe that's the issue.
[14:40] <dngray[m]1> i kinda copied that from somewhere else i guess i shouldn't have
[14:41] <dngray[m]1> i'll try to use virtiofsd though if that's newer and preferable
[14:41] <minimal> right, so perhaps the command is not correct in the first place...
[14:41] <dngray[m]1> quite possibly.
[14:42] <minimal> as for your earlier VLAN issue with alpine, I tried to point out to you earlier on IRC that cloud-init specifically depends on ifupdown-ng which has the VLAN support - speaking as the Alpine maintainer for the cloud-init package :-)
[14:43] <dngray[m]1> oh yeah, i fixed that one by installing ifupdown-ng
[14:43] <dngray[m]1> and removing the ifupdown, that actually fixed the issue, and yes cloud-init does depend on ifupdown-ng in alpinelinux
[14:44] <dngray[m]1> when you use ifupdown-ng you don't actually need the old "vlan" package, that has a script that must be included in ifupdown-ng
[14:44] <dngray[m]1> oh yeah, so basically what you said, i figured out haha by trying it
[14:44] <minimal> dngray[m]1: my point was you shouldn't have needed to install ifupdown-ng as cloud-init depends on it already
[14:44] <dngray[m]1> oh yeah for sure, but it was conflicting with the vlan package, so i had to remove that first
[14:46] <minimal> I'm guessing perhaps you had upgraded prior to then and maybe didn't do an "apk -a upgrade" to have an up-to-date deps list
[14:47] <dngray[m]1> maybe.
[14:47] <minimal> dngray[m]1: one last thing, if you are intending to build cloud-init enabled Alpine images you might be interested in my script for this: https://github.com/dermotbradley/create-alpine-disk-image
[14:48] <dngray[m]1> i'll take a look, because i might in the future
[14:48] <dngray[m]1> i certainly do like alpine linux, but sometimes i want to use arch
[14:48] <dngray[m]1> mostly when im so lazy i want rolling release lol
[14:49] <minimal> I'm welcome to any feedback to improve cloud-init on Alpine
[14:52] <minimal> falcojr: I just had a failure in Travis CI for PR #1084 and it doesn't look like its anything to do with my PR.
[14:53] <minimal> falcojr: seems to be a Sphinx issue
[15:05] <mNantern> Hello 👋. I'm not sure that I'm in the right place but I have a question about cloud-init.
[15:07] <mNantern> I want to update my hostname on EC2 (to the instance_id) by using jinja templating. It works well when I pass the template as a `user_data` but not at all when set as a file in `/etc/cloud/cloud.cfg.d/15_hostname.cfg`. I'm on Debian 10 Buster with cloud-init version 20.2
[15:08] <blackboxsw> mNantern: 20.2 should have jinja template support. Do you have example raw user_data (be careful if you have passwds in it)
[15:08] <blackboxsw> BTW: this is the right place
[15:09] <mNantern> Thanks :pra
[15:09] <mNantern> The file: https://pastebin.com/25G4diBa
[15:10] <blackboxsw> mNantern: you can see the user-data that cloud-init sees on the vm with: `sudo cloud-init query userdata`
[15:11] <blackboxsw> ahh sorry, backing up, you tried provided that ## template: jinja in the file named `/etc/cloud/cloud.cfg.d/15_hostname.cfg ?
[15:11] <mNantern> Yes ! I shouldn't have?
[15:13] <blackboxsw> normally jinja template renderers are applied to user-data block which is provided to the system at launch time. I think it doesn't apply during rendering of the consolidated system config which is on disk in /etc/cloud/cloud.cfg and /etc/cloud/cloud.cfg.d/*.     I'm double checking that now though. I believe this is a desirable feature for cloud-init, but I think it isn't currently implemented. Again, I need to double check that now 
[15:13] <blackboxsw> to confirm
[15:15] <mNantern> Thanks! According to the doc (https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data) it should have worked, no? "Both user-data scripts and #cloud-config data support jinja template rendering. When the first line of the provided user-data begins with, ## template: jinja cloud-init will use jinja to render that file. " 
[15:20] <blackboxsw> mNantern: correct, thought I think that needs to be clearer in docs. The files that are delivered in an image on disk are considered merged system config which basically sets opinionated image configuration defaults. `sudo cloud-init query merged_cfg` would show you on your system what the merged config from disk looks like. user-data though is a separate configuration blob that can contain #cloud-config or user-data scripts etc. 
[15:20] <blackboxsw> That user-data is assumed to override any existed merged_cfg config defaults, cloud instance meta-data or cloud instance vendor-data.
[15:21] <blackboxsw> all said, the user-data processing handlers I think are the only ones that are jinja aware.  We could extend the merged config handling from disk to be jinja template aware. but I don't think that is there yet.
[15:23] <mNantern> Alright, thanks for the verification! I will use my config in user_data in this case ! 
[18:12] <falcojr> blackboxsw: another CI dep issue... https://github.com/canonical/cloud-init/pull/1085
[18:23] <minimal> falcojr: I assume you mean https://github.com/canonical/cloud-init/pull/1084
[18:35] <falcojr> minimal: yes, it's a fix for that
[18:47] <minimal> ok, thanks
[19:53] <Xe> does ssh_import_id work with modern cloud_init?
[19:53] <Xe> the examples claim it does but i cannot observe it working
[20:19] <falcojr> Xe: it does. Do you get any errors in your /var/log/cloud-init.log ? How are you specifying it?