[00:02] <powersj> ananke, https://github.com/hashicorp/packer/issues/2639
[00:02] <powersj> workaround in the last comment
[00:03] <ananke> powersj: indeed, that's exactly what I found earlier today and used in my implementation
[00:03] <powersj> there's also this one https://www.packer.io/docs/other/debugging.html#issues-installing-ubuntu-packages
[00:03] <ananke> not as clean as I'd like, but it does give one ability to set a timeout if things go south
[00:06] <ananke> my eventual goal is to use gitlab CI to kick off an EC2 instance, deploy packer on it with cloud-init, then use packer and cloud-init to build an AMI based on a vanilla one + our add-ons
[00:33] <ananke> so I'm trying to debug why a very basic set of runcmd directives do not appear to be working. I've gone as far as cleaning out everything from a basic user data and using the example section from https://cloudinit.readthedocs.io/en/latest/topics/examples.html
[00:34] <ananke> cloud-init analyze show indicates that it should have been executed: |`->config-runcmd ran successfully @17.71300s +00.00100s
[00:34] <ananke> yet the log file shows this: cloud-init.log:2020-01-07 00:27:04,770 - cc_runcmd.py[DEBUG]: Skipping module named runcmd, no 'runcmd' key in configuration
[00:38] <powersj> ananke, common thing to do is to validate your YAML to ensure the syntax is good
[00:59] <ananke> sorry, had to deal with a small emergency
[01:01] <ananke> powersj: YAML seems to be correct. multipass accepts it, and the running instance has said YAML in /var/lib/cloud/instances/test/user-data.txt
[01:03] <ananke> http://dpaste.com/28XMSTQ shows the input YAML and the resulting YAML
[01:05] <ananke> I also tried running it explicitly such as:
[01:05] <ananke> $ sudo cloud-init single --name runcmd --frequency always
[01:06] <ananke> the CLI output appears without any issues: Cloud-init v. 19.3-41-gc4735dd3-0ubuntu1~18.04.1 running 'single' at Tue, 07 Jan 2020 01:04:43 +0000. Up 2283.14 seconds.
[01:06] <ananke> but the log still has: 2020-01-07 01:04:43,096 - cc_runcmd.py[DEBUG]: Skipping module named runcmd, no 'runcmd' key in configuration
[01:07] <ananke> this is output of tail -f in /var/log after said execution: http://dpaste.com/2H1NDZN
[13:04] <ananke> powersj: well, color me surprised. after testing the yaml with cloud-init devel schema I learned that the YAML was actually broken. seems double quotes were removed from one of the runcmd items, which meant the http:// URL was breaking YAML
[13:05] <ananke> now the question is, what removed said quotes. cloud-init or multipass. seems they were removed on one line, but not on another, wtf
[14:02] <ananke> so it appears to be due to yaml-cpp used by multipass, https://github.com/canonical/multipass/issues/1097
[14:16] <Odd_Bloke> Huh, weird.
[14:16] <Odd_Bloke> Let me go and chat to the multipass folks and see if we can (in the long-term) improve that.
[14:36] <meena> Odd_Bloke: hello, good morning
[15:31] <Odd_Bloke> o/
[15:47] <ananke> k, I think I've given up. there seems to be no way to quote things with multipass for runcmd to function correctly. semi-related, I am surprised that cloud-init doesn't have a 'fetch file from url' module
[15:47] <Odd_Bloke> You can do includes, let me find the docs.
[15:48] <Odd_Bloke> ananke: https://cloudinit.readthedocs.io/en/latest/topics/format.html#include-file
[15:49] <ananke> Odd_Bloke: that appears to be only for fetching its own configs, not some random data
[15:49] <Odd_Bloke> Oh, in that case I don't think I understand what you're looking for, could you expand?
[15:51] <ananke> yes, I'm trying to fetch a binary from URL, since it's not available in repos as a package. my hope was to use wget/curl, but that's mangled with the existing multipass problems
[15:54] <blackboxsw> ananke: some more complex runcmd examples (could use sh -xc "something" ) or single quote around the outside of the curl etc https://cloudinit.readthedocs.io/en/latest/topics/examples.html#run-commands-on-first-boot and https://www.digitalocean.com/community/questions/help-with-cloud-init-syntax-for-runcmd
[15:55] <ananke> blackboxsw: doesn't work, because yaml-cpp used by multipass mangles that. see https://github.com/canonical/multipass/issues/1097
[15:57] <ananke> it's a bit ironic, considering cloud-init's documentation recommends multipass as means for validating YAML :) things were going too well for me with multipass & cloud-init, figures I'd have to run into something eventually
[16:16] <roberto-sanchez> Hello guys, got a question, I'll try to make it short: can I format and mount an N number of EBS raw volumes (may be 1, may be 20, externally defined) with cloud-init? As in: it would need to check for unforrmatted disks (lsblk, fdisk, or parted), and if found, format them with mkfs.ext4 and mount them to /data[N] (/data01, /data02 and so on). If
[16:16] <roberto-sanchez> someone reads this and can help me, thank you.
[16:16] <roberto-sanchez> I know I can do this in the final stage, my question was thinking of the fs_setup and disk_setup modules.
[16:17] <rharper> roberto-sanchez: yes, those are the right modules
[16:17] <roberto-sanchez> but how can I get it to iterate on the unformatted disks? That's what I don't get.
[16:18] <roberto-sanchez> and to dynamically act on the N amount of volumes, so it makes N amount of dirs (data01, data02).
[16:18] <roberto-sanchez> and then to mount them.
[16:20] <rharper> oh I understand, an instance may launch with variable mount of volumes but you want a consistent process
[16:20] <rharper> those modules for now, require direct mapping in the config, it supports some abstraction (ephemeral0, 1, 2) and it will look up the name, but you really want a pattern matching ...
[16:21] <roberto-sanchez> right, sorry for my poor explanation, you got it clearly
[16:22] <Odd_Bloke> ananke: Yeah, it's frustrating!
[16:22] <roberto-sanchez> so this is better resolved by standard bash scripting then, @rharper?
[16:25] <blackboxsw> ananke: hrm nice issue will peek a bit today to see if I can reproduce the issue today
[16:28] <ananke> blackboxsw: you can see some more attempts here: https://paste.ofcode.org/6vQAzp2LncyVRuh98Gf6qq
[16:38] <rharper> roberto-sanchez: likely;  we don't currently have support for a syntax that would pattern match N devices by some attribute; which is the first part.  if you know the number ahead of time, it's possible to generate a cloud-config using disk_setup + fs_setup and mount config to do what you're wanting to do; for now, it's likely more portable to write a program to do it and you can execute it early via bootcmd: or later in boot via run_cmd cloud-config
[16:39] <roberto-sanchez> thank you very much for your help and time rharper, logging off; have a nice day everyone!
[17:01] <meena> Odd_Bloke: have you had any time to look at cloudinit/net?
[17:03] <Odd_Bloke> meena: Not yet, I'm afraid!
[17:27] <usrdev> hey all! curious, is it intended behavior that at reboot that cloud-init would reject/refuse to see particular partitions sizes and resize the boot partition?
[17:30] <blackboxsw> looks like i's that time again. +15 :)
[17:30] <blackboxsw> #startmeeting Cloud-init bi-weekly status
[17:30] <meetingology> Meeting started Tue Jan  7 17:30:28 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:30] <meetingology> Available commands: action commands idea info link nick
[17:30] <blackboxsw> #chair Odd_Bloke
[17:30] <meetingology> Current chairs: Odd_Bloke blackboxsw
[17:30] <blackboxsw> #chair rharper
[17:30] <meetingology> Current chairs: Odd_Bloke blackboxsw rharper
[17:31] <blackboxsw> Welcome to the first cloud-init community status meeting of 2020. cloud-init upstream uses this meeting as a platform for community updates, feature/bug discussions, and an opportunity to get some extra input on current development.
[17:31] <Odd_Bloke> usrdev: I'm not 100% sure from that description, could you file a bug using the link in the topic and attach the output of `cloud-init collect-logs` on an affected instance?
[17:31] <blackboxsw> We generally have this meeting ever 2 weeks (outside of intermittent holidays)... You can always find the next scheduled meeting in the topic of this channel
[17:31] <blackboxsw> Let
[17:31] <blackboxsw> Let
[17:32] <blackboxsw> Let's schedule the next meeting now as well
[17:32] <blackboxsw> Any objections to Jan 21 ?
[17:33] <robjo> Look I'm not late ;)
[17:33] <blackboxsw> ok topic set for next meeting
[17:33] <blackboxsw> nope, just me robjo :) welcome to the party
[17:33] <blackboxsw> as always previous meeting minutes are here.
[17:33] <blackboxsw> #link https://cloud-init.github.io/status-2019-12-10.html#status-2019-12-10
[17:34] <blackboxsw> topics for this round: Feel free to interject/suggest other topics at any time. Our typical format is the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Upcoming Meetings, Office Hours (~30 mins).
[17:34] <robjo> The move to Tuesday creates a conflict for me for the last 15 minutes of the meeting. Generally I don't think that's an issue as we are often done in less than 1 hour, just pointing out that usually I have to leave 15 minutes early
[17:34] <robjo> not today ;)
[17:36] <blackboxsw> +1 robjo. We'll try to keep it snappy :) and if others have conflicts we can certainly touch on shifting the schedule a bit. We generally have a conflict at 1 hr before this meeting, which is the only reason it isn't 1 hr earlier
[17:36] <blackboxsw> #topic Previous Actions
[17:37] <blackboxsw> last round: rharper to confirm https://github.com/canonical/cloud-init/pull/42 can land. COMPLETED
[17:37] <blackboxsw> action2:  upstream core-devs to decide about whether a PR can land if any upstream dev still has 'requested changes'
[17:38] <blackboxsw> Odd_Bloke: started writing up a spec/procedure for PR review and he is currently working on adding a documentation addition PR to http://cloudinit.readthedocs.io that will describe the workflow for a PR to get from proposed -> merged.
[17:39] <blackboxsw> that PR should likely be up this week for review if folks are watching our review queue
[17:39] <blackboxsw> #link https://github.com/cloud-init/cloud-init/pulls
[17:39] <blackboxsw> No other actions from the previous meeting in December.
[17:39] <blackboxsw> #topic Recent Changes
[17:40] <blackboxsw> recent commits that made it into tip: found via git log --since 12-10-2019
[17:41] <blackboxsw> let's see if I get throttled for spam
[17:41] <blackboxsw>     - freebsd: fix create_group() cmd (#146) [Gonéri Le Bouder]
[17:41] <blackboxsw>     - doc: make apt_update example consistent (#154)
[17:41] <blackboxsw>     - doc: add modules page toc with links (#153) (LP: #1852456)
[17:41] <blackboxsw>     - Add support for the amazon variant in cloud.cfg.tmpl (#119)
[17:41] <blackboxsw>       [Frederick Lefebvre]
[17:41] <blackboxsw> heh
[17:41] <blackboxsw>     - freebsd: fix create_group() cmd (#146) [Gonéri Le Bouder]
[17:41] <blackboxsw> 10:41     - doc: make apt_update example consistent (#154)
[17:41] <blackboxsw> 10:41     - doc: add modules page toc with links (#153) (LP: #1852456)
[17:41] <blackboxsw> 10:41     - Add support for the amazon variant in cloud.cfg.tmpl (#119)
[17:41] <blackboxsw> 10:41       [Frederick Lefebvre]
[17:41] <blackboxsw> 10:41     - ci: remove Python 2.7 from CI runs (#137)
[17:41] <blackboxsw> 10:41     - modules: drop cc_snap_config config module (#134)
[17:41] <blackboxsw> 10:41     - migrate-lp-user-to-github: ensure Launchpad repo exists (#136)
[17:41] <blackboxsw> 10:41     - docs: add initial troubleshooting to FAQ (#104) [Joshua Powers]
[17:41] <blackboxsw> 10:41     - doc: update cc_set_hostname frequency and descrip (#109)
[17:41] <blackboxsw> 10:41       [Joshua Powers] (LP: #1827021)
[17:41] <blackboxsw>     - ci: emit names of tests run in Travis (#120)
[17:41] <blackboxsw> 10:41     - Release 19.4 (LP: #1856761)
[17:41] <blackboxsw> 10:41     - rbxcloud: fix dsname in RbxCloud [Adam Dobrawy] (LP: #1855196)
[17:41] <blackboxsw> 10:41     - tests: Add tests for value of dsname in datasources [Adam Dobrawy]
[17:41] <blackboxsw> 10:41     - apport: Add RbxCloud ds [Adam Dobrawy]
[17:41] <blackboxsw> 10:41     - docs: Updating index of datasources [Adam Dobrawy]
[17:41] <blackboxsw> 10:41     - docs: Fix anchor of datasource_rbx [Adam Dobrawy]
[17:41] <blackboxsw> 10:41     - settings: Add RbxCloud [Adam Dobrawy]
[17:41] <blackboxsw> 10:41     - doc: specify _ over - in cloud config modules
[17:41] <blackboxsw> 10:41       [Joshua Powers] (LP: #1293254)
[17:42] <blackboxsw>    - tools: Detect python to use via env in migrate-lp-user-to-github
[17:42] <blackboxsw>       [Adam Dobrawy]
[17:42] <blackboxsw>     - Partially revert "fix unlocking method on FreeBSD" (#116)
[17:42] <blackboxsw>     - tests: mock uid when running as root (#113)
[17:42] <blackboxsw>       [Joshua Powers] (LP: #1856096)
[17:42] <blackboxsw>     - cloudinit/netinfo: remove unused getgateway (#111)
[17:42] <blackboxsw>     - docs: clear up apt config sections (#107) [Joshua Powers] (LP: #1832823)
[17:42] <blackboxsw>     - doc: add kernel command line option to user data (#105)
[17:42] <blackboxsw>       [Joshua Powers] (LP: #1846524)
[17:42] <blackboxsw>     - config/cloud.cfg.d: update README [Joshua Powers] (LP: #1855006)
[17:42] <blackboxsw>     - azure: avoid re-running cloud-init when instance-id is byte-swapped
[17:42] <blackboxsw>       (#84) [AOhassan]
[17:42] <blackboxsw>     - fix unlocking method on FreeBSD [Igor Galić] (LP: #1854594)
[17:42] <blackboxsw>     - debian: add reference to the manpages [Joshua Powers]
[17:42] <blackboxsw>     - ds_identify: if /sys is not available use dmidecode (#42)
[17:42] <blackboxsw>       [Igor Galić] (LP: #1852442)
[17:42] <blackboxsw>     - docs: add cloud-id manpage [Joshua Powers]
[17:42] <blackboxsw>     - docs: add cloud-init-per manpage [Joshua Powers]
[17:42] <blackboxsw>     - docs: add cloud-init manpage [Joshua Powers]
[17:42] <blackboxsw>     - docs: add additional details to per-instance/once [Joshua Powers]
[17:42] <blackboxsw>     - Merge pull request #96 from fred-lefebvre/master [Joshua Powers]
[17:42] <blackboxsw>     - Update doc-requirements.txt [Joshua Powers]
[17:42] <blackboxsw>     - doc-requirements: add missing dep [Joshua Powers]
[17:42] <blackboxsw> Ok that should do it.
[17:42] <blackboxsw> maybe best to just pastebin next time
[17:43] <robjo> yup
[17:43] <blackboxsw> lots of doc changes as you can see. dropping python 2.7 automatic testing
[17:44] <blackboxsw> some additional FreeBSD enablement work landed too (thanks Goneri && meena )
[17:44] <blackboxsw> total changelog since last meeting:
[17:44] <blackboxsw> #link https://paste.ubuntu.com/p/Cwnn3SbmWQ/
[17:44] <blackboxsw> much better
[17:44] <blackboxsw> #topic In-progress Development
[17:45] <blackboxsw> We've dusted off our shoes and will get back into using our Trello board more frequently for the immediate updates for what we are currently working.
[17:45] <blackboxsw> New Year's resolution and all
[17:45] <blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
[17:46] <blackboxsw> expect to see more cloud-init cards migrating through the lanes of the board. Expectation as well is that we'll drop the backlog and ideas lanes and keep the board a simple kanban of what is in progress, review and done
[17:47] <blackboxsw> Also note I'm going to drop the community charter lane and create bugs for each item, tagging them 'bitesize' so that quick drivebys of developers that want to contribute can search bugs for those straightforward tasks
[17:47] <blackboxsw> that said, some high level goals upstream is working:
[17:48] <blackboxsw> - cloud-init one-shot daemon work
[17:48] <blackboxsw> - cloud-init network hotplug handling
[17:48] <blackboxsw>  - boot performance  improvements
[17:49] <blackboxsw> - github automation and tooling improvements for expedited reviews and process
[17:50] <blackboxsw> I think that plus reviewing the PR active review queues will keep folks busy for the next 2 weeks :)
[17:51] <blackboxsw> we will likely be adding a cloud-init SRU into xenial, bionic, disco, eoan into the mix as well
[17:51] <blackboxsw> #topic Community Charter
[17:52] <blackboxsw> So generally I'd be pointing to the trello lane "Community low hanging fruit" but I hope to convert those cards to bugs today. So let's say community ongoing efforts fall into two camps"
[17:53] <blackboxsw> 1. add json schema validation to missing cloudinit/config/cc_*py modules.  ( I think there are about 45 remaining modules that need json schema for syntax validation)
[17:53] <blackboxsw> 2. doc scrub and update for datasources in read the docs
[17:54] <blackboxsw> All of these items can easily be worked in parallel, which is why they are a good set of tasks for the greater community
[17:55] <blackboxsw> Expect to find them by searching cloud-init bugs for bitesize tag
[17:55] <robjo> With bugs remaining in launchpad, would it be a good idea to have things like the schema validation not as bugs but issues in GitHub?
[17:55] <robjo> that would make them more visible IMHO
[17:55] <robjo> and those are not really bugs nor is it pressing
[17:56] <blackboxsw> #link https://bugs.launchpad.net/cloud-init/?field.tag=bitesize
[17:57] <blackboxsw> robjo: good suggestion.  I think we were trying to avoid the confusion of having two places for bugs (launchpad bugs and github issues) That is a good point though, and maybe it's worth a mailing list discussion to get others to weight in.
[17:58] <Odd_Bloke> I would be -1 on enabling issues, we would spend our entire lives telling people to report in Launchpad instead.
[17:59] <Odd_Bloke> I totally understand wanting to separate "bugs" and "development tasks", though.
[18:00] <Odd_Bloke> But I don't think we have a _great_ way of doing that which doesn't end up with a confusing experience for bug reporters.
[18:00] <robjo> True that people will equate issues in GitHub with bugs and thus file problems there rather than launchpad, it's a two edged sword
[18:00] <blackboxsw> right, I think designation is there. We could also add a link to community charter bugs to the top-level README.md for the github project. Just so there is a close breadcrumb in github to get to those items
[18:01] <Odd_Bloke> Our plan is to assess how this is working in a month or two, so if it's not working well then we can figure something else out.
[18:01] <blackboxsw> I think the designation of "community development tasks" is there by using bitesize tag or some equivalent
[18:02] <blackboxsw> #ACTION bbsw seed initial community charter bitesize bugs
[18:02] <meetingology> ACTION: bbsw seed initial community charter bitesize bugs
[18:02] <blackboxsw> #topic Office Hours (next ~30 mins)
[18:02] <robjo> Well, "community development tasks" is a bit mis-leading, after all the core team should be part of the "community" right?
[18:03] <robjo> So everything is really a  "community development tasks", just that some things are easier than others ;)
[18:03] <blackboxsw> robjo: yes absolutely. right... I've seen some projects use 'goodfirstbug' or something like that  too
[18:04] <blackboxsw> just something to reduce the barrier to involvement for anyone wanting to contribute
[18:05] <blackboxsw> and yes, core team should be accountable to work on some of those community charter tasks when time permits
[18:05] <robjo> Yes, I think it is important to label the "easy" stuff to help people find a place to get started
[18:05] <blackboxsw> so that hopefully next cloud-init summit we can set a charter for something else
[18:06] <robjo> just based on experience there are a lot of people that are sensitive to wording and we don't really want to get into the bikeshedding that comes along with such situations
[18:07] <blackboxsw> for those reading, office hours is a time of open and unstructured discussion. core cloud-init devs will have eyes on the channel to field questions, concerns, feature or bug discussions. Participate at will. In the absence of any ongoing discussions, upstream will groom/review the active review queue @  https://git.io/JeVed |
[18:09] <Odd_Bloke> Honestly losing my mind over this bug: https://bugs.launchpad.net/cloud-init/+bug/1858615
[18:09] <Odd_Bloke> The board reboots if you use dmidecode!
[18:10] <Odd_Bloke> smoser: As you said, that's a regression.  Do you think it follows that the fix should be in cloud-init?
[18:10] <Odd_Bloke> Because I don't know how you deal with something that broken from where we are in the stack. :/
[18:10] <Odd_Bloke> (Unless we think this is enough evidence that we can't reliably use dmidecode on aarch64, then I guess it is on us to stop doing that. :( )
[18:10] <robjo> This was probably in the e-mail by rharper I have not yet read, but I'll ask anyway ;)
[18:11] <robjo> I think I had some pending merge proposals in launchpad and patches, did these "magically" make their way into GitHub? DO I need to sort out where hings were?
[18:11] <smoser> i've heard "board reboots if you use dmidecode" before.
[18:12] <smoser> and maybe even cloud-init skipped calling dmidecode on aarch64 to avoid that.
[18:12] <smoser> but that is sheer non-sense
[18:12] <Odd_Bloke> Very glad that boards like this are going to be in the walls of every building in 5 years. ;)
[18:12] <smoser> umm..... fix your hardware ?
[18:13] <blackboxsw> other dmidecode issues on other hardware here too https://bugs.launchpad.net/qemu/+bug/1243287
[18:13] <smoser> its more forgivable because dmidecode is priviledged but i swear that all it does is *read* /dev/mem
[18:16] <blackboxsw> robjo: for your pending merge proposals we'd like to see you propose against github if possible. Looking for a run of ./tools/migrate-lp-user-to-github robjo <your_GITHUB_USERNAME> to get your github user included as a CLA signer
[18:17] <blackboxsw> then we have Conributor License Agreement accountability and can start merging those branches on the github side
[18:17] <robjo> Yesh I haven't migrated to the GitHub repo.... even in 2020 the 24 hour/day limitation remains, darn it ;)
[18:17] <robjo> I'll get at least my migration to GitHub done this week, possibly even this afternoon
[18:18] <blackboxsw> heh, absolutely, and actually I mistyped your migrate cmd:  ./tools/migrate-lp-user-to-github rjschwei <YOUR_GITHUB_USERNAME>
[18:39] <blackboxsw> ok think that about wraps the meeting for today. Happy new year folks! Thanks for dropping in!
[18:39] <blackboxsw> #endmeeting
[18:39] <meetingology> Meeting ended Tue Jan  7 18:39:55 2020 UTC.
[18:39] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-01-07-17.30.moin.txt
[19:43] <meena> smoser: didn't we have an actual dmidecode fix that would be a better candidate for causing this? given how much care we have taken that my code never gets executed on Linux
[19:46] <smoser> meena: yeah, i incorrectly blamed you i think
[19:46] <smoser> b
[19:47] <smoser> but on such a system ds-identify would probably run dmidecode
[19:47] <meena> does that System have /sys/class?
[19:47] <meena> then, no
[19:48] <meena> well, rather: then, no, it shouldn't
[19:50] <meena>         # if `/sys/class/dmi/id` exists, but not the object we're looking for,
[19:50] <meena>         # do *not* fallback to dmidecode!
[19:50] <meena>         return
[19:56] <meena> we should ask the person if that path exists
[20:45] <anarcat> hello!
[20:45] <Odd_Bloke> Hi!
[20:46] <anarcat> i'm trying to figure out if cloud-init is a good fit for improving our install processes here
[20:47] <anarcat> we have an heterogenous environment, with machines distributed across "cloud" (Hetzner) and baremetal hosts, in different locations, usually without local network authority/trust
[20:48] <anarcat> we have a common trunk of commands we run (by hand!!) on each machine when we set it up, and a set of hosting-specific setup procedures, of course
[20:48] <anarcat> i'm thinking the common set might be done better by cloud-init than trying to write my own installer
[20:48] <anarcat> i also looked at FAI, to give you an idea
[20:48] <anarcat> and i'm wondering if I shouldn't just write Ansible stuff instead
[20:49] <Odd_Bloke> How do the bare metal hosts get provisioned?
[20:50] <blackboxsw> Is this fai? https://fai-project.org/
[20:50] <anarcat> blackboxsw: yes
[20:50] <anarcat> Odd_Bloke: blood, sweat and tears
[20:50] <anarcat> it depends.
[20:51] <anarcat> on Hetzner "robot" (bare metal) it's https://help.torproject.org/tsa/howto/new-machine-hetzner-robot/
[20:51] <anarcat> it's horrendous
[20:51] <anarcat> cloud is https://help.torproject.org/tsa/howto/new-machine-hetzner-cloud/
[20:51] <anarcat> and the common trunk is in https://help.torproject.org/tsa/howto/new-machine/
[20:51] <anarcat> my MVP is to replace the common trunk
[20:53] <Odd_Bloke> anarcat: Are you looking to configure Puppet as part of this, or remove Puppet entirely?
[20:53] <anarcat> Odd_Bloke: we keep puppet
[20:54] <blackboxsw> most of your https://help.torproject.org/tsa/howto/new-machine/  look like they could be replaced with existing cloud-config modules (puppet support, hostname setting package installation etc
[20:54] <Odd_Bloke> OK, cool.
[20:54] <Odd_Bloke> I figured, but just in case.
[20:54] <anarcat> blackboxsw: yeah, that's what i gathered as well
[20:54] <anarcat> blackboxsw: how about the partitionning stuff in https://help.torproject.org/tsa/howto/new-machine-hetzner-robot/ ?
[20:54] <anarcat> does cloud-init support LUKS and raid?
[20:54] <anarcat> and lvm? and btrfs and zfs and weirdofs? :)
[20:55] <anarcat> the only compromise i'd be ready to do on puppet would be to run ansible to bootstrap puppet
[20:55] <anarcat> we have too much puppet stuff written to switch away
[20:55] <meena> Odd_Bloke: https://github.com/canonical/cloud-init/pull/143 merge merge merge
[20:55] <Odd_Bloke> Yeah, I totally understand!
[20:56] <blackboxsw> anarcat: some basic disk formatting and config https://cloudinit.readthedocs.io/en/latest/topics/modules.html#disk-setup
[20:56] <Odd_Bloke> meena: done done done
[20:57] <meena> anarcat: if luks had documentation, we could consider supporting it
[20:57] <blackboxsw> With MAAS maas.io the curtin project also handles bare metal disk formatting and provisioning  and hands the configured machine over to cloud-init
[20:57] <blackboxsw> anarcat: ^
[20:57] <Odd_Bloke> MAAS isn't really practical for Hetzner though?
[20:58] <blackboxsw> good pt.
[20:58] <anarcat> blackboxsw: this doesn't seem to say which filesystem types are supported...
[20:59] <anarcat> i must say i find the documentation a bit confusing :/
[20:59] <anarcat> meena: luks is definitely documented... i am not sure what you mean
[20:59] <anarcat> i mean its documentation isn't great either
[20:59] <anarcat> but it's documented
[21:00] <Odd_Bloke> So I don't know specifics of LUKS and raid off the top of my head.
[21:00] <anarcat> maas looks something like FAI that assume you control DHCP and have a PXE server, not our case
[21:00] <anarcat> right
[21:00] <anarcat> cloud-init is, after all, ... er... cloud :p
[21:00] <anarcat> RAID is abstracted away
[21:00] <meena> https://dev.glitch.social/@hirojin/103382178381991566
[21:01] <anarcat> meena: heh
[21:01] <anarcat> meena: then i think you meant "good" documentation :p
[21:01] <blackboxsw> anarcat:  here are a couple of other contextual examples for disk setup filesystem type etc: https://cloudinit.readthedocs.io/en/latest/topics/examples.html#create-partitions-and-filesystems  and  https://cloudinit.readthedocs.io/en/latest/topics/examples.html#create-partitions-and-filesystems
[21:01] <anarcat> most documentation sucks, to be honest :p
[21:01] <meena> anarcat: does that answer your question
[21:01] <Odd_Bloke> But it has fairly decent support for multiple filesystems, and partitioning
[21:02] <anarcat> Odd_Bloke: yeah, i saw those thanks
[21:02] <anarcat> meena: i guess it does
[21:02] <meena> apparently not. go read some openbsd documentation
[21:03] <anarcat> meena: sorry, say again?
[21:03] <anarcat> meena: did you just RTFM me?
[21:03]  * anarcat confused
[21:04] <meena> also, luks vs luks2 feels like a php function bad, use this new php function
[21:04] <meena> anarcat: no, i meant just for comparison
[21:04] <meena> openbsd docs are really good
[21:04] <anarcat> from here on, you can assume i have read other documentation than the cryptsetup manpage
[21:05] <anarcat> meena: actually, i find the FreeBSD docs much better than openbsd :p
[21:05] <anarcat> but i agree openbsd has good docs :)
[21:05] <Odd_Bloke> anarcat: So I think cloud-init can do a chunk of what you want natively.
[21:05] <anarcat> Odd_Bloke: right :)
[21:05] <anarcat> it doesn't seem reasonable to expect it to do funky disk partitionning though
[21:05] <Odd_Bloke> And when it comes down to it, you can pass shell scripts as additional configuration.
[21:05] <anarcat> right
[21:06] <Odd_Bloke> So hopefully it lets you structure some of the stuff, and only have to have scripting for the Complicated Bits.
[21:06] <anarcat> maybe i could reuse FAI's setup-storage thing to do my funky stuff
[21:06] <anarcat> i created those monstrosities already https://gitweb.torproject.org/admin/tsa-misc.git/tree/installer
[21:06] <anarcat> so maybe those could be hooked up
[21:07] <meena> anarcat: yeah, like, you can read man make in freebsd top to bottom and actually understand it, and you can read gnu's make manual, and not understand anything
[21:07] <anarcat> bsd make is simpler than gnu make, though
[21:07] <anarcat> but yeah, the info system might have been a mistake
[21:08] <Odd_Bloke> Oh, I just recite the four software freedoms three times while thinking about a GNU make option, and the help text for it just enters my head.
[21:09] <anarcat> Odd_Bloke: that's surprisingly disturbing
[21:09] <Odd_Bloke> Is that not how it works for everyone else?
[21:09] <anarcat> no
[21:09] <anarcat> i start by using make
[21:09] <anarcat> then end up writing a shell script in make
[21:09] <anarcat> then realize what the fuck am i doing
[21:09] <anarcat> and rewrite it in python
[21:09] <meena> i have never once successfully read anything in info
[21:09] <Odd_Bloke> i always yell about variable assignment for a while
[21:09] <anarcat> god that's insane
[21:09] <Odd_Bloke> definitely some pacing up and down
[21:10] <anarcat> oh, i have another actual question :)
[21:10] <anarcat> so it seems cloud-init is designed to be automatically hooked up in cloud images
[21:11] <meena> i used to use make before i knew puppet, cuz it's idempotent!
[21:11] <anarcat> so it's kind of pre-installed or something... e.g. on the youtube video in the frontpage, you just copy-paste the config in a text field when you create an amazon instance
[21:11] <Odd_Bloke> Yep, that's how it's expected to be installed.
[21:11] <anarcat> but i'm a weirdo that hate clouds and love the sun
[21:11] <anarcat> so i'm bare bones
[21:11] <anarcat> if i'm lucky, i have a decent debian install to start from
[21:11] <anarcat> how does that work from there?
[21:11] <anarcat> apt install cloud-init?
[21:11] <anarcat> then call cloud-init do-magic?
[21:13] <Odd_Bloke> That's a good question.  We would _generally_ expect cloud-init to be included in the image mastering (or customisation) process, and cloud-init is generally invoked by systemd units in a few phases.
[21:13] <Odd_Bloke> I'm not 100% sure what happens when you install it on a system without it, because there are no such Ubuntu systems and I work on Ubuntu. :p
[21:14] <anarcat> uh!
[21:14] <Odd_Bloke> But I see no reason why it wouldn't work, off the top of my head.
[21:14] <anarcat> so an Ubuntu desktop comes with cloud-init pre-installed?
[21:14] <Odd_Bloke> Oh no, I meant servers, sorry.
[21:14] <blackboxsw> anarcat: ubuntu cloud-images all come with cloud-init installed.
[21:15] <anarcat> how do you pass the config in that context? https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html ?
[21:15] <anarcat> blackboxsw: yeah i figured as much, but i meant more generically
[21:15] <anarcat> assume that i'm building a cloud
[21:15] <anarcat> can cloud-init be used to setup the cloud? :)
[21:15] <anarcat> maybe i'm just picking the wrong hammer here, that would be fine too :)
[21:16] <Odd_Bloke> anarcat: So the NoCloud data source looks for a CD drive/ISO with a particular label attached to the system, and reads data off of it.
[21:16] <meena> what *is* the cloud?
[21:16]  * blackboxsw just tested in a debian stretch (9)  lxc that didn't have cloud-init apt-get install cloud-init (0.7.9 waaay old) worked fine and ran automatically on reboot
[21:16] <anarcat> meena: other people's computers
[21:16] <Odd_Bloke> That data is the stuff that on, for example, EC2 would be fetched from the metadata service.
[21:17] <anarcat> Odd_Bloke: a *CD* drive?
[21:17] <anarcat> like the plastic coasters you put your beer on? :)
[21:17] <Odd_Bloke> A virtual one!
[21:17] <anarcat> yuck!
[21:17] <anarcat> it must be all sticky! ;)
[21:17] <anarcat> okay, got it
[21:17] <Odd_Bloke> :)
[21:17] <anarcat> can i get away with not doing that? :)
[21:17] <Odd_Bloke> Things like hostname, network configuration, and the user-data/custom data that you would type into a box.
[21:17] <anarcat> like fetch over https://i-trust-this-domain-because-i-love-dnssec.com?
[21:18] <Odd_Bloke> That's a good question, I believe you can.
[21:19] <anarcat> is that the "nocloud" data source?
[21:19] <meena> https://github.com/canonical/cloud-init/pull/144 merge merge merge
[21:19] <Odd_Bloke> That would be the nocloud-net data source.
[21:19] <rharper> No cloud also reads from /var/lib/cloud/seed/nocloud-net/{user-data,meta-data,network-config}
[21:19] <rharper> or from any filesystem with the label 'cidata'
[21:22] <Odd_Bloke> anarcat: So if you're going to be installing cloud-init yourself, you could consider having a simple script which populates /var/lib/cloud/seed/nocloud-net/... from https://its-not-paranoia-if-theyre-really-out-to-get.you/ before cloud-init runs.
[21:23] <blackboxsw> robjo: https://github.com/canonical/cloud-init/pull/158 will land when CI passes thanks
[21:23] <Odd_Bloke> Or you could write the appropriate configuration to /etc/cloud/cloud.cfg.d/... to point at your server.
[21:24] <anarcat> i see
[21:24] <anarcat> you can hook datasources in /etc/cloud?
[21:25] <blackboxsw> anarcat: datasources can be set with something like this:
[21:25] <blackboxsw> root@dev-x:~# cat /etc/cloud/cloud.cfg.d/90_dpkg.cfg
[21:25] <blackboxsw> # to update this file, run dpkg-reconfigure cloud-init
[21:25] <blackboxsw> datasource_list: [ ConfigDrive, NoCloud, OpenNebula, DigitalOcean, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, SmartOS, Bigstep, Scaleway, AliYun, Ec2, CloudStack, Exoscale, None ]
[21:25] <Odd_Bloke> anarcat: Yeah, so you would just hard-code the specific datasource you want, and the config to kick it off.
[21:25] <blackboxsw> if your image provides just one datasource type in the list, cloud-init will default to use that datasource. otherwise ds-identify script will try detecting the datasource
[21:26] <Odd_Bloke> That long list is intended for images which will run across multiple platforms; cloud-init performs local-only discovery to find which of those data sources are applicable, and then uses that one.
[21:27] <anarcat> okay
[21:27] <anarcat> i don't quite understand the details, but it seems i'll be able to do the magic i need
[21:27] <anarcat> do i need to reboot for cloud-init to do its stuff, or can i run it interactively?
[21:28] <Odd_Bloke> I expect you can run it interactively (and depending on what the units do on installation, may have to do something to stop it happening :p), but a reboot might give you a more consistent experience with other cloud-init users.
[21:30] <blackboxsw> anarcat: right and you can optionally provide other specific datasource config params with a /etc/cloud/cloud.cfg.d file that looks like  https://paste.ubuntu.com/p/kD4SgnMm7J/
[21:31] <blackboxsw> I *think* though I haven't played with overriding NoCloud config in a while.(just looked over the ds_cfg reading in cloudinit/sources/DataSourceNoCloud.py
[21:33] <blackboxsw> and yes you *could* run it directly without reboot during development with sudo cloud-init init --local; cloud-init init; sudo cloud-init modules --mode=config; sudo cloud-init modules --mode=final;
[21:34] <anarcat> how do you remember all that stuff :)
[21:34] <anarcat> thanks!
[21:34] <blackboxsw> it's what the systemd units/jobs do for each cloud-init boot stage per https://cloudinit.readthedocs.io/en/latest/topics/boot.html
[21:34] <blackboxsw> anarcat: I don't remember it. I fgrep -r cloud-init /lib/systemd/ | grep Exec
[21:35] <blackboxsw> that told me the individual cloud-init commands that are run by systemd during boot :)
[21:35] <blackboxsw> fgrep -ir to save swap space in my head
[21:35] <anarcat> aweome
[21:35] <anarcat> you guys rock
[21:37] <Odd_Bloke> rharper: I'd be interested to hear your thoughts on the LUKS/RAID storage configuration anarcat discussed above.
[21:37] <blackboxsw> btw anarcat if you are creating your own debian image, I'd recommend building/getting a more recent version of cloud-init than 0.7.9 it's about 4 years old.
[21:38] <blackboxsw> ubuntu 16.04 (Xenial) and later is currently running cloud-inig 19.3 (released late in 2019)
[21:39] <anarcat> versions in debian: https://tracker.debian.org/pkg/cloud-init
[21:39] <blackboxsw> buster & bullseye look good
[21:39] <anarcat> blackboxsw: yeah, don't worry, we're on stable and up for new machines, so 18.3 at least
[21:39] <blackboxsw> +1
[21:39] <anarcat> i'm trying to avoid building images, because i don't always control the initial setup
[21:39] <anarcat> i am trying to avoid building an installer
[21:39] <anarcat> building images mean writing an installer
[21:40] <anarcat> building an image is like installing debian
[21:40] <anarcat> i wish we would just converge
[21:41] <rharper> Odd_Bloke: right, anarcat : there is limited support in cloud-init for filesystem creation and partitioning;  for advanced storage; I would point toward  curtin, https://curtin.readthedocs.io/en/latest/index.html ; which has extensive support for creating customizing storage, include, bcache, raids, luks, zfs, filesystems, lvm, etc;
[21:42] <anarcat> curtin, intersting thanks
[21:43] <anarcat> not in debian though
[21:43] <rharper> it's an installer, and under the MAAS product, it runs curtin from cloud-init to install ubuntu or other OSes to physical (or virtual) systems;  its all command line based, so it can be incorporated into whatever workflow you have;  it's ubuntu centric, so on the debian path, there are some known issues where it doesn't quite match debian (like kernel package names and othee defaults)
[21:44] <rharper> no
[21:46] <anarcat> so MAAS does the basic PXE bootstrap, then calls cloud-init which calls curt?
[21:46] <blackboxsw> MAAS does PXE bootstrap to call curtin which pre-provisions, then calls cloud-init
[21:48] <anarcat> oic
[21:55] <rharper> blackboxsw: not quite, PXE boot into a live image, which runs cloud-init, pulling cloud-config from MAAS, which invokes curtin with config provided by maas;
[21:57] <rharper> MAAS boots the cloud image ephemerally; and uses that environment to run curtin to deploy any target OS to the platform, curtin customizes the storage layout, unpacks the payload, then runs a "post-install" we call curthooks to enable additional packages, configurations, bootloader etc;
[21:58] <anarcat> such a mess
[22:00] <rharper> bare metal provisioning is overkill for customizing images; for sure.
[22:01] <rharper> that said, re-using curtin to customize storage may be helpful depending on how much you want to do youself vs generating config for curtin to consume;
[22:08] <meena> can we get cloud-init or something else sensible, like pxe for installing android phones?
[22:11] <blackboxsw> harper: doesn't curtin's post-install step pass reporting #cloud-config to properly configure the node to talk to maas etc. Or is that earlier?
[22:12]  * blackboxsw was thinkimg curthooks: handle_cloudconfig function
[22:13] <blackboxsw> but maybe that is only for during ephemeral provisioning  process as you stated
[22:15] <rharper> blackboxsw: right, so we configure the baremetal target machine to use cloud-init as well, it will contact maas for further configuration; this first boot on baremetal is just like a cloud instance; first time booting, finds  a datasource, fetches config etc
[22:15] <rharper> we emit cloud-config to set the datasource to the MAAS controller with creds to talk to MAAS, etc