[00:25] <catphish> is there a short answer to how to start building a datasource and make it execute?
[00:33] <catphish> ah, it's documented at https://cloudinit.readthedocs.io/en/latest/topics/datasources.html - duh
[00:47] <catphish> though i'm still not very clear about how to get started
[00:53] <catphish> anyway, i'd really appreciate it if anyone could point me in the direction of some very simple instructions on getting started, essentially i just want to place a datasource module somewhere and have it be executed to i can start developing, either by cloning the repo and running it, or by droping my module into a default ubuntu install, whichever is simlpler
[00:55] <catphish> my initial attempt to place a file into cloudinit/sources and running "cloud-init init" do not result in my code running, so i'm clearly missing several steps to load the module and have it be identified as the active datasource
[08:28] <otubo> rharper, yes, RHEL8 is NetworkManager only (sorry for delay, was on PTO)
[09:32] <catphish> good morning sirs, same question as last night, would anyone be able to point me in the direction of getting started developing for cloud-init, specifically i'm looking to create a datasource, but i need some basic pointers about how to run cloud-init from the repo, and how to add a datasource class so that it executes
[09:58] <catphish> hopefully i can use this as a template and try again https://github.com/canonical/cloud-init/commit/e80517ae6aea49c9ab3bd622a33fee44014f485f
[13:28] <Odd_Bloke> catphish: What platform are you creating a datasource for, out of interest?  To test cloud-init as if it's a first boot, you'll want to look at `cloud-init clean`; that will remove all of cloud-init's state.  Also note that the set of datasources cloud-init will consider is generally configured in /etc/cloud/cloud.cfg (or /e/c/cloud.cfg.d/*) so your source will need to be in that list to even be
[13:28] <Odd_Bloke> considered.
[13:28] <Odd_Bloke> (I would suggest adding it as the _only_ DS while you're iterating on it.)
[13:33] <catphish> Odd_Bloke: i'm writing a datasource for a new cloud provider - https://katapult.io/ - but my intention is for it to be somewhat different from the existing datasources, specifically because it will use http over ipv6 link local (possibly with multicast discovery), rather than DHCP or APIPA, if at all possible i will make it generic rather than proprietary
[13:35] <catphish> Odd_Bloke: thanks for the pointer, i will try adding my datasource module and adding it to /etc/cloud/cloud.cfg - i have one other question though, should i be hacking on an ubuntu install, or directly on the source repo, i couldn't work out how to execute the latter, i'm actually not that familiar with python packages
[13:42] <Odd_Bloke> catphish: It's probably easiest to iterate in an install; cloud-init is system software, so running it "from source" is tricky.  We generally use `./packages/bddeb` to build debs from the tree, which you can then install in an Ubuntu system to test.
[13:44] <catphish> thanks! i'll give that all a try
[13:44] <Odd_Bloke> rharper: You mentioned "there's an existing test in-tree that tests the case where content is not shellscript" but I just added `assert False` to the top of UserDataProcessor._process_msg and it didn't cause any tests to fail.  Am I missing something?
[13:44] <Odd_Bloke> (Perhaps it's a cloud test, I realise immediately after sending that message.)
[13:46] <Odd_Bloke> Ooor perhaps I hadn't saved the file?  I'm seeing failures now.
[13:46] <Odd_Bloke> rharper: Disregard the above. :)
[14:00] <otubo> Odd_Bloke, smoser quick question about cloud-utils[-growpart]: What's the difference between these two? IIUC -growpart is the package shipped by distros that includes just the growpart script from cloud-utils. Is that correct?
[14:01] <otubo> Odd_Bloke, also, I was on PTO. Gonna fix that PR this week :-)
[14:26] <smoser> otubo: i can't really speak to that.
[14:27] <smoser> ubuntu ships 'cloud-image-utils' and 'cloud-guest-utils'.  growpart is included in cloud-guest-utils.
[14:27] <smoser> i really don't know about other distros.
[14:28] <smoser> i can agree that with 10  years of hindsight, the connection of 'growpart' to 'ec2metadata' seems silly.  it is "obvious" that I just should have made a separate upstream package for growpart.
[14:29] <smoser> what is more obvious is that I should have just written such a thing in C ;)
[14:37] <meena> *cough* rust *cough*
[14:39] <smoser> meena: yes. but please give the smoser from 10 years ago a break on that.
[14:39] <smoser> he justu didn't think that rust was going to pan out.
[14:40] <meena> fair
[14:41] <meena> i think ten years ago i still held onto the believe that C is a real programming language.
[14:41] <meena> instead of 38962 different dialects
[14:41] <smoser> but for what its worth, if you're interrested in a rust rewrite of growpart
[14:41] <smoser>  https://github.com/bottlerocket-os/bottlerocket/tree/develop/sources/growpart
[14:41] <smoser> might be a place to start.
[14:44] <meena> cool
[14:45] <otubo> oh nice
[14:46] <otubo> smoser, thanks. Yeah, and the mystery of why distros ship growpart as a different package continues.
[14:46] <otubo> if I get any interesting info on that I'll leave some bits here :-)
[15:51] <Odd_Bloke> https://github.com/canonical/cloud-init/pull/512 <-- short-term fix for the pylint CI failures we've started seeing since pytest 6.x released
[15:51] <Odd_Bloke> rharper: ^ should fix your PR's CI failure.
[15:56] <soasada> Hi guys, I need some help. I have an Ubuntu 18.04 LTS VPS on OVH and has installed cloud-init. The thing is that I have just removed the "set_hostname" from "cloud_init_modules" in the "/etc/cloud/cloud.cfg" file and I reboot the server, the problem is that now I cannot connect to the server, is completely down. It is possible to recover it?
[16:08] <Odd_Bloke> soasada: I don't have experience with OVH; do you have access to a serial console for the machine?
[16:09] <soasada> No, I haven't
[16:10] <Odd_Bloke> Hmm, then I don't know how much help we'll be able to offer here, you may need to follow up in OVH support channels.
[16:11] <Odd_Bloke> (FWIW, I wouldn't expect that change to take a server down completely, which is why I suspect this may be an OVH-specific issue.)
[16:12] <soasada> ok, so I have to contact then
[16:12] <soasada> thank you so much Odd_Bloke
[16:12] <Odd_Bloke> soasada: Good luck! :)
[16:15] <Odd_Bloke> blackboxsw_: That pytest change hasn't been released yet; any objection to landing that fix so CI will run, and backing it out once we do have a release?
[16:16]  * blackboxsw_ was wondering about us actually pinning https://github.com/pytest-dev/pytest/commit/d46fe88ec33f3ee2aa8addc56ee090b0119474d3 for the moment.
[16:16] <blackboxsw_> in our deps. but, let's just go with the simpler <6
[16:17] <blackboxsw_> can we add a comment about the pytest issue Odd_Bloke for reference
[16:17] <blackboxsw_> or make that the commit msg
[16:17] <blackboxsw_> either way, a bread crumb would be nice to the issue so future us can track closure and back this out
[16:22] <Odd_Bloke> blackboxsw_: Done.
[16:22] <blackboxsw_> and Approved thx
[18:15] <rharper> Odd_Bloke: thanks, i'll update