[02:23] <rharper> cmm_:  you can check  if /sys/firmware/efi   exists ; if so you've booted UEFI; if  isn't present, then you're on BIOS;
[06:48] <dikonoor> smoser:rharper:Odd_Bloke: I am looking for information on when is the next release of cloud-init coming out
[06:49] <dikonoor> This is primarily to understand in which release some of the recent upstreamed changes will be available
=== hjensas|PTO is now known as hjensas
[14:24] <cmm_> Hi @rharper, yes.  I'm aware of /sys/firmware/efi.   I have to do the check to change behaviors in several places, so I was hoping to put this into instance data to use jinja templating .  Is it possible at all?   I've tried brute-force adding to instance-data-sensitive.json using jq, but it just ends up getting overwritten.  Is there a hack possible using, say, a part-handler to add values to instance data?  Or perhaps use vendor data somehow?
[14:26] <cmm_> I was surprised merged_cfg wasn't showing new settings I put into /etc/cloud/cloud.cfg.d/, since it appeared to be getting loaded from looking at the logs.  All I can think is each module must insert this data so I'd have to make my own, perhaps.
[14:32] <cmm_> I'm building VM images using Docker, which I use with iPXE and squashfs to boot, so making a module is an option.  I just haven't dug into ci like this before.
[14:45] <Odd_Bloke> cmm_: I think the problem you're going to run into with /etc/cloud/cloud.cfg.d/ is that cloud-init reads that config once and caches it; by the time you can do anything to it with cloud-init, it's already cached.
[14:47] <cmm_> I'd like to do something like this (which doesn't work, but I tried):  https://gist.github.com/chris-mccoy/1a8082a47d1aa49e6676c7cfd0341790
[14:48] <cmm_> it'd be super awesome if there was a counterpart to 'cloud-init query'
[14:52] <Odd_Bloke> This isn't really a way I've really thought about using the data before; it's intended to be a read-only view onto the state that cloud-init has fetched from its various config sources, so people can switch on that.  Which isn't to say that it couldn't make sense for it to extend out to a user-facing KV store, but we currently don't have any plans around it.
[14:52] <cmm_> I understand, okay.  :-\
[14:54] <cmm_> I have full control over /meta-data and /user-data on NoCloud-net... If I do this early enough in a boot-stage, would cloud-init exit and run again and pull new values in?  Perhaps merge them from the filesystem somewhere?
[15:11] <Odd_Bloke> cmm_: cloud-init fetches those once and caches them also; those generally don't change during an instance's lifetime, so there's no reason to spend the time using the network if we don't need to.
[15:12] <cmm_> understood.  Thank you for your help.
[15:14] <cmm_> I'll just write the runcmd scripts to do this check and modify write_files that cloud-init makes for now.
[15:14] <Odd_Bloke> Yeah, that sounds like the right path forward; sorry there isn't a cleaner way to do it!
[15:14] <cmm_> no worries
[15:24] <AnhVoMSFT> Is it just me or running tox on master failed for xenial?
[15:25] <AnhVoMSFT> https://paste.ubuntu.com/p/Mm5kV2n6ZD/
[15:30] <Odd_Bloke> AnhVoMSFT: Looking now.
[15:36] <minimal> Odd_Bloke: I'll have a look at users_groups integration test and see if I can work something out. Not sure how to run integration tests myself as don't have a Ubuntu box handy
[15:39] <Odd_Bloke> minimal: The tests default to use LXD which is in most Ubuntu Server images: launching an Ubuntu VM (locally or in your cloud of choice) and running `lxd init --auto` should give you a working environment.
[15:39] <Odd_Bloke> (I would expect any installation of LXD to work, Ubuntu is just the quickest path to getting one that I know of. :)
[15:41] <minimal> Odd_Bloke: ok, will look into it. Any chance you could review/merge #626? Its had a few minor comments and has been submitted for over a week.
[15:53] <Odd_Bloke> minimal: No promises, I'm afraid, my list for today is already pretty full.
[15:54] <minimal> no problem
[15:55] <Odd_Bloke> falcojr: I noticed that the PR template test steps call for specific instructions for reproduction on an Ubuntu machine: this means that meena has (very reasonably) been saying "you can't reproduce this on Ubuntu" for BSD-related changes.  What do you think to making that wording less specific, so we get testing steps for all PRs?
[16:53] <meena> he he he
[16:54] <meena> you really want me to write all the tests, eh
[16:55] <meena> I'm pretty sure the integration test suite currently fails about 95% of the time on not-Linux
[16:55] <Odd_Bloke> meena: Those steps can be automated output, but for cases where automation isn't possible (at all, or "yet"), then manual steps are totally acceptable.
[16:56] <Odd_Bloke> We really want submitters to demonstrate that this code has run at least once in a real environment, and done the right thing.
[16:56] <Odd_Bloke> (Unless that isn't possible, in which case documenting that fact is fine too!)
[16:59] <meena> so for the gpart stuff i resized my qcow2 image, it came up "corrupt", i did gpart recover, gpart resize, zpool online, and all that last bit worked without a reboot
[17:20] <falcojr> Odd_Bloke: https://github.com/canonical/cloud-init/pull/648
[17:39] <Odd_Bloke> smoser1: I've replied to your PR template comment: https://github.com/canonical/cloud-init/pull/642#discussion_r516145738
[17:40] <Odd_Bloke> falcojr: Thanks!  Landed.
[17:41] <Odd_Bloke> AnhVoMSFT: https://github.com/canonical/pycloudlib/issues/41 is what came out of my investigation; I'll be looking at addressing that this pm.
[17:49] <AnhVoMSFT> Thanks @Odd_Bloke
[17:49] <AnhVoMSFT> but this did not seem to correlate to any change from cloud-init side though?
[17:50] <AnhVoMSFT> the build was working on Friday, just today things started to fail
[17:51] <AnhVoMSFT> looks like when trying to install pylint, pip failed to determine which setuptools package it should install. It ended up downloading all the setuptools packages
=== ijohnson is now known as ijohnson|lunch
[18:03] <meena> Odd_Bloke, i've updated the test steps here https://github.com/canonical/cloud-init/pull/646
[18:45] <Odd_Bloke> AnhVoMSFT: The latest version of pip (20.3b1) switches to their new dependency resolver by default, I bet that's the cause: https://github.com/pypa/pip/blob/20.3b1/NEWS.rst#features
[18:46] <Odd_Bloke> And that was released on Friday, so it makes sense we would only be seeing it now.
[18:49] <Odd_Bloke> That's a prerelease though, so I'm a little surprised that it's been pulled in already, but that is what I'm seeing when I reproduce the issue.
=== ijohnson|lunch is now known as ijohnson
[20:01] <meena> rick_h: i hope to have answered your question appropriately https://github.com/canonical/cloud-init/pull/646#issuecomment-720691634
[20:50] <smoser1> a comment...
=== smoser1 is now known as smoser
[20:50] <smoser> i went to cherry-pick a fix for 1879673 from https://github.com/canonical/cloud-init/pull/423
[20:51] <smoser> i believe that it is deemed "ok" to add oneself to contributors tools/.github-cla-signers
[20:51] <smoser> in the same PR as an actual  change.
[20:51] <smoser> it does break a simple cherry-pick.
[20:55] <rharper> smoser: yeah; I was just asking Odd_Bloke about that;  the idea was to not have to add any more burden to cla process; but I think if it were a separate commit; and we didn't do squash and merge; it'd work out;