Charm Policy Review

Registered by Antonio Rosales on 2013-04-25

[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

Related branches

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://pad.ubuntu.com/uds-1308-servercloud-s-juju-charm-policy-review

[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/interfaces are documented per charm in charm-helpers: TODO
[marcoceppi] Provide an example for interfaces in the wherever approriate: TODO

This blueprint contains Public information 
Everyone can see this information.