René, I'm actually quite interested in what you learned about setting up the simulator in docker. A 2 GB image is no problem for our CI system. A startup time of 5 - 10 minutes is completely workable as well.
- Matt On Sunday, January 22, 2017 at 2:31:39 PM UTC-8, René Moser wrote: > > Hi > > I am not sure if this fits onto the devel ML, so if there is a better > place to discuss it, let me know. > > I've worked on the automated integration testing for cloudstack modules > and just wanted to get some feedback regarding, is this "the way to go" > > > RUN TESTS AGAINST CLOUDSTACK PRs > ================================ > > My intention is to run integration tests on PRs automated but only if > the PR has changes in one of the following paths: > > - lib/ansible/module_utils/cloudstack.py > - lib/ansible/modules/cloud/cloustack/ > > If the change is in a cloudstack module, e.g. "cs_user", tags e.g. > test_cs_user can be applied so only tests with this tag gets executed: > > make cloudstack TEST_FLAGS="--tags test_cs_user" > > I didn't find a way in the current setup but I remember a discussion > (mattclay?, gundalow?) that this might be already possible in the > current test setup. Hay anyone more infos about that? Or point me to the > right direction? > > > SIMULATUR TEST SETUP > ==================== > > So how does the cloudstack module testing setup work. > > There is a "thing" in cloudstack which let's you simulate an hypervisor. > > (I don't want to go into details but I tried the last couple of weeks to > make it work with docker but the result was a full blown image with > 2 > GB and the initialization would take rather long.) > > There is a pre-set endpoint at http://cloud-sim.resmo.ch (HTTPs is in > the queue) and the API http://cloud-sim.resmo.ch/client/api. > > API ACCESS > ========== > To get access to the API, an api key and secret is required. These are > "generated" and may change over time. Therefore I made an export to > http://cloud-sim.resmo.ch/admin-keys.json where I put more persistent > auth mechanism in front. > > The role "cs_test_prepare" takes care of all the test preparation, > getting the keys and put in a cloudstack.ini, from where it will be read > by the cloudstack modules (See PR > https://github.com/ansible/ansible/pull/20552) > > So as I said http://cloud-sim.resmo.ch/admin-keys.json is auth protected > and the cs_test_prepare needs the BASIC AUTH username and password which > is expected in ENV vars CLOUDSTACK_SIMULATOR_USERNAME and > CLOUDSTACK_SIMULATOR_PASSWORD > > This means a full test run can be made by running: > > export CLOUDSTACK_SIMULATOR_USERNAME=... > export CLOUDSTACK_SIMULATOR_PASSWORD=... > make cloudstack TEST_FLAGS="--tags test_cs_user" > > These env variables can be put into secure env variables in > shippable.yml > > http://shippable-docs-20.readthedocs.io/en/latest/config.html#secure-environment-variables > > > FEEDBACK > ======== > > I would like to get some feedback if this is the way it is meant to be > done, or if it would be more appropriate to run it in a dedicated CI > environment locally and just provide the tests results for the PR. > > I also thought about a way to hook external CI which then feed back the > results in a link as comment, e.g.: > > shippable detect changes in cloud/cloudstack in a PR--> hooks > ci.resmo.ch --> runs tests agains cloud-sim.resmo.ch --> ci.resmo.ch > reports back tests results to the PR. > > Thanks for your feedback. > > René (resmo) > -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
