[02:30] also rharper, and Odd_Bloke I believe the args passed into the handle function is also supported via 'cloud-init single --name cc_ssh_import_id --frequency always ubuntu chad.smith' so if we are deprecating use of providing 'args' directly to cloud-init config modules, we would be impacting that CLI call path as well. [02:30] yes just confirmed on a container [04:37] Hey all, im tryingo to set my hostname to the instanceId, and i put this in my config. hostname: {{ v1.instance_id }} however, it says Invalid format at line 4 column 11: "while constructing a mapping in "" any ideas what Im doing wrong? [04:38] https://apaste.info/VwYP [04:39] ^ config and this is the error [04:39] https://apaste.info/Rjxn [10:21] I have a question. Is multi NIC deployment is possible with cloud init. If so which part of code is responsible to make Multi NIC IPs up? [13:44] socket-: You need `## template: jinja` as your first line for the substitution to happen: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data [13:54] Hi. I use runcmd to do a git clone upon init. however, it seems that git is not using the private SSH key (placed in ~/.ssh/id_rsa), because when I log into the consle (TTY) and run the command, everything’s fine. Is there a “proper way” to run a git pull with cloud-init ? [13:55] ah - I get “Host verification failed” during cloud-init. [14:02] sackrebutz: cloud-init runcmd runs as root, so you'll need to specify a path to the key [14:02] well the key is placed in /root/.ssh/id_rsa [14:03] which I’d expect to be used when root is running `git …` [14:03] I would as well; [14:03] how would i specify the key explicitly? [14:04] man git says, GIT_SSH or GIT_SSH_COMMAND can override the default git ssh command it uses [14:04] if nothing else, you could use ssh -vv to see what's happening [14:05] well it works if I connect through TTY (as root) and execute the git clone. it does not work when i execute that very command through runcmd. [14:06] I have verified that the files are all in place before the git command is executed [14:06] as to the env variables, it looks like they’re not being set , as a runcmd `set > /tmp/set` file shows .. [14:11] I have a question. Is multi NIC deployment is possible with cloud init. If so which part of code is responsible to make Multi NIC IPs up? Second thing is is the route files being cleaned up by cloud init itself? [14:13] Third is: PER_INSTANCE basically means it will run just once even if we reboot or does it mean the file have frequency PER_INSTANCE means it will run on every boot [14:14] sackrebutz: right, we don't pass and env, you can wrap them like sh -c 'SSH_CMD=ssh -vv git clone https:....' [14:15] ah, good hint, I’ll try that! [14:16] amansi26: We don't have support for user-provided network configuration in general. What cloud/data source are you using? [14:16] amansi26: yes, https://cloudinit.readthedocs.io/en/latest/topics/network-config.html, the code for networking is cloudinit.net; you say route files, so that sounds like sysconfig related, and cloud-init does not "clean-up sysconfig files" as good as it should, so re-using the same image in a new instance could have issues; [14:17] amansi26: per-instance means first time image has booted on a particular platform; subsequent reboot of the same image will not re-run certain parts of cloud-init; especially for network configuration, this depends on the platform, on Azure for example, network configuration is rendered on every boot, not just the first time; [14:19] sackrebutz: https://stackoverflow.com/questions/4565700/how-to-specify-the-private-ssh-key-to-use-when-executing-shell-command-on-git [14:19] this looks relevant [14:20] so the issue I see is the ip was not coming up initially to I made a custom module and wrote code to make IP up and set frequency=PER_INSTANCE. but I see my module running evertime I reboot [14:23] amansi26: look in your cloud-init.log, you should see 'Calling handler ... with frequency [14:34] @rharper the solution was to do `ssh-keyscan github.com >> /root/.ssh/known_hosts` [14:35] issue was bcs of HOST key not PRIVATE key - my bad. [14:35] sackrebutz: nice! [14:36] TIL ssh-keyscan [14:36] me too :-D [14:36] hehe [14:36] thanks for you support! [14:37] sure! [14:43] sackrebutz: As an aside, you might want to consider specifying the exact key you want in .ssh/known_hosts (using write_files). Fetching the key at runtime means that an attacker could claim to be github.com without you realising, whereas specifying the key means that your git clones would fail in such an attack. [14:43] (A caveat: I don't know how often GH rotate their host keys, so there may be an unwelcome maintenance burden there.) [14:45] Odd_Bloke: Thanks - I guess I take that risk as I don’t plan to deploy often, too. [15:15] rharper: As you mention on Azure for example, network configuration is rendered on every boot, not just the first time; is this the only case with Azure or with all other distros [15:17] Second thing is once the vopt get removed, the n/w conf will set to dhcp (as designed) . so is there a way where we can make sure the n/w conf set only once(apart from network: disabled) [15:30] amansi26: unrelated to the distro, property of the Datasource, DataSourceAzure.py configures this. [15:30] I am using ConfigDrive as Datasource [15:30] amansi26: I don't understand 'vopt get removed' [15:31] ConfigDrive does not render every boot; the default for datasources is once per instance; Azure, EC2 (classic), SmartOS, and maybe one more Scaleway i think, are per-boot ... [15:32] So what I mean is if the datasource is set to None and the system is rebooted , DHCP n/w will get configured right? === blackboxsw changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting May 5 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug [15:35] if you don't have a datasource, cloud-init won't run [15:35] if you're previously booted the default network config is to DHCP on one of the interfaces; that config will still be present on new boots; [15:51] so is there a way where we can make sure the n/w conf set only once(apart from network: disabled) [16:06] for configdrive, it's only once [16:07] but generally we don't have a way to say, please generate network-config once and only once no matter what [19:27] blackboxsw: So I've reviewed the process doc parts of https://github.com/canonical/uss-tableflip/pull/45, and I've just approved https://github.com/canonical/cloud-init/pull/312. I'm going to go ahead and push your branch to ubuntu/daily/devel to save you from doing it as you're doing release work currently. [19:28] thanks Odd_Bloke please do. I've got the 20.2 release branch up for review rharper Odd_Bloke https://github.com/canonical/cloud-init/pull/337 [19:29] I'm currently curating the 'hightlights for 20.1 -> 20.2' [19:30] Odd_Bloke: nice! [19:30] blackboxsw: excellent [19:37] Cool, merged, synced to Launchpad and daily build kicked off. [19:37] Bit of a backlog for builds, so it'll be a few before we can confirm it's fixed. [19:40] good deal [19:47] SRU process bug created with 20.2 upstream release highlights https://bugs.launchpad.net/cloud-init/+bug/1875951 [19:47] Ubuntu bug 1875951 in cloud-init "Release 20.2" [Undecided,New] [21:09] Odd_Bloke: or rharper if either of you can review the 20.2 upstream release, I can send out email and discourse post about it [21:09] https://github.com/canonical/cloud-init/pull/337 [21:10] and I can close out bugs, we can have any post-release bug management/milestone discussions separately if we need to tweak the process a bit [21:34] blackboxsw: hrm, do you have local changes to tableflip scripts? I used the upstream-release script and my CHangelog is different than yours [21:36] rharper: checking. nope I'm on fresh master of uss-tableflip [21:37] I did have to enter the process bug number 1875951 [21:37] to the prompt [21:37] lemme try again [21:37] but I ran cd /tmp; git clone cloud-init; cd cloud-inoit; upstream-release 20.2 20.1 [21:38] I'll try re-running as well to make sure I didn't do some other stuff. [21:39] blackboxsw: what i"m seeing is all of the cherry-pick/update changelog entries , did you manually redact those ? [21:41] rharper: makes me think you are working from non-master branch when you ran upstream-release [21:42] we need to run that script from master to get the right changelog [21:43] like you were in ubuntu/devel or daily/devel branch when upstream-release was run maybe? [21:44] oh [21:44] yes [21:44] yes i iwas [21:44] thank you [21:46] there we go [21:46] schweet. I'll add that to the script so it warns [21:46] PR for uss-tableflip incoming [21:47] cool [21:54] rharper: https://github.com/canonical/uss-tableflip/pull/46 [21:55] a quick pre-flight check on the branch we have checked out [21:55] k [21:57] s/ upstream-snapshot/upstream-release/ on the commit message and PR [21:57] done and force-pushed [21:57] blackboxsw: can we get some comments added to the upstream_release doc mentioning that ubuntu/devel and release branches are going to produce incorrect output... [21:58] rharper: +1 will add that to the PR. and will also move the git pull outside of the if "master" check (as we always want to make sure master is at latest [22:05] blackboxsw: +1 [22:14] blackboxsw: looks good [22:14] thanks rharper [22:14] done pushing to uss-tableflip PR as well [22:15] thanks [22:15] * blackboxsw needs to setup my gorilla sbuild enbv [22:15] env [22:39] Another one for tomorrow for releasing 20.2 to gorilla https://github.com/canonical/cloud-init/pull/339