[13:04] <AnhVoMSFT> Odd_Bloke I am running into this weird pylint error
[13:05] <AnhVoMSFT> ************* Module cloudinit.tests.test_conftest
[13:05] <AnhVoMSFT> cloudinit/tests/test_conftest.py:14: [E1120(no-value-for-parameter), TestDisableSubpUsage.test_typeerrors_on_incorrect_usage] No value for argument 'args' in function call
[13:06] <AnhVoMSFT> it does not happen if I checkout to my local box and run tox, but somehow in our build server it's throwing this error. I've cross-checked the versions of the modules and they seem to match. Do you have any idea on top of your head why I might be seeing this?
[13:44] <Odd_Bloke> Technically it's correct, we are intentionally calling the function without that necessary parameter.
[13:44] <Odd_Bloke> But I don't know why we aren't seeing it consistently.
[13:44] <Odd_Bloke> AnhVoMSFT: Does your build server not use tox?
[13:45] <Odd_Bloke> ausfestivus: Hmm, interesting; what's the serial in /etc/cloud/build.info?
[13:54] <AnhVoMSFT> Odd_Bloke it does use tox, which is why it has been puzzling me
[13:56] <AnhVoMSFT> it runs the whole test in a xenial container (I don't think it would make a difference. I did try to run the whole thing in a xenial container but also did not reproduce the issue)
[14:05] <Odd_Bloke> AnhVoMSFT: Could you paste the full tox log for a failing run?
[14:16] <AnhVoMSFT> @Odd_Bloks https://pastebin.ubuntu.com/p/QMkhNtShjW/
[14:17] <AnhVoMSFT> @Odd_Bloke https://pastebin.ubuntu.com/p/QMkhNtShjW/
[14:18] <AnhVoMSFT> we're running "tox -e py3 -e xenial -e pycodestyle -e pyflakes -e pylint" in the build server but the very same command doesn't fail in my dev box
[14:51] <lucasmoura> Hi everyone, I am working creating a schema for cc_apt_configure, similar to what we have in other config modules such as cc_ubuntu_drivers. However, I don know how to properly handle the description we already have. Right now, it describes the all of the parameters the config accepts
[14:51] <lucasmoura> Should I add the entire text under the description key of the schema dict or should I break it down by property and just add an overall description for the description key ?
[14:55] <rharper> lucasmoura: have you looked at some of the other modules with schemas?  cc_ntp.py  ;
[14:56] <rharper> lucasmoura: I think you'll end up including much of the docs around the elements of the schema, and look at cc_runcmd.py, it pushed the examples into an 'examples'  parameter; and then we use get_schema_doc() to convert to docstring
[14:56] <lucasmoura> okay, I will take look at them. Thanks rharper
[14:56] <rharper> lucasmoura: and you can use tox -e docs to render the output to see how its looking,  checking https://cloudinit.readthedocs.io/en/latest/topics/modules.html#runcmd
[15:00] <lucasmoura> cool, thanks again rharper :)
[15:13] <Odd_Bloke> lucasmoura: Also `cloud-init devel schema -d cc_runcmd` will emit the documentation markup for cc_runcmd, which can be useful for iterating so you don't have to do a full doc run.
[15:50] <Odd_Bloke> Is the job log on https://travis-ci.org/github/canonical/cloud-init/jobs/683892541 failing to load for anyone else, or is it just me?
[15:52] <Odd_Bloke> (I forgot that restarting the job would wipe out the previous log (or lack thereof), oh well.)
[15:58] <Odd_Bloke> OK, pushing a completely new commit also doesn't fix it, so I'm going to leave that for a while and assume we'll see a Travis outage notification before too long. :p
[19:26] <Odd_Bloke> rharper: blackboxsw: lucasmoura: falcojr: smoser: I'm working on some more unit testing docs, and I'd like us to standardise the module-level constant we use in test modules for the prefix for the module under test (e.g. https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/tests/test_oracle.py#L19).  https://paste.ubuntu.com/p/wBx3mcG5Fj/ is a rough list of the ones we use currently.  I'd
[19:26] <Odd_Bloke> like to suggest we standardise on M_PATH in general, with an exception for DS_PATH in datasource tests.  What do you think?
[19:29] <lucasmoura> Odd_Bloke, No problem for me
[19:45] <rharper> Odd_Bloke: +1 on M_PATH ,  did we also standardize on the attribute name? m_<how verbose should this be?> m_util_subp?  m_config_cc_ntp_util_subp  ?
[19:46] <blackboxsw> lucasmoura: good work on https://github.com/canonical/cloud-init/pull/348#pullrequestreview-406931356
[19:46] <blackboxsw> I'm +1, awaiting CI
[19:47] <blackboxsw> falcojr: that approach might also relate to your work on https://bugs.launchpad.net/cloud-init/+bug/1876414 too
[19:49] <falcojr> what do you mean by approach?
[19:52] <blackboxsw> falcojr: ohh I mean that if you are adding unit tests that involve json schema we probably need to use the @skipUnlessJsonSchema decorator
[19:52] <blackboxsw> so unit tests will succeed on all distros. (some of which won't have Json schema)
[19:54] <falcojr> ahh, gotcha. Yeah thanks for the heads up. I think that can remove my file filter
[19:56] <Odd_Bloke> rharper: We do have the m_ prefix standardised (right above https://cloudinit.readthedocs.io/en/latest/topics/hacking.html#type-annotations).
[19:56] <rharper> Odd_Bloke: excellent
[19:59] <falcojr> why do we need an import check for jsonschema in our tests?
[20:00] <falcojr> jsonschema is in requirements.txt...is there somewhere that tests run that doesn't install requirements.txt?
[20:01] <Odd_Bloke> falcojr: The unit tests are run as part of the Ubuntu package builds (and hopefully other package builds) against the Python packages installed in the test system via debs.  xenial does not have the jsonschema dependency.
[20:01] <Odd_Bloke> (At least xenial, I just know that one for sure because lucasmoura and I happened to look at that patch during our conversation yesterday. :)
[20:01] <blackboxsw> falcojr: in cloud-init we have some dependencies that are considered optional runtime dependencies. If not present we have try/except ImportError blocks that handle graceful feature-disabling if the module isn't available
[20:02] <falcojr> interesting...thanks!
[20:05] <blackboxsw> the other python module which are not a hard/firm requirement are: cheetah (cloudinit/templater.py)  oauthlib.oauth1 (cloudinit/url_helper.py)  and I thought there was something else
[20:05] <lucasmoura> Does anyone know if it is possible to share a property in a local jsonschema ? For apt_configure, primary and security have the same config variables, so I thing it is best to define them once and reuse them on both fields. I was taking a look at ref, but since it is a python module, I think the pointer does not work properly...
[20:05] <blackboxsw> my fgrep-fu is not showing me the other "optional" runtime dependency
[20:06] <Odd_Bloke> pyserial.
[20:08] <Odd_Bloke> Jinja2 is also optional.
[20:09] <blackboxsw> thanks Odd_Bloke right, forgot about jinja and lumped that in my head with jsonschema :/
[20:10] <blackboxsw> Odd_Bloke: did we create a card or bug to better document cloudinit dependencies (hard vs 'soft')
[20:10] <blackboxsw> I thought we just talked about this
[20:16] <Odd_Bloke> blackboxsw: I have a post-it on my desk to do so, does that count? :p
[20:17] <blackboxsw> yes, yes I can see that clearly from the nanny cam I just had installed at your house. #countit
[20:19] <blackboxsw> merged https://github.com/canonical/cloud-init/pull/348 lucasmoura thanks!
[20:20] <lucasmoura> blackboxsw, great :)
[20:24] <blackboxsw> lucasmoura: I just manually added https://bugs.launchpad.net/cloud-init/+bug/1876412/comments/1 now that your branch merged and Fix Commited the bug https://bugs.launchpad.net/cloud-init/+bug/1876412/comments/1
[20:25] <lucasmoura> Thanks blackboxsw :)
[20:25] <blackboxsw> at some point lucasmoura and falcojr we'd probably like to extend our github automation to maintain launchpad bugs automatically on our behalf (like a cron job in travis or github action)
[20:25] <blackboxsw> just FYI so we don't have to manually maintain bugs in launchpad at some point
[20:25] <lucasmoura> makes sense
[20:42] <Odd_Bloke> I've opened myriad PRs today, BTW, I've been working through a backlog of papercuts.  Reviews much appreciated!
[20:49] <falcojr> I get errors building pyyaml when running tox...any obvious answers?
[20:54] <falcojr> bah, nevermind. My mental model of tox is broken. I thought it used its own virtualenvs for everything, but I get different results when running in a virtualenv
[21:44] <Odd_Bloke> falcojr: I've just reviewed #355, thanks for the PR!  As I say in the PR, I think this test would work well as a parameterised test.  Would you like to setup some time tomorrow to pair on converting it?