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

Antonio Rosales antonio at canonical.com
Thu May 2 18:32:55 UTC 2013


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
+ 
+ Two modes of testing:
+  -Unit (does the charm start, and report ready)
+  -Workload (test the charms relations, and pushing data)
  
  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]
  [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/
  
  Charm-Runner integration:
-  - https://launchpad.net/juju-deployer
+  - https://launchpad.net/juju-deployer
  
  Wrap Go/Py juju client status:
-  - https://launchpad.net/python-jujuclient
+  - https://launchpad.net/python-jujuclient

-- 
Juju Charm Testing
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-juju-charm-testing



More information about the Ubuntu-server-bugs mailing list