| chillysurfer | out of curiosity, does cloud-init (when installed on a target machine) utilize a virtual environment? or does it just deal with shared python dependencies on the machine? | 16:05 |
|---|---|---|
| powersj | chillysurfer, the ubuntu packaging uses python packages from the distro | 16:09 |
| powersj | other distros do the same | 16:10 |
| chillysurfer | powersj: correct me if i'm wrong, but using python packages from the distro is the equivalent of shared deps for python | 16:35 |
| Odd_Bloke | chillysurfer: That's correct. | 16:40 |
| Odd_Bloke | When `import X` runs, the Python interpreter runs through PYTHONPATH to find what's being imported, and we ensure that all dependencies for cloud-init are in the system PYTHONPATH entries (by expressing dependencies in our Debian packaging). | 16:41 |
| chillysurfer | Odd_Bloke: yep that makes sense! | 16:42 |
| chillysurfer | funny that there haven't been nightmares of dep conflicts though..? | 16:42 |
| Odd_Bloke | That's what a lot of distro work is: getting all the packages you want to ship on to versions that are mutually compatible | 16:44 |
| Odd_Bloke | We're also very conservative about adding new dependencies to cloud-init, for precisely this reason. | 16:45 |
| Odd_Bloke | It might save us a few hours or days of development time, but we'll be on the hook for support and maintenance for that version of that dependency for the lifetime of the Ubuntu releases it's in. | 16:46 |
| Odd_Bloke | Which in the case of bionic, at least, is until 2028. | 16:47 |
| Odd_Bloke | chillysurfer: You'll probably also want `--release eoan` or similar, else you still won't be able to upload it. | 16:51 |
| chillysurfer | Odd_Bloke: ah ok. i'm building this for bionic though so i'll specify that instead | 16:52 |
| Odd_Bloke | Yep! | 16:53 |
| AnhVoMSFT | rharper regarding this https://code.launchpad.net/~vtqanh/cloud-init/+git/cloud-init/+merge/369785 - I have some concern about mocking the systemctl call as you suggested because I actually want to test against the real systemd output. In a non-systemd system we're not interested in the boot telemetry at all (for now) and the fact that the code isn | 17:28 |
| AnhVoMSFT | 't exercised in that case is a desirable outcome. My main concern is that if there's a behavior change say in systemctl and the output is now formatted in a way that is not compatible with what the function expected; we want to catch that in unit test | 17:28 |
| Odd_Bloke | AnhVoMSFT: Unit tests are not the appropriate place to be testing integration with system utilities. As Ryan notes, the unit tests shouldn't be dependent on whether or not systemd is installed (or, for that matter, what version of systemd you have installed). This is the sort of issue that we would expect to catch in integration testing (i.e. cloud_tests). | 17:39 |
| Odd_Bloke | If we found an issue there, we would then modify the unit tests' test data to reflect the discrepancy, and fix the issue so that those tests were passing again. | 17:40 |
| Odd_Bloke | To put it another way, the unit tests are there to ensure that _we_ haven't broken our interactions with systemctl when we make changes in the future. | 17:41 |
| Odd_Bloke | (Just having the unit tests run against the system's systemctl doesn't really help in the case where there is a change in behaviour, regardless. We would need to test against _both_ behaviours, and the system systemctl will obviously only exhibit one of the behaviours.) | 17:43 |
| rharper | AnhVoMSFT: we only run unittests against a particular host os; so a unittest won't ever verify that systemctl isn't broken on any other os; as Odd_Bloke said, one could write an integration test which runs on multiple OSes and versions of systemd to ensure systemdctl isn't broken but I don' t _really_ think we need that level of testing for the systemctl command output ; | 17:44 |
| AnhVoMSFT | rharper Odd_Bloke I don't disagree with the intention of unittests here but the the only thing the function does is making those two calls foo and bar, and if mock both foo and bar, what exactly are we testing? | 18:17 |
| Odd_Bloke | AnhVoMSFT: So I haven't reviewed the MP in question, but if you're worried about the systemctl output then we are presumably testing that we parse the current systemctl output correctly? | 18:18 |
| rharper | AnhVoMSFT: we want to exercise the various code paths; systemctl provides no output, systemctl throws an exception, systemctl provides stdout (but not in the expected format Foo=abc) , systemct provides output in the correct format | 18:20 |
| rharper | we can mock the return value (and side-effect) of the subp call to show that cloud-init does the expected thing in each of those possible scenarios | 18:20 |
| AnhVoMSFT | ok, that seems a bit clearer on the intention - thanks guys | 18:20 |
| AnhVoMSFT | my original intention was to basically test two things: if the VM has systemd, I want to see xyz as output, if no systemd, I want to see no output | 18:23 |
| === mskalka_ is now known as mskalka | ||
| === fyx_ is now known as fyx | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!