I anticipate this being more CI than unit testing - but will leave exact timings to Ben and Derek.
This session will include the following subject(s):
Unit testing TripleO and Friends:
TripleO currently has a CI system in place that does a good job of covering the basic devtest workflow, and makes sure changes that break said workflow don't get in. However, it cannot reasonably be expected to cover every possible code path in TripleO and the associated projects. That sort of coverage requires unit testing, which is something that is rather lacking in most of the TripleO projects right now.
This lack of unit testing puts more pressure on reviewers - not only do they need to review for big picture issues, they also have to watch for simple correctness. It's entirely possible for changes to be submitted that just plain don't work. Unit testing would, at least in some cases, alleviate this by allowing them to trivially check that the unit tests cover the changed code, and as long as the gate/check job passes the code is most likely functionally correct.
Some specific topics that could be discussed: -Additional infrastructure needed to test some parts of TripleO (for example, a fake root environment that would allow testing of scripts that expect to write to system file locations) -At what point should we start requiring unit tests for new features. -What, if any, things do we not want to require unit tests for. For example, some incubator scripts might be going away and thus not worth the effort. There also may be configuration scripts that don't make sense when run outside the context of a deployment. -Methods of testing - Python unit tests, Bash unit testing frameworks, etc.
(Session proposed by Ben Nemec)
TripleO CI :
I like to spend some time talking about o where tripleo ci should go next o what our short and medium term priorities should be o how to best use the resources we have o dealing with outages
