| === anticw_ is now known as anticw | ||
| === sambetts|afk is now known as sambetts | ||
| === shardy is now known as shardy_afk | ||
| === lunarlamp is now known as mariusv | ||
| === shardy_afk is now known as shardy | ||
| === rangerpbzzzz is now known as rangerpb | ||
| blackboxsw | powersj: I'm not quite understanding the need for ctest -- tree_collect or tree_run versus just collect and run | 17:31 |
|---|---|---|
| blackboxsw | if you don't pass a --deb to tox -e citest -- run doesn't it just perform the existing run against the cloud-init in the current branch? | 17:32 |
| blackboxsw | ... which seems to be the intent behing tree_run? | 17:32 |
| powersj | if you use collect and run you use the cloud-init that comes with the image itself. If you use tree_* you are going to run using the local tree. | 17:32 |
| blackboxsw | behind* rather | 17:32 |
| blackboxsw | ohhh | 17:32 |
| powersj | if you use --deb as you said, it will pull in that deb, but why force the developer to have a deb built locally. | 17:32 |
| powersj | tree_* will go and build the deb for you so you don't have to have all the build deps and build env setup. | 17:33 |
| blackboxsw | feels strange to me that citest -- run, since you have source locally in order to run these tests, wouldn't use the cloud-init tree as default test target | 17:33 |
| blackboxsw | ahhh it's to avoid debs | 17:34 |
| blackboxsw | ahhh it's to avoid deps | 17:34 |
| blackboxsw | ok | 17:34 |
| blackboxsw | ok I'm good now. thx | 17:34 |
| blackboxsw | though it kinda feels like instead of tree_collect and tree_run we could just provide a citest -- run --use-tree option right? | 17:35 |
| blackboxsw | or is there more to it than that? it seems tree_(run|collect) is just a mirror of run|collect right? | 17:35 |
| powersj | Well there are lots of options to go along with the building and I think this made the argparsing much easier | 17:36 |
| blackboxsw | thanks. I'll keep firing questions as I go through this until I get the context. | 17:36 |
| powersj | please do :) | 17:37 |
| === shardy is now known as shardy_afk | ||
| === shardy_afk is now known as shardy | ||
| === shardy is now known as shardy_afk | ||
| === sambetts is now known as sambetts|afk | ||
| blackboxsw | powersj: do you know where the template_override verbs are used "when: - create\n-copy" etc that I see in platforms.yaml? | 18:15 |
| blackboxsw | it seems template_overrides is only used on lxd-specific cases. | 18:16 |
| blackboxsw | but I don't really know where the consumer of that template is | 18:17 |
| powersj | so keep in mind we only have lxd as a platform, no other platforms are enabled right now | 18:17 |
| powersj | as far as when, I don't know off the top of my head | 18:17 |
| powersj | I'll try to look and see | 18:17 |
| powersj | looks like images/lxd.py:update_templates | 18:19 |
| blackboxsw | tests/cloud_tests/images/lxd.py yeah was just typing that too | 18:19 |
| blackboxsw | thanks | 18:19 |
| blackboxsw | ahh so these are lxd specifc metadata config options when building and configuring containers | 18:36 |
| powersj | yeah | 18:40 |
| powersj | if I recall we added this to later add various platform specific configs/options down the road | 18:40 |
| powersj | e.g. kvm with a couple storage devices or with multiple networks | 18:40 |
| blackboxsw | powersj: so I'm going through tests/cloud_tests/releases.yaml and looking over feature flags in general. Do you know where ubuntu_user or lsb_release feature actually turns into some sort of feature setup in #cloud-config during these vm tests? | 18:48 |
| powersj | blackboxsw: if you look at the test case yaml you will see the feature flags called out. The feature flags are not a cloud-init thing, but an integration test thing. | 19:22 |
| === rangerpb is now known as rangerpbzzzz | ||
| blackboxsw | man josh, this is a beast. | 21:11 |
| blackboxsw | 3700 lines. sorry it's taking me a while | 21:11 |
| blackboxsw | sorry 3200 lines | 21:12 |
| blackboxsw | adding another set of small nits | 21:12 |
| powersj | blackboxsw: no worries ;0 | 21:13 |
| blackboxsw | :/ that I'm only 1/3 through it | 21:13 |
| blackboxsw | I'm gaining knowledge though on how different parts interact... so not just a code review. | 21:14 |
| blackboxsw | so, powersj feature flags are just arbitrary strings that some unit tests claim to require and some distros and series claim to support per releases.yaml? | 21:26 |
| powersj | bingo | 21:26 |
| blackboxsw | it's basically a set of bools that each release claims to support. man I thought there was more to it. | 21:26 |
| blackboxsw | ok, so is it kindof out goal to make tests flexible enough to avoid having to exlude it based on a feature? | 21:28 |
| blackboxsw | is the the feature flag really just intended to save time via skips | 21:28 |
| blackboxsw | that last statement should have been a question: "or is the the feature flag really just intended to save time via skips?" | 21:29 |
| powersj | I think no to both. For example, we want to be able to have apt based tests that only run on debian, and just skip on centos/rhel/fedora | 21:32 |
| powersj | Yes the test case could have logic that collects what release it was on and exit before hand, but that seems more complicated than just saying this test needs x feature so don't run on y. | 21:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!