[Blueprint servercloud-r-juju-charm-testing] Juju Charm Testing

[Antonio Rosales]

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
+  * 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 ---
  
  (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
+     
+ 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.
+  
+ Interfaces doc link 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