lp:~rharding/charmworld/proof-config-2

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:~juju-jitsu/charmworld/trunk at revision 426

Juju-Jitsu Hackers: Pending requested 2013-10-22

Diff: 1009 lines (+419/-407)

9 files modified

charmworld/lib/proof.py (+0/-33)
charmworld/lib/tests/test_proof.py (+2/-72)
charmworld/models.py (+17/-1)
charmworld/tests/test_models.py (+39/-0)
charmworld/views/api/__init__.py (+4/-132)
charmworld/views/api/proof.py (+145/-0)
charmworld/views/tests/test_api.py (+4/-169)
charmworld/views/tests/test_proof.py (+175/-0)
charmworld/views/utils.py (+33/-0)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

430. By Richard Harding on 2013-10-22

garden

429. By Richard Harding on 2013-10-22

Update tests and calls to pass

428. By Richard Harding on 2013-10-22

Working on tests, still failing

427. By Richard Harding on 2013-10-22

Working on tests

426. By Richard Harding on 2013-10-20

Garden

425. By Richard Harding on 2013-10-20

Rearrange the proof code and split the logic into more usable parts

424. By Richard Harding on 2013-10-18

Add charm config proofing and update api response

- Move proof logic into a new lib/proof.py module
- Update the proof api call to look through the bundles and proof them
- Change errors to be catchable exceptions, the exception contains both a msg
and debug_info we expose via the api call
- Update the api call to provide a summary error_messages (for Marco's needs)
but keep the details in the actual list of errors with the messages and the
debug info we have that went into those errors.

Sample proof api call and response:
http://paste.mitechie.com/show/1049/

Note: this is only adding the new proof checks of validating the
config/options from the charm found in the database to the options defined in
the bundle.

- Validate the option exists in the charm we found in the db
- Validate that the type is of the correct type.
- Validate that the charm we found has options at all.

QA
---
You have to ingest the charms so that we can validate them. You can then toss
the yaml file (as a single string) to the proof api endpoint as a POST'd key
deployer_file. Right now it only handles yaml.

R=
CC=
https://codereview.appspot.com/14789043

423. By Brad Crittenden on 2013-10-18

Make queue and ingest handle prior charm revs.

In order to support multiple charm revisions, the queueing and ingest
processes must support older revisions of charms.

Up to 10 old revisions of a charm are queued up for ingesting. A charm that
is not the latest revision is not updated in the database if it already
exists. A current revision of the charm is updated even if it exists. This
updating may not be required as a charm cannot change without updating the
revision.

Approved by Juju Gui Bot, Richard Harding.

422. By j.c.sackett on 2013-10-17

Better latency calculation for tasks.

Approved by Juju Gui Bot, Aaron Bentley.

421. By Abel Deuring on 2013-10-16

Fix string type handling of the config.yaml linter: Use charmtools 1.1.0-253-cw.

Approved by Juju Gui Bot, Brad Crittenden.