[00:24] <falcojr> I've done test parametrization before. I see tradeoffs both ways and could go either way for this. I usually think of parametrization for when you start accumulating very similar individual tests (e.g., test_x_less_than_0, test_x_greater_than_0, test_x_equal_0), and need an abstraction to reduce code duplication.  In this case, I would never think
[00:24] <falcojr> to write "test_file_x", "test_file_y", "test_file_z", so to me I think of this as a single test...test all the examples. But like I said, I could go either way, so if there's a strong preference for paramterization, I can do that. Just let me know
=== vrubiolo1 is now known as vrubiolo
[13:53] <Odd_Bloke> falcojr: Interesting, I think I see it differently for a couple of reasons.  Firstly, I think, as-written, the for loop _is_ parameterising this test already: it's running an identical validation test with different parameters for each iteration of the for loop.  So for me that meets the "very similar individual tests" standard.  And secondly, if I'm making changes to our schema validation code or our
[13:53] <Odd_Bloke> schemas, I would like to have a granular indication of which examples I've broken with my changes but the current test will fail on the first failure it finds.  You could update the current test to gather all errors before it fails the test, but that's effectively reimplementing a test runner in a way that's opaque to our actual test runner, so we may as well use the features it provides us.
[13:55] <falcojr> Odd_Bloke makes sense, I'll parametrize it
[13:57] <Odd_Bloke> falcojr: Thanks! :)
[14:24] <Odd_Bloke> (I just misspelled schema as schma, and that's a fun word to say.)
[14:25] <falcojr> https://vignette.wikia.nocookie.net/disney/images/6/6f/Mr._Smee_Profile.jpg
[14:25] <Odd_Bloke> falcojr: Thanks for the update on the PR, I've pushed another couple of (minor) comments. :)
[14:26] <Odd_Bloke> (Regrettably with schema spelled correctly.)
[16:52] <blackboxsw> robjo: if you have a moment, do you have any concerns with switching the default localhost IP to 127.0.1.1 on suse in cloud-init, just like debian and ubuntu? chengcheng from vmware land would like to make that change in cloud-init https://github.com/canonical/cloud-init/pull/336
[16:53] <blackboxsw> the branch looks sounds, and the IP address is accessible on a couple of opensuse containers I've launched but I wasn't certain if there are any specific concerns on OpenSUSE side that I should be cognizant of before reviewing and landing this branch
[16:54] <robjo> blackboxsw: LGTM, commented on the PR
[16:54] <blackboxsw> awesome robjo thanks for the quick turnaround here
=== tds8 is now known as tds