Ubuntu system image

Merge lp://staging/~mvo/ubuntu-system-image/json-output into lp://staging/~registry/ubuntu-system-image/client

json-output
Merge into client

Proposed by Michael Vogt on 2015-02-27

Status:

Rejected

Rejected by:

Barry Warsaw on 2015-03-04

Proposed branch:

lp://staging/~mvo/ubuntu-system-image/json-output

Merge into:

lp://staging/~registry/ubuntu-system-image/client

Diff against target:

73 lines (+17/-2)

3 files modified

systemimage/config.py (+2/-0)
systemimage/download.py (+6/-1)
systemimage/main.py (+9/-1)

To merge this branch:

bzr merge lp://staging/~mvo/ubuntu-system-image/json-output

High

Fix Released

Link a bug report

Reviewer	Review Type	Date Requested	Status
Registry Administrators		2015-02-27	Pending
Review via email: mp+251226@code.staging.launchpad.net

Description of the change

This branch implements --json-ouput as described in bug #1423622.

Note that I did not test this yet, I have a bit of difficulties with
that. When I run "tox" on trunk I get all sorts of errors on my vivid
box that look unrelated. I also could not find a debian/ packaging
branch to test for real. Pointers appreciated :) I'm happy to do more
serious testing once I figured the testsuite and the debian/ dir out.

Revision history for this message

Barry Warsaw (barry) wrote on 2015-02-27:

I'd love to know what problems you had with tox. Be sure you have all the build dependencies though: `sudo apt-get build-dep system-image` should install them all (except for the new pycurl dependencies w/3.0, but I bet you already have those)

Normally, the packaging branch is here: bzr+ssh://bazaar.launchpad.net/~ubuntu-managed-branches/ubuntu-system-image/system-image/

But I am working on an mp for that to build si 3.0: bzr+ssh://bazaar.launchpad.net/~barry/ubuntu-system-image/citrain30beta/

Yeah, it's kind of schizophrenic and we should probably merge the debian/ into trunk, but hysterical raisins are so delicious!

Revision history for this message

Barry Warsaw (barry) wrote on 2015-02-27:

It's a nice simple branch (without the testing :) but I wonder if we'd ever want other formats of stdout progress, and whether we should extend the existing callback mechanism to implement this.

Right now, DownloadManagerBase takes a single callback function. What if instead we could register multiple callback functions and then _do_callback() would call each in turn? It would have to make sure that errors in one callback don't affect the others of course. But then it would just be a matter of implementing the JSON-to-stdout callback and adding it to the normal downloader callback stack.

The other thought I had was about the cli u/i. Maybe `--progress=json` would be translated into adding the JSON callback to the downloader stack. Or maybe `--progress=jsonv1` just to future proof us against possible different JSON contents?

main.py already adds a single callback function (e.g. differently depending on whether verbosity == 1 or not, though that should probably be verbosity >= 1). If state.downloader.callback were a list, it could just append to it instead of assigning to it. We could even allow for `--progress=dots` and `--progress=debuglog` to handle the current cases.

Revision history for this message

Barry Warsaw (barry) wrote on 2015-02-27:

Oh yeah, and don't forget the PPA! https://launchpad.net/~barry/+archive/ubuntu/systemimage

You can always grab the packages from there and test those (I'll be sure to upload a new version once this feature lands).

Revision history for this message

Barry Warsaw (barry) wrote on 2015-03-04:

https://code.launchpad.net/~barry/ubuntu-system-image/lp1423622/+merge/251819