=== 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
[17:31] <blackboxsw> powersj: I'm not quite understanding the need for ctest -- tree_collect or tree_run versus just collect and run
[17:32] <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:33] <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:34] <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:35] <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:36] <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:37] <powersj> please do :)
=== 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
[18:15] <blackboxsw> powersj: do you know where the template_override verbs are used "when: - create\n-copy" etc that I see in platforms.yaml?
[18:16] <blackboxsw> it seems template_overrides is only used on lxd-specific cases.
[18:17] <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:19] <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:36] <blackboxsw> ahh so these are lxd specifc metadata config options when building and configuring  containers
[18:40] <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:48] <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?
[19:22] <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.
=== rangerpb is now known as rangerpbzzzz
[21:11] <blackboxsw> man josh, this is a beast.
[21:11] <blackboxsw> 3700 lines. sorry it's taking me a while
[21:12] <blackboxsw> sorry 3200 lines
[21:12] <blackboxsw> adding another set of small nits
[21:13] <powersj> blackboxsw: no worries ;0
[21:13] <blackboxsw> :/ that I'm only 1/3 through it
[21:14] <blackboxsw> I'm gaining knowledge though on how different parts interact... so not just a code review.
[21:26] <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:28] <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:29] <blackboxsw> that last statement should have been a question: "or is the the feature flag really just intended to save time via skips?"
[21:32] <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:33] <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.