Blueprint changed by Antonio Rosales: Whiteboard changed: Discussion: *Bug submission on charm failure. *Define a process around how charm maintainers respond to test failures and subsequent bugs. Can a user run a manual test and submit the test back to the bug report to update testing status to green. *Enable Autocharm tester to be more resilient against provider failures, and Jenkins usage. simulate provider failure, and be able to recover: $ juju ssh <MACHINE> sudo shutdown now * Define WIs to execute auto charm testing on Go. * Continuous Integration (also will help with gating on charm commits) * Juju Testing Blogging * Juju testing communication to Juju lists. * Work on integrating/fixing Charm runner (graph testing/ dependency/env set up testing). Add a Jenkins workflow to run a charm or a set of charms in the following LXC environments: -raring container on raring host -raring container on precise host -precise container on raring host -precise container on precise host Reference Links: *Charm Test Spec [html] https://juju.ubuntu.com/docs/charm-tests.html * Charm Test Spec [source] http://bazaar.launchpad.net/~juju/juju/docs/view/head:/source/charm-tests.rst * CharmTester Charm http://jujucharms.com/~mark-mims/oneiric/charmtester * Charm Runner: https://launchpad.net/charmrunner * Jenkins Charm Testing: https://jenkins.qa.ubuntu.com/view/Charms/ - --- User Stories --- - - --- Risks --- - - --- Test Plans --- - - --- Release Note --- - - --- Blog Post --- + [USER STORIES] + [ASSUMPTIONS] + [RISKS] + [IN SCOPE] + [OUT OF SCOPE] + [USER ACCEPTANCE] (Needs spec and WI definition) -[a.rosales; 12-DEC-2012] === UDS 1303 Notes === Pad: http://pad.ubuntu.com/uds-1303-servercloud-r-juju-charm-testing Question: Is there a way in meta-data to explicitly state provider support. - -Example: Ceph: Does cloud provider have block support - -More broadly stated does the cloud provider have the capabilities the charm needs - + -Example: Ceph: Does cloud provider have block support + -More broadly stated does the cloud provider have the capabilities the charm needs + Idea: - -In charm testing status be able to show that a charm failure can be a result of the provider not providing the needed capabilities, ie the Ceph charm fails on a provider because it does not support object store. - -Make interface usage more verbose in the charm description. - -Need a rule/spec on how a interface should be implemented - -Need to investigate possible enforment of interfaces - -**Have the testing framework iterate through the operational deployment requirments. - + -In charm testing status be able to show that a charm failure can be a result of the provider not providing the needed capabilities, ie the Ceph charm fails on a provider because it does not support object store. + -Make interface usage more verbose in the charm description. + -Need a rule/spec on how a interface should be implemented + -Need to investigate possible enforment of interfaces + -**Have the testing framework iterate through the operational deployment requirments. + Interfaces doc link broken: - -Example: http://jujucharms.com/interfaces/ceph-client Interface doc link broken: - https://juju.ubuntu.com/Interfaces/ceph-client <-- broken + -Example: http://jujucharms.com/interfaces/ceph-client Interface doc link broken: + https://juju.ubuntu.com/Interfaces/ceph-client <-- broken Meta-language testing (http://paste.ubuntu.com/5588570/): Lanugage suggestions: http://lettuce.it/ http://cukes.info/
-- Juju Charm Testing https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-juju-charm-testing -- Ubuntu-server-bugs mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
