| 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; | 02:23 |
|---|---|---|
| dikonoor | smoser:rharper:Odd_Bloke: I am looking for information on when is the next release of cloud-init coming out | 06:48 |
| dikonoor | This is primarily to understand in which release some of the recent upstreamed changes will be available | 06:49 |
| === hjensas|PTO is now known as hjensas | ||
| 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:24 |
| 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:26 |
| 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:32 |
| 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:45 |
| cmm_ | I'd like to do something like this (which doesn't work, but I tried): https://gist.github.com/chris-mccoy/1a8082a47d1aa49e6676c7cfd0341790 | 14:47 |
| cmm_ | it'd be super awesome if there was a counterpart to 'cloud-init query' | 14:48 |
| 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:52 |
| 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? | 14:54 |
| 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:11 |
| cmm_ | understood. Thank you for your help. | 15:12 |
| 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:14 |
| AnhVoMSFT | Is it just me or running tox on master failed for xenial? | 15:24 |
| AnhVoMSFT | https://paste.ubuntu.com/p/Mm5kV2n6ZD/ | 15:25 |
| Odd_Bloke | AnhVoMSFT: Looking now. | 15:30 |
| 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:36 |
| 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:39 |
| 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:41 |
| Odd_Bloke | minimal: No promises, I'm afraid, my list for today is already pretty full. | 15:53 |
| minimal | no problem | 15:54 |
| 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? | 15:55 |
| meena | he he he | 16:53 |
| meena | you really want me to write all the tests, eh | 16:54 |
| 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:55 |
| 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:56 |
| 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 | 16:59 |
| falcojr | Odd_Bloke: https://github.com/canonical/cloud-init/pull/648 | 17:20 |
| Odd_Bloke | smoser1: I've replied to your PR template comment: https://github.com/canonical/cloud-init/pull/642#discussion_r516145738 | 17:39 |
| Odd_Bloke | falcojr: Thanks! Landed. | 17:40 |
| 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:41 |
| AnhVoMSFT | Thanks @Odd_Bloke | 17:49 |
| AnhVoMSFT | but this did not seem to correlate to any change from cloud-init side though? | 17:49 |
| AnhVoMSFT | the build was working on Friday, just today things started to fail | 17:50 |
| 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 | 17:51 |
| === ijohnson is now known as ijohnson|lunch | ||
| meena | Odd_Bloke, i've updated the test steps here https://github.com/canonical/cloud-init/pull/646 | 18:03 |
| 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:45 |
| Odd_Bloke | And that was released on Friday, so it makes sense we would only be seeing it now. | 18:46 |
| 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. | 18:49 |
| === ijohnson|lunch is now known as ijohnson | ||
| meena | rick_h: i hope to have answered your question appropriately https://github.com/canonical/cloud-init/pull/646#issuecomment-720691634 | 20:01 |
| smoser1 | a comment... | 20:50 |
| === smoser1 is now known as smoser | ||
| smoser | i went to cherry-pick a fix for 1879673 from https://github.com/canonical/cloud-init/pull/423 | 20:50 |
| 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:51 |
| 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; | 20:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!