Charm Policy Review
[GOAL]
Update the charm policy to include new charm attributes, and ensure it is properly serving the charm community.
[RATIONALE]
As the charm store tips 130 charms, and new charm attributes are added it is necessary to evaluate the current policy and determine if any updates need to made in order to properly serve the charm community.
Blueprint information
- Status:
- Not started
- Approver:
- Antonio Rosales
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Jorge Castro
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
[USER STORIES]
Geddy is a sysadmin and is evaluating the charm store's quality for his deployments, he needs to ensure that things in the store jive with his company's assurance processes.
Alex is a devop who wants to contribute his work back to the community, but isn't sure how; he's adverse to spending too much time going through a process that won't return a benefit to him having his charm in the store.
Neil is a security admin at a company and needs to find out which charms are vulnerable to certain security issues and how that correlates to the rest of his Ubuntu deployment.
[ASSUMPTIONS]
[RISKS]
[IN SCOPE]
[OUT OF SCOPE]
[USER ACCEPTANCE]
[RELEASE NOTE/BLOG]
1308 vUDS: Etherpad: http://
[notes from cloudsprint 2013-05]
Topics:
Charm store policy and IS policy
Update current charm policy
Feedback from IS
Canonical Support
Policy AND a “best practice stuff that we do in production”
Juan wants 3 reviews before things goes into the store
When testing is good enough, scale back
[jorge]: Propose this as policy.
Current Policy concerns
Don’t build stuff in the charm ←- Dont add to policy (recommend as config parameter)
where stuff is installed (should be in /srv) ← Add to policy
ensure owner of the code is not the same as the owner running code ←-don’t add (is only)
create nagios checks ← Add to policy
noting which thing are critical checks
recommend on bash or python coding style ←- don't add, recommends
confirm data logs ← don’t add, recommends
properly sanitize sensitive config parameters in the GUI (GUI bug)
Policy: backport-config option. Charm updates must maintain backwards compatibility. A Charm should provide a means for a user to specify the upstream version and maintain backwards compatibility
3 acks for a charm review.
Work Items
Work items for ubuntu-13.05:
[jorge] Update charm policy to reflect charm quality requirements: DONE
[jorge] Define best practice for new charms: DONE
[jorge] Juju GUI updates to reflect policy changes: INPROGRESS
[jorge] Propose for policy: Backport-Config option. Charm updates must maintain backwards compatibility. A charm should provide a means for a user to specify the upstream version and maintain backwards compatibility.: DONE
[jorge] Propose for best practice: bits should be installed to /srv: DONE
[jorge] Propose for best practice: create nagios checks and note which things are critical to monitor: DONE
Work items:
Best practice: confirm where data logs are.: TODO
Best practice: don’t build stuff in the charm (recommend as a config parameter).: TODO
Best practice: If possible don’t run your service as root.: DONE
[jorge] File Juju-GUI bug to properly sanitize sensitive config parameters in the GUI.: DONE
[jorge] Split Juju Docs best practices and policy sections.: DONE
[jorge] Ensure relations/
[marcoceppi] Provide an example for interfaces in the wherever approriate: TODO
