| davido | Odd_Bloke, thanks for pointer to docs | 00:17 |
|---|---|---|
| === lachesis_ is now known as lachesis | ||
| === Gaffel_ is now known as Gaffel | ||
| === ItsAGeekThing4 is now known as ItsAGeekThing | ||
| === Tahvok_ is now known as Tahvok | ||
| === jmcgnh_ is now known as jmcgnh | ||
| === jmcgnh is now known as jmcgnh_ | ||
| === jmcgnh_ is now known as jmcgnh | ||
| beantaxi | Morning all! Question on testing ... from reading the readthedocs, I see that both pytest tests and unittest.TestCase tests are supported. I'm not savvy enough about Python testing to know if this is clearly a Good Thing, or if it's just sort of how things are because in early days some folks used pytest, some used UnitTest.TestCase, and you were happy enough they were writing tests at all to not | 13:30 |
| beantaxi | worry about it till a future date to be named later. Thanks! | 13:30 |
| meena | beantaxi: i think it's that we started out with x because that's what people knew, or what was available, and then later as they got smarter about testing we did y | 13:46 |
| meena | you fill in the variables | 13:46 |
| beantaxi | I'm not qualified to fill those blanks in, but if x or y is better/newer/preferred, I'm happy to use that one, since I have nothing invested in either | 13:51 |
| beantaxi | Meanwhile I'm in "How does anyone figure out how anything works in Python" mode. I've been trying to find where in pytest.org it documents what (eg) @pytest.mark.user_data(USER_DATA), specifically how the USER_DATA argument is used, but I can't find anything | 13:53 |
| chillysurfer | hey, all! it appears as though this pr keeps getting closed: https://github.com/canonical/cloud-init/pull/780 could i get it reopened? thanks! | 13:54 |
| Odd_Bloke | beantaxi: We moved to using pytest over the last year and a bit, so that's preferred; the integration tests are entirely written using pytest. Some marks have specific meaning in pytest by default (e.g. @pytest.mark.skip), but it's a generic tagging mechanism, which allows you to store data along with the tag: that's how we're using the user_data mark. | 14:25 |
| Odd_Bloke | beantaxi: Most of the integration tests use the `client` (or `class_client`) fixture defined in https://github.com/canonical/cloud-init/blob/master/tests/integration_tests/conftest.py; these are all wrappers around `_client`, which uses the user_data mark: https://github.com/canonical/cloud-init/blob/master/tests/integration_tests/conftest.py#L202 | 14:26 |
| Odd_Bloke | beantaxi: But, basically, it's passed into the instance however user-data is passed into instances for the cloud under test. | 14:27 |
| Odd_Bloke | chillysurfer: Done; sorry! | 14:29 |
| chillysurfer | Odd_Bloke: no problem! and thank you!! | 14:29 |
| beantaxi | Odd_Bloke: Thanks very much for that. So @pytest.mark.user_data(USER_DATA) is sort of like DI, and it allows you to pull the value of a 'user_data' setting from the ether in an unrelated part of code, instead of explicitly passing in a reference. So to speak. I'm not sure why I could not find that in the pytest docs but perhaps I was overlooking something obvioius. Thanks! | 14:34 |
| Odd_Bloke | beantaxi: In pytest terms, fixtures are closer to dependency injection than marks. Marks are just metadata on tests: at their most basic, they can be used to select tests (e.g. "don't run 'slow' tests"). However, test framework code can also use them programmatically: pytest knows how to handle some of them itself (i.e. it skips tests marked with "skip"), and we've written framework code that knows how | 14:48 |
| Odd_Bloke | to handle others (including `user_data`). | 14:48 |
| Odd_Bloke | In our case `user_data` is used to mean, "please pass this user-data into the instance that you launch as a result of running this test". | 14:48 |
| beantaxi | Odd_Bloke: That sounds more accurate. I was using 'DI' as a minumum for 'all the things Spring does for Java', which includes decorating variable declarations with annoations that result in those variables being assigned values pulled from property files, without an explicit assignment in the code. So you can look forever for that assignment and never find anything, but it doesn't mean you're crazy. | 14:57 |
| beantaxi | Thanks for the insight. | 14:57 |
| beantaxi | It also looks like running integration tests requires logging into a VM, and specifying that VM as your platform one way or another when running integration tests, unless you want lots of failures. So among other things, if I were running an on EC2 instance, pytest integration_tests is going to invoke pycloudlib which will dynamically create, snapshot, and destroy a new VM ... or possibly do all that | 15:00 |
| beantaxi | on the existing VM, which would save on EC2 charges I suppose | 15:00 |
| beantaxi | (fyi for fun I tried to run integration_tests inside my Docker image, which required adding git and gcc, and then when I ran pytest integration_tests I think literally every test failed. That wasn't unexpected; I just wanted to see what happened.) | 15:02 |
| Odd_Bloke | beantaxi: The integration test framework will launch instances in the target platform: by default it uses LXD containers. | 15:32 |
| Odd_Bloke | It just requires credentials for the platform in question, you don't need to be running there. | 15:33 |
| Odd_Bloke | And it won't use existing VMs in its default configuration, so it _will_ try to launch things which cost you money (hence defaulting to containers, which don't :). | 15:34 |
| Odd_Bloke | (The support for using an existing VM is really intended for test development, or specific manual cases: for clouds which we don't have automated integration with, for example.) | 15:34 |
| beantaxi | Odd_Bloke: Gotcha, I did look at the code and I saw the default was lxd. So I can run integration_tests on any linux system with lxd installed? Eg if I run from an EC2 instance I can just run pytest integration_tests from the command line and be good. Do I need to uninstall the lxd apt package and install from snap? Or does the installed version work from a default EC2 Ubuntu instance. I guess I'm | 15:53 |
| beantaxi | assuming y'all have ttried this and the answer is well known to you. | 15:53 |
| Odd_Bloke | beantaxi: I just run it locally mostly, on my (Ubuntu 20.10) desktop; I have no reason to think that LXD on an EC2 instance shouldn't work, though. | 16:40 |
| Odd_Bloke | (It's possible that the LXD in xenial is older than we need for some of the tests, I'm unsure.) | 16:40 |
| beantaxi | I just tried on an EC2 instance I had up. My naive invocation fails -- here are the first 50 lines of output -> https://paste.ubuntu.com/p/wzpbWdTSMY/ -- but perhaps my unadorned `pytest tests/integration_tests` is missing something | 17:01 |
| === blackboxsw changed the topic of #cloud-init to: 20.4 (Nov 24), 21.1 (Feb 22) | file a bug: https://bugs.launchpad.net/cloud-init/+filebug | pull-requests: https://git.io/JeVed | meeting minutes: https://goo.gl/mrHdaj | next office hours: Mar 09 17:15 UTC | ||
| blackboxsw | oops had to correct the UTC time typo 15:15 -> 17.15. Yes officially we will host cloud-init office hours today. starting in about 7 mins. | 17:08 |
| * blackboxsw is putting up the discourse post content now with high level status update content | 17:09 | |
| Odd_Bloke | beantaxi: I'd expect that to work; try running `pytest tests/integration_tests/modules/test_runcmd.py` and letting it complete: that way we'll get more info about what that error is. | 17:16 |
| blackboxsw | #startmeeting cloud-init bi-weekly office-hours | 17:19 |
| meetingology | Meeting started at 17:19:08 UTC. The chair is blackboxsw. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 17:19 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 17:19 |
| blackboxsw | #char Odd_Bloke falcojr | 17:19 |
| blackboxsw | #chair Odd_Bloke falcojr | 17:19 |
| meetingology | Current chairs: Odd_Bloke, blackboxsw, falcojr | 17:19 |
| blackboxsw | hi cloud-init, sorry for the confusion on the UTC time that I posted in the topic. I had incorrectly set 15:15 UTC instead of 17:15. | 17:20 |
| blackboxsw | welcome to the bi-weekly cloud-init office hours | 17:20 |
| blackboxsw | This cloud-init status meeting has moved to a more asynchronous posting of high-level happenings in cloud-init to discourse to support timezone differences for all cloud-init developers. | 17:21 |
| blackboxsw | We plan on continuing to host these office hours to provide a means for quick communication, questions and discussions with a couple of upstream developers present to help facilite any questions or discussions of interest to folks. | 17:23 |
| blackboxsw | For reference, here are the high-level "happenings" in cloud-init upstream over the last two weeks. | 17:23 |
| Odd_Bloke | o/ | 17:23 |
| blackboxsw | #link https://discourse.ubuntu.com/t/cloud-init-status-03-09-2021/21309 | 17:23 |
| blackboxsw | As of last office-hours I belive upstream had just cut the first 21.1 release in the tip of cloud-init. Canonical will be starting the SRU process this week I believe to publish the 21.1 release (plus a couple of extra fixes which just landed in tip) into Ubuntu Xenial, Bionic, Focal, Groovy and Hirsute. | 17:26 |
| beantaxi | Odd_Bloke: I tried your command and it was helpful. It complained about a missing ssh key, so I shrugged, tried ssh-keygen -t rsa and reran the test, and it passed. I've kicked off a run of all the tests, which I assume will take a bit. | 17:41 |
| Odd_Bloke | beantaxi: Great, thanks for the update! A full run in LXD containers takes ~12mins locally (though I'm probably running on beefier hardware than you're paying EC2 for so YMMV :p). | 17:55 |
| Odd_Bloke | beantaxi: Once you had the output, was it clear that the missing SSH key was the issue? | 17:55 |
| === blackboxsw changed the topic of #cloud-init to: 20.4 (Nov 24), 21.1 (Feb 22) | file a bug: https://bugs.launchpad.net/cloud-init/+filebug | pull-requests: https://git.io/JeVed | meeting minutes: https://goo.gl/mrHdaj | next office hours: Mar 23 17:15 UTC | ||
| blackboxsw | setting the appropriate time for next office hours | 17:55 |
| blackboxsw | setting the appropriate time for next office hours Mar 23 17:15 UTC | 17:56 |
| beantaxi | ERROR tests/integration_tests/modules/test_runcmd.py::TestRuncmd::test_runcmd - FileNotFoundError: [Errno 2] No such file or directory: '/home/ubuntu/.ssh/id_rsa.pub' | 17:57 |
| beantaxi | That was the error message | 17:57 |
| falcojr | tests require an ssh keypair. It'll use your user one by default or you can specify one manually in the integration settings config | 17:59 |
| falcojr | do an `ssh-keygen` | 17:59 |
| beantaxi | The full test failed with 7 failures: https://paste.ubuntu.com/p/hcYN7ZDvbs/ | 17:59 |
| beantaxi | falcojr: Thanks ... I was just showing Odd_Bloke the error message I got before running ssh-keygen, which did indeed solve most of my issues | 18:00 |
| beantaxi | falcojr: Also, this is just me running the existing integration tests on an EC2 instance. Without any of my changes | 18:01 |
| falcojr | not sure the cause of that first one, but the rest are for code not in ubuntu images yet | 18:01 |
| falcojr | the version of cloud_init to use is specified by the CLOUD_INIT_SOURCE variable (integration_settings.py...copy this to user_settings.py to easily override defaults) | 18:03 |
| falcojr | it defaults to NONE which means use whatever image has been released on this platform | 18:03 |
| falcojr | to test non-released code, changing it to IN_PLACE (only works on LXD) should work | 18:04 |
| falcojr | you can also set it to ppa:cloud-init-dev/daily , but that won't contain any changes that you're trying to test | 18:08 |
| beantaxi | falcojr: Copying integration_settings.py to user_settings.py and setting CLOUD_INIT_SOURCE=IN_PLACE made all the test_keys_to_console errors clean. There's still that simple_streams error. Do I just need to add a PPA for simplestreams? It looks like requires a file in /etc/apt/sources.list.d, but mine is empty | 18:18 |
| falcojr | Not sure off the top of my head. Did you pip install the integration_requirements.txt? | 18:23 |
| * blackboxsw thinks I should about wrap up office hours. Thanks falcojr Odd_Bloke and beantaxi for the discussion there | 18:38 | |
| blackboxsw | #endmeeting | 18:38 |
| meetingology | Meeting ended at 18:38:08 UTC. Minutes at https://new.ubottu.com/meetingology/logs/cloud-init/2021/cloud-init.2021-03-09-17.19.moin.txt | 18:38 |
| beantaxi | falcojr: Yes, I ran this command: pip install -r ./requirements.txt -r test-requirements.txt -r integration-requirements.txt | 19:47 |
| Odd_Bloke | beantaxi: falcojr: That simplestreams error looks to me like we're assuming that we'll detect an Ubuntu release to look for. | 19:48 |
| Odd_Bloke | Let me explain that better. :p | 19:49 |
| Odd_Bloke | In your first log, I see "ubuntu-distro-info (from the distro-info package) must be installed to guess Ubuntu os/release" followed by "Detected image: image_id=focal os=None release=None". | 19:50 |
| Odd_Bloke | In test_apt.py, we look for .release to determine the file to read: https://github.com/canonical/cloud-init/blob/master/tests/integration_tests/modules/test_apt.py#L145 | 19:52 |
| Odd_Bloke | Which leads to "/etc/apt/sources.list.d/simplestreams-dev-ubuntu-trunk-None.list" being looked for; "None" being the problem here. | 19:53 |
| Odd_Bloke | (The fact that it's simplestreams is a coincidence: that's just the PPA the test author chose to use for the test.) | 19:53 |
| beantaxi | $ ls -1 /etc/apt/sources.list.d | wc -l return 0 for me ... the folder is empty. Would that be resolved by installing (ubuntu-)distro-info? Or am I reading that wrong | 19:55 |
| Odd_Bloke | The two fixes: manually specify the OS and release by setting CLOUD_INIT_OS_IMAGE=focal::ubuntu::focal in your environment (or OS_IMAGE = "..." in your settings), or install distro-info. | 19:56 |
| Odd_Bloke | beantaxi: You are reading it a little wrong: the path in question is within the system-under-test. | 19:56 |
| Odd_Bloke | The two fixes I suggested would mean that it would look for the correct path. | 19:56 |
| Odd_Bloke | (It's a minor bug in the test, to be clear.) | 19:56 |
| beantaxi | Odd_Bloke: I seem to recall this from the integration_tests instructions, something about how if you are too vague in specifying a variable, you will get errors when the wrong tests are run, but if you're more specific that won't happen | 20:01 |
| beantaxi | Odd_Bloke: Making that change to user_settings.py cleaned up the test_apt.py error. So if I just wanted a one liner, and not touch any files, I could do CLOUD_INIT_OS_IMAGE focal::ubuntu::focal CLOUD_INIT_SOURCE=IN_PLACE pytest tests/integration_tests should work? | 20:07 |
| Odd_Bloke | beantaxi: You're missing an = after OS_IMAGE but otherwise, yeah, that should run all the integration tests that apply to Ubuntu focal using the code in your cloud-init tree. | 20:09 |
| Odd_Bloke | beantaxi: Oh, no, you need CLOUD_INIT_CLOUD_INIT_SOURCE, actually. | 20:10 |
| Odd_Bloke | (CLOUD_INIT_ is stripped off the environment variables.) | 20:10 |
| beantaxi | Yes I'd read that and thought I understood it, but then I say CLOUD_INIT_SOURCE in the settings file and figured I'd misunderstood. Ok, that's nice I can do it as a one-liner without touching any settings files. | 20:13 |
| Odd_Bloke | Yep, that's what I do. | 20:27 |
| beantaxi | Odd_Bloke: falcojr: I finally got test to complete without my ssh session dying before I checked. I'm getting a clean run with this command: | 23:22 |
| beantaxi | CLOUD_INIT_OS_IMAGE=focal::ubuntu::focal CLOUD_INIT_CLOUD_INIT_SOURCE=IN_PLACE pytest $HOME/src/github.com/canonical/cloud-init/tests/integration_tests | 23:22 |
| beantaxi | There are some warnings, mostly deprecation I think. Any objection to my fixing those while I'm in the area? | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!