[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
   * Jenkins Charm Testing: https://jenkins.qa.ubuntu.com/view/Charms/
  
- [USER STORIES] 
+ [USER STORIES]
  [ASSUMPTIONS]
  [RISKS]
  [IN SCOPE]
  [OUT OF SCOPE]
  [USER ACCEPTANCE]
+ [RELEASE NOTE/BLOG]
  
  (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