[Blueprint servercloud-p-cfjuju] Juju: Configuration Management for Juju

Marc Cluet marc.cluet at canonical.com
Mon Jan 9 09:54:32 UTC 2012


Blueprint changed by Marc Cluet:

Whiteboard changed:
  Work Items:
  [lynxman]  write puppet external node classifier for juju status -> puppet: TODO
+ [lynxman]  write puppet facter integration out of juju status information: TODO
  [clint-fewbar] Start project for recovering useful information out of juju status: TODO
  [juju] after colocation investigate cli interface for local / arbitrary unit / relation info: TODO
- 
  
  Session notes:
  
  We have detected a need for DSL integration in Juju, this would mean
  that any of the current configuration management applications available.
  
  Advantages
  * Faster implementation of juju on running platforms
  * Faster testing of juju on individual nodes
  * Complements the amazing capabilities of juju with some node specific templating
  
  TALKING POINTS
  * What can DSL integration provide to juju
-   - How it can complement the juju ecosystem
+   - How it can complement the juju ecosystem
  * Ways to export through a RESTful interface metadata from Juju
-   - Ensure freshfulness statefulness of data
+   - Ensure freshfulness statefulness of data
  * Ways to implement this so Juju can action on this without problem
-   - Charm integration
-   - Ways of informing back to juju about provides from DSL systems
+   - Charm integration
+   - Ways of informing back to juju about provides from DSL systems
  * Finding ways around the SPOFs
-   - How to survive in case of miscommunication or recoverable failure
+   - How to survive in case of miscommunication or recoverable failure
  
  Juju roadmap right now has priority on colocation
  Colocation can be used in colocation mode as well
  Colocated service has access to filesystem services (whichever they are) and can establish master/slave relationships with the master unit
  Juju charms can trigger an update of the facter information since it's always stateful, it can be a "trigger" on the update hook
  So far the best action would be to query the CLI (juju status) and its a very effective way to recover information from juju in a quick (albeit slightly dirty) way
  
- 
  ACTIONS
  [lynxman]  write puppet external node classifier for juju status -> puppet
  [clint-fewbar] Start project for recovering useful information out of juju status
  [juju] after colocation investigate cli interface for local / arbitrary unit / relation info

-- 
Juju: Configuration Management for Juju
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-cfjuju



More information about the Ubuntu-server-bugs mailing list